On 13/10/2015 15:29, Philip Oakley wrote: > From: "Konstantin Khomoutov" <kostix+...@007spb.ru> >> On Tue, 13 Oct 2015 10:50:40 +0200 >> Francois-Xavier Le Bail <devel.fx.leb...@orange.fr> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
