Re: Difficulties in advertising a new branch to git newbies
- From
Jeff King <peff@peff.net>
- Date
- Jan 31, 2007, 17:07 UTC
- Message-ID
- <20070131170752.GA19527@coredump.intra.peff.net>
- In-Reply-To
- <Pine.LNX.4.64.0701310932320.3021@xanadu.home>
On Wed, Jan 31, 2007 at 09:59:08AM -0500, Nicolas Pitre wrote:
> 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 branchHopefully 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.
Show 5 quoted lines
> 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?
Show 7 quoted lines
> 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?
> 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.
Show 6 quoted lines
> 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