Ancestry Graphs (fast-forward versus merge)

[Alexander Belchenko]

John Arbash Meinel пишет:
> I'm actually going to try and split up my responses, because we have
> several threads going on at once. :)
> 
> I'm also bringing it onto the list. I realize it is sort of in the
> middle of the conversation, but I've had some insight, that I think is
> worthy of sharing.
> 
...
> 
> Now, there is another case that I would like to propose, which is where
> it is very useful (IMO) to have a node F, so that you can review what
> has been going on:
> 
> v- public tree
>     v- Feature branch
>         v- Commit message
> A	# Release 0.1
> | \
> |   B   # Add function foobar to create feature foo
> |   |
> |   C   # Crush the bugs and hear the lamentations of the evil
> |   |
> |   D	# Ooops, missed one
> |   |
> |   E	# use foobar in solve_all_problems()
> | /
> F	# [merge] foobar solves all problems
> 

I think this workflow is very good in many cases. I personally try to
use it when I work with CVS but it was slightly hard. Bzr make it's very
easy. I think it's big win.

> A fairly involved feature branch can be summarized in the commit F. So
> that looking at the A, F history, you can see the release, and then that
> feature "foobar" was added.
> 
> If you used fast-forward, you wouldn't get the opportunity to create the
> summary information, and if you were answering the question:
> 
>   When was "foobar" added to the public branch
> 
> You would probably search through the logs and see the log for B, when
> it was created, but it may not be clear that it wasn't ready until E to
> actually be used.
> 
> Also, you can have the nice property that all of the commits on 'public
> tree' pass the test suite, while things elsewhere may or may not.
> 
> I believe the kernel tree has the policy that all of B-E must not have
> any (known) bugs in them, which means you have to rewrite the history to:
> 
> A
> |
> D # Bugless foobar
> |
> E # foobar used in solve_all_problems()
> 
> Basically, you have to hide that B and C existed, because there are bugs
> in them, or maybe they wouldn't apply cleanly to a new tip.
> 
> Now, I can agree that in a project the size of the kernel, with as many
> developers as it has. The ancestry becomes a little unwieldy. And you
> can scale clean commits, because each person trying to get something
> done can do the work to make it clean. While there is only 1 person
> doing the merging. But in smaller projects, the time spent cleaning up
> your patches may become a large percent of the time actually spent doing
> work.
> 
> Hopefully I've answered your direct questions about why you have to
> either add a new node, or keep a separate file indicating which nodes
> are the linear history. And why there may be value in an "empty" merge.
> (It is a way to collapse history without throwing it away).
> 
> Also, I've gained the insight that checking the tree content may be very
> worthwhile to avoid "more empty" (truly empty??, very empty???) merges,
> where both parents have the same content.

I alos think it's worth to do. At least it will be expected behaviour
for those users who don't want to dive into details of DAG, leftmost
parents and revision internals.

--
Alexander