On Thu, Nov 11, 2010 at 11:41 AM, Catalin Marinas <catalin.marinas@xxxxxxxxx> wrote: > On 11 November 2010 10:29, Karl Wiberg <kha@xxxxxxxxxxx> wrote: > >> I've thought a bit about this in the past, and the best solution I >> could come up with is of the first kind, and would change the >> representation of applied patches to use just two refs: the branch >> itself, and the stack base ref. I think git rebase wouldn't wreck >> things for that representation. > > git rebase would most likely change the base of the stack so stgit > can no longer track its patches. I was thinking we could use another git branch as stack base---specifically, use origin/master as stack base for master, etc. The stack of applied patches would then be defined as origin/master..master. That way, git rebase really wouldn't do any harm. Of course, if git rebase was used to rebase onto a different branch, then StGit would have to be told about it; but git already stores information of this sort, used by e.g. git pull with no arguments. (No, I haven't researched this part properly. ) > Maybe a better option for stgit is to just remember the branch and > the number of patches (probably including the patch names unless we > always generate them automatically, not that bad but you lose the > possibility of renaming patches). Yes, that's another way to do it. I think I like my proposal better, but as I said, I haven't worked it out in detail, and I'm not about to do so any time soon. > The above would work well if people use git commit on top of an > stgit branch. That goes for my proposal as well. > The patch names maybe be wrongly associated or (if we automatically > generate patch names) we may miss the first patch in the series > because of the number of commits. The latter is not that bad since > we can always use stg uncommit, though a stg rebase could override > the committed patch. Patch names are a problem in all these "minimal metadata for applied patches" ideas. They could possibly be preserved by guessing the best match if the stack is modified outside StGit. -- Karl Wiberg, kha@xxxxxxxxxxx ÂÂ subrabbit.wordpress.com ÂÂ www.treskal.com/kalle -- 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