Git rebase, what can go wrong • Hacker News Board

Re: Git rebase, what can go wrong

#261

Post by dahart » Mon, Nov 06, 2023, 9:27 PM UTC

nomel wrote: post #214

dahart wrote: post #162

Earlier quoted context omitted.

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

What about the context where one works with other people, while sharing code?

When working with published/shared branches with other people, the advice with git has always been that history is history and not to be changed after publishing, unless there is an emergency like a security incident.

Aside from that we need might need to clarify what the question is. With shared code & git, it’s nice to use a branch & merge workflow, and it’s nice to make incoming merges as clean / nice as you can do the resulting history is as smooth as it can be while capturing what happened at a reasonable granularity. These are today’s conventions though, and it’s really up to the team to decide how to balance shared work, and what people feel are the most important workflows and tools.

Re: Git rebase, what can go wrong

#262

Post by dkbrk » Mon, Nov 06, 2023, 9:28 PM UTC

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…

> the mess is the actual history.

This argument reminds me of a scene from Yes Prime Minister [0]:

> Humphrey: The minutes do not record everything that was said at a meeting do they?

> Bernard: Well of course not.

> Humphrey: And people change their minds during a meeting don't they?

> Bernard: Well, yes.

> Humphrey: The actual meeting is a mass of ingredients for you to choose from.

> Bernard: Oh, like cooking?

> Humphrey: No, not like cooking. Better not to use that word in connection with books or minutes. You choose, from a jumble of ill-digested ideas, a version which represents the Prime Minister's views, as he would, on reflection, have liked them to emerge.

> Bernard: But if it's not a true record...

> Humphrey: The purpose of minutes is not to record events it is to protect people. You do not take notes if the Prime Minister say something he did not mean to say, particularly if it contradicts something he has said publicly. You try to improve on what has been said, to put it in a better order. You are tactful.

> Bernard: But how do I justify that?

> Humphrey: You are his servant

> Bernard: Oh, yes.

> Humphrey: A minute is a note for the records and a statement of action if any that was agreed upon.

I think the analogy is pretty clear. A pull request does not record every single little change you made when writing it. You choose, from a jumble of ill-digested ideas, a version which better reflects your intent as you would, on reflection, have liked it to emerge. It doesn't matter that it's not a true record, since its purpose is not to record events but to communicate ideas. You try to improve on the commits as they have been written, to put it in a better order. You are tactful.

[0]: https://youtu.be/MF-Qnv2Srfs?si=U6xKNLrTAIn5h1Iz&t=118

Re: Git rebase, what can go wrong

#263

Post by rstuart4133 » Mon, Nov 06, 2023, 9:28 PM UTC

I'm someone who was programming long before CVS was a thing. To me this is akin to a discussion of "1st world problems". We got a remarkable amount of code written without version control, and we saved a lot of time on discussions these. (They seem depressingly common.) That said, I would not be without git now - but it's the cherry on top, not the cake. Perhaps it gives me a different perspective.

I'd rate the benefits of version control, in rough order of importance, as:

* It allows multiple programmers to work on one body of code. This has always been it's main use. Rebase screws with this because multiple authors updating a rebased branch creates a cluster. The simple fix is rebases to a branch are only allowed when you are the sole person working on it. (Atlassian is wrong. The branch can be public. It's multiple writers that creates the problem, other people reading and reviewing a public branch isn't.)

* A backup. I've lost more than enough work to know the importance of backups yet if I have to do it manually I still don't do it regularly enough. git==backup. Wonderful.

* Assist in reviews. Actually, I'm not sure how you would do reviews without it, as version control system both highlights the differences and serves as a communication medium. Rebases help here, as they let the author parcel up a body of work to make the reviewers job a lot easier.

* Make open source contributions auditable. To be fair I've never used this personally, but I use software that depends on it - like the kernel, so I rank it pretty highly. If becomes very difficult to anonymously introduce malicious changes when the version control system is tracking who made every modification. In an amazing coincidence, a branch is effectively a block chain which makes it hard to change. Rebases could muck this up of course if the "only personal branches may be rebased" rule isn't enforced - but it normally is.

* Bug hunting. Blame and bisect are the main tools. In my experience compared to the previous points this gets used very rarely, but bisect in particular can save a lot of time on those rare occasions. Before version control we did bisects using by restoring backups. Notably git blame still works perfectly if you follow the "only rebase branches you own" rule.

* Going by the discussion here, some people spend time on archaeological digs through source code repositories. It seems some of them prefer their digs to be dirty (aka rebase free) and others like it clean (rebased).

Interestingly, most of the noise here comes from people arguing about the last point. That strikes me as about important as the colour of the bike shed. The only other place rebase effects is reviews. Reviews are a problem everywhere I've worked. Everybody prefers to be doing something else, so making them as friction free as possible is a worthwhile goal. Rebasing does that (and so does unit tests).

Re: Git rebase, what can go wrong

#264

Post by watwut » Mon, Nov 06, 2023, 9:32 PM UTC

orblivion wrote: post #259

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…

