Simon Oosthoek venit, vidit, dixit 15.10.2012 15:20: > Hi Michael, sorry for the duplicate, forgot to reply-all... > > On 10/15/2012 11:13 AM, Michael J Gruber wrote: > >> ...only because you don't know the color coding scheme. It's green >> because those changes are saved somewhere (in the index) and would even >> survice a branch switch. >> > > But git doesn't exactly let you do this: > I modified some things in git-prompt.sh trying to implement some of what > we discussed. Then staged the file and tried git checkout HEAD^^ (or any > branch) > > error: Your local changes to the following files would be overwritten by > checkout: > contrib/completion/git-prompt.sh > Please, commit your changes or stash them before you can switch branches. > Aborting > > So I don't think it's all that strange to mark the branch as not quite > safe to change. The idea (or at least my idea) behind these hints is > that it reminds me to do stuff that prevents these "Aborts". I think > that that is a useful feature for any user of git. > > In this light, would you accept yellow in the branch color to indicate > uncommitted staged changes? No, simply because it's not up to me to accept something ;) I still think that following "git status -sb" would be the least confusing solution, and that means - green for a checked out branch, where you know that any committed changes will not be "lost" - red for a detached head, where any committed changes will only be accessible from the reflog, and only until pruned. I'm open to change "git status -sb", but I think having the branch coloring and the status character coloring be independent has quite some merit. (Your yellow branch just duplicates the information "there are staged changes".) Also note that in your example above, you cannot switch branches because your staged changes overlap with the changes in the branch that you want to switch to (changes relative to your current head). Otherwise, you could have switched. The only way to find out whether there's such a conflict is to actually try it, and that is too heavy for a prompt command. Michael -- 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