Jeff King venit, vidit, dixit 23.05.2010 11:23: > 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: > >>> 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 -- 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