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

["Philip Oakley" <philipoakley@iee.org>]

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