llvm dev - Aug 2020 - How to deal with multiple patches to the same file

At 8/10/2020 03:02 PM, Robinson, Paul wrote:
>> Why did you 'git pull --rebase' when the branch was up-to-date?
Is this
>> just a safety habit?
>
>Yes.  Frequently I put my patches on my local master branch, rather 
>than create a separate patch branch, and always rebasing keeps my 
>commits at the HEAD of the branch.  It's harmless when you have no 
>local commits, so it's a good habit to form.
Do you work on multiple patches at once this way? If so, how do you tease the
files apart when it's time to submit one of the patches?

------------------------------

>> I don't understand the pushing upstream. Since we use Phabricator,
isn't
>> that the job of the person who commits the patch?
>
>Soon enough (if you keep contributing) you'll get commit access and 
>be doing that yourself.  LLVM is a lot more liberal about commit 
>privileges than many open-source projects.
Ah, I was confused. I thought the final commit of a patch was done from the
patch file in Phabricator, not from the submitting person's repository.

> >> Why did you 'git pull --rebase' when the branch was
up-to-date? Is this
> >> just a safety habit?
> >
> >Yes.  Frequently I put my patches on my local master branch, rather
> >than create a separate patch branch, and always rebasing keeps my
> >commits at the HEAD of the branch.  It's harmless when you have no
> >local commits, so it's a good habit to form.
> 
> Do you work on multiple patches at once this way? If so, how do you tease
> the files apart when it's time to submit one of the patches?
I don't intentionally work on multiple patches at once this way. :0)
But for something simple, I'll work directly on my copy of master,
and then `git pull --rebase` is crucial.  Given that --rebase is a
no-op if you have no private commits, it's a worthwhile habit.

I did once find myself working on multiple patches at once this way,
unintentionally.  I created separate branches from a point before my
local commits, cherry-picked my commits to the separate branches, and 
did `git reset --hard` on master to unwind those commits.  Going 
forward from there it was mainly a matter of keeping my build trees
organized, one per branch.
> >> I don't understand the pushing upstream. Since we use
Phabricator,
> isn't
> >> that the job of the person who commits the patch?
> >
> >Soon enough (if you keep contributing) you'll get commit access and
> >be doing that yourself.  LLVM is a lot more liberal about commit
> >privileges than many open-source projects.
> 
> Ah, I was confused. I thought the final commit of a patch was done from
> the patch file in Phabricator, not from the submitting person's
> repository.
If I'm committing someone else's patch for them, I retrieve the patch
file from Phab and apply it to my repo, then commit from there.  If it's
my own patch I just push from my repo.
Phab doesn't have a way to push; I believe Arcanist does, but again it's
working off of your local repo not what has been posted to Phab.
--paulr

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?