Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git rebase, what can go wrong

jvns.ca

Post reply on HN
Print view View original

111–120 of 404 posts

Re: Git rebase, what can go wrong

#111

Post by ruds »

sidlls wrote: post #107
FeepingCreature wrote: post #87

Earlier quoted context omitted.

Not parent: there are technical commits, such as "fix review", "fix jenkins", "fix typo" etc. Those don't delineate a particular feature but a fix for a problem that arose from the workflow. This ends up with a history of "big feature commit that is wrong in three trivial ways" + "fix 1" + "fix 2" + "fix 3". Of those, "big feature commit" is the important one, but "fix 3" is the only working one. This is clearly sill…

Perhaps I'm missing something, but I don't see how your comment answers my questions. Do you mean that a "clean history" is one without "fix 1", "fix 2" and "fix 3"? Or is that a "semantically delineated commit"?

A clean history is one where there is a single commit, "big feature commit", that produces a worktree that is the same as the one produced by "fix 3" in the "unclean" history.

Re: Git rebase, what can go wrong

#112

Post by jimbob45 »

dkarl wrote: post #92
recursive wrote: post #5

Earlier quoted context omitted.

Squash merges cut down the noise considerably.

I think squash merges are a last resort heavy-handed tool for dealing with developers who refuse to clean up their commit history before merging. Most developers can do better by hand. Git history should tell a simple, understandable story of each change. For example: 1) refactor existing code, 2) add feature. Or 1) add missing tests, 2) refactor existing code, 3) add feature. But since you're working on the fly with…

I think squash merges are a last resort heavy-handed tool for dealing with developers who refuse to clean up their commit history before merging. Most developers can do better by hand.

This is too much thought put into a VCS. I don’t want to have to think about my VCS at all beyond the commit message. For all of Git’s popularity, I’ve never seen benefits that justify the absurd amount of work and knowledge it takes to perform simple actions. It’s the VCS equivalent of Scheme or emacs.

Re: Git rebase, what can go wrong

#113

Post by Arch-TK »

btilly wrote: post #48
ajkjk wrote: post #12

Earlier quoted context omitted.

Never understood why you wouldn't want it clean. There's no benefit whatsoever to it being messy and it's a liability for a lot of reasons, whereas the clean version is free and easy and makes everything you do that interacts with git history simpler.

There is a giant benefit to it being messy. And that is that the mess is the actual history. Every time you do a git rebase, you are literally asking your source control system to lie about history. If you mess up, and you eventually will, you're then forced to manually figure out what the history really was despite being lied to. If you mess it up, well, good luck. I used to work at a company where someone (we never…

