Re: [Monotone-devel] Suggestion for new commit variant

[Daniel Carosone]

On Thu, Oct 27, 2005 at 08:55:30AM +0200, Wim Oudshoorn wrote:
> It just dawned on me that the following command would
> solve quite a few of my problems:
> 
> monotone newcommit [-b branch] -parentrevs rev1 rev2 ....
> 
> That is, I can commit a set of source files  
> and explicitly specify the parent revisions.

Hm.  I have cheated on one occasion by just editing MT/revision prior
to committing.  I did this as a different form of disapprove - partly
out of curiosity, and partly because I still had the chance to avoid
publishing the actual mistake, which was only in my local db.

This cheat doesn't address multiple parents.  In my case, the work
file was empty too, which is another issue njs notes and which I
hadn't thought about at the time.

> This would solve quite a few of my problems:
> 
> 1 - merging outside of monotone's control:
> 
>   * Check out HEAD1
>   * Check out HEAD2
>   * Check out ANCESTOR
>   * Do my merge on my tree
>   * monotone newcommit -parentrevs HEAD1 HEAD2

I wonder...

 * check out HEAD1, HEAD2, ANCESTOR, manual-merge as above
 * echo HEAD1 > MT/revision; commit -m "manual merge with HEAD2"
 * echo HEAD2 > MT/revision; commit -m "manual merge with HEAD1"
 * monotone merge

I give the example not so much as a possible workaround using today's
syntax, but to pose the question of whether the extra nodes in the
graph add any value (since you're so fond of them :-).  Probably they
don't, and in fact hide the true merge step in the graph.

> 2 - propagate does not mess up my tree:
> 
>   REV1    
>   branch A
>             \
>              \
>              REV2
>              branch B
> 
>    
>    propagate B A
> 
>    wil change in:
> 
>    monotone newcommit -b branch A  -parentrevs REV1 REV2 to yield
> 
>    which results in:
> 
>    REV1              REV3
>    branch A -------> branch A
>             \        /
>              \      /
>             REV2 
>             branch B

I discussed this one elsewhere.  I can see why you want REV3, and I'm
tempted to want it myself, too, but I don't think it's the right thing
for distributed editing.

> 3 - I can do an explicit dissapprove
> 
>   REV1       -----> REV2
>   branch A          branch A
>                /
>               /
>          ....
> 
> 
>    namely checkout REV1 
>    and do:
> 
>    monotone newcommit -parentrevs REV1 REV2.

Others discuss this one elsewhere, too.

> DISCLAIMER
> ----------
> 
> This just occured to me, so it might be totally
> unworkable, if so please let me know.

So, it's possible now (at least for single parents, and with some
other restrictions/caveats) with the cheat I describe.  Therefore, we
pretty much have to deal with it anyway :-) 

Regardless of whether the examples you happened to choose above are
good ones, or should be handled by something more explicitly designed
for the particular purpose (such as upcoming workingdir merge
features), there may be others we haven't thought of yet.  I suspect
there may be some of these to be found in cherry-picking use cases.

--
Dan.

pgpLnc6waCAcC.pgp
Description: PGP signature