"Drew DeVault" <drew@xxxxxxxxxxxx> writes:
> Trailers and headers are different. The main point of the change-id
> discussion earlier on this list was to avoid adding trailers.
It sounds like this "avoiding trailers" is the root cause of the
problem. If change-id is something not precious as you earlier
said, having various operations lose it by design or by accident
may not hurt a lot, but then doesn't it make it harder to notice
by hiding it in a non-standard commit header field? There is no
easy way to tell "git log --format" to show such a custom header,
you'd need to tell amend, rebase, cherry-pick, etc. to carry the
custom header forward (or not---have all the change-id loving
communities agreed on when to propagate and when not to?).
Keeping it as one of the trailer fields will always make it
available [*], propagate existing one by default with any existing
tool, and because it is in the same place as log message, the user
can easily remove it if it is not appropriate to keep it.
Side note: [*] Unless you are doing "log --oneline", that is,
but I'd say at that point you are hiding it deliberately.
> I also suspect that if we added this as an "inbody header" that older
> git implementations would ingest the X-Change-ID header into the commit
> message, which is not a desirable behavior.
Of course not. If the thing is a trailer, you do not even have to
worry about such sillyness caused by adding it as a new in-body
header.
> IMO the right way forward is to use a mail header.
No. In the change-id case, trailer is the right way to go.
Having said all that, you may sense that I am not all that impressed
by the previous rounds of dicsussions arguing for recording
change-id as an extra non-standard commit header. We should think
twice or more before making anything that structurally does not
cause Git to behave differently taking advantage of the information
recorded there an extra commit header field.
But after thinking thrice, we may find a set of good pieces of
information that should be added as new commit header that are
structurally more meaningful, and there will be times when we need
to convey them over e-mailed workflow to allow patch recipient not
to lose such information.
In such a case, I fully agree that embedding in an e-mail header
would be the way to go.
I would suggest a lot more generic implementation to solve it once
and for all. How about doing it more like this:
"git format-patch --extra-headers" grabs all extra headers
(i.e. those that are not the bog-standard "tree", "parent",
"author", "committer") and emit these
X-git-extra-commit-header: encoding=iso8859-1
X-git-extra-commit-header: frotz=nitfol
next to "Subject:", etc.
