Dear diary, on Tue, Nov 01, 2005 at 10:23:55AM CET, I got a letter where Catalin Marinas <catalin.marinas@gmail.com> told me that... > On 01/11/05, Petr Baudis <pasky@suse.cz> wrote: > > and the fact that I cannot version my changes to patches > > - this is one advantage of having quilt stuff tracked by GIT, I think, > > but that feels ugly. > > That's not too far away. Chuck Lever has a patch (and there were some > other discussions in the past) for tracking the history of a patch. > Basically, there would be another commit object, not reachable from > HEAD but only via an StGIT command, which would chain all the versions > of a patch. You would be able to view them with gitk for example. Perhaps you could emulate the topical branches - one patch == one head. E.g. for patch foo-bar on branch 'master', you would create head master/foo-bar, etc. > My main issue was whether we should store every state resulted from a > refresh or use a separate command (somebody suggested 'freeze') to > mark the states that should be preserved in the history. Chuck's patch > implements the first. The drawback is that a future 'stg prune' > command would not be able to remove the history and some states of the > patch might not be useful (there are times when I do a refresh only to > pop the patch and modify a different one, without any logical meaning > for the state of the patch). I'd prefer the snapshotting being done in refresh anyway. Perhaps you would be asked for log message when you refresh by default, but when you refresh -n or something, only a temporary commit would be created and next refresh would mutate it instead of creating another commit. Anyway, "freeze" is confusing. Perhaps "snapshot" if anything... -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't. - 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 Tue Nov 01 21:10:42 2005
This archive was generated by hypermail 2.1.8 : 2005-11-01 21:10:46 EST