Rebase a branch without merge to keep it up to date

[smarkets]

Rebase a branch without merge to keep it up to date

[jcpetruzza]

Rebasing is painful only if there are conflicts to resolve, right? What should be the expected behaviour the moment marge finds the first conflict?

[leguminator]

The goal is to have an automated task to rebase long term branches, as a human developper will forget to do it most of the time. If there is a conflict, Marge sends a message so that the developper solves it.
The "full human" scenario will undoubtly result in a painful final rebase : I have already witnessed such a dramatic situation.
The "marge" scenario will force the developper to solve conflicts regularly so that there is no painful final rebase.

[jcpetruzza]

Ok, I think I get the idea: you'd want something to regularly go through every branch, checkl it out locally, attempt a rebase and if there are conflicts, notify the person responsible. I see how this could be useful.

There are still things that should be fleshed out in the design of this, imo:

• Would you restrict this to PR's only? Long-running branches may not have an associated PR
• If there is no PR, How do you decide the branch against which rebase?
• Similarly, how do you find out the person responsible for the the branch? Latest commit? Author of last commit? Committer of last commit? And how do you let them know? A comment in the last commit?
• How do you opt-in / opt-out of this behaviour per branch? It is not clear that every branch is a long-running branch. Some teams will leave merge branches forever, and attempting to rebase all of these over time can become expensive.

In the spirit of doing one thing and doing it right, I suspect this would be better served by a separate bot, though

[leguminator]

A separate bot (Homer ?) may be the best solution to avoid confusion.

The branches could be eligible through a regex list / blacklist mechanism. The blacklist is intended to easely disqualify unconcerned branches.
In a PR context, the functioning would be similar to Marge's one.

Without a PR :

• the branch against which rebase could be designated by the most recent comment containing some kind of command e.g. "Homer --rebase-against BranchName". That could be canceled either by managing the lists or by another command "Homer --ignore".
• in case of conflicts, you could find the author of the last commit along with his email address but that requires an SMTP server... A comment in the last commit showing a message for the latest rebase status would be an acceptable solution. Possibly a tag could do the trick, e.g. "BranchName__Homer_Did_Not_Rebase_Cause_Conflicts".

[leguminator]

After digging up for a while :

• One could ask a rebase of a branch through a PR with a predefined label e.g. Bot-Rebase => that solves the problem of distinction with merge operations AND designates the branch against which rebase
• Homer (separate bot) could be some kind of Marge clone with a RebaseJob class instead of MergeJob
• A parameter (rebase-periodicity e.g. 2 days) can prevent rebasing repeatedly the same branche before the periodicity is reached from the last rebase

[leguminator]

Finally I have created a derived Bot class that manages Rebase jobs. The launch of the proper job (Rebase) can be handled with the changes proposed in #130