Re: [PATCH] gitweb: Fix and simplify "split patch" detection

[Jakub Narebski <jnareb@gmail.com>]

Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > Alternate solution, which we did chose, is to check when git splits
> > patches, and do not check if parsed info from current patch corresponds
> > to current or next raw diff format output line.  Git splits patches
> > only for 'T' (typechange) status filepair, and there always two patches
> > corresponding to one raw diff line.
> 
> Not that I can think of a better way offhand than what you
> already mentioned, but I have to say that I am not entirely
> happy with this implementation.

I'm also bit unhappy with tying git_patchset_body code to the
minute details of git-diff output.

>                                    A really old git showed two 
> patches (one creation and one deletion) for "complete rewrite",
> which was corrected long time ago.  I do not think we will
> change the typechange output in a similar way in the future, but
> relying on that level of detail feels somewhat ugly.

Gitweb requires git with --git-dir at least, so I don't think it
(it meaning "complete rewrite" patch being "split patch") is
a problem here.

> As you are reading from --patch-with-raw, you already know the
> order of patches that will be given to you when you finished
> reading the "raw" part.  The patches will come in the same
> order.  So it might be possible to keep track of patches to what
> path you are expecting and decide if it is part of what you are
> processing at the point you process "diff --git" line.

I'll try to come with the second solution.

I wonder if the post-image name is unique in raw format of diff
output, and can be used alone to check if there are two patches
per one raw output format line...

-- 
Jakub Narebski
Poland