On Sun, 25 Jan 2009, Johannes Schindelin wrote:
> Hi,
>
> [please do not forget to Cc: me; today is a slow day, so I did not miss
> your mail, but that is definitely not true on other days.]
This was spur of the moment idea, one that I wouldn't mind if you
would miss it.
But now that you have something interesting to say, I'll re-added
CC list for this thread.
> On Sun, 25 Jan 2009, Jakub Narebski wrote:
>> Johannes Schindelin wrote:
>>
>>>> Hmm. You're right, that is not really intuitive. How about
>>>>
>>>> merge (B) A # Merge...
>>>>
>>>> instead?
>>>
>>> Or even better:
>>>
>>> merge B parent A' # Merge...
>>
>> merge B with A' # Merge...
>
> No, that does not catch the meaning.
Errr... I didn't mean for 'with' to mean 'into'.
> B is the _original_ merge commit. So it actually knows what parents it
> has, but we want to give the user the freedom to change those parents.
>
> The first parent is easy: this will be HEAD at that stage.
>
> The other parents will be relatively easy: just replace A' by something
> else.
>
> _However_ now that the merge commit B will be _redone_, we _still_ want to
> be able to refer to it later in the rebase script. Therefore, rebase has
> to know that we _redid_ B at this stage.
>
> Another idea:
>
> merge B Merge bla/blub
> parent A' bla/blub
It would be good idea... even better if 'p' shortcut was not taken
by 'pick'...
This is similar to your earlier idea:
merge 9383af1' was f39d50a Merge branch 'mh/unify-color' into next
# \ 9383af1 Revert previous two commits
Or perhaps:
merge A' D' into B Merge bla/blub
--
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
