Richard Lee wrote:
> Jonathan Nieder wrote:
>> Then your response pushed me towards the question of whether --no-ff is a
>> good idea in general
>>
>
> John, I get the feeling from what you say in general that fast forwards are
> default behaviour for merges for a reason and by using the --no-ff option I
> am making my workflow and git history uncessesarily awkward and working
> against best practices?
Well, no. Some of us (read: I) just haven’t figured out yet how to fit the
--no-ff option into a broader workflow yet. It is only two years old. :)
There are pros and cons to using --no-ff to merge topic branches. Pros:
* 'git log --first-parent' will give the list of topics now.
* The beginning and end of each topic is not forgotten by a clone any
more.
Cons:
* The perceived beginning and end of a topic might be irrelevant or
misleading.
* Every topic needs a good name. :)
* More commits for a person looking through the history to deal with.
A merge commit from a would-be fast-forward records content identical
to its second parent, and it is not necessary as glue to tie the
content-changing commits together any more.
After thinking about it a little, the pros seem to far outweight the cons.
>> Björn Steinbrink wrote:
>>
>>> I guess Richard took the "branch topic1, merge topic1, branch topic2,
>>> merge topic2" thing just as an example because that ends up with two
>>> fast-forwards.
>>
>> Hmm, I found Richard’s example pretty realistic. I used to work like
>> that, and I don’t think I am the only one.
>>
>
> I'm not saying there is any one "right" workflow. But is there a more
> suitable workflow than than "branch topic1, merge topic1, branch topic2,
> merge topic2"?
Yes, in my opinion. I prefer to branch topic1, branch topic2, ...
and only later (after some time to reflect) decide which topics to
merge. For this to work, each topic should not have all previous
topics as ancestors, or there is no way to postpone merging any one.
This is especially nice when a topic turns into a long-term project.
By not merging in the partial work, I keep the code in the master
branch a little cleaner, but more importantly, bugs in the partial
work do not interfere with work on other topics. Once it is finally
time to merge the topic back to master, it is in one clean merge, and
all the commits are together for someone looking at the history.
“What about testing?” one might ask. “How can I tell when it is safe
to merge the topic to master, when the topic and other features since
then might work well separately but not together?” The “Throw-away
integration” section in gitworkflows(7) [1] discusses how to deal with
this.
Taking the idea of forking from the oldest relevant commit to an
extreme in a single-person project, you can end up with history like
this:
initial---------------final
\ /|
\---A-------/ |
\ / /|
\---B---/ / |
\ / |
\---C-- |
\ /
\--D---
\
-E- ...
i.e., full of octopus merges and basically unreadable in gitk.
Arguably, this is at least partially a gitk bug. [Aside: a dream
feature for gitk would be to give the --first-parent history at first
and then fill in topics when the user requests them. That is, in this
example, it would show
initial---final
but after a click on the parent A, it would show
initial---final
\ /
A
and so on.] To avoid this, it is best not defer merging topics into
the mainline for too long, and to base each topic branch not on the
oldest relevant commit but on the tip of the oldest branch it might be
merged to (which in the simplest case is usually the mainline).
A single person has a lot of control over the shape of the history,
so that it is easy to make it totally linear or sequence of enormous
octopuses. The nicest history for others to read, I think, is that
most like one created by many people in a healthy project. But that’s
a hard ideal to achieve, and more important than crafting well shaped
history is to write good code, so it is not worth obsessing over.
I hope that is a little clearer.
Regards,
Jonathan
[1] http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html#_throw_away_integration
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html