Re: [PATCH v3] Support ent:relative_path

From: Junio C Hamano <junkio@cox.net>
Date: May 7, 2007, 00:18 UTC
Message-ID: <7v6475bi69.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0705070110040.4167@racer.site>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 36 quoted lines

> On Sun, 6 May 2007, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> 
>> > On Sat, 5 May 2007, Junio C Hamano wrote:
>> >
>> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> >> 
>> >> >> (a) In a bare repository, I believe 
>> >> >> setup.c:setup_git_directory_gently() determines the prefix to be 
>> >> >> NULL.  This means my patch will see ALL paths as absolute, except 
>> >> >> :../path which will result in an error.
>> >> >
>> >> > My point was that it feels inconsistent to take the current path into 
>> >> > account in one case, but not in the other.
>> >> 
>> >> I do not understand your reasoning.  In a bare repository you cannot 
>> >> even be in a subdirectory to begin with.
>> >
>> > Exactly! That is my point. If you can do it in a working directory, but 
>> > also with a bare repository, I find it highly confusing and inconsistent 
>> > to have different meaning.
>> 
>> Sorry.  Now you confused me further.  I can do:
>> 
>> 	cd Documentation
>>         git diff v1.5.0 v1.5.1 -- git.txt
>> 
>> Is that confusing, inconsistent and bad for the users?
>
> Well, I am partly at fault that you _can_ execute git-diff outside of a 
> repository.
>
> But given the _arguments_ you give to git-diff as above, I'd expect it to 
> actually care about the working directory. IOW I would _not_ expect this 
> to work outside of a working directory (even if it does).

Oh, I was not thinking about "outside of repository" use. I was talking about your earlier "bare repository vs inside worktree vs inside a subdirectory of worktree" point. In a bare repository,

	git diff v1.5.0 v1.5.1 -- Documentation/git.txt

is the only form that makes sense, as you cannot say "I am interested in Documentation/" by _being_ in that subdirectory. In a repository with worktree, you can, and we let you do so.

I would expect v1.5.0:Documentation/git.txt notation would be the only sane variant that would make sense to name that blob in a bare repository for the same reason. I do not expect anybody to complain because we do not allow him to say v1.5.0:git.txt in a bare repository, either.

Also I sympathize with people who would wish to (eventually) be able to do:

	$ cd Documentation/
	$ git show v1.5.0:git.txt

in a repository with worktree, by making the "relative path" the default behaviour. They would need to do either one of:

	$ git show v1.5.0:/git.c
	$ git show v1.5.0:../git.c

if we ever made the "relative path" the default. As long as you make sure that you make:

	$ git show v1.5.0:/git.c

work the same way in a bare repository _if_ we make the "relative path" the default, I do not see any inconsistency problem there.

A bare repository and a repository with working tree are different. In the former, you cannot say "I am interested in this subtree" by _being_ in a subdirectory; in the latter you can. Taking advantage of that and allowing the user to express himself better (only) in the latter is not an inconsistency. Not being able to do that in a bare repository comes from what a bare repository inherently is.