this post was submitted on 22 Jul 2023
278 points (97.3% liked)

Programmer Humor

19809 readers
284 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 7 points 1 year ago (2 children)

You can always revert (i.e. undo in a new commit) the faulty commit. That will keep the history. This meme is not just about pushing straight to master, it's about push --force which overwrites the remote branch completely, changing history.

[–] [email protected] 3 points 1 year ago (2 children)

What happens when you want to merge again? Won't it say already up to date or something cause the commits are already there?

[–] [email protected] 5 points 1 year ago (1 children)

Revert doesn't just move head back, it creates reversal commits. As such, merging again can happen since the changes are present and require a merge commit

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

There are situations where it does actually cause problems when you want to merge the branch again. It knows that those specific commits have already been reverted once, so it doesn't apply them...

See also: https://github.com/git/git/blob/master/Documentation/howto/revert-a-faulty-merge.txt (especially line 56)

Basically you need to revert the revert, before re-merging the fixed branch. Otherwise you will lose commits without noticing!

[–] Gecko 2 points 1 year ago (1 children)

You could just rebase your develop branch to a commit before the merge and have a different commit history, or actually do it properly and have squash merges.

[–] [email protected] 1 points 1 year ago

do it properly and have squash merges

If you have big features that deletes a lot of maybe important commit history.

[–] [email protected] 3 points 1 year ago (1 children)

Sometimes there's only the nuclear option left, I have only done it a few times, someone merged a major refactoring and we ended up reverting by changing history.

I have also observed that when you revert with git revert and then merge back some time later git can get confused about if a commit was merged or not.

Mind you we didn't use git flow or other smart processes to our own regret.

[–] [email protected] 2 points 1 year ago* (last edited 1 year ago) (1 children)

git can get confused about if a commit was merged or not.

You have to revert the revert before re-merging the branch. Otherwise git keeps track of the commits that you reverted and doesn't apply them ever again.

See: https://github.com/git/git/blob/master/Documentation/howto/revert-a-faulty-merge.txt

[–] [email protected] 2 points 1 year ago

Thanks for the info, I think that's exactly what we didn't do.