Carl Worth <cworth@xxxxxxxxxx> writes:
> On Tue, 02 Jan 2007 14:44:31 -0800, Junio C Hamano wrote:
> ...
>> In any case, I did this because I got tired of waiting for it to
>> happen (I thought you wanted to hack on this over the long
>> week^W yearend, so I deliberately stayed away from doing this)
>> and I was bored. This will not be in 'next' in the current
>> shape.
> ...
> I don't actually prefer "no commit allowed". I just didn't want the
> user to have to explicitly disable the safety before being able to
> perform a checkout based on a tag.
>
> I am still interested in this feature,...
I decided to fast-track this one. With a handful fix-ups, this
is now at the tip of 'next'.
The primary difference from the one we discussed, and then has
been sitting in 'pu', is that coming back from the detached HEAD
state is allowed only with '-f' or to a branch that is a
fast-forward of HEAD.
So you can do:
git checkout v1.2.0 ;# detach
... look around ...
git checkout v1.4.0 ;# still detached
... look around ...
git checkout master ;# Ok, because v1.4.0 is an ancestor of master
but you would be warned and asked to say -f if you do:
git checkout v1.4.0 ;# detach
edit ...
git commit -a -m 'some tweak'
git checkout master ;# Not Ok -- you may lose that commit.
An alternative exit in this case is to create a new branch at
that point. So this does work:
git checkout v1.4.0 ;# detach
edit ...
git commit -a -m 'some tweak'
git checkout -b maint-1.4.0 ;# start the maint-1.4.0 branch
Have fun.
-
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