| Message ID | 20220223115347.3083-1-shivam828787@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | avoid pipes with Git on LHS | expand |
Hi, I am using mails for code review for the first time, I have some doubts, Can someone please clarify them? - 1. It looks like the cover letter (Including "Range-diff" section) is only for context sharing with reviewers, nothing from it gets merged to the "seek" or any other branch. 2. I wanted to know how the merging process takes place. Once the patch is accepted, do we merge all previous versions of it one after another or every patch is independent so we have to just merge the last accepted patch? 3. How does a particular patch set is linked to its previous version? I added the flag "--in-reply-to" while sending this mail but I can't find any linking here on the mail. Not sure If I am missing something here.
On Wed, Feb 23, 2022 at 8:42 PM Shubham Mishra <shivam828787@gmail.com> wrote: > > Hi, Hi, > I am using mails for code review for the first time, I have some > doubts, Can someone please clarify them? - > 1. It looks like the cover letter (Including "Range-diff" section) is > only for context sharing with reviewers, nothing from it gets merged > to the "seek" or any other branch. The cover letter stands for an introduction/summary to your patches. You can also put helpful context in it for better understanding. According to my knowledge, it will not be in the commit messages. > 2. I wanted to know how the merging process takes place. Once the > patch is accepted, do we merge all previous versions of it one after > another or every patch is independent so we have to just merge the > last accepted patch? Not so sure about this question. My two cents: generally the most agreed-upon patch will be merged, but the exact merging process could vary based on the circumstances. Probably Junio can have a better answer to this. > 3. How does a particular patch set is linked to its previous version? "--in-reply-to" will do. > I added the flag "--in-reply-to" while sending this mail but I can't > find any linking here on the mail. Not sure If I am missing something > here. Just by looking at the current thread, I think you are doing it right. Adding "--in-reply-to" to the Message-ID of your previous patch can give you a threaded view of the patch history on the public-inbox. For instance, by always "--in-reply-to" the first patch version ("v1"), you can line up your patches as they are threaded on the same level. You also can choose to always reply to the previous patch's cover letter (just an example), so that your patch history cascades. I think you always go the way that best illustrates the history and helps reviewers. I'm also new to the community, that's the best I can answer. Inaccuracies may be found above.
On Wed, Feb 23, 2022 at 09:19:23PM +0800, Shaoxuan Yuan wrote: > On Wed, Feb 23, 2022 at 8:42 PM Shubham Mishra <shivam828787@gmail.com> wrote: > > > > Hi, > > Hi, > > > I am using mails for code review for the first time, I have some > > doubts, Can someone please clarify them? - > > 1. It looks like the cover letter (Including "Range-diff" section) is > > only for context sharing with reviewers, nothing from it gets merged > > to the "seek" or any other branch. > > The cover letter stands for an introduction/summary to your patches. > You can also put helpful context in it for better understanding. According > to my knowledge, it will not be in the commit messages. Right; the cover letter (along with any notes below the '---' in your patches do not make it into the commit history). The range-diff you posted is empty and doesn't look quite right to me... when I applied both versions of your patches locally and generated a range-diff myself, I got the expected (non-empty) results. I'm not sure exactly how you're generating the range-diff locally, but you may want to make sure that you're picking the previous version correctly (and not doing something like `git range-diff master HEAD HEAD`, which is what I suspect may have happened). > > 2. I wanted to know how the merging process takes place. Once the > > patch is accepted, do we merge all previous versions of it one after > > another or every patch is independent so we have to just merge the > > last accepted patch? > > Not so sure about this question. My two cents: generally the most agreed-upon > patch will be merged, but the exact merging process could vary based > on the circumstances. Probably Junio can have a better answer to this. Emily Shaffer did some great work a couple of years ago on a "My First Contribution" tutorial, which you can find in Documentation/MyFirstContribution.txt. The section "My Patch Got Emailed - Now What?" provides a good overview of the review and queuing process. Thanks, Taylor
Thanks to both of you, your responded were really insightful. > The range-diff you posted is empty and doesn't look quite right to me... > when I applied both versions of your patches locally and generated a > range-diff myself, I got the expected (non-empty) results. This is a new command for me, I am looking on the web about range-diff to know what I did wrong :) Thanks, Shubham