On 01/11/05, Petr Baudis <pasky@suse.cz> wrote: > 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... > > 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. The patches need to be chained so a top patch would also refer to the previously applied patches since they are its base. Anyway, I don't like adding too many files to the refs/heads directory. > > 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. The refresh -n should be the default and maybe just specifying an option when you want to add a comment to that commit. But, by mutating the temporary commit, wouldn't this mean that you lose the refresh history? > Anyway, "freeze" is confusing. Perhaps "snapshot" if anything... You are right. -- Catalin - 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 04:35:16 2005
This archive was generated by hypermail 2.1.8 : 2005-11-02 04:35:20 EST