Jeff King <peff@xxxxxxxx> writes: > [1] I have mixed feelings about the aggressive rebasing. Our 'master' is > pretty stable, so I don't feel the need to build off the last tagged > release. In a very busy project (like the kernel), it would make sense to build off of the last tagged release when your interaction with the upstream is primarily based on patch exchange. But I think that is primarily because the maintainer and the reviewer do not have to ask "where does this apply to? It does not apply to my tree; please resend" if you did so. Because our "master" does not move so fast, sending a complete patch series based on any commit that was once at the tip of "master" works similarly well, especially because "am -3" works well in such an environment if "master" is never rewound. But if your interaction with the upstream is merge based, I think it is preferrable to base your fork point as if you are the person at the upstream. There is no "where does this apply to" at that point, and you have a larger responsibility and say in the final shape of the history. Namely (I know you know this, and I am writing this primarily for other people on the list): - an fix would be appropriate to be made on top of the oldest maintenance track that contains the commit that introduced a bug (or even directly on the buggy commit itself), as long as merging up from maint-O to maint-N (O < N) to master is simple enough; - For enhancement patches that do not deserve to be backported to maintenance branches, "master" is a good place to start. For this topic, you could have said that this is a documentation bug fix and started the topic at the tip of maint, given that this is a fairly low-risk change, and that we haven't added any new file between maint and master that requires an evil merge to fix up. Or you can say that this is very minor and not worth fixing in maintenance track to fork from master. > 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. When I rebase, I tend to keep the base stable (in other words, I don't use "rebase" in order to change the base, but to rewrite individual patches), too keep comparison between iterations simpler, but I haven't found a satisfactory solution for such a comparison for changes near the tip of longer series. -- 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