Subject: Re: git archive without path

From: Michael J Gruber <[email-masked]>
Date: Mon, 30 Nov 2009 14:05:02 +0100

Dmitry Potapov venit, vidit, dixit 30.11.2009 13:32:
> 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