git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 0/2] avoid pipes with Git on LHS

From
Shaoxuan Yuan <shaoxuan.yuan02@gmail.com>
Date
Feb 23, 2022, 13:19 UTC
Message-ID
<CAJyCBOTiWxAgkZPB6M5jPw=t=32zrnNH5tfnOc9Kdj9mKayrSA@mail.gmail.com>
In-Reply-To
<CAC316V57tHux-+MWMJuP5wNtwYrc2AinZj+ffnoyy-aWQWDukg@mail.gmail.com>
On Wed, Feb 23, 2022 at 8:42 PM Shubham Mishra <shivam828787@gmail.com> wrote:
>
> Hi,
Hi,
Show 5 quoted lines
> 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.

-- 
Thanks & Regards,
Shaoxuan
Previous: Shubham MishraNext: Taylor Blau
Message 24 of 31 in “microproject: avoid using pipes in test”
  1. 0/2 microproject: avoid using pipes in testShubham Mishra, Feb 22, 2022
  2. 1/2 t0001: remove pipesShubham Mishra, Feb 22, 2022
  3. Derrick StoleeFeb 22, 2022
  4. Shubham MishraFeb 22, 2022
  5. Christian CouderFeb 22, 2022
  6. Junio C HamanoFeb 23, 2022
  7. Christian CouderFeb 24, 2022
  8. 2/2 t0003: remove pipesShubham Mishra, Feb 22, 2022
  9. Derrick StoleeFeb 22, 2022
  10. Ævar Arnfjörð BjarmasonFeb 22, 2022
  11. Shubham MishraFeb 22, 2022
  12. Taylor BlauFeb 22, 2022
  13. 0/2 avoid pipes with Git on LHSShubham Mishra, Feb 23, 2022
  14. 1/2 t0001: avoid pipes with Git on LHSShubham Mishra, Feb 23, 2022
  15. Taylor BlauFeb 23, 2022
  16. Shubham MishraFeb 23, 2022
  17. Taylor BlauFeb 23, 2022
  18. Junio C HamanoFeb 23, 2022
  19. Shubham MishraFeb 24, 2022
  20. 2/2 t0003: avoid pipes with Git on LHSShubham Mishra, Feb 23, 2022
  21. Taylor BlauFeb 23, 2022
  22. Shubham MishraFeb 23, 2022
  23. Shubham MishraFeb 23, 2022
  24. Shaoxuan YuanFeb 23, 2022
  25. Taylor BlauFeb 23, 2022
  26. Shubham MishraFeb 23, 2022
  27. Christian CouderFeb 24, 2022
  28. Shubham MishraFeb 24, 2022
  29. Christian CouderFeb 24, 2022
  30. Shubham MishraFeb 24, 2022
  31. Christian CouderFeb 24, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.