This happens only when the corresponding commits are not exported in
the current fast-export run. This can happen either when the relevant
commit is already marked, or when the commit is explicitly marked
as UNINTERESTING with a negative ref by another argument.
This breaks fast-export based remote helpers, as they use marks
files to store which commits have already been seen. The call graph
is something as follows:
$ # push master to remote repo
$ git fast-export --{im,ex}port-marks=marksfile master
$ # make a commit on master and push it to remote
$ git fast-export --{im,ex}port-marks=marksfile master
$ # run `git branch foo` and push it to remote
$ git fast-export --{im,ex}port-marks=marksfile foo
When fast-export imports the marksfile and sees that all commits in
foo are marked as UNINTERESTING (they have already been exported
while pushing master), it exits without doing anything. However,
what we want is for it to reset 'foo' to the already-exported commit.
Either way demonstrates the problem, and since this is the most
succint way to demonstrate the problem it is implemented by passing
master..master on the commandline.
Signed-off-by: Sverre Rabbelier <srabbelier@xxxxxxxxx>
---
t/t9350-fast-export.sh | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/t/t9350-fast-export.sh b/t/t9350-fast-export.sh
index 950d0ff..74914dc 100755
--- a/t/t9350-fast-export.sh
+++ b/t/t9350-fast-export.sh
@@ -440,4 +440,15 @@ test_expect_success 'fast-export quotes pathnames' '
)
'
+cat > expected << EOF
+reset refs/heads/master
+from $(git rev-parse master)
+
+EOF
+
+test_expect_failure 'refs are updated even if no commits need to be exported' '
+ git fast-export master..master > actual &&
+ test_cmp expected actual
+'
+
test_done
--
1.7.8.rc0.36.g67522.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html