[Added] kallithea pull request #29 from pytest_migration

[Mads Kiilerich]

On 02/12/2016 11:06 PM, Andrew Shadura wrote:
> On 12 February 2016 at 23:59, Thomas De Schampheleire (no-reply)
> <kallithea-noreply at kallithea-scm.org> 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