On Friday 08 June 2007, Junio C Hamano wrote:
quoted text
> Johan Herland <johan@herland.net> writes:
> 
> > Thanks to Johannes Schindelin <Johannes.Schindelin@gmx.de> for
> > discovering this.
> >
> > Also add a testcase for this condition.
> >
> > Signed-off-by: Johan Herland <johan@herland.net>
> 
> 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@herland.net>
www.herland.net
-
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