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