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

Re: [PATCH v4 01/10] ref-filter: add option to align atoms to the left

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Jul 26, 2015, 05:58 UTC
Message-ID
<CAPig+cQD3tMmOrYFb=iWEq7CptDgwarZWW3WDGh7QGKVavgWGA@mail.gmail.com>
In-Reply-To
<CAOLa=ZQvMV8C6LV-+B3m74x209Fr1X7W=piaL-Eftu_PdRW64w@mail.gmail.com>
On Sun, Jul 26, 2015 at 12:36 AM, Karthik Nayak <karthik.188@gmail.com> wrote:
Show 10 quoted lines
> On Sun, Jul 26, 2015 at 9:38 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> Also, it is helpful to reviewers if you include an interdiff at the
>> bottom of your cover letter showing the changes from one version to
>> another. You can generate an interdiff with "git diff branchname-v4
>> branchname-v5", for instance.
>
> I've been working on the same branch, and that's why I didn't really
> provide interdiff's, and I kinda worked on the same branch again,
> so I wont be giving an interdiff for the next series either, but I'll keep this
> in mind and follow it from the forthcoming patch series. Thanks

You can still provide an interdiff. It is quite likely that you can find the commit corresponding to v4 in the reflog for that branch (see git-reflog). Failing that, an easy way to recover the state at v4 is to create a new branch (from the parent of your current working branch) and apply the v4 patches which you sent to the mailing list. If Junio queued v4 in his 'pu' branch, then you can also recover from there. Once you've recovered the state of v4 using one of the methods mentioned here (or some other), you can make an interdiff when sending out v5.

Reviewers do appreciate that you provide a URL to the previous version and take the time to explain in your cover letter what changed (and why). Including an interdiff is one more way to ease the review process, and is also appreciated, so it may be worthwhile to put in the effort to recover the state of v4 so that you can include an interdiff with v5. Doing so does require a bit of extra work for you, but that's work you only need to do *once*, whereas if you don't do it, then you place the burden on *each* reviewer for *each* version, which quickly adds up to a lot more work for those reviewing your submissions.

Previous: Karthik NayakNext: Karthik Nayak
Message 8 of 36 in “port tag.c to use ref-filter APIs”
  1. 0/10 port tag.c to use ref-filter APIsKarthik Nayak, Jul 24, 2015
  2. 01/10 ref-filter: add option to align atoms to the leftKarthik Nayak, Jul 24, 2015
  3. Junio C HamanoJul 24, 2015
  4. Junio C HamanoJul 24, 2015
  5. Karthik NayakJul 25, 2015
  6. Eric SunshineJul 26, 2015
  7. Karthik NayakJul 26, 2015
  8. Eric SunshineJul 26, 2015
  9. Karthik NayakJul 26, 2015
  10. Matthieu MoyJul 27, 2015
  11. Duy NguyenJul 27, 2015
  12. Jacob KellerJul 27, 2015
  13. Duy NguyenJul 27, 2015
  14. Duy NguyenJul 28, 2015
  15. 02/10 ref-filter: make the 'color' use ref_formatting_stateKarthik Nayak, Jul 24, 2015
  16. Junio C HamanoJul 24, 2015
  17. Karthik NayakJul 25, 2015
  18. Eric SunshineJul 26, 2015
  19. Eric SunshineJul 26, 2015
  20. Karthik NayakJul 26, 2015
  21. 03/10 ref-filter: add option to filter only tagsKarthik Nayak, Jul 24, 2015
  22. 04/10 ref-filter: support printing N lines from tag annotationKarthik Nayak, Jul 24, 2015
  23. Eric SunshineJul 26, 2015
  24. Karthik NayakJul 26, 2015
  25. 05/10 ref-filter: add support to sort by versionKarthik Nayak, Jul 24, 2015
  26. Junio C HamanoJul 25, 2015
  27. Karthik NayakJul 26, 2015
  28. Junio C HamanoJul 27, 2015
  29. Karthik NayakJul 27, 2015
  30. 06/10 ref-filter: add option to match literal patternKarthik Nayak, Jul 24, 2015
  31. Eric SunshineJul 26, 2015
  32. Karthik NayakJul 26, 2015
  33. 07/10 tag.c: use 'ref-filter' data structuresKarthik Nayak, Jul 24, 2015
  34. 08/10 tag.c: use 'ref-filter' APIsKarthik Nayak, Jul 24, 2015
  35. 09/10 tag.c: implement '--format' optionKarthik Nayak, Jul 24, 2015
  36. 10/10 tag.c: implement '--merged' and '--no-merged' optionsKarthik Nayak, Jul 24, 2015

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.