[RFC] Enforcing a "linear" repository by first parent?

[Andy Lutomirski]

Mark A. Flacy wrote:
> On Thu, 2009-03-19 at 15:26 -0400, Greg Ward wrote:
> 
> [snip]
>> Less smart-alecky response: embrace the brave new world.  Branches and
>> merges happen all the time, so why not let your history reflect that?
>> Use rebase if you don't want so many silly little merge changesets.

I like the brave new world.  But I also like to follow the tip of the 
main branch, and the tip changes over time, and from my point of view, 
it changes in a linear manner (i.e. today the tip is X and then tomorrow 
the tip is Y).

>>
>> Disclaimer: it sounds nice on paper, but I haven't fully embraced the
>> brave new world myself yet.  I mean, yeah, sure, I've used hg and git
>> to prepare and submit patches to a couple of projects, and I use hg
>> for my own piddling little spare-time projects, but we haven't taken
>> the plunge at work.  Yet.  ;-)
> 
> 
> We deal with a ClearCase/UCM version of the "brave new world" at work
> every day.  Sure, the version tree graph of any given file can be rather
> imposing, but you can still designate a "main branch" and deliver
> everything into that one.

Yes.  But how do I figure out after the fact what got delivered?

> 
> A path down a single branch is a linear one.
> 

I'm not sure I follow.  Suppose I have revision 1 on the main branch. 
Alice commits revision 2 locally, and Bob commits revision 3 (parent = 
1) locally.  Alice pushes revision 2 to master (or pulls or whatever). 
Bob follows the usual workflow:

hg push # fails because it would create a new head

hg pull # gets a copy of rev 2
hg merge; hg commit # produces revision 4, with parents (3, 2)
hg push # works

Here's my objection: there's another user Charlie who likes to review 
things that hit the main tree.  He sees revision 2 go in and reviews it. 
  The next day he looks at the main tree and sees revision 4 on the tip. 
  Unless he remembers that revision 2 used to be the tip, how can he 
tell that 2 was *ever* a tip?  As far as he can tell, revision 3 might 
have gone in first.  (OK, he can do it using revision numbers as opposed 
to hashes, but that seems really painful and might not survive pulls.)

There isn't even a consistent way to tell based on the order of the 
parents (using standard practice) because in this case the second parent 
was the old tip but, if it were a named branch merge, it would be the 
other way around (you have to merge the named branch into default and 
now the other way around if you want the merge result to be part of 
default).

As a more serious explanation of why I care:  My project has a handful 
of developers who all implement new features in their local trees (on 
named or unnamed branches, depending on how big they are) -- this is 
*why* we use Mercurial.  After a feature is done and reviewed, the 
developer pushes it into the main tree.  Afterwards, before we spin new 
releases, we like to look over what changed, and conceptually I'd like 
to see "Feature B was pushed.  Before that, feature A was pushed" as 
opposed to "Feature B was pushed.  Before that, the developer of feature 
B fixed all these bugs.  And before that, the developer implemented the 
second half of feature B.  And in parallel, someone else did 
such-and-such to feature A. ..."   In other words, I'm often more 
interested in seeing the history of things hitting the main tree, as 
opposed to the history of the development of those things, even though I 
like having the latter in the tree somewhere.

I think that this is solved nicely by my proposed (configurable) rule: 
all pushes to the main tree must have the previous tip as a first 
ancestor.  Now I can always see the history ordered by when it went in 
to the main tree.

The only cost seems to be that, in the example above, Bob would have had 
to do:

hg push # fails because it would create a new head

hg pull # gets a copy of rev 2
hg up -r 2 # -C might be needed as well.
hg merge -r 3; hg commit # produces revision 4, with parents (2, 3)
hg push # works

If we went even farther and added a --swap-parents flag to hg merge, 
this would be a piece of cake.

--Andy