Re: [PATCH] Add bare repository indicator for __git_ps1

[Marius Storm-Olsen <marius@trolltech.com>]

Michael J Gruber said the following on 20.02.2009 17:39:
>> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
>> rv:1.8.1.19) Gecko/20081209 Lightning/0.9 Thunderbird/2.0.0.19
>> ThunderGit/0.1a Mnenhy/0.7.6.666

Heh, you noticed the user-agent extra \o/ :-)


> Marius Storm-Olsen venit, vidit, dixit 20.02.2009 15:56:
>> Prefixes the branch name with "BARE:" if you're in a bare 
>> repository.
>> 
>> Signed-off-by: Marius Storm-Olsen <marius@trolltech.com> ---
>> Patch tried sent via ThunderGit extension. Sorry if it's mangled
>> :-)
> 
> Now what's that ThunderGit thingy? ;)
> 
> Seriously, I see you and Dscho have been carrying this on, and soon
> external commands may be lauched. Is this going in a git specific 
> direction rather than attaching patch files unmangled (UnflowedTB)?

Well, Dscho's intentions was, as the project name says, to simply send 
patches unflowed. I have, however, had many other features which I 
would like to see in a Git extension, which is why called it 
ThunderGit instead. First I want the extension to help with Best 
Practices for sending patches. Second, I want the extension to have 
neatness like:

   1) Saving a whole patch series as a mailbox, for easy apply. Maybe
      even a "create new branch based on <branch>, and apply series"
      feature? ^shrug^

   2) Send patch (series) based on a selected email
      (ie. setting "references" based on selection)

   3) Showing Git patches with diff coloring (maybe also in the
      editor, but mostly for received mails)

   4) Basic validation of patch before sending, like
      a) trailing whitespace
      b) consistent preceding whitespaces
      c) <add favorite>

This is my first extension though, so any help from people "in the 
know" would be great!

If all attempts fail to make the extension fool proof wrt sending 
proper unflowed patches, we could always just use Thunderbird as the 
front-end for 'git send-email' ;-) I'm almost tempted to already go 
that route, simply to avoid all the hassle. Then we could also just 
use the plaintext composer, instead of the HTML composer which isn't 
exactly "fool proof" for plaintext patches.

--
.marius