[Added] kallithea pull request #29 from pytest_migration
Mads Kiilerich
mads at kiilerich.com
Mon Feb 15 17:54:59 UTC 2016
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>
More information about the kallithea-general
mailing list