(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,
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