From: Junio C Hamano Date: Wed, 31 Jan 2007 01:34:07 GMT Subject: Re: Difficulties in advertising a new branch to git newbies Message-ID: <7vzm80vv1s.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <20070130231015.GB10075@coredump.intra.peff.net> Jeff King writes: > On Tue, Jan 30, 2007 at 12:13:26PM -0800, Carl Worth wrote: > >> Also, if I'm willing to assume (or insist) that users have git 1.5 or >> newer, it'd be nice to be able to drop the "-b build" thing thanks to >> the new detached HEAD support. But if I suggest doing just: >> >> git checkout origin/proposed-fix >> >> the user is presented with the following message which is much more >> scary than useful in this situation: >> >> warning: you are not on ANY branch anymore. >> If you meant to create a new branch from the commit, you need -b to >> associate a new branch with the wanted checkout. Example: >> git checkout -b origin/proposed-fix > > I don't see any reason why we can't scare the user when making a commit, > instead of just checkout out to look around. Something like the patch > below. It needs a few things: > - remove the old checkout message > - we wrap the colorization over the multi-line message. Probably a > color_printf_lines() function should be added > - if colorization is enabled, print it using color.status.warning > (default to red). > > I'm happy to make all those happen if there is interest (Junio, please > comment). That does not protect anything other than interactive "git commit". People often do "git commit -m" or "git commit -C". In addition, rebasing a detached HEAD, merging into a detached HEAD, cherry-picking onto a detached HEAD or running reset on a detached HEAD to move to a particular state you want to look at are all useful and valid operations, and you wouldn't get any warning when you do so. I do not think warning at every step that you are "in a funny state" does not help productivity, so I'd prefer warning upfront once and be silent afterwards, until you try to come back with "git checkout ", potentially losing your state, which is what we currently do. Having said that, I think making "git checkout -f" not to issue the warning might be enough. Actually, I would even say it would make perfect sense. For situations like Carl's intstruction where a user, who is purely a sightseer, uses the detached HEAD to go-and-look a particular state, the fact that "-f" loses the previous local modifications is not an issue at all. On the other hand, if the user is a developer who uses git, the warning upfront (if we want to keep it for educational purposes, to make people aware of what is happening) is useful without "-f", and when a user who is using git to manage his own development, he hopefully knows what "git checkout -f" means to his local modifications already.