What's cooking in git.git (Jan 2009, #02; Sun, 11)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the branches, but I am still holding onto them.

The topics list the commits in reverse chronological order. The topics meant to be merged to the maintenance series have "maint-" in their names.

---------------------------------------------------------------- [New Topics]

* rs/fgrep (Sat Jan 10 00:18:34 2009 +0100) 2 commits
 + grep: don't call regexec() for fixed strings
 + grep -w: forward to next possible position after rejected match

* lt/zlib-wrap-xprm (Wed Jan 7 19:54:47 2009 -0800) 1 commit
 - Wrap inflateInit to retry allocation after releasing pack memory

Need to clean up the log message, perhaps rebase it to maint-1.6.0 and start cooking in 'next'.

* jc/maint-format-patch (Sat Jan 10 12:41:33 2009 -0800) 1 commit
 + format-patch: show patch text for the root commit

* tr/maint-no-index-fixes (Wed Jan 7 12:15:30 2009 +0100) 3 commits
 + diff --no-index -q: fix endless loop
 + diff --no-index: test for pager after option parsing
 + diff: accept -- when using --no-index

* gb/gitweb-opml (Fri Jan 2 13:49:30 2009 +0100) 2 commits
 - gitweb: suggest name for OPML view
 - gitweb: don't use pathinfo for global actions

* mh/maint-commit-color-status (Thu Jan 8 19:53:05 2009 +0100) 2 commits
 - git-status -v: color diff output when color.ui is set
 - git-commit: color status output when color.ui is set

* ks/maint-mailinfo-folded (Thu Jan 8 01:43:42 2009 +0300) 1 commit
 - mailinfo: correctly handle multiline 'Subject:' header

* js/patience-diff (Thu Jan 1 17:39:37 2009 +0100) 3 commits
 - bash completions: Add the --patience option
 - Introduce the diff option '--patience'
 - Implement the patience diff algorithm

All of the above 'pu' topics are ready for 'next'.

* ap/clone-into-empty (Fri Jan 9 02:24:23 2009 +0300) 2 commits
 - Use is_pseudo_dir_name everywhere
 - Allow cloning to an existing empty directory

There is an updated patch that only refactors the repeated code to check if a dirent is dot or dot-dot posted, which I should have picked up to replace these but I haven't yet (the "clone into empty" can and should build on top of it).

---------------------------------------------------------------- [Stalled and may need help and prodding to go forward]

* ds/uintmax-config (Mon Nov 3 09:14:28 2008 -0900) 1 commit
 - autoconf: Enable threaded delta search when pthreads are supported

This automatically enables threaded delta search code when autoconf detects pthreads are usable. I haven't heard neither positive nor negative comments from minority platforms that might be harmed, but this feels like the right thing to do, so perhaps the best course of action is to merge this down to 'master' and see if anybody screams.

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
 + blame: show "previous" information in --porcelain/--incremental
   format
 + git-blame: refactor code to emit "porcelain format" output

This gives Porcelains (like gitweb) the information on the commit _before_ the one that the final blame is laid on, which should save them one rev-parse to dig further. The line number in the "previous" information may need refining, and sanity checking code for reference counting may need to be resurrected before this can move forward.

---------------------------------------------------------------- [Actively cooking]

* mv/apply-parse-opt (Fri Jan 9 22:21:36 2009 -0800) 2 commits
 + Resurrect "git apply --flags -" to read from the standard input
 + parse-opt: migrate builtin-apply.

* rs/maint-shortlog-foldline (Tue Jan 6 21:41:06 2009 +0100) 1 commit
 + shortlog: handle multi-line subjects like log --pretty=oneline et.
   al. do

* tr/rebase-root (Fri Jan 2 23:28:29 2009 +0100) 4 commits
 - rebase: update documentation for --root
 - rebase -i: learn to rebase root commit
 - rebase: learn to rebase root commit
 - rebase -i: execute hook only after argument checking

