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

[Junio C Hamano <gitster@pobox.com>]

David Kastrup <dak@gnu.org> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> 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.

That was actually not the cumbersome part.  I wanted to be very sure
that the revert was correctly done, and one way I know to get an
independent verification is to rebuild the master branch starting
all the way back from the point before the problematic topic was
merged to it.  Some of the topics merged to 'master' after that
point, however, were forked after that original problematic merge
was made, so they needed to be rebuilt before I could do so.

It is worth noting that this verification can also be done in a
different way.  You can start at 06c27689^1, and "cherry-pick -m1"
(or "cherry-pick" for non-merge commits that update the release
notes) the commits in "git rev-list --reverse --first-parent
06c27689..master" on top of it.  That should result in the same tree
object as a correct revert on top of 'master' would have.

Because "cherry-pick -m1" loses the other parents, the resulting
history does not reflect the reality, but I am not doing this in
order to replace the history of the 'master' with the result but
only to make sure that the final tree matches what would have
happened if the topic were not merged to 'master', so it is
sufficient for the purpose of this exercise.

Hope it clarifies.