fast-export: don't handle uninteresting refs
commit49266e8a11cffa1bb41217021470e33d26109bb2
authorFelipe Contreras <felipe.contreras@gmail.com>
Wed, 28 Nov 2012 22:23:59 +0000 (28 23:23 +0100)
committerJunio C Hamano <gitster@pobox.com>
Mon, 3 Dec 2012 17:52:08 +0000 (3 09:52 -0800)
tree5b2575c0b5d22a697d91bb85c6f8e3badbc36a8e
parent9ff10fc86989940eb2c016511c293bc0ac50e6f6
fast-export: don't handle uninteresting refs

They have been marked as UNINTERESTING for a reason, lets respect
that.  Currently the first ref is handled properly, but not the
rest.  Assuming that all the refs point at the same commit in the
following example:

  % git fast-export master ^uninteresting ^foo ^bar
  reset refs/heads/bar
  from :0

  reset refs/heads/foo
  from :0

  reset refs/heads/uninteresting
  from :0

  % git fast-export ^uninteresting ^foo ^bar master
  reset refs/heads/master
  from :0

  reset refs/heads/bar
  from :0

  reset refs/heads/foo
  from :0

Clearly this is wrong; the negative refs should be ignored.

After this patch:

  % git fast-export ^uninteresting ^foo ^bar master
  # nothing
  % git fast-export master ^uninteresting ^foo ^bar
  # nothing

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 check it.

However, in order to do it properly we need to get the UNINTERESTING
flag from the command line, not from the commit object, because
"^foo bar" will mark the commit 'bar' uninteresting if foo and bar
points at the same commit.  rev_cmdline_info, which was introduced
exactly to handle this situation, contains all the information we
need for get_tags_and_duplicates(), plus the ref flag. This way the
rest of the positive refs will remain untouched; it's only the
negative ones that change in behavior.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/fast-export.c
t/t5801-remote-helpers.sh
t/t9350-fast-export.sh