I should be able to find time to read this over again and merge to 'next' sometime this week.

* as/autocorrect-alias (Sun Jan 4 18:16:01 2009 +0100) 1 commit
 + git.c: make autocorrected aliases work

* js/notes (Sat Dec 20 13:06:03 2008 +0100) 4 commits
 - Add an expensive test for git-notes
 - Speed up git notes lookup
 - Add a script to edit/inspect notes
 - Introduce commit notes

* sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
 - gitweb: Optional grouping of projects by category
 - gitweb: Split git_project_list_body in two functions
 - gitweb: Modularized git_get_project_description to be more generic

* gb/gitweb-patch (Thu Dec 18 08:13:19 2008 +0100) 4 commits
 - gitweb: link to patch(es) view in commit(diff) and (short)log view
 - gitweb: add patches view
 - gitweb: change call pattern for git_commitdiff
 - gitweb: add patch view

---------------------------------------------------------------- [Graduated to "master"]

* mh/maint-sendmail-cc-doc (Mon Dec 29 00:37:25 2008 +0100) 1 commit
 + doc/git-send-email: mention sendemail.cc config variable

* rs/diff-ihc (Sun Dec 28 19:45:32 2008 +0100) 1 commit
 + diff: add option to show context between close hunks

* js/maint-merge-recursive-r-d-conflict (Mon Dec 22 23:10:20 2008 +0100) 1 commit
 + merge-recursive: mark rename/delete conflict as unmerged

* mk/gitweb-feature (Mon Dec 15 22:16:19 2008 -0800) 1 commit
 + gitweb: unify boolean feature subroutines

* cb/merge-recursive-fix (Mon Dec 15 02:41:24 2008 -0800) 3 commits
 + Merge branch 'cb/maint-merge-recursive-fix' into cb/merge-
   recursive-fix
 + merge-recursive: do not clobber untracked working tree garbage
 + modify/delete conflict resolution overwrites untracked file

* cb/maint-merge-recursive-fix (Sun Dec 14 19:40:09 2008 -0800) 2 commits
 + merge-recursive: do not clobber untracked working tree garbage
 + modify/delete conflict resolution overwrites untracked file

* wp/add-p-goto (Thu Dec 4 10:22:40 2008 +0000) 2 commits
 + Add 'g' command to go to a hunk
 + Add subroutine to display one-line summary of hunks

* jn/gitweb-blame (Thu Dec 11 01:33:29 2008 +0100) 3 commits
 + gitweb: cache $parent_commit info in git_blame()
 + gitweb: A bit of code cleanup in git_blame()
 + gitweb: Move 'lineno' id from link to row element in git_blame

* mv/um-pdf (Wed Dec 10 23:44:50 2008 +0100) 1 commit
 + Add support for a pdf version of the user manual

* kk/maint-http-push (Tue Dec 23 11:31:15 2008 +0300) 1 commit
 + http-push: support full URI in handle_remote_ls_ctx()

---------------------------------------------------------------- [Will merge to "master" soon]

* nd/grep-assume-unchanged (Sat Dec 27 15:21:03 2008 +0700) 2 commits
 + grep: grep cache entries if they are "assume unchanged"
 + grep: support --no-ext-grep to test builtin grep

* as/maint-shortlog-cleanup (Tue Dec 30 22:01:44 2008 +0100) 1 commit
 + builtin-shortlog.c: use string_list_append(), and don't strdup
   unnecessarily

* jc/maint-ls-tree (Wed Dec 31 19:00:50 2008 +0900) 2 commits
 + Document git-ls-tree --full-tree
 + ls-tree: add --full-tree option

* js/bundle-tags (Fri Jan 2 19:08:46 2009 +0100) 1 commit
 + bundle: allow rev-list options to exclude annotated tags

* js/add-not-submodule (Fri Jan 2 19:08:40 2009 +0100) 1 commit
 + git add: do not add files from a submodule

