From: Junio C Hamano <hidden> Date: 2016-06-15 22:45:19
"Stephen R. van den Berg" [off-list ref] writes:
- And depending on an affirmative on the previous question, would it be
acceptable to teach the gitk preceding/following tag listing to deal
with these backport/forwardports ?
Even though the answer to "the previous question" is a solid no, it is not
just acceptable but it would be very useful to teach gitk that the commit
you cherry-picked from is somehow related to the resulting commit from the
cherry-picking, and teach it to give you an easy access (and even a visual
cue about their relationship) to the other commit when it is showing the
cherry-picked commit.
I think the commit object name -x records in the commit message of the
cherry-picked one is noticed by gitweb to give you an easy access. You
could teach gitk a similar trick, and that would not just help cherry
picking but also reverts, and a fix-up commit that says "This fixes the
regression introduced by commit 90ff09a5".
You could further draw _different_ kind of line on the upper "graph" pane,
to show that a commit is _related_ to another commit. Because cherry-pick
relation is about the resulting commit and the _single_ commit that was
cherry-picked (in other words, the parent of the cherry-picked original
does not have _any_ relation to the commit that results from the
cherry-pick), such a line should be visually very distinct from the usual
parent-child relationship, which is the gitk graph (or any other commit
ancestry graph) is about. But if it can be represented clearly, I'd
imagine that it would be interesting to see.
From: Stephen R. van den Berg <hidden> Date: 2016-06-15 22:45:19
Junio C Hamano wrote:
"Stephen R. van den Berg" [off-list ref] writes:
I think the commit object name -x records in the commit message of the
cherry-picked one is noticed by gitweb to give you an easy access. You
could teach gitk a similar trick, and that would not just help cherry
picking but also reverts, and a fix-up commit that says "This fixes the
regression introduced by commit 90ff09a5".
Checking the on-disk format I see that it has been defined in a rather
extensible way.
If we were to put the SHA1-ref somewhere in the commit message,
finding references to a certain commit through cherry-picks becomes
rather disk/CPU-intensive.
Would there be any objections against extending the on-disk format to
accomodate something like the following:
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
Whereas cherry-pick would (optionally) generate a cousin reference for every
commit it picks.
I'm willing to do the work to fix up git-core to support the new field.
--
Sincerely,
Stephen R. van den Berg.
The Horkheimer Effect: "The odds of it being cloudy are directly proportional
to the importance of an astronomical event."
From: Paolo Bonzini <hidden> Date: 2016-06-15 22:45:19
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
What about "origin", and making it propagated through cherry-picks? In
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.
Furthermore, "git cherry" should use origins if available.
Paolo
From: Stephen R. van den Berg <hidden> Date: 2016-06-15 22:45:19
Paolo Bonzini wrote:
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
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.
--
Sincerely,
Stephen R. van den Berg.
The Horkheimer Effect: "The odds of it being cloudy are directly proportional
to the importance of an astronomical event."
From: Jakub Narebski <hidden> Date: 2016-06-15 22:45:19
"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
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:45:19
"Stephen R. van den Berg" [off-list ref] wrote:
If we were to put the SHA1-ref somewhere in the commit message,
finding references to a certain commit through cherry-picks becomes
rather disk/CPU-intensive.
Would there be any objections against extending the on-disk format to
accomodate something like the following:
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
Whereas cherry-pick would (optionally) generate a cousin reference for every
commit it picks.
Sorry for wandering into a thread in the middle. But we've already
been down this road before, and decided the additional header wasn't
worth it from cherry-pick. What's changed? The fact that gitk
wants to hyperlink this? Why can't it just regex out a string of
hex digits longer than 6 and see if there is a commit that matches?
--
Shawn.
From: Stephen R. van den Berg <hidden> Date: 2016-06-15 22:45:19
Shawn O. Pearce wrote:
"Stephen R. van den Berg" [off-list ref] wrote:
quoted
Whereas cherry-pick would (optionally) generate a cousin reference for every
commit it picks.
Sorry for wandering into a thread in the middle. But we've already
been down this road before, and decided the additional header wasn't
worth it from cherry-pick. What's changed?
I'm not familiar with the old thread. Any pointers? (I tried googling,
but couldn't seem to find it).
The fact that gitk
wants to hyperlink this? Why can't it just regex out a string of
hex digits longer than 6 and see if there is a commit that matches?
To avoid (accidental) duplication of the old thread, I'll try and read
that first.
--
Sincerely,
Stephen R. van den Berg.
The Horkheimer Effect: "The odds of it being cloudy are directly proportional
to the importance of an astronomical event."
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:45:19
"Stephen R. van den Berg" [off-list ref] wrote:
Shawn O. Pearce wrote:
quoted
"Stephen R. van den Berg" [off-list ref] wrote:
quoted
Whereas cherry-pick would (optionally) generate a cousin reference for every
commit it picks.
quoted
Sorry for wandering into a thread in the middle. But we've already
been down this road before, and decided the additional header wasn't
worth it from cherry-pick. What's changed?
I'm not familiar with the old thread. Any pointers? (I tried googling,
but couldn't seem to find it).
From: Paolo Bonzini <hidden> Date: 2016-06-15 22:45:19
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...).
I think it would be used mostly for informational purposes (for
hyperlinks in gitk, and in git-cherry).
Paolo
From: Paolo Bonzini <hidden> Date: 2016-06-15 22:45:19
Sorry for wandering into a thread in the middle. But we've already
been down this road before, and decided the additional header wasn't
worth it from cherry-pick. What's changed? The fact that gitk
wants to hyperlink this? Why can't it just regex out a string of
hex digits longer than 6 and see if there is a commit that matches?
The main difference is that git-cherry too often does not work right now
(I have a local patch so that it more-or-less works with my GNU
ChangeLogs, but it does not improve the situation if rerere kicks in).
(Of course git cherry could also regex out a string of hex digits longer
than 6 and see if there is a commit that matches).
Paolo
From: Stephen R. van den Berg <hidden> Date: 2016-06-15 22:45:20
Shawn O. Pearce wrote:
"Stephen R. van den Berg" [off-list ref] wrote:
quoted
Shawn O. Pearce wrote:
quoted
"Stephen R. van den Berg" [off-list ref] wrote:
quoted
Whereas cherry-pick would (optionally) generate a cousin reference for every
commit it picks.
quoted
quoted
Sorry for wandering into a thread in the middle. But we've already
been down this road before, and decided the additional header wasn't
worth it from cherry-pick. What's changed?
quoted
I'm not familiar with the old thread. Any pointers? (I tried googling,
but couldn't seem to find it).
Found it, thanks. Digested it, and yes, some things changed.
I'll make a formal proposal which should take care of all the old
objections.
--
Sincerely,
Stephen R. van den Berg.
"Be spontaneous!"