Re: [PATCH v2] allow user aliases for the --author parameter

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

 



Junio C Hamano venit, vidit, dixit 27.08.2008 08:13:
> Jeff King <peff@xxxxxxxx> writes:
> 
>> On Tue, Aug 26, 2008 at 04:31:30PM -0700, Junio C Hamano wrote:
>>
>>>> This allows the use of author abbreviations when specifying commit
>>>> authors via the --author option to git commit. "--author=$key" is
>>>> resolved by looking up "user.$key.name" and "user.$key.email" in the
>>>> config.
>>> Maybe it is just me, but I am hesitant about the contamination of user.*
>>> configuration namespace.  This patch as a general solution does not scale
>>> well, once you start working with more than a few dozen people.
>> It is not just you. I think this version of the patch is much improved,
>> but I am still against user.$key.*. At the very least, it needs its own
>> namespace.
> 
> It's not just that.  Having many of these in .git/config will slow down
> any unrelated thing that needs to read from config.

I don't see a namespace problem as long as nobody uses "name" or "email"
as $key. That said I'd suggest useralias.$key.{name,email} then which
gives a cleaner separation and leaves the possibility to

- use the alias for other cases than --author
- use other fields than name, email

at a later time.

> I am not married to the "reuse existing information" idea, but doing it
> the way this sample patch does at least makes only people who uses this
> feature to pay the price and only when they use it.

People who don't use this feature don't have any entries and don't pay
anything.
People who use this feature and have a moderate number of entries don't
pay a recognizable price.
People who use this feature and have a vast amount of entries should be
told to implement an alias file parser ;)

> Not extensively tested, beyond the usual test suite, and using it for real
> only once to commit this with "git commit --author=Jeff".  I wanted to say
> "Michael J" instead, but there is this little chicken-and-egg problem ;-)
[patch snipped]

I'd be happy with that approach as well for my use case. In general it
may suffer from the uniqueness problem: If there's a recent commit
authored by "Michael@xxxxxxxx" your "--author=Jeff" will resolve
differently from yesterday, and you won't even notice (not even commit
-v tells you). [ A typo is punished by a search through all commits;
that's fine.]

But I won't compete with an alternative patch from The Man, of course ;)

+	die("No existing author found with '%s'", name);
Minor suggestion:
"...or malformed --author parameter"
I foresee questions like "Huh? What does it mean not existing" when
people don't get the A U Thor <author@xxxxxxxxxxx> format right.

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

[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]

  Powered by Linux