Andy Parkins schrieb:
quoted text
> On Monday 2007, April 09, René Scharfe wrote:
> 
>> I agree with (1) and (3), meaning that we are free to change the
>> behaviour.  I don't agree with (2), though.  I'd find it strange if
>> changing the working directory wouldn't change the archive contents.
>>
>> We should keep consistency with the rest of git here.  Since
>> git-archive is just a fancy git-ls-tree, I think we should mirror its
>> behaviour with respect to the working directory.  (Which is what the
>> current code does. Modulo bugs, of course.)
> 
> I don't agree with the supposition that git-archive is a fancy 
> git-ls-tree.  If it were, then you'd be right.  It's not though.  It's 
> more like a git-read-tree or git-checkout-index; those both don't care 
> where you are in the working tree.
>
> Argument 1)
> git-archive should have nothing to do with a working tree in fact; it's 
> perfectly reasonable to expect that it would work in a bare repository 
> in fact - that's almost the definition of a command that shouldn't be 
> working directory aware.

It works in bare repositories, as does git-ls-tree.  There the question
of what to do in subdirectories doesn't even come up, because there are
none. :)

But just because it works in situations where there are no
subdirectories that doesn't mean that it has to ignore them in other
situations.

quoted text
> Argument 2)
> Consider the --remote option.  What "working path" should be relevant 
> when "--remote" is passed?  For consistency, git-archive should always 
> refer to the repository root.

'git-archive --remote' passes the options to the remote system, ignoring
the local working directory.  What matters in this case is the working
directory on the remote end, which is the repository's root.

But just because there is currently no way (that I know of) to change
the working directory on the remote end that doesn't mean the command
needs to ignore the working directory when operating locally, where it
can be changed easily.

quoted text
> Argument 3)
> git-archive is similar to other VCS's "export" command; and for those 
> the export command in it's default form will work without a local 
> checkout and they export from the repository root.

OK, I haven't seen other tools, so I can't really comment on them.
git-archive _does_ work without a checkout, though.

quoted text
> Argument 4)
> What if the repository has multiple root commits, similar to git's html 
> and todo branches.  Now, use git-archive and reference one of those 
> commits.  The working directory you're in now has no relevance at all 
> to the commit your targeting - it need not even exist.  The same 
> problem exists of course if you are now in a directory that didn't 
> exist in the past.

Yes, that's true; git-archive will tell you that your current working
directory is untracked in that case.  (git-ls-tree in that case lists:
nothing.)  But if you want to create a full archive you need to be in
the repository's root directory anyway, so this is no new issue.

What it comes down to is the decision between consistency with third
party export tools or with its (implementation-wise) brother
git-ls-tree, between the convenience of not needing to care where in the
repository you are or the convenience of being able to let the working
directory determine the file set that ends up in the archive.

I'd rather keep it consistent from a technical, implementation point of
view and not care too much about other export tools, and I like my
working directory to influence which files I'm working with.  Working
directory sensitivity is just another input method, like parameters and
environment variables.  I still see no benefit in removing it.  But
perhaps I'm in a rut, unable to see the difficulties with this way to work.

Re(not getting it ;-)né
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html