threads / discuss / 16961

git checkout does not warn about tags without corresponding commits

Subject: git checkout does not warn about tags without corresponding commits

## tl;dr

8 messages between Jan 2, 2009 and Jan 3, 2009.

replies: 7people: 4as markdown or json

Henrik Austad· Jan 2, 2009, 12:25 UTC · lore
Hi!

I recently tried to do a checkout of (what I thought was the first) inux kernel in the linux git repo.

git checkout -b 2.6.11 v2.6.11

This tag exists in the linux-tree (direct clone from Linus' tree), along with v2.6.11-tree

However, when I inspect the log, I see that I am still stuck in master. So, I did a git tag -v v2.6.11 and got the following:

object c39ae07f393806ccf406ef966e9a15afc43cc36a type tree tag v2.6.11-tree

This is the 2.6.11 tree object.

NOTE! There's no commit for this, since it happened before I started with git. Eventually we'll import some sort of history, and that should tie this tree object up to a real commit. In the meantime, this acts as an anchor point for doing diffs etc under git. gpg: Signature made Thu 05 May 2005 01:50:54 AM CEST using DSA key ID 76E21CBB gpg: Good signature from "Linus Torvalds (tag signing key) <torvalds@osdl.org>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: FF6D 4EAC 37AC C1B9 53AE C7E8 1776 2C46 76E2 1CBB

I can see that there's no commit for this, but, when there's a tag. I thought that a tag was just a commit-sha1 with a name attached, along with some tag info and a signature. Can you really create a tag without a commit?

Shouldn't git checkout fail in some way, letting me know that the checkout did not check out what I thought it did? (I got aware of the bug when I found CFS-related code in something I thought was 2.6.11.. :-)

-- 
 -> henrik
Miklos Vajna· Jan 2, 2009, 15:04 UTC · re: Henrik Austad · lore

Re: git checkout does not warn about tags without corresponding commits

On Fri, Jan 02, 2009 at 01:25:57PM +0100, Henrik Austad <henrik@austad.us> wrote:
> I can see that there's no commit for this, but, when there's a tag. I thought 
> that a tag was just a commit-sha1 with a name attached, along with some tag 
> info and a signature. Can you really create a tag without a commit?

Sure, you can tag any object type (blob, tree, commit or tag), but usually only commits are tagged.

See for example the 'junio-gpg-pub' tag in git.git which tags a blob.
Junio C Hamano· Jan 2, 2009, 21:44 UTC · re: Henrik Austad · lore

Re: git checkout does not warn about tags without corresponding commits

Henrik Austad <henrik@austad.us> writes:
> I recently tried to do a checkout of (what I thought was the first) inux 
> kernel in the linux git repo.
>
> git checkout -b 2.6.11 v2.6.11

This should have barfed, and indeed I think it is a regression around v1.5.5. v1.5.4 and older git definitely fails to check out a tree object like that.

Henrik Austad· Jan 3, 2009, 11:00 UTC · re: Junio C Hamano · lore

Re: git checkout does not warn about tags without corresponding commits

On Friday 02 January 2009 22:44:50 Junio C Hamano wrote:
Show 9 quoted lines
> Henrik Austad <henrik@austad.us> writes:
> > I recently tried to do a checkout of (what I thought was the first) inux
> > kernel in the linux git repo.
> >
> > git checkout -b 2.6.11 v2.6.11
>
> This should have barfed, and indeed I think it is a regression around
> v1.5.5.  v1.5.4 and older git definitely fails to check out a tree object
> like that.

You're right, I bisected it down to commit 782c2d65c24066a5d83453efb52763bc34c10f81

It introduces quite a large change, adding checkout-builtin.c, which coud be the cause I guess.

As of how to fix this (if a fix is desired) I have not yet any clue what so ever :-)

I attached the bisect result (sorry if attachements are frowned upon, but my email client tends to mutilate text-contents like that).

-- 
 -> henrik


782c2d65c24066a5d83453efb52763bc34c10f81 is first bad commit
commit 782c2d65c24066a5d83453efb52763bc34c10f81
Author: Daniel Barkalow <barkalow@iabervon.org>
Date:   Thu Feb 7 11:40:23 2008 -0500

    Build in checkout

    The only differences in behavior should be:

     - git checkout -m with non-trivial merging won't print out
       merge-recursive messages (see the change in t7201-co.sh)

     - git checkout -- paths... will give a sensible error message if
       HEAD is invalid as a commit.

     - some intermediate states which were written to disk in the shell
       version (in particular, index states) are only kept in memory in
       this version, and therefore these can no longer be revealed by
       later write operations becoming impossible.

     - when we change branches, we discard MERGE_MSG, SQUASH_MSG, and
       rr-cache/MERGE_RR, like reset always has.

    I'm not 100% sure I got the merge recursive setup exactly right; the
    base for a non-trivial merge in the shell code doesn't seem
    theoretically justified to me, but I tried to match it anyway, and the
    tests all pass this way.

    Other than these items, the results should be identical to the shell
    version, so far as I can tell.

    [jc: squashed lock-file fix from Dscho in]

    Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
    Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

