Re: [PATCH/RFC] diff --relative: output paths as relative to the current subdirectory

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 13, 2008, 01:19 UTC
Message-ID: <7vhcgdzm8u.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.LFD.1.00.0802121604310.2920@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 5 quoted lines

> So I simply don't think that we should assume a working directory for any 
> basic git operation, unless that operation fundamentally needs one because 
> it's only defined for a system with working directories (which is fairly 
> rare, but obviously happens: "git reset --hard", "git pull/merge", "git 
> checkout" etc).

Yeah, but that begs for a larger design-level question.

Instead of treating "diff --relative=drivers/ a..b", as a special case, shouldn't we have a more general "I may be in a bare repository, but please pretend that my prefix were this path" option?

    $ git --prefix=drivers/ diff --relative a..b -- scsi
    $ git --prefix=drivers/scsi log a..b .

Of course, if you are truly in a bare repository and if you did an operation that wants a work tree, you would get mostly useless results, e.g.

    $ git --prefix=fs/ diff v2.6.24 -- ext3

will give you tons of whole-file removals.

I suspect that a lot of existing code assumes a non NULL prefix automatically means we have work tree, which needs to be fixed, if we go this route, though.