On Wed, Oct 24, 2012 at 8:08 PM, Jonathan Nieder <jrnie...@gmail.com> wrote:
> Hi Felipe,
>
> Felipe Contreras wrote:
>
>> This test is completely wrong.
>>
>> 1) Where are the marks file?
>> 2) master..master shouldn't export anything
>
> Why shouldn't master..master export anything?  It means "update the
> master ref; we already have all commits up to and including master^0".

Does it mean that? I don't think so, but let's assume that's the case.

We don't have all those commits; without the marks we have nothing. Or
what exactly do you mean by 'we'?

Go to your git.git repository, and run this:

% git git init /tmp/git
% git fast-export master^..master | git --git-dir=/tmp/git/.git fast-import

What do you expect? I expect a single commit, and that's what we get,
now do the same with 'master..master', what do you expect?

How about 'git fast-export ^master'? Do you expect to get anything
there? Or what about '^master master'?

Without marks these idioms don't make any sense. Now lets assume that
marks were meant to be there.

If 'master..master' is supposed to update master, then what is
'master' supposed to do?

% git fast-export --{im,ex}port-marks=/tmp/marks master..master

vs.

% git fast-export --{im,ex}port-marks=/tmp/marks master

Either way, my patch will make 'master..master' throw a reset (if the
marks are present, I haven't tried without them), I don't think it
should, but that's a different story, and a different patch fix.

> The underlying problem is that fast-export takes rev-list arguments as
> parameters, which is unfortunately only an approximation to what is
> really intended.  Ideally it would separately take a list of refs to
> import and rev-list arguments representing the commits we already
> have.

The commits we already have (exported before) are stored in the marks.
Maybe we can store the refs there as well, but that would not change
the semantics of refspecs, nor the fact that we need the marks.

Cheers.

-- 
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