Merges as commits when first_parent=False

[Szpadel]

Hello,

I trying to bring gitlab support to copybara for my company, but in the process I discovered issue with git -> git synchronization.

In default configuration merges are squashed to single commit and in branch based workflows this disrupts whole git history, therefore I tried first_parent=False option in git.origin and it copies both sides of merge as it should, but it isn't able to copy merges, as they are treated as usual commits and they usually doesn't contain any changes.

This disrupts closing github PR when branch is merged on gitlab side and it caused also merge conflicts when on other branches after one of them was merged.

I tried to find a way to fix that in cohybara source code, but it looks like isMerge info is lost many calls up in stack trace before it reaches writer.

[mikelalcon]

Hi, Sorry for the late reply. Copybara moves commits as linear history. There is a pending feature we still want to add that is first_parent = False + ITERATIVE. But even in this case you'll get a linear history in the destination. For merging and/or closing PRs we use another strategy, that is `integrates` for external changes and git.github_pr_destination + git.github_destination (with pr_branch_to_update) for internal started changes. Enabling integrates is easy. just add metadata.expose_label("COPYBARA_INTEGRATE_REVIEW") to both the workflow for importing external changes and the one for exporting submitted changes from internal. We could give more specific answer if you tell us what is your Source of Truth. Cheers, Mikel.

…

On Mon, Oct 21, 2019 at 4:08 AM Szpadel ***@***.***> wrote: Hello, I trying to bring gitlab support to copybara for my company, but in the process I discovered issue with git -> git synchronization. In default configuration merges are squashed to single commit and in branch based workflows this disrupts whole git history, therefore I tried first_parent=False option in git.origin and it copies both sides of merge as it should, but it isn't able to copy merges, as they are treated as usual commits and they usually doesn't contain any changes. This disrupts closing github PR when branch is merged on gitlab side and it caused also merge conflicts when on other branches after one of them was merged. I tried to find a way to fix that in cohybara source code, but it looks like isMerge info is lost many calls up in stack trace before it reaches writer. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#99?email_source=notifications&email_token=AAHJWQH4MLYSWVUNDIS3SOLQPVPPJA5CNFSM4JCZWEEKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HTC5W7Q>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHJWQF44YTGSYWPFWLVHKLQPVPPJANCNFSM4JCZWEEA> .