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

371–380 of 404 posts

Re: Git rebase, what can go wrong

#371

Post by dahart »

tomjakubowski wrote: post #365
Nullabillity wrote: post #284

Earlier quoted context omitted.

> Agreed. But the rewrite occurs in your private branch. It's history is just as private as the undo list in your editor. No one cares about what's going on in your editors undo list. And by the same logic they shouldn't care about commits in a private branch. The rebase becomes part of the public branch eventually, inflicting your lies on everyone else. > If you avoid rebase, then you end up "rebasing" without rebas…

Do you consider it lying when a commit doesn't include all changes in the working tree at the time it was committed? How about when a committer adds a file to .gitignore?

My advice is don’t engage with the ‘rebase is a lie’ argument. It is a textbook bad-faith argument, since it deliberately and explicitly ignores the stated intention behind rebase. It’s a talking point that people like to parrot without fully understanding what the author of the argument (Fossil developers) meant, and without fully understanding the implications of the argument. FWIW, HN mods in the past have previously confirmed that repeating this hyperbolic claim goes against HN guidelines.

Fun note though, I argued this directly with Dr Hipp (principal author of SQLite and of Fossil, inventor of the ‘git rebase is a lie’ argument) and during that discussion, he agreed to soften the language on the Fossil pages. They are still hyperbolic, using the word ‘dishonest’, and continue to distort the reasons and usage behind rebase, but he did remove some instances of the word ‘lie’ and ‘lying’, which is progress.

It’s a bit of a shame that they haven’t found the strength to frame Fossil in a positive light without trash-talking the competition. There is a good-faith argument for Fossil vs git, but they’re choosing not to use it.

Re: Git rebase, what can go wrong

#372

Post by haradion »

sethammons wrote: post #325
alkonaut wrote: post #143

If I were to write a blog post on this I’d make a few do’s and don’ts (why make a blog post when you can blog in HN comments?) Don’t merge the base branch into a feature branch. Rebase to “update”. Do use rerere and the curse of fixing the same conflict over and over is (almost) gone. Don’t rebase (or force push for other reasons) a shared branch. Rule of thumb here is you can probably rewrite history if you work wit…

> Don’t force push after review, until the review is complete. This keeps the history of the review process but you can later merge the fixups with the commits they logically belong in right before merging. I've had to talk to soooo many developers about this. I want to see what changed since my last review, not restart my review.

`git range-diff` can be handy for the reviewer when trying to "recover from" a mid-review force-push.

Re: Git rebase, what can go wrong

#373

Post by leptons »

lolinder wrote: post #370
leptons wrote: post #351

Earlier quoted context omitted.

>That leaves you prone to losing work if you have a false start that you need to back out of. Hasn't happened to me in over 20 years of using version control. I always keep moving forward, there's really never been a need to go back to a previous commit that hitting crtl-Z wouldn't accomplish just the same. If I wanted to try a new direction I'd just clone the repo again and do the work there. Littering the git histo…

> Littering the git history with dozens of superfluous commits just seems pointless. This is where the final rebase comes in—you should be combining all the small commits into one. > Having to stop and think about writing a commit comment is also just a waste of time Most of my commits when I'm working like this are named "draft". The names don't matter when you're going to redo the history later. > I always keep mov…

>This is where the final rebase comes in—you should be combining all the small commits into one.

Sorry, but I'm a software engineer, not a git engineer, and the less I have to do with git, the better. KISS applies to git, too. A simple thing like not creating a commit for every stupid thing keeps the history clean, doesn't bog down the developer by requiring to think about writing a commit message every 2 minutes, and keeps git simple.

>Most of my commits when I'm working like this are named "draft". The names don't matter when you're going to redo the history later.

But then what value have you added by naming everything "draft" and creating a commit? There is no value in doing this.

>You've never started down one path for solving a subproblem only to realize 30 minutes in that it's not going to work?

Sure I have, but I don't need to enter it into the git logs. I'll either start over in a clone of the repo if I want to save the bad work for whatever reason (which is very unlikely), or I'll just stash the work, or whatever. The thing I don't need to do is commit the bad work.

Re: Git rebase, what can go wrong

#374

Post by ajkjk »

sethammons wrote: post #324
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…

this exact problem led us to block all --force pushes.

Yeah, that's a standard feature in large organizations afaik.

Re: Git rebase, what can go wrong

#375

Post by bafe »

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…

