[PATCH 5 of 6] hg: add updatetotally skipupdate to examine destination before actual update
pierre-yves.david at ens-lyon.org
Sat Mar 19 14:19:57 EDT 2016
On 03/12/2016 04:02 AM, FUJIWARA Katsunori wrote:
> 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".
Okay I see why this is useful (could you plese update the docstring to
reflect that?) and this seems sensible to be able to avoid the double
dest computation (and therefore double locking).
I checked patch 6 and I see why this need to be a function (rebase issue
different message in this case) but this feel very strange to me. How
could `hg pull` fair in this case?
Lets chat about it at the sprint
More information about the Mercurial-devel