Re: cherry picking and merge

From: Nico Williams <nico@cryptonector.com>
Date: Aug 6, 2014, 16:26 UTC
Message-ID: <CAK3OfOj4_ttmv6gQ4zkvG1tod9rUBMvLfwvtVVbbdttqZWcECA@mail.gmail.com>
In-Reply-To: <53E25090.7010803@gmail.com>

On Wed, Aug 6, 2014 at 10:58 AM, Jakub Narębski <jnareb@gmail.com> wrote:

Show 16 quoted lines

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

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

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

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.

Nico --