Comment by kazinator | Hacker News Reader

Comment by kazinator | Hacker News Reader

Parent Full thread

The diatribe against rebasing is stupid. In fact, not having more than one parent is a good thing because you with multiple parents, you don't know what is relevant. The history has turned into a hairball. When you try to navigate back in time, you face forking roads at every step and it turns into a maze walk.

The point is valid that when we rebase, we are losing history: the context of where that change was originally parented.

However, (1) the history does not matter if the change was parented in some temporary context, like your unpublished changes and (2) the information can be tracked in other ways, such as a Gerrit Change-Id (or something like it) in the commit message.

Regarding (1) the extra parent pointers in a merge commit cause retention of garbage. If we do everything with merge instead of rebase, we will never lose any of the temporary commits. If we prepare an unpublished change through numerous rebase operations, all that temporary crap will stay referenced from the head, waste space and confuse other people with irrelevant information when they try to navigate the history.

> history does not matter if the change was parented in some temporary context

It does if it means a big ball o' hackage lands on the public working branch, since it complicates merges, backouts, cherrypicks, and bisects.

Git users can also hide individual commit messages behind one big combined message, losing part of the project's development history and logical progression.

When I pull your repo and build it, and I find that it doesn't build on my system, I don't want to dig through a 500-line merge commit to figure out why you changed this one line from the one that used to build last week, I want the 14-line diff it was part of so I can begin to understand what you were thinking when you committed it. If I later find out that that 14-line change was wrong but the rest of your 500-line merge was fine, I want to be able to back it out with a single command. (In Fossil, it's `fossil merge --backout abcd1234`.)

> confuse other people with irrelevant information when they try to navigate the history.

How much time do you spend navigating the project's history vs looking at the tip of the current branch?

I'd wager that the times you dig back into the history, it's because you are in fact trying to figure out why you got here, which means a trail of detailed breadcrumbs will be more likely helpful than "...and between one week and the next, something changed in commit abcd1234, but we've lost all of its internal context, so we'll be spending next week reconstructing it because Angie's on vacation now."

Squashing changes isn't the only use of rebasing.

It's reasonably common for me to start exploring a problem space, stub out a concept, and have a long drawn-out conversation with the compiler that touches many files, before finally reaching a point that is working enough to be interesting.

At that point, I can take a step back and note that actually, not all of those changes have to be made all at once, and I can break that patch up into a bunch of simpler pieces.

In Git, I have two essentially-equivalent choices:

1. stage the commit in small chunks, adding a separate descriptive comment for each.

2. commit everything as a WIP commit so this working state is in the reflog, then break it up into smaller commits with interactive rebase.

In either process, I'm able to get a better comprehension of my own thoughts along the way.

Fossil, refusing both staging would force me to commit the proverbial 500-line blob all at once, which is less helpful to the reviewer trying to discern my thought process.

If rebasing isn't important to your workflow, Fossil probably is a better choice for you than Git. It has a lot of comforts that I really appreciated even eight years ago when I did frequently use Fossil (distributed wiki and tickets are really nice, the web interface serving raw artifacts from any point in time is great for HTML5 game jams, SQLite is a very portable repository format, etc. etc. etc.), and I'm sure it's only improved in that regard. The only reason I use Git for personal projects is because rebase is that helpful to my process.

> Fossil...would force me to commit the proverbial 500-line blob all at once

Nope.

If it were me doing such a thing as you describe, I'd start the work on a feature branch. If I'm working on that repo with other active developers, this lets them see what I'm up to and possibly help; and if not help, then at least be aware about where my head's at, so they can better predict what's likely to land on the shared working branch later.

If I got to a point where only part of the branch needed to be applied, I could cherrypick those individual changes, either down to the parent branch or up to a higher-level feature branch.

All of this happens in public, with the work fully recorded, so someone doesn't have to reconstruct the development history after the fact later.

This mode of development helps keep your project's bus factor above 1.

You can commit code that doesn't compile onto a feature branch so people can see what you're up to, I guess, but I don't see that helping with bisecting later, and I wouldn't expect the commit messages to be useful.

To be clear, my typical approach is certainly to commit every time I return to a working state. But in more experimental modes, I often reach that the long-way-around and have ended up with multiple semantic changes I wish to break apart for study.

Unless I'm missing something and Fossil has gained the ability to cherry-pick selective lines from a commit.

Squashing isn't rebasing, period.

The connection between the two is that git has a script called git rebase, which has an interactive mode, and that can squash commits.

git merge has squash functionality also (git merge --squash).

> It does if it means a big ball o' hackage lands on the public working branch, since it complicates merges, backouts, cherrypicks, and bisects.

Rebase on a local working copy is normally used for cleaning up a string of commits that is messy and/or separating commits that mixed multiple logical changes together.

Local commit history before push is arbitrary. There’s nothing sacred that needs to be preserved about the exact order I typed things into each file, that’s not what I want from a version control system.

Personally, I haven’t really seen use of rebase complicating merges, reverts, cherry picks, or bisects. I can imagine ways it can happen, but I haven’t seen it be a problem in practice. However, I have seen cases where failing to rebase caused problems. Allowing build breakage between two commits is an example where bisect is affected, and squashing the fix into the first commit before push is much preferred.

So, anyway, your example feels totally contrived.

> How much time do you spend navigating the project’s history vs looking at the tip of the current branch?

This is a false dichotomy. I need both. I happen to navigate project history quite a lot, like multiple times per day. In addition to how I got here I usually need to know who changed it, so I can talk to them.

Reply on news.ycombinator.com