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

Re: [PATCH] commit: Add -f, --fixes <commit> option to add Fixes: line

From
Johan Herland <johan@herland.net>
Date
Oct 30, 2013, 17:53 UTC
Message-ID
<CALKQrgc297dqaxBNDT-N831a94gF7TyDrjt2y4DpOdT_tkyayA@mail.gmail.com>
In-Reply-To
<87txg1hwsa.fsf@linux-k42r.v.cablecom.net>
On Mon, Oct 28, 2013 at 11:10 PM, Thomas Rast <tr@thomasrast.ch> wrote:
Show 15 quoted lines
> Johan Herland <johan@herland.net> writes:
>> But I still don't see exactly what this option should do (inside "git
>> commit") that would end up being useful across most/all projects, and
>> not just something that could more easily be implemented in the
>> *commit-msg hooks for relevant projects.
>
> [Ok, admittedly I don't really know what to quote from your message,
> since I'm mostly responding to the overall concept.]
>
> I like the idea of putting all that in hooks, but I have two
> observations:
>
> * Signed-off-by: is already such a case (and was probably also added for
>   the kernel?) that _could_ have been dealt with using {prepare-,}commit-msg,
>   but has its own support in various git tools.

Yes, and I don't like using the precedent of "Signed-off-by" as an argument to push support for more (IMHO project-specific) footers into core Git. Hence, I'd rather see the "Signed-off-by" reimplemented as a hook (obviously, the -s option for "git commit" would have to remain for backward-compatibility).

Show 19 quoted lines
> * In your list
>
>>   Fixes:
>>   Reported-by:
>>   Suggested-by:
>>   Improved-by:
>>   Acked-by:
>>   Reviewed-by:
>>   Tested-by:
>>   Signed-off-by:
>
>   and I might add
>
>     Cherry-picked-from:
>     Reverts:
>
>   if one were to phrase that as a footer/pseudoheader, observe that
>   there are only two kinds of these: footers that contain identities,
>   and footers that contain references to commits.

I'm not so sure we can make those assumptions. One might conceivably imagine a "Fixes:" footer that refers to a bug ID, and not a commit. Also, projects might want to apply different rules on what may appear in which footer. E.g. one could e.g. want to enforce that the ident listed in "Reviewed-by:" or "Signed-off-by:" must always appear in a project-specific REVIEWERS.txt or AUTHORS.txt file. Since we don't really know what projects might want, we shouldn't make too many assumptions on how these footers will be used... That said, I am not (or at least no longer) opposed to generic support in core Git for processing these footers, as long as that support is flexible/generic in nature, and equally available to be reused from within hooks as from within core Git.

Show 24 quoted lines
> So why not support these use-cases?  We could have something like
> footer.foo.* configuration, e.g.
>
> [footer "fixes"]
>         type = commit
>         suggest = true
> [footer "acked-by"]
>         type = identity
>
> where 'suggest' (please suggest a better name) means that git-commit
> will put a blank one in the commit message template for you to fill in.
> 'commit' and 'identity' can have some elementary expansion and
> validation tied to them.  Some easy extensiblity (hooks?) might not
> hurt, but then as you point out, the existing hooks already cover that.
>
> Perhaps we could also have, for Gerrit (cf. [1]):
>
> [footer "change-id"]
>         type = uuid
>
> though admittedly I haven't investigated if it's okay to just put a
> random string there, or it needs to have a specific value.
>
> [1]  http://thread.gmane.org/gmane.comp.version-control.git/236429

How the config ends up looking is not actually that interesting to me (not at this stage, at least). My objection is to adding support for specific footers with specific interpretations tailored specifically for one (or a few) projects. Such things only open the door to more bloat. Instead, we already have the hooks for implementing such project-specific rules and conventions. This is the core of my argument. Since then, the discussion has moved towards generic and flexible support for commonly-used footers, and I don't really have a problem with that, as long as it is easily reusable (and extensible) by a project's own hooks.

...Johan
-- 
Johan Herland, <johan@herland.net>
www.herland.net
Previous: Jeff KingNext: Christian Couder
Message 14 of 49 in “commit: Add -f, --fixes <commit> option to add Fixes: line”
  1. commit: Add -f, --fixes <commit> option to add Fixes: lineJosh Triplett, Oct 27, 2013
  2. Michael HaggertyOct 27, 2013
  3. Theodore Ts'oOct 27, 2013
  4. Josh TriplettOct 27, 2013
  5. Michel LespinasseOct 27, 2013
  6. Josh TriplettOct 27, 2013
  7. Thomas RastOct 27, 2013
  8. Josh TriplettOct 27, 2013
  9. Johan HerlandOct 27, 2013
  10. Christian CouderOct 27, 2013
  11. Johan HerlandOct 28, 2013
  12. Thomas RastOct 28, 2013
  13. Jeff KingOct 29, 2013
  14. Johan HerlandOct 30, 2013
  15. Christian CouderOct 29, 2013
  16. Johan HerlandOct 30, 2013
  17. Christian CouderNov 2, 2013
  18. Stefan BellerOct 27, 2013
  19. Thomas RastOct 27, 2013
  20. Stefan BellerOct 27, 2013
  21. Stefan BellerOct 31, 2013
  22. Documentation: add a script to generate a (long/short) options overviewStefan Beller, Oct 31, 2013
  23. Stefan BellerOct 31, 2013
  24. brian m. carlsonOct 31, 2013
  25. Junio C HamanoNov 1, 2013
  26. Michael HaggertyOct 28, 2013
  27. Johan HerlandOct 28, 2013
  28. Jeff KingOct 29, 2013
  29. Matthieu MoyOct 29, 2013
  30. Johan HerlandOct 30, 2013
  31. Duy NguyenOct 31, 2013
  32. Junio C HamanoOct 31, 2013
  33. Duy NguyenOct 31, 2013
  34. Johan HerlandNov 1, 2013
  35. Duy NguyenOct 27, 2013
  36. Josh TriplettOct 27, 2013
  37. Jim HillOct 28, 2013
  38. Junio C HamanoOct 28, 2013
  39. Josh TriplettOct 28, 2013
  40. Michael HaggertyOct 28, 2013
  41. Christoph HellwigOct 28, 2013
  42. Benjamin HerrenschmidtOct 28, 2013
  43. Russell King - ARM LinuxOct 28, 2013
  44. Russell King - ARM LinuxOct 28, 2013
  45. Junio C HamanoOct 28, 2013
  46. Christian CouderOct 29, 2013
  47. Junio C HamanoOct 29, 2013
  48. Tony LuckOct 30, 2013
  49. Junio C HamanoOct 30, 2013

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.