Jakub Narebski [off-list ref] 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. 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.
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.
Junio C Hamano wrote:
Jakub Narebski [off-list ref] writes:
quoted
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