git patch management workflow: porting changes from a rebased patch queue branch to a merged feature branch

Question

I'm working on upstreaming some code to qemu, which wants patches sent the the mailing list in small manageable chunks. I therefore have three branches in my git repository:

• master, tracks upstream.
• feature, has all my development history, including code that is not yet ready for upstreaming. This one is regularly merged with master, and published on github.
• upstreaming, the pending queue for patch submissions, which is regularly revised and rebased against master (and as a result, I don't publish this one, although per What's the Git approach to publish a patch queue? perhaps I could do so with a suitable warning).

Each time I submit a version of the patch series to the mailing list, I get code review feedback and address that in the upstreaming branch (using git rebase --interactive and git commit --amend) before generating a new version of the patch series. This works reasonably well.

However, I'd also like to keep the feature branch up to date with these changes. Ideally, I'd like to record a single commit on feature that is equivalent to all the changes in the last respin of the patch series, however I have not found a clean way to do this.

If I merge from upstreaming into feature, then I have a ton of conflicts that I need to manually resolve each time, because the same files with almost (but not entirely) identical content appear to have been created independently; i.e. there is no common ancestor for a 3-way merge, and no merge history, so each subsequent merge of a new revision appears to be re-introducing a slightly different copy of the same file.

I think what I'd like to do is diff the vN and vN+1 of the upstreaming branch, and then apply that as a single patch to the feature branch. But (short of manual diff-and-patch) I haven't found anything in git to handle this.

Answer 1

There is one trick which I use, but it's not ideal. After you rebased upstreaming, you can git merge --strategy-ours .. its older head. Than it is remembered as forward-updated and can be merged.

Downsides are:

1. It looks ugly in history. All commits are mentioned both before and after rebase, sometimes mixed.

2. You should be careful to rebase only forward. For example if you upstreaming on some master's commit A1, and you rebase to later commit from the master A2 which is some grand-grand-child of A1. Then it's OK to merge-ours older upstreaming. But when you rebase it to some other branch B1, or to some earlier commit in master A0, then you must not merge older upstreaming, otherwise it will be considering some history before A1 as merged, but will not in fact have that changes.