On Sun, Feb 14, 2016 at 4:14 PM, Mads Kiilerich <[email protected]> wrote: > On 02/12/2016 11:06 PM, Andrew Shadura wrote: >> >> On 12 February 2016 at 23:59, Thomas De Schampheleire (no-reply) >> <[email protected]> wrote: >>> >>> Same as v1, but with better commit msgs and an extra patch to fix test >>> interdependency. Also, as requested, changes made on a branch. >> >> Acttually, I disagree with Mads' opinion on branches: >> 1) The end result will be on the branch default (or stable, depending >> on what sort of changes it is) anyway > > > Yes. But until the PR is merged, they will be something that _not_ is on > default ... and some of it will never be. > > I guess it pretty much boils down to how used you are to git branches vs > named branches. > >> 2) If the PR doesn't require any more work, it can be simply pulled if >> it's on the right branch > > > There will generally be multiple PRs incoming in parallel and there will > generally be a "need" for rebasing anyway. That is no extra work. > > Right now I verify all changes from all contributors by deploying them on > our production system before pushing upstream. I keep everything so safe > that I dare do that. In that process, I am rebasing everything anyway. > > If we want to keep using that offer, I will never do a simple pull anyway. > >> 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). With a bookmark this would be different. Allow me to try that approach too for the next set of changes, then I'll compare the approaches and report back :-) > >> In any case, I suggest not just closing old PR versions, but also >> obsoleting them (for exampl, using rebase or histedit), so that the >> old changesets don't hang around needlessly. > > > That could perhaps be something that could be done automatically when > "updating" a PR? > > /Mads _______________________________________________ kallithea-general mailing list [email protected] http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
