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

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

[Francois-Xavier Le Bail]

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 2222222... become 7777777...,
the message
"Update test output for 2222222222222222222222222222222222222222"
become
"Update test output for 7777777..."

Is it possible currently? And if yes how?

Greetings,
Francois-Xavier

-------------------------------------------------------------------
commit 6666666666666666666666666666666666666666
Author: First Last <first.last@example.com>
Date:  Fri Jul 3 17:14:58 2015 -0700

Fix 5

xxx xxx xxx xxx

commit 5555555555555555555555555555555555555555
Author: First Last <first.last@example.com>
Date:  Fri Jul 3 16:58:58 2015 -0700

Update test output for 2222222222222222222222222222222222222222

commit 4444444444444444444444444444444444444444
Author: First Last <first.last@example.com>
Date:  Fri Jul 3 17:50:27 2015 -0700

Fix 4

commit 3333333333333333333333333333333333333333
Author: First Last <first.last@example.com>
Date:  Fri Jul 3 15:01:36 2015 -0700

Fix 3

xxx xxx xxx xxx

commit 2222222222222222222222222222222222222222
Author: First Last <first.last@example.com>
Date:  Fri Jul 3 11:20:28 2015 -0700

Fix 2

xxx xxx xxx xxx

commit 1111111111111111111111111111111111111111
Author: First Last <first.last@example.com>
Date:  Fri Jul 3 09:15:59 2015 -0700

Fix 1

xxx xxx xxx xxx

-------------------------------------------------------------------

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

[Matthieu Moy]

Francois-Xavier Le Bail <devel.fx.lebail@orange.fr> 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 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.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Francois-Xavier Le Bail]

On 12/10/2015 22:21, Matthieu Moy wrote:
> Francois-Xavier Le Bail <devel.fx.lebail@orange.fr> 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 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?

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

[Konstantin Khomoutov]

On Tue, 13 Oct 2015 10:50:40 +0200
Francois-Xavier Le Bail <devel.fx.lebail@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.

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

[Philip Oakley]

From: "Konstantin Khomoutov" <kostix+git@007spb.ru>
> On Tue, 13 Oct 2015 10:50:40 +0200
> Francois-Xavier Le Bail <devel.fx.lebail@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 

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

[Jacob Keller]

On Tue, Oct 13, 2015 at 6:29 AM, Philip Oakley <philipoakley@iee.org> 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: <sha1,
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

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

[Mike Rappazzo]

On Tue, Oct 13, 2015 at 1:07 PM, Jacob Keller <jacob.keller@gmail.com> wrote:
> On Tue, Oct 13, 2015 at 6:29 AM, Philip Oakley <philipoakley@iee.org> 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: <sha1,
> 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.

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

[Philip Oakley]

From: "Mike Rappazzo" <rappazzo@gmail.com>
> On Tue, Oct 13, 2015 at 1:07 PM, Jacob Keller <jacob.keller@gmail.com> 
> wrote:
>> On Tue, Oct 13, 2015 at 6:29 AM, Philip Oakley <philipoakley@iee.org> 
>> 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: <sha1,
>> 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.
> --
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

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

[Jacob Keller]

On Tue, Oct 13, 2015 at 12:24 PM, Philip Oakley <philipoakley@iee.org> 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

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

[Philip Oakley]

From: "Jacob Keller" <jacob.keller@gmail.com>
> On Tue, Oct 13, 2015 at 12:24 PM, Philip Oakley <philipoakley@iee.org>
> 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~<n> 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 

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

[Francois-Xavier Le Bail]

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.

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

[Francois-Xavier Le Bail]

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.

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

[Francois-Xavier Le Bail]

On 13/10/2015 15:29, Philip Oakley wrote:
> From: "Konstantin Khomoutov" <kostix+git@007spb.ru>
>> On Tue, 13 Oct 2015 10:50:40 +0200
>> Francois-Xavier Le Bail <devel.fx.lebail@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

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

[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?

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.

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

[Philip Oakley]

From: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
> 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).

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

[Thomas Koch]

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 <devel.fx.lebail@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?

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

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

[Ævar Arnfjörð Bjarmason]

On Mon, Oct 12, 2015 at 9:59 PM, Francois-Xavier Le Bail
<devel.fx.lebail@orange.fr> 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 2222222... become 7777777...,
> the message
> "Update test output for 2222222222222222222222222222222222222222"
> become
> "Update test output for 7777777..."
>
> 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.