Commit Graph

26 Commits

Author SHA1 Message Date
Linus Torvalds
a08b650594 git-rev-parse: pass on "--" flag when required
If rev-parse output includes both flags and files, we should pass on any
"--" marker we see, so that the end result can also tell the difference
between a flag and a filename that begins with '-'.

[jc: merged a later one liner updates from Linus]

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-20 22:32:07 -07:00
Linus Torvalds
7a3dd472ad Avoid ambiguity between refname and filename in rev-parse
Although it really is very convenient, not requiring explicit
'-r' option to name revs is sometimes ambiguous.

Usually we allow a "--" to say where a filename starts when it
_is_ ambiguous.  However, we fail that at times. In particular,
git-rev-parse fails it.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-18 00:16:45 -07:00
Junio C Hamano
e091eb9325 upload-pack: Do not choke on too many heads request.
Cloning from a repository with more than 256 refs (heads and tags
included) will choke, because upload-pack has a built-in limit of
feeding not more than MAX_NEEDS (currently 256) heads to underlying
git-rev-list.  This is a problem when cloning a repository with many
tags, like http://www.linux-mips.org/pub/scm/linux.git, which has 290+
tags.

This commit introduces a new flag, --all, to git-rev-list, to include
all refs in the repository.  Updated upload-pack detects requests that
ask more than MAX_NEEDS refs, and sends everything back instead.

We may probably want to tweak the definitions of MAX_NEEDS and
MAX_HAS, but that is a separate topic.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-05 14:49:54 -07:00
Linus Torvalds
c1babb1d65 [PATCH] Teach "git-rev-parse" about date-based cut-offs
This adds the options "--since=date" and "--before=date" to git-rev-parse,
which knows how to translate them into seconds since the epoch for
git-rev-list.

With this, you can do

	git log --since="2 weeks ago"

or

	git log --until=yesterday

to show the commits that have happened in the last two weeks or are
older than 24 hours, respectively.

The flags "--after=" and "--before" are synonyms for --since and --until,
and you can combine them, so

	git log --after="Aug 5" --before="Aug 10"

is a valid (but strange) thing to do.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-20 18:10:32 -07:00
Linus Torvalds
a8783eeb79 [PATCH] Add "--git-dir" flag to git-rev-parse
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>
2005-09-18 14:18:34 -07:00
Junio C Hamano
4866ccf0f4 Rationalize output selection in rev-parse.
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>
2005-08-24 14:30:04 -07:00
Linus Torvalds
0360e99d06 [PATCH] Fix git-rev-parse --default and --flags handling
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>
2005-08-23 12:42:58 -07:00
Junio C Hamano
30b96fcef1 Add --symbolic flag to git-rev-parse.
This is most useful with --all, --revs-only, --no-flags and --verify.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-17 12:11:36 -07:00
Linus Torvalds
d288a70030 [PATCH] Make "git diff" work inside relative subdirectories
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>
2005-08-16 18:47:22 -07:00
Junio C Hamano
5ccfb758b0 Update rev-parse flags list.
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>
2005-08-09 22:28:21 -07:00
Junio C Hamano
9938af6a85 Update get_sha1() to grok extended format.
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>
2005-08-05 00:51:07 -07:00
Junio C Hamano
5bb2c65aba [PATCH] Help scripts that use git-rev-parse to grok args with SP/TAB/LF
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>
2005-07-22 20:34:16 -07:00
Linus Torvalds
79162bb8ad git-rev-parse: Allow a "zeroth" parent of a commit - the commit itself.
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.
2005-07-11 18:27:25 -07:00
Linus Torvalds
f79b65aa65 Add "--flags" and "--no-flags" arguments to git-rev-parse
The scripts that use this (notably "git diff") will want to split up
flags and file arguments.
2005-07-06 10:08:08 -07:00
Linus Torvalds
671fe4bb20 git-rev-parse: support show sha1 names for pack entries
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.
2005-07-03 21:01:11 -07:00
Linus Torvalds
5736bef18c Make git-rev-parse support cogito-style "short hex names"
Currently only for unpacked objects, but the infrastructure
is there to do it for packed objects too.
2005-07-03 20:27:06 -07:00
Linus Torvalds
960bba0d8c Add "--all" flag to rev-parse that shows all refs
And make git-rev-list just silently ignore non-commit refs if we're not
asking for all objects.
2005-07-03 13:07:52 -07:00
Linus Torvalds
042a4ed7c5 git-rev-parse: add "--not" flag to mark subsequent heads negative
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.
2005-06-26 11:34:30 -07:00
Linus Torvalds
023d66ed7b git-rev-parse: re-organize and be more careful
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).
2005-06-24 10:12:55 -07:00
Linus Torvalds
218e441daf Change parent syntax to "xyz^" instead of "xyz.p"
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.
2005-06-20 21:06:47 -07:00
Linus Torvalds
a8be83fe00 Make rev-parse understand "extended sha1" syntax
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).
2005-06-20 20:28:09 -07:00
Linus Torvalds
9d73fad4ca git-rev-parse: flush "default" head when encountering something unexpected
The unexpected thing is likely a pathname, we need the default for that
too.
2005-06-20 16:14:13 -07:00
Linus Torvalds
800644c5cb git-rev-parse: parse ".." before simple SHA1's
This fixes "<hexsha1>..*", since get_sha1() will happily ignore any
garbage at the end and thus we never got to the ".." check before.
2005-06-20 08:29:13 -07:00
Linus Torvalds
921d865ea2 Teach git-rev-parse about revision-specifying arguments
Things like "--max-count=xxx" are "rev-only".
2005-06-13 11:14:20 -07:00
Linus Torvalds
8ebb018402 git-rev-parse: split "revs" and "non-revs"
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.
2005-06-13 10:21:11 -07:00
Linus Torvalds
178cb24338 Add 'git-rev-parse' helper script
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.
2005-06-13 10:06:50 -07:00