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

181–190 of 404 posts

Re: Git rebase, what can go wrong

#181

Post by htamas »

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…

A clean git history on a pull request also makes it easier for the reviewer to understand your code. Small, concise commits will tell the reviewers about your train of thought or what issues did you run into, making it easier to pick up the context. I start with every code review by looking at the commit history.

I prefer not to have squash commits in our team for this reason. It makes master look good, but usually nobody ever looks at the master commit history first, they look at the merged pull requests. However, everybody must look at the commits you made in a pull request. If you have squash commits, you are encouraged to have messy commit history in your pull requests, leading to meaningless commit messages and even large commits (causing other problems...).

IMO the only advantage of squashing is that it makes it easy to roll forward when you accidentally deploy something that causes problems.

Re: Git rebase, what can go wrong

#182

Post by bigstrat2003 »

jzm2k wrote: post #58
m3kw9 wrote: post #20

Git rebase is stupid, I’ve seen countless f ups because someone needed the git history to look good

git-rebase is stupid because somebody doesn't know how to use it? I use it all the time and I really like how I can make garbage commits (wip, test) and then squash them into atomic commits which are easy to review and later on easy to bisect when inevitably mistakes happen. Sure I've fucked up too when I was learning on how to use it and those were some painful mistakes but only through using it and making those mis…

> git-rebase is stupid because somebody doesn't know how to use it?

No, it's stupid because it's really common for people to fuck it up, and because the purported benefits (clean history) are not something which matters.

Re: Git rebase, what can go wrong

#183

Post by ksenzee »

ajkjk wrote: post #172
ksenzee wrote: post #38

Earlier quoted context omitted.

I’m curious how this workflow differs from `git merge --squash`.

I dunno, I've literally never used merge ever since realizing what it does to the commit history.

Then you should probably look up squash “merges,” because I believe that’s your `git rebase --tip`. I use quotation marks because it’s not an actual merge. It just takes all the changes from the feature branch and stages them in the index, ready for you to commit as one single non-merge commit.

Re: Git rebase, what can go wrong

#184

Post by nomel »

smw wrote: post #141
naasking wrote: post #80

Earlier quoted context omitted.

> git-rebase is stupid because somebody doesn't know how to use it? The whole purpose of source control is to reliably track code changes so you don't lose anything and can revert to any point or recover from bad merges. Since rebase permits you to violate this core purpose and literally lose the entire history of code changes, then yes, it is stupid.

It doesn't. Reflog still exists.

No. Reflog exists locally.

Getting away from dependence on the ephemeral is why git exists.

Re: Git rebase, what can go wrong

#185

Post by ksenzee »

Izkata wrote: post #121
ksenzee wrote: post #34

Earlier quoted context omitted.

Only metaphorically, maybe. You can squash merge in lots of cases where a rebase will fail.

They are essentially rebase+squash, despite the name. There is no actual merge taking place. And for that matter, you'd manually do a squash with the interactive rebase tool anyway ("git rebase -i").

Imagine a feature branch where someone has been keeping it up to date by merging main into it regularly. Now the feature is ready to go into main. You can easily `git merge --squash` that branch into main. You can likely do the same thing manually (as you point out) by running `git rebase -i` if you squash all the commits in the branch. But you’ll never manage to do a genuine rebase, where every commit in the branch gets turned into a clean non-merge commit onto main.

Re: Git rebase, what can go wrong

#186

Post by nicwolff »

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…

Dude your "random thoughts" are better than a lot of folks' work output ツ

Re: Git rebase, what can go wrong

#188

Post by marcandre »

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.

The classic example where this fails is when needing to revert something. An atomic commit for the migrations + some atomic commits for the implementation mean you can easily revert the implementation, and leave the migration intact (as should be) and add a reverse migration.

Re: Git rebase, what can go wrong

#189

Post by foobarbaz33 »

btilly wrote: post #114
foobarbaz33 wrote: post #104

Earlier quoted context omitted.

> the mess is the actual history. The true history is not recorded in your normal commits either. Every time you modify your source buffer, that is the true sequence of events. This truth is lost already as you undo/rework things before you commit. You're ALWAYS manipulating and telling a false story of history whether you realize it or not. Commits are a tool that give stronger backup/undo protections over simple fi…

I believe that you are confusing "full history" and "true history". Every single point in the commit history represents an actual state of a repository at a specific point of time, along with the information of which point or points were next before it. This is all part of the true history. This is not a full history - you don't have every keystroke, abandoned commit, switch between branches and so on. But nothing th…

> As soon as you do a rebase, you're rewriting history.

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.

> You're losing information about points of time and specific states that actually existed

If you avoid rebase, then you end up "rebasing" without rebasing. You "squash" intermediate states by never recording them to begin with.

Failing to record history is not superior to squashing it.

> And finds that it is gone without a trace.

I don't have the details, but it sounds like someone rebased a public branch. Yes that is bad. But it's sort of like saying we shouldn't drive cars because someone chose to drive the wrong direction down a 1 way road.

Re: Git rebase, what can go wrong

#190

Post by gwright »

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.

> why spend time on a ‘nice’ commit history in a (smallish) feature branch when you can squash merge later.

Several reasons:

    * facilitates much better code review discussions
    * enables use of git bisect to locate bugs
    * allows for informative commit messages associated with the changes
    * communicates clearly to future self about why changes were made
Post reply on HN