(thinking more about this, digesting Jonathan's response...) 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). 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. Side effects besides addressing the contiguous and related commit grouping need: - no more need to sign-off on cherry-picks: the branch will record the ousher's ID, which can then be taken as the person signing off; - branch objects substantially replace/augment reflogs; - no need to ammend commits: just push an empty set of commits just to update the branch object with a note! The UI would mostly consist of an option to git push to include a push message, and a way to review branch history (much like git log -g, but with access to the push-time metadata). Also along for the ride: a way to get the new metadata in post-receive hooks. 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. Just a thought, Nico -- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html