Re: What's cooking in git.git (Mar 2014, #08; Mon, 31)

From: David Kastrup <dak@gnu.org>
Date: Apr 2, 2014, 05:05 UTC
Message-ID: <87ha6cian0.fsf@fencepost.gnu.org>
In-Reply-To: <xmqqppl0yaf9.fsf@gitster.dls.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 19 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> I haven't reverted the merge of that "submodule update" topic yet; I
>> should do that soonish.
>> ...
>
> Sigh...  This is giving me a lot of headache.
>
> As 23d25e48 (submodule: explicit local branch creation in
> module_clone, 2014-01-26) has been in 'master' since fairly early
> during this cycle, a lot of topics that are not planned to be on the
> 'maint' branch has forked from the tip of 'master' and are now
> contaminated by that commit.
>
> I think I have a preparatory patch to correctly revert 00d4ff1a
> (Merge branch 'wt/doc-submodule-name-path-confusion-2', 2014-03-31)
> and 06c27689 (Merge branch 'wk/submodule-on-branch', 2014-02-27),
> and also a part of 384364b (Start preparing for Git 2.0,
> 2014-03-07), but I am not sure what to do with them ;-<))

Why not just revert on master? When merging with the topic branches, the revert should then override the contamination.

It makes some sense then to rewrite the "submodule update" topic branch so that when it gets reintroduced, its commits are not negated by the branch revert on master.

Sounds like a stock case out of the "using Git with topic branches" book, so what am I missing?

-- 
David Kastrup