On Tue, Nov 24, 2009 at 04:48:26PM -0500, Avery Pennarun wrote: > On Tue, Nov 24, 2009 at 2:53 PM, Marc Fournier > <marc.fournier@xxxxxxxxxxxxxx> wrote: > > I was not able to reproduce this bug in any of the following cases: > > - if the README file wasn't empty > > - if modules/cognac is renamed to something else > > - if modules/cognac doesn't have the same sub-directories than > > modules/mapserver > > > > This bug happens using git 1.5.5.6 as well as 1.6.5. It seems to happen > > when git-subtree calls "git merge -s subtree". > > Yup. This is basically a bug in "git merge -s subtree": it guesses > which subtree to merge into, rather than actually taking a prefix > parameter. I've been meaning to either submit a patch for this, or > find a way to work around it. I see. What sort of criteria does git-merge use to do this auto-guessing ? I'm hoping to find a way to workaround this problem. I have a couple of subtrees I'm completely unable to update. The best I found is: "git rm -fr ..." followed by "git subtree add ..." again. > This doesn't usually happen once your project is relatively mature > (ie. doesn't have blank or "default" template files in it) since then > the auto-guessing gets more reliable. But there's no good reason to > do the auto-guessing, so it would be best to do this "properly." The thing is I use dozens of different "modules" in my project, all merged into using git-subtree. All these modules have the same structure, and most of them have quite minimal content and won't really evolve more. In my case, evolution will mean adding even more modules. If I understand the thread Nanako Shiraishi pointed us to, a patch implementing a prefix to "git merge -s subtree" is available somewhere but hasn't been added in any official release yet ? Marc -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html