Re: "Branch objects" (was: Re: cherry picking and merge)

[Nico Williams <nico@cryptonector.com>]

On Wed, Aug 06, 2014 at 08:31:18PM +0200, Jakub Narębski wrote:
> On Wed, Aug 6, 2014 at 6:26 PM, Nico Williams <nico@cryptonector.com> wrote:
> > My proposal was to put this sort of ancillary history info in a
> > "branch object" (and that branches should be objects).  This would
> > have a number of benefits, not the least of which is that at push time
> > you can drop such ancillary history without having to alter the
> > commits being pushed.
> 
> Is it something like object-ified reflog, similar to how replacement
> objects (git-replace) can be thought to be object-ified grafts (I know
> they are more)? Do I understand it correctly?

Yes, per-branch.  At push time a commit would be pushed to the upstream
branch listing the commits pushed now (and who by).  Locally every
rebase/cherry-pick/merge/commit onto the branch would appear in the
branch object's history, kinda just like the reflog.  The main
difference is that the upstream branch's history could be viewed.

> Did you plan to (ab)use known object types: tree and commit (a bit
> similar to git-replace and git-note object, though there is no need for
> fanout trees - the top level tree can reproduce refs hierarchy)? I see
> that you planned to (ab)use existing transfer mechanism of refs and
> objects...

Just like signed tags, basically.

> > Reverts upstream?  The revert should record the commit hash of the
> > commit it reverts (but file-level reverts lose), so that this could be
> > noticed.
> 
> If it is object-ified reflog then reverts are not a problem...

Right.

> > Rebases upstream?  Well, that shouldn't happen, but if it does then
> > you must rebase --onto and any cherry-picks of upstream rebased
> > commits lose their ties to those (but this can be detected).
> 
> With rebases the problem is that it would be nice to have (at least
> for a short time) the history of series of patches (the metahistory,
> or history of a branch), but usually one doesn't need old pre-rebase
> version after cleaning up the history for publishing.

Right.

> > In general recording more metadata (assuming there's not privacy
> > issues to consider) can't hurt.  Using it might, but having the option
> > to can also help.
> 
> True...

The principle should be to record as much metadata as possible, pruning
ancillary metadata (reflog-like metadata that isn't on the commits) only
at push time.  

Nico
--