On Tue, Nov 01, 2005 at 05:18:49PM +0000, Catalin Marinas wrote: > On 01/11/05, Chris Mason <mason@suse.com> wrote: > > That's true, but you can use a 'git tag' command to mark the whole > stack as something useful and this would include the state of all the > patches on the stack. This would be a whole stack history, not > individual patch history. Maybe we should implement this as well (or > maybe only this). > > Anyway, I wasn't sure that's the right implementation and that's why I > didn't include Chuck's patch yet. I would suggest just putting the .git/patches directory under revision control. If you make it a head in git and then add helper functions so that common operations are easy to do, you won't be reimplementing the whole SCM wheel just for patches. For example: stg commit-patch-tree: does git-write-tree and git-commit-tree on .git/patches stg checkout-patches sha1: updates .git/patches to a given patch commit stg diff-patches [-p] [-f]: by default this does the same as git-diff-tree -p, read the patch commit objects and diff the patch files -f, read the patch commit objects and diff the source files The command names could be better, but the idea is to make commits that change the state of your patch tree. Later on, you'll be able to find the one commit where you added 6 patches, or the one commit where you adapted the whole tree to some new feature. More importantly, you can reuse gitk and all of the other history functionality in the SCM. -chris - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Wed Nov 02 05:14:30 2005
This archive was generated by hypermail 2.1.8 : 2005-11-02 05:14:34 EST