[PATCH] rebase: 'pull --rebase' rebase on new branching only

[Ryan McElroy]

On 5/5/2016 11:57 PM, Pierre-Yves David wrote:
>
>
> On 05/05/2016 10:45 PM, Martin von Zweigbergk wrote:
>> On Thu, May 5, 2016 at 9:04 AM, Pierre-Yves David
>> <pierre-yves.david at ens-lyon.org> wrote:
>>> # HG changeset patch
>>> # User Pierre-Yves David <pierre-yves.david at ens-lyon.org>
>>> # Date 1462366525 -7200
>>> #      Wed May 04 14:55:25 2016 +0200
>>> # Node ID 7e72800c070d941f294c4e7ed91db29a08bac073
>>> # Parent  906a1c8a75fd8a18e43e8545eedcbe5222f84647
>>> # EXP-Topic pull.rebase
>>> rebase: 'pull --rebase' rebase on new branching only

"new branching" sounds awkward to me as a native english speaker. After 
reviewing what this patch does, I think it would be more clear to say 
"rebase on newly introduced branch only".

>> Meant for stable?
>
> No, this is a new behavior making 'hg pull --rebase' a bit closer to 
> its initial intend (and therefore hopefully more reliable to build 
> work-flow on) but the 3.7 behavior was even more baroque so no 
> regression testing here.

Are you saying that `hg pull --rebase` was intended to have 
non-idempotent semantics? Or am I missing something? Can you spell out 
what you think the original intention was, and why getting closer to it 
is a good thing?

>
>>> Previously, if two heads existed on the current branch before the 
>>> pull and the
>>> pull add changeset on the one unrelated to the working copy 'hg pull 
>>> --rebase'
>>> would trigger a rebase on that branch. This might not what the user 
>>> wants
>>> as they could have resolved the head situation before pulling if 
>>> they wanted to.

The new behavior might also not be what the user wants, so I don't think 
this is a good enough reason to make the change.

The changes I would like to see in pull --rebase are to make it so that 
`hg pull && hg pull --rebase` (eg, "oh crap I forgot the flag") has the 
same result as `hg pull --rebase` from the beginning. This patch doesn't 
move us in that direction (indeed, I would argue that it moves us 
further away), so I'm skeptical of the direction.

That being said, after having written all this, I see that you have had 
a nice long discussion about it already over at 
https://bz.mercurial-scm.org/show_bug.cgi?id=5214, so I'll bow out now, 
haha.


>>>
>>> Therefore, we restrict the set of destination candidate to 'hg pull 
>>> --rebase' to
>>> the set of pulled changesets that create a branching from the 
>>> current working
>>> copy branch.
>>>
>>> diff -r 906a1c8a75fd -r 7e72800c070d hgext/rebase.py
>>> --- a/hgext/rebase.py   Wed May 04 06:44:44 2016 +0900
>>> +++ b/hgext/rebase.py   Wed May 04 14:55:25 2016 +0200
>>> @@ -1245,15 +1245,18 @@ def pullrebase(orig, ui, repo, *args, **
>>>                   if 'source' in opts:
>>>                       del opts['source']
>>>                   # revsprepull is the len of the repo, not revnum 
>>> of tip.
>>> -                destspace = 
>>> list(repo.changelog.revs(start=revsprepull))
>>> +                destspace = repo.revs("(%ld and children(::.))::",
>>> + repo.changelog.revs(start=revsprepull))
>> Is this equivalent to repo.revs("(%d: and children(::.))::", 
>> revsprepull)?
>
> Almost, but if revsprepull is filtered (for some reason), the '%d:' 
> version will fail while the version using "%ld" and changelog.revs 
> will be robust.
>
> Cheers,
>