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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Oct 16, 2007, 11:16 UTC
Message-ID: <Pine.LNX.4.64.0710161209480.25221@racer.site>
In-Reply-To: <20071016060456.GC13801@spearce.org>

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.

Show 5 quoted lines

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