Dana How <danahow@xxxxxxxxx> wrote: > >I think this particular change needs to either preceed the prior > >commit, or be part of it. If someone tries to bisect this patch > >series with a large enough project that multiple packfiles are being > >produced then you run into some ugly problems in this repack script. ... > Sorry, you lost me. git is being bisected, or a project managed by git? > My intent was that the pack splitting wouldn't be available until > _all_ patches were applied (active). Bisecting git _within_ this patchset > would still be useful -- it could be used to isolate where some of > this new code broke some pre-existing feature. git bisecting itself, to search for bugs in itself... In that case a bisect could stop at any random point in the middle of this series, even if this series isn't the one that is at fault for the given breakage. In such a case we try to hope that git.git is always in a working state at any given commit. On second thought looking at your series I see how you were able to assure that here. You didn't activate the option until the shell script could also handle more than one name, so since the option is not available in any prior commit there's no way to turn on the multiple-name-output that git-repack.sh would have broken on. But lets just say the 7/8 patch actually did break git, and we are bisecting to look for it. We wouldn't actually see the breakage activate until 8/8, which is misleading, as the broken code is actually in 7/8. But if you are looking at 8/8 as broken and see the lines broken, you can easily run git-blame to really figure out what changed, and why. So its not really a big deal that the series is organized like this. I blew it out of proportion. :-) -- Shawn. - 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