[PATCH 5 of 6] hg: add updatetotally skipupdate to examine destination before actual update

FUJIWARA Katsunori foozy at lares.dti.ne.jp
Sat Mar 12 07:02:53 EST 2016

At Fri, 11 Mar 2016 23:14:04 +0000,
Pierre-Yves David wrote:
> On 03/11/2016 07:41 PM, FUJIWARA Katsunori wrote:
> > # HG changeset patch
> > # User FUJIWARA Katsunori <foozy at lares.dti.ne.jp>
> > # Date 1457724942 -32400
> > #      Sat Mar 12 04:35:42 2016 +0900
> > # Node ID 4ec341fd8f85ca07dc6f99d82c155e9d559be390
> > # Parent  231ea15298afd3e1a4347791d4eb904742bf8243
> > hg: add updatetotally skipupdate to examine destination before actual update
> >
> > This is useful for client, which wants to show any message before
> > (abortion of) actual updating, for example.
> Patch 1-4 are on the clowncopter. Thanks
> I'm deeply confused about why this is useful and why the complexity is 
> worth it. Can you elaborate on this?

"hg pull --rebase" and "hg fetch" skip actual updating procedure (=
merge.update()), if update destination is current parent itself.

(this series doesn't care "hg fetch", because corresponded code path
has issue and inefficiency to be fixed in my next series :-))

Because "hg pull --rebase" also shows "nothing to rebase" or "nothing
to rebase - updating instead" message according to the destination of
update, just introducing "skip if update isn't needed" flag isn't
useful for this purpose (at least, if current behavior should be

If invoking destupdate() twice is acceptable redundancy, this change
isn't needed.

BTW, there are commands below, which imply bare "hg update" action at
the end of them, and some of them omit updating procedure (including
hook invocation), if there is no descendant.

                     update to     inform about
  command            parent itself omission
  ================== ============= ============
  fetch (*1)           x            x
  pull --rebase (*1)   x            o
  pull --update        o            -
  unbundle --update    o            -

(*1) work as bare "hg update", only if there is no another branch head

Which is preferable behavior ? (or should we keep current behavior of
them ?)

IMHO, omission of updating to parent itself seems reasonable also for
pull/unbundle, because '--update' option of them is described as
"update to NEW branch head if changesets were pulled/unbundled".

> -- 
> Pierre-Yves David

[FUJIWARA Katsunori]                             foozy at lares.dti.ne.jp

More information about the Mercurial-devel mailing list