{"thread":{"id":"36986","subject":"Use case (was Re: Should branches be objects?)","startedAt":"2014-06-24T03:20:14Z","lastAt":"2014-06-25T22:44:40Z","messageCount":6,"participants":["Nico Williams","John Keeping","Theodore Ts'o","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"244908","messageId":"CAK3OfOgskVKs=eUT+EM+GZOjh0p6gxKeDWH-iTt29P1i1d1iZA@mail.gmail.com","threadId":"36986","inReplyTo":null,"subject":"Use case (was Re: Should branches be objects?)","fromName":"Nico Williams","fromEmail":"nico@cryptonector.com","sentAt":"2014-06-24T03:20:14Z","receivedAt":"2014-06-24T03:20:14Z","isPatch":false,"sender":{"key":"nico@cryptonector.com","avatar":null},"body":"(thinking more about this, digesting Jonathan's response...)\n\nThe Illumos repo, like OpenSolaris before it, and Solaris itself at\nSun (and now at Oracle) requires that fixes be broken down into small\ncommits, with related fixes, tests, and docs changes all typically in\nseparate commits, but all pushed together, so that a single push of N\ncommits is a logical set of changes (e.g., to be backed out together\nif, say, any one of them breaks a build). With git the only way to\nrecord this grouping at push time is with a post-receive hook that\ndoes the recording (which is what the Illumos repo does, sending email\nto a list about all the commits pushed in one go).\n\nNow, suppose that branches were objects. Then at push time one might\npush with a message about the set of commits being pushed, and this\nmessage (and time of push, and pusher ID) would get recorded in the\nbranch object. At fetch time the branch objects's histories would be\npulled (but usually never pushed), and would be available for browsing\nwith git log at remotes//. Each commit of the branch\nobject (as it were) would record each logical set of commits.\n\nSide effects besides addressing the contiguous and related commit grouping need:\n\n - no more need to sign-off on cherry-picks: the branch will record\nthe ousher's ID, which can then be taken as the person signing off;\n\n - branch objects substantially replace/augment reflogs;\n\n - no need to ammend commits: just push an empty set of commits just\nto update the branch object with a note!\n\nThe UI would mostly consist of an option to git push to include a push\nmessage, and a way to review branch history (much like git log -g, but\nwith access to the push-time metadata). Also along for the ride: a\nway to get the new metadata in post-receive hooks.\n\nProblem: if pushing via an intermediary the push metadat would get\nlost. This would argue for either a stronger still notion of related\ncommits, or none stronger than what exists now (because ETOOMUCH).\nBut this branch object concept could also be just right: if pushing\nthrough a an intermediary (what at Sun was called a project gate) then\nit becomes that intermedirary's (gatekeeper's) job to squash, rebase,\nregroup, edit, drop, reword, ... commits.\n\nJust a thought,\n\nNico\n--\n"},{"id":"244920","messageId":"20140624110127.GH28807@serenity.lan","threadId":"36986","inReplyTo":"CAK3OfOgskVKs=eUT+EM+GZOjh0p6gxKeDWH-iTt29P1i1d1iZA@mail.gmail.com","subject":"Re: Use case (was Re: Should branches be objects?)","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2014-06-24T11:01:27Z","receivedAt":"2014-06-24T11:01:27Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote:\n> The Illumos repo, like OpenSolaris before it, and Solaris itself at\n> Sun (and now at Oracle) requires that fixes be broken down into small\n> commits, with related fixes, tests, and docs changes all typically in\n> separate commits, but all pushed together, so that a single push of N\n> commits is a logical set of changes (e.g., to be backed out together\n> if, say, any one of them breaks a build). With git the only way to\n> record this grouping at push time is with a post-receive hook that\n> does the recording (which is what the Illumos repo does, sending email\n> to a list about all the commits pushed in one go).\n\nHave you considered using merges for this instead? If each set of\nrelated changes is its own branch, then if you merge with `--no-ff` so\nthat a merge commit is always created, you can identify the set of\nrelated changes with:\n\n\tgit log ${MERGE_COMMIT}^1..${MERGE_COMMIT}^2\n\nThere are some interesting effects with reverting merge commits,\nparticularly if you want to merge the same set of changes at a later\ndate, but this seems like the \"Git way\" of identifying related commits.\n"},{"id":"244921","messageId":"20140624110932.GI14887@thunk.org","threadId":"36986","inReplyTo":"CAK3OfOgskVKs=eUT+EM+GZOjh0p6gxKeDWH-iTt29P1i1d1iZA@mail.gmail.com","subject":"Re: Use case (was Re: Should branches be objects?)","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2014-06-24T11:09:32Z","receivedAt":"2014-06-24T11:09:32Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote:\n> \n> Now, suppose that branches were objects. Then at push time one might\n> push with a message about the set of commits being pushed, and this\n> message (and time of push, and pusher ID) would get recorded in the\n> branch object. At fetch time the branch objects's histories would be\n> pulled (but usually never pushed), and would be available for browsing\n> with git log at remotes//. Each commit of the branch\n> object (as it were) would record each logical set of commits.\n\nThis seems pretty close to what we have with signed tags. When I send\na pull request to Linus, I create a signed tag which createscontains a\nmessage about a set of commits, and this message is automatically\nincluded in the pull request message generated with \"git\nrequest-pull\", and when Linus merges my pull request, the\ncryptographically signed tag, along with the message, date of the\nsignature, etc., is preserved for all posterity.\n\n> Problem: if pushing via an intermediary the push metadat would get\n> lost. This would argue for either a stronger still notion of related\n> commits, or none stronger than what exists now (because ETOOMUCH).\n> But this branch object concept could also be just right: if pushing\n> through a an intermediary (what at Sun was called a project gate) then\n> it becomes that intermedirary's (gatekeeper's) job to squash, rebase,\n> regroup, edit, drop, reword, ... commits.\n\nWith signed tags, the metadata is preserved even when the set of\ncommits is sent via an intermediary.\n\nIt seems the major difference is that it's a pull model, where some\nprojects seem much happier with a push model. But that sounds like\nwhat is needed is that someone replaces Linus Torvalds with a shell\nscript --- namely, an e-mail bot that receives pull requests, checks\nthe signed tag against an access control list, and if it is an\nauthorized committer, accepts the pull request automatically (or\nrejects it if there are merge conflicts).\n\nNot that I am suggesting for even a second that Linus could be fully\nreplaced by a shell script. For example, he handles trivial merge\nconflicts, and more importantly, applies a \"oh my G*d you must be\nkidding\" taste filter on incoming pull requests, which I think would\nbe hard to automate. Then again, neural networks have automatically\nevolved to recognize cat videos, so we can't rule it out in the\nfuture. :-)\n\nCheers,\n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"244958","messageId":"CAK3OfOgb3zt0HKkeQKfMR9u7sKRzjCZAeOQh=qSyt9cVordG4A@mail.gmail.com","threadId":"36986","inReplyTo":"20140624110932.GI14887@thunk.org","subject":"Re: Use case (was Re: Should branches be objects?)","fromName":"Nico Williams","fromEmail":"nico@cryptonector.com","sentAt":"2014-06-25T05:29:50Z","receivedAt":"2014-06-25T05:29:50Z","isPatch":false,"sender":{"key":"nico@cryptonector.com","avatar":null},"body":"On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o wrote:\n>\n> On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote:\n> >\n> > Now, suppose that branches were objects. Then at push time one might\n> > push with a message about the set of commits being pushed, and this\n> > message (and time of push, and pusher ID) would get recorded in the\n> > branch object. At fetch time the branch objects's histories would be\n> > pulled (but usually never pushed), and would be available for browsing\n> > with git log at remotes//. Each commit of the branch\n> > object (as it were) would record each logical set of commits.\n>\n> This seems pretty close to what we have with signed tags. When I send\n> a pull request to Linus, I create a signed tag which createscontains a\n> message about a set of commits, and this message is automatically\n> included in the pull request message generated with \"git\n> request-pull\", and when Linus merges my pull request, the\n> cryptographically signed tag, along with the message, date of the\n> signature, etc., is preserved for all posterity.\n\nThanks for pointing this out. Signed tags are objects -- that's a\nclear and strong precedent.. That's another thing that branches as\nobjects could have: signatures of pushed commits (separately from the\ncommits themselves).\n\n> It seems the major difference is that it's a pull model, where some\n> projects seem much happier with a push model. But that sounds like\n> what is needed is that someone replaces Linus Torvalds with a shell\n> script --- namely, an e-mail bot that receives pull requests, checks\n> the signed tag against an access control list, and if it is an\n> authorized committer, accepts the pull request automatically (or\n> rejects it if there are merge conflicts).\n\nShell script, protocol.. The git push protocol is convenient. The\nfact that git supports a patches-via-email, push, and pull models,\nthat's a great aspect of git. Why disadvantage the push case, when\nit's so popular (e.g., via github and such)?\n\nNico\n--\n"},{"id":"244974","messageId":"xmqqegycans6.fsf@gitster.dls.corp.google.com","threadId":"36986","inReplyTo":"CAK3OfOgb3zt0HKkeQKfMR9u7sKRzjCZAeOQh=qSyt9cVordG4A@mail.gmail.com","subject":"Re: Use case (was Re: Should branches be objects?)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-06-25T17:42:49Z","receivedAt":"2014-06-25T17:42:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nico Williams writes:\n\n> On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o wrote:\n> ...\n>> This seems pretty close to what we have with signed tags. When I send\n>> a pull request to Linus, I create a signed tag which createscontains a\n>> message about a set of commits, and this message is automatically\n>> included in the pull request message generated with \"git\n>> request-pull\", and when Linus merges my pull request, the\n>> cryptographically signed tag, along with the message, date of the\n>> signature, etc., is preserved for all posterity.\n>\n> Thanks for pointing this out. Signed tags are objects -- that's a\n> clear and strong precedent..\n\nSounds as if you are interpreting what Ted said as a supporting\nargument for having branches as separate type of objects, but the\nway I read it was \"signed tags are sufficient for what you want to\ndo; adding a new \"branch\" type does not make much sense at this\npoint\".\n"},{"id":"244992","messageId":"20140625224440.GD10397@thunk.org","threadId":"36986","inReplyTo":"xmqqegycans6.fsf@gitster.dls.corp.google.com","subject":"Re: Use case (was Re: Should branches be objects?)","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2014-06-25T22:44:40Z","receivedAt":"2014-06-25T22:44:40Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Jun 25, 2014 at 10:42:49AM -0700, Junio C Hamano wrote:\n> Nico Williams writes:\n> \n> > On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o wrote:\n> > ...\n> >> This seems pretty close to what we have with signed tags. When I send\n> >> a pull request to Linus, I create a signed tag which createscontains a\n> >> message about a set of commits, and this message is automatically\n> >> included in the pull request message generated with \"git\n> >> request-pull\", and when Linus merges my pull request, the\n> >> cryptographically signed tag, along with the message, date of the\n> >> signature, etc., is preserved for all posterity.\n> >\n> > Thanks for pointing this out. Signed tags are objects -- that's a\n> > clear and strong precedent..\n> \n> Sounds as if you are interpreting what Ted said as a supporting\n> argument for having branches as separate type of objects, but the\n> way I read it was \"signed tags are sufficient for what you want to\n> do; adding a new \"branch\" type does not make much sense at this\n> point\".\n\nYes, that's what I was saying. If you want to record a reliable \"who\npushed this\" (or \"who requested this to be pulled\"), you really want\nto use a GPG signature, since otherwise the identity of the pusher can\nbe completely faked --- especially if the you have a tiered system\nwhere you have sub-maintainers in the mix. So if you want any kind of\nauditability long after the fact, you want digital signatures, and so\na signed tag maps exactly to what you want --- modulo needing a\nstandardized \"Linus Torvalds\" bot. But the nice thing about creating\nsuch an automated pull request processing system is that it doesn't\nrequire making any changes to core git.\n\nIf you insist that it has to be done via a \"git push\", I suspect it\nwouldn't be that hard to add changes to Gerrit (which already has an\nconcept of access control which ssh keys are allowed to push a\nchange), and extended it to include a hook that validated whether the\npush included a signed tag. Again, no core changes needed to git, or\nto the repository format.\n\n\t\t\t\t\t- Ted\n"}]}