On Wed, Oct 24, 2012 at 11:41 PM, Johannes Schindelin
<johannes.schinde...@gmx.de> 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

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

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:


cat > git-remote-foo <<-\EOF

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

read l
echo $l 1>&2
echo ? refs/heads/master

read l
echo $l 1>&2

while read l; do
        echo $l 1>&2
        test "$l" == 'done' && exit

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 ==
feature done
mark :1
data 5

reset refs/heads/master
commit refs/heads/master
mark :2
author Felipe Contreras <felipe.contre...@gmail.com> 1351140987 +0200
committer Felipe Contreras <felipe.contre...@gmail.com> 1351140987 +0200
data 15
Initial commit
M 100644 :1 Test

== foo ==
feature done
reset refs/heads/foo
from :2


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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to