Re: co-authoring commits
On Fri, Jun 19, 2015 at 11:11 PM, Tuncer Ayaz wrote: > On Fri, Jun 19, 2015 at 8:18 PM, Jakub Narębski wrote: >> [This is sent from Thunderbird news, so it should be all right] > > This is fine, the other one was broken. Out of curiosity what's the > difference between Thunderbird email and news? One was sent as Reply All from the news interface (nntp://news.gmane.org), one was sent as Reply All from the email interface (Gmail account). Damned if I know why the difference... -- Jakub Narebski -- To unsubscribe from this list: send the line "unsubscribe git" in
Re: co-authoring commits
On Fri, Jun 19, 2015 at 8:18 PM, Jakub Narębski wrote: > On 2015-06-18 at 23:25, Tuncer Ayaz wrote: > > On Thu, Jun 18, 2015 at 12:52 AM, Theodore Ts'o wrote: > > > On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote: > [...] > > > One could imagine some frankly, quite rare example where there > > > is a team of people who votes on each commit before it gets sent > > > out and where everyone is equal and there is no hierarchy. In > > > that case, perhaps you could set the from field to a mailing > > > list address. But honestly, how often is that *all* of the > > > authors are completely equal[1]? > > > > For that case something like patchwork, phabricator, or gerrit > > seems to be the logical tool to use, and should ideally leave a > > trace of approvals and such in the resulting commit message(s). If > > the patch management tool takes care of merging the commit(s), it > > can be harder to misattribute signed-off/reviewed-by/etc, which is > > a good thing. > > Doesn't Gerrit (at least) use trailer-like structured *notes* in the > 'reviews' category (i.e. refs/notes/reviews ref) to store > information about review process? Don't remember if it does specifically, but I'm sure it can be configured to. I know Phabricator appends a lot upon doing the commit. I'll have to check it the next time I happen to use Gerrit. > > You could of course use multiple (everybody makes their own) > > commits, where you risk breaking bisectability and avoid the need > > for equal co-authorship support. In pair programming such > > intermediate commits will quite often be fixups, and when you > > attempt to squash the fixups for bisectability's sake, you may get > > a desire for co-authorship of the resulting commit. > > Hmmm... I didn't think about the problem of attributing authorship > for squashed commits. Though here multiple 'author' headers, or Strictly speaking, in a live pair programming session usually the one currently typing will be corrected by the other dev, and the roles will switch when the typist changes. > multiline 'author' header would be a better match than 'coauthor' > header (which itself doesn't need, I think, the date filed, or does > it?) What makes sense to me is that the date is decoupled from the list of authors and there is one date only. I think of it as an expanded version of the previously single-entry author field, where the limit has been lifted. With my purely git-user hat on, that is. So, yes, a multiline author header sounds like a solution to me. Maybe it should be sorted alphabetically upon commit regardless of the order of --author ONE --author TWO. > [This is sent from Thunderbird news, so it should be all right] This is fine, the other one was broken. Out of curiosity what's the difference between Thunderbird email and news? -- To unsubscribe from this list: send the line "unsubscribe git" in
Re: co-authoring commits
On 2015-06-18 at 23:25, Tuncer Ayaz wrote: > On Thu, Jun 18, 2015 at 12:52 AM, Theodore Ts'o wrote: >> On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote: [...] >> One could imagine some frankly, quite rare example where there is a >> team of people who votes on each commit before it gets sent out and >> where everyone is equal and there is no hierarchy. In that case, >> perhaps you could set the from field to a mailing list address. But >> honestly, how often is that *all* of the authors are completely >> equal[1]? > > For that case something like patchwork, phabricator, or gerrit seems > to be the logical tool to use, and should ideally leave a trace of > approvals and such in the resulting commit message(s). If the patch > management tool takes care of merging the commit(s), it can be harder > to misattribute signed-off/reviewed-by/etc, which is a good thing. Doesn't Gerrit (at least) use trailer-like structured *notes* in the 'reviews' category (i.e. refs/notes/reviews ref) to store information about review process? > You could of course use multiple (everybody makes their own) commits, > where you risk breaking bisectability and avoid the need for equal > co-authorship support. In pair programming such intermediate commits > will quite often be fixups, and when you attempt to squash the fixups > for bisectability's sake, you may get a desire for co-authorship of > the resulting commit. Hmmm... I didn't think about the problem of attributing authorship for squashed commits. Though here multiple 'author' headers, or multiline 'author' header would be a better match than 'coauthor' header (which itself doesn't need, I think, the date filed, or does it?) [This is sent from Thunderbird news, so it should be all right] -- Jakub Narębski -- To unsubscribe from this list: send the line "unsubscribe git" in
Re: co-authoring commits
On 2015-06-19 at 06:25, Jeff King wrote: > 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. 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)... >> 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"). > >> I wonder what would break if one used 'Name , Name ' >> 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 ">") 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 or for the email part... Would this work, I wonder? [hoping that Thunderbird email didn;t screw up formatting] -- Jakub Narębski -- To unsubscribe from this list: send the line "unsubscribe git" in
Re: co-authoring commits
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 , Name ' > 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 ">") and so will parse back to the second ">". Fsck will definitely complain about it. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: co-authoring commits
Junio C Hamano wrote: j...@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. 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 , Name ' as the author... -- Jakub Narębski -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: co-authoring commits
On Thu, Jun 18, 2015 at 12:52 AM, Theodore Ts'o wrote: > On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote: > > > > By allowing multiple authors, you don't have to decide who's the > > primary author, as in such situations usually there is no primary > > at all. I sometimes deliberately override the author when > > committing and add myself just as another co-author in the commit > > message, but as others have noted it would be really great if we > > can just specify multiple authors. > > Just recently, there a major thread on the IETF mailing list where > IETF working group had drafts where people were listed as co-authors > without their permission, and were upset that the fact that their > name was added made it seem as if they agreed with the end product. > (i.e., that they were endorsing the I-D). So while adding formal > coauthor might solves (a few) problems, it can also introduce > others. You can misuse signed-off/reviewed-by/etc the same way. > Ultimately there is one person who can decide which parts of the > changes to put in the commit that gets sent to the maintainer. So > there *is* someone who is the primary author; the person who takes > the final pass on the patch and then hits the send key. If you (do it in isolation and) want to take full responsibility, yes, but I consider reviewed-by/signed-off as taking partial responsibility because it's a vetting process. > One could imagine some frankly, quite rare example where there is a > team of people who votes on each commit before it gets sent out and > where everyone is equal and there is no hierarchy. In that case, > perhaps you could set the from field to a mailing list address. But > honestly, how often is that *all* of the authors are completely > equal[1]? For that case something like patchwork, phabricator, or gerrit seems to be the logical tool to use, and should ideally leave a trace of approvals and such in the resulting commit message(s). If the patch management tool takes care of merging the commit(s), it can be harder to misattribute signed-off/reviewed-by/etc, which is a good thing. > In my personal practice, if I make significant changes to a patch, I > will indeed simply change the submitter, and then give credit the > original author. This is the case where I'm essentially saying, "Bob > did a lot of work, but I made a bunch of changes, so if things break > horribly, blame *me*, not Bob". > > Alternatively, if I just need to make a few cosmetic changes to > Alice's patch (i.e., fix white spaces, correct spelling, change the > commit description so it's validly parsable and understandable > English, etc.), I'll just add a comment in square brackets > indicating what changes I made before I committed the change. This > seems to work just fine, and I don't think we should try to fix > something that isn't broken. Perfectly valid use cases, but different from the scenarios Josh mentioned. You could of course use multiple (everybody makes their own) commits, where you risk breaking bisectability and avoid the need for equal co-authorship support. In pair programming such intermediate commits will quite often be fixups, and when you attempt to squash the fixups for bisectability's sake, you may get a desire for co-authorship of the resulting commit. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: co-authoring commits
> -Original Message-
> From: Theodore Ts'o
> Sent: Wednesday, June 17, 2015 6:52 PM
>
> On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:
> >
> > By allowing multiple authors, you don't have to decide who's the
> > primary author, as in such situations usually there is no
> primary at
> > all. I sometimes deliberately override the author when
> committing and
> > add myself just as another co-author in the commit message, but as
> > others have noted it would be really great if we can just specify
> > multiple authors.
> One could imagine some frankly, quite rare example where
> there is a team of people who votes on each commit before it
> gets sent out and where everyone is equal and there is no
> hierarchy. In that case, perhaps you could set the from
> field to a mailing list address.
This is a perfect use the signed commit by multiple persons. Git already
supports it (under the hood and in reporting).
A quick google pulled up my notes on this:
http://marc.info/?l=git&m=140845378317052&w=2
$ cat merge-multisigs.sh
#!/bin/bash
(
for i in "$@"
do
gpg --dearmor < "$i"
done
) | gpg --enarmor
$ cat write-commit.ruby
#!/usr/bin/irb
require 'fileutils'
file = File.open(ARGV[0], "rb")
content = file.read
header = "commit #{content.length}\0"
store = header + content
require 'digest/sha1'
sha1 = Digest::SHA1.hexdigest(store)
require 'zlib'
zlib_content = Zlib::Deflate.deflate(store)
path = '.git/objects/' + sha1[0,2] + '/' + sha1[2,38]
FileUtils.mkdir_p(File.dirname(path))
File.open(path, 'w') { |f| f.write zlib_content }
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: co-authoring commits
On Wed, Jun 17, 2015 at 06:52:24PM -0400, Theodore Ts'o wrote: > On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote: > > > > By allowing multiple authors, you don't have to decide who's the > > primary author, as in such situations usually there is no primary at > > all. I sometimes deliberately override the author when committing and > > add myself just as another co-author in the commit message, but as > > others have noted it would be really great if we can just specify > > multiple authors. > > Just recently, there a major thread on the IETF mailing list where > IETF working group had drafts where people were listed as co-authors > without their permission, and were upset that the fact that their name > was added made it seem as if they agreed with the end product. (i.e., > that they were endorsing the I-D). So while adding formal coauthor > might solves (a few) problems, it can also introduce others. > > Ultimately there is one person who can decide which parts of the > changes to put in the commit that gets sent to the maintainer. So > there *is* someone who is the primary author; the person who takes the > final pass on the patch and then hits the send key. I've worked on many patches with another person in a shared screen session, co-authoring a series of patches and commit messages in vim, and writing an email in mutt. There were, ultimately, two people deciding what to put in a commit and send to the maintainer. This is, admittedly, unusual, but pair programming is not ridiculously uncommon. > In that case, perhaps you could set the from field to a mailing list > address. The "From" field in email headers supports a list of comma-separated addresses, just like To and Cc. Speaking from experience, this more-or-less works with all the mail software we tried it with, with the occasional program only displaying the first or last entry. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: co-authoring commits
On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote: > > By allowing multiple authors, you don't have to decide who's the > primary author, as in such situations usually there is no primary at > all. I sometimes deliberately override the author when committing and > add myself just as another co-author in the commit message, but as > others have noted it would be really great if we can just specify > multiple authors. Just recently, there a major thread on the IETF mailing list where IETF working group had drafts where people were listed as co-authors without their permission, and were upset that the fact that their name was added made it seem as if they agreed with the end product. (i.e., that they were endorsing the I-D). So while adding formal coauthor might solves (a few) problems, it can also introduce others. Ultimately there is one person who can decide which parts of the changes to put in the commit that gets sent to the maintainer. So there *is* someone who is the primary author; the person who takes the final pass on the patch and then hits the send key. One could imagine some frankly, quite rare example where there is a team of people who votes on each commit before it gets sent out and where everyone is equal and there is no hierarchy. In that case, perhaps you could set the from field to a mailing list address. But honestly, how often is that *all* of the authors are completely equal[1]? In my personal practice, if I make significant changes to a patch, I will indeed simply change the submitter, and then give credit the original author. This is the case where I'm essentially saying, "Bob did a lot of work, but I made a bunch of changes, so if things break horribly, blame *me*, not Bob". Alternatively, if I just need to make a few cosmetic changes to Alice's patch (i.e., fix white spaces, correct spelling, change the commit description so it's validly parsable and understandable English, etc.), I'll just add a comment in square brackets indicating what changes I made before I committed the change. This seems to work just fine, and I don't think we should try to fix something that isn't broken. - Ted [1] Gilbert and Sullivan attacked this notion is a commedic way in "The Gondoliers"; especially in the songs "Replying we sing as one individual" and "There Lived a King": https://www.youtube.com/watch?v=YD0dgXTQ3K0 https://www.youtube.com/watch?v=oSaVdqcDgZc -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: co-authoring commits
j...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: co-authoring commits
On Wed, Jun 17, 2015 at 02:51:18PM -0700, Junio C Hamano wrote: > j...@joshtriplett.org writes: > > > Having more than one author field in a commit would likely break things, > > but having a coauthor field seems plausible these days. Git added > > support for signed commits, and the world didn't end, so it's possible > > to extend the commit format. > > Something being possible and something being sensible are two > different things, though. > > I agree "coauthor field that is not understood by anybody" would > unlikely break existing implementations, but it is not a useful way > to add this information to commit objects. For one thing, until you > teach "git log" or its equivalents in everybody's (re)implementation > of Git, the field will not be shown, you cannot easily edit it while > amending or rebasing, "git log --grep=" would not know about it, and > you would need "git cat-file commit" to view it. > > A footer Co-authored-by: does not have any such issue. Sure it does; while it would display in raw form because it's a part of the commit message, you'd still have to teach "git log --author" about it (git grep is not a substitute), map it through mailmap, teach git shortlog about it, teach send-email and format-patch to use it in mail headers, teach repository statistics tools about it, and in general teach every tool that reads the "author" field of a commit to handle co-authors. And if it's a pseudo-field in the commit, you'd also have to have more complex parsing rules to find and parse it. Git has almost no understanding of in-band magic "headers" in a commit message. It has a bit of support for generating (but not parsing) Signed-off-by, and send-email has some support for adding *-by headers to Cc, but a pseudo-header that git tools actually *parse* out of the commit message would be a first. > We left commit headers extensible long before we introduced commit > signing, and we used it to add the "encoding" header. In general, > we invent new headers only when structurely necessary. When you > declare that the log message for this indiviaul commit is done in > one encoding, that is not something you would want to _edit_ with > your editor while you are editing your message. Similarly you would > not want to risk touching the GPG signature of a signed commit or a > signed merge while editing your message. > > The _only_ reason I would imagine why somebody may be tempted to > think that "coauthor" as part of the object header makes sense is > because "author" is already there. You can argue that "author" did > not have to be part of the object header, and that is right. I > would agree with you 100% that "author" did not have to be there. 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. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: co-authoring commits
On Wed, Jun 17, 2015 at 11:51 PM, Junio C Hamano wrote: > j...@joshtriplett.org writes: > > > Having more than one author field in a commit would likely break > > things, but having a coauthor field seems plausible these days. > > Git added support for signed commits, and the world didn't end, so > > it's possible to extend the commit format. > > Something being possible and something being sensible are two > different things, though. > > I agree "coauthor field that is not understood by anybody" would > unlikely break existing implementations, but it is not a useful way > to add this information to commit objects. For one thing, until you > teach "git log" or its equivalents in everybody's (re)implementation > of Git, the field will not be shown, you cannot easily edit it while > amending or rebasing, "git log --grep=" would not know about it, and > you would need "git cat-file commit" to view it. > > A footer Co-authored-by: does not have any such issue. > > We left commit headers extensible long before we introduced commit > signing, and we used it to add the "encoding" header. In general, we > invent new headers only when structurely necessary. When you declare > that the log message for this indiviaul commit is done in one > encoding, that is not something you would want to _edit_ with your > editor while you are editing your message. Similarly you would not > want to risk touching the GPG signature of a signed commit or a > signed merge while editing your message. > > The _only_ reason I would imagine why somebody may be tempted to > think that "coauthor" as part of the object header makes sense is > because "author" is already there. You can argue that "author" did > not have to be part of the object header, and that is right. I would > agree with you 100% that "author" did not have to be there. > > But that is too late to change. > > And being consistent with a past mistake is not a good reason to > repeat that same mistake. Makes sense. Without intimate knowledge of current internals, what about the following potentially crazy plan? 1. demote/deprecate GIT_AUTHOR_* 2. implement a new author-ship model that supports both and treats the old entries as supported-but-deprecated 3. maybe auto-migrate entries in the repo, or add a switch to do that as part of git-gc or another process 4. extend tooling to support 'commit --add-author' or similar 5. teach git.git tools to properly display additional authors as equals in commit ownership 6. let other tools catch up, but rest assured nothing was broken 7. consider other use cases and different implementations (flexibility), to not have to repeat this 5 years down the road for another field -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: co-authoring commits
j...@joshtriplett.org writes: > Having more than one author field in a commit would likely break things, > but having a coauthor field seems plausible these days. Git added > support for signed commits, and the world didn't end, so it's possible > to extend the commit format. Something being possible and something being sensible are two different things, though. I agree "coauthor field that is not understood by anybody" would unlikely break existing implementations, but it is not a useful way to add this information to commit objects. For one thing, until you teach "git log" or its equivalents in everybody's (re)implementation of Git, the field will not be shown, you cannot easily edit it while amending or rebasing, "git log --grep=" would not know about it, and you would need "git cat-file commit" to view it. A footer Co-authored-by: does not have any such issue. We left commit headers extensible long before we introduced commit signing, and we used it to add the "encoding" header. In general, we invent new headers only when structurely necessary. When you declare that the log message for this indiviaul commit is done in one encoding, that is not something you would want to _edit_ with your editor while you are editing your message. Similarly you would not want to risk touching the GPG signature of a signed commit or a signed merge while editing your message. The _only_ reason I would imagine why somebody may be tempted to think that "coauthor" as part of the object header makes sense is because "author" is already there. You can argue that "author" did not have to be part of the object header, and that is right. I would agree with you 100% that "author" did not have to be there. But that is too late to change. And being consistent with a past mistake is not a good reason to repeat that same mistake. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: co-authoring commits
On Wed, Jun 17, 2015 at 01:57:12PM -0700, Junio C Hamano wrote: > Tuncer Ayaz writes: > > > On Wed, Jun 17, 2015 at 9:58 PM, Junio C Hamano wrote: > >> Tuncer Ayaz writes: > >> > >> > Is this something that breaks the design and would never be > >> > implemented, > >> > >> Yes. > > > > Junio, thanks for the quick response. > > > > I suppose things have changed since Jonathan Nieder's response in [1] > > (2010),... > > I do not think there is anything changed. Jonathan was being a bit > more diplomatic and academic than I am. > > "There is no reason in principle some faraway future version of Git > could" is _always_ true as a mental masturbation without taking > reality into account, aka "Sounds doable but a lot of trouble" means > "it is doable but it is dubious that it is worth doing". What happens in old versions of git if you try to look at a signed git commit? The same level of interoperability used there would work here, with the additional property that this would be optional metadata so we might be able to make read-only access work with older versions. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: co-authoring commits
On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote: > On Wed, Jun 17, 2015 at 9:58 PM, Junio C Hamano wrote: > > Tuncer Ayaz writes: > > > > > Is this something that breaks the design and would never be > > > implemented, > > > > Yes. > > Junio, thanks for the quick response. > > I suppose things have changed since Jonathan Nieder's response in [1] > (2010), or I've read too much into the mini-thread between Jonathan > and Josh. I was under the impression that this is generally possible > without shaking up all underpinnings. > > For what it's worth, here's why I would use the feature: > > By allowing multiple authors, you don't have to decide who's the > primary author, as in such situations usually there is no primary at > all. I sometimes deliberately override the author when committing and > add myself just as another co-author in the commit message, but as > others have noted it would be really great if we can just specify > multiple authors. Having more than one author field in a commit would likely break things, but having a coauthor field seems plausible these days. Git added support for signed commits, and the world didn't end, so it's possible to extend the commit format. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: co-authoring commits
Tuncer Ayaz writes: > On Wed, Jun 17, 2015 at 9:58 PM, Junio C Hamano wrote: >> Tuncer Ayaz writes: >> >> > Is this something that breaks the design and would never be >> > implemented, >> >> Yes. > > Junio, thanks for the quick response. > > I suppose things have changed since Jonathan Nieder's response in [1] > (2010),... I do not think there is anything changed. Jonathan was being a bit more diplomatic and academic than I am. "There is no reason in principle some faraway future version of Git could" is _always_ true as a mental masturbation without taking reality into account, aka "Sounds doable but a lot of trouble" means "it is doable but it is dubious that it is worth doing". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: co-authoring commits
On Wed, Jun 17, 2015 at 9:58 PM, Junio C Hamano wrote: > Tuncer Ayaz writes: > > > Is this something that breaks the design and would never be > > implemented, > > Yes. Junio, thanks for the quick response. I suppose things have changed since Jonathan Nieder's response in [1] (2010), or I've read too much into the mini-thread between Jonathan and Josh. I was under the impression that this is generally possible without shaking up all underpinnings. For what it's worth, here's why I would use the feature: By allowing multiple authors, you don't have to decide who's the primary author, as in such situations usually there is no primary at all. I sometimes deliberately override the author when committing and add myself just as another co-author in the commit message, but as others have noted it would be really great if we can just specify multiple authors. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451880 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: co-authoring commits
Tuncer Ayaz writes: > Is this something that breaks the design and would never be implemented, Yes. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
co-authoring commits
Even though I don't have time to work on a feature like this, like others before me, I've been in situations where I would have liked to set more than one GIT_AUTHOR_NAME (etc.) for a single commit due to the involvement of multiple developers in authoring a change. Is this something that breaks the design and would never be implemented, or can it be integrated such that one can specify co-authors when committing a change? I'm thinking: $ git commit --add-author "Tony Zwei " -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
