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

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+...@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 222... become 777...,
>>> >> the message
>>> >> "Update test output for "
>>> >> become
>>> >> "Update test output for 777..."
>>> >>
>>> >> 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

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

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.leb...@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 222... become 777...,
>> the message
>> "Update test output for "
>> become
>> "Update test output for 777..."
>>
>> 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?
--
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

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 222... become 777...,
the message
"Update test output for "
become
"Update test output for 777..."

Is it possible currently? And if yes how?

Greetings,
Francois-Xavier

---
commit 
Author: First Last 
Date:  Fri Jul 3 17:14:58 2015 -0700

Fix 5

xxx xxx xxx xxx

commit 
Author: First Last 
Date:  Fri Jul 3 16:58:58 2015 -0700

Update test output for 

commit 
Author: First Last 
Date:  Fri Jul 3 17:50:27 2015 -0700

Fix 4

commit 
Author: First Last 
Date:  Fri Jul 3 15:01:36 2015 -0700

Fix 3

xxx xxx xxx xxx

commit 
Author: First Last 
Date:  Fri Jul 3 11:20:28 2015 -0700

Fix 2

xxx xxx xxx xxx

commit 
Author: First Last 
Date:  Fri Jul 3 09:15:59 2015 -0700

Fix 1

xxx xxx xxx xxx

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