Proposal: patches and diffs support

[yajo]

This is one idea that came to my mind. The quick summary is to be able to do things like this:

./odoo:
    defaults:
        depth: 100 # Shallow clone, faster but less git merge ability
    remotes:
        ocb: https://github.com/OCA/OCB.git
        odoo: https://github.com/odoo/odoo.git
        openupgrade: https://github.com/OCA/OpenUpgrade.git
    target: ocb 12.0 # I'm cloning version 12.0
    merges:
        - ocb 12.0
        - odoo 12.0
    # Here comes the meat:
    patches:
        - https://github.com/odoo/odoo/pull/37142.patch
    diffs:
        - https://github.com/odoo/odoo/pull/37187.diff # This is a PR for branch 11.0, merged on branch 12.0!

The effect of these new configuration items would be the same as executing:

# To merge patches:
curl -sSL https://github.com/odoo/odoo/pull/37142.patch | git am -3 --keep-non-patch -

# To merge diffs:
curl -sSL https://github.com/odoo/odoo/pull/37187.diff | patch -fp1
git add .
git commit -m "Merging diff https://github.com/odoo/odoo/pull/37187.diff"

The point of adding patches is maybe not so much important because almost the same you can get with just plain git, and it shares the same limitations. For example, the depth: 100 key will make the git am command fail if the cloned shallow repository doesn't have the parent commit.¹

However, adding diffs would enable us to merge patches that don't share parent commits. In this concrete case, I'm applying a patch for branch 11.0 on top of the 12.0 branch, without sharing a parent commit in git history. This enables both a fast repo download and a flexible merging system that doesn't depend on the present branch but only on the present code.

---

¹ For this concrete case, if you open https://github.com/odoo/odoo/pull/37142.patch you'll see the required parent commit is 23c3fb1abce11d3d5b71cf31a3925198b53d1ea9.

@Tecnativa TT19524

[sbidoul]

This proposal makes sense to me. I would even say that diff/patch it is safer than merge, because I have seen people doing a merge of a PR branched off of a more recent version of their base branch and thinking git-aggregate would apply the diff while it was actually getting more commit from the main branch too.

So 👍

[blaggacao]

I've done similar thing for Dockery Odoo, it should also allow to use a patch file locally (out of a directory).
I'm probably porting the branch management of odooup odooup repo to make use of git aggregator, so I would be able to take this one, if you don't mind...

[yajo]

Please do, I still didn't have time to do it.

[sbidoul]

For those interested to experiment with this approach today, shell_command_after can be used to run commands similar to what @yajo explained (i.e. curl | git am).

[blaggacao]

For my own clarity, I start with typing the problem:

@dataclass
class TargetDirectory(DataClassYAMLMixin):
    origin: str
    upstreams: List[Upstream] = field(default_factory=list)
    target: str
    postprocess: List[str]

@dataclass
class Upstream(DataClassYAMLMixin):
    name: str = "upstream"
    url: str
    merges: List[str] = field(default_factory=list)

How do we ensure the proposed patches don't conflict with merges?

[blaggacao]

I would even say that diff/patch it is safer than merge, because I have seen people doing a merge of a PR branched off of a more recent version of their base branch and thinking git-aggregate would apply the diff while it was actually getting more commit from the main branch too.

I think that is true. Could we go so far to state, that the additional history a merge brings us is not even a necesary feature?

This presumes we would need a stronger semantic separating:

• origin
• upstream (preserving history, might be even doing rebases)
• remotes (for patches)

Does this make sense to you? Is there a use case that brakes when history is only preserved for a primary upstream?

see also: #43

[yajo]

How do we ensure the proposed patches don't conflict with merges?

Merge 1st, patch 2nd. Error = exit code 1. It's quite simple, you don't need to ensure anything AFAICS... 🙄

remotes (for patches)

IMHO patches should just be a list of URLs or paths. If it's just a path, it could be absolute or relative to the repos.yaml file.

[blaggacao]

@sbidoul how do you think about patches be safer than merge? I agree, but should that opinion translate into some action? Maybe not on this PR, though. But it might still validly inform the implementation.