Rename info lost after repeated amends
Pierre-Yves David
pyd at fb.com
Thu Apr 17 15:01:50 UTC 2014
Did you tried it again with the Julien fix?
On 04/17/2014 10:50 AM, Greg Ward wrote:
> On 17 April 2014, To evolve-testers at selenic.com said:
>> I just got bitten by a bug that I think I have seen before: I'm
>> working on a single changeset that reorganizes a project, so there are
>> a lot of plain renames and a lot of renames that include small changes
>> (update imports, etc.).
> A bit more detail: it appears that pure renames are not mangled by
> evolve. But a rename with a diff is mangled: it simply becomes
> add/remove of unrelated files. Or at least that's what I now suspect
> from manually inspecting the predecessor/successor graph.
>
>> I believe I can
>> workaround the problem with "hg rename --after" and another "hg
>> amend", but yuck.
> Actually, that didn't work. "hg rename --after OLD NEW" requires
> that OLD still be present in the working dir.
>
> What I ended up doing is creating a brand-new reorg changeset that had
> no relationship with the mangled one. Here's the idea:
>
> hg update $oldrev
>
> where $oldrev is the parent of my bad amended changeset, i.e. my
> project without any of my reorganization changes. Then I want to apply
> all the reorg changes, ignoring copy information:
>
> hg revert -a -r $badrev
>
> where $badrev is the latest amended changeset, i.e. the desired end
> state of the project. It's "bad" because the rename information has
> been mangled by evolve.
>
> At this point my working dir looks like
>
> $ hg status -C
> A newname
> R oldname
>
> (many times over). I need to make newname a rename of oldname. But "hg
> rename --after" won't work, because oldname does not exist. Hmmmmm.
>
> The trick was to make the dirstate look like it did after "hg up
> $oldrev", but keep the working dir looking like $badrev:
>
> removed=`hg status -rn`
> hg revert $removed
> rm $removed
> added=`hg status -an`
> hg forget $added
>
> Now my working dir looks like
>
> $ hg status -C
> ? newname
> ! oldname
>
> Perfect! This is exactly the use case for
>
> $ hg addremove -s 80
>
> and now things look right:
>
> $ hg status -C
> A newname
> oldname
> R oldname
>
> So now I can commit a brand-new changeset with my reorg as it should
> have looked from the start.
>
> I would not expect this workaround to occur to anyone who has not
> spent a lot of time hacking on Mercurial. ;-)
>
> Greg
> _______________________________________________
> Evolve-testers mailing list
> Evolve-testers at selenic.com
> http://selenic.com/mailman/listinfo/evolve-testers
More information about the Evolve-testers
mailing list