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, 14:05 UTC
Message-ID: <b0943d9e0802220605t56257718p850c677a59671862@mail.gmail.com>
In-Reply-To: <20080221071819.GA8250@diana.vm.bytemark.co.uk>

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

Show 9 quoted lines

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

Show 15 quoted lines

>
>
>  > Anyway, I don't really like the idea of an additional commit (I
>  > don't even like the old patch log implementation) when the stack is
>  > modified. It needs some profiling but it has a visible impact on
>  > stacks with a big number of patches (my last kernel release at
>  > www.linux-arm.org/git had 80 patches and it takes a lot of time to
>  > push them).
>
>
> One thing to remember is that my patch stack log gets one new commit
>  per StGit operation, not one per changed patch. So if you push 80
>  patches with one command, that will give you just one commit on the
>  log. (If someone makes a scripts that calls push 80 times this won't
>  help, of course.)

Ah, I got it now. Indeed, it would be faster than the current per-patch log. I no longer that worried :-)

Show 8 quoted lines

>  > In my kernel repository I have several branches with many patches
>  > and, even after "git gc" and repacking, it is still slow (mainly
>  > because of git-read-tree but I'd like to reduce the number of calls
>  > to GIT).
>
>
> 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.

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

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

-- 
Catalin