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

131–140 of 404 posts

Re: Git rebase, what can go wrong

#131

Post by joshribakoff »

ecnahc515 wrote: post #120
ZeWaren wrote: post #101

Earlier quoted context omitted.

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.

You can bisect across the more coarse merge commits, without “destroying” history and losing the ability to bisect across more granular constituent commits. Bisect is more robust when more information is preserved.

Re: Git rebase, what can go wrong

#132

Post by smw »

adhesive_wombat wrote: post #49
spankalee wrote: post #10

Earlier quoted context omitted.

A PR with merges is fine by me, it lets me see how the PR has evolved. What I want is for GitHub to track changes between sets of commits in a PR so that you can do most of the review with merges and "address review comments" commits, and then rebase into well organized, logical commits and review that those have the same diff as the messy history after a force push.

At least Gitlab does that when you push a new commit (force or not) to the branch: it'll show a list of value of the branch head commit and you can diff between them.

So does Github, but it breaks if you fix via rebase and push -f. Gerrit and some other competitors manage this better.

Re: Git rebase, what can go wrong

#133

Post by rhinoceraptor »

brunooliv wrote: post #53

Haven't read the article yet. Whenever I'm working on a feature branch, I always tend to "merge master into the feature branch". The effect of this obviously being that I want to have the latest changes incorporated into my work to avoid conflicts and/or to proceed with my own feature work. This has always worked well for me and never failed me. If I understand what rebase does correctly, it just adds all my commits…

This is a simple example with only two feature branches, and it's already a bit hard to follow. Imagine it with even twelve which is not even that many branches:

    *      Merge Branch 'B' into 'main'
    |\
    * \    Merge Branch 'A' into 'main'
    |\ \
    | | |
    | | *  B Commit 2
    | | *  Merge remote-tracking branch 'upstream/main'
    | * |  A commit 2
    | * |  Merge remote-tracking branch 'upstream/main'
    | | *  B commit 1
    | |/
    | *    A commit 1
    |/
    *
Compared to a commit graph where feature branches are rebased to replay their commits against the tip of main before merging:

    * Merge branch 'B' into 'main'
    |\
    | * B commit 2
    | * B commit 1
    |/
    * Merge branch 'A' into 'main'
    |\
    | * A commit 2
    | * A commit 1
    |/
    *

Re: Git rebase, what can go wrong

#134

Post by duped »

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…

The point of a clean git history is not to have a clean git history. The point is to make it possible to debug later, via bisect, or show, or even just a diff. The point is to make the workspace clean for the next guy.

Instead of letting it go, maybe we should have more discipline and organization in our lives and not less.

Re: Git rebase, what can go wrong

#135

Post by duped »

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.

Do you work with other people or on large codebases at all? It comes up pretty much weekly for me.

Re: Git rebase, what can go wrong

#136

Post by dkarl »

jimbob45 wrote: post #112
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 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 t…

It really pays the effort back, though, when you can figure out why something was done, beyond knowing the feature it was related to, which is all you get with a squash merge.

Re: Git rebase, what can go wrong

#137

Post by lifeisstillgood »

Do I have the wrong mental model of rebase?

You want to "pretend" you all took turns at making the code better, like Alice goes first then everyone downs tools while Alice makes her chnages and then Bob picks up Alices work and does his changes, then Charlie starts

The difference is that Bob can start while Alice is working and all he needs to do is right before checking his stuff in, he grabs her fixes from master, and then applies his fixes on top of hers as if he had started after she had finished. Sometimes they both worked on the same code and he needs to figure out what's safe but hey that happens any which way.

As long as you ensure fast-forward merging onto master only it's kind of simple.

Annoying. but simples.

Re: Git rebase, what can go wrong

#138

Post by dewey »

sdfghswe wrote: post #130
dewey wrote: post #44

Earlier quoted context omitted.

Do people not collaborate on feature branches?

Don't rebase ESPECIALLY stuff that people are collaborating on.

Well aware of that, but in my experience I sometimes collaborate on feature branches with 1-2 people and we just communicate when there's a rebase happening (For example if there was a bigger change in main and we want to align our feature branch on it). I don't think that's very uncommon.

Re: Git rebase, what can go wrong

#139

Post by Izkata »

recursive wrote: post #31
paulddraper wrote: post #17

Earlier quoted context omitted.

Squash merges are rebases.

Just when I thought I was starting to understand git...

Rebase essentially means "create new commits out of old commits", the original use being to "move" a set of commits from one branch to another (think of the name as meaning, to change the base these commits started from).

There's a few special cases that have their own names, a common one is when you amend a commit - to do that manually you'd make a new commit, then use interactive rebase to squash the two commits together into a new one (or, use the "fixup" command available in that tool, which is a squash that automatically picks the first commit message instead of asking for a new one).

Squash merges will squash a whole branch into a single commit, rebasing it onto the target in the process, and then fast-forward the target to the new commit. It's a tightly controlled use of rebase, and can be thought of a bit like how "for", "foreach", and "while" loops are a tightly controlled use of "goto", an abstraction built on top of a far more flexible tool.

Re: Git rebase, what can go wrong

#140

Post by bregma »

davedx wrote: post #9

I’ve never understood the tradeoff of rebasing, squashing or otherwise “keeping a clean history”. It always seemed like tons of sometimes highly error prone work (sometimes you can wipe out a colleague’s work with it! Wtf!), for almost no gain (why does it matter that the git history is “clean”?).

It makes your git graph instagrammable.
Post reply on HN