Re: git archive without path

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Nov 30, 2009, 13:05 UTC
Message-ID: <4B13C2FE.3040707@drmicha.warpmail.net>
In-Reply-To: <20091130123203.GA11235@dpotapov.dyndns.org>

Dmitry Potapov venit, vidit, dixit 30.11.2009 13:32:

Show 19 quoted lines

> Hi!
> 
> I have never run "git archive" inside of a subdirectory but somehow I
> have always assumed that it creates an archive containing all files in
> it regardless the current directory. In fact, the git-archive man page
> says so:
> 
> path
>     If one or more paths are specified, include only these in the
>     archive, otherwise include all files and subdirectories.
> 
> 
> But it turned out that "git archive" works as "git archive .", i.e.
> adds files starting with the current directory. Is any rational for
> this behavior? It smells to me like a bug rather than a feature. I
> cannot imagine wanting to create archive containing just part of the
> whole repository just because he happened to be in that directory,
> and documentation clearly says that all files should be added unless
> one or more paths are specified.

Depends on the definition of "all" :)

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. I expect that we'll have a gradual migration path towards a "full-tree" default, but that is just my personal interpretation of the current "battle". In the short term the best that we can hope for is a consistent, convenient notation which enforcers a specific behaviour, such as "/" (non-existent) versus "." (existent).

Cheers, Michael