git-backport-diff: Kill git-log after a match has been found

[XanClic]

Hi Jeff,

Thomas has tried running git-backport-diff on a rather large patch series (several hundred patches) and reported it behaved like a fork bomb after my previous patch.

It looks like in contrary to what I thought, the git-log process is actually not terminated when the while loop stops consuming its output, and so when you have a large patch series (and a large git history), you get many lingering git-log processes that all cause heavy I/O.

I think this patch should fix the problem. (Sorry! :/)

Max

[huth]

I've searched a little bit and came accross this discussion:
https://stackoverflow.com/questions/81520/how-to-suppress-terminated-message-after-killing-in-bash#answer-5722874
And indeed, if I add a " wait %$job_id 2>/dev/null || true " after the kill line, the messages are gone for me, too. So please either add the "wait" line or the "-PIPE" here.

[XanClic]

Ah, good, thanks. I had a wait in a previous version but decided to drop it because I didn’t see the need for it. So I’ll add a wait there (should even work without the %$job_id).

Max

[XanClic]

I’ve force-pushed an updated commit (with a simple “wait &>/dev/null” added). Sorry, I don’t know how this is usually done on github. (I suppose I should have pushed the original patch not to master but to a sub-branch and then created a different pull request for a new branch now?)

So here’s the backport-diff (:wink:):

Key:
[----] : patches are identical
[####] : number of functional differences between upstream/downstream patch
[down] : patch is downstream-only
The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively

001/1:[0001] [FC] 'git-backport-diff: Kill git-log after match found'

And this is the relevant diff between the patches:

@@ -52,6 +52,7 @@
 +
 +        # Ignore errors
 +        kill %$job_id &>/dev/null || true
++        wait &> /dev/null
 +        rm -f "$git_fifo"
  
          if [[ -n "$uphash" ]]