Re: Use case (was Re: Should branches be objects?)
Nico Williams n...@cryptonector.com writes: On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o ty...@mit.edu wrote: ... This seems pretty close to what we have with signed tags. When I send a pull request to Linus, I create a signed tag which createscontains a message about a set of commits, and this message is automatically included in the pull request message generated with git request-pull, and when Linus merges my pull request, the cryptographically signed tag, along with the message, date of the signature, etc., is preserved for all posterity. Thanks for pointing this out. Signed tags are objects -- that's a clear and strong precedent.. Sounds as if you are interpreting what Ted said as a supporting argument for having branches as separate type of objects, but the way I read it was signed tags are sufficient for what you want to do; adding a new branch type does not make much sense at this point. -- 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: Use case (was Re: Should branches be objects?)
On Wed, Jun 25, 2014 at 10:42:49AM -0700, Junio C Hamano wrote: Nico Williams n...@cryptonector.com writes: On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o ty...@mit.edu wrote: ... This seems pretty close to what we have with signed tags. When I send a pull request to Linus, I create a signed tag which createscontains a message about a set of commits, and this message is automatically included in the pull request message generated with git request-pull, and when Linus merges my pull request, the cryptographically signed tag, along with the message, date of the signature, etc., is preserved for all posterity. Thanks for pointing this out. Signed tags are objects -- that's a clear and strong precedent.. Sounds as if you are interpreting what Ted said as a supporting argument for having branches as separate type of objects, but the way I read it was signed tags are sufficient for what you want to do; adding a new branch type does not make much sense at this point. Yes, that's what I was saying. If you want to record a reliable who pushed this (or who requested this to be pulled), you really want to use a GPG signature, since otherwise the identity of the pusher can be completely faked --- especially if the you have a tiered system where you have sub-maintainers in the mix. So if you want any kind of auditability long after the fact, you want digital signatures, and so a signed tag maps exactly to what you want --- modulo needing a standardized Linus Torvalds bot. But the nice thing about creating such an automated pull request processing system is that it doesn't require making any changes to core git. If you insist that it has to be done via a git push, I suspect it wouldn't be that hard to add changes to Gerrit (which already has an concept of access control which ssh keys are allowed to push a change), and extended it to include a hook that validated whether the push included a signed tag. Again, no core changes needed to git, or to the repository format. - Ted -- 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: Use case (was Re: Should branches be objects?)
On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote:
The Illumos repo, like OpenSolaris before it, and Solaris itself at
Sun (and now at Oracle) requires that fixes be broken down into small
commits, with related fixes, tests, and docs changes all typically in
separate commits, but all pushed together, so that a single push of N
commits is a logical set of changes (e.g., to be backed out together
if, say, any one of them breaks a build). With git the only way to
record this grouping at push time is with a post-receive hook that
does the recording (which is what the Illumos repo does, sending email
to a list about all the commits pushed in one go).
Have you considered using merges for this instead? If each set of
related changes is its own branch, then if you merge with `--no-ff` so
that a merge commit is always created, you can identify the set of
related changes with:
git log ${MERGE_COMMIT}^1..${MERGE_COMMIT}^2
There are some interesting effects with reverting merge commits,
particularly if you want to merge the same set of changes at a later
date, but this seems like the Git way of identifying related commits.
--
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: Use case (was Re: Should branches be objects?)
On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote: Now, suppose that branches were objects. Then at push time one might push with a message about the set of commits being pushed, and this message (and time of push, and pusher ID) would get recorded in the branch object. At fetch time the branch objects's histories would be pulled (but usually never pushed), and would be available for browsing with git log at remotes/remote/branch. Each commit of the branch object (as it were) would record each logical set of commits. This seems pretty close to what we have with signed tags. When I send a pull request to Linus, I create a signed tag which createscontains a message about a set of commits, and this message is automatically included in the pull request message generated with git request-pull, and when Linus merges my pull request, the cryptographically signed tag, along with the message, date of the signature, etc., is preserved for all posterity. Problem: if pushing via an intermediary the push metadat would get lost. This would argue for either a stronger still notion of related commits, or none stronger than what exists now (because ETOOMUCH). But this branch object concept could also be just right: if pushing through a an intermediary (what at Sun was called a project gate) then it becomes that intermedirary's (gatekeeper's) job to squash, rebase, regroup, edit, drop, reword, ... commits. With signed tags, the metadata is preserved even when the set of commits is sent via an intermediary. It seems the major difference is that it's a pull model, where some projects seem much happier with a push model. But that sounds like what is needed is that someone replaces Linus Torvalds with a shell script --- namely, an e-mail bot that receives pull requests, checks the signed tag against an access control list, and if it is an authorized committer, accepts the pull request automatically (or rejects it if there are merge conflicts). Not that I am suggesting for even a second that Linus could be fully replaced by a shell script. For example, he handles trivial merge conflicts, and more importantly, applies a oh my G*d you must be kidding taste filter on incoming pull requests, which I think would be hard to automate. Then again, neural networks have automatically evolved to recognize cat videos, so we can't rule it out in the future. :-) Cheers, - Ted -- 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: Use case (was Re: Should branches be objects?)
On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o ty...@mit.edu wrote: On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote: Now, suppose that branches were objects. Then at push time one might push with a message about the set of commits being pushed, and this message (and time of push, and pusher ID) would get recorded in the branch object. At fetch time the branch objects's histories would be pulled (but usually never pushed), and would be available for browsing with git log at remotes/remote/branch. Each commit of the branch object (as it were) would record each logical set of commits. This seems pretty close to what we have with signed tags. When I send a pull request to Linus, I create a signed tag which createscontains a message about a set of commits, and this message is automatically included in the pull request message generated with git request-pull, and when Linus merges my pull request, the cryptographically signed tag, along with the message, date of the signature, etc., is preserved for all posterity. Thanks for pointing this out. Signed tags are objects -- that's a clear and strong precedent.. That's another thing that branches as objects could have: signatures of pushed commits (separately from the commits themselves). It seems the major difference is that it's a pull model, where some projects seem much happier with a push model. But that sounds like what is needed is that someone replaces Linus Torvalds with a shell script --- namely, an e-mail bot that receives pull requests, checks the signed tag against an access control list, and if it is an authorized committer, accepts the pull request automatically (or rejects it if there are merge conflicts). Shell script, protocol.. The git push protocol is convenient. The fact that git supports a patches-via-email, push, and pull models, that's a great aspect of git. Why disadvantage the push case, when it's so popular (e.g., via github and such)? Nico -- -- 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
