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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Nov 15, 2007, 00:49 UTC
Message-ID: <Pine.LNX.4.64.0711150038020.4362@racer.site>
In-Reply-To: <7vfxz89x9q.fsf@gitster.siamese.dyndns.org>

Hi,

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

Show 23 quoted lines

> ----------------------------------------------------------------
> [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.

Show 7 quoted lines

> ----------------------------------------------------------------
> [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.

Show 7 quoted lines

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

Show 5 quoted lines

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

Show 8 quoted lines

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