836

Well well well. (lemmy.ml)

submitted 2 days ago by ipconf@lemmy.ml to c/programmer_humor@programming.dev

129 comments fedilink hide all child comments

Yeah learned this the hard way.

top 50 comments

sorted by: hot top controversial new old

[-] cmhe@lemmy.world 20 points 2 days ago* (last edited 1 day ago)

Isn't it the exact opposite?

I learned that you can never make a mistake if you aren't using git, or any other way for having access to old versions.

With git it is really easy to get back to an old version, or bisect commits to figure out what exact change was the mistake.

The only way I understand this joke is more about not wanting to be caught making a mistake, because that is pretty easy. In other methods figuring out who did the mistake might be impossible.

[-] AeonFelis@lemmy.world 14 points 1 day ago* (last edited 1 day ago)

This is not about mistakes in the Git-managed code. This is about mistakes in the Git commands themselves. Anything that involves merging/rebasing/conflict resolution can potentially be botched. These mistakes are usually fixable, but:

Fixing it requires some Git proficiency behind the level of the common Git user.
If you don't catch it in time, and only find the mistake when it's deep in your layers of Git history - well, good luck.

[-] LePoisson@lemmy.world 5 points 1 day ago

Went to tech elevator boot camp, was a decent experience even if I don't find myself doing exactly what I was expecting to do. Life is that way though.

Anyways, my first week I fucked some git stuff up so bad I became the go to guy when anyone had any git issues because I had to learn so much to undo my egregious error. I don't remember now exactly what it was but it took some serious git magic to sort.

Just saying that point 1 is very true. And yeah don't make mistakes in git.

load more comments (3 replies)

[-] fibojoly@sh.itjust.works 4 points 1 day ago

You're confusing errors in your code, and errors while doing some git command you thought you knew. Lucky you, it's clearly never happened to you because you don't mess around with it.

load more comments (4 replies)

[-] QuizzaciousOtter@lemmy.dbzer0.com 45 points 2 days ago* (last edited 2 days ago)

Use git for any code you write. Yes, even a simple script.
Commit and push often. More often than you think is reasonable. You can always rebase / fixup / squash / edit but you can't recover what you didn't commit.
???
Profit.

Seriously, once you commited something to the repo it's hard to lose it. Unless you delete .git. But a this point frequent pushing has your back.

I know git can be hard to grasp in the beginning. It was hard for me too. I highly encourage everyone to put in the effort to understand it. But if you don't want to do that right now just use it. Just commit and push. It will pay off.

[-] Rooster326@programming.dev 8 points 2 days ago* (last edited 2 days ago)

(3) Get annoyed by constantly increasing Code Coverage Requirements on untestable (often legacy) code. Even afding comments requires code coverage go up! Line must always go up!
Change step 2 to "Commit and push ONLY when absolutely necessary. Because adding comments often requires a rewrite of untestable code."
Go back to Step 2 and wait for a major bug.

[-] QuizzaciousOtter@lemmy.dbzer0.com 1 points 1 day ago

3 is not related to using git in any way. I'm not really sure what you mean in 4. I didn't mean making a lot of changes, I meant that you should not wait with committing until you have a finished feature / fix / whatever. Commit after each refactor, commit after adding a new testable unit. It's always better to have more checkpoints. If your team does code review, they will appreciate atomic commits too.

[-] fibojoly@sh.itjust.works 3 points 1 day ago* (last edited 1 day ago)

Our company "architects" decided we needed 80% coverage minimum. On a mostly .Net 4.8 codebase. Hundreds of programs used in prod, with barely any tests in sight.
It's a fucking nightmare.

[-] Metju@lemmy.world 1 points 21 hours ago

Ah, the classical "just introduce tests in a legacy codebase", what can go wrong?

My condolences, it's always a BITCH to handle

load more comments (1 replies)

[-] Ephera@lemmy.ml 137 points 2 days ago

I've had juniors who didn't believe this, so just to say it: If you know what you're doing, practically any Git problem is recoverable.

The one major exception is if you delete your local changes before committing them.

[-] sorter_plainview@lemmy.today 51 points 2 days ago

Yeah.But many of them are extremely annoying. Specifically screwing up rebase. It is recoverable, but very annoying.

That said I have seen juniors make two other common mistakes.

Pushing your commit without fetching
Continuing on a branch even after it was merged.

I'm fed up with these two. Yesterday I had to cherry-pick to solve a combination of these two.

[-] psycotica0@lemmy.ca 39 points 2 days ago* (last edited 2 days ago)

Maybe I'm just a wizard, or I don't know what y'all are talking about, but rebases aren't special. If you use git reflog it just tells you where you used to be before the rebase. You don't have to fix anything, git is append only. See where the rebase started in reflog, it'll say rebase in the log line, then git reset --hard THAT_HASH

Pushing without fetching should be an error. So either they got the error, didn't think about it, and then force pushed, or someone taught them to just always force push. In either case the problem is the force part, the tool is built to prevent this by default.

Continuing after merge should be pretty easy? I'd assume rebase just does it? Unless the merge was a squash merge or rebase merge. Then yeah, slightly annoying, but still mostly git rebase -i and then delete lines look like they were already merged?

[-] sorter_plainview@lemmy.today 19 points 2 days ago

See all this is fine for someone with good experience in git. They know how to solve the screw up. But wih junior devs, who don't know much about it, they will just get confused and stuck. And one of the senior has to involve and help them solve. This is just annoying because these can be avoided very easily. Until they understand the pattern of how everyone operates with git, it just creates issues.

To me first time causing this issue is completely fine. I will personally sit with them and explain then what went wrong and how to recover. Most of them will repeat it again, act clueless and talk like they are seeing this for the first time in their life. That is the difficult part to me.

