Junio C Hamano wrote: > Jakub Narebski <jnareb@xxxxxxxxx> 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 - 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
