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 ;-)
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
