Re: How to rebase when some commit hashes are in some commit messages
On Mon, Oct 12, 2015 at 9:59 PM, Francois-Xavier Le Bail wrote: > Hello, > > [I try some search engines without success, perhaps I have missed something]. > > For example, if I rebase the following commits, I would want that if > the commit hash 222... become 777..., > the message > "Update test output for " > become > "Update test output for 777..." > > Is it possible currently? And if yes how? This isn't strictly speaking an answer to your question (others have done that), but in my workflow if I have a patch series where I want to refer to commits inside the series, and I know I'm going to rebase it I work around this by just using the subject line of the commit as an ID. E.g. in the message I'll say something like "See my 'commit.c: Avoid segfaults on OSX' commit for details". Then I can just find that with git log --grep. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to rebase when some commit hashes are in some commit messages
On Thursday 15 October 2015 09:44:59 Francois-Xavier Le Bail wrote: > >> On Tue, 13 Oct 2015 10:50:40 +0200 > >> Francois-Xavier Le Bail wrote: > >>> >> For example, if I rebase the following commits, I would want that > >>> >> if the commit hash 222... become 777..., > >>> >> the message > >>> >> "Update test output for " > >>> >> become > >>> >> "Update test output for 777..." > >>> >> > >>> >> Is it possible currently? And if yes how? The code review system Gerrit (highly recommended!) uses a commit-hook to adds a trailer line to every commit message, e.g.: Change-Id: Id8269a1aa4a2c7a1a584b23b01d63259410c4e85 This Change-Id is used to identify a change even if the change gets amended or rebased and thus is represented in a different commit. So if you're using Gerrit you can refer to changes instead of commits and use the Change-Id. Even if you don't use Gerrit you can still use its commit-hook to write the Change-Id trailers. Regards, Thomas Koch -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to rebase when some commit hashes are in some commit messages
From: "Johannes Schindelin" Hi Francois-Xavier, On Thu, 15 Oct 2015, Francois-Xavier Le Bail wrote: On 13/10/2015 15:29, Philip Oakley wrote: > 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). Yes. So what happens for commits that are in the pick list but then end up not being rewritten at all, e.g. when a patch has been applied upstream (and the --cherry logic did not detect that) and then you end up with a "No changes to commit"? And what if a patch ends up in merge conflicts and the user just skips it? And what if the referenced commit is to be picked *afterwards* due to the commits being reordered? My policy (bikeshed) for these style of occurrences would be that such 'disappeared sha1 refs' should be considered as equivalent to a 'merge conflict' "known"<>"unknown", and drop the user into the appropriate review code path so the user can fix it up. A sha1 ref can only 'disappear' if it was known before hand, that is, it must have been reachable from the tip of the original rebase. Only those commits between the original rebase tip and its merge-base with the destination (e.g. --onto) are candidates for re-write. When taken along with the minimum (config) length for a sha1 it should be pretty robust to false positives. In the case of --orphan branch rebasing one does get left and right roots for the 'merge-base' which is a particular corner case. It would appear that the strategy you propose is still too ill-defined to make for a robust feature. Ciao, Johannes P.S.: The recommended way to refer to a commit is not only using the SHA-1 but also mentioning the one-line, and even the date. That way, even rebased commits can found most of the time. This is not fool-proof, by far, of course, but still better than trying to rewrite a SHA-1 and failing. In terms of re-writing a quoted --one-line ref, the tool must also be told (config option) the few valid quoting commands the user wishes to re-write, so that if the sha1 is part of a full quote then the whole quote can be replaced by a fresh quote of the updated commit (especially in the --onto case). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to rebase when some commit hashes are in some commit messages
Hi Francois-Xavier, On Thu, 15 Oct 2015, Francois-Xavier Le Bail wrote: > On 13/10/2015 15:29, Philip Oakley wrote: > > > 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). > > Yes. So what happens for commits that are in the pick list but then end up not being rewritten at all, e.g. when a patch has been applied upstream (and the --cherry logic did not detect that) and then you end up with a "No changes to commit"? And what if a patch ends up in merge conflicts and the user just skips it? And what if the referenced commit is to be picked *afterwards* due to the commits being reordered? It would appear that the strategy you propose is still too ill-defined to make for a robust feature. Ciao, Johannes P.S.: The recommended way to refer to a commit is not only using the SHA-1 but also mentioning the one-line, and even the date. That way, even rebased commits can found most of the time. This is not fool-proof, by far, of course, but still better than trying to rewrite a SHA-1 and failing. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to rebase when some commit hashes are in some commit messages
On 13/10/2015 20:00, Mike Rappazzo wrote: > It seems reasonable that this could be added as a feature of > interactive rebase. The todo list could be automatically adjusted to > "reword" for those commits which are referring to other commits within > the same rebase. As each commit is re-written, a mapping could be > kept of old sha1 -> new sha1. Then when one of the reworded commits > is being applied, the old sha1 -> new sha1 mapping could be used to > add a line to the $COMMIT_MSG. Even for non-interactive rebase, it could work. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to rebase when some commit hashes are in some commit messages
On 13/10/2015 19:07, Jacob Keller wrote: > b) you are rebasing a commit which references another commit in the same > rebase > > I see no valid reason to reference a sha1 in this case. If you're > referencing as a "fixes", then you are being silly since you can just > squash the fix into the original commit and thus prevent introduction > of bug at all. squash need manual process, renaming the sha1 not. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to rebase when some commit hashes are in some commit messages
On 13/10/2015 15:29, Philip Oakley wrote: > From: "Konstantin Khomoutov" >> On Tue, 13 Oct 2015 10:50:40 +0200 >> Francois-Xavier Le Bail wrote: >> >>> >> For example, if I rebase the following commits, I would want that >>> >> if the commit hash 222... become 777..., >>> >> the message >>> >> "Update test output for " >>> >> become >>> >> "Update test output for 777..." >>> >> >>> >> Is it possible currently? And if yes how? >>> > >>> > AFAIK, it's not possible other than by editing the message by hand. >>> >>> It seems to me useful to be able to do it. Can we hope a new option? >> >> How do you think this could be practically implemented? >> >> A couple of things which immediately spring to my mind: >> >> To begin with, you are free to specify just a few first characters of >> the commit name you're referring to. So the alogrythm which finds the >> relevant commits them has to be smart to somehow avoid misfires. Or >> have knobs to tune it (like -M of `git log`). >> >> OK, suppose that this is solved through the usage of some agreed-upon >> keywords in the commit message. Say, you adopt a policy to put >> something like >> >> X-Refers-To: 2dd8a9d9bb33ebffccb2ff516497adc8535bcab4 >> >> in your commit message to make the finder tool happy. >> >> Now think how exactly it should work. First, any commit at all might >> mention the name of the target commit in its commit message. Okay, >> let's suppose there will be some way to somehow prune the possible DAG >> down. Then what happens if the commit to change is a part of the chain >> of commits reachable from some branch other than that you're rebasing? >> Automatically rebasing it would rewrite that commits and all commits >> "after" it -- possibly resulting in what the "Recovering from upstream >> rebase" part of the git-rebase(1) manual page deals with. >> >> Having said that, the feature you're after appears to me to be a >> sensible thing to have but the possibility of its generic implementation >> appears to be moot. >> >> Note that to deal with narrow simple cases (all possibly affected >> commits leave on the same branch you're rebasing, and come later than >> the rebase's anchor) you could write a script which uses `git log` to >> find those commits which need special care. > > 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 > upstream consumption, with social controls and understandings with colleagues. > > 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). Yes. > 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). > > 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. I think full 40 sha1 is more secure to avoid confusion with previous or future sha1. > 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 > upstream maintainer know which sha1 referred to which patch. > > Philip -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to rebase when some commit hashes are in some commit messages
From: "Jacob Keller" On Tue, Oct 13, 2015 at 12:24 PM, Philip Oakley wrote: IIUC (as an alternate example), in G4W one can submit a (long) pull request with internal back references that would be merged directly, so the sha1's could be updated as Francois-Xavier originally asked. I have a series that's been bumping along for a long while that needs regular rebasing, though doesn't have sha1 back references, so I can see that the need does happen. I can see that others may have a workflow that would work well with the sha1 auto-update. -- Philip I still don't see how this is useful, because the part that *can* be implemented is not valuable and the part that is valuable can't be implemented. So, what we can implement easily enough: you rebase a series and any time the message contains sha1 of a commit we're modifying in this rebase, we update the sha1 to match again. This seems reasonable, but not useful. Why would you reference a commit that is *ITSELF* being rebased. No one has explained a reasonable use for this... I'm sure there exists one, but I would want an explanation of one first. This particular case is about self-references within a long series. At the moment, on the Git list there is general comments about say [PATCH v3 18/44], whichs is great for for the list ($gmane) but not for a `git log`. In flows where PRs are valid, one can have what was [34/44] refering to prior patch [26/44] as `deadbeaf` or whatever. It won't be suitable for most flows but will be useful for a proportion (as already evidenced by the request). The "useful" case is if you rebase "onto" a tree that has a previous history that has been changed. In this case, how do you propose we find it. This use case (where upstream also rebases) hasn't been considered. It would be a tricky one. As long as the possibility (of such an A depends on B re-write) isn't closed off then the smaller requested case could still go ahead. Doing as suggested above, ie: only changing sha1s that we are already rebasing works, but why are you backreferencing it if you are re-writing the commit? Essentially one wants to say `$CURR_COMMIT~nn` (i.e. "see nn commits earlier in my series") and have that replaced with its cannonical sha1, and updated when rebased. It sort of begs the question whether there should be a ref shorthand for "the (this) current commit" to allow THIS~ as an interpretable [valid?] format. That doesn't make sense to me at all. Yes, you can do it, but I don't get why this is valuable. If you're backref is "fixes xyz" why not just fix xyz instead of have two commits. If the back ref has some other value... what is that value? I don't understand it I guess. For the 'fixes' (of a bug report) case we are already talking about an immutable so it would not be part of this. Its use may be more of the type "Using helper function xyz introduced earlier in patch abcde", which would change after each rebase. It just seems pretty narrow focus. I mean if someone wants to implement it, that is fine. Agreed -- Philip -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to rebase when some commit hashes are in some commit messages
On Tue, Oct 13, 2015 at 12:24 PM, Philip Oakley wrote: > IIUC (as an alternate example), in G4W one can submit a (long) pull request > with internal back references that would be merged directly, so the sha1's > could be updated as Francois-Xavier originally asked. I have a series that's > been bumping along for a long while that needs regular rebasing, though > doesn't have sha1 back references, so I can see that the need does happen. I > can see that others may have a workflow that would work well with the sha1 > auto-update. > > -- > Philip > I still don't see how this is useful, because the part that *can* be implemented is not valuable and the part that is valuable can't be implemented. So, what we can implement easily enough: you rebase a series and any time the message contains sha1 of a commit we're modifying in this rebase, we update the sha1 to match again. This seems reasonable, but not useful. Why would you reference a commit that is *ITSELF* being rebased. No one has explained a reasonable use for this... I'm sure there exists one, but I would want an explanation of one first. The "useful" case is if you rebase "onto" a tree that has a previous history that has been changed. In this case, how do you propose we find it. Doing as suggested above, ie: only changing sha1s that we are already rebasing works, but why are you backreferencing it if you are re-writing the commit? That doesn't make sense to me at all. Yes, you can do it, but I don't get why this is valuable. If you're backref is "fixes xyz" why not just fix xyz instead of have two commits. If the back ref has some other value... what is that value? I don't understand it I guess. It just seems pretty narrow focus. I mean if someone wants to implement it, that is fine. Regards, Jake -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to rebase when some commit hashes are in some commit messages
From: "Mike Rappazzo" On Tue, Oct 13, 2015 at 1:07 PM, Jacob Keller wrote: On Tue, Oct 13, 2015 at 6:29 AM, Philip Oakley wrote: 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 upstream consumption, with social controls and understandings with colleagues. Agreed here. There would be no need to change any sha1s that didn't change during the rebase. This limits the scope. Alright. 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). Correct, you would be able to limit the number of sha1s to search for. However, (see below), any reasonable reference to a sha1 should be relatively stable. 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). 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. 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 upstream maintainer know which sha1 referred to which patch. My issue: the only sha1s in commit messages are *generally* things which will NOT be changed in general. Supporting a work flow that wants to change these is definitely crazy. Essentially: I don't see a reason that you would be rebasing a commit and needing to change any references in it. You can reference a commit which isn't changing, but here's the possible situations I see: a) you are rebasing a commit which references in the message a commit that is not being changed (it is ancient) In this case, nothing needs to be done. b) you are rebasing a commit which references another commit in the same rebase I see no valid reason to reference a sha1 in this case. If you're referencing as a "fixes", then you are being silly since you can just squash the fix into the original commit and thus prevent introduction of bug at all. What other reason? If you are referencing such as "thix extends implementation from sha1" then your commit message is probably poorly formatted. I don't see a reason to support this flow. c) you are rebasing a commit which is referencing a commit that has already been changed. (?) I think (maybe) this is your interesting case, but here are some caveats. Let's say you are fixing some old commit such as "Fixes: " or something. If you do a "git pull --rebase", your commit might be updated to play ontop of more new work, but the sha1 should still be valid, *unless* the remote history did some rewind, at which point I don't think any algorithm will work, see the issues above. It may be something worth doing in git-filter-branch, but then you're looking at losing the two assumptions above making it really hard to get right. Regards, Jake It seems reasonable that this could be added as a feature of interactive rebase. The todo list could be automatically adjusted to "reword" for those commits which are referring to other commits within the same rebase. As each commit is re-written, a mapping could be kept of old sha1 -> new sha1. Then when one of the reworded commits is being applied, the old sha1 -> new sha1 mapping could be used to add a line to the $COMMIT_MSG. -- The extra fun begins if the commit message is of a one-line pretty quoted style, where more of the quote needs changing... e.g. [alias] quote = log -1 --pretty='tformat:%h (%s, %ad)' --date=short log1 = log -1 --pretty=\"format:%ad %h (%an): %s\" --date=short Jake was concerned about the 'crazy' workflow, however almost all workflows are crazy at a distance. The rebase is required if the workflow's allowed base point moves forward faster than one can complete the (likely long) patch series, so the series is rebased and then an acceptable series can be merged without modifications. Git has the former issue i.e. master and next can move forward faster than a long series takes to be reviewed, but does not have the latter because Junio adds his signature to each commit, and uses the patch submission flow. IIUC (as an alternate example), in G4W one can submit a (long) pull request with internal back references that would be merged directly, so the sha1's could be updated as Francois-Xavier originally asked. I have a series that's been bumping along for a long while that needs regular rebasing, though doesn't have sha1 back references, so I can see that the need does happen. I can see that others may have a workflow that would work well with the sha1 auto-update. -- Philip -- To
Re: How to rebase when some commit hashes are in some commit messages
On Tue, Oct 13, 2015 at 1:07 PM, Jacob Keller wrote: > On Tue, Oct 13, 2015 at 6:29 AM, Philip Oakley wrote: >> 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 upstream consumption, with social >> controls and understandings with colleagues. >> > > Agreed here. There would be no need to change any sha1s that didn't > change during the rebase. This limits the scope. Alright. > >> 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). >> > > Correct, you would be able to limit the number of sha1s to search for. > > However, (see below), any reasonable reference to a sha1 should be > relatively stable. > >> 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). >> >> 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. >> >> 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 upstream >> maintainer know which sha1 referred to which patch. >> > > My issue: the only sha1s in commit messages are *generally* things > which will NOT be changed in general. Supporting a work flow that > wants to change these is definitely crazy. > > Essentially: I don't see a reason that you would be rebasing a commit > and needing to change any references in it. You can reference a commit > which isn't changing, but here's the possible situations I see: > > a) you are rebasing a commit which references in the message a commit > that is not being changed (it is ancient) > > In this case, nothing needs to be done. > > b) you are rebasing a commit which references another commit in the same > rebase > > I see no valid reason to reference a sha1 in this case. If you're > referencing as a "fixes", then you are being silly since you can just > squash the fix into the original commit and thus prevent introduction > of bug at all. > > What other reason? If you are referencing such as "thix extends > implementation from sha1" then your commit message is probably poorly > formatted. I don't see a reason to support this flow. > > c) you are rebasing a commit which is referencing a commit that has > already been changed. (?) > > I think (maybe) this is your interesting case, but here are some caveats. > > Let's say you are fixing some old commit such as "Fixes: summary, date>" or something. > > If you do a "git pull --rebase", your commit might be updated to play > ontop of more new work, but the sha1 should still be valid, *unless* > the remote history did some rewind, at which point I don't think any > algorithm will work, see the issues above. > > It may be something worth doing in git-filter-branch, but then you're > looking at losing the two assumptions above making it really hard to > get right. > > Regards, > Jake It seems reasonable that this could be added as a feature of interactive rebase. The todo list could be automatically adjusted to "reword" for those commits which are referring to other commits within the same rebase. As each commit is re-written, a mapping could be kept of old sha1 -> new sha1. Then when one of the reworded commits is being applied, the old sha1 -> new sha1 mapping could be used to add a line to the $COMMIT_MSG. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to rebase when some commit hashes are in some commit messages
On Tue, Oct 13, 2015 at 6:29 AM, Philip Oakley wrote: > 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 upstream consumption, with social > controls and understandings with colleagues. > Agreed here. There would be no need to change any sha1s that didn't change during the rebase. This limits the scope. Alright. > 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). > Correct, you would be able to limit the number of sha1s to search for. However, (see below), any reasonable reference to a sha1 should be relatively stable. > 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). > > 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. > > 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 upstream > maintainer know which sha1 referred to which patch. > My issue: the only sha1s in commit messages are *generally* things which will NOT be changed in general. Supporting a work flow that wants to change these is definitely crazy. Essentially: I don't see a reason that you would be rebasing a commit and needing to change any references in it. You can reference a commit which isn't changing, but here's the possible situations I see: a) you are rebasing a commit which references in the message a commit that is not being changed (it is ancient) In this case, nothing needs to be done. b) you are rebasing a commit which references another commit in the same rebase I see no valid reason to reference a sha1 in this case. If you're referencing as a "fixes", then you are being silly since you can just squash the fix into the original commit and thus prevent introduction of bug at all. What other reason? If you are referencing such as "thix extends implementation from sha1" then your commit message is probably poorly formatted. I don't see a reason to support this flow. c) you are rebasing a commit which is referencing a commit that has already been changed. (?) I think (maybe) this is your interesting case, but here are some caveats. Let's say you are fixing some old commit such as "Fixes: " or something. If you do a "git pull --rebase", your commit might be updated to play ontop of more new work, but the sha1 should still be valid, *unless* the remote history did some rewind, at which point I don't think any algorithm will work, see the issues above. It may be something worth doing in git-filter-branch, but then you're looking at losing the two assumptions above making it really hard to get right. Regards, Jake -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to rebase when some commit hashes are in some commit messages
From: "Konstantin Khomoutov" On Tue, 13 Oct 2015 10:50:40 +0200 Francois-Xavier Le Bail wrote: >> For example, if I rebase the following commits, I would want that >> if the commit hash 222... become 777..., >> the message >> "Update test output for " >> become >> "Update test output for 777..." >> >> Is it possible currently? And if yes how? > > AFAIK, it's not possible other than by editing the message by hand. It seems to me useful to be able to do it. Can we hope a new option? How do you think this could be practically implemented? A couple of things which immediately spring to my mind: To begin with, you are free to specify just a few first characters of the commit name you're referring to. So the alogrythm which finds the relevant commits them has to be smart to somehow avoid misfires. Or have knobs to tune it (like -M of `git log`). OK, suppose that this is solved through the usage of some agreed-upon keywords in the commit message. Say, you adopt a policy to put something like X-Refers-To: 2dd8a9d9bb33ebffccb2ff516497adc8535bcab4 in your commit message to make the finder tool happy. Now think how exactly it should work. First, any commit at all might mention the name of the target commit in its commit message. Okay, let's suppose there will be some way to somehow prune the possible DAG down. Then what happens if the commit to change is a part of the chain of commits reachable from some branch other than that you're rebasing? Automatically rebasing it would rewrite that commits and all commits "after" it -- possibly resulting in what the "Recovering from upstream rebase" part of the git-rebase(1) manual page deals with. Having said that, the feature you're after appears to me to be a sensible thing to have but the possibility of its generic implementation appears to be moot. Note that to deal with narrow simple cases (all possibly affected commits leave on the same branch you're rebasing, and come later than the rebase's anchor) you could write a script which uses `git log` to find those commits which need special care. 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 upstream consumption, with social controls and understandings with colleagues. 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). 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). 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. 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 upstream maintainer know which sha1 referred to which patch. Philip -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to rebase when some commit hashes are in some commit messages
On Tue, 13 Oct 2015 10:50:40 +0200 Francois-Xavier Le Bail wrote: > >> For example, if I rebase the following commits, I would want that > >> if the commit hash 222... become 777..., > >> the message > >> "Update test output for " > >> become > >> "Update test output for 777..." > >> > >> Is it possible currently? And if yes how? > > > > AFAIK, it's not possible other than by editing the message by hand. > > It seems to me useful to be able to do it. Can we hope a new option? How do you think this could be practically implemented? A couple of things which immediately spring to my mind: To begin with, you are free to specify just a few first characters of the commit name you're referring to. So the alogrythm which finds the relevant commits them has to be smart to somehow avoid misfires. Or have knobs to tune it (like -M of `git log`). OK, suppose that this is solved through the usage of some agreed-upon keywords in the commit message. Say, you adopt a policy to put something like X-Refers-To: 2dd8a9d9bb33ebffccb2ff516497adc8535bcab4 in your commit message to make the finder tool happy. Now think how exactly it should work. First, any commit at all might mention the name of the target commit in its commit message. Okay, let's suppose there will be some way to somehow prune the possible DAG down. Then what happens if the commit to change is a part of the chain of commits reachable from some branch other than that you're rebasing? Automatically rebasing it would rewrite that commits and all commits "after" it -- possibly resulting in what the "Recovering from upstream rebase" part of the git-rebase(1) manual page deals with. Having said that, the feature you're after appears to me to be a sensible thing to have but the possibility of its generic implementation appears to be moot. Note that to deal with narrow simple cases (all possibly affected commits leave on the same branch you're rebasing, and come later than the rebase's anchor) you could write a script which uses `git log` to find those commits which need special care. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to rebase when some commit hashes are in some commit messages
On 12/10/2015 22:21, Matthieu Moy wrote: > Francois-Xavier Le Bail writes: > >> Hello, >> >> [I try some search engines without success, perhaps I have missed something]. >> >> For example, if I rebase the following commits, I would want that if >> the commit hash 222... become 777..., >> the message >> "Update test output for " >> become >> "Update test output for 777..." >> >> Is it possible currently? And if yes how? > > AFAIK, it's not possible other than by editing the message by hand. It seems to me useful to be able to do it. Can we hope a new option? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to rebase when some commit hashes are in some commit messages
Francois-Xavier Le Bail writes: > Hello, > > [I try some search engines without success, perhaps I have missed something]. > > For example, if I rebase the following commits, I would want that if > the commit hash 222... become 777..., > the message > "Update test output for " > become > "Update test output for 777..." > > Is it possible currently? And if yes how? AFAIK, it's not possible other than by editing the message by hand. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