May be I'm just old school, and a grumpy old person, even though I'm not that aged.

[-] psycotica0@lemmy.ca 3 points 1 day ago

Oh, the human interaction is annoying! Yeah gotcha. That makes more sense!

load more comments (1 replies)

load more comments (6 replies)

load more comments (11 replies)

[-] sucoiri@lemmy.world 3 points 1 day ago

Fun fact! If you added a file but never committed it you can still recover it with git fsck --lost-and-found. The changes were still added to the git object store, and by grepping through the dangling blobs you can find the object containing the changes you care about.

load more comments (10 replies)

[-] isVeryLoud@lemmy.ca 6 points 1 day ago

git reflog is your friend

The worst thing you could do is delete your local git repo.

[-] sik0fewl@lemmy.ca 48 points 2 days ago

git reflog

[-] squaresinger@lemmy.world 29 points 2 days ago

git re-flog is what you do with those idiots who mess up the repo so that someone else has to come in and fix it again.

load more comments (13 replies)

[-] csm10495@sh.itjust.works 27 points 2 days ago

Special shout out to the person who committed a gigabyte memory dump a few years ago. Even with a shallow clone, it's pretty darn slow now.

We can't rewrite history to remove it since other things rely on the commit IDs not changing.

Oh well.

[-] Michal@programming.dev 11 points 2 days ago

Sounds like a flawed workflow, if this didn't go through at least code review. Was it committed directly to master?

Curious to know what kind of system relies on hashed not changing? Technically the hashes don't change, but a new set of commits is made. The history diverges, and you can still keep the old master if you need it for some time, even cherry pick patches to it..

load more comments (6 replies)

[-] Anafabula@discuss.tchncs.de 24 points 2 days ago

With Jujutsu (which is compatible with git), you can just

jj undo

[-] JustTesting@lemmy.hogru.ch 14 points 2 days ago* (last edited 2 days ago)

Been using it for over a year now and not being scared of trying operations is such a boon. It helps so much with learning when you know you can just roll back to an earlier state.

I've had zero issues with it so far and no one at work noticed anything different, other than there being a bit more rebase spam on PRs.

[-] umfk@lemmy.world 9 points 2 days ago

That is so cool. Why doesn't git have this already?

[-] kata1yst@sh.itjust.works 10 points 2 days ago

I mean, by definition, it does. It just involves parsing through the git log and a bunch of unintuitive, archaic commands.

load more comments (1 replies)

load more comments (2 replies)

[-] kibiz0r@midwest.social 32 points 2 days ago

Git repository operations are (almost?) always recoverable. git reflog is your friend.

The filesystem operations are another story. Handle with care.

load more comments (6 replies)

[-] Eiri@lemmy.ca 19 points 2 days ago

As long as you never touch the rebase button, you'll be fine. Probably.

[-] GissaMittJobb@lemmy.ml 14 points 2 days ago

Don't be afraid of rebases, they are an essential tool in Git.

This particular fear can only be addressed by understanding.

[-] Eiri@lemmy.ca 1 points 15 hours ago

I don't understand it. Every time I see something about a rebase it's some purist telling me it's "cleaner". Never got it to do what it says on the tin, and never hit a situation that I couldn't solve using more straightforward tools like merge.

[-] GissaMittJobb@lemmy.ml 2 points 12 hours ago

What's your mental model for a Git commit, and a Git branch?

Once I properly learned those two concepts, understanding rebases became a lot easier.

I'll try to explain it to the best of my abilities.

Think of a commit being a patch - a description of how to take a particular file from one state to another
A branch is a list of patches to be applied in order, from the point where the branch was created until the last commit on the branch

When you rebase a particular branch, what you're essentially doing is taking all of the commits that are currently on your branch, checking out the other branch, and then applying each of the patches in order on that new branch.

A rebase can be cleanly applied if the premise for each commit has not changed when applied, but if the premise has changed, you get a conflict to be resolved before being able to continue the rebase.

I mentally model a rebase a bit as a fast version of how it would look like to build the branch I was on, but on top of the branch I'm rebasing on.

[-] Eiri@lemmy.ca 1 points 7 hours ago

That's a good explanation of what it's supposed to do. That was how I understood it as well.

But anytime I've tried it, I've ended up with conflicts where there shouldn't be (like, I already solved that conflict when I merged earlier) and/or completely undesirable results in the end (for instance, some of my changes are just NOT in the result).

So I just gave up on the whole feature. Simpler to just merge the source branch into mine.

[-] GissaMittJobb@lemmy.ml 1 points 6 hours ago

Depending on how structured your commits have been, it can either be very difficult to get a rebase through or a complete breeze. There are some features to make it easier - rerere being the main one I'm thinking about.

[-] Eiri@lemmy.ca 1 points 6 hours ago

Is that what interactive rebase tools use?

I don't do CLI git

[-] GissaMittJobb@lemmy.ml 1 points 53 minutes ago

You enable it using git config, after that it will apply to whatever frontend you're using.

[-] pupbiru@aussie.zone 10 points 2 days ago

…button

[-] LedgeDrop@lemmy.zip 11 points 2 days ago

... and force push.

If you ever find yourself in a situation where rebase or a force push seems to be the solution, take a step back, clone your repo in a new directory and copy the changes into you're new checkout - 'cause you gon' and screwed somethin' up, son.

[-] Eiri@lemmy.ca 1 points 15 hours ago

Hmm, I'm less afraid of force push. It does what it says on the tin. If I pushed a fuck-uo to remote and a reset is the simplest way out, you can bet I'm force-pushing that reset.