:100644 100644 5cfadfd307d588a427e200576ba97a5227653a13 90c0dd8c43cd66008d29492bdfb6b21a17855a00 M      Makefile
:000000 100644 0000000000000000000000000000000000000000 59a0ef4ec9770af6d031abe959adc587c9538a89 A      builtin-checkout.c
:100644 100644 428160d0e48b2acf1ac54d6d73910fd93151ca22 25d91bbfb21ea3c1ea067b10f7ea033d3563936a M      builtin.h
:040000 040000 098e84f3f9fc152debb0f92eb849127f460391d7 0860a331e5a98a88a143d32f371385e78a0121d8 M      contrib
:100755 000000 5621c69d86062c7c75c0b8c2749d34efc78cafb4 0000000000000000000000000000000000000000 D      git-checkout.sh
:100644 100644 114ea75eef55e2960ff111014a505c3eb678caae fc156863b0bbd7d264864c49c2529e47709abf4d M      git.c
:040000 040000 49b19f06ce0395f99f5b9729a1e51b5fa7fd1875 4165e146453fa357ef5e76a9ad48e683301ae669 M      t
Junio C Hamano· Jan 3, 2009, 11:36 UTC · re: Henrik Austad · lore

Re: git checkout does not warn about tags without corresponding commits

Henrik Austad <henrik@austad.us> writes:
Show 13 quoted lines
> On Friday 02 January 2009 22:44:50 Junio C Hamano wrote:
>> Henrik Austad <henrik@austad.us> writes:
>> > I recently tried to do a checkout of (what I thought was the first) inux
>> > kernel in the linux git repo.
>> >
>> > git checkout -b 2.6.11 v2.6.11
>>
>> This should have barfed, and indeed I think it is a regression around
>> v1.5.5.  v1.5.4 and older git definitely fails to check out a tree object
>> like that.
>
> You're right, I bisected it down to commit 
> 782c2d65c24066a5d83453efb52763bc34c10f81
I am not surprised.

That one discarded an implementation of "git checkout" in Bourne shell, with a complete reimplementation in C.

I haven't looked at the code very closely, but I think this should fix it. Thorough reviewing (not just running the test suite) is much appreciated.

-- >8 --
Subject: git-checkout: do not allow switching to a tree-ish

"git checkout -b newbranch $commit^{tree}" mistakenly created a new branch rooted at the current HEAD, because in that case, the two structure fields used to see if the command was invoked without any argument (hence it needs to default to checking out the HEAD), were populated incorrectly.

Upon seeing a command line argument that we took as a rev, we should store that string in new.name, even if that does not name a commit.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 builtin-checkout.c               |    2 +-
 t/t2011-checkout-invalid-head.sh |    4 ++++
 2 files changed, 5 insertions(+), 1 deletions(-)
diff --git c/builtin-checkout.c w/builtin-checkout.c
index c2c0561..b5dd9c0 100644
--- c/builtin-checkout.c
+++ w/builtin-checkout.c
@@ -681,8 +681,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
 		argv++;
 		argc--;
 
+		new.name = arg;
 		if ((new.commit = lookup_commit_reference_gently(rev, 1))) {
-			new.name = arg;
 			setup_branch_path(&new);
 			if (resolve_ref(new.path, rev, 1, NULL))
 				new.commit = lookup_commit_reference(rev);
diff --git c/t/t2011-checkout-invalid-head.sh w/t/t2011-checkout-invalid-head.sh
index 764bb0a..798790d 100755
--- c/t/t2011-checkout-invalid-head.sh
+++ w/t/t2011-checkout-invalid-head.sh
@@ -15,4 +15,8 @@ test_expect_success 'checkout master from invalid HEAD' '
 	git checkout master --
 '
 
+test_expect_success 'checkout should not start branch from a tree' '
+	test_must_fail git checkout -b newbranch master^{tree}
+'
+
 test_done
Junio C Hamano· Jan 3, 2009, 11:53 UTC · re: Junio C Hamano · lore

Re: git checkout does not warn about tags without corresponding commits

Junio C Hamano <gitster@pobox.com> writes:
> I haven't looked at the code very closely, but I think this should fix
> it.  Thorough reviewing (not just running the test suite) is much
> appreciated.

Just for fun, this will apply to 782c2d6 (Build in checkout, 2008-02-07) and seems to fix the issue ;-)

No, I am not going to issue a maintenance release for 1.5.5 just to include this fix, even though I could. I do not think this is a grave enough regression to warrant a backport beyond 1.6.0 series.

 builtin-checkout.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git i/builtin-checkout.c w/builtin-checkout.c
