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

From: Nico Williams <nico@cryptonector.com>
Date: Aug 6, 2014, 20:07 UTC
Message-ID: <20140806200726.GE23449@localhost>
In-Reply-To: <CANQwDwcHSO+KwhZbo4BTcWnAWGWbJzNQ7CY2m3nq+p0t9uDeqg@mail.gmail.com>

On Wed, Aug 06, 2014 at 08:31:18PM +0200, Jakub Narębski wrote:

Show 10 quoted lines

> 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.

Show 5 quoted lines

> 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.

Show 5 quoted lines

> > 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.

Show 8 quoted lines

> > 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.

Show 5 quoted lines

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