Re: cherry picking and merge

On Wed, Aug 6, 2014 at 10:58 AM, Jakub Narębski [off-list ref] wrote:

W dniu 2014-08-01 22:55, Nico Williams pisze:

quoted

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