"Stephen R. van den Berg" <srb@xxxxxxx> writes: > Paolo Bonzini wrote: >>> commit 7df437e56b5a2c5ec7140dd097b517563db4972c >>> tree a006f20b481d811ccb4846534ef6394be5bc78a8 >>> parent ff1e8bfcd69e5e0ee1a3167e80ef75b611f72123 >>> parent bbb896d8e10f736bfda8f587c0009c358c9a8599 >>> cousin 6ffaecc7d8b2c3c188a2efa5977a6e6605d878d9 >>> cousin a1184d85e8752658f02746982822f43f32316803 >>> author Junio C Hamano <gitster@xxxxxxxxx> 1220153499 -0700 >>> committer Junio C Hamano <gitster@xxxxxxxxx> 1220153499 -0700 > >> What about "origin", and making it propagated through cherry-picks? In > > "origin" gives a better sense of direction, so maybe that's better, yes. > >> 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. > >> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
