David Kastrup <d...@gnu.org> writes: > Junio C Hamano <gits...@pobox.com> writes: > >> Junio C Hamano <gits...@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. -- 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
