On Wed, Oct 24, 2012 at 11:41 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi, > > On Wed, 24 Oct 2012, Felipe Contreras wrote: > >> 2) master..master shouldn't export anything > > The underlying issue -- as explained in the thread -- is when you want to > update master to a commit that another ref already points to. In that case > no commits need to exported, but the ref needs to be updated nevertheless. > > We just wrote the test in the most convenient way, no need to complicate > things more than necessary. That test cannot work, and it shouldn't work. You say you want to 'update master to a commit that another ref already points to'. What other ref? If you want to update master, this is what you do: % git fast-export master What do you expect 'git fast-export master..master' to export? This? --- reset refs/heads/master from $(git rev-parse master) --- What is a remote helper supposed to do with a SHA-1? Nothing, a git SHA-1 is useless to say, a mercurial remote helper. To make sense of it you would need to access the git repository and get the commit object, and that's defeating the purpose of a fast exporter. No, that's not what you want. But at this point there's only one ref in the picture, you said 'update master to a commit that another ref already points to', but there's only one ref, where is the other ref? Maybe your test should do this: % git fast-export foo master But wait, that actually works, except that the output will be nothing close what you expected before, we would get all the commits and files that constitute 'foo', which is actually useful, and what we expect from fast-export, and in addition, master will be updated to the right ref. No, the problem is not only 'update master to a commit that another ref already points to', but that this happens in two different commands, and that can only be done with marks, just like the test I proposed. The original test doesn't expose the problem we are trying to solve, and it shouldn't work anyway. Moreover, what we eventually want to do is support the transport helpers, so how about you run this: --- #!/bin/sh cat > git-remote-foo <<-\EOF #!/bin/sh read l echo $l 1>&2 echo export echo refspec refs/heads/*:refs/foo/origin/* test -e /tmp/marks-git && echo *import-marks /tmp/marks-git echo *export-marks /tmp/marks-git echo read l echo $l 1>&2 echo ? refs/heads/master echo read l echo $l 1>&2 while read l; do echo $l 1>&2 test "$l" == 'done' && exit done EOF chmod +x git-remote-foo export PATH=$PWD:$PATH rm -f /tmp/marks-git ( git init test cd test echo Test >> Test git add --all git commit -m 'Initial commit' git branch foo echo "== master ==" git push foo::test master echo "== foo ==" git push foo::test foo ) --- I get this output with my patch: --- [master (root-commit) b159eff] Initial commit 1 file changed, 1 insertion(+) create mode 100644 Test == master == capabilities list export feature done blob mark :1 data 5 Test reset refs/heads/master commit refs/heads/master mark :2 author Felipe Contreras <felipe.contreras@xxxxxxxxx> 1351140987 +0200 committer Felipe Contreras <felipe.contreras@xxxxxxxxx> 1351140987 +0200 data 15 Initial commit M 100644 :1 Test done == foo == capabilities list export feature done reset refs/heads/foo from :2 done --- Hey, did you see that? 'foo' is updated, both 'master' and 'foo' point to the same object. What is the problem? -- Felipe Contreras -- 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