summaryrefslogtreecommitdiff
path: root/t/t6120-describe.sh
AgeCommit message (Collapse)Author
2013-07-18describe: fix --contains when a tag is given as inputJunio C Hamano
"git describe" takes a commit and gives it a name based on tags in its neighbourhood. The command does take a commit-ish but when given a tag that points at a commit, it should dereference the tag before computing the name for the commit. As the whole processing is internally delegated to name-rev, if we unwrap tags down to the underlying commit when invoking name-rev, it will make the name-rev issue an error message based on the unwrapped object name (i.e. either 40-hex object name, or "$tag^0") that is different from what the end-user gave to the command when the commit cannot be described. Introduce an internal option --peel-tag to the name-rev to tell it to unwrap a tag in its input from the command line. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-18name-rev: differentiate between tags and commits they point atJunio C Hamano
"git name-rev --stdin" has been fixed to convert an object name that points at a tag to a refname of the tag. The codepath to handle its command line arguments, however, fed the commit that the tag points at to the underlying naming machinery. With this fix, you will get this: $ git name-rev --refs=tags/\* --name-only $(git rev-parse v1.8.3 v1.8.3^0) v1.8.3 v1.8.3^0 which is the same as what you would get from the fixed "--stdin" variant: $ git rev-parse v1.8.3 v1.8.3^0 | git name-rev --refs=tags/\* --name-only v1.8.3 v1.8.3^0 Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-20describe: Add --first-parent optionMike Crowe
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, ↵Junio C Hamano
t7012 and t7060 Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-10i18n: git-describe basic messagesÆvar Arnfjörð Bjarmason
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 dateShawn O. Pearce
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-21describe: do not use unannotated tag even if exact matchThomas Rast
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'Junio C Hamano
* jp/dirty-describe: Teach "git describe" --dirty option
2009-10-27Teach "git describe" --dirty optionJean Privat
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 repositoryJunio C Hamano
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 maintJunio C Hamano
* sp/maint-describe-all-tag-warning: describe: Avoid unnecessary warning when using --all
2008-12-27describe: Avoid unnecessary warning when using --allShawn O. Pearce
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 oftenShawn O. Pearce
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)Nanako Shiraishi
Converts tests between t3600-t6300. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-03Fix describe --tags --long so it does not segfaultShawn O. Pearce
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'Junio C Hamano
* maint: describe: match pattern for lightweight tags too
2008-06-04describe: match pattern for lightweight tags tooMichael Dressel
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"Junio C Hamano
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-04t6120 (describe): check --long properlyJunio C Hamano
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-04Add git-describe test for "verify annotated tag names on output"Shawn O. Pearce
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-04Test for packed tags in git-describe outputShawn O. Pearce
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-04Don't allow git-describe failures to go unnoticed in t6120Shawn O. Pearce
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-26git-describe: --long shows the object name even for a tagged commitSanti Béjar
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-03Rewrite "git-frotz" to "git frotz"Junio C Hamano
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-01-15Add describe test.Junio C Hamano
... with help from Shawn. Signed-off-by: Junio C Hamano <junkio@cox.net>