Re: Difficulties in advertising a new branch to git newbies
- From
Junio C Hamano <junkio@cox.net>
- Date
- Jan 31, 2007, 01:34 UTC
- Message-ID
- <7vzm80vv1s.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <20070130231015.GB10075@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 27 quoted lines
> 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 <new_branch_name> 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 <existing branch>", 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.