Re: Stacked GIT 0.1 (a.k.a. quilt for git)
From: Catalin Marinas <hidden>
Date: 2016-06-15 22:42:00
Daniel Barkalow [off-list ref] wrote:
On Sat, 18 Jun 2005, Catalin Marinas wrote:quoted
Having different series would be a good idea but it might complicate the tool usage. I will thing about it once I'm sure the basic operations work fine.You could future-proof yourself a bit by simply saving the base as .git/refs/bases/master and making the patches be .git/patches/master/. That way, you'd be ready when you start to support multiple series.
You are right. I will do this for the next release (0.2, probably of the end of this week), something like the tree structure below: .git/refs/bases/<head> .git/series/<head>/ .git/series/<head>/applied .git/series/<head>/unapplied .git/series/<head>/current .git/series/<head>/patches/* I don't know whether a git-diff-* command would look into .git/refs/bases (I can do this in stgit but, this was only for convenience). [...]
Note that it gets more complex if mainline takes only your second patch (due to it not requiring your first, and your first not being as acceptable). In this case, it needs to entire mainline as a patch, because merges can't cherrypick, whereas patches can act arbitrarily. But it would be nice to store the information of what happened even with patches that cherrypick, such that we have a better chance for managing things later.
You can cherry-pick the second patch by first commuting it with the previous patches. If they are independent, the commuting via diff3 wouldn't generate any conflict. Even with the current stgit, you can pop all the patches and only push those to be merged upstream. HEAD would only contain the those patches. If you want to implement a full-featured patch treacking, you might end up with something like darcs which doesn't scale to the size of the Linux kernel. On the other hand, you might not agree with the changes to your accepted patch and a conflict is welcomed so that you can choose whether to keep the old version or not.
But I think that you have the right ideas about how patches should be represented, and it would be good to get your representation implemented inside git, because operations more central to git would benefit from having this information.
Do you mean creating a new git type like the blob, tree or commit? I would prefer not to modify git or have my own version of git. StGIT should be a tool running directly on top of an existing installation of git. Instead of having a directory for every patch (with bottom, top etc. files), I could create a git blob to store this information and the series files (applied/unapplied files) would only contain the blob id. This could simplify things if, in a future version, stgit would allow patch cherry-picking. -- Catalin