Dana How <danahow@gmail.com> wrote:
quoted text
> >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.
...
quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html