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

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

Hi,

On Sun, 11 Nov 2007, Junio C Hamano wrote:

> * js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit
>  + rebase: operate on a detached HEAD

Note: this might have a subtle bug when the last patch in the series 
failed.  If I was not too tired this morning (which might well have been 
the case), rebase could not switch back to the branch correctly with this.

> ----------------------------------------------------------------
> [Approaching 'next']
> 
> * kh/commit (Sun Nov 11 17:36:52 2007 +0000) 12 commits
>  - builtin-commit: Add newline when showing which commit was created
>  - builtin-commit: resurrect behavior for multiple -m options
>  - builtin-commit --s: add a newline if the last line was not a S-o-b
>  - builtin-commit: fix --signoff
>  - git status: show relative paths when run in a subdirectory
>  - builtin-commit: fix author date with --amend --author=<author>
>  - builtin-commit: Refresh cache after adding files.
>  - builtin-commit: fix reflog message generation
>  - launch_editor(): read the file, even when EDITOR=:
>  - Port git commit to C.
>  - Export launch_editor() and make it accept ':' as a no-op editor.
>  - Add testcase for ammending and fixing author in git commit.
> 
> Dscho fixed a handful obvious glitches.  I am hoping that this
> series should be in "testable" shape now.  Will merge to "next"
> after giving it a final round of eyeballing.

FWIW I am running 'next'+builtin-commit+a couple of other patches I am 
brewing.  These issues are on my TODO list (most pressing first):

- commit --amend <file> erroneously commits other files that were
  git-add'ed
- under certain circumstances (my maildir update script) does not
  show newly created and deleted files anymore.
- do not rebuild the whole index when committing just one file,
  instead use the old index, and then adjust it to the HEAD.
- remove "launching editor, logfile (null)" message
- forward port 6d4bbebd35e3a6e8091d7188f1c4d49af7f054e3 to builtin-commit
- when a message is given and no editor should be launched, avoid
  lengthy runstatus calculation

Clarification for the "do not rebuild" thingie:  ATM it seems that there 
is a lengthy calculation going on, even if the index is clean and you only 
passed one single filename on the command line.

> * sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
>  - refactor fetch's ref matching to use refname_match()
>  - push: use same rules as git-rev-parse to resolve refspecs
>  - add refname_match()
>  - push: support pushing HEAD to real branch name
> 
> This changes the semantics slightly but I think it is a move in
> the right direction.

We could add a "--matching" option and output a warning when it is not 
passed.  I would like this pretty soon, and would not be sad if it went 
into 'next' before this topic.

> * cr/tag-options (Fri Nov 9 14:42:56 2007 +0100) 1 commit
>  - Make builtin-tag.c use parse_options.
> 
> This changes the handling of multiple -m option without much
> good reason.  It should be a simple fix, once we know what we
> want.  I think the existing behaviour of refusing multiple -m
> is probably the most sane at this point.

I tend to agree.

> * sb/clean (Tue Nov 6 23:18:51 2007 -0600) 1 commit
>  - Make git-clean a builtin

Time is fleeting, so I could not yet look into the ambiguity problem where 
help was requested.

> ----------------------------------------------------------------
> [Others]
> 
> * jc/branch-contains (Wed Nov 7 14:58:09 2007 -0800) 1 commit
>  - git-branch --with=commit
> 
> I did this just for my own fun.

As I already said, I'd like this, but renamed to --containing=.  In fact, 
I just scrapped a script of mine to do the same, in excited expectation of 
this feature.

Ciao,
Dscho