On Feb 14, 2016 11:46 PM, "Mads Kiilerich" <[email protected]> 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
_______________________________________________ kallithea-general mailing list [email protected] http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
