On Tue, Aug 21, 2018 at 12:43:49PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > When we serve a fetch, we pass the "wants" and "haves" from > > ... > > This lets us limit the change primarily to the oe_delta() > > and oe_set_delta_ext() functions. And as a bonus, most of > > the rest of the code does not consider these dummy entries > > at all, saving both runtime CPU and code complexity. > > > > Signed-off-by: Jeff King <peff@xxxxxxxx> > > > > Signed-off-by: Jeff King <peff@xxxxxxxx> > > --- > > Sorry for commenting on something completely off-topic, but when > applied with "git am -s", I get a resulting commit with 3 S-o-b (the > above two, plus the one added by "-s"), with a blank line in between > them. I can understand the first blank line (the one between your > two S-o-b), as the first S-o-b does not even appear to be part of > the trailer block, but cannot explain why I get an extra one before > the one added by "-s". Puzzled... Hmm. This case is most curious. I don't normally have a S-o-b in my commits themselves, but in this case I had done quite a bit of editing in my MUA while sending out the patches, so I picked up the result for my local branch with a "git reset --hard origin && git am ~/what-i-sent". Then for sending v2, I did my usual "format-patch -s". For the first 5 patches, it worked fine, but for this one, it created the funny duplicate, which should have been suppressed. So something about this commit message seems to confuse our trailer-parsing code. And indeed, running: git show -s --format='%(trailers)' shows nothing, which explains the other behavior (we don't think there's a trailer block, so we make a new one). I wonder if it gets confused by the big block of perf results (which all start with "^%[0-9.]:"). -Peff
