Submitter | Jordi Gutiérrez Hermoso |
---|---|
Date | Aug. 24, 2014, 11:06 p.m. |
Message ID | <87bc71fdf83ba5ba2d85.1408921600@Iris> |
Download | mbox | patch |
Permalink | /patch/5581/ |
State | Changes Requested |
Headers | show |
Comments
Jordi Gutiérrez Hermoso writes: > # HG changeset patch > # User Jordi Gutiérrez Hermoso <jordigh@octave.org> > # Date 1407783206 14400 > # Mon Aug 11 14:53:26 2014 -0400 > # Node ID 87bc71fdf83ba5ba2d85f8cf082819d30b93e31f > # Parent 44ecb51c857da4cbfddcc8c1220747a477a96ac2 > filemerge: add non-interactive internal:merge-local and internal:merge-other > > There are two non-interactive internal merge tools, internal:other and > internal:local, but they don't really merge, they just pick all > changes from the local or other version of the file. In some > situations, it is known that we want a merge and also know that all > merge conflicts should be resolved in one direction. Although external > merge tools can do this, sometimes it can be convenient to do so from > within hg, without invoking a merge tool. These new > internal:merge-local and internal:merge-other tools can do just that. So, I really like this functionality but since the sprint is this week, maybe we could talk about a UI for this and other changes proposed?
On 08/25/2014 01:06 AM, Jordi Gutiérrez Hermoso wrote: > # HG changeset patch > # User Jordi Gutiérrez Hermoso <jordigh@octave.org> > # Date 1407783206 14400 > # Mon Aug 11 14:53:26 2014 -0400 > # Node ID 87bc71fdf83ba5ba2d85f8cf082819d30b93e31f > # Parent 44ecb51c857da4cbfddcc8c1220747a477a96ac2 > filemerge: add non-interactive internal:merge-local and internal:merge-other I was expecting some trace of reflexion about the naming scheme of this familly of tool. any advance on that?
On Tue, 2014-08-26 at 22:57 +0200, Pierre-Yves David wrote: > > On 08/25/2014 01:06 AM, Jordi Gutiérrez Hermoso wrote: > > # HG changeset patch > > # User Jordi Gutiérrez Hermoso <jordigh@octave.org> > > # Date 1407783206 14400 > > # Mon Aug 11 14:53:26 2014 -0400 > > # Node ID 87bc71fdf83ba5ba2d85f8cf082819d30b93e31f > > # Parent 44ecb51c857da4cbfddcc8c1220747a477a96ac2 > > filemerge: add non-interactive internal:merge-local and internal:merge-other > > I was expecting some trace of reflexion about the naming scheme of this > familly of tool. any advance on that? Yeah, I tried to think of something else, and I couldn't think of a better name for it. I asked around, nobody answered. I don't think the name is that bad. It's about as short as it can be while remaining descriptive. I honestly don't understand why you dislike the name, or what you have in mind instead. - Jordi G. H.
On 08/27/2014 02:07 AM, Jordi Gutiérrez Hermoso wrote: > On Tue, 2014-08-26 at 22:57 +0200, Pierre-Yves David wrote: >> >> On 08/25/2014 01:06 AM, Jordi Gutiérrez Hermoso wrote: >>> # HG changeset patch >>> # User Jordi Gutiérrez Hermoso <jordigh@octave.org> >>> # Date 1407783206 14400 >>> # Mon Aug 11 14:53:26 2014 -0400 >>> # Node ID 87bc71fdf83ba5ba2d85f8cf082819d30b93e31f >>> # Parent 44ecb51c857da4cbfddcc8c1220747a477a96ac2 >>> filemerge: add non-interactive internal:merge-local and internal:merge-other >> >> I was expecting some trace of reflexion about the naming scheme of this >> familly of tool. any advance on that? > > Yeah, I tried to think of something else, and I couldn't think of a > better name for it. I asked around, nobody answered. I don't think the > name is that bad. It's about as short as it can be while remaining > descriptive. I honestly don't understand why you dislike the name, or > what you have in mind instead. There is at least 3 differents possible level we may want to resolve conflict (1) manifest: always takes file from (other|local) (2) file: instead of merging take version from (other|local) (3) chunk: merge but resolve conflict in favor of (other|local) case (2) is currently handled in core and called internal:other You are proposing something for (3) called internal:merge-other (1) is currentl unsupported and we have no name planned for it. What I would like now from you is to actually think about the whole picture. Do we want to handle (1) ? is there other cases? Then come with a some proposal for a naming scheme of the possible case (this may involve drawing table). What I current dislike about "internal:merge-other" is that if I hand "internal:other" and "internal:merge-other", he will have not idea about what each of those is doing. I also have no idea about how to name (1) after your new introduction for (3)
Patch
diff --git a/mercurial/filemerge.py b/mercurial/filemerge.py --- a/mercurial/filemerge.py +++ b/mercurial/filemerge.py @@ -229,6 +229,40 @@ def _imerge(repo, mynode, orig, fcd, fco return True, r return False, 0 +def _imergeauto(repo, mynode, orig, fcd, fco, fca, toolconf, files, + labels=None, localorother=None): + """ + Generic driver for _imergelocal and _imergeother + """ + assert localorother is not None + tool, toolpath, binary, symlink = toolconf + if symlink: + repo.ui.warn(_('warning: internal:merge-%s cannot merge symlinks ' + 'for %s\n') % (localorother, fcd.path())) + return False, 1 + a, b, c, back = files + r = simplemerge.simplemerge(repo.ui, a, b, c, label=labels, + localorother=localorother) + return True, r + +@internaltool('merge-local', True) +def _imergelocal(*args, **kwargs): + """ + Like internal:merge, but resolve all conflicts non-interactively + in favor of the local changes. + """ + success, status = _imergeauto(localorother='local', *args, **kwargs) + return success, status + +@internaltool('merge-other', True) +def _imergeother(*args, **kwargs): + """ + Like internal:merge, but resolve all conflicts non-interactively + in favor of the other changes. + """ + success, status = _imergeauto(localorother='other', *args, **kwargs) + return success, status + @internaltool('merge3', True, _("merging %s incomplete! " "(edit conflicts, then use 'hg resolve --mark')\n")) diff --git a/tests/test-conflict.t b/tests/test-conflict.t --- a/tests/test-conflict.t +++ b/tests/test-conflict.t @@ -232,3 +232,66 @@ internal:merge3 5 >>>>>>> other Hop we are done. + + +Add some unconflicting changes on each head, to make sure we really +are merging, unlike internal:local and internal:other + + $ hg up -C + 2 files updated, 0 files merged, 0 files removed, 0 files unresolved + $ printf "\n\nEnd of file\n" >> a + $ hg ci -m "Add some stuff at the end" + $ hg up -r 1 + 1 files updated, 0 files merged, 1 files removed, 0 files unresolved + $ printf "Start of file\n\n\n" > tmp + $ cat a >> tmp + $ mv tmp a + $ hg ci -m "Add some stuff at the beginning" + +Now test internal:merge-other and internal:merge-local + + $ hg merge + merging a + warning: conflicts during merge. + merging a incomplete! (edit conflicts, then use 'hg resolve --mark') + 1 files updated, 0 files merged, 0 files removed, 1 files unresolved + use 'hg resolve' to retry unresolved file merges or 'hg update -C .' to abandon + [1] + $ hg resolve --tool internal:merge-other a + merging a + (no more unresolved files) + $ cat a + Start of file + + + Small Mathematical Series. + 1 + 2 + 3 + 6 + 8 + Hop we are done. + + + End of file + + $ hg up -C + 1 files updated, 0 files merged, 1 files removed, 0 files unresolved + $ hg merge --tool internal:merge-local + merging a + 2 files updated, 0 files merged, 0 files removed, 0 files unresolved + (branch merge, don't forget to commit) + $ cat a + Start of file + + + Small Mathematical Series. + 1 + 2 + 3 + 4 + 5 + Hop we are done. + + + End of file