Re: git-fetch will leave a ref pointing to a tag

From: linux@horizon.com <linux@horizon.com>
Date: Jul 3, 2007, 03:23 UTC
Message-ID: <20070703032315.7279.qmail@science.horizon.com>
In-Reply-To: <Pine.LNX.4.64.0707022207420.4071@racer.site>

> Why not do 'git branch temp v2.6.22-rc7' to begin with? Or even better: 
> git checkout -b temp v2.6.22-rc7.

In my case, it was the "master" branch; I couldn't remember if I'd done any hacking on it. But I used the branch name "temp" while demonstrating how to recreate the problem.

> But in any case, you should know that there is no floating tag in git, and 
> therefore, by storing it in the "branch" temp, you doom that branch to 
> not be able to be committed to.

I just wanted to fast-forward my master to -rc7, like the git-merge-ff utility that's been floating around.

> What you should have done, of course, is
> 
> $ git checkout temp
> $ git merge v2.6.22-rc7

But if I'd have changes to my master, I would have examined them and either rebased them or assigned a branch name. It was just a way to either do what I wanted or get an error message, all in one step.

Show 6 quoted lines

>> $ git checkout temp
>> $ (make minor change)
>> $ git commit -a
>> fatal: 087ea061253277de2b27e82d8572a386835a1b7e is not a valid 'commit' object
>> 
>> git-fetch does odd things when handed a tag rather than a commit.

> No. It is perfectly sane to fetch a tag, and to store it.

I suppose, but should the result be put in the "refs/heads" directory?

And until git-merge-ff is available, what's the recommended way to "advance master to tag <foo>, but only if that wouldn't lose anything?"