Re: What's cooking in git/spearce.git (topics)

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

first let me thank you for being the interim maintainer.  I know it is 
much work, and I frankly do not have the time, or nerve, to do it.  Out of 
curiousity: did you use the scripts in "todo" to send these emails?

On Tue, 16 Oct 2007, Shawn O. Pearce wrote:

> * lt/diff-rename (Tue Oct 2 19:28:19 2007 -0700) 1 commit
>  + optimize diffcore-delta by sorting hash entries.

AFAIR this was ready to go to master, with a 5-10% speedup or so, just 
needing a bit of testing.  Which it should have gotten by now.

> * kh/commit (Mon Sep 17 20:06:47 2007 -0400) 4 commits
>  + Export rerere() and launch_editor().
>  + Introduce entry point add_interactive and add_files_to_cache
>  + Enable wt-status to run against non-standard index file.
>  + Enable wt-status output to a given FILE pointer.

This is the beginning of the builtin-commit.  The option parser has to go 
in before that (it was split out from the builtin-commit series), and the 
(minimal) adjustments to builtin-commit.c for the now-changed option 
parser have to be done.

So I think this topic should stay in master until builtin-commit is there, 
too.

> * js/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
>  + rebase: allow starting from a dirty tree.
>  + stash: implement "stash create"

This needs more work in rebase-i, and Junio indicated that he's not 
completely happy with it.

It would serve to be able to rebase in a dirty tree, by first stashing 
away the changes, and then applying them on top of the rebased branch.

I think that this would avoid many "Huh?" effects, but it should try to 
"git stash apply --index" first, falling back to "git stash apply".

Something like that would be very nice for git-pull, too, I guess.

However, I have not thought through all implications.

Ciao,
Dscho