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

241–250 of 404 posts

Re: Git rebase, what can go wrong

#241

Post by pjc50 »

richbell wrote: post #6
jawns wrote: post #2

I like how Atlassian puts it: > The golden rule of rebasing > Once you understand what rebasing is, the most important thing to learn is when not to do it. The golden rule of git rebase is to never use it on public branches. https://www.atlassian.com/git/tutorials/merging-vs-rebasing#... For me, even though rebasing comes with some trappings, I still greatly prefer it to the alternative, which is to have merge commit…

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

Re: Git rebase, what can go wrong

#242

Post by mablopoule »

hhjinks wrote: post #233
erik_seaberg wrote: post #203

Earlier quoted context omitted.

This. It bugs me that people permanently throw away details of changes rather than show just the log of merge commits.

Why would I want to keep the details? Umpteen "tmp", "fix" and "fixed typo" provide negative value. When I check the blame of a line, I need to see the context of the change, meaning a description of all the work that was done as part of that change, and perhaps a ticket number. Anything else is noise that actively detracts from the value of the log. It's like 4K porn. It's less appealing when you see everything .

No yeah, absolutely do squash those commits, they are actually polluting the git history.

The issue for me is when commit who are about adding a new value in the env file become mixed with template and responsive handling, mixed potentially with a bug fix.

Re: Git rebase, what can go wrong

#243

Post by qhwudbebd »

latexr wrote: post #224
qhwudbebd wrote: post #84

Earlier quoted context omitted.

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

Unfortunately that's bash-specific I think: the POSIX shell spec still hasn't picked it up. (Though strictly speaking, my 'local' is out of spec too.)

Re: Git rebase, what can go wrong

#244

Post by folmar »

bogeholm wrote: post #108
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 ser it the other way around - why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later. I prefer one commit to main per feature, a long with a good description on the GitHub PR. Sometimes I’ll branch out from a feature branch for the occasional and infamous ‘get CI working’ round of 10 one-line commits though, to not make it too muddy.

If things are heading towards a single commit an amend commit works fine for me. If I need a previous state I just get it from reflog.

Re: Git rebase, what can go wrong

#245

Post by jiehong »

I used to commit and then rebase -i to squash interactively, but I always had troubles with which commit is the oldest vs youngest and wether I need to pick one and squash the rest or squash them all.

Now I make a single commit per PR that I commit —amend —no-edit until it’s merged. I sometimes have to rebase it onto main for conflicts but that’s easy.

Re: Git rebase, what can go wrong

#246

Post by bonzini »

WorldMaker wrote: post #220
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.

If merge points are your "known good" points anyway you can just use the powers of the git dag and `git bisect --first-parent` in your main branch to just bisect the merge points. There's no need for rebase/squash and you still get useful git bisect results.

All commits are good points and potentially useful points. Was the bug in the refactoring? In the feature itself? In the resolution of merge conflicts? You can only answer if you don't squash, and it becomes easier to fix the bug if you know the answer.

Re: Git rebase, what can go wrong

#247

Post by h1fra »

lycos wrote: post #4
h1fra wrote: post #3

I might be lucky but in my whole developer life I have only used like 3 commands git stash, git pull --rebase and git merge. I'm not even sure I used git rebase once.

what do you think git pull --rebase does..

well it rebase but I never had to deal with everything in this article. It put my commits on top of HEAD and that's it, never had any issue.

Re: Git rebase, what can go wrong

#248

Post by BeetleB »

duped wrote: post #134
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.

It's hard to tell what side you're on, because both sides refer to their stance as "clean history".

The pro-revisionists (squash, rebase) say they do what they do so the history looks clean (no intermediate commits breaking stuff, a "straight line" graph, etc)

The anti-revisionists say they do what they do so the history looks clean (can see the actual development, can safely diff different commits to see what changed in between, see the log in chronological order, etc).

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

Again, both sides could argue that they're the ones with more discipline.

> The point is to make it possible to debug later, via bisect, or show, or even just a diff.

This sounds anti-revisionist.

> The point is to make the workspace clean for the next guy.

This is one of the most common pro-revisionist arguments.

Re: Git rebase, what can go wrong

#249

Post by sodapopcan »

Lio wrote: post #179
mablopoule wrote: post #13

Earlier quoted context omitted.

I actually hate squash merge because of all the noise it adds. Sure, the commit graph looks nicer, but it come with a terrible loss of information when doing git blame. I'm a big proponent of rebase and squash if it helps to make a commit more coherent, but we use squash merges by default in the current project I'm working on, and I die a little bit each time I try to understand what changes were related to a line wh…

Git blame confuses people even without squash merges. I've seen people forget to go back more than one commit and then blame the person who last indented a file instead of going back to the commit that actually wrote the code many times.

> I've seen people forget to go back more than one commit and then blame the person who last indented a file instead of going back to the commit that actually wrote the code many times.

I default my `git blame` to `git blame -w` which ignores whitespace commits. Though knowing how to jump back commits should be required knowledge.

Re: Git rebase, what can go wrong

#250

Post by btilly »

latexr wrote: post #217
btilly wrote: post #103

Earlier quoted context omitted.

No, because git bisect operates off of the information in the history. And thanks to the bad rebase, the history no longer existed in the branch.

Wasn’t `git reflog` viable?

How do you find the right commit from a month ago to reflog to?

How do you determine which combination of changes are yours, and not accidentally undo changes that other developers made in the last month?

Could git reflog have helped? Maybe sometimes. If we had the foresight to have saved the right commits from the past, sure. I think we did start saving old branches just in case it happened again, but then we had to sort through a month of changes to figure out what to keep, what to change, and what conflicts there might be.

Remember, the person screwing up didn't know he screwed up. And the person trying to fix it is doing so a long time after the fact. It was a disaster.

Post reply on HN