Nico Williams <nico@xxxxxxxxxxxxxxxx> writes: > 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. Cherry-pick? Why bother? What problem do we solve, having no merges whatsoever? Why? GIT is so good at merges! My impression is that people mostly rather do topic branches, and merge them wherever they need the fixes, no? >> 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? Different from what? I'm almost sure commit message has nothing to do with it. Please refer to this explanation to see for yourself how git behaves when rebasing: http://www.mail-archive.com/git%40vger.kernel.org/msg55605.html > >>> 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. I fail to see why do you consider merge commits to be an evil, really. I didn't think about cherry-picking carefully, but I don't feel cherry-picking is the best tool for the job here. I suspect random cherry-picking would create a mess, sooner or later. -- Sergey. -- 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