diff --relative: output paths as relative to the current subdirectory
authorJunio C Hamano <gitster@pobox.com>
Tue, 12 Feb 2008 22:26:02 +0000 (14:26 -0800)
committerJunio C Hamano <gitster@pobox.com>
Wed, 13 Feb 2008 22:58:07 +0000 (14:58 -0800)
commitcd676a513672eeb9663c6d4de276a1c860a4b879
treed03ba0875a0c3e5bdb8f879ccda999b42d927f56
parent7a2078b4b00fb1c5d7b0bf8155778f79377b8f2f
diff --relative: output paths as relative to the current subdirectory

This adds --relative option to the diff family.  When you start
from a subdirectory:

        $ git diff --relative

shows only the diff that is inside your current subdirectory,
and without $prefix part.  People who usually live in
subdirectories may like it.

There are a few things I should also mention about the change:

 - This works not just with diff but also works with the log
   family of commands, but the history pruning is not affected.

   In other words, if you go to a subdirectory, you can say:

        $ git log --relative -p

   but it will show the log message even for commits that do not
   touch the current directory.  You can limit it by giving
   pathspec yourself:

        $ git log --relative -p .

   This originally was not a conscious design choice, but we
   have a way to affect diff pathspec and pruning pathspec
   independently.  IOW "git log --full-diff -p ." tells it to
   prune history to commits that affect the current subdirectory
   but show the changes with full context.  I think it makes
   more sense to leave pruning independent from --relative than
   the obvious alternative of always pruning with the current
   subdirectory, which would break the symmetry.

 - Because this works also with the log family, you could
   format-patch a single change, limiting the effect to your
   subdirectory, like so:

        $ cd gitk-git
        $ git format-patch -1 --relative 911f1eb

   But because that is a special purpose usage, this option will
   never become the default, with or without repository or user
   preference configuration.  The risk of producing a partial
   patch and sending it out by mistake is too great if we did
   so.

 - This is inherently incompatible with --no-index, which is a
   bolted-on hack that does not have much to do with git
   itself.  I didn't bother checking and erroring out on the
   combined use of the options, but probably I should.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/diff-options.txt
builtin-diff.c
diff.c
diff.h
revision.c