On Friday 08 June 2007, Junio C Hamano wrote:
> Johan Herland <johan@xxxxxxxxxxx> writes:
>
> > Thanks to Johannes Schindelin <Johannes.Schindelin@xxxxxx> for
> > discovering this.
> >
> > Also add a testcase for this condition.
> >
> > Signed-off-by: Johan Herland <johan@xxxxxxxxxxx>
>
> While this certainly is an improvement, I suspect that your
> parse_tag() does a little too much. In a format such as "tag"
> object that does header + blank + body, it is customary to allow
> header fields that your version does not understand (assuming
> that such extention will go after the known fields is fine).
>
> Which means that you should not be even saying "Ok, I've checked all
> headers I know about---there should be a double LF to terminate it",
> as you do not know if headers have ended.
Ok, I'm currently working on a patch series for Dscho and others where I
split up the big patch ('[PATCH 1/6] Refactor git tag objects; make "tag"
header optional; introduce new optional "keywords" header') into babysteps.
I can:
1. Provide a new patch series to totally replace the previous 6-part patch
series (plus bugfixes). The new patch series will make smaller steps and
end up (hopefully) in a better place, with less overzealous
checking/parsing, and more "traditional" whitespacing.
OR
2. Provide the babystep-series ending up exactly where we are today (i.e.
after the patch series, plus bug fixes). Then, provide patches on top of
the existing series to get it into shape, both scope-wise (i.e. not trying
to do too much) and whitespace-wise.
Which do you prefer?
...Johan
--
Johan Herland, <johan@xxxxxxxxxxx>
www.herland.net
-
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
