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).
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
