More protections and suggestions about branches

[Edward K. Ream]

I have just added a new protection rule that applies to all branches. This rule specifies the PR's are always required.  However, authors may still push to their own branches, as I have just verified.

Info item #1058 discusses how to create and use branches. The most important point:

    Everything new comes from devel and goes to devel.

The recent chaos arose from two separate serious mistakes:

- A merge was made into a branch that the merging author did not own. This should no longer be possible.

- The merged branch was not based on devel. Basing branches on devel should make it possible to handle separate branches as independently as possible.

Summary

We can all learn from these mistakes:

- After it was too late I realized that I could undo the offending PR. There was an undo button that I had never noticed before.

- Requiring PR's for all branches should prevent unwanted interference in other people's code.

Edward

[Thomas Passin]

Do you mean that every branch that is not devel, and that person A did not create, should never be pushed to or merged by anyone else besides person A?  That's an easy-enough rule to understand.  Up til now, I had thought that if some feature was being worked on, say layout code, that everyone who wanted to contribute could work on it.

[Edward K. Ream]

On Tue, Oct 13, 2020 at 7:07 AM Thomas Passin <tbp1...@gmail.com> wrote:

Do you mean that every branch that is not devel, and that person A did not create, should never be pushed to or merged by anyone else besides person A? 

Exactly. A PR is a pull request, not a license to make changes willy-nilly.

That's an easy-enough rule to understand.  Up til now, I had thought that if some feature was being worked on, say layout code, that everyone who wanted to contribute could work on it.

I'm no expert on git workflow, but I don't see how PR's can possibly be a substitute for cooperation based on close communication.

Edward

[Thomas Passin]

On Tuesday, October 13, 2020 at 9:50:10 AM UTC-4, Edward K. Ream wrote:

I'm no expert on git workflow, but I don't see how PR's can possibly be a substitute for cooperation based on close communication.

I wouldn't disagree, but I've seen on some other projects that a PR sometimes generates a  long and careful discussion of the issue and proposed change.

Here's the conundrum I had with regards to the layout2 branch.  I had to make some changes in VR3 to match changes you made.  In my own clone repo, I created a layout2 branch based off yours, so it was up to date with yours at that point.  I assumed it was also up to date with devel at the time you created your branch.

I figured that you would need to try out my VR3 changes to see if you could find an error with either my or your changes.  But you didn't have my version.  The purpose of the PR was so you could try out my changes.  That couldn't happen in devel because your layout changes weren't there.  I had not made any changes to your splitter code, so I knew that merging my VR3 wouldn't cause any problems there.

I'm sorry now that I didn't start a discussion thread about these things before I did the VR3 merge.

[Edward K. Ream]

On Tue, Oct 13, 2020 at 9:45 AM Thomas Passin <tbp1...@gmail.com> wrote:

On Tuesday, October 13, 2020 at 9:50:10 AM UTC-4, Edward K. Ream wrote:

I'm no expert on git workflow, but I don't see how PR's can possibly be a substitute for cooperation based on close communication.

I wouldn't disagree, but I've seen on some other projects that a PR sometimes generates a  long and careful discussion of the issue and proposed change.

And that's good, naturally.

I'm sorry now that I didn't start a discussion thread about these things before I did the VR3 merge.

Live and learn. It should no longer be possible to have you merge your branch into mine without my say so.

The recent situation was a bit unusual, since we were both trying to change our branches simultaneously. If a similar situation happens in future we will both be a bit more careful.

Edward