git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [bug] blame duplicates trailing ">" in mailmapped emails

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
Feb 6, 2012, 23:11 UTC
Message-ID
<CAMP44s3i3eE8mVGHBB5zUdcX95+KEz9xcC1B3B6qON1StD=FXQ@mail.gmail.com>
In-Reply-To
<7vliof62ko.fsf@alter.siamese.dyndns.org>
On Tue, Feb 7, 2012 at 12:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 15 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> This subject doesn't explain the *purpose* of the patch: always return
>> a plain mail address from map_user()
>
> That would be a much better subject.
>
>> I think the immediate problem should be here:
>>
>> Currently 'git blame -e' would add an extra '>' if map_user() returns
>> true, which would end up as '<foo@bar.com>>'. This is because
>> map_user() sometimes modifies, the mail string, but sometimes not. So
>> let's always modify it.
>
> That is just a symptom.

That's a matter of semantics. Is the API broken? Then the API has a problem, and you are fixing it, otherwise you are merely *improving* it.

> People who reached this commit by digging the
> history of mailmap.c would need to see the *cause* of the symptom
> described in the light of how the API is designed to be used.

Well, when you have a summary as "always return a plain mail address from map_user()", I think it's pretty clear what is the "problem"; the API does not always return a plain mail address. But any case, that is described below, in my suggestion.

Besides, even people digging the history would benefit from seeing the "symptom" first.

> In other
> words, "the code after the update has to be this way because these are the
> i/o constraints this API has".  "Otherwise you would see this breakage for
> example" is merely a supporting material.

I disagree. The reader of the current commit message will keep in his/her head the question "Why?", and it would be answered only at the very end. Besides, what more succinct way to describe a problem with the API than with an example (that happens to be real).

-- 
Felipe Contreras
Previous: Junio C HamanoNext: Junio C Hamano
Message 29 of 38 in “completion: couple of cleanups”
  1. 0/4 completion: couple of cleanupsFelipe Contreras, Feb 2, 2012
  2. Jonathan NiederFeb 2, 2012
  3. Felipe ContrerasFeb 2, 2012
  4. Thomas RastFeb 2, 2012
  5. Jonathan NiederFeb 2, 2012
  6. Jonathan NiederFeb 2, 2012
  7. Felipe ContrerasFeb 2, 2012
  8. Junio C HamanoFeb 2, 2012
  9. Felipe ContrerasFeb 2, 2012
  10. Junio C HamanoFeb 3, 2012
  11. Felipe ContrerasFeb 3, 2012
  12. Junio C HamanoFeb 3, 2012
  13. Felipe ContrerasFeb 4, 2012
  14. [bug] blame duplicates trailing ">" in mailmapped emailsJeff King, Feb 4, 2012
  15. Felipe ContrerasFeb 4, 2012
  16. Jeff KingFeb 4, 2012
  17. Felipe ContrerasFeb 5, 2012
  18. Jeff KingFeb 5, 2012
  19. Junio C HamanoFeb 5, 2012
  20. Junio C HamanoFeb 5, 2012
  21. Jeff KingFeb 5, 2012
  22. Junio C HamanoFeb 6, 2012
  23. Jeff KingFeb 6, 2012
  24. Junio C HamanoFeb 6, 2012
  25. Junio C HamanoFeb 6, 2012
  26. Jeff KingFeb 6, 2012
  27. Felipe ContrerasFeb 6, 2012
  28. Junio C HamanoFeb 6, 2012
  29. Felipe ContrerasFeb 6, 2012
  30. Junio C HamanoFeb 5, 2012
  31. Jonathan NiederFeb 2, 2012
  32. Junio C HamanoFeb 2, 2012
  33. Jonathan NiederFeb 2, 2012
  34. Felipe ContrerasFeb 2, 2012
  35. Jonathan NiederFeb 2, 2012
  36. Felipe ContrerasFeb 2, 2012
  37. Jonathan NiederFeb 2, 2012
  38. Felipe ContrerasFeb 2, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.