[PATCH 0 of 8 RFC] Add guard option to update, which aborts if the update is unsafe

[Laurens Holst]

Hi,

Op 22-12-2011 2:05, Matt Mackall schreef:
>> As for -c, honestly I don’t really see the use of it.
> It's a "look before you leap" option, just like -g.
>
> And just like -g, when it says "no, you can't do that", you're still
> stuck with "ok, I'd better think hard about my next step: I either need
> to dive in with a plain old update or commit and merge". From this
> perspective, the only difference between --check and --guard is the size
> of the "safe space".

The reason why I said this is, a user will indeed think hard whether to 
update or commits and merge, but he will do this even before he invokes 
hg update. I know I have changes, I know update can mess them up, so why 
do I need a -c flag to make Mercurial mechanically confirm that for me? 
Hence why I think for a front-end user, the value of -c is close to zero 
[1], and I don’t think they use it.

By adding --guard, we give the user a new option, which is to try out 
the update and see if it works out. This wasn’t possible before. If it 
doesn’t, the user faces the choice you mentioned, but at least the user 
will know to expect a conflict (contrary to -c), so he can make a more 
informed choice. This is the value that -g adds.

For comparison, a rollback function for update would fulfill a similar 
purpose and be an alternative to guard.

>>> Also, I think it's a bit problematic in that people are going to ask for
>>> this functionality everywhere merges can happen (pull -u, normal merge,
>>> rebase, graft, etc.)
>> Well only the ‘abort the merge if there are conflicts’ part would apply
>> to those; this is really centred around the problems around unversioned
>> changes described above and does more than that.
> Remember, your goal is to convince me to care about your feature. If I
> say "perhaps there's some generic utility here that I actually might
> care about", then you should say "yes, let me think more about that",
> not "no, this is unrelated." People do in fact ask about "merge only if
> safe" on a regular basis and I'm much more interested in code that
> serves multiple goals.

Ok that’s interesting to hear. This change could facilitate that I 
think, after the code is moved to the correct place.

I need to think a little about whether it is ok to use the same term 
(guard) for that, as there is a slight difference in semantics for 
regular merges (as bullet point 3 reversibility does not apply).

> And anyway: pull --update? I'm guessing you didn't actually think about
> that at all. I'm absolutely not going to do a pull --update-guard (yuck)
> but it doesn't take a crystal ball to know people ARE going to want an
> equivalent if your feature is even slightly loved. So tell me what the
> plan for that is before I commit to painting us into that particular
> corner.

Hmm, possibilities that I can see:

1. Add -g/--guard option to pull. Could also interact with --rebase. See 
the above comment about semantics... But can probably get away with it.

2. Configure the default behaviour of update through a setting. May 
exceed the room settings have for altering behaviour?

3. That --update-guard thing or some variation. Not an option unless the 
variation is really clever.

4. Not support it. Note that -c is not available as an option on pull 
either.

Did I miss anything? Of these, I think option 1 is by far the most 
likely choice.

~Laurens

[1] I do think there is practical use for --check in tools. One example 
I could think of, I should use it in the update that’s on the incoming 
hook of my two website repositories. That way if I make any local 
changes directly on the working copy files through SSH, I would be sure 
that pages never get broken by a conflict.

-- 
~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
Laurens Holst, developer, Utrecht, the Netherlands
Website: www.grauw.nl. Working @ www.roughcookie.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4332 bytes
Desc: S/MIME cryptografische ondertekening
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111224/cf08b36c/attachment.bin>