Patchwork debugsetparent: document one common caveat specifically

login
register
mail settings
Submitter Martin von Zweigbergk
Date Feb. 25, 2015, 7:48 p.m.
Message ID <f4138e611d14b8e9bc9e.1424893697@martinvonz.mtv.corp.google.com>
Download mbox | patch
Permalink /patch/7829/
State Accepted
Headers show

Comments

Martin von Zweigbergk - Feb. 25, 2015, 7:48 p.m.
# HG changeset patch
# User Martin von Zweigbergk <martinvonz@google.com>
# Date 1424893154 28800
#      Wed Feb 25 11:39:14 2015 -0800
# Node ID f4138e611d14b8e9bc9e2dc8417a094ddb83173a
# Parent  e7785573a4af258101d0cc0b0947a6de65273096
debugsetparent: document one common caveat specifically

After calling debugsetparent, it's quite common that status is
incorrect. The command's help text already says that it should be used
with care, but let's describe this caveat explicitly since it's
probably the most common one.
Pierre-Yves David - March 2, 2015, 8:45 p.m.
On 02/25/2015 07:48 PM, Martin von Zweigbergk wrote:
> # HG changeset patch
> # User Martin von Zweigbergk <martinvonz@google.com>
> # Date 1424893154 28800
> #      Wed Feb 25 11:39:14 2015 -0800
> # Node ID f4138e611d14b8e9bc9e2dc8417a094ddb83173a
> # Parent  e7785573a4af258101d0cc0b0947a6de65273096
> debugsetparent: document one common caveat specifically

Good step forward, pushed to the clowncopter.

Maybe we should also point directly to the `debugrebuilddirstate` command ?
Martin von Zweigbergk - March 2, 2015, 9:47 p.m.
On Mon, Mar 2, 2015 at 12:45 PM Pierre-Yves David <
pierre-yves.david@ens-lyon.org> wrote:

>
>
> On 02/25/2015 07:48 PM, Martin von Zweigbergk wrote:
> > # HG changeset patch
> > # User Martin von Zweigbergk <martinvonz@google.com>
> > # Date 1424893154 28800
> > #      Wed Feb 25 11:39:14 2015 -0800
> > # Node ID f4138e611d14b8e9bc9e2dc8417a094ddb83173a
> > # Parent  e7785573a4af258101d0cc0b0947a6de65273096
> > debugsetparent: document one common caveat specifically
>
> Good step forward, pushed to the clowncopter.
>
> Maybe we should also point directly to the `debugrebuilddirstate` command ?
>
>
Good idea. I think it should work when not merging. I had to try it to see
how it behaved during merges. Unfortunately, it doesn't seem to work. It
resets the parents. The best I can think of is 'hg files | xargs touch -c'.
Do you think it's still worth adding a pointer to debugrebuilddirstate for
non-merges?
Pierre-Yves David - March 20, 2015, 12:32 a.m.
On 03/02/2015 01:47 PM, Martin von Zweigbergk wrote:
>
>
> On Mon, Mar 2, 2015 at 12:45 PM Pierre-Yves David
> <pierre-yves.david@ens-lyon.org <mailto:pierre-yves.david@ens-lyon.org>>
> wrote:
>
>
>
>     On 02/25/2015 07:48 PM, Martin von Zweigbergk wrote:
>      > # HG changeset patch
>      > # User Martin von Zweigbergk <martinvonz@google.com
>     <mailto:martinvonz@google.com>>
>      > # Date 1424893154 28800
>      > #      Wed Feb 25 11:39:14 2015 -0800
>      > # Node ID f4138e611d14b8e9bc9e2dc8417a09__4ddb83173a
>      > # Parent  e7785573a4af258101d0cc0b0947a6__de65273096
>      > debugsetparent: document one common caveat specifically
>
>     Good step forward, pushed to the clowncopter.
>
>     Maybe we should also point directly to the `debugrebuilddirstate`
>     command ?
>
>
> Good idea. I think it should work when not merging. I had to try it to
> see how it behaved during merges. Unfortunately, it doesn't seem to
> work. It resets the parents. The best I can think of is 'hg files |
> xargs touch -c'. Do you think it's still worth adding a pointer to
> debugrebuilddirstate for non-merges?

probably ? With a mention that this is broken during merge, especially 
in the debugrebuilddirstate documentation itself.

Patch

diff -r e7785573a4af -r f4138e611d14 mercurial/commands.py
--- a/mercurial/commands.py	Wed Feb 18 16:45:16 2015 -0800
+++ b/mercurial/commands.py	Wed Feb 25 11:39:14 2015 -0800
@@ -2893,7 +2893,8 @@ 
     """manually set the parents of the current working directory
 
     This is useful for writing repository conversion tools, but should
-    be used with care.
+    be used with care. For example, neither the working copy nor the dirstate
+    is updated, so file status may be incorrect after running this command.
 
     Returns 0 on success.
     """