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.
> > 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. :-/
> > 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@xxxxxxxxxxx
www.treskal.com/kalle
-
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
