Instructions concerning detached head lead to lost local changes

Instructions concerning detached head lead to lost local changes

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]

So after some recent experiments to explore all this detached head
stuff, I found myself making a change to my code having forgotten I
had some old state checked out.

So, I tried doing something like:

	git checkout master

in order to get where I wanted to be. I was stopped with the warning:

	You are not on any branch and switching to branch 'master'
	may lose your changes.  At this point, you can do one of two things:
	 (1) Decide it is Ok and say 'git checkout -f master';
	 (2) Start a new branch from the current commit, by saying
	     'git checkout -b <branch-name>'.

At this point, I _knew_ that I didn't care about the state I was
leaving, (it was something random that I had done for testing). So I
definitely didn't want to name it with option (2).

I also knew I hadn't done any commits while detached, which is what I
thought the warning was all about. So I wasn't worried about losing
nothing with option (1).

But I found that after "git checkout -f master" I lost the dirty
changes I had made. And I don't see anything in the message above
telling me a better way to get from the state I was in to the state I
wanted.

I don't know if the "-f" always existed for git-checkout, or if it was
added to support this warning. But clearly, the current warning and
suggestion did not help in this case.

And what would have worked great is if the original checkout had just
worked and carried along my dirty changes, (just as would have
happened if I found I had accidentally made changes while on the wrong
branch instead of accidentally making changes while detached).

Can we fix this please?

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Instructions concerning detached head lead to lost local changes

[Linus Torvalds]

On Thu, 1 Feb 2007, Carl Worth wrote:
> 
> But I found that after "git checkout -f master" I lost the dirty
> changes I had made. And I don't see anything in the message above
> telling me a better way to get from the state I was in to the state I
> wanted.

Yeah, I think "-f" was a mistake. 

There was already real meaning for "-f": force update of all the files, 
regardless of whether they are dirty or unmerged or anything else.

And that meaning is totally independent of the new meaning of -f, which 
says "drop the old detached head". Sometimes you might want to use them 
together, but they shouldn't really be tied together.

Maybe something like this, which adds "--drop" as the flag to say "ok to 
drop the old detached head"? I'm not married to that name, it's meant more 
as an RFC than as anything to be applied as-is.

NOTE! This makes "-f" _imply_ "--drop" too, since it does make sense that 
if somebody just wants to force it, he can - regardless of any dirty 
state, regardless of the current state of the HEAD.

But using just "git checkout --drop new-head" will have the old "dirty 
state follows along with branch changes" semantics.

		Linus

PS. I don't think "--drop" really makes much sense as a name. Especially 
when written out like that, it sounds like we're dropping the *new* 
branch, not the old one. Maybe something like "--no-check" instead?

---
diff --git a/git-checkout.sh b/git-checkout.sh
index deb4795..8e852df 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -11,6 +11,7 @@ oldbranch=$(git-symbolic-ref $old_name 2>/dev/null)
 new=
 new_name=
 force=
+drop=
 branch=
 newbranch=
 newbranch_log=
@@ -36,10 +37,14 @@ while [ "$#" != "0" ]; do
 		;;
 	"-f")
 		force=1
+		drop=1
 		;;
 	-m)
 		merge=1
 		;;
+	--drop)
+		drop=1
+		;;
 	--)
 		break
 		;;
@@ -163,7 +168,7 @@ If you want to create a new branch from this checkout, you may do so
 elif test -z "$oldbranch" && test -n "$branch"
 then
 	# Coming back...
-	if test -z "$force"
+	if test -z "$drop"
 	then
 		git show-ref -d -s | grep "$old" >/dev/null || {
 			echo >&2 \

Re: Instructions concerning detached head lead to lost local changes

[Junio C Hamano]

Carl Worth <cworth@cworth.org> writes:

> At this point, I _knew_ that I didn't care about the state I was
> leaving, (it was something random that I had done for testing). So I
> definitely didn't want to name it with option (2).
>
> I also knew I hadn't done any commits while detached, which is what I
> thought the warning was all about. So I wasn't worried about losing
> nothing with option (1).

Well, the wording could probably be improved because you _did_
care about the state you were leaving (the "state" is not just
what commit HEAD points at), but the suggestions did make it
sound as if your had to choose between only these two, and
neither would have worked for you.

> Can we fix this please?

The question is how.

We can admit that suggestions are just suggestions and listing
only two is more confusing than not saying anything concrete.

Alternatively we could add yet another suggestion that let's you
discard the detached HEAD but still keep your local changes.
Either --drop by Linus renamed to some sensible name, or "the
obscure but useful trick".

I dunno.

Re: Instructions concerning detached head lead to lost local changes

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 463 bytes --]

On Thu, 01 Feb 2007 17:41:11 -0800, Junio C Hamano wrote:
> > Can we fix this please?
>
> The question is how.

Why not just allow the checkout when there's nothing to lose??

Is there some technical reason this can't be done?

It's exactly what I wanted in this case and solves all problems about
how to word the message and what flags to require by not printing any
message and not requiring any flags.

What am I missing here? This seems quite obvious.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Instructions concerning detached head lead to lost local changes

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

