josh@joshtriplett.org writes:
Author and committer are used by many git tools; if they weren't part of
the object header, they'd need to be part of some pseudo-header with a
standardized format that git can parse.
Yes, the same goes to the address on Signed-off-by: footers. There
recently was a series to enhance the footer list handling (Christian
Cc'ed) for the generation and maintenance side, and I do think it is
reasonable to further add enhanced support for footers.
That does not argue for having a new "coauthor" as a new commit
object header at all, though.
Junio C Hamano wrote:
josh@joshtriplett.org writes:
quoted
Author and committer are used by many git tools; if they weren't part of
the object header, they'd need to be part of some pseudo-header with a
standardized format that git can parse.
Yes, the same goes to the address on Signed-off-by: footers. There
recently was a series to enhance the footer list handling (Christian
Cc'ed) for the generation and maintenance side, and I do think it is
reasonable to further add enhanced support for footers.
That does not argue for having a new "coauthor" as a new commit
object header at all, though.
The threshold for modifying commit object is high. This is an
ABI-level change, something to do if there is no other solution.
Author and committer include datetime in the contents of the
field, which is used by Git for heuristics limiting walk. Coauthor
would have the same date as author, isn't it? If, after long
and involved discussion, we didn't add 'generation' field (for
easier cutting history walking), what chance adding 'coauthor'
has.
OTOH it would be nice to have support for .mailmap, and for
grepping... but the former could conceivably be added to the trailer
tool, the latter can be done with appropriate regexp in
"git log --grep=...".
I wonder what would break if one used 'Name <e@mai.l>, Name <em@i.l>'
as the author...
--
Jakub Narębski
On Thu, Jun 18, 2015 at 11:25:44PM +0200, Jakub Narębski wrote:
Author and committer include datetime in the contents of the
field, which is used by Git for heuristics limiting walk. Coauthor
would have the same date as author, isn't it? If, after long
and involved discussion, we didn't add 'generation' field (for
easier cutting history walking), what chance adding 'coauthor'
has.
I don't think the two situations are comparable. I would (and did) argue
that a "generation" field is a bad header to bake in because of what it
means (it is redundant with the graph structure).
Whereas "co-author" is not a fundamentally bad; it's just not something
we chose to support early on, and it would have to be added now.
OTOH it would be nice to have support for .mailmap, and for
grepping... but the former could conceivably be added to the trailer
tool, the latter can be done with appropriate regexp in
"git log --grep=...".
I don't think we munge trailers during "git log" pretty-printing at all
now, but it is certainly something we could add (including mailmap-ing
them). That doesn't seem like much more work than showing the co-author
field, and it's a lot more generally applicable (you could mailmap
S-O-B, Reviewed-by, and so forth).
Similarly, something like "git shortlog" would have to learn about
multiple authors under the "co-author" scheme. But likewise, it would
not be much more work to teach it something like:
git shortlog --field=Reviewed-by
to handle an arbitrary trailer. And that is much more flexible.
I wonder what would break if one used 'Name <e@mai.l>, Name <em@i.l>'
as the author...
The "normal" parser we use for pretty-printing goes left-to-right and
will stop at the first ">", and show only the first author.
Older versions of git would then get the date wrong, complaining about
the ",". Newer versions parse the date from right-to-left to work around
such bogosities (especially things like "<foo <bar>>") and so will parse
back to the second ">".
Fsck will definitely complain about it.
-Peff
On 2015-06-19 at 06:25, Jeff King wrote:
On Thu, Jun 18, 2015 at 11:25:44PM +0200, Jakub Narębski wrote:
quoted
Author and committer include datetime in the contents of the
field, which is used by Git for heuristics limiting walk. Coauthor
would have the same date as author, isn't it? If, after long
and involved discussion, we didn't add 'generation' field (for
easier cutting history walking), what chance adding 'coauthor'
has.
I don't think the two situations are comparable. I would (and did) argue
that a "generation" field is a bad header to bake in because of what it
means (it is redundant with the graph structure).
Whereas "co-author" is not a fundamentally bad; it's just not something
we chose to support early on, and it would have to be added now.
It is true that "generation" field is redundant with the graph
structure, but it is
not necessarily something bad. You don't avoid using red-black trees or
AVL trees
because they keep some _redundant_ "bookkeeping" data in the node structure.
Same for "generation" header: it is bookkeeping, but would make Git more
effective
(faster).
Though I don't think any distributed version control system store such
data in
their equivalent of commit objects... maybe Veracity (I didn't check)...
quoted
OTOH it would be nice to have support for .mailmap, and for
grepping... but the former could conceivably be added to the trailer
tool, the latter can be done with appropriate regexp in
"git log --grep=...".
I don't think we munge trailers during "git log" pretty-printing at all
now, but it is certainly something we could add (including mailmap-ing
them). That doesn't seem like much more work than showing the co-author
field, and it's a lot more generally applicable (you could mailmap
S-O-B, Reviewed-by, and so forth).
This is certainly something nice to have. Though for author and
committer (and also
for tagger if I remember it correctly) we have mailmap-aware and
not-mailmapped
versions. There isn't anything like that for trailers.
Similarly, something like "git shortlog" would have to learn about
multiple authors under the "co-author" scheme. But likewise, it would
not be much more work to teach it something like:
git shortlog --field=Reviewed-by
to handle an arbitrary trailer. And that is much more flexible.
It would also be nice to have something like this for blame... but at
least multiple
authors support doesn't make much sense wrt display uless using graphical
blame tool (like "git gui blame").
quoted
I wonder what would break if one used 'Name <e@mai.l>, Name <em@i.l>'
as the author...
The "normal" parser we use for pretty-printing goes left-to-right and
will stop at the first ">", and show only the first author.
Older versions of git would then get the date wrong, complaining about
the ",". Newer versions parse the date from right-to-left to work around
such bogosities (especially things like "<foo <bar>>") and so will parse
back to the second ">".
Fsck will definitely complain about it.
Ah, that is a problem.
If I remember correctly, I have seen somewhere using Bob+Alice for the
name part
and [off-list ref] or <bob@emai.l+alice@em.ail> for the email
part...
Would this work, I wonder?
[hoping that Thunderbird email didn;t screw up formatting]
--
Jakub Narębski