[Added] kallithea pull request #29 from pytest_migration

[Thomas De Schampheleire]

On Sun, Feb 14, 2016 at 4:14 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
> 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 ;-)

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