On Thu, 01 Feb 2007 17:41:11 -0800, Junio C Hamano wrote:
> The question is how.

I replied already about the no-warning-necessary case.

> Alternatively we could add yet another suggestion that let's you
> discard the detached HEAD but still keep your local changes.
> Either --drop by Linus renamed to some sensible name, or "the
> obscure but useful trick".

But, when the warning is necessary, then I would recommend changing
the -f suggestion to instead suggest --drop, (or whatever it ends up
getting named---I don't care much at all). I think it's fine (and
safer) to just remove the -f option altogether, rather than adding a
third option.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Instructions concerning detached head lead to lost local changes

[Nicolas Pitre]

On Thu, 1 Feb 2007, Junio C Hamano wrote:

> Alternatively we could add yet another suggestion that let's you
> discard the detached HEAD but still keep your local changes.
> Either --drop by Linus renamed to some sensible name, or "the
> obscure but useful trick".
> 
> I dunno.

I have a feeling that proper reflog for HEAD would make the issue so 
much simpler.

But in the mean time I tend to agree with Ted about the fact that simply 
losing the detached position is not _that_ important.  If you go to 
HEAD^ and want to come back to master I think it should just work (with 
a display of what the last position was as Carl mentioned).

It might be some work to get to a given position with a detached head 
and this very position might be valuable information, but if you then do 
"checkout HEAD^" you will still be detached but your previous position 
is lost just like it would be if you moved to master.  Yet you're not 
prevented from going to HEAD^ but you are prevented from going to 
master.

Same issue if you perform a commit on top of a detached head.  Nothing 
prevents you from doing "checkout HEAD^" which will leave your head 
detached but it will also silently drop your last commit dangling.

In short I think there is no magic solution other than proper reflog for 
HEAD.


Nicolas

Re: Instructions concerning detached head lead to lost local changes

[Theodore Tso]

On Thu, Feb 01, 2007 at 09:49:27PM -0500, Nicolas Pitre wrote:
> It might be some work to get to a given position with a detached head 
> and this very position might be valuable information, but if you then do 
> "checkout HEAD^" you will still be detached but your previous position 
> is lost just like it would be if you moved to master.  Yet you're not 
> prevented from going to HEAD^ but you are prevented from going to 
> master.

Exactly.  With Junio's reasoning, then why aren't we forcing -f in this sequence:

git checkout HEAD^
git checkout HEAD^^
git checkout HEAD^^^
git checkout -f master

The first three are just as likely to "lose" information as the last.
Personally, I don't think any of this is "losing" information, any
more than I "lose" information in the following sequence of commands:

cd /usr/src/linux/drivers/net
cd /usr/src/linux/drivers/char
cd /usr/src/linux/fs/ext3
cd /home/tytso

The current working directory is just like the detached HEAD.  If I'm
moving it around, there is no loss of data.  cd != rm.

						- Ted

Re: Instructions concerning detached head lead to lost local changes

[Nicolas Pitre]

On Fri, 2 Feb 2007, Theodore Tso wrote:

> On Thu, Feb 01, 2007 at 09:49:27PM -0500, Nicolas Pitre wrote:
> > It might be some work to get to a given position with a detached head 
> > and this very position might be valuable information, but if you then do 
> > "checkout HEAD^" you will still be detached but your previous position 
> > is lost just like it would be if you moved to master.  Yet you're not 
> > prevented from going to HEAD^ but you are prevented from going to 
> > master.
> 
> Exactly.  With Junio's reasoning, then why aren't we forcing -f in this sequence:
> 
> git checkout HEAD^
> git checkout HEAD^^
> git checkout HEAD^^^
> git checkout -f master
> 
> The first three are just as likely to "lose" information as the last.
> Personally, I don't think any of this is "losing" information, any
> more than I "lose" information in the following sequence of commands:
> 
> cd /usr/src/linux/drivers/net
> cd /usr/src/linux/drivers/char
> cd /usr/src/linux/fs/ext3
> cd /home/tytso
> 
> The current working directory is just like the detached HEAD.  If I'm
> moving it around, there is no loss of data.  cd != rm.

It's just that moving around amongst thousands of commits to pin point a 
particular commit might require some digging work.  This is why there 
might be some value in a particular position and why there is an attempt 
at protecting that "work".

But since moving to another position while still remaining detached from 
any branch has the same potential for losing the important position and 
so without any kind of protection then it makes no sense to have such a 
protection when moving back to a branch.


Nicolas

Re: Instructions concerning detached head lead to lost local changes

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> It's just that moving around amongst thousands of commits to pin point a 
> particular commit might require some digging work.  This is why there 
> might be some value in a particular position and why there is an attempt 
> at protecting that "work".
>
> But since moving to another position while still remaining detached from 
> any branch has the same potential for losing the important position and 
> so without any kind of protection then it makes no sense to have such a 
> protection when moving back to a branch.

Thanks -- I'd agree.

Also I agree that "reflog on HEAD" is the right direction as it
makes these 'protection' unnecessary.  I've applied all your
patches from today on the topic, along with Johannes's "log -g
@{now}".