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

From: Jakub Narębski <jnareb@gmail.com>
Date: Aug 6, 2014, 18:31 UTC
Message-ID: <CANQwDwcHSO+KwhZbo4BTcWnAWGWbJzNQ7CY2m3nq+p0t9uDeqg@mail.gmail.com>

On Wed, Aug 6, 2014 at 6:26 PM, Nico Williams <nico@cryptonector.com> wrote:

Show 24 quoted lines

> On Wed, Aug 6, 2014 at 10:58 AM, Jakub Narębski <jnareb@gmail.com> wrote:
>> W dniu 2014-08-01 22:55, Nico Williams pisze:
>>>
>>> It would help if cherry-pick history where recorded somewhere (beyond
>>> the reflog)...
>>>
>>> Cherry-picks should record two parents, like merges.
>>>
>>> (Of course, it does no good to know about an unreachable parent, when
>>> a commit with two parents is pushed to a repo that doesn't have one of
>>> those parents, which can happen when topic branches aren't pushed
>>> upstream.)
>>
>> There was (long time ago) a long thread about idea of adding some
>> kind of 'weak' references (links), 'weakparent' that can be automatically
>> used by Git but do not pollute the commit message,
>> and do not affect reachability calculations.  Ultimately it went
>> nowhere (as you can see) - there were many problems.
>
> 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?

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

BTW. sometimes I do wonder if we are not making a mistake trying to shoehorn new features like stash, replacements and notes into DAG, objects (commit, tree, blob), refs and reflogs. I'd rather Git did not make the same mistake (well, I think it was a mistake) that Mercurial did with .hgtags file, (ab)using file transfer for tags, instead of adding separate transfer mechanism like Git has... which led to contortions in interpreting / deling with said file (most recent version is used, not the one in checked out revision) and things like having to commit creating a tag for it to be transferrable.

Show 5 quoted lines

>> For example: how it would work for reverts and rebases?
>
> 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...

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

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

-- 
Jakub Narębski