[llvm-dev] How to deal with multiple patches to the same file
Robinson, Paul via llvm-dev
llvm-dev at lists.llvm.org
Wed Aug 12 08:11:58 PDT 2020
> -----Original Message-----
> From: Paul C. Anagnostopoulos <paul at windfall.com>
> Sent: Wednesday, August 12, 2020 10:22 AM
> To: Robinson, Paul <paul.robinson at sony.com>
> Cc: 'llvm-dev at lists.llvm.org' <llvm-dev at lists.llvm.org>
> Subject: RE: [llvm-dev] How to deal with multiple patches to the same file
> I have a patch being reviewed in Phabricator. A couple of suggestions were
> made, so I would like to submit a revised patch. I think this patch will
> take awhile to be accepted, or perhaps never will be.
> Meanwhile, I would like to fix an unrelated bug in one of the same C++
> files. Here is my plan. Could you tell me if this makes sense?
> I will make a branch off master for the bug fix, make the fix, and submit
> a patch to Phabricator. I will mark that patch as needing to come before
> the one already submitted.
If they are unrelated, you should not need to mark one as dependent on
> I will make the fixes to the original patch. I will include the bug fix,
> since the second bug-fix patch will be committed before the original
> patch. I will use --amend to merge the suggested changes into the original
> patch and then submit a revised patch.
> Is that right?
Not really best practice for unrelated fixes, no.
If they are really unrelated, you can develop, post, and push (or get
someone to push for you) those two changes, completely independently,
as if the other patch did not exist. On separate branches, of course.
Whichever one gets into upstream master first, you would then pull
into your local master, and rebase the other patch branch. Poof, the
second branch has both changes.
In effect, ask yourself: How would this work if someone else made the
bugfix? You wouldn't have to incorporate that fix into your first
branch, even if they posted it to Phabricator. If it appears upstream
at some point, then you'd automatically incorporate it into your
first branch the next time you rebased. Just because you are making
two independent changes on independent branches in your local clone
doesn't mean those two changes need to "know" about each other.
Asking questions is all well and good, but it sounds like you could
benefit from a real tutorial on using git. I read a book (Pro Git,
by Scott Chacon), because that's how I learn best, but git-scm.com
has literally the same material online. I'm sure there are plenty
of other tutorials out there. A basic understanding of the project's
SCM system will definitely help your work go more smoothly.
More information about the llvm-dev