Re: [StGit PATCH 2/2] Write to a stack log when stack is modified

["Catalin Marinas" <catalin.marinas@gmail.com>]

On 22/02/2008, Karl Hasselström <kha@treskal.com> wrote:
> On 2008-02-22 14:05:55 +0000, Catalin Marinas wrote:
>
>  > On 21/02/2008, Karl Hasselström <kha@treskal.com> 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