Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
- From
Felipe Contreras <felipe.contreras@gmail.com>
- Date
- Nov 12, 2012, 16:28 UTC
- Message-ID
- <CAMP44s0WH-P7WY4UqhMX3WdrrSCYXUR9yCgsUV+mzLOCK5LkHQ@mail.gmail.com>
- In-Reply-To
- <1352642392-28387-16-git-send-email-felipe.contreras@gmail.com>
On Sun, Nov 11, 2012 at 2:59 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
Show 44 quoted lines
> They have been marked as UNINTERESTING for a reason, lets respect that.
>
> Currently the first ref is handled properly, but not the rest, so:
>
> % git fast-export master ^master
>
> Would currently throw a reset for master (2nd ref), which is not what we
> want.
>
> % git fast-export master ^foo ^bar ^roo
> % git fast-export master salsa..tacos
>
> Even if all these refs point to the same object; foo, bar, roo, salsa,
> and tacos would all get a reset, and to a non-existing object (invalid
> mark :0).
>
> And even more, it would only happen if the ref is pointing to exactly
> the same commit, but not otherwise:
>
> % git fast-export ^next next
> reset refs/heads/next
> from :0
>
> % git fast-export ^next next^{commit}
> # nothing
> % git fast-export ^next next~0
> # nothing
> % git fast-export ^next next~1
> # nothing
> % git fast-export ^next next~2
> # nothing
>
> The reason this happens is that before traversing the commits,
> fast-export checks if any of the refs point to the same object, and any
> duplicated ref gets added to a list in order to issue 'reset' commands
> after the traversing. Unfortunately, it's not even checking if the
> commit is flagged as UNINTERESTING. The fix of course, is to do
> precisely that.
>
> The current behavior is most certainly not what we want. After this
> patch, nothing gets exported, because nothing was selected (everything
> is UNINTERESTING).
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>And here's yet another reason why this is obviously correct that I just found:
% git fast-export --use-done-feature --{import,export}-marks=.git/hg/origin/marks-git ^refs/hg/origin/branches/default ^refs/hg/origin/bookmarks/test6 refs/heads/test6 ^refs/hg/origin/bookmarks/master ^refs/hg/origin/bookmarks/test feature done reset refs/hg/origin/bookmarks/test from :4
reset refs/heads/test6 from :14
done
What is that refs/hg/origin/bookmarks/test doing there?
transport-helper does use a fast-export command like that to specify precisely what refs should be *IGNORED*, and yet fast-export will throw a reset for a ref that has been marked as UNINTERESTING. So, the receiving end in the helper will see a reset for a ref that it explicitly said was marked as outside it's refspec realm:
refspec refs/heads/*:refs/hg/origin/bookmarks/*
What is remote-hg supposed to do with 'refs/hg/origin/bookmarks/test'? There's nothing that can be done, it's a bug in fast-export that such a thing was exported in the first place. And the reason it happens is that another ref happens to be pointing to the same object, (in this case refs/hg/origin/branches/default)
So yeah, the patch is good.
Of course, transport-helper shouldn't even be specifying the negative (^) refs, but that's another story.
Cheers.
-- Felipe Contreras