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

Re: [PATCH 2/2] Add Author and Documentation sections to git-for-each-ref.txt

From
Jeff King <peff@peff.net>
Date
Mar 17, 2011, 06:59 UTC
Message-ID
<20110317065955.GE11931@sigill.intra.peff.net>
In-Reply-To
<7vd3lviie7.fsf@alter.siamese.dyndns.org>
On Sat, Mar 12, 2011 at 11:33:52PM -0800, Junio C Hamano wrote:
Show 10 quoted lines
> > Git-cherry sort of does this, but patch-ids miss a lot of cases: patches
> > tweaked in transit, patches applied on a different commit, or even
> > patches taken partially or split up. So I rebase frequently, and as
> > patches get picked up in master, the branches dwindle to empty.
> > Suggestions welcome if anybody else has figured out something clever.
> 
> A solution to string different iterations of the same patch together,
> perhaps using notes as the storage media, that makes it easier to view the
> changes between different iterations?  I think Shawn does something like
> that in Gerrit code review.

I don't necessarily care about different iterations of the patch on my end. Usually when I discard an old version I don't go back to it, and in the rare case that I do, it is simple enough to pull it from the reflog or from the mailing list.

What I mean is lining up what I have locally (and what I send) with what ends up in your repository. Which can have arbitrary changes from the original. I don't think there is a general solution. In theory you could take a single patch of mine, split it into two, then mark up each half. I know you have the sense not to do this, but there are simpler cases that still cause problems.

For example, in my recent trace-sifter series, you took some squashes from other people on the early bits, and those impacted the text of later bits. So there was no way for patch-id to link up the patches.

Rebasing at least faces me with the conflicts over the rewrite, and I can manually check each conflict and say "OK, it looks like he took my patch, but this part had to be rewritten". And then I can either accept your rewrite (by resolving in favor of you), or I can rework my patch to do what I think should be done on top of yours, and then submit my new one on top.

I could also use Jay's suggested "loose patch id", and link things up by commit author and message. Unless you do something drastic like splitting a patch in two (or merging two patches into one), then I can create the correlation. But it makes me a little nervous, because the content of your version may not be the same as mine. And probably I should be reviewing it before throwing away my version in favor of yours.

-Peff
Previous: Michael J GruberNext: Junio C Hamano
Message 23 of 24 in “A couple of tweaks in git-for-each-ref.txt”
  1. 0/2 A couple of tweaks in git-for-each-ref.txtAlexei Sholik, Mar 8, 2011
  2. 1/2 Documentation: remove redundant colons in git-for-each-ref.txtAlexei Sholik, Mar 8, 2011
  3. Michael J GruberMar 9, 2011
  4. 2/2 Add Author and Documentation sections to git-for-each-ref.txtAlexei Sholik, Mar 8, 2011
  5. Michael J GruberMar 9, 2011
  6. Alexei SholikMar 9, 2011
  7. Will PalmerMar 17, 2011
  8. Jeff KingMar 17, 2011
  9. Alexei SholikMar 17, 2011
  10. Jeff KingMar 17, 2011
  11. Alexei SholikMar 17, 2011
  12. Junio C HamanoMar 9, 2011
  13. Jeff KingMar 10, 2011
  14. Junio C HamanoMar 10, 2011
  15. Jeff KingMar 11, 2011
  16. Junio C HamanoMar 11, 2011
  17. Alexei SholikMar 12, 2011
  18. Jeff KingMar 13, 2011
  19. Junio C HamanoMar 13, 2011
  20. Jeff KingMar 13, 2011
  21. Junio C HamanoMar 13, 2011
  22. Michael J GruberMar 13, 2011
  23. Jeff KingMar 17, 2011
  24. Junio C HamanoMar 9, 2011

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.