* pb/maint-git-pm-false-dir (Mon Dec 29 01:25:00 2008 +0100) 1 commit
 + Git.pm: correctly handle directory name that evaluates to "false"

* pj/maint-ldflags (Sun Jan 4 21:27:41 2009 -0500) 1 commit
 + configure clobbers LDFLAGS

* fe/cvsserver (Fri Jan 2 16:40:14 2009 +0100) 2 commits
 + cvsserver: change generation of CVS author names
 + cvsserver: add option to configure commit message

* js/maint-bisect-gitk (Fri Jan 2 19:08:00 2009 +0100) 1 commit
 + bisect view: call gitk if Cygwin's SESSIONNAME variable is set

* np/no-loosen-prune-expire-now (Tue Dec 30 14:45:11 2008 -0500) 1 commit
 + objects to be pruned immediately don't have to be loosened

* cb/maint-unpack-trees-absense (Thu Jan 1 21:54:33 2009 +0100) 3 commits
 + unpack-trees: remove redundant path search in verify_absent
 + unpack-trees: fix path search bug in verify_absent
 + unpack-trees: handle failure in verify_absent

* mc/cd-p-pwd (Tue Dec 30 07:10:24 2008 -0800) 1 commit
 + git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on
   OS X

* mh/cherry-default (Thu Jan 1 22:56:29 2009 +0100) 2 commits
 + Documentation: clarify which parameters are optional to git-cherry
 + git-cherry: make <upstream> parameter optional

---------------------------------------------------------------- [Will drop]

* as/commit-signoff (Mon Dec 29 12:16:45 2008 +0100) 1 commit
 - [WIP] Add a commit.signoff configuration option to always use --
   signoff in commit

The semantics when "git commit" was used as a backend for other actions such as rebase and cherry-pick was unclear.

---------------------------------------------------------------- [On Hold]

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for

This would be the right thing to do for command line use, but gitk will be hit due to tcl/tk's limitation, so I am holding this back for now.

* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
 - git-am --forge: add Signed-off-by: line for the author
 - git-am: clean-up Signed-off-by: lines
 - stripspace: add --log-clean option to clean up signed-off-by:
   lines
 - stripspace: use parse_options()
 - Add "git am -s" test
 - git-am: refactor code to add signed-off-by line for the committer

On 01:51 Sun 11 Jan     , Junio C Hamano wrote:

My testcases ([PATCH] Add new testcases for format-patch root commits) for this don't satisfy the target behaviour.

As far as I understood from your message, you don't think that cloning into empty directories is necessary. So, I thought, the best solution for yesterday was "[PATCH] add is_dot_or_dotdot inline function" (to make you happy ;)).

But the workarounds like this:

|    $ git clone -n $there it.git
|    $ mv it.git/.git . && rmdir it.git && git checkout -f

are painful, especially for newbies who have no idea about anything but 'git clone'.

Btw, I've sent some worthwhile patches, I but haven't got any reply from you:
	[PATCH] use || instead of | in logical expressions
	[PATCH] Replace deprecated dashed git commands in usage
	[PATCH] remove unnecessary 'if'
It's better if you say "No" than nothing.

Alexander Potashev <aspotashev@gmail.com> writes:

I thought I squashed the test case from your original to it and they seem to pass for me, but maybe you are talking about some other tests? If you know of breakages please send in incremental updates.

I merely said "I am not particularly interested in it." That's quite different from "I oppose and reject".

As long as the new feature is maintainability-wise low-impact and does not hurt users who do _not_ use it, I am not opposed to have a new feature even when I see it is only narrowly useful.

If a topic brings in a large change that helps to support only one particular workflow better, while making it cumbersome to update the resulting code to support some other workflow later, even if the change is useful for users of that one particular workflow, I may oppose it. It would be high-impact from the maintainability point of view [*1*].

But I do not think your "clone here" falls into that category.

It is really up to you to follow through with it, and people with similar needs to cheer you on. I thought you took a good strategy to first get dot-or-dotdot in (which is generally useful), hoping to bring up the "clone here" topic again by building on top of it later.

