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

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Feb 22, 2008, 15:58 UTC
Message-ID: <b0943d9e0802220758j76248cf3rb4dbb86f03b57b16@mail.gmail.com>
In-Reply-To: <20080222145609.GA19172@diana.vm.bytemark.co.uk>

On 22/02/2008, Karl Hasselström <kha@treskal.com> wrote:

Show 21 quoted lines

> 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.

Show 10 quoted lines

>  > > 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) :-).

Show 16 quoted lines

>  > >  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.

Show 6 quoted lines

>  > 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