On 13/10/2015 15:29, Philip Oakley wrote: > From: "Konstantin Khomoutov" <kostix+git@xxxxxxxxx> >> On Tue, 13 Oct 2015 10:50:40 +0200 >> Francois-Xavier Le Bail <devel.fx.lebail@xxxxxxxxx> wrote: >> >>> >> For example, if I rebase the following commits, I would want that >>> >> if the commit hash 2222222... become 7777777..., >>> >> the message >>> >> "Update test output for 2222222222222222222222222222222222222222" >>> >> become >>> >> "Update test output for 7777777..." >>> >> >>> >> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html