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?
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
$ 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.
...
No. It is perfectly sane to fetch a tag, and to store it.
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.
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.
quoted
$ 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?"
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:19
Hi,
On Tue, 3 Jul 2007, Jeff King wrote:
On Mon, Jul 02, 2007 at 11:23:15PM -0400, linux@horizon.com wrote:
quoted
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?"
You can ask "do I have anything that foo doesn't?":
test "`git-rev-list foo.. | wc -l`" -gt 0
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
From: Jeff King <hidden> Date: 2016-06-15 22:43:19
On Tue, Jul 03, 2007 at 01:01:49PM +0100, Johannes Schindelin wrote:
If it is only the test, you can do that by
test $(git merge-base foo bar) = $(git rev-parse foo)
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.
(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.
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