[Arch-TK]

To be fair. I have never really heard of pushing to master as a CI technique for git. You would push to your own publicly visible branch and some script would automatically attempt to merge into a CI branch unless there's merge conflicts in which case you get notified. Then as you add things you get notified if the whole thing is breaking and get made aware of upcoming issues.

[jaggederest]

Yeah when I set up a repo, I set up two or three builds per PR:

- the code exactly as it is in that branch

- that branch merged into current main

- that branch merged into what is currently running in production (in the case that it's not what is in main e.g. tagged or branched)

This really helps to see whether it's an issue in "your" code, or whether it's a merge issue conflict causing failures.

[eru]

Making those provisionally merge commits (and testing them) is a good idea, if you can spare the computational resources.

See https://bors.tech/ for a similar idea.

What I would object to is changing the 'official' master every few minutes automatically.

[jaggederest]

Yes, I would not advocate for that either. I like having PRs be a more complete thought, ideally, though sometimes you're left with 3 PRs for "one change" if you need e.g. a database change, a migration for the data, and changing the code to use the new column, which is frustrating but doable.

[eru]

I'd like my PRs to tell a very sanitised story of how I could have come up with the change, with the power of foresight.

Basically, first you write your code however you see fit. Then you use git to rewrite history to make the reviewers life easy, and then you give it to the reviewer.

The reviewer doesn't need to know that my original version had a bug that I fixed later. I can make it look like I came up with a bug free version from the start.

[jaggederest]

I used to do that but these days I prefer the whole story be in there so I can reference it later if I run into the same bug in a different place.

In general I find my past efforts to maintain a clean git history were probably not that useful, as long as you're not running e.g. 4 or 5 branches in parallel with crossing history. Branch off, make change, merge back main, PR, is fine.

[eru]

Most of the time most PRs are small and can be squashed into a single commit, and still produce useful history.

Sometimes it makes sense to have multiple commits. The next step up the complexity ladder is:

- one preparatory refactoring commit that does _not_ change behaviour

- one simple commit that changes behaviour

[eru]

If there's no merge conflict (and the tests pass), would the tool also change master to the new merge commit?

Or are all the merge commits just made provisionally to inform you, but don't change master?

[Arch-TK]

>would the tool also change master to the new merge commit

Not in my experience, no.

The goal is just to keep you aware of what problems you're likely to run into if you tried to push for your change to be merged in at the present moment. If these problems are due to work another team is doing the idea is then that you might begin conversations with that other team to discuss how best to sort these things out.

[crdrost]

One of the easiest tools in this regard is just a “test” that blocks merging if the request is n commits behind master—just enforcing a rebase whenever you update a pull request. Combine with forbidding fast forward merges for pull requests (just let the code review tool generate a merge commit) and your `git log --graph` becomes much mor bounded in terms of how bad it can get.

[eru]

Do you see `git log --graph` becoming entangled as a problem in itself, or as a symptom of a problem?

Your suggestion seems to help with the former, but not really the latter, or does it?

You might like https://bors.tech/ however.