Re: [RFC v2] git-multimail: a replacement for post-receive-email

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Feb 25, 2013, 10:50 UTC
Message-ID: <512B4203.3090802@alum.mit.edu>
In-Reply-To: <vpqd2vok9bv.fsf@grenoble-inp.fr>

On 02/25/2013 10:54 AM, Matthieu Moy wrote:

Show 38 quoted lines

> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> On 02/20/2013 01:28 PM, Matthieu Moy wrote:
>>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>>> A while ago, I submitted an RFC for adding a new email notification
>>>> script to "contrib" [...]
>>>
>>> We've discussed offline with Michael, a few patches have been merged,
>>> and there are still a few pending pull requests. I liked the script
>>> already, but it's getting even cooler ;-).
>>>
>>> A few more random thoughts (not on my personal todo-list):
>>>
>>> * It may make sense to add the short sha1 of the new reference in email
>>>   titles (branch foo updated -> branch foo updated to $sha1), so that
>>>   gmail users do not get a single huge thread "branch foo updated".
>>>
>>>   (Yes, I do know about the Reference field, but gmail uses Subject: for
>>>   threading).
>>> [...]
>>
>> I just implemented this in branch sha1s-in-subject [1].  Please let me
>> know if this works for you then I'll merge it to master.  (It depends on
>> the header-handling branch, which also includes your patch for non-ASCII
>> header fields.)
> 
> Works for me. One minor knit: you've included 10-characters sha1s (this
> comes from
> 
>         self.short = read_output(['git', 'rev-parse', '--short=10', sha1])
> 
> ), I'd find it better with shorter sha1s. In the case of branch update,
> if the branch name is a bit long, it could be nice to save a few
> characters.
> 
> Why not just say "git rev-parse --short", without argument? This way,
> the default is used, ie. AFAICT it uses 7 characters by default, but
> will use more if needed to keep the unicity.

I did this intentionally because the SHA1s appear in columns within the refchange emails, and having varying-length SHA1s would cause subsequent columns to be misaligned. I figured that a length of 10, aside from being a number that I can still count on my fingers, would be long enough that it would rarely have to be extended.

I guess I will change the code to use $(git rev-parse --short) (i.e., shorter SHA1s) but reserving 10 columns in tables for them (which can be done via Python string formatting in the templates). That should give the best of both worlds.

Thanks for the feedback!

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/