On Sat, Mar 12, 2011 at 11:33:52PM -0800, Junio C Hamano wrote: > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html