[llvm-dev] How to deal with multiple patches to the same file
James Henderson via llvm-dev
llvm-dev at lists.llvm.org
Tue Aug 11 04:33:52 PDT 2020
Just chiming in to mention that there are two ways I know of in Phabricator
to say that two patches are dependent on one another.
1) In the patch description, put "Depends on DXXXXXX" (where XXXXXX is the
patch number the new patch depends on).
2) In the Phabricator UI, there's an "Edit Related Objects" option on the
right of the description, which you can use to enter other revisions that
either rely on the patch, or that the patch relies on.
Note that this doesn't affect the diff at all, so you usually will want a
diff of the commit versus the previous commit in your chain, rather than
against the head of master, when doing that, to avoid things showing up
that were changed earlier in the series.
You can view the patch series/tree by the "Stack" option in the UI, which
appears when a patch either has dependent revisions, or it depends on them.
The text for this option will appear in red with a number if there are any
patches that need to land before that one does, according to the hierarchy
- it's very easy to mix up the order, so it's good to check out the tab to
make sure things look right.
On Mon, 10 Aug 2020 at 15:07, Robinson, Paul via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> > -----Original Message-----
> > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Paul C.
> > Anagnostopoulos via llvm-dev
> > Sent: Monday, August 10, 2020 9:30 AM
> > To: llvm-dev at lists.llvm.org
> > Subject: [llvm-dev] How to deal with multiple patches to the same file
> >
> > I have submitted a patch to Phabricator that includes the TableGen file
> > TGparser.cpp. Now I want to fix a bug in that file. What is the proper
> > procedure so that the two patches don't get screwed up, either in my
> > repository or in the master repository? Please answer as if I'm a
> > git/Phabricator idiot, because, well, I am.
> >
> > I should note that all I did in my repository for the first patch was
> > stage the files and then do a diff --staged. Those files remain staged
> > because I'm not sure what to do with them given that we use Phabricator
> > and not pull requests.
>
> (I'm not completely giving you recipes; if you need more explicit steps
> then let me know and I'll do a full-on example.)
>
> Even though we don't use pull requests, I still tend to commit my patches
> to branches off of master, in my local clone. This allows `git show` to
> generate the diff. As master advances, you update your master branch and
> then on the patch branch, a simple `git rebase master` updates it.
>
> Assuming the patch is approved, on master you can `git merge --ff-only`
> to move the patch to your local master, and then push it from there.
>
> If the bugfix is not near your other changes, and can be made
> independently,
> then you can treat it as a fully independent patch on its own branch.
>
> If the bugfix is near your other changes or is dependent on it, then I'd
> create a second patch branch based on the first patch branch. As before,
> `git show` generates the diff, and in Phabricator there's a way to mark
> the second patch as dependent on the first patch. I haven't done this
> personally so I'm unclear about the exact steps, but I see people doing
> "patch series" all the time.
>
> HTH and again let me know if you need a more explicit example.
> --paulr
>
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200811/66db82c3/attachment.html>
More information about the llvm-dev
mailing list