{"thread":{"id":"40542","subject":"How to rebase when some commit hashes are in some commit messages","startedAt":"2015-10-12T19:59:46Z","lastAt":"2015-10-18T16:23:39Z","messageCount":17,"participants":["Francois-Xavier Le Bail","Matthieu Moy","Konstantin Khomoutov","Philip Oakley","Jacob Keller","Mike Rappazzo","Johannes Schindelin","Thomas Koch","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"271487","messageId":"561C1132.3090606@orange.fr","threadId":"40542","inReplyTo":null,"subject":"How to rebase when some commit hashes are in some commit messages","fromName":"Francois-Xavier Le Bail","fromEmail":"devel.fx.lebail@orange.fr","sentAt":"2015-10-12T19:59:46Z","receivedAt":"2015-10-12T19:59:46Z","isPatch":false,"sender":{"key":"devel.fx.lebail@orange.fr","avatar":null},"body":"Hello,\n\n[I try some search engines without success, perhaps I have missed something].\n\nFor example, if I rebase the following commits, I would want that if\nthe commit hash 2222222... become 7777777...,\nthe message\n\"Update test output for 2222222222222222222222222222222222222222\"\nbecome\n\"Update test output for 7777777...\"\n\nIs it possible currently? And if yes how?\n\nGreetings,\nFrancois-Xavier\n\n-------------------------------------------------------------------\ncommit 6666666666666666666666666666666666666666\nAuthor: First Last \nDate: Fri Jul 3 17:14:58 2015 -0700\n\nFix 5\n\nxxx xxx xxx xxx\n\ncommit 5555555555555555555555555555555555555555\nAuthor: First Last \nDate: Fri Jul 3 16:58:58 2015 -0700\n\nUpdate test output for 2222222222222222222222222222222222222222\n\ncommit 4444444444444444444444444444444444444444\nAuthor: First Last \nDate: Fri Jul 3 17:50:27 2015 -0700\n\nFix 4\n\ncommit 3333333333333333333333333333333333333333\nAuthor: First Last \nDate: Fri Jul 3 15:01:36 2015 -0700\n\nFix 3\n\nxxx xxx xxx xxx\n\ncommit 2222222222222222222222222222222222222222\nAuthor: First Last \nDate: Fri Jul 3 11:20:28 2015 -0700\n\nFix 2\n\nxxx xxx xxx xxx\n\ncommit 1111111111111111111111111111111111111111\nAuthor: First Last \nDate: Fri Jul 3 09:15:59 2015 -0700\n\nFix 1\n\nxxx xxx xxx xxx\n\n-------------------------------------------------------------------\n"},{"id":"271490","messageId":"vpqsi5fx2gr.fsf@grenoble-inp.fr","threadId":"40542","inReplyTo":"561C1132.3090606@orange.fr","subject":"Re: How to rebase when some commit hashes are in some commit messages","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-10-12T20:21:24Z","receivedAt":"2015-10-12T20:21:24Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Francois-Xavier Le Bail writes:\n\n> Hello,\n>\n> [I try some search engines without success, perhaps I have missed something].\n>\n> For example, if I rebase the following commits, I would want that if\n> the commit hash 2222222... become 7777777...,\n> the message\n> \"Update test output for 2222222222222222222222222222222222222222\"\n> become\n> \"Update test output for 7777777...\"\n>\n> Is it possible currently? And if yes how?\n\nAFAIK, it's not possible other than by editing the message by hand.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"271563","messageId":"561CC5E0.7060206@orange.fr","threadId":"40542","inReplyTo":"vpqsi5fx2gr.fsf@grenoble-inp.fr","subject":"Re: How to rebase when some commit hashes are in some commit messages","fromName":"Francois-Xavier Le Bail","fromEmail":"devel.fx.lebail@orange.fr","sentAt":"2015-10-13T08:50:40Z","receivedAt":"2015-10-13T08:50:40Z","isPatch":false,"sender":{"key":"devel.fx.lebail@orange.fr","avatar":null},"body":"\n\nOn 12/10/2015 22:21, Matthieu Moy wrote:\n> Francois-Xavier Le Bail writes:\n> \n>> Hello,\n>>\n>> [I try some search engines without success, perhaps I have missed something].\n>>\n>> For example, if I rebase the following commits, I would want that if\n>> the commit hash 2222222... become 7777777...,\n>> the message\n>> \"Update test output for 2222222222222222222222222222222222222222\"\n>> become\n>> \"Update test output for 7777777...\"\n>>\n>> Is it possible currently? And if yes how?\n> \n> AFAIK, it's not possible other than by editing the message by hand.\n\nIt seems to me useful to be able to do it. Can we hope a new option?\n"},{"id":"271573","messageId":"20151013160004.11a103942062ee09c53bd235@domain007.com","threadId":"40542","inReplyTo":"561CC5E0.7060206@orange.fr","subject":"Re: How to rebase when some commit hashes are in some commit messages","fromName":"Konstantin Khomoutov","fromEmail":"kostix+git@007spb.ru","sentAt":"2015-10-13T13:00:04Z","receivedAt":"2015-10-13T13:00:04Z","isPatch":false,"sender":{"key":"kostix+git@007spb.ru","avatar":null},"body":"On Tue, 13 Oct 2015 10:50:40 +0200\nFrancois-Xavier Le Bail wrote:\n\n> >> For example, if I rebase the following commits, I would want that\n> >> if the commit hash 2222222... become 7777777...,\n> >> the message\n> >> \"Update test output for 2222222222222222222222222222222222222222\"\n> >> become\n> >> \"Update test output for 7777777...\"\n> >>\n> >> Is it possible currently? And if yes how?\n> > \n> > AFAIK, it's not possible other than by editing the message by hand.\n> \n> It seems to me useful to be able to do it. Can we hope a new option?\n\nHow do you think this could be practically implemented?\n\nA couple of things which immediately spring to my mind:\n\nTo begin with, you are free to specify just a few first characters of\nthe commit name you're referring to. So the alogrythm which finds the\nrelevant commits them has to be smart to somehow avoid misfires. Or\nhave knobs to tune it (like -M of `git log`).\n\nOK, suppose that this is solved through the usage of some agreed-upon\nkeywords in the commit message. Say, you adopt a policy to put\nsomething like\n\n X-Refers-To: 2dd8a9d9bb33ebffccb2ff516497adc8535bcab4\n\nin your commit message to make the finder tool happy.\n\nNow think how exactly it should work. First, any commit at all might\nmention the name of the target commit in its commit message. Okay,\nlet's suppose there will be some way to somehow prune the possible DAG\ndown. Then what happens if the commit to change is a part of the chain\nof commits reachable from some branch other than that you're rebasing?\nAutomatically rebasing it would rewrite that commits and all commits\n\"after\" it -- possibly resulting in what the \"Recovering from upstream\nrebase\" part of the git-rebase(1) manual page deals with.\n\nHaving said that, the feature you're after appears to me to be a\nsensible thing to have but the possibility of its generic implementation\nappears to be moot.\n\nNote that to deal with narrow simple cases (all possibly affected\ncommits leave on the same branch you're rebasing, and come later than\nthe rebase's anchor) you could write a script which uses `git log` to\nfind those commits which need special care.\n"},{"id":"271574","messageId":"AD64941D9533442AB025BE27FF8F08AF@PhilipOakley","threadId":"40542","inReplyTo":"20151013160004.11a103942062ee09c53bd235@domain007.com","subject":"Re: How to rebase when some commit hashes are in some commit messages","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2015-10-13T13:29:57Z","receivedAt":"2015-10-13T13:29:57Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Konstantin Khomoutov\" \n> On Tue, 13 Oct 2015 10:50:40 +0200\n> Francois-Xavier Le Bail wrote:\n>\n>> >> For example, if I rebase the following commits, I would want that\n>> >> if the commit hash 2222222... become 7777777...,\n>> >> the message\n>> >> \"Update test output for 2222222222222222222222222222222222222222\"\n>> >> become\n>> >> \"Update test output for 7777777...\"\n>> >>\n>> >> Is it possible currently? And if yes how?\n>> >\n>> > AFAIK, it's not possible other than by editing the message by hand.\n>>\n>> It seems to me useful to be able to do it. Can we hope a new option?\n>\n> How do you think this could be practically implemented?\n>\n> A couple of things which immediately spring to my mind:\n>\n> To begin with, you are free to specify just a few first characters of\n> the commit name you're referring to. So the alogrythm which finds the\n> relevant commits them has to be smart to somehow avoid misfires. Or\n> have knobs to tune it (like -M of `git log`).\n>\n> OK, suppose that this is solved through the usage of some agreed-upon\n> keywords in the commit message. Say, you adopt a policy to put\n> something like\n>\n> X-Refers-To: 2dd8a9d9bb33ebffccb2ff516497adc8535bcab4\n>\n> in your commit message to make the finder tool happy.\n>\n> Now think how exactly it should work. First, any commit at all might\n> mention the name of the target commit in its commit message. Okay,\n> let's suppose there will be some way to somehow prune the possible DAG\n> down. Then what happens if the commit to change is a part of the chain\n> of commits reachable from some branch other than that you're rebasing?\n> Automatically rebasing it would rewrite that commits and all commits\n> \"after\" it -- possibly resulting in what the \"Recovering from upstream\n> rebase\" part of the git-rebase(1) manual page deals with.\n>\n> Having said that, the feature you're after appears to me to be a\n> sensible thing to have but the possibility of its generic implementation\n> appears to be moot.\n>\n> Note that to deal with narrow simple cases (all possibly affected\n> commits leave on the same branch you're rebasing, and come later than\n> the rebase's anchor) you could write a script which uses `git log` to\n> find those commits which need special care.\n\nMy tuppence is that the only sha1's that could/would be rewritten would be \nthose for the commits within the rebase. During rebasing it is expected that \nthe user is re-adjusting things for later upstream consumption, with social \ncontrols and understandings with colleagues.\n\nThus the only sha1 numbers that could be used are those that are within the \n(possibly implied) instruction sheet (which will list the current sha1s that \nwill be converted by rebase to new sha1's).\n\nIt should be clear that the sha1's are always backward references (because \nof the impossibility of including a forward reference to an as yet \nun-created future commit's sha1).\n\nThe key question (for me) is whether short sha1s are accepted, or if they \nmust be full 40 char sha1's (perhaps an option). There are already options \nfor making sure that short refs are not ambiguous.\n\nIt sound to me like a sensible small project for those that have such a \nworkflow. I'm not sure if it should work with a patch based flow when \nsubmitting upstream - I'm a little fuzzy on how would the upstream \nmaintainer know which sha1 referred to which patch.\n\nPhilip \n"},{"id":"271580","messageId":"CA+P7+xoDia6PC+qJeVn3sD5g4jk7KRuDAPOcEHvrntd+ndUraA@mail.gmail.com","threadId":"40542","inReplyTo":"AD64941D9533442AB025BE27FF8F08AF@PhilipOakley","subject":"Re: How to rebase when some commit hashes are in some commit messages","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2015-10-13T17:07:54Z","receivedAt":"2015-10-13T17:07:54Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Tue, Oct 13, 2015 at 6:29 AM, Philip Oakley wrote:\n> My tuppence is that the only sha1's that could/would be rewritten would be\n> those for the commits within the rebase. During rebasing it is expected that\n> the user is re-adjusting things for later upstream consumption, with social\n> controls and understandings with colleagues.\n>\n\nAgreed here. There would be no need to change any sha1s that didn't\nchange during the rebase. This limits the scope. Alright.\n\n> Thus the only sha1 numbers that could be used are those that are within the\n> (possibly implied) instruction sheet (which will list the current sha1s that\n> will be converted by rebase to new sha1's).\n>\n\nCorrect, you would be able to limit the number of sha1s to search for.\n\nHowever, (see below), any reasonable reference to a sha1 should be\nrelatively stable.\n\n> It should be clear that the sha1's are always backward references (because\n> of the impossibility of including a forward reference to an as yet\n> un-created future commit's sha1).\n>\n> The key question (for me) is whether short sha1s are accepted, or if they\n> must be full 40 char sha1's (perhaps an option). There are already options\n> for making sure that short refs are not ambiguous.\n>\n> It sound to me like a sensible small project for those that have such a\n> workflow. I'm not sure if it should work with a patch based flow when\n> submitting upstream - I'm a little fuzzy on how would the upstream\n> maintainer know which sha1 referred to which patch.\n>\n\nMy issue: the only sha1s in commit messages are *generally* things\nwhich will NOT be changed in general. Supporting a work flow that\nwants to change these is definitely crazy.\n\nEssentially: I don't see a reason that you would be rebasing a commit\nand needing to change any references in it. You can reference a commit\nwhich isn't changing, but here's the possible situations I see:\n\na) you are rebasing a commit which references in the message a commit\nthat is not being changed (it is ancient)\n\nIn this case, nothing needs to be done.\n\nb) you are rebasing a commit which references another commit in the same rebase\n\nI see no valid reason to reference a sha1 in this case. If you're\nreferencing as a \"fixes\", then you are being silly since you can just\nsquash the fix into the original commit and thus prevent introduction\nof bug at all.\n\nWhat other reason? If you are referencing such as \"thix extends\nimplementation from sha1\" then your commit message is probably poorly\nformatted. I don't see a reason to support this flow.\n\nc) you are rebasing a commit which is referencing a commit that has\nalready been changed. (?)\n\nI think (maybe) this is your interesting case, but here are some caveats.\n\nLet's say you are fixing some old commit such as \"Fixes: \" or something.\n\nIf you do a \"git pull --rebase\", your commit might be updated to play\nontop of more new work, but the sha1 should still be valid, *unless*\nthe remote history did some rewind, at which point I don't think any\nalgorithm will work, see the issues above.\n\nIt may be something worth doing in git-filter-branch, but then you're\nlooking at losing the two assumptions above making it really hard to\nget right.\n\nRegards,\nJake\n"},{"id":"271582","messageId":"CANoM8SVAGQ4AL9wBiBMaAu0GvaotC8rhn-rWQhLjsyWr4DnXmw@mail.gmail.com","threadId":"40542","inReplyTo":"CA+P7+xoDia6PC+qJeVn3sD5g4jk7KRuDAPOcEHvrntd+ndUraA@mail.gmail.com","subject":"Re: How to rebase when some commit hashes are in some commit messages","fromName":"Mike Rappazzo","fromEmail":"rappazzo@gmail.com","sentAt":"2015-10-13T18:00:50Z","receivedAt":"2015-10-13T18:00:50Z","isPatch":false,"sender":{"key":"rappazzo@gmail.com","avatar":"https://avatars.githubusercontent.com/u/525287?v=4"},"body":"On Tue, Oct 13, 2015 at 1:07 PM, Jacob Keller wrote:\n> On Tue, Oct 13, 2015 at 6:29 AM, Philip Oakley wrote:\n>> My tuppence is that the only sha1's that could/would be rewritten would be\n>> those for the commits within the rebase. During rebasing it is expected that\n>> the user is re-adjusting things for later upstream consumption, with social\n>> controls and understandings with colleagues.\n>>\n>\n> Agreed here. There would be no need to change any sha1s that didn't\n> change during the rebase. This limits the scope. Alright.\n>\n>> Thus the only sha1 numbers that could be used are those that are within the\n>> (possibly implied) instruction sheet (which will list the current sha1s that\n>> will be converted by rebase to new sha1's).\n>>\n>\n> Correct, you would be able to limit the number of sha1s to search for.\n>\n> However, (see below), any reasonable reference to a sha1 should be\n> relatively stable.\n>\n>> It should be clear that the sha1's are always backward references (because\n>> of the impossibility of including a forward reference to an as yet\n>> un-created future commit's sha1).\n>>\n>> The key question (for me) is whether short sha1s are accepted, or if they\n>> must be full 40 char sha1's (perhaps an option). There are already options\n>> for making sure that short refs are not ambiguous.\n>>\n>> It sound to me like a sensible small project for those that have such a\n>> workflow. I'm not sure if it should work with a patch based flow when\n>> submitting upstream - I'm a little fuzzy on how would the upstream\n>> maintainer know which sha1 referred to which patch.\n>>\n>\n> My issue: the only sha1s in commit messages are *generally* things\n> which will NOT be changed in general. Supporting a work flow that\n> wants to change these is definitely crazy.\n>\n> Essentially: I don't see a reason that you would be rebasing a commit\n> and needing to change any references in it. You can reference a commit\n> which isn't changing, but here's the possible situations I see:\n>\n> a) you are rebasing a commit which references in the message a commit\n> that is not being changed (it is ancient)\n>\n> In this case, nothing needs to be done.\n>\n> b) you are rebasing a commit which references another commit in the same rebase\n>\n> I see no valid reason to reference a sha1 in this case. If you're\n> referencing as a \"fixes\", then you are being silly since you can just\n> squash the fix into the original commit and thus prevent introduction\n> of bug at all.\n>\n> What other reason? If you are referencing such as \"thix extends\n> implementation from sha1\" then your commit message is probably poorly\n> formatted. I don't see a reason to support this flow.\n>\n> c) you are rebasing a commit which is referencing a commit that has\n> already been changed. (?)\n>\n> I think (maybe) this is your interesting case, but here are some caveats.\n>\n> Let's say you are fixing some old commit such as \"Fixes: summary, date>\" or something.\n>\n> If you do a \"git pull --rebase\", your commit might be updated to play\n> ontop of more new work, but the sha1 should still be valid, *unless*\n> the remote history did some rewind, at which point I don't think any\n> algorithm will work, see the issues above.\n>\n> It may be something worth doing in git-filter-branch, but then you're\n> looking at losing the two assumptions above making it really hard to\n> get right.\n>\n> Regards,\n> Jake\n\nIt seems reasonable that this could be added as a feature of\ninteractive rebase. The todo list could be automatically adjusted to\n\"reword\" for those commits which are referring to other commits within\nthe same rebase. As each commit is re-written, a mapping could be\nkept of old sha1 -> new sha1. Then when one of the reworded commits\nis being applied, the old sha1 -> new sha1 mapping could be used to\nadd a line to the $COMMIT_MSG.\n"},{"id":"271591","messageId":"B846BC4FDE6944D39DC79E245264E544@PhilipOakley","threadId":"40542","inReplyTo":"CANoM8SVAGQ4AL9wBiBMaAu0GvaotC8rhn-rWQhLjsyWr4DnXmw@mail.gmail.com","subject":"Re: How to rebase when some commit hashes are in some commit messages","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2015-10-13T19:24:51Z","receivedAt":"2015-10-13T19:24:51Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Mike Rappazzo\" \n> On Tue, Oct 13, 2015 at 1:07 PM, Jacob Keller \n> wrote:\n>> On Tue, Oct 13, 2015 at 6:29 AM, Philip Oakley \n>> wrote:\n>>> My tuppence is that the only sha1's that could/would be rewritten would \n>>> be\n>>> those for the commits within the rebase. During rebasing it is expected \n>>> that\n>>> the user is re-adjusting things for later upstream consumption, with \n>>> social\n>>> controls and understandings with colleagues.\n>>>\n>>\n>> Agreed here. There would be no need to change any sha1s that didn't\n>> change during the rebase. This limits the scope. Alright.\n>>\n>>> Thus the only sha1 numbers that could be used are those that are within \n>>> the\n>>> (possibly implied) instruction sheet (which will list the current sha1s \n>>> that\n>>> will be converted by rebase to new sha1's).\n>>>\n>>\n>> Correct, you would be able to limit the number of sha1s to search for.\n>>\n>> However, (see below), any reasonable reference to a sha1 should be\n>> relatively stable.\n>>\n>>> It should be clear that the sha1's are always backward references \n>>> (because\n>>> of the impossibility of including a forward reference to an as yet\n>>> un-created future commit's sha1).\n>>>\n>>> The key question (for me) is whether short sha1s are accepted, or if \n>>> they\n>>> must be full 40 char sha1's (perhaps an option). There are already \n>>> options\n>>> for making sure that short refs are not ambiguous.\n>>>\n>>> It sound to me like a sensible small project for those that have such a\n>>> workflow. I'm not sure if it should work with a patch based flow when\n>>> submitting upstream - I'm a little fuzzy on how would the upstream\n>>> maintainer know which sha1 referred to which patch.\n>>>\n>>\n>> My issue: the only sha1s in commit messages are *generally* things\n>> which will NOT be changed in general. Supporting a work flow that\n>> wants to change these is definitely crazy.\n>>\n>> Essentially: I don't see a reason that you would be rebasing a commit\n>> and needing to change any references in it. You can reference a commit\n>> which isn't changing, but here's the possible situations I see:\n>>\n>> a) you are rebasing a commit which references in the message a commit\n>> that is not being changed (it is ancient)\n>>\n>> In this case, nothing needs to be done.\n>>\n>> b) you are rebasing a commit which references another commit in the same \n>> rebase\n>>\n>> I see no valid reason to reference a sha1 in this case. If you're\n>> referencing as a \"fixes\", then you are being silly since you can just\n>> squash the fix into the original commit and thus prevent introduction\n>> of bug at all.\n>>\n>> What other reason? If you are referencing such as \"thix extends\n>> implementation from sha1\" then your commit message is probably poorly\n>> formatted. I don't see a reason to support this flow.\n>>\n>> c) you are rebasing a commit which is referencing a commit that has\n>> already been changed. (?)\n>>\n>> I think (maybe) this is your interesting case, but here are some caveats.\n>>\n>> Let's say you are fixing some old commit such as \"Fixes: > summary, date>\" or something.\n>>\n>> If you do a \"git pull --rebase\", your commit might be updated to play\n>> ontop of more new work, but the sha1 should still be valid, *unless*\n>> the remote history did some rewind, at which point I don't think any\n>> algorithm will work, see the issues above.\n>>\n>> It may be something worth doing in git-filter-branch, but then you're\n>> looking at losing the two assumptions above making it really hard to\n>> get right.\n>>\n>> Regards,\n>> Jake\n>\n> It seems reasonable that this could be added as a feature of\n> interactive rebase. The todo list could be automatically adjusted to\n> \"reword\" for those commits which are referring to other commits within\n> the same rebase. As each commit is re-written, a mapping could be\n> kept of old sha1 -> new sha1. Then when one of the reworded commits\n> is being applied, the old sha1 -> new sha1 mapping could be used to\n> add a line to the $COMMIT_MSG.\n> --\nThe extra fun begins if the commit message is of a one-line pretty quoted \nstyle, where more of the quote needs changing...\ne.g.\n[alias]\n quote = log -1 --pretty='tformat:%h (%s, %ad)' --date=short\n log1 = log -1 --pretty=\\\"format:%ad %h (%an): %s\\\" --date=short\n\nJake was concerned about the 'crazy' workflow, however almost all workflows \nare crazy at a distance.\nThe rebase is required if the workflow's allowed base point moves forward \nfaster than one can complete the (likely long) patch series, so the series \nis rebased and then an acceptable series can be merged without \nmodifications.\nGit has the former issue i.e. master and next can move forward faster than a \nlong series takes to be reviewed, but does not have the latter because Junio \nadds his signature to each commit, and uses the patch submission flow.\n\nIIUC (as an alternate example), in G4W one can submit a (long) pull request \nwith internal back references that would be merged directly, so the sha1's \ncould be updated as Francois-Xavier originally asked. I have a series that's \nbeen bumping along for a long while that needs regular rebasing, though \ndoesn't have sha1 back references, so I can see that the need does happen. I \ncan see that others may have a workflow that would work well with the sha1 \nauto-update.\n\n--\nPhilip\n"},{"id":"271598","messageId":"CA+P7+xpgY-PGdxDKHBeu0X=U6FKMavzmjexUTWatUzEdw8CmcQ@mail.gmail.com","threadId":"40542","inReplyTo":"B846BC4FDE6944D39DC79E245264E544@PhilipOakley","subject":"Re: How to rebase when some commit hashes are in some commit messages","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2015-10-13T21:28:56Z","receivedAt":"2015-10-13T21:28:56Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Tue, Oct 13, 2015 at 12:24 PM, Philip Oakley wrote:\n> IIUC (as an alternate example), in G4W one can submit a (long) pull request\n> with internal back references that would be merged directly, so the sha1's\n> could be updated as Francois-Xavier originally asked. I have a series that's\n> been bumping along for a long while that needs regular rebasing, though\n> doesn't have sha1 back references, so I can see that the need does happen. I\n> can see that others may have a workflow that would work well with the sha1\n> auto-update.\n>\n> --\n> Philip\n>\n\nI still don't see how this is useful, because the part that *can* be\nimplemented is not valuable and the part that is valuable can't be\nimplemented.\n\nSo, what we can implement easily enough:\n\nyou rebase a series and any time the message contains sha1 of a commit\nwe're modifying in this rebase, we update the sha1 to match again.\nThis seems reasonable, but not useful. Why would you reference a\ncommit that is *ITSELF* being rebased. No one has explained a\nreasonable use for this... I'm sure there exists one, but I would want\nan explanation of one first.\n\nThe \"useful\" case is if you rebase \"onto\" a tree that has a previous\nhistory that has been changed. In this case, how do you propose we\nfind it. Doing as suggested above, ie: only changing sha1s that we are\nalready rebasing works, but why are you backreferencing it if you are\nre-writing the commit? That doesn't make sense to me at all. Yes, you\ncan do it, but I don't get why this is valuable. If you're backref is\n\"fixes xyz\" why not just fix xyz instead of have two commits. If the\nback ref has some other value... what is that value? I don't\nunderstand it I guess.\n\nIt just seems pretty narrow focus. I mean if someone wants to\nimplement it, that is fine.\n\nRegards,\nJake\n"},{"id":"271602","messageId":"B8985A8E92044BD8845B1ABD23FABA13@PhilipOakley","threadId":"40542","inReplyTo":"CA+P7+xpgY-PGdxDKHBeu0X=U6FKMavzmjexUTWatUzEdw8CmcQ@mail.gmail.com","subject":"Re: How to rebase when some commit hashes are in some commit messages","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2015-10-13T23:06:58Z","receivedAt":"2015-10-13T23:06:58Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jacob Keller\" \n> On Tue, Oct 13, 2015 at 12:24 PM, Philip Oakley \n> wrote:\n>> IIUC (as an alternate example), in G4W one can submit a (long) pull\n>> request\n>> with internal back references that would be merged directly, so the\n>> sha1's\n>> could be updated as Francois-Xavier originally asked. I have a series\n>> that's\n>> been bumping along for a long while that needs regular rebasing, though\n>> doesn't have sha1 back references, so I can see that the need does\n>> happen. I\n>> can see that others may have a workflow that would work well with the\n>> sha1\n>> auto-update.\n>>\n>> --\n>> Philip\n>>\n>\n> I still don't see how this is useful, because the part that *can* be\n> implemented is not valuable and the part that is valuable can't be\n> implemented.\n>\n> So, what we can implement easily enough:\n>\n> you rebase a series and any time the message contains sha1 of a commit\n> we're modifying in this rebase, we update the sha1 to match again.\n> This seems reasonable, but not useful. Why would you reference a\n> commit that is *ITSELF* being rebased. No one has explained a\n> reasonable use for this... I'm sure there exists one, but I would want\n> an explanation of one first.\n>\nThis particular case is about self-references within a long series. At the\nmoment, on the Git list there is general comments about say [PATCH v3\n18/44], whichs is great for for the list ($gmane) but not for a `git log`.\nIn flows where PRs are valid, one can have what was [34/44] refering to\nprior patch [26/44] as `deadbeaf` or whatever. It won't be suitable for most\nflows but will be useful for a proportion (as already evidenced by the\nrequest).\n\n> The \"useful\" case is if you rebase \"onto\" a tree that has a previous\n> history that has been changed. In this case, how do you propose we\n> find it.\n\nThis use case (where upstream also rebases) hasn't been considered. It would\nbe a tricky one. As long as the possibility (of such an A depends on B\nre-write) isn't closed off then the smaller requested case could still go\nahead.\n\n> Doing as suggested above, ie: only changing sha1s that we are\n> already rebasing works, but why are you backreferencing it if you are\n> re-writing the commit?\n\n Essentially one wants to say `$CURR_COMMIT~nn` (i.e. \"see nn commits\nearlier in my series\") and have that replaced with its cannonical sha1, and\nupdated when rebased.\nIt sort of begs the question whether there should be a ref shorthand for\n\"the (this) current commit\" to allow THIS~ as an interpretable [valid?]\nformat.\n\n> That doesn't make sense to me at all. Yes, you\n> can do it, but I don't get why this is valuable.\n\n> If you're backref is\n> \"fixes xyz\" why not just fix xyz instead of have two commits. If the\n> back ref has some other value... what is that value? I don't\n> understand it I guess.\nFor the 'fixes' (of a bug report) case we are already talking about an\nimmutable so it would not be part of this.\nIts use may be more of the type \"Using helper function xyz introduced\nearlier in patch abcde\", which would change after each rebase.\n\n>\n> It just seems pretty narrow focus. I mean if someone wants to\n> implement it, that is fine.\n>\nAgreed\n--\nPhilip \n"},{"id":"271715","messageId":"561F597B.8090102@orange.fr","threadId":"40542","inReplyTo":"AD64941D9533442AB025BE27FF8F08AF@PhilipOakley","subject":"Re: How to rebase when some commit hashes are in some commit messages","fromName":"Francois-Xavier Le Bail","fromEmail":"devel.fx.lebail@orange.fr","sentAt":"2015-10-15T07:44:59Z","receivedAt":"2015-10-15T07:44:59Z","isPatch":false,"sender":{"key":"devel.fx.lebail@orange.fr","avatar":null},"body":"\n\nOn 13/10/2015 15:29, Philip Oakley wrote:\n> From: \"Konstantin Khomoutov\" \n>> On Tue, 13 Oct 2015 10:50:40 +0200\n>> Francois-Xavier Le Bail wrote:\n>>\n>>> >> For example, if I rebase the following commits, I would want that\n>>> >> if the commit hash 2222222... become 7777777...,\n>>> >> the message\n>>> >> \"Update test output for 2222222222222222222222222222222222222222\"\n>>> >> become\n>>> >> \"Update test output for 7777777...\"\n>>> >>\n>>> >> Is it possible currently? And if yes how?\n>>> >\n>>> > AFAIK, it's not possible other than by editing the message by hand.\n>>>\n>>> It seems to me useful to be able to do it. Can we hope a new option?\n>>\n>> How do you think this could be practically implemented?\n>>\n>> A couple of things which immediately spring to my mind:\n>>\n>> To begin with, you are free to specify just a few first characters of\n>> the commit name you're referring to. So the alogrythm which finds the\n>> relevant commits them has to be smart to somehow avoid misfires. Or\n>> have knobs to tune it (like -M of `git log`).\n>>\n>> OK, suppose that this is solved through the usage of some agreed-upon\n>> keywords in the commit message. Say, you adopt a policy to put\n>> something like\n>>\n>> X-Refers-To: 2dd8a9d9bb33ebffccb2ff516497adc8535bcab4\n>>\n>> in your commit message to make the finder tool happy.\n>>\n>> Now think how exactly it should work. First, any commit at all might\n>> mention the name of the target commit in its commit message. Okay,\n>> let's suppose there will be some way to somehow prune the possible DAG\n>> down. Then what happens if the commit to change is a part of the chain\n>> of commits reachable from some branch other than that you're rebasing?\n>> Automatically rebasing it would rewrite that commits and all commits\n>> \"after\" it -- possibly resulting in what the \"Recovering from upstream\n>> rebase\" part of the git-rebase(1) manual page deals with.\n>>\n>> Having said that, the feature you're after appears to me to be a\n>> sensible thing to have but the possibility of its generic implementation\n>> appears to be moot.\n>>\n>> Note that to deal with narrow simple cases (all possibly affected\n>> commits leave on the same branch you're rebasing, and come later than\n>> the rebase's anchor) you could write a script which uses `git log` to\n>> find those commits which need special care.\n> \n> My tuppence is that the only sha1's that could/would be rewritten would be those for the commits within the rebase. During rebasing it is expected that the user is re-adjusting things for later\n> upstream consumption, with social controls and understandings with colleagues.\n> \n> Thus the only sha1 numbers that could be used are those that are within the (possibly implied) instruction sheet (which will list the current sha1s that will be converted by rebase to new sha1's).\n\nYes.\n\n> It should be clear that the sha1's are always backward references (because of the impossibility of including a forward reference to an as yet un-created future commit's sha1).\n> \n> The key question (for me) is whether short sha1s are accepted, or if they must be full 40 char sha1's (perhaps an option). There are already options for making sure that short refs are not ambiguous.\n\nI think full 40 sha1 is more secure to avoid confusion with previous or future sha1.\n\n> It sound to me like a sensible small project for those that have such a workflow. I'm not sure if it should work with a patch based flow when submitting upstream - I'm a little fuzzy on how would the\n> upstream maintainer know which sha1 referred to which patch.\n> \n> Philip\n"},{"id":"271718","messageId":"561F5E73.3050506@orange.fr","threadId":"40542","inReplyTo":"CA+P7+xoDia6PC+qJeVn3sD5g4jk7KRuDAPOcEHvrntd+ndUraA@mail.gmail.com","subject":"Re: How to rebase when some commit hashes are in some commit messages","fromName":"Francois-Xavier Le Bail","fromEmail":"devel.fx.lebail@orange.fr","sentAt":"2015-10-15T08:06:11Z","receivedAt":"2015-10-15T08:06:11Z","isPatch":false,"sender":{"key":"devel.fx.lebail@orange.fr","avatar":null},"body":"\n\nOn 13/10/2015 19:07, Jacob Keller wrote:\n\n> b) you are rebasing a commit which references another commit in the same rebase\n> \n> I see no valid reason to reference a sha1 in this case. If you're\n> referencing as a \"fixes\", then you are being silly since you can just\n> squash the fix into the original commit and thus prevent introduction\n> of bug at all.\n\nsquash need manual process, renaming the sha1 not.\n"},{"id":"271720","messageId":"561F5FF9.3070906@orange.fr","threadId":"40542","inReplyTo":"CANoM8SVAGQ4AL9wBiBMaAu0GvaotC8rhn-rWQhLjsyWr4DnXmw@mail.gmail.com","subject":"Re: How to rebase when some commit hashes are in some commit messages","fromName":"Francois-Xavier Le Bail","fromEmail":"devel.fx.lebail@orange.fr","sentAt":"2015-10-15T08:12:41Z","receivedAt":"2015-10-15T08:12:41Z","isPatch":false,"sender":{"key":"devel.fx.lebail@orange.fr","avatar":null},"body":"\n\nOn 13/10/2015 20:00, Mike Rappazzo wrote:\n> It seems reasonable that this could be added as a feature of\n> interactive rebase. The todo list could be automatically adjusted to\n> \"reword\" for those commits which are referring to other commits within\n> the same rebase. As each commit is re-written, a mapping could be\n> kept of old sha1 -> new sha1. Then when one of the reworded commits\n> is being applied, the old sha1 -> new sha1 mapping could be used to\n> add a line to the $COMMIT_MSG.\n\nEven for non-interactive rebase, it could work.\n"},{"id":"271723","messageId":"alpine.DEB.1.00.1510151134250.31610@s15462909.onlinehome-server.info","threadId":"40542","inReplyTo":"561F597B.8090102@orange.fr","subject":"Re: How to rebase when some commit hashes are in some commit messages","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2015-10-15T09:41:48Z","receivedAt":"2015-10-15T09:41:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Francois-Xavier,\n\nOn Thu, 15 Oct 2015, Francois-Xavier Le Bail wrote:\n\n> On 13/10/2015 15:29, Philip Oakley wrote:\n>\n> > Thus the only sha1 numbers that could be used are those that are\n> > within the (possibly implied) instruction sheet (which will list the\n> > current sha1s that will be converted by rebase to new sha1's).\n> \n> Yes.\n\nSo what happens for commits that are in the pick list but then end up not\nbeing rewritten at all, e.g. when a patch has been applied upstream (and\nthe --cherry logic did not detect that) and then you end up with a \"No\nchanges to commit\"? And what if a patch ends up in merge conflicts and the\nuser just skips it? And what if the referenced commit is to be picked\n*afterwards* due to the commits being reordered?\n\nIt would appear that the strategy you propose is still too ill-defined to\nmake for a robust feature.\n\nCiao,\nJohannes\n\nP.S.: The recommended way to refer to a commit is not only using the SHA-1\nbut also mentioning the one-line, and even the date. That way, even\nrebased commits can found most of the time. This is not fool-proof, by\nfar, of course, but still better than trying to rewrite a SHA-1 and\nfailing.\n"},{"id":"271805","messageId":"84D417D967EA4E31B0AD471329E9577C@PhilipOakley","threadId":"40542","inReplyTo":"alpine.DEB.1.00.1510151134250.31610@s15462909.onlinehome-server.info","subject":"Re: How to rebase when some commit hashes are in some commit messages","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2015-10-16T08:01:07Z","receivedAt":"2015-10-16T08:01:07Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Johannes Schindelin\" \n> Hi Francois-Xavier,\n>\n> On Thu, 15 Oct 2015, Francois-Xavier Le Bail wrote:\n>\n>> On 13/10/2015 15:29, Philip Oakley wrote:\n>>\n>> > Thus the only sha1 numbers that could be used are those that are\n>> > within the (possibly implied) instruction sheet (which will list the\n>> > current sha1s that will be converted by rebase to new sha1's).\n>>\n>> Yes.\n>\n> So what happens for commits that are in the pick list but then end up not\n> being rewritten at all, e.g. when a patch has been applied upstream (and\n> the --cherry logic did not detect that) and then you end up with a \"No\n> changes to commit\"? And what if a patch ends up in merge conflicts and the\n> user just skips it? And what if the referenced commit is to be picked\n> *afterwards* due to the commits being reordered?\n\nMy policy (bikeshed) for these style of occurrences would be that such \n'disappeared sha1 refs' should be considered as equivalent to a 'merge \nconflict' \"known\"<>\"unknown\", and drop the user into the appropriate review \ncode path so the user can fix it up.\n\nA sha1 ref can only 'disappear' if it was known before hand, that is, it \nmust have been reachable from the tip of the original rebase.\n\nOnly those commits between the original rebase tip and its merge-base with \nthe destination (e.g. --onto) are candidates for re-write. When taken along \nwith the minimum (config) length for a sha1 it should be pretty robust to \nfalse positives.\n\nIn the case of --orphan branch rebasing one does get left and right roots \nfor the 'merge-base' which is a particular corner case.\n\n>\n> It would appear that the strategy you propose is still too ill-defined to\n> make for a robust feature.\n>\n> Ciao,\n> Johannes\n>\n> P.S.: The recommended way to refer to a commit is not only using the SHA-1\n> but also mentioning the one-line, and even the date. That way, even\n> rebased commits can found most of the time. This is not fool-proof, by\n> far, of course, but still better than trying to rewrite a SHA-1 and\n> failing.\n>\n\nIn terms of re-writing a quoted --one-line ref, the tool must also be told \n(config option) the few valid quoting commands the user wishes to re-write, \nso that if the sha1 is part of a full quote then the whole quote can be \nreplaced by a fresh quote of the updated commit (especially in the --onto \ncase).\n"},{"id":"271874","messageId":"1634617.ZbHCyji7nE@x121e","threadId":"40542","inReplyTo":"561F597B.8090102@orange.fr","subject":"Re: How to rebase when some commit hashes are in some commit messages","fromName":"Thomas Koch","fromEmail":"thomas@koch.ro","sentAt":"2015-10-18T13:58:25Z","receivedAt":"2015-10-18T13:58:25Z","isPatch":false,"sender":{"key":"thomas@koch.ro","avatar":null},"body":"On Thursday 15 October 2015 09:44:59 Francois-Xavier Le Bail wrote:\n> >> On Tue, 13 Oct 2015 10:50:40 +0200\n> >> Francois-Xavier Le Bail wrote:\n> >>> >> For example, if I rebase the following commits, I would want that\n> >>> >> if the commit hash 2222222... become 7777777...,\n> >>> >> the message\n> >>> >> \"Update test output for 2222222222222222222222222222222222222222\"\n> >>> >> become\n> >>> >> \"Update test output for 7777777...\"\n> >>> >> \n> >>> >> Is it possible currently? And if yes how?\n\nThe code review system Gerrit (highly recommended!) uses a commit-hook to adds \na trailer line to every commit message, e.g.:\n\nChange-Id: Id8269a1aa4a2c7a1a584b23b01d63259410c4e85\n\nThis Change-Id is used to identify a change even if the change gets amended or \nrebased and thus is represented in a different commit.\n\nSo if you're using Gerrit you can refer to changes instead of commits and use \nthe Change-Id. Even if you don't use Gerrit you can still use its commit-hook \nto write the Change-Id trailers.\n\nRegards,\n\nThomas Koch\n"},{"id":"271876","messageId":"CACBZZX5K775B=w_RtwCowPoK54ZcL43WO5gTLrmAc8p8=D7Jxg@mail.gmail.com","threadId":"40542","inReplyTo":"561C1132.3090606@orange.fr","subject":"Re: How to rebase when some commit hashes are in some commit messages","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2015-10-18T16:23:39Z","receivedAt":"2015-10-18T16:23:39Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Mon, Oct 12, 2015 at 9:59 PM, Francois-Xavier Le Bail\n wrote:\n> Hello,\n>\n> [I try some search engines without success, perhaps I have missed something].\n>\n> For example, if I rebase the following commits, I would want that if\n> the commit hash 2222222... become 7777777...,\n> the message\n> \"Update test output for 2222222222222222222222222222222222222222\"\n> become\n> \"Update test output for 7777777...\"\n>\n> Is it possible currently? And if yes how?\n\nThis isn't strictly speaking an answer to your question (others have\ndone that), but in my workflow if I have a patch series where I want\nto refer to commits inside the series, and I know I'm going to rebase\nit I work around this by just using the subject line of the commit as\nan ID.\n\nE.g. in the message I'll say something like \"See my 'commit.c: Avoid\nsegfaults on OSX' commit for details\". Then I can just find that with\ngit log --grep.\n"}]}