On Thu, Nov 13, 2014 at 09:50:24AM +0100, Johannes Sixt wrote: > >That looks more like it is failing the actual test (i.e., the creation > >of branch "one" when there is cruft in the reflog). My guess is that > >calling open() on a directory is giving us EACCES instead of EISDIR. Can > >you verify that? > > > >If that is the case, then this isn't a new breakage, I think, but just > >code we weren't previously exercising. It would be interesting to know > >whether: > > > > git config core.logallrefupdates true > > git branch one/two > > git branch -d one/two > > git branch one > > > >works (even without my patch). If so, then there's probably something > >else going on. > > Don't know what you mean with "my patch" (the one I was responding to > touches only t1410). The patch you are responding to is a fix-up for 9233887, which tweaked the code and added those tests in the first place (I doubt it would work for you, though, as it has a problem on case-insensitive filesystems). > But the sequence works as expected with a version built > in September: Hmph. So that would mean my theory is not right. Or maybe I am not accounting for something else in my analysis. I guess it is odd that the test right before the failing one passes (it is basically that same sequence, with reflogs turned on for both operations), which implies that we are properly getting EISDIR. The only difference in the failing test is that reflogs are turned off for the "git branch one" operation. But I cannot see why that would be broken if the other one passes. I wish it were easy for me to ssh into a Windows VM and run gdb. ;) -Peff -- 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