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

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

[Junio C Hamano]

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

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

[Alexander Potashev]

On 01:51 Sun 11 Jan     , Junio C Hamano wrote:
> [New Topics]
> 
> 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

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

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

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

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


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.

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

[Jakub Narebski]

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

> ----------------------------------------------------------------
> [Actively cooking]
>
> * 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

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

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
Poland
ShadeHawk on #git

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

[Junio C Hamano]

Alexander Potashev <aspotashev@gmail.com> writes:

>> * jc/maint-format-patch (Sat Jan 10 12:41:33 2009 -0800) 1 commit
>>  + format-patch: show patch text for the root commit
>
> My testcases ([PATCH] Add new testcases for format-patch root commits)
> for this don't satisfy the target behaviour.

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.

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

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.

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

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.

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

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

>> ----------------------------------------------------------------
>> [Actively cooking]
>>
>> * 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
>
> 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.

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.

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

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

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

[Jakub Narebski]

On Sun, 11 Jan 2009, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
>>> ----------------------------------------------------------------
>>> [Actively cooking]
>>>
>>> * 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
>>
>> 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.
> 
> 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.

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?

>>> * 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
>>
>> 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.
> 
> Thanks; I take it that it is basically usable, useful and can be
> incrementally improved in 'next'?

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
Poland

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

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> On Sun, 11 Jan 2009, Junio C Hamano wrote:
>> 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.
>
> I think it is just the author being slow moving; there was quite
> a bit of time between subsequent versions of this patch series.

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

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

Thanks.

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

[Marcel Koeppen]

Hi,

Am 11.01.2009 um 10:51 schrieb Junio C Hamano:

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

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

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


	Marcel

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

[Junio C Hamano]

Marcel Koeppen <lists@marzelpan.de> writes:

> Hi,
>
> Am 11.01.2009 um 10:51 schrieb Junio C Hamano:
>
>> ----------------------------------------------------------------
>> [Will merge to "master" soon]
>
>> * 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
>
> I think this belongs into maint - without it the testsuite fails on OSX.

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.

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

[Sebastien Cevey]

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.

> >>> ----------------------------------------------------------------
> >>> [Actively cooking]
> >>>
> >>> * 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
> >>
> >> 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.
> > 
> > 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.
> 
> I think it is just the author being slow moving; there was quite
> a bit of time between subsequent versions of this patch series.

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

-- 
Sebastien Cevey - inso.cc

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

[Jakub Narebski]

On Wed, 21 Jan 09, Sebastien Cevey wrote:

>>>>> ----------------------------------------------------------------
>>>>> [Actively cooking]
>>>>>
>>>>> * 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
>>>>
>>>> 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.
>>> 
>>> 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.
>> 
>> I think it is just the author being slow moving; there was quite
>> a bit of time between subsequent versions of this patch series.
> 
> 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..

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.
-- 
Jakub Narebski
Poland