Non-semilinear repository history

[64kramsystem]

I've noticed that the repo history is not semi-linear:

*   3511b6f (HEAD -> master, upstream/staging, upstream/master, origin/master, origin/HEAD) Merge #178
|\  
| * 6a5cd6b Move EngineConfig to a Static Global
* |   3f19a44 Merge #175
|\ \  
| * | 05cc6cc Make Web Build Script Exit Early on Failure
| |/  
* |   c8ce82f Merge #174
|\ \  
| |/  
|/|   
| * 99e1373 Implement Enemy FOV
|/  
*   83e6285 Merge #173

I thought that Bors would have generated something like:

*   3511b6f (HEAD -> master, ... which head branch? ...) Merge #178
|\
| * 6a5cd6b Move EngineConfig to a Static Global
|/
*   3f19a44 Merge #175
|\
| * 05cc6cc Make Web Build Script Exit Early on Failure
|/
*   c8ce82f Merge #174
|\
| * 99e1373 Implement Enemy FOV
|/
*   83e6285 Merge #173

am I correct (I've never used Bors)?

If so, any idea why?

[64kramsystem]

Uh, I think this is actually what the intended Bors result is 😢 (see here, with discussion here).

[zicklag]

Yeah, looks like you found it. I suppose the only existing alternative is to use squash merges which produces a 100% linear history, but. like you mentioned earlier has it's disadvantages because entire PRs turn into one commit.

I think our options are:

1. Deal with octopus merges
2. Have bors squash our PRs
3. Try to rebase our PRs on master before having bors merge them

I think 2 probably isn't a great option. GitHub might make it easy to try out option 3 because I think there's an "update this branch" button, that we could just use before running bors merge.

[zicklag]

Or another option:

4. See if there's an alternative merge bot somewhere that does what we want.

I'd think there'd be bors competitors, but I'm not sure about free ones.

[zicklag]

And another option:

5. GitHub has an "automerge" feature you can enable, where it will wait to merge pull requests until their CI passes. If we could tell it to automerge and only ever use rebase that would produce a 100% linear merge history.

[zicklag]

I did an extensive test of the auto-merge feature in GitHub, and the issue is that if we want to ensure that the master branch is always tested before merging, we essentially have to tell GitHub to require that branches are up-to-date before merging, and it won't automatically rebase them, so while we as maintainers end up having to merge all branches in sequence, one after the other manually.

So that's not optimal, especially if we ever end up with more frequent other contributors.

[64kramsystem]

Yeah. Shame!

We were applying a semi-linear capable workflow at my company; we ultimately didn't - I think it's possible but tedious to setup.

I'm not fussy about history outlook - it would have been a nice to have, IMO.

Granular commits are definitely very important for me 😁 Last bisection was while developing the stages PR, which actually helped isolating an issue 😍. Yeah, I'm a big fan of granular commits!! 😂

[zicklag]

I think I may have found a bot that will do what we need:

https://github.com/palantir/bulldozer

I'm still investigating.

[zicklag]

Nevermind, it would almost work, but I don't like the way it updates the PR branches by automatically merging in master. I'd rather it never touch the PR branch like bors does.

[zicklag]

I'll have to test drive this one:

https://github.com/chdsbd/kodiak

It touches the PR branch to update it with master, but only once you tell it to merge, so that's probably fine. I want to test it out first to make sure it feels right, though.