kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
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>	20 years ago
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.	20 years ago
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.	20 years ago
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.	20 years ago
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.	20 years ago
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.	20 years ago
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.	20 years ago
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).	20 years ago
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.	20 years ago
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).	20 years ago
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.	20 years ago
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.	20 years ago
Linus Torvalds	921d865ea2	Teach git-rev-parse about revision-specifying arguments Things like "--max-count=xxx" are "rev-only".	20 years ago
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.	20 years ago
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.	20 years ago

15 Commits (37fde874c2448ae2cd98abe24df2bd2a50aa2cda)