On Wed, Jul 30, 2014 at 3:42 AM, Sergei Organov <osv@xxxxxxxxx> wrote: > Nico Williams <nico@xxxxxxxxxxxxxxxx> writes: >> Local merge commits mean that you either didn't rebase to keep all >> your local commits on top of the upstream, or that you have multiple >> upstreams (the example exception I gave). > > I rather have multiple (release) branches on single upstream, say, v2.3 > and v2.4. When something needs to be fixed in 2.3, it's fixed there and > pushed upstream, then, on 2.4, the 2.3 is merged to it, and result is > pushed upstream. When I do this merge, I need to push the merge Hmm, why not cherry-pick the fix? That's how every project I know that ports fixes across release branches does it. > upstream, and this won't work reliably when --rebase=true is acitve > (through pull.merge=rebase). If nothing changes upstream, I can simply > push this, and the merge is correctly preserved. However, if somebody > makes any changes upstream while I perform the merge, I'll need to pull > before pushing, and this immediately flattens-out my merge, that is > absolutely not what is needed here. Or I can simply pull before push, > just in case, and this flattens history even when there are no any > changes upstream! Does this change if you give your merge commits an different commit message? >> Conversely, if you always rebase your local commits on top of the >> upstream then you won't have merge commits to worry about. > > Wrong. I do alwys rebase my local commits on top of upstream, but I > still do have my own merge commits to worry about, as explained above. If you cherry-pick the cross-release-branch commits you'll not have a merge commit to worry about. Nico -- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html