A tidy, linear Git history | Hacker News Reader

A tidy, linear Git history

bitsnbites.eu

22 pointsjacobr8 comments

That graph on the right isn't a true linear history. This is:

    * HEAD
    |
    *
    |
    *
    |
    *
    |
    *
    .
    :
    .

No damned two-parent merge commits! Rebase or die.

This isn't about rebasing, it is about fast forwarding: this author tells you to turn off that feature manually... "an alternative would be to leave out "--no-ff", which would allow Git to do a fast-forward instead of a merge, in which case it may not be as clear which of the commits actually belonged to your topic branch". FWIW: I am with you... but I also think the concept of "topic branches" is not only high friction but kind of silly.

Is your statement about topic branches based on experience on a real product team with 5+ engineers working on the same codebase? If so, what's your preferred workflow?

Can't speak for grandparent, but in my real product experience, every change its its own topic. Multiple related changes are reviewed as separate Gerrit items and merged separately. Sometimes out of order, and with other things intervening. Every change is built, and has to pass some smoke tests.

The exception are external change sets (i.e. from open source upstreams). If you have some 53 commit feature from some kernel stream elsewhere that you would like to include, that doesn't turn into 53 individual cherry picks in the trunk. A topic "temp" branch is used for that, which is treated as one review item and merged.

Very few git repos need this workflow; it wouldn't be used for anything developed in-house.

If you have set of related changes, they are almost never the same "topic". Each change has its own topic. For instance, you'd like to implement some feature. But it requires refactoring of some code first. That refactoring is its own topic; it can go into the stream if your feature doesn't. The mere dependency of the feature on the refactoring doesn't make them the same topic.

The team should be able to say: "hey that refactoring is a good idea, we approve it---but, hold it, there are issues with the feature requiring more work".

So a situation is possible that the refactoring work goes into the stream, and other people's changes start to be based on it prior to the approval of the original feature it was intended for.

The idea that several individual dependent commits are one topic is just the biased opinion of the original developer.

What is true is that if some other stream wants the feature, then the dependent commits have to be picked up also. However, so what? The other stream can be so diverged already that it needs to pick up a truckload of other dependent commits for that feature to apply. In general, you can't just take a "topic branch" in isolation, only sometimes.

This is how I used to do it, but now I've come around to using --no-ff. The reason for this is that it allows easy visualization of the actual branch development without scrutinizing commit metadata. And it does so without any loss of linearity, because the second parent commit is already an ancestor of the first parent, therefore you have the property that the merge commit never has any conflict resolution in it, and you lose no git-bisect fidelity. The more I thought about it the more I found this to be win-win and changed my teams workflow a couple years ago.

Since I don't use "git merge", I have no use for --no-ff. (See "rebase or die" quip in parent.)

git rebase does take --no-ff, but it is silly (except in some special cases, when rewriting strictly local history). (I can't think of what those special cases are).

If you do a fetch and have diverged from upstream changes, "git rebase --no-ff" will rewrite those upstream changes, rather than fast-forward over them, which you almost certainly don't want.

You're not engaging with my actual point. Post-hoc delineation of topic branches without the effective loss of linearity is superior. Prove me wrong.

You need to explain git rerere to be able to save you from rebase trouble.

Reply on news.ycombinator.com