| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
The scripts that use this (notably "git diff") will want to split up
flags and file arguments.
|
|
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.
|
|
Currently only for unpacked objects, but the infrastructure
is there to do it for packed objects too.
|
|
And make git-rev-list just silently ignore non-commit refs if we're not
asking for all objects.
|
|
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).
|
|
The ".pN" thing might be a common ending of a tag, and in
contrast, ^ already is a special character for revisions
so use that instead.
|
|
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).
|
|
The unexpected thing is likely a pathname, we need the default for that
too.
|
|
This fixes "<hexsha1>..*", since get_sha1() will happily ignore any
garbage at the end and thus we never got to the ".." check before.
|
|
Things like "--max-count=xxx" are "rev-only".
|
|
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.
|
Junio C Hamano
Linus Torvalds
Linus Torvalds