colocated branches and auto nicknaming may solve merge&push problem.

[Martin Pool]

On 15 February 2010 17:31, INADA Naoki <songofacandy at gmail.com> wrote:
> Thank you, Stephen.
>
> Git doesn't care about "left" revision so bzr should solve it original way.
>
> After some consideration, I think adding option to commit like "bzr
> commit --land=1"
> is better than adding option to merge. (1 means pending:1, 0 means current head,
> --land without argument means --land=1)
>
> If adding --land option to merge, make "bzr revert" well is hard.
> And we should make an way to change "left" revision after merging.

So to be a bit more explicit, the problem with revert would be that if
'merge' rearranges your working tree and branch's pointers, revert is
not likely to undo them.  Naively, revert would leave you on the tip
of the branch you were trying to merge --into, with your previous work
stranded.

It would be a bit ugly and error prone to count on revert undoing this.

One solution is, as you say, 'commit --land'.

Another is to make merge set the working tree parents to [trunk_tip,
my_tip], but to leave the branch's tip at my_tip.  They are stored
separately, which allows for a wt being out of date etc.  commit
should then see the wt as up to date with the branch because the
branch is one of the parents.  revert would naively take the wt back
to being a clean copy of trunk_tip(?), at which point the tree would
seem out of date; or revert could be updated to go back to the branch
tip.  This would I think be a fairly safe, clean and feasible way to
do the option at merge time rather than commit time.  We will probably
need some new tests for the wt varying in that way and they may find
small assumptions that need to be relaxed, but probably not many.

-- 
Martin <http://launchpad.net/~mbp/>