<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 02/15/2016 11:57 AM, Thomas De
Schampheleire wrote:<br>
</div>
<blockquote
cite="mid:CAAXf6LVN=euGu0Pzi=WVgk_sov23y7oKke6QibjH7TnEPW-=qw@mail.gmail.com"
type="cite">
<div dir="ltr">
<p dir="ltr">On Feb 14, 2016 11:46 PM, "Mads Kiilerich" <<a
moz-do-not-send="true" href="mailto:mads@kiilerich.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:mads@kiilerich.com">mads@kiilerich.com</a></a>> wrote:<br>
>> On 02/14/2016 09:11 PM, Thomas De Schampheleire
wrote:<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>
>>> 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>
</div>
</blockquote>
<br>
I expect the shared kallithea-incoming to become a mess. There is no
point in keeping it tidy as long as everybody knows how to find
their own changes. With named branches (or bookmarks) that should be
easy. Thus, I don't care about whether rebased changes are marked as
rebased there or not.<br>
<br>
However, if you use evolve, it will mark the changesets as evolved,
no matter if they are on a custom named branch or just bookmarked?<br>
<br>
/Mads<br>
<br>
</body>
</html>