kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Dmitry V. Levin	5b6df8e45f	Handle invalid argc gently describe, git: Handle argc==0 case the same way as argc==1. merge-tree: Refuse excessive arguments. Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Dmitry V. Levin	8112894d82	Make count-objects, describe and merge-tree work in subdirectory Call setup_git_directory() to make these commands work in subdirectory. Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Jonas Fonseca	f7122265fc	describe: fix off-by-one error in --abbrev=40 handling Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
David Rientjes	96f1e58f52	remove unnecessary initializations [jc: I needed to hand merge the changes to the updated codebase, so the result needs to be checked.] Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	1974632c66	Remove TYPE_* constant macros and use object_type enums consistently. This updates the type-enumeration constants introduced to reduce the memory footprint of "struct object" to match the type bits already used in the packfile format, by removing the former (i.e. TYPE_* constant macros) and using the latter (i.e. enum object_type) throughout the code for consistency. Eventually we can stop passing around the "type strings" entirely, and this will help - no confusion about two different integer enumeration. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Timo Hirvonen	554fe20d80	Make some strings const Signed-off-by: Timo Hirvonen <tihirvon@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	885a86abe2	Shrink "struct object" a bit This shrinks "struct object" by a small amount, by getting rid of the "struct type *" pointer and replacing it with a 3-bit bitfield instead. In addition, we merge the bitfields and the "flags" field, which incidentally should also remove a useless 4-byte padding from the object when in 64-bit mode. Now, our "struct object" is still too damn large, but it's now less obviously bloated, and of the remaining fields, only the "util" (which is not used by most things) is clearly something that should be eventually discarded. This shrinks the "git-rev-list --all" memory use by about 2.5% on the kernel archive (and, perhaps more importantly, on the larger mozilla archive). That may not sound like much, but I suspect it's more on a 64-bit platform. There are other remaining inefficiencies (the parent lists, for example, probably have horrible malloc overhead), but this was pretty obvious. Most of the patch is just changing the comparison of the "type" pointer from one of the constant string pointers to the appropriate new TYPE_xxx small integer constant. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Dmitry V. Levin	31fff305bc	Separate object name errors from usage errors Separate object name errors from usage errors. Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	46a6c2620b	abbrev cleanup: use symbolic constants The minimum length of abbreviated object name was hardcoded in different places to be 4, risking inconsistencies in the future. Also there were three different "default abbreviation precision". Use two C preprocessor symbols to clean up this mess. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	181dc77695	describe: omit clearing marks on the last one. When describing more than one, we need to clear the commit marks before handling the next one, but most of the time we are running it for only one commit, and in such a case this clearing phase is totally unnecessary. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	4c34a2c555	git-describe: default to HEAD This is based on the patch by Andreas Ericsson, but done slightly differently, preferring to have separate loops -- one for options and then arguments. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	8c23b6fae2	describe: do not silently ignore indescribable commits We silently ignored indescribable commits without complaining. Complain and die instead. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	f8f9c73c7d	describe: allow more than one revs to be named. The main loop was prepared to take more than one revs, but the actual naming logic wad not (it used pop_most_recent_commit while forgetting that the commit marks stay after it's done). Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	64deb858b0	git-describe: still prefer annotated tag under --all and --tags Even though --all and --tags can be used to include non annotated tags in the reference point candidates, prefer to use annotated tags if there are more than one refs that name the same commit. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	2d9e7c9f90	git-describe: --tags and --abbrev With --tags, not just annontated tags, but also any ref under refs/tags/ are used to name the revision. The number of digits is configurable with the --abbrev=<n> option. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	4cdf78bf96	git-describe: use find_unique_abbrev() Just in case 8 hexadecimal digits are not enough. We could use shorter default if we wanted to. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	635d413430	git-describe: really prefer tags only. Often there are references other than annotated tags under refs/tags hierarchy that are used to "keep things just in case". default to use annotated tags only, still leaving the option to use any ref with --all flag. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	908e5310b9	Add a "git-describe" command It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit `2414721b19`. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago

21 Commits (83b5d2f5b0c95fe102bc3d1cc2947abbdf5e5c5b)