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

221–230 of 404 posts

Re: Git rebase, what can go wrong

#221

Post by Dylan16807 »

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…

> I don’t want to have to think about my VCS at all beyond the commit message.

Fine as an opinion.

> For all of Git’s popularity, I’ve never seen benefits that justify the absurd amount of work and knowledge it takes to perform simple actions. It’s the VCS equivalent of Scheme or emacs.

This is just wrong. When people talk about this, it's not about git at all.

You write some code, and you make it into commits. Part of that is choosing if/how to organize it with multiple commits, and how much effort you want to put into that. This is fundamental to using a VCS, any VCS.

Or by analogy, if a lot of emacs users complain about your spelling, that's not because emacs is overly demanding.

Re: Git rebase, what can go wrong

#222

Post by WorldMaker »

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

Earlier quoted context omitted.

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.

`--first-parent` also today works for blame and bisect.

Re: Git rebase, what can go wrong

#223

Post by Izkata »

nicolaslem wrote: post #22
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”?).

Sometimes when working on an old code base built by developers that came and went, one needs to perform what I call "code archeology": going back in time to understand why a feature was implemented the way it was. Whether this is feasible at all depends largely on the care developers put in structuring their commits.

This has become a large chunk of my job over the past few years, as part of fixing/upgrading systems no one has touched in a decade, and none of those original people are still here. There are some weird things in there I've only been able to figure out because all the svn history still exists.

Re: Git rebase, what can go wrong

#224

Post by latexr »

qhwudbebd wrote: post #84
ajkjk wrote: post #8

I love rebase (I'm a tip-of-master-only person, no merges ever, squash all your commits with `rebase -i` before pushing and write one good commit message for the group). But there's one really, really irritating thing about them: You should not be able to use `--amend` during a rebase. For me editing all my changes onto the commit I'm working on with `git commit -a --amend` (or as I've aliased it, `gcaa`) is automati…

Random thought: given you already have the gcaa alias, perhaps you could include a check that .git/REBASE_HEAD doesn't exist in that? Probably easiest as a little shell function like gcca() { local GIT_DIR if ! GIT_DIR=$(git rev-parse --git-dir); then return 1 elif test -f "$GIT_DIR/REBASE_HEAD"; then printf 'Rebase in progress: commit --amend is disabled\n' >&2 return 1 fi git commit -a --amend "$@" } rather than an…

You can shorten `>/dev/null 2>&1` to `&>/dev/null`.

Re: Git rebase, what can go wrong

#225

Post by watwut »

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.

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.

Re: Git rebase, what can go wrong

#226

Post by WorldMaker »

Lio wrote: post #215
erik_seaberg wrote: post #207

Earlier quoted context omitted.

We shouldn’t tamper with code we don’t actually need to fix, it’s not a good use of time and it makes history less useful. Just because it doesn’t look like I wrote it doesn’t make it wrong.

I’m thinking of situations where the surrounding structure of the code has been changed to correct a problem. That’s done by an automated tool. Correction of indentation is just a byproduct. I don’t consider that “tampering”.

You can deal with that through tooling.

In a lot of my work I call those types of automated tool commits "wrench" commits personally and even have a simple shell script to help automate committing them. In my case I prefix the command line with a wrench emoji. At that point it's very obvious in git blame that if a line starts with a wrench it was last touched by an automated tool of some sort.

You can also very easily at that point grep your git log for wrenches to dump commit hashes into a git-ignore-revs file and automate that part too so that those commits don't even show up in git blame at all.

Re: Git rebase, what can go wrong

#229

Post by Groxx »

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.

>how often is "understanding your project history" something that actually comes up for you?

Frequently, for any long and complex project. Large amounts were written by people no longer working on it, and the history of how things came to be can help fill in documentation gaps and make intent clear.

By "frequently" I mean something like "I check history for about 2/3rds of bug fixes, and 1/4 of adding features" to understand the surroundings better, when writing or reviewing. Anything that makes that better saves me hours per week.

It catches and prevents more than enough subtle issues to be worth the effort.

Re: Git rebase, what can go wrong

#230

Post by WorldMaker »

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 `git bisect --first-parent` and only bisect top-level merge commits. In most cases that gets you to the ballpark of "PR that introduced the bug" no matter how dirty the commit history inside that PR had been and if you can git bisect further in that branch. In my experience that is most of what you want anyway, "PR that introduced the bug" gives more than enough context.
Post reply on HN