[issue2235] default behaviour of update shoul not be merge

[Matt Mackall]

On Sat, Jun 12, 2010 at 02:23:18PM +0200, Peter Arrenbrecht wrote:
> On Sat, Jun 12, 2010 at 2:20 PM, Sune Foldager <cryo at cyanite.org> wrote:
> > On 2010-06-12 14:10, Gabor Szelei wrote:
> >>
> >> New submission from Gabor Szelei<gabor.szelei at birdstep.com>:
> >>
> >> Update should not merge uncommitted changes as default.
> >> If merge fails uncommitted changes would be lost.
> >> update should behave like update -c by default.
> >
> > Uncommitted changes aren't lost, as the original files are saved (with .orig
> > suffix). Still, it might be worth discussing if we should rather assume -c
> > by default and have an -m option.

Sune, this message didn't connect with the BTS user..
 
> +1
> -parren

..which is just as well, because this falls pretty squarely in the
category of long-standing behavior that won't change.

Look, if I started Mercurial over, there are a lot of little things I would
have done differently. And if Mercurial were a different type of tool,
I might make some of those changes today. This might be even be one of them.

But Mercurial is an SCM and that means it's a) a tool people place a
huge amount of trust in b) make a long-term investment in and c) build
lots of fragile habits and automation around. And that means we don't change
things that don't need changing because it's more important not to
upset the people heavily invested in stability than to please new
users.

This feature was 'inherited' from CVS and has survived five years of
new users without significant complaint. That's five years of evidence
that this feature doesn't need changing and five years of users who
now expect that behavior because it's convenient. So now it's basically
set in stone _even if better behaviors are known to exist_.

The point of this rant: I really wish more of the core developers
would internalize "backwards compatibility matters" because I'm
getting really worn out being the only one carrying this flag.

...

That said, that doesn't mean we can't improve hg. For instance, if we
sit down and think about all the ways that the current update command
is broken, we can gather those all into a new command with better
behavior and migrate to it over time (though the old command will
obviously stay around forever). For one thing, the name could be
better: n00bs routinely can't figure out that you can check out -old-
versions with update.

-- 
Mathematics is the supreme nostalgia of our time.