Patchwork [4,of,5,V3] update: specify custom conflict markers for update (BC)

login
register
mail settings
Submitter Durham Goode
Date May 13, 2014, 12:47 a.m.
Message ID <2ca6a41546b166ca4915.1399942056@dev2000.prn2.facebook.com>
Download mbox | patch
Permalink /patch/4731/
State Superseded
Headers show

Comments

Durham Goode - May 13, 2014, 12:47 a.m.
# HG changeset patch
# User Durham Goode <durham@fb.com>
# Date 1399684151 25200
#      Fri May 09 18:09:11 2014 -0700
# Node ID 2ca6a41546b166ca491537d85729fc3e9c42c01b
# Parent  3e64ef576f5da47348903d25727d5e7c6c6a046a
update: specify custom conflict markers for update (BC)

Add custom conflict markers 'working copy' and 'destination' for doing hg update
when there are conflicts between your working copy and the destination.
Antoine Pitrou - May 15, 2014, 11:33 a.m.
On Mon, 12 May 2014 17:47:36 -0700
Durham Goode <durham@fb.com> wrote:
> # HG changeset patch
> # User Durham Goode <durham@fb.com>
> # Date 1399684151 25200
> #      Fri May 09 18:09:11 2014 -0700
> # Node ID 2ca6a41546b166ca491537d85729fc3e9c42c01b
> # Parent  3e64ef576f5da47348903d25727d5e7c6c6a046a
> update: specify custom conflict markers for update (BC)
> 
> Add custom conflict markers 'working copy' and 'destination' for doing hg update
> when there are conflicts between your working copy and the destination.

I find the term "destination" confusing in that context. Why not
"repository"?

Regards

Antoine.
Durham Goode - May 15, 2014, 9:05 p.m.
On 5/15/14, 4:33 AM, "Antoine Pitrou" <solipsis@pitrou.net> wrote:

>On Mon, 12 May 2014 17:47:36 -0700
>Durham Goode <durham@fb.com> wrote:
>> # HG changeset patch
>> # User Durham Goode <durham@fb.com>
>> # Date 1399684151 25200
>> #      Fri May 09 18:09:11 2014 -0700
>> # Node ID 2ca6a41546b166ca491537d85729fc3e9c42c01b
>> # Parent  3e64ef576f5da47348903d25727d5e7c6c6a046a
>> update: specify custom conflict markers for update (BC)
>> 
>> Add custom conflict markers 'working copy' and 'destination' for doing
>>hg update
>> when there are conflicts between your working copy and the destination.
>
>I find the term "destination" confusing in that context. Why not
>"repository"?
>
>Regards
>
>Antoine.

I don¹t think normal users have a great understanding of the difference
between the working copy and the repository.  Œdestination¹ at least
differentiates itself from working copy in that the working copy is your
files, and destination is where you¹re going, especially since this only
shows up during an hg update.
Antoine Pitrou - May 15, 2014, 9:18 p.m.
On Thu, 15 May 2014 21:05:53 +0000
Durham Goode <durham@fb.com> wrote:
> 
> I don¹t think normal users have a great understanding of the difference
> between the working copy and the repository.  Œdestination¹ at least
> differentiates itself from working copy in that the working copy is your
> files, and destination is where you¹re going, especially since this only
> shows up during an hg update.

I'm not sure how someone can use hg without understanding the
difference between working copy and repository.
On the other hand the word "destination" is confusing here. You claim
that the "destination" is where you fetch the changes *from*, but my
own intuition is that the "destination" of an update is the working
copy, i.e. where you put the changes *into*.

Regards

Antoine.


PS : I don't know what you compose your e-mails with, but the charset
declaration in your headers looks wrong here (see above quotation of
your message as seen from here).
Durham Goode - May 15, 2014, 9:40 p.m.
On 5/15/14, 2:18 PM, "Antoine Pitrou" <solipsis@pitrou.net> wrote:

>On Thu, 15 May 2014 21:05:53 +0000

>Durham Goode <durham@fb.com> wrote:

>> 

>> I don¹t think normal users have a great understanding of the difference

