[Added] kallithea pull request #29 from pytest_migration

[Thomas De Schampheleire]

On Feb 14, 2016 11:46 PM, "Mads Kiilerich" <mads at kiilerich.com> wrote:
>
> On 02/14/2016 09:11 PM, Thomas De Schampheleire wrote:
>>
>>
>>>> 3) I can't say bookmarks don't provide the same visibility as named
>>>> branches do, but at least there can be just one bookmark with the said
>>>> name, which means it's always the most recent version of the PR.
>>>
>>>
>>> A named branch (as revision specification) will also only designate one
>>> revision. Like with bookmarks, it can easily move forward in the easy
>>> unambiguous case. Switching to a different DAG branch can and will only
>>> happen when explicitly requested when pushing. With named branches it
can be
>>> confusing that the old heads still are around - with bookmarks it can be
>>> confusing they are not.
>>>
>>> I see no significant difference ... except that named branches make it
very
>>> explicit in a shared repository what the different changesets belong
to. Do
>>> whatever you want - just make sure the PR contains the right changes ;-)
>>
>> Now this set of changes are merged (thanks!) I'm now facing the first
>> annoying thing about the named branch approach: assuming I will reuse
>> the same branch for more pytest changes, I now need to add a merge
>> with the default branch to avoid divergence (during the integration to
>> default there may have been some fixups by Mads).
>
>
> Why do need to merge? You can either restart the branch from 'default',
or rebase the branch to default with --keepbranches.

But what will happen when I push to kallithea-incoming with such a moved
branch? It also requires changeset evolution, right?

>
>
>> With a bookmark this would be different.
>
>
> Why would it be any different with a bookmark?
>
> /Mads
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20160215/efd33b8a/attachment.html>