This is such a strange thing to say. I'd be curious if you feel the same way about cleaning up your code, or cleaning up your room. I think you have an unfair advantage in this argument because it's difficult to defend such intangible benefits. We have to resort to making up logical explanations, or sounding unhinged or emotional as you suggest. But it's simply intangible. My instinct tells me that it's helpful and t…

> I'd be curious if you feel the same way about cleaning up your code, or cleaning up your room

Very genuinely: I do not care at all whether you clean your room starting from left and continuing to right. Or, starting from doors and continuing toward window. Or whether you clean it in a random order. I also do not care about whether you clean every Friday or whenever you feel like. That is the equivalent of git history. Because this excessive care about git history is just that - insisting that room is cleaned from left to right as if any other order was an issue.

The reason why it is hard to defend the tangible benefits of this or that git history strategy is that there are very little benefits.

Re: Git rebase, what can go wrong

#265

Post by jordigh » Mon, Nov 06, 2023, 9:32 PM UTC

Mercurial fixes pretty much all of these problems via changeset evolution: commits are marked as obsolete and the obsolescence marker says which commit replaces the obsolete commit. So you have a meta-graph of commits as they change. You can therefore undo, you can trace the history, and since obsolete commits aren't shared by default, they slowly fade away.

https://www.mercurial-scm.org/doc/evolution/

It's a good idea that's been attempted to be ported into a git

https://lwn.net/Articles/914041/

Re: Git rebase, what can go wrong

#266

Post by unregistereddev » Mon, Nov 06, 2023, 9:33 PM UTC

brainzap wrote: post #260

Please write the spec for next generation version control. I feel like Git is great but we could have one which is easier to use and has built in concepts like Pull Prequest or deployed state.

This is a short-sighted view in my opinion. Similar views often lead to reimplementing old bugs, rediscovering hidden requirements, and ultimately re-implementing most of the things that made the old system complicated.

We've seen this in npm. Npm was supposed to be simpler than maven - then it slowly rediscovered the reasons we need package signing, support for circular dependencies, and all the other messy things that go into package management.

While I don't have numbers, it seems like a huge percentage of the "this problem should be simple, let's build a new app" projects either fail or recreate the same gnarly problems that led the existing projects to be complicated.

Re: Git rebase, what can go wrong

#267

Post by Nullabillity » Mon, Nov 06, 2023, 9:34 PM UTC

pjc50 wrote: post #241

richbell wrote: post #6

Earlier quoted context omitted.

> I still greatly prefer it to the alternative, which is to have merge commits cluttering up the commit history. GitHub recently added a feature that prompts people to update their branches via merge. It's frustrating because every PR now had dozens of merge commits polluting the history.

Some people have pull set to merge, which is a "I don't know how you can live like that" feature.

Some of us like our history tracking tools to.. track history.

Re: Git rebase, what can go wrong

#268

Post by Nullabillity » Mon, Nov 06, 2023, 9:36 PM UTC

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…

Every time I try to blame or bisect and just end up stuck on an irrelevant megacommit I curse the Git maintainers that don't have the backbone to just get rid of --squash.

Every time I try to review a PR and the bookmark resets because they decided to force push I curse the Git maintainers that don't have the backbone to just get rid of rebase.

Re: Git rebase, what can go wrong

#269

Post by Terr_ » Mon, Nov 06, 2023, 9:40 PM UTC

bonzini wrote: post #206

toast0 wrote: post #201

Earlier quoted context omitted.

> * enables use of git bisect to locate bugs This is really only viable if each intermediate commit on a development branch is intended to be bug free. If that's the standard you and your team work with, that's fine, but it's not usually my standard; in a development branch, I may commit things that don't even compile, let alone work, if it's a good point to commit.

The point of the parent comment is exactly that you should clean up the history before merging to a public branch, so that you can use bisect, even if so far you had wip wip doh wip as the commit messages. The way to get there is to have a mix of proper and wip commits.

> even if so far you had wip wip doh wip as the commit messages

Aside, `git commit --fixup HEAD` is often better than `git commit -m "oops, one more thing"`, since it means you can easily `git rebase -i --autosquash`.

Re: Git rebase, what can go wrong

#270

Post by orblivion » Mon, Nov 06, 2023, 9:41 PM UTC

watwut wrote: post #264

orblivion wrote: post #259

Earlier quoted context omitted.

This is such a strange thing to say. I'd be curious if you feel the same way about cleaning up your code, or cleaning up your room. I think you have an unfair advantage in this argument because it's difficult to defend such intangible benefits. We have to resort to making up logical explanations, or sounding unhinged or emotional as you suggest. But it's simply intangible. My instinct tells me that it's helpful and t…

> I'd be curious if you feel the same way about cleaning up your code, or cleaning up your room Very genuinely: I do not care at all whether you clean your room starting from left and continuing to right. Or, starting from doors and continuing toward window. Or whether you clean it in a random order. I also do not care about whether you clean every Friday or whenever you feel like. That is the equivalent of git histo…

> I do not care at all whether you clean your room starting from left and continuing to right

But you didn't say that you don't want it clean. It sounds like you're talking about how it's organized rather than whether it's organized.

> The reason why it is hard to defend

I'm talking about intangible benefits and no that's not the reason. Intangible benefits are inherently difficult to defend in words. Citing this as evidence of anything is akin to a debater's trick.