Carry over SHA from parent to child repository or vice versa

One question that came up when evaluating X-Modules as a possible feature request:

Is it possible to optionally specify that you want to carry over the sha from one repository to the other repository?

To make our use-case clear:

When we make a commit in the parent repository in the X-Module folder, we would like the child repository’s commit to reflect the sha of the parent. Since the sha’s cannot match exactly we were thinking that the commit message could be prepended with the short sha. Something like this:

Parent repository:

Author: Bob

Message: Some Commit Message here

Child repository

Author: Bob

Message: ab1cd2d - Some Commit Message here

Could work bidirectionally as well (in our case we only want unidirectional, but carrying the child’s sha over to the parent seems interesting as well)

Is this a feature that you guys have discussed before? Is there a workaround to achieve something similar currently?

Hi @cpdeethree,

Thank you for the feedback and for the feature request.

Is this a feature that you guys have discussed before? Is there a workaround to achieve something similar currently?

We’ve discussed something similar internally: at the moment the mapping between commits in a parent repository and its modules is stored within the parent repository under refs/gx/metadata ref. The metadata structure is rather straightforward, you can see that by fetching the ref and walking through its contents:

git fetch origin refs/gx/metadata:refs/gx/metadata
git log -p refs/gx/metadata
git cat-file -p refs/gx/metadata:objects/af/0588abd7057128bdefe5df03afa10478827d44
...
[map "44527eb9-9dab-3ca2-a435-350ed44aa81f"]
    object = 1b33ac811d13e911834aa9e8ee64a06e3700af3a
    path = contrib/module
    stage = sync
    type = extract module
...

This record basically means that parent commit af0588abd7057128bdefe5df03afa10478827d44 is mapped to 1b33ac811d13e911834aa9e8ee64a06e3700af3a for module contrib/module.

You can use the metadata ref for extracting the commit mappings and then generating commit notes according to them.

When we were discussing this kind of the mapping between commits in parent repository and its modules, we suggested that we can automatically generate commit notes with the information on existing modules for every commit in a parent repository that has modules. So, this is something we’re planning to implement at some point in future.

Generating this kind of commit notes for commits in a module repository may be more challenging as one repository can be included into multiple parent repositories. So keeping information on the commit mappings in a module repository is something we didn’t think deeply enough.

All I mentioned above corresponds to a general mapping between commits in a parent repository and in its modules. When it comes to module commits being extracted from a parent commit or module commits being inserted into a parent commit, we thought that adding a footer would make a lot of sense, e.g.:

commit 3e75b8a8431b594f6b5946cf4b62722d2f678017
Author: ...
Date: ...

    Some module commit message
    
    Parent commit: e39c442d3f8729c2e7611b80e72ea23a66a6990e
    Module path: contrib/module

or

commit 3e75b8a8431b594f6b5946cf4b62722d2f678017
Author: ...
Date: ...

    Some parent commit message
    
    Module commit: e39c442d3f8729c2e7611b80e72ea23a66a6990e
    Module path: contrib/module

These additional footer lines could be optional, if commit notes would suffice for your team. These lines also can be configurable, e.g. if you’d like to add some module specifics: whether commit was squashed, rebased or merged into a parent commit, etc.

One thing I’m worried about is that commit messages get preserved when one cherry-picks a commit or rebases it, in this case the footer lines may be misleading because the actual commit was not extracted from a parent repository it was rather cherry-picked from a commit that was extracted. Note that commit notes don’t get preserved when an original commit gets cherry-picked or rebased and to me it looks like a better way to keep the information on relationship between parent and module commits.

Please let me know if commit notes would work well for your setup or if you’d still like to keep this kind of information within commit messages. Also, is a commit hash is sufficient information in this case or you’d rather have more information in a commit note and/or commit message, e.g. a module path.

Thanks!