If you think the mess (i.e. 50 mixed up mini commits as you work on a feature and iterate on it) is useful history (it usually isn't) then use a different DVCS because git was not designed around this mode of operation and a lot of its advanced features work poorly when applied to such a history.

Alternative DVCSes which support this workflow include: fossil

Re: Git rebase, what can go wrong

#114

Post by btilly »

foobarbaz33 wrote: post #104
btilly wrote: post #48

Earlier quoted context omitted.

There is a giant benefit to it being messy. And that is that the mess is the actual history. Every time you do a git rebase, you are literally asking your source control system to lie about history. If you mess up, and you eventually will, you're then forced to manually figure out what the history really was despite being lied to. If you mess it up, well, good luck. I used to work at a company where someone (we never…

> the mess is the actual history. The true history is not recorded in your normal commits either. Every time you modify your source buffer, that is the true sequence of events. This truth is lost already as you undo/rework things before you commit. You're ALWAYS manipulating and telling a false story of history whether you realize it or not. Commits are a tool that give stronger backup/undo protections over simple fi…

I believe that you are confusing "full history" and "true history".

Every single point in the commit history represents an actual state of a repository at a specific point of time, along with the information of which point or points were next before it. This is all part of the true history.

This is not a full history - you don't have every keystroke, abandoned commit, switch between branches and so on. But nothing that you're being told is wrong.

As soon as you do a rebase, you're rewriting history. You're claiming that there were specific points of time with specific states that never actually existed. You're losing information about points of time and specific states that actually existed, which someone once considered important enough to do a git commit over.

The difference becomes important if that someone, which at a previous job was me far more often than I would like, tries to go back to the historical commit. And finds that it is gone without a trace.

Re: Git rebase, what can go wrong

#115

Post by khalilravanna »

AndrewDucker wrote: post #70

I find it fascinating that people talk about "Having a history of what people did" in such emotive terms - "Cluttering", "Polluting". What matters is that you end up with working systems. That a lot of change happened is just, well, what happened. It doesn't need to be prettied up and made to look like your development occurred in a clockwork march of cleanliness. It literally does not matter unless you spend a lot o…

I think if the definition of a “good history” is “clean and not messy”, then yes I agree that’s pointless. If the definition is “a clear ability to see what changes were made, by who, and most importantly why” I think that’s incredibly necessary and would even go so far as to say it’s naive at best to not support.

The amount of time that has been saved in my life by someone leaving an explanation in their commit (for some weird edge case or context I’d have no way of gleaning because they’ve since left the company) is SO much more than the extra time I’ve put in to make sure the history has this extra info in it.

Re: Git rebase, what can go wrong

#116

Post by Izkata »

FeepingCreature wrote: post #87
sidlls wrote: post #54

Earlier quoted context omitted.

What is a "semantically delineated commit"? What is a "clean history"? Why are these two things important?

Not parent: there are technical commits, such as "fix review", "fix jenkins", "fix typo" etc. Those don't delineate a particular feature but a fix for a problem that arose from the workflow. This ends up with a history of "big feature commit that is wrong in three trivial ways" + "fix 1" + "fix 2" + "fix 3". Of those, "big feature commit" is the important one, but "fix 3" is the only working one. This is clearly sill…

They are. Or at least can be. Typos I probably agree with, but I've seen plenty of logic bugs introduced in those "fix" commits and keeping them separate from the big one is useful when figuring out what was supposed to happen.

Re: Git rebase, what can go wrong

#117

Post by jjeaff »

FeepingCreature wrote: post #90
AndrewDucker wrote: post #70

I find it fascinating that people talk about "Having a history of what people did" in such emotive terms - "Cluttering", "Polluting". What matters is that you end up with working systems. That a lot of change happened is just, well, what happened. It doesn't need to be prettied up and made to look like your development occurred in a clockwork march of cleanliness. It literally does not matter unless you spend a lot o…

> What matters is that you end up with working systems. That a lot of change happened is just, well, what happened. It doesn't need to be prettied up and made to look like your development occurred in a clockwork march of cleanliness. It literally does not matter unless you spend a lot of time doing git-bisect. And git blame. And git checkout to a past state. It "doesn't matter" only if ease of understanding your pro…

how often is "understanding your project history" something that actually comes up for you? In all my years of working with projects in git, I will occasionally look at my history to help me find a change that may have led to a bug, but it really only comes up for me once or twice a year and even then, it is rarely an extensive deep dive and never very far back in time.

Re: Git rebase, what can go wrong

#118

Post by [deleted] »

btilly wrote: post #103
debaserab2 wrote: post #78

Earlier quoted context omitted.

> I used to work at a company where someone (we never figured out who) Wouldn't this be trivially solvable by git bisecting your deploy branch?

No, because git bisect operates off of the information in the history. And thanks to the bad rebase, the history no longer existed in the branch.

[deleted]

Re: Git rebase, what can go wrong

#119

Post by joshribakoff »

ohwellhere wrote: post #26
jawns wrote: post #2

I like how Atlassian puts it: > The golden rule of rebasing > Once you understand what rebasing is, the most important thing to learn is when not to do it. The golden rule of git rebase is to never use it on public branches. https://www.atlassian.com/git/tutorials/merging-vs-rebasing#... For me, even though rebasing comes with some trappings, I still greatly prefer it to the alternative, which is to have merge commit…

The way I phrase and teach what I consider to be the important rule of git is: > Don't rewrite history on shared branches with proper communication. I don't teach "never", I don't teach that `main` is special, I don't teach that force pushing is forbidden, because I don't believe in those things. I highly prefer a rebase-heavy workflow. In addition to not "cluttering" the history, it's an invaluable tool to keep comm…

You can simply pass flags to “git log” to hide merge commits, without needing to rewrite history to “destroy” that information. While they are often noisy, sometimes they can be useful. I usually prefer to hide information rather than destroy it.

Re: Git rebase, what can go wrong

#120

Post by ecnahc515 »

ZeWaren wrote: post #101
AndrewDucker wrote: post #70

I find it fascinating that people talk about "Having a history of what people did" in such emotive terms - "Cluttering", "Polluting". What matters is that you end up with working systems. That a lot of change happened is just, well, what happened. It doesn't need to be prettied up and made to look like your development occurred in a clockwork march of cleanliness. It literally does not matter unless you spend a lot o…

I've accepted this a decade ago. I put my ego on the side, and now I don't care if my git history doesn't look like "beautiful" when looking at the commit graph. I've been working on dozens of projects since, and probably did thousands of commits. Some of the teams of those projects included dozens of developers working concurrently on the same codebases. We always merged the upstream branches into our development br…

Have you ever had to use git bisect? That's really where a 'clean' git history is important. Plenty of people never use git bisect, and that's fine too. That said it's a very useful tool when you do need it, and can drastically simplify finding when and where a regression was introduced.
Post reply on HN