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

From: Karl Hasselström <kha@treskal.com>
Date: Feb 22, 2008, 14:56 UTC
Message-ID: <20080222145609.GA19172@diana.vm.bytemark.co.uk>
In-Reply-To: <b0943d9e0802220605t56257718p850c677a59671862@mail.gmail.com>

On 2008-02-22 14:05:55 +0000, Catalin Marinas wrote:

Show 13 quoted lines

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

Show 6 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. :-/

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

> The "(modified)" information was also displayed for a three-way
> merge (either read-tree or recursive-merge) but now it is only shown
> for the recursive one. Correctly, merging git-read-tree modifies a
> patch as well since it no longer applied cleanly.

Ah, so the precise meaning of a patch being "modified" is that git apply failed to apply it. I didn't know that.

> 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? (Otherwise stg export would do the job -- I used to use that before I got confident enough with StGit.)

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.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle