Re: [RFC] cherry-pick using multiple parents to implement -x

"Stephen R. van den Berg" [off-list ref] writes:

Paolo Bonzini wrote:

quoted

quoted

commit 7df437e56b5a2c5ec7140dd097b517563db4972c
tree a006f20b481d811ccb4846534ef6394be5bc78a8
parent ff1e8bfcd69e5e0ee1a3167e80ef75b611f72123
parent bbb896d8e10f736bfda8f587c0009c358c9a8599
cousin 6ffaecc7d8b2c3c188a2efa5977a6e6605d878d9
cousin a1184d85e8752658f02746982822f43f32316803
author Junio C Hamano [off-list ref] 1220153499 -0700
committer Junio C Hamano [off-list ref] 1220153499 -0700

quoted

What about "origin", and making it propagated through cherry-picks?  In

"origin" gives a better sense of direction, so maybe that's better, yes.

quoted

other words, if I "cherry-pick -x" A generating B, and do the same on B
generating C, C should have A as origin.  Also, "git cherry-pick -n -x"
should add the commit to a list of origins somewhere so that "git
commit" can reuse it.

That is debatable, and should be configurable with a switch.
It depends on the way of operation, I guess.
If one picks A -> B, and then B -> C, then usually for C you want B
to be the origin to indicate that the patch has been tested and shaved
to fit from A -> B, and further polished to fit from B -> C.
Usually backporting involves shaving the patch slightly to fit the older
branch, and in that case it is truly more honest to point back to B
instead of A from C.  And besides, you can follow the chain to C -> B -> A
if you like, no information is lost.

quoted

Furthermore, "git cherry" should use origins if available.

That is one of the places in git that needs to accomodate the new field,
luckily the impact on the rest of git-core is rather minimal, I think.

Unfortunately I think it is more complicated than that.

If I understand correctly (please correct me if I am wrong) you meant
'cousin' / 'origin' link to refer only to single commit, and not to
the whole history ending with given commit, as it is in the case of
'parent' link.  One thing to consider is the fact that git is
_snapshot_ based, while cherry-picking is _changeset_ based.  When you
cherry pick commit B to apply on top of commit A, what you do in fact
is to pick (A^..A) or in other syntax (A-A^) change, and apply it on
top of A.  So cherry picked B, let's denote it by B', is in fact
C'=(A-A^).  For example having only commit A is not enough to replay
cherry-picking.

Second, unless such header would be for informational purposes only
(there was even proposal to add generic 'note <sth>' informational
only header, but it was shot down; see the archives), you would have
to do quite a bit of surgery to revision walking code.  For example
you would have to think about how commits pointed by 'origin' header
would be protected against pruning; if you allow to prune parents of
grandparents of cherry-picked commits, you would break I think a lot
of assumptions in the code, and assumption in git design that if we
have commit, then all that it references should be available (well,
there are grafts, and there is shallow clone, but those modify
reachability...).

-- 
Jakub Narebski
Poland
ShadeHawk on #git