Pushing after merge considered harmful

[Alexander Belchenko]

Eli Zaretskii пишет:
>> From: Alexander Belchenko <bialix at ukr.net>
>> Date: Tue, 26 Jan 2010 21:47:53 +0200
>>
>> BTW, I wrote series of articles about bzr mainline idea in Russian:
>>
>> http://bzr-day.blogspot.com/2009/09/mainline-1_08.html
>> http://bzr-day.blogspot.com/2009/09/mainline-2.html
>> http://bzr-day.blogspot.com/2009/11/mainline-3.html
> 
> Thanks, everything is clear.  I have only one question.  You say:
> 
>    ... a direct `push' [from a feature branch to mainline] is not a
>    good idea, especially if your feature branch has more than one
>    revision.
> 
>    If all your changes were committed as a single revision, you can
>    choose whether to merge or push.  [...]
> 
> Can you explain what is the significance of a single revision vs
> multiple revisions in this case?

The reason is very simple.

If I have all my changes in one revision, and such revision has correct 
commit message (in the same manner as other mainline commits) then I 
will push to the trunk and everybody will be happy.

When I have several commits which done while I'm working on some 
specific feature, then it makes big sense to not push this sequence to 
trunk, because many intermediate steps have no sense by itself, but only 
as tight group of related changes. Because if I do branch from some of 
intermediate revision I can get unfinished or even broken state of my work.

So bzr promote the workflow when you merge all your revisions from 
feature branch into trunk mirror (and thus effectively collapse them 
into *one* mainline revision) and then push.

In this case log of mainline represents very nice overview of new 
features added, bugs fixed, every one in dedicated revision, not messed 
up. And in the same time intermediate (merged in) revisions from your 
feature branch made precise annotation for every single change.

Just for comparison: in Mercurial there is no idea of mainline. But not 
so long ago I saw there was developed extension (plugin) called "group" 
to organize several revisions in the logical groups which represents 
every single feature. http://mercurial.selenic.com/wiki/GroupExtension
Is not this looks very similar to what bzr do by default using workflow 
I've described above?

>> It takes me 3 attempts to articulate it without using word "DAG" in
>> every second sentence.
> 
> IMO, it's a pity that the graphs are not mentioned and not discussed.
> Especially since the snapshots you show from qlog actually show the
> DAG.  They say a picture is worth a thousand words, and they are
> right.  But a picture _with_ a thousand words based on it is worth
> much more, in my experience.  Abstract ideas are much easily consumed
> if they are illustrated by a picture, and a DAG is a very simple
> picture.

Well, I'm not mathematician and even don't have a degree in computer 
science. I have diploma of radio-engineer, and I develop embedding 
systems. That's my excuse.
So while I'm understand the DAG concept (at least I think so), I'm 
trying to avoid talking about it too much. Maybe I should not.