Re: How to rebase when some commit hashes are in some commit messages

From: Konstantin Khomoutov <kostix+git@007spb.ru>
Date: Oct 13, 2015, 13:00 UTC
Message-ID: <20151013160004.11a103942062ee09c53bd235@domain007.com>
In-Reply-To: <561CC5E0.7060206@orange.fr>

On Tue, 13 Oct 2015 10:50:40 +0200 Francois-Xavier Le Bail <devel.fx.lebail@orange.fr> wrote:

Show 12 quoted lines

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