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

161–170 of 404 posts

Re: Git rebase, what can go wrong

#161

Post by ajkjk »

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…

IMO the relevant 'true history' is at the plane of 'things relevant to other developers'. As far as anyone is concerned, my local work history is that I atomically wrote all my code in a single instant. Commits are that unit of atomicity.

But I have never seen a commit disappear while rebasing, ever. That workflow is busted somehow. They were doing it wrong.

Re: Git rebase, what can go wrong

#162

Post by dahart »

nomel wrote: post #153
ruds wrote: post #111

Earlier quoted context omitted.

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.

How is this possible, while sharing code? Doesn't this require that pushed code is perfect? What about everyone else working on the same code? Do they wait until you've reached perfection? Or, do you squash the branch once it's complete, with the assumption that there's no other development on/from that temporary branch (I envy you if so)? (I ask these questions fully assuming I'm doing it wrong.)

> Doesn't this require that pushed code is perfect?

We aren’t talking about pushed code. We are talking about cleaning up the local commit history before pushing it into a shared branch.

Re: Git rebase, what can go wrong

#163

Post by mablopoule »

diek wrote: post #100
lelandfe wrote: post #79

Earlier quoted context omitted.

Those commits would be the bathwater one casts out alongside the useful commits in using squash merges.

If the useful commits are the "baby" in your bathwater analogy, all the useful information in those commits is in the squashed commit. This assumes a branch being merged in represents one logical change (a feature/bugfix/etc) that is "right sized" to be represented by one commit.

Yes, but now it's mixed with the bathwater, and now morph into another metaphor as it become the needle in the haystack.

It's okay to have 'low information' commits one can easily ignore in your history, as long as the 'high information' ones stay readable and coherent.

Re: Git rebase, what can go wrong

#164

Post by ajkjk »

haakonhr wrote: post #15
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.

Is it free though? I'm a fan of rebase myself, but understand the point made above. For me, the biggest pro of a clean history is when doing `git blame`. If the history is clean and the commits are good, it might solve my issue. On the other hand, if the commit in question is a huge mess of unrelated things it doesn't help me at all. I also find it way easier to review a PR with a clean, well-described history.

Well I also object to multiple unrelated changes in the same commit. Those should be separate commits, and separate code reviews for that matter.

Re: Git rebase, what can go wrong

#165

Post by nerdponx »

gray_-_wolf wrote: post #76
nerdponx wrote: post #16

Earlier quoted context omitted.

This is the big one for me. destroying Commit information just to keep the graph tidy is a bad idea in my opinion. It would be better if Git provided better tools for filtering the log, e.g. providing some mechanism to elide commits from parents of any merge commit other than the 1st.

You mean like for example `git log --first-parent`?

TIL, thank you! Now I know for a fact that squash-mergers have no excuse and can brandish the man page at them.

Re: Git rebase, what can go wrong

#166

Post by sodapopcan »

recursive wrote: post #5
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…

Squash merges cut down the noise considerably.

No one is mentioning:

    $ git log --merges
Now you can see your features in a nice history and also have added benefit of seeing intermediary commits. Pro tip: merge commits aren't required to use the canned "Merge branch into..." message, you can give it any message you want, such as "feat: ..." or whatever your convention is.

I hate that branch squashing has become something of a defacto. I actually do rewrite my history and often add context to my commits. `git blame` can be an incredibly useful tool to get context about a given small change. Getting a massive diff for a whole feature is much less so, especially since you can just look at the diff of the merge commit.

Re: Git rebase, what can go wrong

#167

Post by tomjakubowski »

jjeaff wrote: post #117
FeepingCreature wrote: post #90

Earlier quoted context omitted.

> 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.

I read git commits in either the repo I am working on or a dependency repo almost every day

Re: Git rebase, what can go wrong

#168

Post by ufo »

bogeholm wrote: post #108
dkarl wrote: post #92

Earlier quoted context omitted.

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 ser it the other way around - why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later. I prefer one commit to main per feature, a long with a good description on the GitHub PR. Sometimes I’ll branch out from a feature branch for the occasional and infamous ‘get CI working’ round of 10 one-line commits though, to not make it too muddy.

Precisely, you want to keep it about one commit per feature. I think the parent comment was worried about monster merges that squash many features together.

Re: Git rebase, what can go wrong

#169

Post by diek »

mablopoule wrote: post #148
diek wrote: post #56

Earlier quoted context omitted.

> I die a little bit each time I try to understand what changes were related to a line when tracking down a bug A change/feature/bug is a branch, which is squashed into a commit on your main branch, right? So your main branch should be a linear history of changes, one change per commit. How does that impact the ability to git blame?

Because now instead of having a line changed within a granular level of changes, it's lost with the other changes from the same feature branch, which is a more macro level. So if a change in config is needed for the feature, the part when this config change actually need to be handled, or would impact the data-flow is harder to evaluate now that you mix it with template changes, style changes, new interactions needed…

> EDIT: On top of that, there's usually a bit of 'related' work you need for a task, by example when you find an edge case related to your feature, and now you also needed to fix a bug, or you did a bit of refactoring on a related service, or needed to change the data on a badly formatted JSON file.

I agree that's related work, but I'd argue that work doesn't belong in that branch. If you find a bug in the process of implementing a feature, create a bugfix branch that is merged separately. If you need to refactor a service, that's also a separate branch/PR.

That's actually the most common pushback I get from people when I talk about squashing. They say "but then a bunch of unrelated changes will be lumped together in the same commit", to which I respond, "why are a bunch of unrelated changes in the same branch/PR?"

Re: Git rebase, what can go wrong

#170

Post by Lio »

> fixing the same conflict repeatedly is annoying

This is usually caused by merging an upstream branch (e.g. develop) into your feature branch and then later trying rebase it.

Effectively the commits you've merged in from develop undo the changes you've made in your feature branch. You fix them but the foreign commits undo the changes again.

The solution is actually pretty easy. Use git rebase --interactive to remove any commits from the rebase that aren't directly part of the feature work.

You may still have an odd merge conflict to fix but you'll only have to do it the once and everything should go smoothly.

I would also recommend never using the same commit message twice. When you have a list of 10 commits all called "Wip" it's hard to tell which are obviously duplicates that can be deleted.

Post reply on HN