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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