index 59a0ef4..1d0de68 100644
--- i/builtin-checkout.c
+++ w/builtin-checkout.c
@@ -435,6 +435,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
 			argv++;
 			argc--;
 		} else if ((source_tree = parse_tree_indirect(rev))) {
+			new.name = arg;
 			argv++;
 			argc--;
 		}
Henrik Austad· Jan 3, 2009, 12:37 UTC · re: Junio C Hamano · lore

Re: git checkout does not warn about tags without corresponding commits

On Saturday 03 January 2009 12:36:04 Junio C Hamano wrote:
Show 55 quoted lines
> Henrik Austad <henrik@austad.us> writes:
> > On Friday 02 January 2009 22:44:50 Junio C Hamano wrote:
> >> Henrik Austad <henrik@austad.us> writes:
> >> > I recently tried to do a checkout of (what I thought was the first)
> >> > inux kernel in the linux git repo.
> >> >
> >> > git checkout -b 2.6.11 v2.6.11
> >>
> >> This should have barfed, and indeed I think it is a regression around
> >> v1.5.5.  v1.5.4 and older git definitely fails to check out a tree
> >> object like that.
> >
> > You're right, I bisected it down to commit
> > 782c2d65c24066a5d83453efb52763bc34c10f81
>
> I am not surprised.
>
> That one discarded an implementation of "git checkout" in Bourne shell,
> with a complete reimplementation in C.
>
> I haven't looked at the code very closely, but I think this should fix
> it.  Thorough reviewing (not just running the test suite) is much
> appreciated.
>
> -- >8 --
> Subject: git-checkout: do not allow switching to a tree-ish
>
> "git checkout -b newbranch $commit^{tree}" mistakenly created a new branch
> rooted at the current HEAD, because in that case, the two structure fields
> used to see if the command was invoked without any argument (hence it
> needs to default to checking out the HEAD), were populated incorrectly.
>
> Upon seeing a command line argument that we took as a rev, we should store
> that string in new.name, even if that does not name a commit.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  builtin-checkout.c               |    2 +-
>  t/t2011-checkout-invalid-head.sh |    4 ++++
>  2 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git c/builtin-checkout.c w/builtin-checkout.c
> index c2c0561..b5dd9c0 100644
> --- c/builtin-checkout.c
> +++ w/builtin-checkout.c
> @@ -681,8 +681,8 @@ int cmd_checkout(int argc, const char **argv, const
> char *prefix) argv++;
>  		argc--;
>
> +		new.name = arg;
>  		if ((new.commit = lookup_commit_reference_gently(rev, 1))) {
> -			new.name = arg;
>  			setup_branch_path(&new);
>  			if (resolve_ref(new.path, rev, 1, NULL))
>  				new.commit = lookup_commit_reference(rev);

this fixed my problem when i hacked this into master (git apply failed on the patch, so I did a manual patch. Moving that line did the trick

Acked-by/Signed-off-by Henrik Austad <henrik@austad.us>
Show 18 quoted lines
> diff --git c/t/t2011-checkout-invalid-head.sh
> w/t/t2011-checkout-invalid-head.sh index 764bb0a..798790d 100755
> --- c/t/t2011-checkout-invalid-head.sh
> +++ w/t/t2011-checkout-invalid-head.sh
> @@ -15,4 +15,8 @@ test_expect_success 'checkout master from invalid HEAD' '
>  	git checkout master --
>  '
>
> +test_expect_success 'checkout should not start branch from a tree' '
> +	test_must_fail git checkout -b newbranch master^{tree}
> +'
> +
>  test_done
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
 -> henrik
Daniel Barkalow· Jan 3, 2009, 19:31 UTC · re: Junio C Hamano · lore

Re: git checkout does not warn about tags without corresponding commits

On Sat, 3 Jan 2009, Junio C Hamano wrote:
Show 24 quoted lines
> Henrik Austad <henrik@austad.us> writes:
> 
> > On Friday 02 January 2009 22:44:50 Junio C Hamano wrote:
> >> Henrik Austad <henrik@austad.us> writes:
> >> > I recently tried to do a checkout of (what I thought was the first) inux
> >> > kernel in the linux git repo.
> >> >
> >> > git checkout -b 2.6.11 v2.6.11
> >>
> >> This should have barfed, and indeed I think it is a regression around
> >> v1.5.5.  v1.5.4 and older git definitely fails to check out a tree object
> >> like that.
> >
> > You're right, I bisected it down to commit 
> > 782c2d65c24066a5d83453efb52763bc34c10f81
> 
> I am not surprised.
> 
> That one discarded an implementation of "git checkout" in Bourne shell,
> with a complete reimplementation in C.
> 
> I haven't looked at the code very closely, but I think this should fix
> it.  Thorough reviewing (not just running the test suite) is much
> appreciated.
That looks right to me.
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
	-Daniel
*This .sig left intentionally blank*

← back to recent threads