On 2008-02-20 22:46:48 +0000, Catalin Marinas wrote:
> On 14/02/2008, Karl Hasselström <kha@xxxxxxxxxxx> wrote:
>
> > Create a log branch (called <branchname>.stgit) for each StGit
> > branch, and write to it whenever the stack is modified.
>
> 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, 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.)
> Can we not use some of the automatic reflog recording that GIT does
> instead of writing a commit? It's cheaper to write a text file than
> generating a commit.
As I said, I'm not convinced that it's a huge difference when you have
just one log commit per operation, not one per changed patch. But
let's stop arguing about it until I have some numbers to back my claim
up. ;-)
> 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?
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.
--
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
