Re: Draft of Git Rev News edition 38

[Christian Couder <christian.couder@gmail.com>]

Hi Sergey,

On Mon, Apr 16, 2018 at 2:29 PM, Sergey Organov <sorganov@gmail.com> wrote:
> Hi Christian,
>
> Christian Couder <christian.couder@gmail.com> writes:
>> On Mon, Apr 16, 2018 at 12:11 AM, Christian Couder
>> <christian.couder@gmail.com> wrote:
>>>
>>> A draft of a new Git Rev News edition is available here:
>>>
>>>   https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-38.md
>>
>> The draft has just been updated with 2 articles contributed by Jake
>> about rebasing merges, so I am cc'ing more people involved in those
>> discussions.
>
> I find this section of the draft pretty close to my own vision of what
> and how has been discussed, except for a few issues.
>
> [all quotations below are taken from the draft]
>
>> Some discussion about --preserve-merges and compatibility with scripts
>> (i.e. should we change or fix it? or should we deprecate it?)
>> followed.
>>
>>    Rebasing merges: a jorney to the ultimate solution (Road Clear)
>>    (written by Jacob Keller)
>
> What article by Jacob is actually meant here I have no idea, please
> check, as this one, and the RFC this refers to, was written by me, not
> by Jacob,

Jake wrote the article below the above line. His article summarizes
the discussions that happened following your email that is linked to
in the above line. The above line is actually the title of Jake's
second article.

> and it is the outline of potential method of actually rebasing
> merges that is discussed in the next paragraph, so it likely belongs
> right after the next paragraph:
>
>> After the discussions in the above article

Here "the above article" means the Jake's "branch -l: print useful
info whilst rebasing a non-local branch" article above the current
article.

>> Sergey posted an outline of a
>> potential method for actually rebasing a merge (as opposed to recreating
>> it from scratch) which used a process of git cherry-pick -mN of the
>> merge onto each topic branch being merged, and then merging the result.
>
> The reference to:
>
>     Rebasing merges: a jorney to the ultimate solution (Road Clear)
>     (written by Sergey Organov)
>
> belongs here, if at all.

You call it a reference but it is actually the title of the article
that Jake wrote. Yes, it contains a link to your email, but that is
just because we want to make it easy and straightforward for people
who are interested in all the discussions to find them.

It has been like this since the very beginning of Git Rev News. For
example in the first edition
(https://git.github.io/rev_news/2015/03/25/edition-1/) the first
article was contributed by Junio so you can see "Promoting Git
developers (written by Junio C Hamano)" where "Promoting Git
developers" is a link to the following email (yeah the link is not
valid anymore because Gmane is no more) that I wrote:

https://public-inbox.org/git/CAP8UFD1+rC0FjisSddDcyn1E_75wtBU9pEpUcQX5zNtd4zKYFQ@mail.gmail.com/

> In addition, I'd like to see a minor edition to the following:
>
>> Sergey replied that he thinks the solution produces the same result as
>> his updated strategy.
>
> This has been said in the context that assumed lack of conflicts during
> application of both strategies. Something like this, maybe:
>
> "Sergey replied that he thinks the solution produces the same result as
> his updated strategy, at least when none of the strategies produce any
> conflicts."

Ok with this change.

> Next, this is very close, but not exactly right:
>
>> Further suggestions to the strategy were proposed and tested, ultimately
>> resulting in Sergey proposing the addition of using the original merge
>> commit as a merge base during the final step.
>
> This was not an addition, this was a fix of particular mistake in the
> original RFC that has been revealed during testing. I didn't get it
> right at first that it's original merge commit that must be used as
> merge base, so my original proposal ended up implicitly using wrong
> merge base, that is the one computed by "git merge-base U1' U2'".
>
> Something along these lines may fit better:
>
> "Further suggestions to the strategy were proposed and tested,
> ultimately resulting in Sergey proposing the fix to his method,
> specifically using the original merge commit as a merge base during the
> final step."

Ok with this change except for s/the fix to his method/a fix to his
method/ as I think it reads better with "a".

> I'd also like a reference to the final fixed [RFC v2] be added right
> here. The reference is:
>
> https://public-inbox.org/git/87r2oxe3o1.fsf@javad.com/

Ok to add this link.

I just pushed the changes

Thanks for your comments,
Christian.