From: Michael J Gruber <git@drmicha.warpmail.net>
To: git@vger.kernel.org
Subject: [RFD PATCH 3/3] name-rev: Allow lightweight tags and branch refs
Date: Wed, 15 Mar 2017 14:15:10 +0100 [thread overview]
Message-ID: <db54f291407ef34080fe9e8c9dbdd482b4b3698d.1489581340.git.git@drmicha.warpmail.net> (raw)
In-Reply-To: <cover.1489581340.git.git@drmicha.warpmail.net>
When name-rev constructs possible names for a rev, it assigns the
taggerdate to an annotated tag and ULONG_MAX to other names such as
lightweight tags and branch names. Practically, this rules out even
naming a tagged commit by the tag if that is lightweight and there is
another possible indirect name (e.g. foo~5) coming from an annotated
tag.
Instead, assign the commit date to lightweight tags or branch refs so
that they get their fair chance of being picked up.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Originally, I didn't even think of submitting this as is until I noticed that
all tests succeed with it (bar one for git-prompt.h which looked strange
anyways); rather, I thought about another switch "--lightweight" or so.
I still submit it as RFD. This origin of my foray into name-rev came from
git describe, where a fair expectation should be that "--contains" mode
is the same as the odinary mode, albeit with a different direction in
time/traversal. (Technically, describe --contains is name-rev.)
Consider the following:
git init
echo past >tense
git add tense
git commit -m past
git tag -m past -a past
echo present >tense
git commit -am present
git tag present
echo future >tense
git commit -am future
"git describe past present future" gives
past
past-1-g5ad942f
future
because (as documented) it does not consider lightweight tags, and thus
has to describe present from the past.
"git describe --tags past present future" gives
past
present
future
because (as documented) it does consider lightweight tags.
"git describe --contains past present future" gives
past^0
future~1
future^0
and I have a hard time matching that with the documentation
(describe doc claims that --tags is automatic; name-rev doc does not
distinguish between tag types).
"--tags" does not make any difference here, nor does "--all"
(besides fully qualifying the tags).
"git describe --contains past present future" gives
past^0
present
future^0
with this patch (I'm tempted to say: with the present patch),
which is what I would expect.
I'm wondering whether I'm overlooking any side-effects that our test
suite doesn't cover, though. In any case, we may want to have
lightweight tags allowed based on an extra flag (like the
existing --tags for describe, which means something else for name-rev).
builtin/name-rev.c | 2 ++
t/t9903-bash-prompt.sh | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index 8bdc3eaa6f..75ba7bbad5 100644
--- a/builtin/name-rev.c
+++ b/builtin/name-rev.c
@@ -207,6 +207,8 @@ static int name_ref(const char *path, const struct object_id *oid, int flags, vo
if (o && o->type == OBJ_COMMIT) {
struct commit *commit = (struct commit *)o;
+ if (taggerdate == ULONG_MAX) /* lightweight tag */
+ taggerdate = commit->date;
path = name_ref_abbrev(path, can_abbreviate_output);
name_rev(commit, xstrdup(path), taggerdate, 0, 0, deref);
}
diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index 97c9b32c2e..d467d5957d 100755
--- a/t/t9903-bash-prompt.sh
+++ b/t/t9903-bash-prompt.sh
@@ -107,7 +107,7 @@ test_expect_success 'prompt - describe detached head - contains' '
'
test_expect_success 'prompt - describe detached head - branch' '
- printf " ((tags/t2~1))" >expected &&
+ printf " ((b1~1))" >expected &&
git checkout b1^ &&
test_when_finished "git checkout master" &&
(
--
2.12.0.384.g157040b11f.dirty
next prev parent reply other threads:[~2017-03-15 13:15 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-15 13:15 [PATCH 0/3] describe --contains sanity Michael J Gruber
2017-03-15 13:15 ` [PATCH 1/3] describe: debug is incompatible with contains Michael J Gruber
2017-03-15 19:21 ` Junio C Hamano
2017-03-17 10:54 ` Michael J Gruber
2017-03-15 13:15 ` [PATCH 2/3] git-prompt: add a describe style for any tags Michael J Gruber
2017-03-15 19:25 ` Junio C Hamano
2017-03-17 10:56 ` Michael J Gruber
2017-03-15 13:15 ` Michael J Gruber [this message]
2017-03-15 16:14 ` [RFD PATCH 3/3] name-rev: Allow lightweight tags and branch refs Junio C Hamano
2017-03-15 19:50 ` Junio C Hamano
2017-03-15 20:51 ` Junio C Hamano
2017-03-15 22:50 ` [PATCH 0/2] Teach name-rev to pay more attention to lightweight tags Junio C Hamano
2017-03-15 22:50 ` [PATCH 1/2] name-rev: refactor logic to see if a new candidate is a better name Junio C Hamano
2017-03-15 22:50 ` [PATCH 2/2] name-rev: favor describing with tags and use committer date to tiebreak Junio C Hamano
2017-03-17 4:07 ` Lars Schneider
2017-03-17 5:45 ` Junio C Hamano
2017-03-17 5:56 ` Junio C Hamano
2017-03-17 17:09 ` Lars Schneider
2017-03-17 17:17 ` Junio C Hamano
2017-03-17 22:43 ` Junio C Hamano
2017-03-29 14:39 ` [PATCH v2 0/3] name-rev sanity Michael J Gruber
2017-03-29 14:39 ` [PATCH v2 1/3] name-rev: refactor logic to see if a new candidate is a better name Michael J Gruber
2017-03-29 14:39 ` [PATCH v2 2/3] name-rev: favor describing with tags and use committer date to tiebreak Michael J Gruber
2017-03-29 14:39 ` [PATCH v2 3/3] name-rev: provide debug output Michael J Gruber
2017-03-29 17:15 ` [PATCH v2 0/3] name-rev sanity Junio C Hamano
2017-03-29 17:43 ` Junio C Hamano
2017-03-30 13:48 ` Michael J Gruber
2017-03-30 17:30 ` Junio C Hamano
2017-03-31 13:51 ` [PATCH v3 0/4] " Michael J Gruber
2017-03-31 13:51 ` [PATCH v3 1/4] name-rev: refactor logic to see if a new candidate is a better name Michael J Gruber
2017-03-31 13:51 ` [PATCH v3 2/4] name-rev: favor describing with tags and use committer date to tiebreak Michael J Gruber
2017-03-31 13:51 ` [PATCH v3 3/4] name-rev: provide debug output Michael J Gruber
2017-03-31 16:52 ` Junio C Hamano
2017-03-31 16:55 ` Junio C Hamano
2017-03-31 18:02 ` Michael J Gruber
2017-03-31 18:06 ` Junio C Hamano
2017-03-31 18:33 ` Junio C Hamano
2017-04-03 14:46 ` Michael J Gruber
2017-04-03 17:07 ` Junio C Hamano
2017-05-20 5:19 ` Junio C Hamano
2017-03-31 19:10 ` Junio C Hamano
2017-03-31 13:51 ` [PATCH v3 4/4] describe: pass --debug down to name-rev Michael J Gruber
2017-03-17 11:25 ` [PATCH 2/2] name-rev: favor describing with tags and use committer date to tiebreak Michael J Gruber
2017-03-17 16:03 ` Junio C Hamano
2017-03-16 0:14 ` [PATCH 0/2] Teach name-rev to pay more attention to lightweight tags Stefan Beller
2017-03-16 10:28 ` Jacob Keller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=db54f291407ef34080fe9e8c9dbdd482b4b3698d.1489581340.git.git@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).