llvm dev - Aug 2020 - 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.

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?

> -----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
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

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