Why bare 'hg update' needs behaviour change

[James Reynolds]

I brought this topic up a few months than ago.

I also wrote a patch, unsubmitted, that did what I proposed. (Also, why
can't mercurial use pull requests, rather then email patches? Do any
organizations really work by emailing patches around? Maybe if mercurial
did, users would realize the problems with bookmarks in practice)

1. Added a setting that changed the behavior of hg up to be predictable.
2. The setting is opt-in.  No setting =old behavuor.

I liked this because it opened the door to a reasonable depreciation policy.

However, two things happened.

1. The "change" camp felt this was too much work in large teams (to add
just one line item to an hgrc).

1.b the "remain" camp are purists and like the behavior as is and prefer we
should all be purists.

2. The small minority remaining then went down the rabbit hole of "let's
name this setting variable!"

That's about when I gave up.

Anyway, I'm happy to submit the patch if there is interest.

James


On Dec 21, 2016 3:04 AM, "David Demelier" <demelier.david at gmail.com> wrote:

> 2016-12-20 23:25 GMT+01:00 Marcin Kasperski <Marcin.Kasperski at mekk.waw.pl>
> :
> > Leaving apart the general design discussion: in such a scenario I would
> > seriously consider using SINGLE named branch, called experimental (and
> > various bookmarks and heads on this branch to mark actual work items) –
> > plus merging finished work to default (and merging default back to
> > experimental to keep it up to date). This avoild pollution of maaany
> > named branches, but clearly separates development from stable and keeps
> > hg update sane.
> >
>
> To me default is already a branch for development. It's even
> recommended to develop on this branch. I use stable branch and
> releases branches where only "safe" revisions are committed/pushed.
>
> > Regarding general thing, I think that there is more promise in making
> > branches sane (able to fade away, then disappear) than in making
> > bookmarks sane (able to stay where they should and cooperate with update
> > properly). Those sane branches are to be called topics IIRC, not sure
> > how far advanced is the work on them.
>
> Topics are nice but you can't share them unless you make a
> non-publishing server which to me is not an option.
>
> --
> Demelier David
> _______________________________________________
> Mercurial mailing list
> Mercurial at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20161221/4ddf56da/attachment-0002.html>