Conrad Irwin <conrad.irwin@xxxxxxxxx> writes:
> In the process of changing things around to do this, I noticed that
>
> git branch -M <foo> <current-branch>
>
> surprisingly works, and does confusing things, in that you will get a:
>
> $ git rev-parse HEAD@{1}
> warning: Log .git/logs/HEAD has gap after Fri, 19 Aug 2011 02:00:09 -0700
>
> Presumably this is the reason that git branch -f forbids you from
> changing the current branch?
[jc: edited typo in the original command exhibition]
I also suspect that "git status" will become nonsense at that point, as
the working tree and the index were still the original state while the
commit pointed by HEAD have changed underneath you.
And you are correct to point out that it is why "git branch -f" shouldn't
touch the current branch. We should notice the situation and error out.
Patches welcome.
I initially thought that such a patch can optionally as a bonus suggest an
alternative way to confuse yourself, e.g. "git reset --soft <foo>", which
is what is happening, but I do not think it makes sense, especially with
"--soft", either.
The user is saying "I know the <current-branch> exists already, and I want
it to match the tip of <foo> branch", without saying what should happen to
what is in the working tree, so depending on what s/he wants, either "git
reset --hard <foo>" or "git reset --keep <foo>" followed by "git branch -d
foo" would be the right thing to do, and I would imagine that one could
even argue that "git branch -M <foo> <current-branch>" should do exactly
that under the hood, but the <current-branch> may be a typo and the user
may have meant to affect some other branch, so in order to play it safe,
just an error message without any advice based on a vague second-guess of
the user's intention, would be the most appropriate, I would think.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html