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.
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
