Main repository should only have a master branch

[halcwb]

I would like to keep the main repository as clean as possible. For example, if you want to show some code but are not sure whether this should go in the main branch per pr, I would like to recommend to do this in your own fork and then refer to the branch in your fork, as that is what forks are for?

This is my opinion. So, feel free to push against this. But there should I think be some policy on how to deal with this.

[ploeh]

We can definitely change the workflow so that all of us work off forks instead of directly on the main repository.

We did, however, yesterday discuss changing the pull request strategy to use squash merges (a direction that I find problematic). If we squash commits into a single commit, we lose the detailed history, and as the linked story demonstrates, this could make troubleshooting harder.

As we discussed in yesterday's meeting, even if we squash a pull request into a single commit, we could still use the original branch for troubleshooting. If, however, we exclude pull-request branches to only originate from forks, we lose control with those branches, and thus lose control with the repository history.

Since this is an open-source repository, it's conceivable that someone submits a pull request from a fork, then subsequently, mission accomplished, deletes the fork. I often do that myself.

Using rebase instead of squash does address that problem, but then what's the point? Why not use proper merges, as Git was intended?

To be clear, this is an incarnation of a discussion that I constantly run into. People wish to keep repositories 'clean', and it's not that I don't sympathise with that aspiration. The difference of opinion lies in how one defines 'clean'.

I get the impression that people often associate cleanliness in code with some kind of aesthetics. After all, code bases have no germs or poisons to clean away, so the definition of 'clean' is a metaphor at best.

To me, there's beauty in reality and truth. While I, too, aspire to keep the working state of a code base as simple and accessible as possible, I believe that the source-control history should capture what actually happened, and not be a summary. If several people worked on the code base in parallel, then that's the truth, and I don't consider a 'multi-track' Git history messy.

So, if we were to keep using Git merges for pull requests, this wouldn't be an issue. Once branches are merged, they can be safely deleted.

[halcwb]

@ploeh Thanks! Valid points.

We can definitely change the workflow so that all of us work off forks instead of directly on the main repository.

That I would really like to use as the basic workflow.

We did, however, yesterday discuss changing the pull request strategy to use squash merges (a direction that I find problematic). If we squash commits into a single commit, we lose the detailed history, and as the linked story demonstrates, this could make troubleshooting harder.

As we discussed in yesterday's meeting, even if we squash a pull request into a single commit, we could still use the original branch for troubleshooting. If, however, we exclude pull-request branches to only originate from forks, we lose control with those branches, and thus lose control with the repository history.

Since this is an open-source repository, it's conceivable that someone submits a pull request from a fork, then subsequently, mission accomplished, deletes the fork. I often do that myself.

And their is a legitimate concern you raise and something I didn't realize. @dawedawe: sorry about this but is their a way to avoid the squash commits?

Using rebase instead of squash does address that problem, but then what's the point? Why not use proper merges, as Git was intended?

You convinced me. I agree.

To be clear, this is an incarnation of a discussion that I constantly run into. People wish to keep repositories 'clean', and it's not that I don't sympathise with that aspiration. The difference of opinion lies in how one defines 'clean'.

I get the impression that people often associate cleanliness in code with some kind of aesthetics. After all, code bases have no germs or poisons to clean away, so the definition of 'clean' is a metaphor at best.

To me, there's beauty in reality and truth. While I, too, aspire to keep the working state of a code base as simple and accessible as possible, I believe that the source-control history should capture what actually happened, and not be a summary. If several people worked on the code base in parallel, then that's the truth, and I don't consider a 'multi-track' Git history messy.

With that I completely agree. My main concern is that there is a lot of trial and, thus, error, some of which may even by accident ends up in source code. And, taking a good look in the mirror, that is something that I did too much (in the past), particularly with regard to generating documentation, in hindsight.

The need to use PRs is, hopefully, going to prevent at least my bad habits.

So, if we were to keep using Git merges for pull requests, this wouldn't be an issue. Once branches are merged, they can be safely deleted.

And that's what I precisely have been doing!

[ploeh]

@halcwb Did you intend to tag @7sharp9?

[halcwb]

I think you are confusing me with someone else. I don't work on anything related to this project.

@dawedawe I am terribly sorry, confused you with @7sharp9. 😳 A big OOPS.

[7sharp9]

I was wondering what the connection was, I assumed the tagged person was related to the Shipit repo :-)

We can use rebase merge, which would include the commits one by one, replayed onto the main branch etc. Or just merge commit, making sure we always have the tooling include ignore-merge-branch option. To be honest, because this is an active repo we have to include that anyway due to their being merge PR's already present.

[ploeh]

My vote is on merge commits 😀

[7sharp9]

@halcwb just merged my PR and it does work, there was a little little wrinkle with duplicate prose due to the hand written part from one of my previous commits, but the process seems to work.

I think the only issue we might hit is a chunky changelog depending on how we choose to do features.