Especially when you're deep inside the git repository, it's not all that
trivial for scripts to figure out where GIT_DIR is if it isn't set.
So add a flag to git-rev-parse to show where it is, since it will have
figured it out anyway.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier rounds broke 'whatchanged -p'. In attempting to fix this,
make two axis of output selection in rev-parse orthogonal:
--revs-only tells it not to output things that are not revisions nor
flags that rev-list would take.
--no-revs tells it not to output things that are revisions or
flags that rev-list would take.
--flags tells it not to output parameters that do not start with
a '-'.
--no-flags tells it not to output parameters that starts with a '-'.
So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386',
while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'.
Also the meaning of --verify has been made stronger. It now rejects
anything but a single valid rev argument. Earlier it passed some flags
through without complaining.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes the argument to --default and any --flags arguments should up
correctly, and makes "--" together with --flags act sanely.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We always show the diff as an absolute path, but pathnames to diff are
taken relative to the current working directory (and if no pathnames are
given, the default ends up being all of the current working directory).
Note that "../xyz" also works, so you can do
cd linux/drivers/char
git diff ../block
and it will generate a diff of the linux/drivers/block changes.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I haven't audited the rev-parse users, but I am having a feeling
that many of them would choke when they expect a couple of SHA1
object names and malicious user feeds them "--max-count=6" or
somesuch to shoot himself in the foot. Anyway, this adds a
couple of missing parameters that affect the list of revs to be
returned from rev-list, not the flags that affect how they are
presented by rev-list. I think that is the intention, but I am
not quite sure.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Everybody envies rev-parse, who is the only one that can grok
the extended sha1 format. Move the get_extended_sha1() out of
rev-parse, rename it to get_sha1() and make it available to
everybody else.
The one I posted earlier to the list had one bug where it did
not handle a name that ends with a digit correctly (it
incorrectly tried the "Nth parent" path). This commit fixes it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The git-rev-parse command uses LF to separate each argument it
parses, so its users at least need to set IFS to LF to be able
to handle filenames with embedded SPs and TABs. Some commands,
however, can take and do expect arguments with embedded LF,
notably, "-S" (pickaxe) of diff family, so even this workaround
does not work for them.
When --sq flag to git-rev-parse is given, instead of showing one
argument per line, it outputs arguments quoted for consumption
with "eval" by the caller, to remedy this situation.
As an example, this patch converts git-whatchanged to use this
new feature.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This sounds nonsensical, but it's useful to make sure that the result is
a commit.
For example, "git-rev-parse v2.6.12" will return the _tag_ object for
v2.6.12, but "git-rev-parse v2.6.12^0" will return the _commit_ object
associated with that tag (and v2.6.12^1 will return the first parent).
Also, since the "parent" code will actually parse the commit, this,
together with the "--verify" flag, will verify not only that the result
is a single SHA1, but will also have verified that it's a proper commit
that we can see.
This is actually subtly wrong. If a short match is found in the object
directory, but would _also_ match another SHA1 ID in a pack (or it shows
in one pack but not another), we'll never have done the pack lookup, and
we think it's unique.
I can't find it in myself to care. You really want to use enough of a
SHA1 that there is never any ambiguity.
If you have two lists of heads, and you want to see ones reachable from
list $a but not from list $b, just do
git-rev-list $(git-rev-parse $a --not $b)
which is useful for both bisecting (where "b" would be the list of known
good revisions, and "a" would be the latest found bad head) and for just
seeing what the difference between two sets of heads are if you want to
generate a pack-file for the difference.
Output default revisions as their hex SHA1 names to be consistent.
Add "--verify" flag that verifies that we output a single ref and not
more (and disables ref arguments).
You can say "HEAD.p" for the "parent of HEAD". It nests, so
HEAD.p2.p
means parent of second parent of HEAD (which obviously depends
on HEAD being a merge).
Sometimes we only want to output revisions, and sometimes we want to
only see the stuff that wasn't revisions. Teach git-rev-parse to
understand the "--revs-only" and "--no-revs" flags.
It's an incredibly cheesy helper that changes human-readable revision
arguments into the git-rev-list argument format.
You can use it to do something like this:
git-rev-list --pretty $(git-rev-parse --default HEAD "$@")
which is what git-log-script will become. Here git-rev-parse will
then allow you to use arguments like "v2.6.12-rc5.." or similar
human-readable ranges.
It's really quite stupid: "a..b" will be converted into "a" and "^b" if
"a" and "b" are valid object pointers. And the "--default" case will be
used if nothing but flags have been seen, so that you can default to a
certain argument if there are no other ranges.
