Set up pull and/or rebase automation from upstream (using bots, actions, apps, etc.)

[DeeDeeG]

Continuing the discussion from here: #12

We should work out our approach for merging/rebasing stuff from upstream master into this fork.

---

I think we should have pull bot hard reset our upstream_master to match atom/atom:master (upstream's master) every time upstream pushes to their master.

---

I have my doubts about any automated rebasing being a good idea... But if we want to do that:

Then we can trigger a rebase Action to rebase our master on our upstream_master each time our upstream_master is pushed.

That way our work in our master is rebased on top of upstream master any time they push to their master.

(Pull Bot doesn't know how to rebase our work on top of the remote, it only know how to rebase the remote on top of us.)

We could also try this rebase Action, but we would have to schedule it, or think of an appropriate trigger for it (maybe pushes to upstream_master here? Meaning we would still use Pull Bot to sync upstream_master.)

[DeeDeeG]

Still working on writing my own rebase Action, will update here if there is news on that.

[aminya]

I will rewrite the history of the master, then we can use a clean method after that. I agree with upstream_master. We should probably rebase manually.

[DeeDeeG]

Mind if I rebase (manually) on upstream_master now? I haven't done that yet. Don't want to cause a conflict.

For any force pushes, including pushing our master branch after a manual rebase, I recommend we get in the habit of using:
git push --force-with-lease

https://blog.developer.atlassian.com/force-with-lease/

[aminya]

Yes, you can do it. We have a master_backup branch in case something goes wrong.

When I rebased the upstream, for some reason, I was added as the co-author of other's commits. We should avoid that.

[DeeDeeG]

When I rebased the upstream, for some reason, I was added as the co-author of other's commits. We should avoid that.

GitHub shows the Author and Committer with equal prominence in their GUI. When you rebase someone's commit, you become the committer, but the author info is preserved.

Under the hood this is all correct, it's just weird seeing both names like they have the same role. (This is a User Experience problem on GitHub. Changing comitter is standard Git behavior during a rebase of someone else's commits.)

You can cheat and manually set the committer and commit date to the original one, with env vars like GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL, but as far as I know there is no convenient tooling around this. And it seems reasonable to record who actually re-committed the code during the rebase, since the rebaser might have modified the code during merge conflicts, etc.

(Yes, you can totally fake/fabricate someone else's commit activity, barring that they usually cryptographically sign their commits. But this is like any kind of forgery/lying, it's bad and no-one should do it.)

[aminya]

We should not try to rebase/force-push our master anymore. This breaks all the open pull requests. From now on, I will merge the changes normally. Pull bot alters us about the changes. We should not rely on the inaccurate commit counter of GitHub for comparing our changes to upstream, as it does not say anything useful.

I want to close this if there are not any other thoughts.

[DeeDeeG]

We should not try to rebase/force-push our master anymore. This breaks all the open pull requests. From now on, I will merge the changes normally.

Yeah, that sounds okay.

Thoughts beyond that: This isn't new, but I think for upstreaming changes, posting just the changes relative to upstream master, as committed directly on the tip of upstream master, is the way to go. (But that's sort of out of scope for this issue, so we don't have to discuss it here).

I want to close this

👍