Re: [PATCH] Show branch information in short output of git status

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: May 25, 2010, 07:19 UTC
Message-ID: <4BFB79F6.5070501@drmicha.warpmail.net>
In-Reply-To: <20100523092348.GA16811@coredump.intra.peff.net>

Jeff King venit, vidit, dixit 23.05.2010 11:23:

Show 20 quoted lines

> On Fri, May 14, 2010 at 08:54:07AM +0200, Knittl wrote:
> 
>>> That being said, I still get "Initial commit on master". I think that
>>> stat_tracking_branch just gives up if the branch doesn't exist (which
>>> does make some sense). So in practice, I think your original and this
>>> one actually behave the same (sorry, I know that changing it was my
>>> suggestion).
>>
>> yep, that's what i discovered too—but i don't care if this condition
>> is 3 lines up or down. if stat_tracking_branch decides it will work
>> for initial commits, then this code will do the expected thing
> 
> Agreed.
> 
>> should be no problem. the second patch changed quite a bit, so i
>> thought it is easier to review when i send it as a separate patch. the
>> final patch can be squashed of course
> 
> OK.  Nobody else seems to be commenting, so I would go ahead and put
> together your final patch, cc-ing the maintainer.

Been following silently :)

I'm a regular shortstatus user and find myself calling ordinary status just to get that part of info you're adding to shortstatus. I agree the default should stay as is and use aliases anyways. (I also think we need to clean up our option/config mess at one point and make at least long options the same as config variables.)

I even wanted to try out the patch but was stopped by:

Show 12 quoted lines

> 
>>>  2. Your patch has wrapped lines which make it impossible to apply
>>>     without fixing up manually. This is a common gmail problem.  See
>>>     the "gmail" section of SubmittingPatches.
>>
>> ok, browsed through that. i think i will just put my branch into a
>> pasteservice or on a fileserver, unless the email way is *really*
>> preferred—what about email attachments?
> 
> Inline email is best, but I think an email attachment would be preferred
> to putting it on some out-of-band service (it's nice for the mailing
> list archive to have a record of everything).

I'm really wondering what the problem is with git-send-email + GMail's smtp. I'm not saying there is none: I'm just observing that we seem to attract a lot of new contributors lately and that the email-inline-patch requirement seems to be a hurdle to quite a few. I've created a mob branch at

http://repo.or.cz/w/git/mjg.git

based off current master to which you can push, Daniel.

I'm wondering whether we should have a mob branch+receive hook solution where people can push to mob-{maint,master,next} (whose tip coincides with the resp. main branches), maybe allowing fast-forwards only, and where a post-receive-hook hook sends the patch to the list and resets the mob-... branch.

That would require push/pull expertise only, no MUA tweaking necessary.

Cheers, Michael