On Mon, Apr 16, 2018 at 5:29 AM, Sergey Organov <sorganov@xxxxxxxxx> wrote: > Hi Christian, > > Christian Couder <christian.couder@xxxxxxxxx> writes: >> On Mon, Apr 16, 2018 at 12:11 AM, Christian Couder >> <christian.couder@xxxxxxxxx> 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, 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: I believe he meant that the summary on git rev news was written by me, that's all :) > >> After the discussions in the above 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. > > 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." > > 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." > > 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@xxxxxxxxx/ > > Thanks a lot! > > -- Sergey Yep that all sounds right to me also. Thanks, Jake
