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

381–390 of 404 posts

Re: Git rebase, what can go wrong

#381

Post by seba_dos1 »

naasking wrote: post #368
seba_dos1 wrote: post #335

Earlier quoted context omitted.

The principal reason for VCS has nothing to do with "history" at all. It has all to do with "versions". What exactly the word "version" means depends on context. If you put your essay under git, you probably want to track how it was changing with time. When you hack on some codebase and throw things at wall to see what sticks, you want to be able to go back to the previous attempt should your next one turn out to be…

> What exactly the word "version" means depends on context. If you put your essay under git, you probably want to track how it was changing with time. In other words, the history. > It's not a useful information and it never becomes a "version" of a shared project, because why would it? Because the real world doesn't match your ideal of how software development works. You need the full history because sometimes innoc…

> In other words, the history.

Yes, that was my point. Have you read it?

> You need the full history because sometimes innocuous looking "simple fixes" are neither innocuous nor fixes, and because obscuring the history makes auditing and merges more difficult, not less.

Obscuring logically split and curated commits makes auditing and merges more difficult. Obscuring pointless edit history of the developer makes them easier.

> So blame and bisect are poorly written therefore you should hack around them using a convoluted process that obscures the true history and raises the risk of requiring people to redo weeks worth of work

blame and bisect are powerful tools that can work sensibly in various repository topologies. However, if you're either intentionally putting garbage into your topology, or not utilizing it well because of ill-defined idea of "clean history", you're simply doing yourself a disservice and induce unnecessary mental load.

> by overwriting branch histories on shared repos. Great idea.

Who said anything about overwriting branch histories on shared repos? It has its uses too (it can be useful in some cases when you're a downstream working on a project maintained upstream, for example), but it's not what most projects will ever want to do. That's not what rebase is there for.

Re: Git rebase, what can go wrong

#382

Post by seba_dos1 »

naasking wrote: post #319
rhinoceraptor wrote: post #289

Earlier quoted context omitted.

There is obviously a point where you do not want full history. For example, it would absurd to use your editor's undo history tree with keystroke level granularity as your VCS, because in most of those points in history, the code won't even compile because you were in the middle of typing a word. If your goal is to be able to revert the codebase to a previous version, then you want your history to a series of well pr…

Clearly that's the reason you make a commit to begin with. Erasing that commit history is just silly.

There are a lot of reasons to make a commit other than wanting to make an atomic change meant to be integrated onto shared repository. Ignoring those is just silly.

Re: Git rebase, what can go wrong

#383

Post by seba_dos1 »

WorldMaker wrote: post #236
nemetroid wrote: post #27

Earlier quoted context omitted.

It matters because when I: * use filtering commands like "git log -S" * press the "annotate" button in my IDE and can see which commit introduced each line * run "git bisect" * use "tig" to drill down through the history of a file (shortcut "," is "move to commit preceding current line's blame commit") ...every step of the way, I get a meaningful description of why a change was made and what other diffs were necessar…

* `git log --first-parent -S` * `git blame --first-parent` * `git bisect --first-parent` * At least one "tig-like" with a --first-parent first UI: https://github.com/kalkin/git-log-viewer

--first-parent is incredibly useful, but having both merge commits and properly curated atomic commits under them is even more useful.

Re: Git rebase, what can go wrong

#384

Post by fulafel »

unlikelytomato wrote: post #366
fulafel wrote: post #352

Earlier quoted context omitted.

It's a log of what happened in dev and supports reconstructing history to understand why something worked or didn't in retrospect. "It work when we tried it" "oh this dependency was updated in this merge commit that could have changed the behaviour"

I am not sure how this is unique to a merge commit. The commit with the dependency change still exists in the main branch. The commit should never have gotten into main branch of it failed tests. If I take a positive action to rebase, I am accepting my fate from master anyway. If I merge into my working branch instead of rebase, that historical context issue only useful for that moment in time of reconstructing histo…

It's not unique to a merge commit of course, but a point in favour of preserving history.

Re: Git rebase, what can go wrong

#385

Post by seba_dos1 »

Chris_Newton wrote: post #367
watwut wrote: post #362

Earlier quoted context omitted.

> there’s also no point in writing unit tests or defining static types or having code reviews Not true. I do not do those to have nice clean process. I do unit tests, because without them the code is unstable and it is hard to fix bugs without causing unrelated ones. If the code is super simple and unlikely to break, I don't do test. I like to use static types, because I am much faster when writing them. The code is…

But, in all of those cases, things are done because they beneficial impact in final code and speed of delivery. Beautiful git history does not have such tangible measurable benefit. I respectfully disagree. In my experience, a tidy history directly benefits both efficiency and outcomes of code reviews, speeds up investigations of both bug reports and sometimes general background before starting new development, makes…

Fully agreed. Seems to me that most people who don't care about curating their commits (and either leave a mess or squash everything at merge regardless of context) simply don't work on projects that are either complex, distributed or long-living enough, so they can easily afford such carelessness.

Re: Git rebase, what can go wrong

#386

Post by krferriter »

watwut wrote: post #225
bonzini wrote: post #206

Earlier quoted context omitted.

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.

Frankly, people lately spend more time managing commit history then using it. Like, commit history is useful once in a year little bit, maybe, but we spend absurd amount of time trying to make it look nice.

Yeah I just don't care really. I have noisy dev branches, force pushing rebases from an upstream branch, and usually just squash merge and throw the history away when merging back to master. I've never come across a situation where I needed a preserved, fine-grained commit history for every dev branch after they've already been put in working order and merged to master. I guess I just don't use commit histories very much after the fact, like months later trying to find what original commit changeset a line of code was changed in. It's never mattered.

Re: Git rebase, what can go wrong

#387

Post by krferriter »

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.

I have never used git bisect, which is maybe why I'm wondering why people care so much about curating and cleaning up git history.

Re: Git rebase, what can go wrong

#388

Post by gray_-_wolf »

lesuorac wrote: post #98
gray_-_wolf wrote: post #81

Earlier quoted context omitted.

> * "fixing whitespace" * "incorporate review comments" * "fix broken test" * "fix other broken test" Things like this should not be standalone commits though, they should be incorporated into the previous branch by amending the original work. It takes some effort to have a useful git history, it does not just happen on its own.

Sounds like six vs half-dozen. Why does it matter if somebody amends vs squashes?

It does not matter if you have one commit. If your change is split into few commits for increased readability, in that case it does matter.

Do you really believe that if, for example, this change to btrfs filesystem https://lore.kernel.org/linux-btrfs/cover.1699470345.git.jos... would be squashed, nothing of value would be lost?

Re: Git rebase, what can go wrong

#389

Post by PhilippGille »

sam_bristow wrote: post #343
thebigspacefuck wrote: post #329

Earlier quoted context omitted.

It’s annoying when someone force pushes to a branch that you just reviewed, but you can no longer see the history so you have to scan through the whole PR you already reviewed looking for the change. Please just commit the fix, let me see it, then squash it.

Unfortunately I haven't seen a git forge that will let you do "autosquash on merge" so I could just push up fixup commits as part of an merge request.

GitHub: https://docs.github.com/en/repositories/configuring-branches...

Re: Git rebase, what can go wrong

#390

Post by mixmastamyk »

Izkata wrote: post #380
mixmastamyk wrote: post #378

Earlier quoted context omitted.

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.

Not if you want them read by non-developers.
Post reply on HN