summaryrefslogtreecommitdiff
path: root/t/t6120-describe.sh
AgeCommit message (Collapse)AuthorFilesLines
2013-05-20describe: Add --first-parent optionLibravatar Mike Crowe1-0/+3
Only consider the first parent commit when walking the commit history. This is useful if you only wish to match tags on your branch after a merge. Signed-off-by: Mike Crowe <mac@mcrowe.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-13i18n: use test_i18ncmp and test_i18ngrep in t5541, t6040, t6120, t7004, ↵Libravatar Junio C Hamano1-2/+2
t7012 and t7060 Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09i18n: git-describe basic messagesLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-13describe: Break annotated tag ties by tagger dateLibravatar Shawn O. Pearce1-3/+5
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>
2009-11-20describe: do not use unannotated tag even if exact matchLibravatar Thomas Rast1-0/+6
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>
2009-11-10Merge branch 'jp/dirty-describe'Libravatar Junio C Hamano1-0/+14
* jp/dirty-describe: Teach "git describe" --dirty option
2009-10-27Teach "git describe" --dirty optionLibravatar Jean Privat1-0/+14
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>
2009-10-23Do not fail "describe --always" in a tag-less repositoryLibravatar Junio C Hamano1-0/+2
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>
2008-12-27Merge branch 'sp/maint-describe-all-tag-warning' into maintLibravatar Junio C Hamano1-0/+6
* sp/maint-describe-all-tag-warning: describe: Avoid unnecessary warning when using --all
2008-12-26describe: Avoid unnecessary warning when using --allLibravatar Shawn O. Pearce1-0/+6
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>
2008-10-17describe: Make --tags and --all match lightweight tags more oftenLibravatar Shawn O. Pearce1-4/+4
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>
2008-09-03tests: use "git xyzzy" form (t3600 - t6999)Libravatar Nanako Shiraishi1-15/+15
Converts tests between t3600-t6300. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-02Fix describe --tags --long so it does not segfaultLibravatar Shawn O. Pearce1-0/+2
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>
2008-06-04Merge branch 'maint'Libravatar Junio C Hamano1-0/+22
* maint: describe: match pattern for lightweight tags too
2008-06-04describe: match pattern for lightweight tags tooLibravatar Michael Dressel1-0/+22
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>
2008-05-24tests: do not use implicit "git diff --no-index"Libravatar Junio C Hamano1-1/+1
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>
2008-03-03t6120 (describe): check --long properlyLibravatar Junio C Hamano1-0/+1
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>
2008-03-03Add git-describe test for "verify annotated tag names on output"Libravatar Shawn O. Pearce1-1/+16
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>
2008-03-03Test for packed tags in git-describe outputLibravatar Shawn O. Pearce1-0/+3
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>
2008-03-03Don't allow git-describe failures to go unnoticed in t6120Libravatar Shawn O. Pearce1-1/+3
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>
2008-02-25git-describe: --long shows the object name even for a tagged commitLibravatar Santi Béjar1-0/+2
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>
2007-07-02Rewrite "git-frotz" to "git frotz"Libravatar Junio C Hamano1-11/+11
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-01-14Add describe test.Libravatar Junio C Hamano1-0/+97
... with help from Shawn. Signed-off-by: Junio C Hamano <junkio@cox.net>