[MRG + 2] add link in the contributing doc for rebasing on master

[TomDLT]

As suggested in #7111 (comment), I added two links in the contributor doc:

• http://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html#rebasing-on-master
• [MRG+1] DOC: Added Nested Cross Validation Example #7111 (comment)

[amueller]

Thanks. Should we also link to the page in general as recommended reading, in addition to the official git docs?

[TomDLT]

Done

[amueller]

lgtm

[NelleV]

I am so against enforcing rebasing… I actually had to help people fix git rebasing problem in the early days of scikit-learn during our first sprint ever and it was not a good feeling.

[NelleV]

The text is fine, btw so +1.

[amueller]

I think we should ask people to rebase only in case of conflicts, in which case it's better then merging master.

[NelleV]

I agree it is better but beginners typically make the mistake of rebasing master onto their branch instead of rebasing their branch onto master ( 😟) and the history is then all screwed up (😢) so you need to reset the HEAD to the instance when it was still correct, which means explaining reflog (😭)…

All of this is fine for people who have used git a fair amount of time, but unfortunately, it is typically beginners that mess up rebases and end up in the case where you have to run a number of obscure commands to fix the issue. I typically never use merge (unless with the --ff-only option), but I also never teach rebase to my students.

[TomDLT]

So how do you suggest to solve conflicts with master branch?

[NelleV]

Merging is less risky.
I am actually curious what would merging master and then "Squash & merge" do. It seems like it could either screw up bad or be the same than rebasing + squash & merge.

[NelleV]

My tests seem to imply screw up very badly. I don't think github` will have a squash and merge button for cases were the master branch has been merged into the working branch.

[jnothman]

I had thought squash and merge should work fine... after all it's just
going to merge in the diff that it shows.

On 1 October 2016 at 08:57, Nelle Varoquaux notifications@github.com
wrote:

My tests seem to imply screw up very badly. I don't think github` will
have a squash and merge button for cases were the master branch has been
merged into the working branch.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#7541 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEz6769qpChFGKk1ME3MvyP418oO8slks5qvZPKgaJpZM4KK9M6
.

[NelleV]

I didn't test through the interface, but doing it manually on my computer so maybe I messed up. It'd be interesting to know.

[amueller]

I would expect there to be a screw-up. You have two ancestors and you want to rebase one of them on top of the other? that's kinda weird.

[amueller]

http://stackoverflow.com/questions/4783599/rebasing-a-git-merge-commit

[NelleV]

Well… Unless someone tests and demonstrates the github interface deals with this properly, let's merge the PR as is and change it later if we discover that squash and merge works fine if master has been merged in the branch of the PR.