path: root/rev-parse.c
AgeCommit message (Collapse)Author
2005-10-05upload-pack: Do not choke on too many heads request.Junio C Hamano
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, 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 <>
2005-09-21[PATCH] Teach "git-rev-parse" about date-based cut-offsLinus Torvalds
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 <> Signed-off-by: Junio C Hamano <>
2005-09-18[PATCH] Add "--git-dir" flag to git-rev-parseLinus Torvalds
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 <> Signed-off-by: Junio C Hamano <>
2005-08-24Rationalize output selection in rev-parse.Junio C Hamano
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 <>
2005-08-23[PATCH] Fix git-rev-parse --default and --flags handlingLinus Torvalds
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 <> Signed-off-by: Junio C Hamano <>
2005-08-17Add --symbolic flag to git-rev-parse.Junio C Hamano
This is most useful with --all, --revs-only, --no-flags and --verify. Signed-off-by: Junio C Hamano <>
2005-08-17[PATCH] Make "git diff" work inside relative subdirectoriesLinus Torvalds
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 <> Signed-off-by: Junio C Hamano <>
2005-08-10Update rev-parse flags list.Junio C Hamano
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 <>
2005-08-05Update get_sha1() to grok extended format.Junio C Hamano
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 <>
2005-07-23[PATCH] Help scripts that use git-rev-parse to grok args with SP/TAB/LFJunio C Hamano
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 <> Signed-off-by: Linus Torvalds <>
2005-07-12git-rev-parse: Allow a "zeroth" parent of a commit - the commit itself.Linus Torvalds
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-06Add "--flags" and "--no-flags" arguments to git-rev-parseLinus Torvalds
The scripts that use this (notably "git diff") will want to split up flags and file arguments.
2005-07-04git-rev-parse: support show sha1 names for pack entriesLinus Torvalds
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-04Make git-rev-parse support cogito-style "short hex names"Linus Torvalds
Currently only for unpacked objects, but the infrastructure is there to do it for packed objects too.
2005-07-03Add "--all" flag to rev-parse that shows all refsLinus Torvalds
And make git-rev-list just silently ignore non-commit refs if we're not asking for all objects.
2005-06-26git-rev-parse: add "--not" flag to mark subsequent heads negativeLinus Torvalds
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-24git-rev-parse: re-organize and be more carefulLinus Torvalds
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-21Change parent syntax to "xyz^" instead of "xyz.p"Linus Torvalds
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-21Make rev-parse understand "extended sha1" syntaxLinus Torvalds
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-20git-rev-parse: flush "default" head when encountering something unexpectedLinus Torvalds
The unexpected thing is likely a pathname, we need the default for that too.
2005-06-20git-rev-parse: parse ".." before simple SHA1'sLinus Torvalds
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-13Teach git-rev-parse about revision-specifying argumentsLinus Torvalds
Things like "--max-count=xxx" are "rev-only".
2005-06-13git-rev-parse: split "revs" and "non-revs"Linus Torvalds
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-13Add 'git-rev-parse' helper scriptLinus Torvalds
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.