Re: Difficulties in advertising a new branch to git newbies

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> 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 <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.

-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]