
A tidy, linear Git history - jacobr
http://www.bitsnbites.eu/?p=221
======
kazinator
That graph on the right isn't a true linear history. _This_ is:

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

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

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

~~~
dgreensp
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?

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

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

