[llvm-dev] How to deal with multiple patches to the same file

[Paul C. Anagnostopoulos via llvm-dev]

I didn't think my plan sounded right. I understand what you are saying, but once the first patch is accepted, I have to remember to rebase the other branch and resubmit the patch. No? Otherwise the line numbers in the second patch will no longer match the source file. Ah, I guess if I were committing my own patch, rebasing and recreating the patch file would be part of my usual flow. But what about when someone else commits it for me?

You are certainly correct about reading a book, which is why yesterday I started REreading Brent Laster's "Professional Git." And I appreciate you putting up with all my questions. This will be the third time I've read a Git book; perhaps this is the time it will "take."

At 8/12/2020 11:11 AM, Robinson, Paul wrote:

>> 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
>the other.
>
>> 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.
>--paulr