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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 02/25/2013 10:54 AM, Matthieu Moy wrote:
> Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:
> 
>> On 02/20/2013 01:28 PM, Matthieu Moy wrote:
>>> Michael Haggerty <mhagger@xxxxxxxxxxxx> 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@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]