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

[Matt Mackall]

On Sat, 2011-12-24 at 20:39 +0100, Laurens Holst wrote:
> 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.

So what if we stored every "conflict" that --guard would care about in
the resolve "database", such that you could revisit/back out of the
conflict? This has actually been a goal for a while.

> >>> 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.

Well.. meh. Accumulating non-pull options on pull is ugly. But not
ruling it out entirely. 

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

Yeah, that's too far out there.

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

Worst of the lot.

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

Indeed, and no one's asked for it: no one cares about --check much.

> 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.
> 


-- 
Mathematics is the supreme nostalgia of our time.