git-fetch will leave a ref pointing to a tag

I did this while trying to force a fast-forward merge (I wanted an error message if I had changes to merge), and got a somewhat obscure error message:

$ git branch temp tags/v2.6.22-rc6 $ git fetch . tags/v2.6.22-rc7:temp $ 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. Also, should "git checkout" have complained?

Hi,

On Mon, 2 Jul 2007, linux@horizon.com wrote:

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

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.

What you should have done, of course, is

$ git checkout temp $ git merge v2.6.22-rc7

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

Maybe. Dunno.

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Yes, but not to a branch.

Anything under refs/heads/ should point at a commit and if we allowed a tag to be pointed at, you probably can argue that is a bug.

Hi,

On Mon, 2 Jul 2007, Junio C Hamano wrote:

Ooops. I forgot to write that (as the "No" at the beginning suggests...).

Thank you, Dscho

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.

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

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.

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?"

On Mon, Jul 02, 2007 at 11:23:15PM -0400, linux@horizon.com wrote:

You can ask "do I have anything that foo doesn't?":

  test "`git-rev-list foo.. | wc -l`" -gt 0

-Peff

Hi,

On Tue, 3 Jul 2007, Jeff King wrote:

If it is only the test, you can do that by

	test $(git merge-base foo bar) = $(git rev-parse foo)

(which tests if foo is a stricth ancestor of bar). Although in your (linux@horizon.com's) place I would really look at "git log foo.." myself, as peff almost suggested.

For if you (linux@horizon.com) _have_ changes, you want to know which changes they are, right?

Of course, it seems to me that what you (linux@horizon.com; do you really have no proper name?) _really_ wanted to do is "git rebase v2.6.22-rc7".

Ciao, Dscho

On Tue, Jul 03, 2007 at 01:01:49PM +0100, Johannes Schindelin wrote:

I had thought that calculating the merge base was actually slightly less efficient in this case, since it will actually find all of the merge bases (but I could very well be wrong). But really, either should produce the result effectively instantaneously.

Yes. In fact, I find an even more useful operation in that case to be "gitk foo..." to see "where I'm at" with respect to my changes and upstream changes.

-Peff