Repository navigation
Optionally disable automatic rebasing of patches #52
Description
Tl;dr:
This only applies to the first patch in each repo. The rest (if there are more) can only be merged.
Repos that have no patch applied are still checked out at HEAD. A next step could be to checkout each repo's master branch at the time the first patch was submitted.
Reason:
Many time there are conflicting patches merged that cause the demo creation to fail. This often happens with old patches, but it can even happen in the meantime while waiting for jenkinsbot to approve the patch. Should the conflicting patch contain renames or refactorings, a lengthy rebase is necessary, that can be up to a few hours for massive patches or chains. Often rebasing proof-of-concept solutions has no benefit, it's just lost time.
Detailed algorithm:
For each repository:
- Instead of checking out the HEAD, check out the commit of the first patch directly.
- Allow the use of merged patches / commit hash to choose the version to check out.
- Then merge the rest of the patches for that repo.
- If no patches are applied for a repo then check out the HEAD.
- Alternatively: check out the commit merged before the first patch's submit time.
Prio: would be awesome.
Activity
edg2s commentedon Apr 24, 2020
We should use
git-review -dunless a "rebase" option is selected.MatmaRex commentedon Apr 25, 2020
I don't think this should be the default. It would be confusing if demoing an older patch would look as if it reverted all of the more recent changes made to the codebase since then. But it could be an option, as an alternative to choosing a branch.
DemianX0 commentedon Apr 25, 2020
Good point and an option would be a solution.
When demoing old patches there are other factors too, thus depending on the content of the patch "reverting" recent changes is what the developer might want.
In any case the patch is expected to work on the original base, but it's behavior is not guaranteed on the latest head, more so than if randomly updating old npm dependencies, therefore I tend to prefer the original as default, but both options have their use-cases.
[-]Checkout the actual revision of a patch, don't merge it on top of HEAD[/-][+]Optionally disable automatic rebasing of patches[/+]