On Wed, Jul 30, 2014 at 3:42 AM, Sergei Organov <o...@javad.com> wrote:
> Nico Williams <n...@cryptonector.com> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html