Dear diary, on Sat, Nov 05, 2005 at 09:23:33PM CET, I got a letter where Catalin Marinas <catalin.marinas@gmail.com> said that... > I would like to have a way of checking the changes to individual > patches, just to be able to go back if some changes broke it. Yes, that would be nice to have as well (although in general I lean to recording the whole stack now). Model scenario: A night city, the snow slowly falling. Approaching the roofs covered in white and illuminated by the yellow street lighting, dark windows - but one dimly glowing, a computer screen inside. Close-up on a hacker: $EDITOR opened, lost deep in hack mode, fingers dancing over the keyboard. Dreamy-monumental music in the background. StGIT user, only part of the patches in stack, and the rest depends on the one currently edited, and I want to record my work on this one. I can either: (i) Just keep per-patch history only. (ii) Keep _both_ per-patch and per-stack history (since I don't want to record the stack when I have to keep some patches out of it - the history would look like randomly removing and adding tons of patches, and jumping around would be difficult because of this too). (iii) Keep per-patchlist history - do not actually record only our current stack, but all the patches StGIT knows about. The patches depending on the one currently being changed will not be in consistent state, but that's tough. Actually, this seems to be the most viable strategy. One question is whether to record if some patch is actually applied right now or not (I'd say don't record it since you again have the "bouncing problem" otherwise). Ideas? > It's also useful to have some kind of revision control for the whole > stack, but this can be achieved with tags at the moment. Yes, now let's sequence the tags... ;-) -- 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 Thu Nov 10 10:33:31 2005
This archive was generated by hypermail 2.1.8 : 2005-11-10 10:33:35 EST