Hi Junio, On Tue, 12 Jul 2016, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schinde...@gmx.de> writes: > > > This is the second iteration of the long-awaited re-roll of the attempt to > > avoid spawning merge-recursive from the builtin am and use merge_recursive() > > directly instead. > > This is actually the third iteration. It is. > I am trying to tease dependencies apart and apply this on a more > reasonable base than a commit that happened to be at 'pu' on one > day, but this would probably take some time, and I may give up > merging it anywhere for today's integration cycle. We'll see. The two topics that are in 'pu' and conflict with this series are 'jh/clean-smudge-annex' and 'bc/cocci'. It also conflicted with 'va/i18n-even-more', but that one was merged to 'master'. Now, I think it would be okay to wait for 'bc/cocci' to go to 'master' before integrating the 'am-3-merge-recursive-direct' branch, but I would want to avoid waiting for 'jh/clean-smudge-annex'. Do you concur? If so, I will rebase onto 'master' as soon as 'bc/cocci' lands in there. Ciao, Dscho -- 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
