Hi all, I hope you are well. I'm working in a company where most of our developers are using linux as a development environment, so the performance of git on linux platforms is important for us. We came across this PR: https://github.com/git/git/pull/1352 that is improving git status performance on linux platforms, we tried it out, and we are happy with the result. I was in contact with the author of this patch, and I addressed the PR comments as well. Please let me know how I can proceed? Shall I create a new fresh PR, and refer to existing one in the descriptions? Best regards, Marzi
Eric SunshineRe: completing an existing patch
On Thu, Dec 14, 2023 at 8:21 AM Marzi Esipreh <marzi.esipreh@uber.com> wrote:
Show 7 quoted lines
> We came across this PR: https://github.com/git/git/pull/1352 that is > improving git status performance on linux platforms, we tried it out, > and we are happy with the result. > I was in contact with the author of this patch, and I addressed the PR > comments as well. > Please let me know how I can proceed? Shall I create a new fresh PR, > and refer to existing one in the descriptions?
The general answer is that you can take over a stalled patch series in order to move it forward by rerolling the series with changes which address reviewer comments from the previous rounds, and send the series to the mailing list with a cover letter explaining the situation and enumerating the changes you made since the previous version. Standard practice is to retain the original authorship of the patches[1] and keep the original author's Signed-off-by:. Add your Signed-off-by: below the author's Signed-of-by: on all patches, not just the patches you changed. After submitting, respond to reviewer comments on the new version, and reroll as necessary to address those comments.
Somebody more familiar with GitHub and/or GitGitGadget will have to answer the more specific part of your question about whether you can push your version to the same PR or if you instead need to open a new PR. If you are able to push to the existing PR, then you also need to update the PR's description since that becomes the cover letter for the series. Or you can just send the patch series directly to the mailing list, skipping GitGitGadget altogether.
[1]: That is, unless you change a patch so substantially that little of the author's original work is present, in which case you make yourself the author and typically credit the original author with an Original-patch-by: or Helped-by:.