I do not recall the last one.

The first one I thought was a trivial janitor patch that (1) didn't matter very deeply but made things somewhat easier to read, and more importantly (2) you had "oops" reply to yourself.

I often clean up trivial "oops" in a patch that fixes bugs or adds features to avoid extra round trip with the contributor, but that is only when bugfix and enhancements are worthwhile by itself.

The purpose of a clean-up patch is to clean things up. If it itself has "oops" in it, that fails its own criteria of goodness. Please don't expect/force me to spend time cleaning up "oops" in a clean-up patch, but submit a replacement I can apply straight out of my mailbox.

The second one I was expecting to hear from people who were involved in the discussion back when we standardized on dashless form to show hands as I recall these messages were deliberately left with dashed form for some reason (perhaps to help avoiding "man git foo" vs "man git-foo" confusion).

[Footnote]

*1* Such a change probably needs to be justified either by showing any other workflow does not make sense (so supporting that one true workflow well is sufficient) or by demonstrating that support for some other equally valid workflows can be included trivially, or both.

Junio C Hamano <gitster@pobox.com> writes:

This I think needs some further cooking.  I guess with addition of one
more patch to series categories could be sorted together with projects
they contain, and not always have to be in fixed ordering.
 

If I remember correctly the only point of discussion is calling convention for git_commitdiff, and whether 'patches' view should (re)use git_commitdiff or use its own subroutine.

Jakub Narebski <jnareb@gmail.com> writes:

These should be moved to the Stalled category; nobody seems to be discussing improvements and sending updates to the series as far as I recall.

Thanks; I take it that it is basically usable, useful and can be incrementally improved in 'next'?

On Sun, 11 Jan 2009, Junio C Hamano wrote:

I think it is just the author being slow moving; there was quite a bit of time between subsequent versions of this patch series. But if Sebastien would not resend this series in about a week, I'll try to clean it up, add fourth patch, and resend it.

As to lack of discussion: I think it is cause bu two issues. First, there is support for tags already implemented which somewhat reduces need for categories support. Second, hosting sites which have large number of projects for which categories support might be a nice thing, use I guess modified gitweb with caching, don't they?

Yes, I think so. The changes are cosmetic in nature, and I think the feature this patch adds is quite useful: you can now get patches and [short] patch series from gitweb which you can apply using git-am. Nice, isn't it?

Jakub Narebski <jnareb@gmail.com> writes:

Oh, being slow is fine and "Stalled" is exactly that.

Thanks.

Selon Jakub Narebski <jnareb@gmail.com>:

Hello,

Sorry for not responding earlier, I was quite busy being ill and moving abroad for a new job.

I don't recall what was left to do on top of the series of patches I submitted, could you refresh my mind on that if it still needs to be done? I remember the discussion trailing off as categorized ordering was being discussed..

On Wed, 21 Jan 09, Sebastien Cevey wrote:

I'd have to take a fresh look at discussion but I remember two things: first, that the code dealing with filtering out projects (e.g. removing forks) is high incompatibile with introducing later limiting number of projects per page, as it currently filters out paths _during printing_. So we might want to have this cleanup before your series (which now include a bit unnecessary preparation for projects_list view pagination).

Second, there was IMHO one unnecessary sorting, as with one more commit we can have quite simply categories sorted in order of sorting project they contain, which means that if we sort projects by age (youngest or rather most recently changed first) then with one more commit we can have category containing freshest project first.

I'll try to review this series soon, and if you don't have time I'll resend them with those minor corrections.

Hi,

Am 11.01.2009 um 10:51 schrieb Junio C Hamano:

I think this belongs into maint - without it the testsuite fails on OSX.

	Marcel

Marcel Koeppen <lists@marzelpan.de> writes:

One step at a time.

I did fork the topic at v1.6.1 so that after it proves itself in next and then in master it can go to maint.