Re: git archive without path

From: Dmitry Potapov <dpotapov@gmail.com>
Date: Nov 30, 2009, 15:45 UTC
Message-ID: <37fcd2780911300745r79c0cb54ifc3af5e79bb963e4@mail.gmail.com>
In-Reply-To: <4B13C2FE.3040707@drmicha.warpmail.net>

On Mon, Nov 30, 2009 at 4:05 PM, Michael J Gruber <git@drmicha.warpmail.net> wrote:

>
> Depends on the definition of "all" :)

I don't think it caries any restriction clause in this case....

Show 11 quoted lines

>
> In fact: Two mighty powers are fighting right now for the primacy in the
> Land of the Git, and both carry the name "consistency" on their flags.
> One is the "order of the consistency of generations", also named
> "backwards compatibility", and one is the "order of the consistency of
> commands", also named "user experience".
>
> Many commands have different defaults with respect to how they behave in
> a subdirectory (compare status to ls-files, e.g.), and the discussion
> about how to best change that are underway, most prominently in the case
> of git grep.

Well, "order of the consistency" is a noble cause, but I don't think the situations are comparable. The man page for git-grep has never claimed that git grep works on all files. Also, git grep works on the working tree by default, so defaulting to the current working directory at least makes some sense. I cannot say the same about git-archive, which only works on the repository and if I specified some revision without any path then I expect to have the whole archive not some part of it just because I happened to be in some subdirectory.

So, in the case of git-grep, we speak about changing the behavior that was well-known, often used, and documented as such. On contrast, git-archive documented as including all files if path is not specified.

Dmitry