[Added] kallithea pull request #29 from pytest_migration

[Mads Kiilerich]

On 02/15/2016 11:57 AM, Thomas De Schampheleire wrote:
>
> On Feb 14, 2016 11:46 PM, "Mads Kiilerich" <mads at kiilerich.com 
> <mailto: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?
>

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.

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?

/Mads

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20160215/a7f5fda4/attachment.html>