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