Re: [PATCH v3] Support ent:relative_path

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > 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.