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

Hi,

On Wed, 14 Nov 2007, Junio C Hamano wrote:

----------------------------------------------------------------
[Approaching 'next']

* kh/commit (Wed Nov 14 10:31:53 2007 -0500) 13 commits
 - builtin-commit: Clean up an unused variable and a debug fprintf().
 - Call refresh_cache() when updating the user index for --only
   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: 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 amending and fixing author in git commit.

Dscho fixed a few obvious glitches, but indicated he has a
handful more issues with the series.  I have been hoping that
this series should be in "testable" shape now.  Will need to
look at it again.

Well, it _is_ in testable shape.  My working setup is using builtin-commit 
since a week.  One glitch is serious: "git add a1 && git commit b1" will 
commit a1, too.

Another glitch is only mildly annoying to me (but I have not investigated 
in detail yet): when you commit new files in a subsubdirectory, no summary 
"created file" is printed for them.

Other than that, I am pretty happy with it, and the other issues I listed 
should be easily fixable.

----------------------------------------------------------------
[Stalled]

* mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit
 - Do git reset --hard HEAD when using git rebase --skip

Some people on the list may find this debatable.  Opinions?

I run with it, and like it.  Sometimes when I rebase to 'next', a patch 
has subtle differences compared to the patch which was applied, and then I 
see in the conflict handling that it was applied already.  So I do the 
obvious: I --skip, and it Just Works.

But you _can_ mistakenly say "--skip".  That's why I pushed for the 
detached HEAD when rebasing.

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

Agree.

* nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit
 + Add missing inside_work_tree setting in setup_git_directory_gently

There was an additional patch, which still had issues Dscho pointed out.  
Waiting for refinements.

This might be something pretty painful, though, speaking from my own 
experience with the work-tree stuff.

----------------------------------------------------------------
[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.  --contains might be more
consistent with git-describe but --with is shorter to type ;-)

--with might confuse people who know that you can use "git branch" to 
create branches, but do not quite know how.

Besides, "--con" would be enough, and you can always add '-c'.  Or use 
completions.

Ciao,
Dscho