dummy merge (two branches) for dummies

[Simon King]

On Fri, Aug 19, 2016 at 1:39 PM, Uwe Brauer <oub at mat.ucm.es> wrote:
>
>
>     > The nitpick is wrong. It really should be "hg branch uwe", because
>     > that's the only thing that should be changed in the dirstate after the
>     > initial update to foo: the branch name. Everything else should stay as
>     > it is. As I wrote before, my initial post was wrong in the order of
>     > arguments of debugsetparents. Since you are at "foo", that should also
>     > be the first argument in the parents list, otherwise Mercurial would
>     > get quite confused and produce what Mischa Becker pointed out.
>
>     > So the proper chain is:
>     > hg update foo
>     > hg debugsetparents foo uwe
>     > hg branch uwe
>     > hg commit -m "Merge"
>
>
> Sorry I tried this now two times in two different directories.
> So the proper chain is:
> hg update foo
> hg debugsetparents foo uwe
> hg branch uwe
> hg commit -m "Merge"
>
> And
>
> So the proper chain is:
> hg update foo
> hg debugsetparents uwe foo
> hg branch uwe
> hg commit -m "Merge"
>
>
>
> Give for me (in the example Mischa Becker posted)
>
> The same result.
>
>     > This will give you a merge commit that has the exact same content as the foo revision.
>
> After thinking for a while, for the workflow I have in mind, this
> solution is not what fits me best. My co author usually heavily  edits one
> main file and does not add nor delete files, while I do, but would like
> to dummy merge his changes of the main file into my branch, so the
> first solution Mischa posted
>
>    hg update uwe
>    hg merge foo --tool internal:other
>    hg commit -m "Merge foo internal:other"
>
> Is what fits best (in these particular circumstances).

I think I'm missing something here. Why do you want a dummy merge
(rather than a normal merge) at all? Why are you regularly merging
with a co-author but throwing away his changes? (Or is it *your*
changes you are throwing away?)

Are there going to be some files that you do actually want to merge,
and others that you want to choose just one side or the other? If so,
you might be better off running the merge as usual, but then reverting
*just the files that ought to be reverted* back to one branch or the
other. You could do this using "hg revert -r <branchname> <file1>
<file2...>" before committing the merge.

Simon