Agree, plus let's avoid having the CI pipeline creating commits in the remote repo. I like CI/CD to be stateless with regards to the files in the repository. I tried to plea for this today with my colleagues with very mixed results

Re: Git rebase, what can go wrong

#376

Post by watwut »

deredede wrote: post #356
mixmastamyk wrote: post #345

Earlier quoted context omitted.

Most recent. Interfaces change over time. Everything you need is in the most recent copy. Showing an old one invites errors for no benefit.

A commit is not a method, it is a change set potentially affecting many files. Pointing people to the commit used to implement feature A lets them understand the whole story of which components need to change (and how) to implement similar feature B in a way that pointing them to a single method or file doesn't necessarily can. You would then typically supplement reading the commit with reading the current version of…

The idea is for junior to learn from massive commit that affected many files?

Re: Git rebase, what can go wrong

#377

Post by mixmastamyk »

watwut wrote: post #376
deredede wrote: post #356

Earlier quoted context omitted.

A commit is not a method, it is a change set potentially affecting many files. Pointing people to the commit used to implement feature A lets them understand the whole story of which components need to change (and how) to implement similar feature B in a way that pointing them to a single method or file doesn't necessarily can. You would then typically supplement reading the commit with reading the current version of…

The idea is for junior to learn from massive commit that affected many files?

This reply is overstating a bit, but it does sound like a lot of work simply to avoid saying, "here look at these methods in this file" and the unstated, and trace the imports yourself.

Not to mention just finding the right commit months later sounds like more work than that already.

Personally, even if I were to make the history absolutely perfect, I never get the code right (interfaces etc), the first time. It might be hours or days before I'm 98% happy with the final implementation. Sometimes big refactor opportunities come to me months later, e.g. where I move code needed multiple times into a more central mixin location.

Re: Git rebase, what can go wrong

#378

Post by mixmastamyk »

Terr_ wrote: post #354
mixmastamyk wrote: post #341

Earlier quoted context omitted.

When/how to comment is an art in itself, in no conflict to what I wrote. Either a short quip, doc string, or link to the full story is an accessible combo. Nothing is the correct choice for unsurprising code.

While it's often said that comments should capture the "why" of code, I don't usually think that ought to extend to "cuz ticket#" except when that ticket number is an significant bug/limitation that explains a nasty hack. Noting each feature ticket that ever affected a line--or even just at the function level--is sort of like maintaining a few thousand incomplete micro-changelogs. Doing it "acceptably well" takes muc…

No, it's not difficult (cut/paste), nor a burden for reading in docstrings or even comments. The point is a short link that tells a long story, which should be accessible to non-developers.

Re: Git rebase, what can go wrong

#379

Post by mixmastamyk »

Chris_Newton wrote: post #360
mixmastamyk wrote: post #347

Earlier quoted context omitted.

One of these things is not like the other. (Journey vs. final destination.) As an industry we get paid primarily for 1) working software and 2) communicating with stakeholders. Tidy yet inaccessible (to non-dev) construction stories are not on that path. I would argue unit tests et al are, to ensure #1. No stakeholders? Put why into a readme, where it can be seen at a glance. Comments can reference docs. Complexity m…

Sorry again, but I’m still not seeing the distinction I think you’re trying to make here. I see version history as an asset, just like the code itself, tests, developer documentation, the bug tracker database… None of these things are directly visible to end users under normal circumstances, but they are useful sources of information and organisation and collaboration that help developers to create the software that…

It's not a black and white distinction, I agree.

Also, I said/meant stakeholders not end-users. Ours definitely do write bugs, look at docs and generate db reports etc.

The main distinction is that things on that list have a high cost-to-benefit ratio to goals 1 & 2, where history maintenance does not. The cost is high and utilization isn't. Additionally it can't be used to communicate with anyone but developers.

Re: Git rebase, what can go wrong

#380

Post by Izkata »

mixmastamyk wrote: post #378
Terr_ wrote: post #354

Earlier quoted context omitted.

While it's often said that comments should capture the "why" of code, I don't usually think that ought to extend to "cuz ticket#" except when that ticket number is an significant bug/limitation that explains a nasty hack. Noting each feature ticket that ever affected a line--or even just at the function level--is sort of like maintaining a few thousand incomplete micro-changelogs. Doing it "acceptably well" takes muc…

No, it's not difficult (cut/paste), nor a burden for reading in docstrings or even comments. The point is a short link that tells a long story, which should be accessible to non-developers.

And the commit message is an amazing place to put that.
Post reply on HN