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