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

[Matt Mackall]

On Thu, 2011-12-22 at 01:24 +0100, Laurens Holst wrote:
> Op 21-12-2011 21:51, Matt Mackall schreef:
> > On Wed, 2011-12-21 at 20:45 +0100, Laurens Holst wrote:
> >> Hi,
> >>
> >> If you update while you are working on some changes, when there are conflicts
> >> you are bothered with conflict markers or merge tools and prompts and resolve
> >> commands and all that. Your code that was in a working state will no longer work
> >> until you have resolved the conflicts. Worse, it scatters your focus. In such
> >> case you may rather want to postpone the update until you are done, or commit
> >> your changes first and do a proper merge.
> >>
> >> This set of changes adds a --guard/-g flag that aborts the update if it touches
> >> any files that are modified locally and could potentially cause conflicts. The
> >> update could still break your code, however going back to a working version will
> >> now simply be a matter of updating back to the original revision. Later in the
> >> series it also performs tentative merges to see if there are conflicts, and
> >> only aborts when there is an actual conflict.
> > I'm not completely sold on its value, I think it needs more discussion.
> 
> The driving factor here is really that because you have unversioned 
> changes in your local working copy, Mercurial should tread extra 
> carefully. The default behaviour of update is I think too destructive in 
> some situations, and I would like to have access to a safer version.
> 
> The problem with update (also in SVN) is that a dirty working copy isn’t 
> the right environment for merging.

FYI, we inherited it from the same place SVN did: CVS.

>  Conflicts break your working but 
> unfinished code until you’ve resolved them, and force you from ‘focused 
> coding’ mode into ‘merging and dealing with other people’s changes’ 
> mode, without a way for the user to say ‘oh hey let’s not do this’. And 
> if you chicken out half-way and press ctrl-c you end up even worse with 
> half-merged code.
> 
> However the ability to update in a dirty working copy is still a 
> convenience that we want to have. So what this patch series does is, it 
> updates if it can do so without too much risk (no conflicts), and gives 
> you an easy way to go back if it turns out that it still doesn’t work.
>
> > This seems to fill an intermediate space between -c/--check and the
> > default behavior.
> 
> Well regarding that, I was actually thinking that this would be nice 
> default behaviour :), but I didn’t really want to bring that up eheh. 

Negligible probability of that happening without changing the project
name.

> Also a configuration option to enable this crossed my mind, but meh. I 
> can settle for typing a flag when I’m working on code and don’t want it 
> to merge.

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

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

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.

-- 
Mathematics is the supreme nostalgia of our time.