>> between the working copy and the repository.  Œdestination¹ at least

>> differentiates itself from working copy in that the working copy is your

>> files, and destination is where you¹re going, especially since this only

>> shows up during an hg update.

>

>I'm not sure how someone can use hg without understanding the

>difference between working copy and repository.

>On the other hand the word "destination" is confusing here. You claim

>that the "destination" is where you fetch the changes *from*, but my

>own intuition is that the "destination" of an update is the working

>copy, i.e. where you put the changes *into*.


I’ll let others chime in here.  I think of ‘hg update’ as you moving to
another spot in the repository, hence destination makes sense in my mind.


>

>Regards

>

>Antoine.

>

>

>PS : I don't know what you compose your e-mails with, but the charset

>declaration in your headers looks wrong here (see above quotation of

>your message as seen from here).


I tried changing my email settings to be UTF-8.  Let’s see how this one
turns out.
Antoine Pitrou - May 15, 2014, 10:34 p.m.
On Thu, 15 May 2014 21:40:49 +0000
Durham Goode <durham@fb.com> wrote:
> 
> I tried changing my email settings to be UTF-8.  Let’s see how this one
> turns out.

Thanks, it looks fine now.

Regards

Antoine.
Siddharth Agarwal - May 15, 2014, 10:41 p.m.
On 05/15/2014 02:18 PM, Antoine Pitrou wrote:
> On Thu, 15 May 2014 21:05:53 +0000
> Durham Goode <durham@fb.com> wrote:
>> I don¹t think normal users have a great understanding of the difference
>> between the working copy and the repository.  Œdestination¹ at least
>> differentiates itself from working copy in that the working copy is your
>> files, and destination is where you¹re going, especially since this only
>> shows up during an hg update.
> I'm not sure how someone can use hg without understanding the
> difference between working copy and repository.
> On the other hand the word "destination" is confusing here. You claim
> that the "destination" is where you fetch the changes *from*, but my
> own intuition is that the "destination" of an update is the working
> copy, i.e. where you put the changes *into*.

What about 'target'? I can see where the confusion about 'destination' 
comes from, but I think 'repository' is far more confusing.
Olle Lundberg - May 16, 2014, 12:11 a.m.
On Thu, May 15, 2014 at 11:05 PM, Durham Goode <durham@fb.com> wrote:

