On 22/02/2008, Karl Hasselström <kha@xxxxxxxxxxx> wrote: > On 2008-02-22 14:05:55 +0000, Catalin Marinas wrote: > > > On 21/02/2008, Karl Hasselström <kha@xxxxxxxxxxx> wrote: > > > > > On 2008-02-20 22:46:48 +0000, Catalin Marinas wrote: > > > > > > > The abstractions are really nice (and I still wonder how StGIT > > > > codebase increased that much when all I needed two years ago > > > > was a simple script-like application to reorder commits :-)). > > > > > > :-) I'll take some of the blame, but StGit was quite large already > > > when I started submitting patches to it. > > > > Anyway, the new restructuring is much cleaner, though heavily OO and > > some people might not like it (me not included). > > > That it's conceptually OO is unavoidable, I think (the only way to > avoid that would be through obfuscation). And using Python's OO > features to write code for such a model is the least bad you can do in > Python. IMHO. I agree. > > > When you say "it's still slow", are you referring to the existing > > > per-patch log, my per-branch log, or just StGit in general? > > > > I think it's more GIT in general. Checking the tree status takes > > some time and a 3-way merge on a 512MB RAM machine with GIT using > > over 200MB gets a bit slow. > > > I just upgraded my laptop from 512 MB to 2 GB, so I'll start > neglecting this kind of problem, I fear. :-/ You can boot with mem=512MB (or even less) :-). > > > Have you noticed any difference between commands using the old > > > and new infrastructure (say, stg push vs. stg goto)? The latter > > > should be taking less time, due to touching the worktree only > > > when necessary. > > > > In the patch pushing functions, it now first calls simple_merge() > > which is still a 3-way merge but without rename detection. The old > > StGIT implementation was using "git-diff | git-apply" and falling > > back to the recursive merge. Most of the patches apply cleanly and > > we don't need the three-way merge which uses more RAM. > > > I didn't include patch application because it wasn't necessary to get > things working, and is easy to add at any later point. > > I'd be curious to see how much of a difference it makes. It makes a difference if you don't have much RAM available. I think once a patch falls back to three-way merge, Linux already makes room available for the subsequent merges. But, as I said, most of the time the patches just apply cleanly. > > We could use this "modified" feature to automatically export patches > > (some people asked for this in the past, as means for backup in case > > of StGIT failures). > > > You mean automatically export only the changed patches? Yes, at refresh and pushing, but for the latter, only if a patch was modified. > One cool thing we could do is export the patches as files in a git > branch -- the log machinery I'm building should make it trivial. That > way, you'd get the history of the patches too. Yes, I don't think it is difficult to do (it just need to be optional as some people might not need it). -- Catalin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
