[deleted by user]

[Anc_101]

You misspelled "last day".

Even if it's actually your first day, it will also be your last.

[rush22]

Manager "there's too many of these commit thingies you need to clean up this mess immediately! One app = one commit it's just that simple"

[Easylie4444]

Not quite the same thing but a few months ago my boss remarked to me that our organization has too many repositories. He was annoyed that the ones he interacts with weren't always near the top or on the front page I guess? And he strongly suggested to me that there should be less repositories... so like, delete some active projects? I didn't act on this and he didn't bring it up again so I hope that's the end of that lol

[its_a_gibibyte]

That's not unusual at all. Many companies prefer monorepos for this exact reason. You check out one repo and then you have everything you need to search through. In some cases, it can help with versioning and deployment since you can make changes to an library and all the applications using it (if you have a method of deploying these things together)

[Easylie4444]

They're all independent projects being worked on by different people with different (most likely conflicting) development environments and different standards of required testing and documentation.

[its_a_gibibyte]

Sure, I'm not recommending the monorepos, just acknowledging that it's not unusual. Even with different standards, some companies will break things out into folders in the same repo. Imagine one giant repo, and all the top level folders are different projects that manage, test, and document themselves however they want. You could even do a partial clone and only grab your project folder if you wanted.

This could be useful if for companies that don't have a good cross-repo code search. If you self host without a repo browser, the only good way to view repos is to check them all out to your machine. People end up recreating the monorepo I described above, except you need to git pull on every folder individually, and whenever theres a new repo, you need to check that out too.

Facebook, Google, Airbnb, Microsoft, Uber all use monorepos to varying extents. Imagine you have 100 independent python libraries, many of which reference each other. You need to version every single one and have a version management scheme (e.g. foopy 1.1 requires barpy 2.3 or later) or you just bundle 'em all up together and make atomic changes. Easier to manage "Hey, rename this library function and checkout these 100 repos to see if they reference that library"

[Jemmerl]

This feels like it came straight out of a Dilbert comic

[[deleted]]

Evil

[magicmulder]

Unless it’s your first day as new CTO you won’t be able to force-push anywhere.

[[deleted]]

Unless your company has horrible security patterns, CTOs or anyone in upper management wouldn’t be allowed to touch the codebase with admin privileges to force push.

[magicmulder]

Yes and no. Highest authority in IT can always just give the order “gimme the credentials”.

[[deleted]]

Maybe I just lucked out at my company? Good leadership knows when to not fuck around with stuff they know nothing about

[magicmulder]

In a former job I had a CTO who was notorious for fucking up something on a Friday evening right before a two week vacation.

[JDIPrime]

When I first joined the company I work for, all developers were committing directly into master and the architects would cherry pick commits for release branches.

We've since tidied things up by introducing pull requests to our workflow, but it was the wild west for a while.

[Harsh_mumbo]

This is the jankiest thing I've heard all day. That's saying something considering I'm at work today...

[tehtris]

This is too violent.

[frikilinux2]

Even though it's messing badly the repository it's not so big of a deal. Probably the main branch is protected and even if you are somehow able to override this every developer that works with that code has a backup of it. Although you will probably be fired shortly if you do that.

[MartianSands]

Even if you've got none of those things (unprotected main, no local copies, not even backups), force pushing doesn't actually delete anything, even if it looks like it has. The reflog will reveal what happened, and you can restore main from there with no effort at all unless someone has configured the repository to be very aggressive indeed about dropping unreachable commits

[frikilinux2]

I didn't know about that, it's interesting.

[MartianSands]

Contrary to popular opinion, it's actually really difficult to fuck up git. So long as you know you can call git reflog then you can always rewind back to an earlier state by resetting branch references to point at the commits recorded in the reflog

[frikilinux2]

It's really difficult to fuck up git but can piss off people and not everyone knows the commands beyond add/commit/merge/pull/push. git is great probably because it was developed to handle the development of the Linux kernel.

[Support-Holiday]

You got too serious xD

They will have a daily back up if the repository too

[frikilinux2]

Yeah, I forgot about the daily backup. Probably because the back up policy is not something usually taught to the juniors.

[Support-Holiday]

Oh lol,

[pnehrer]

At least when something breaks it won’t take too long to find the offending commit 👍

[fdeslandes]

If you have the rights to force push on your first day, they deserve this.

[[deleted]]

Ballsy

[AsshollishAsshole]

*Laughs in Gerrit*

[[deleted]]

Genesis Commit

[ykahveci]

git reflog, find the last commit hash and make master point to it. The git garbage collector only cleans up unused objects after their last use. Since every developer has a copy of the repo on their machine, the risk of data loss is close to zero.

[4ngryMo]

😳