> On 5/15/14, 4:33 AM, "Antoine Pitrou" <solipsis@pitrou.net> wrote:
>
> >On Mon, 12 May 2014 17:47:36 -0700
> >Durham Goode <durham@fb.com> wrote:
> >> # HG changeset patch
> >> # User Durham Goode <durham@fb.com>
> >> # Date 1399684151 25200
> >> #      Fri May 09 18:09:11 2014 -0700
> >> # Node ID 2ca6a41546b166ca491537d85729fc3e9c42c01b
> >> # Parent  3e64ef576f5da47348903d25727d5e7c6c6a046a
> >> update: specify custom conflict markers for update (BC)
> >>
> >> Add custom conflict markers 'working copy' and 'destination' for doing
> >>hg update
> >> when there are conflicts between your working copy and the destination.
> >
> >I find the term "destination" confusing in that context. Why not
> >"repository"?
> >
> >Regards
> >
> >Antoine.
>
> I don¹t think normal users have a great understanding of the difference
> between the working copy and the repository.  Œdestination¹ at least
> differentiates itself from working copy in that the working copy is your
> files, and destination is where you¹re going, especially since this only
> shows up during an hg update.
>
> I think this change made it harder to understand merge margers (granted
i'm used to local/other) destination just confused me and i had to re-read
the patch description when looking at the test output.

If we are going to replace the names, can't we do it with the nomenclature
used in mercurial, rather than introduce another word *not* commonly used
in merge markers?

working copy/repo seems sensible to me.


>  _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>
Angel Ezquerra - May 16, 2014, 6:22 a.m.
On Fri, May 16, 2014 at 2:11 AM, Olle <olle.lundberg@gmail.com> wrote:
>
>
>
> On Thu, May 15, 2014 at 11:05 PM, Durham Goode <durham@fb.com> wrote:
>>
>> On 5/15/14, 4:33 AM, "Antoine Pitrou" <solipsis@pitrou.net> wrote:
>>
>> >On Mon, 12 May 2014 17:47:36 -0700
>> >Durham Goode <durham@fb.com> wrote:
>> >> # HG changeset patch
>> >> # User Durham Goode <durham@fb.com>
>> >> # Date 1399684151 25200
>> >> #      Fri May 09 18:09:11 2014 -0700
>> >> # Node ID 2ca6a41546b166ca491537d85729fc3e9c42c01b
>> >> # Parent  3e64ef576f5da47348903d25727d5e7c6c6a046a
>> >> update: specify custom conflict markers for update (BC)
>> >>
>> >> Add custom conflict markers 'working copy' and 'destination' for doing
>> >>hg update
>> >> when there are conflicts between your working copy and the destination.
>> >
>> >I find the term "destination" confusing in that context. Why not
>> >"repository"?
>> >
>> >Regards
>> >
>> >Antoine.
>>
>> I don¹t think normal users have a great understanding of the difference
>> between the working copy and the repository.  Œdestination¹ at least
>> differentiates itself from working copy in that the working copy is your
>> files, and destination is where you¹re going, especially since this only
>> shows up during an hg update.
>>
> I think this change made it harder to understand merge margers (granted i'm
> used to local/other) destination just confused me and i had to re-read the
> patch description when looking at the test output.
>
> If we are going to replace the names, can't we do it with the nomenclature
> used in mercurial, rather than introduce another word *not* commonly used in
> merge markers?
>
> working copy/repo seems sensible to me.

I also find "working copy / destination" confusing. The destination
part is more or less fine (although perhaps "target" or "update
target" would be better) but the "working copy" is ambiguous IMHO.
What working copy? The one before or after the update? When I think
about a merge during an update I tend to think of the working copy as
the _result_ of the merge which is in fact the destination! (i.e. to
me "working copy / source" would make more sense than "working copy /
destination"). Instead I would suggest using "source" or "update
source" (i.e. "source / destination").

That being said, I also find that adding custom markers may make
things more confusing than they were unless they are very, very clear
and consistent. Otherwise we risk introducing a bunch of new concepts
that are only used in some very particular contexts.

Could someone make  list of the proposed markers for all commands that
require them, so that they can all be seen in one single place and
commented on? I think it would make it easier to make sure that all of
them are more or less consistent.

Cheers,

Angel
Pierre-Yves David - May 16, 2014, 6:29 a.m.
On 05/15/2014 11:22 PM, Angel Ezquerra wrote:
> On Fri, May 16, 2014 at 2:11 AM, Olle <olle.lundberg@gmail.com> wrote:
>>
>>
>>
>> On Thu, May 15, 2014 at 11:05 PM, Durham Goode <durham@fb.com> wrote:
>>>
>>> On 5/15/14, 4:33 AM, "Antoine Pitrou" <solipsis@pitrou.net> wrote:
>>>
>>>> On Mon, 12 May 2014 17:47:36 -0700
>>>> Durham Goode <durham@fb.com> wrote:
>>>>> # HG changeset patch
>>>>> # User Durham Goode <durham@fb.com>
>>>>> # Date 1399684151 25200
>>>>> #      Fri May 09 18:09:11 2014 -0700
>>>>> # Node ID 2ca6a41546b166ca491537d85729fc3e9c42c01b
>>>>> # Parent  3e64ef576f5da47348903d25727d5e7c6c6a046a
>>>>> update: specify custom conflict markers for update (BC)
>>>>>
>>>>> Add custom conflict markers 'working copy' and 'destination' for doing
>>>>> hg update
>>>>> when there are conflicts between your working copy and the destination.
>>>>
>>>> I find the term "destination" confusing in that context. Why not
>>>> "repository"?
>>>>
>>>> Regards
>>>>
>>>> Antoine.
>>>
>>> I don¹t think normal users have a great understanding of the difference
>>> between the working copy and the repository.  Œdestination¹ at least
>>> differentiates itself from working copy in that the working copy is your
>>> files, and destination is where you¹re going, especially since this only
>>> shows up during an hg update.
>>>
>> I think this change made it harder to understand merge margers (granted i'm
>> used to local/other) destination just confused me and i had to re-read the
>> patch description when looking at the test output.
>>
>> If we are going to replace the names, can't we do it with the nomenclature
>> used in mercurial, rather than introduce another word *not* commonly used in
>> merge markers?
>>
>> working copy/repo seems sensible to me.
>
> I also find "working copy / destination" confusing. The destination
> part is more or less fine (although perhaps "target" or "update
> target" would be better) but the "working copy" is ambiguous IMHO.
> What working copy? The one before or after the update? When I think
> about a merge during an update I tend to think of the working copy as
> the _result_ of the merge which is in fact the destination! (i.e. to
> me "working copy / source" would make more sense than "working copy /
> destination"). Instead I would suggest using "source" or "update
> source" (i.e. "source / destination").

If working copy is confusing, what about "uncommitted changes"?

> […]
 >
> Could someone make  list of the proposed markers for all commands that
> require them, so that they can all be seen in one single place and
> commented on? I think it would make it easier to make sure that all of
> them are more or less consistent.

What about you?
Pierre-Yves David - May 16, 2014, 6:31 a.m.
On 05/15/2014 02:18 PM, Antoine Pitrou wrote:
> On Thu, 15 May 2014 21:05:53 +0000
> Durham Goode <durham@fb.com> wrote:
>>
>> I don¹t think normal users have a great understanding of the difference
>> between the working copy and the repository.  Œdestination¹ at least
>> differentiates itself from working copy in that the working copy is your
>> files, and destination is where you¹re going, especially since this only
>> shows up during an hg update.
>
> I'm not sure how someone can use hg without understanding the
> difference between working copy and repository.

You will be very surprise about the very thin amount of knowledge of 
average user.
Angel Ezquerra - May 16, 2014, 6:44 a.m.
El 16/05/2014 08:29, "Pierre-Yves David" <pierre-yves.david@ens-lyon.org>
escribió:
>
>
>
> On 05/15/2014 11:22 PM, Angel Ezquerra wrote:
>>
>> On Fri, May 16, 2014 at 2:11 AM, Olle <olle.lundberg@gmail.com> wrote:
>>>
>>>
>>>
>>>
>>> On Thu, May 15, 2014 at 11:05 PM, Durham Goode <durham@fb.com> wrote:
>>>>
>>>>
>>>> On 5/15/14, 4:33 AM, "Antoine Pitrou" <solipsis@pitrou.net> wrote:
>>>>
>>>>> On Mon, 12 May 2014 17:47:36 -0700
>>>>> Durham Goode <durham@fb.com> wrote:
>>>>>>
>>>>>> # HG changeset patch
>>>>>> # User Durham Goode <durham@fb.com>
>>>>>> # Date 1399684151 25200
>>>>>> #      Fri May 09 18:09:11 2014 -0700
>>>>>> # Node ID 2ca6a41546b166ca491537d85729fc3e9c42c01b
>>>>>> # Parent  3e64ef576f5da47348903d25727d5e7c6c6a046a
>>>>>> update: specify custom conflict markers for update (BC)
>>>>>>
>>>>>> Add custom conflict markers 'working copy' and 'destination' for
doing
>>>>>> hg update
>>>>>> when there are conflicts between your working copy and the
destination.
>>>>>
>>>>>
>>>>> I find the term "destination" confusing in that context. Why not
>>>>> "repository"?
>>>>>
>>>>> Regards
>>>>>
>>>>> Antoine.
>>>>
>>>>
>>>> I don¹t think normal users have a great understanding of the difference
>>>> between the working copy and the repository.  Œdestination¹ at least
>>>> differentiates itself from working copy in that the working copy is
your
>>>> files, and destination is where you¹re going, especially since this
only
>>>> shows up during an hg update.
>>>>
>>> I think this change made it harder to understand merge margers (granted
i'm
>>> used to local/other) destination just confused me and i had to re-read
the
>>> patch description when looking at the test output.
>>>
>>> If we are going to replace the names, can't we do it with the
nomenclature
>>> used in mercurial, rather than introduce another word *not* commonly
used in
>>> merge markers?
>>>
>>> working copy/repo seems sensible to me.
>>
>>
>> I also find "working copy / destination" confusing. The destination
>> part is more or less fine (although perhaps "target" or "update
>> target" would be better) but the "working copy" is ambiguous IMHO.
>> What working copy? The one before or after the update? When I think
>> about a merge during an update I tend to think of the working copy as
>> the _result_ of the merge which is in fact the destination! (i.e. to
>> me "working copy / source" would make more sense than "working copy /
>> destination"). Instead I would suggest using "source" or "update
>> source" (i.e. "source / destination").
>
>
> If working copy is confusing, what about "uncommitted changes"?
>

To me an update modifies the working directory by changing its contents
from a source revision to a target revision. So I think I would prefer
"update source", "source revision", "original revision", "starting
revision" or something the sort.

>> […]
>
> >
>>
>> Could someone make  list of the proposed markers for all commands that
>> require them, so that they can all be seen in one single place and
>> commented on? I think it would make it easier to make sure that all of
>> them are more or less consistent.
>
>
> What about you?

I wish I could but I don't think I have all the related patches.

Angel
Pierre-Yves David - May 16, 2014, 6:56 a.m.
On 05/15/2014 11:44 PM, Angel Ezquerra wrote:
>
> El 16/05/2014 08:29, "Pierre-Yves David" <pierre-yves.david@ens-lyon.org
> <mailto:pierre-yves.david@ens-lyon.org>> escribió:
>  >
>  >
>  >
>  > On 05/15/2014 11:22 PM, Angel Ezquerra wrote:
>  >>
>  >> On Fri, May 16, 2014 at 2:11 AM, Olle <olle.lundberg@gmail.com
> <mailto:olle.lundberg@gmail.com>> wrote:
>  >>>
>  >>>
>  >>>
>  >>>
>  >>> On Thu, May 15, 2014 at 11:05 PM, Durham Goode <durham@fb.com
> <mailto:durham@fb.com>> wrote:
>  >>>>
>  >>>>
>  >>>> On 5/15/14, 4:33 AM, "Antoine Pitrou" <solipsis@pitrou.net
> <mailto:solipsis@pitrou.net>> wrote:
>  >>>>
>  >>>>> On Mon, 12 May 2014 17:47:36 -0700
>  >>>>> Durham Goode <durham@fb.com <mailto:durham@fb.com>> wrote:
>  >>>>>>
>  >>>>>> # HG changeset patch
>  >>>>>> # User Durham Goode <durham@fb.com <mailto:durham@fb.com>>
>  >>>>>> # Date 1399684151 25200
>  >>>>>> #      Fri May 09 18:09:11 2014 -0700
>  >>>>>> # Node ID 2ca6a41546b166ca491537d85729fc3e9c42c01b
>  >>>>>> # Parent  3e64ef576f5da47348903d25727d5e7c6c6a046a
>  >>>>>> update: specify custom conflict markers for update (BC)
>  >>>>>>
>  >>>>>> Add custom conflict markers 'working copy' and 'destination' for
> doing
>  >>>>>> hg update
>  >>>>>> when there are conflicts between your working copy and the
> destination.
>  >>>>>
>  >>>>>
>  >>>>> I find the term "destination" confusing in that context. Why not
>  >>>>> "repository"?
>  >>>>>
>  >>>>> Regards
>  >>>>>
>  >>>>> Antoine.
>  >>>>
>  >>>>
>  >>>> I don¹t think normal users have a great understanding of the
> difference
>  >>>> between the working copy and the repository.  Œdestination¹ at least
>  >>>> differentiates itself from working copy in that the working copy
> is your
>  >>>> files, and destination is where you¹re going, especially since
> this only
>  >>>> shows up during an hg update.
>  >>>>
>  >>> I think this change made it harder to understand merge margers
> (granted i'm
>  >>> used to local/other) destination just confused me and i had to
> re-read the
>  >>> patch description when looking at the test output.
>  >>>
>  >>> If we are going to replace the names, can't we do it with the
> nomenclature
>  >>> used in mercurial, rather than introduce another word *not*
> commonly used in
>  >>> merge markers?
>  >>>
>  >>> working copy/repo seems sensible to me.
>  >>
>  >>
>  >> I also find "working copy / destination" confusing. The destination
>  >> part is more or less fine (although perhaps "target" or "update
>  >> target" would be better) but the "working copy" is ambiguous IMHO.
>  >> What working copy? The one before or after the update? When I think
>  >> about a merge during an update I tend to think of the working copy as
>  >> the _result_ of the merge which is in fact the destination! (i.e. to
>  >> me "working copy / source" would make more sense than "working copy /
>  >> destination"). Instead I would suggest using "source" or "update
>  >> source" (i.e. "source / destination").
>  >
>  >
>  > If working copy is confusing, what about "uncommitted changes"?
>  >
>
> To me an update modifies the working directory by changing its contents
> from a source revision to a target revision. So I think I would prefer
> "update source", "source revision", "original revision", "starting
> revision" or something the sort.

The "local" here is not just a "revision", it is a revision + additional 
changes. Additing "revision" anywhere in the name is going to add a lot 
of confusion.

>  >> […]
>  >
>  > >
>  >>
>  >> Could someone make  list of the proposed markers for all commands that
>  >> require them, so that they can all be seen in one single place and
>  >> commented on? I think it would make it easier to make sure that all of
>  >> them are more or less consistent.
>  >
>  >
>  > What about you?
>
> I wish I could but I don't think I have all the related patches.

If you already deleted the, I'm sure the list archive have them.
Antoine Pitrou - May 16, 2014, 9:21 a.m.
On Thu, 15 May 2014 23:31:06 -0700
Pierre-Yves David <pierre-yves.david@ens-lyon.org> wrote:
> 
> 
> On 05/15/2014 02:18 PM, Antoine Pitrou wrote:
> > On Thu, 15 May 2014 21:05:53 +0000
> > Durham Goode <durham@fb.com> wrote:
> >>
> >> I don¹t think normal users have a great understanding of the difference
> >> between the working copy and the repository.  Œdestination¹ at least
> >> differentiates itself from working copy in that the working copy is your
> >> files, and destination is where you¹re going, especially since this only
> >> shows up during an hg update.
> >
> > I'm not sure how someone can use hg without understanding the
> > difference between working copy and repository.
> 
> You will be very surprise about the very thin amount of knowledge of 
> average user.

But how can they make sense of the word "destination"?
At least "repository" is crystal clear and unambiguous for someone who
knows a minimum about hg.

Regards

Antoine.

Patch

diff --git a/mercurial/hg.py b/mercurial/hg.py
--- a/mercurial/hg.py
+++ b/mercurial/hg.py
@@ -483,7 +483,8 @@ 
     When overwrite is set, changes are clobbered, merged else
 
     returns stats (see pydoc mercurial.merge.applyupdates)"""
-    return mergemod.update(repo, node, False, overwrite, None)
+    return mergemod.update(repo, node, False, overwrite, None,
+                           labels=['working copy', 'destination'])
 
 def update(repo, node):
     """update the working directory to node, merging linear changes"""
diff --git a/tests/test-merge-revert2.t b/tests/test-merge-revert2.t
--- a/tests/test-merge-revert2.t
+++ b/tests/test-merge-revert2.t
@@ -57,11 +57,11 @@ 
   @@ -1,3 +1,7 @@
    added file1
    another line of text
-  +<<<<<<< local: c3fa057dd86f  - test: "added file1 and file2"
+  +<<<<<<< working copy: c3fa057dd86f  - test: "added file1 and file2"
   +changed file1 different
   +=======
    changed file1
-  +>>>>>>> other: dfab7f3c2efb - test: "changed file1"
+  +>>>>>>> destination:  dfab7f3c2efb - test: "changed file1"
 
   $ hg status
   M file1