On Wed, Jan 31, 2007 at 09:59:08AM -0500, Nicolas Pitre wrote:

quoted text
> I disagree again.  Making commits on a detached head is not dangerous.
> 
> What is dangerous is moving away from the tip of that detached head 
> without attaching it somewhere.  And that case is well covered already.

Sure, the dangerous thing is moving away. But my point is there are many
steps leading up to that, and we can warn at any one. However, the
warning is _most_ useful as close to the dangerous thing as possible
(ideally, we would warn when doing the actual dangerous thing, but IIRC,
there was some complexity with that).

IOW, here's a rough flow chart of states and user actions:
         checkout non-branch          commit, etc
(1) regular  ---------> (2) detached,  --------> (3) detached,
         ^                  no commits                commits
         |  checkout branch |  checkout old branch     /\
          \-----------------<--------------------------  |
                                                         |  checkout
                                                         | new branch
                                                         v
                                                   (4) new regular branch

Hopefully my ASCII art skillz are coherent enough. The actual
"dangerous" thing here is moving from 3 to 1. We can theoretically warn
at any transition. Right now we warn moving from 1 to 2. But a large
number of users are just going to go right back to 1, never even doing
anything dangerous! For them, the warning is confusing. I'm proposing
warning between 2 and 3. I would also be happy with warning (and
probably blocking without -f) moving from 3 to 1, which is the actual
dangerous thing. However, I think putting a warning between 2 and 3 is
reasonable, because the next step the user will make from 3 is either
moving to 1 (dangerous) or to 4 (ok), and they must use the correct
git-checkout invocation. So basically, it's our last chance (besides the
actual git-checkout itself) to warn them.

quoted text
> Also the warning when moving to a detached head is useful to make the 
> user aware of what just happened because there is really something 
> special about such checkout.  It is not meant to frighten users and if 
> it does so then maybe it should be reworked some more.  But IMHO it is 
> important that the user be aware of this special state.

What is so special about it? My argument is that it is not really very
special _until you make commits_. Are there other operations which we
should be warning people about if they have a detached head?

quoted text
> But making a warning at commit time is wrong. It is completely 
> disconnected from the actual issue and I think it'd create more 
> confusion because there is in fact nothing to worry about at the moment 
> the commit is made.  The very fact that you think yourself that a 
> warning should be displayed at commit time indicates to me that you 
> might be a bit confused yourself and such warning if present at commit 
> time wouldn't help clearing that confusion at all.

I think you are proving my point here. If you think warning at commit
time is too early, then how is warning _before_ that (when we detach)
not too early?

quoted text
> In Carl's case suggesting -f is probably not a good idea.  Using -f _is_ 
> dangerous and we better not get people into the habit of using -f 
> without thinking.

Agreed.

quoted text
> Let's focus on the real issue: the warning message when head gets 
> detached.  This message is not meant to frighten users.  It is meant to 
> make the user aware of a special state (pretty useful but special 
> nevertheless) and give a suggestion about what to do if that state was 
> entered by mistake.  So if that message scares users away then it is the 
> message itself which is buggy not its presence.

Again, I don't understand why the state is special (aside from the
possibility of losing commits).

-Peff
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html