kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Shawn O. Pearce	03e8b541b3	describe: Break annotated tag ties by tagger date If more than one annotated tag points at the same commit, use the tag whose tagger field has a more recent date stamp. This resolves non-deterministic cases where the maintainer has done: $ git tag -a -m "2.1-rc1" v2.1-rc1 deadbeef $ git tag -a -m "2.1" v2.1 deadbeef If the tag is an older-style annotated tag with no tagger date, we assume a date stamp at the UNIX epoch. This will cause us to prefer an annotated tag that has a valid date. We could also try to consider the tag object chain, favoring a tag that "includes" another one: $ git tag -a -m "2.1-rc0" v2.1-rc1 deadbeef $ git tag -a -m "2.1" v2.1 v2.1-rc1 However traversing the tag's object chain looking for inclusion is much more complicated. Its already very likely that even in these cases the v2.1 tag will have a more recent tagger date than v2.1-rc1, so with this change describe should still resolve this by selecting the more recent v2.1. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Thomas Rast	7a0d61bb45	describe: do not use unannotated tag even if exact match `4d23660` (describe: when failing, tell the user about options that work, 2009-10-28) forgot to update the shortcut path where the code detected and used a possible exact match. This means that an unannotated tag on HEAD would be used by 'git describe'. Guard this code path against the new circumstances, where unannotated tags can be present in ->util even if we're not actually planning to use them. While there, also add some tests for --all. Reported by 'yashi' on IRC. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Jean Privat	9f67d2e827	Teach "git describe" --dirty option With the --dirty option, git describe works on HEAD but append s"-dirty" iff the contents of the work tree differs from HEAD. E.g. $ git describe --dirty v1.6.5-15-gc274db7 $ echo >> Makefile $ git describe --dirty v1.6.5-15-gc274db7-dirty The --dirty option can also be used to specify what is appended, instead of the default string "-dirty". $ git describe --dirty=.mod v1.6.5-15-gc274db7.mod Many build scripts use `git describe` to produce a version number based on the description of HEAD (on which the work tree is based) + saying that if the build contains uncommitted changes. This patch helps the writing of such scripts since `git describe --dirty` does directly the intended thing. Three possiblities were considered while discussing this new feature: 1. Describe the work tree by default and describe HEAD only if "HEAD" is explicitly specified Pro: does the right thing by default (both for users and for scripts) Pro: other git commands that works on the work tree by default Con: breaks existing scripts used by the Linux kernel and other projects 2. Use --worktree instead of --dirty Pro: does what it says: "git describe --worktree" describes the work tree Con: other commands do not require a --worktree option when working on the work tree (it often is the default mode for them) Con: unusable with an optional value: "git describe --worktree=.mod" is quite unintuitive. 3. Use --dirty as in this patch Pro: makes sense to specify an optional value (what the dirty mark is) Pro: does not have any of the big cons of previous alternatives * does not break scripts * is not inconsistent with other git commands This patch takes the third approach. Signed-off-by: Jean Privat <jean@pryen.org> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Junio C Hamano	024ab976ff	Do not fail "describe --always" in a tag-less repository This fixes a regression introduce by `d68dc34` (git-describe: Die early if there are no possible descriptions, 2009-08-06). Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Shawn O. Pearce	81dc223deb	describe: Avoid unnecessary warning when using --all In `212945d4` ("Teach git-describe to verify annotated tag names before output") git-describe learned how to output a warning if an annotated tag object was matched but its internal name doesn't match the local ref name. However, "git describe --all" causes the local ref name to be prefixed with "tags/", so we need to skip over this prefix before comparing the local ref name with the name recorded inside of the tag object. Patch-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Shawn O. Pearce	7e425c4fbb	describe: Make --tags and --all match lightweight tags more often If the caller supplies --tags they want the lightweight, unannotated tags to be searched for a match. If a lightweight tag is closer in the history, it should be matched, even if an annotated tag is reachable further back in the commit chain. The same applies with --all when matching any other type of ref. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Acked-By: Uwe Kleine-König <ukleinek@strlen.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Nanako Shiraishi	3604e7c5c6	tests: use "git xyzzy" form (t3600 - t6999) Converts tests between t3600-t6300. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Shawn O. Pearce	14d4642e2a	Fix describe --tags --long so it does not segfault If we match a lightweight (non-annotated tag) as the name to output and --long was requested we do not have a tag, nor do we have a tagged object to display. Instead we must use the object we were passed as input for the long format display. Reported-by: Mark Burton <markb@ordern.com> Backtraced-by: Mikael Magnusson <mikachu@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Michael Dressel	4ed19a3c17	describe: match pattern for lightweight tags too The <pattern> given "git describe --match" was used only to filter tag objects, and not to filter lightweight tags. This fixes it. [jc: made the log to clarify this is a bugfix, not an enhancement, with additional test] Signed-off-by: Michael Dressel <MichaelTiloDressel@t-online.de> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	3af828634f	tests: do not use implicit "git diff --no-index" As a general principle, we should not use "git diff" to validate the results of what git command that is being tested has done. We would not know if we are testing the command in question, or locating a bug in the cute hack of "git diff --no-index". Rather use test_cmp for that purpose. Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	4d4c3e1c12	t6120 (describe): check --long properly Existing test checked --long only for exactly tagged commit. We should make sure it works sensibly for commits that are not tagged. Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Shawn O. Pearce	3291fe4072	Add git-describe test for "verify annotated tag names on output" Back in `212945d4` ("Teach git-describe to verify annotated tag names before output") I taught git-describe to output the name shown in the "tag" header of an annotated tag, rather than the name it is actually stored under in this repository's ref namespace. This test case verifies this is working correctly by renaming the ref for an annotated tag to a different name that what is recorded in the tag body, and verifying that tag is returned. We also verify there is a message shown on stderr to inform the user that the tag is possibly stored under the wrong name locally. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Shawn O. Pearce	d1b28f512c	Test for packed tags in git-describe output In `c374b91c` ("git-describe: use tags found in packed-refs correctly") Junio fixed an issue where git-describe did not parse a tag object it obtained from a packed-refs file, as the peel information was read in from packed-refs and not the tag object itself. This new test case verifies the fix listed above is functioning, and does not have a regression in the future. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Shawn O. Pearce	be7bae0d48	Don't allow git-describe failures to go unnoticed in t6120 If git-describe fails we never execute the test_expect_success, so we never actually test for failure. This is horribly wrong. We need to always run the test case, but the test case is only supposed to succeed if the prior git-describe returned 0. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Santi Béjar	518120e348	git-describe: --long shows the object name even for a tagged commit This is useful when you want to see parts of the commit object name in "describe" output, even when the commit in question happens to be a tagged version. Instead of just emitting the tag name, it will describe such a commit as v1.2-0-deadbeef (0th commit since tag v1.2 that points at object deadbeef....). Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	5be60078c9	Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Junio C Hamano	5312ab11fb	Add describe test. ... with help from Shawn. Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago

20 Commits (33f239365cce2682a1faac0d5670d684aa1981ad)