What's cooking in git.git (Dec 2008, #04; Mon, 29)

What's cooking in git.git (Dec 2008, #04; Mon, 29)

[Junio C Hamano]

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]

* 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

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

* as/maint-shortlog-cleanup (Wed Dec 24 17:34:44 2008 +0100) 2 commits
 - builtin-shortlog.c: do not unnecessarily strdup before insertion
   in list
 - builtin-shortlog.c: use string_list_append() instead of
   duplicating its code

* 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

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

* jc/maint-ls-tree (Thu Dec 25 16:54:23 2008 -0800) 1 commit
 + ls-tree: add --full-tree option

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

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

* wp/add-patch-find (Thu Nov 27 04:08:03 2008 +0000) 3 commits
 . In add --patch, Handle K,k,J,j slightly more gracefully.
 . Add / command in add --patch
 . git-add -i/-p: Change prompt separater from slash to comma

I am still holding onto this earlier topic to add '/' subcommand to allow
finding a hunk with given text, but I'd rather not merge/rebase it on top
of wp/add-p-goto series myself.  Waiting for a reroll.

* kb/am-directory (Fri Aug 29 15:27:50 2008 -0700) 1 commit
 . git-am: Pass the --directory option through to git-apply

A reroll of this by Simon Schubert triggered a series to fix a parameter
propagation bug, and another reroll to add "git am --directory=path/"
should be much easier now.  I am not likely to use the feature myself, so
it is up to intrested volunteers to carry it 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.

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

* 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

* 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

* 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

Jakub seemed to feel they are not yet ready.

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

I do not have a new enough combination of dblatex and asciidoc myself but
this may help interested people.

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

* js/rebase-i-p (Mon Dec 15 11:05:31 2008 +0100) 2 commits
 + rebase -i -p: Fix --continue after a merge could not be redone
 + Show a failure of rebase -p if the merge had a conflict

* np/auto-thread (Mon Dec 15 20:44:30 2008 +0100) 3 commits
 + Force t5302 to use a single thread
 + pack-objects: don't use too many threads with few objects
 + autodetect number of CPUs by default when using threads

* lt/reset-merge (Wed Dec 3 18:00:12 2008 -0800) 2 commits
 + Document "git-reset --merge"
 + Add 'merge' mode to 'git reset'

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

* cb/mergetool (Fri Dec 12 21:48:41 2008 +0000) 4 commits
 + mergetool: Don't keep temporary merge files unless told to
 + mergetool: Add prompt to continue after failing to merge a file
 + Add -y/--no-prompt option to mergetool
 + Fix some tab/space inconsistencies in git-mergetool.sh

I have been waiting for comments from the original author and other
interested parties, but haven't heard anything yet.  This tool is on the
fringe from my point of view anyway, so I'll push them out to 'master'
soon.  If there is a breakage that annoys real people, we will hear from
them, and we can take it from there.

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

* nd/narrow (Sun Nov 30 17:54:38 2008 +0700) 17 commits
 - wt-status: show sparse checkout info
 - Introduce default sparse patterns (core.defaultsparse)
 - checkout: add new options to support sparse checkout
 - clone: support sparse checkout with --sparse-checkout option
 - unpack_trees(): add support for sparse checkout
 - unpack_trees(): keep track of unmerged entries
 - Introduce "sparse patterns"
 - Merge branch 'master' into nd/narrow
 - t2104: touch portability fix
 - grep: skip files outside sparse checkout area
 - checkout_entry(): CE_NO_CHECKOUT on checked out entries.
 - Prevent diff machinery from examining worktree outside sparse
   checkout
 - ls-files: Add tests for --sparse and friends
 - update-index: add --checkout/--no-checkout to update
   CE_NO_CHECKOUT bit
 - update-index: refactor mark_valid() in preparation for new options
 - ls-files: add options to support sparse checkout
 - Introduce CE_NO_CHECKOUT bit

Kicked out of 'next' by popular demand (see recent discussion on the
interaction between the checkout area and commands such as "grep").

* jc/clone-symref-2 (Sat Nov 29 23:38:21 2008 -0800) 7 commits
 - clone: test the new HEAD detection logic
 - Merge commit 'HEAD@{2}' into HEAD
 - upload-pack: send the HEAD information
 - clone: find the current branch more explicitly
 - connect.c::read_extra_info(): find where HEAD points at
 - connect.c::read_extra_info(): prepare to receive more than server
   capabilities
 - get_remote_heads(): refactor code to read "server capabilities"

An attempt to extend the fetch protocol to make the logic to detect where
HEAD on the origin site points to more robust.

* cc/bisect-replace (Mon Nov 24 22:20:30 2008 +0100) 9 commits
 - bisect: add "--no-replace" option to bisect without using replace
   refs
 - rev-list: make it possible to disable replacing using "--no-
   bisect-replace"
 - bisect: use "--bisect-replace" options when checking merge bases
 - merge-base: add "--bisect-replace" option to use fixed up revs
 - commit: add "bisect_replace_all" prototype to "commit.h"
 - rev-list: add "--bisect-replace" to list revisions with fixed up
   history
 - Documentation: add "git bisect replace" documentation
 - bisect: add test cases for "git bisect replace"
 - bisect: add "git bisect replace" subcommand

I think a mechanism like this should be added to replace grafts, but it
should always be enabled for normal revision traversal operation, while
always disabled for object enumeration and transfer operation (iow, fsck,
fetch and push should use the real ancestry information recorded in the
underlying objects, while rev-list, log, etc. should always use the
replaced objects).  I have a suspicion that even cat-file could honor it.

* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
 - "git push": tellme-more protocol extension

This seems to have a deadlock during communication between the peers.
Someone needs to pick up this topic and resolve the deadlock before it can
continue.

* 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 (Dec 2008, #04; Mon, 29)

[Jakub Narebski]

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

> 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.
> 
> ----------------------------------------------------------------
> [Actively cooking]
> 
> * mk/gitweb-feature (Mon Dec 15 22:16:19 2008 -0800) 1 commit
>  - gitweb: unify boolean feature subroutines

Nice thing from what I remember (I assume it is last incantation?).
 
> * 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
> 
> Jakub seemed to feel they are not yet ready.

This is, I think, ready. It is incremental AJAX-y blame in gitweb
that is not yet ready; this is simple cleanup and performance
improvement.
 
> * 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

I think this needs a bit more cooking; with one more commit I think
you can have categories within requested sort order, and not always
sorted alphabetically.
 
> * 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

I think it is ready, or almost ready. I'll try to review this series
within a week. Feel free to prod me if I forget.


P.S. BTW. what is the status on using parse_options among git
commands?
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: What's cooking in git.git (Dec 2008, #04; Mon, 29)

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 354 bytes --]

On Tue, Dec 30, 2008 at 03:15:43PM -0800, Jakub Narebski <jnareb@gmail.com> wrote:
> P.S. BTW. what is the status on using parse_options among git
> commands?

You mean the C or the shell commands?

I sent the third version of the builtin-apply migration ($gmane/104029),
but I got no answer so far, probably it was dropped on the floor by
accident. ;-)

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: What's cooking in git.git (Dec 2008, #04; Mon, 29)

[Junio C Hamano]

Miklos Vajna <vmiklos@frugalware.org> writes:

> On Tue, Dec 30, 2008 at 03:15:43PM -0800, Jakub Narebski <jnareb@gmail.com> wrote:
>> P.S. BTW. what is the status on using parse_options among git
>> commands?
>
> You mean the C or the shell commands?
>
> I sent the third version of the builtin-apply migration ($gmane/104029),
> but I got no answer so far, probably it was dropped on the floor by
> accident. ;-)

No, just I can be slow during a week like everybody else.

Re: What's cooking in git.git (Dec 2008, #04; Mon, 29)

[Christian Couder]

Le mardi 30 décembre 2008, Junio C Hamano a écrit :
>
> * cc/bisect-replace (Mon Nov 24 22:20:30 2008 +0100) 9 commits
>  - bisect: add "--no-replace" option to bisect without using replace
>    refs
>  - rev-list: make it possible to disable replacing using "--no-
>    bisect-replace"
>  - bisect: use "--bisect-replace" options when checking merge bases
>  - merge-base: add "--bisect-replace" option to use fixed up revs
>  - commit: add "bisect_replace_all" prototype to "commit.h"
>  - rev-list: add "--bisect-replace" to list revisions with fixed up
>    history
>  - Documentation: add "git bisect replace" documentation
>  - bisect: add test cases for "git bisect replace"
>  - bisect: add "git bisect replace" subcommand
>
> I think a mechanism like this should be added to replace grafts, 

The problem with replacing grafts is that a graft can specify many parents 
for one commit while a ref associates only one object to a name.

One way to overcome this could be to use many refs for each graft, for 
example (in the packed ref format):

<1st parent sha1> refs/replace/grafts/<commit sha1>-<1st parent sha1>
<2nd parent sha1> refs/replace/grafts/<commit sha1>-<2nd parent sha1>
...

Another way would be to put all the parents in the ref name, for example:

<1st parent sha1> /refs/replace/grafts/<commit sha1>-<1st parent sha1>-<2nd 
parent sha1>-<3rd parent sha1>

There is the same kind of problem to mark many "good" (and "skip") commits 
when bisecting and we use something like the first solution above:

<1st good commit sha1> refs/bisect/good-<1st good commit sha1>
<2nd good commit sha1> refs/bisect/good-<2nd good commit sha1>
...

But I think the above solutions are not very clean and it might be better in 
the long run to make it possible to associate more than one object to a 
ref.

Am I missing something? Do you see another way?

Thanks and happy new year everybody,
Christian.

Re: What's cooking in git.git (Dec 2008, #04; Mon, 29)

[Junio C Hamano]

Christian Couder <chriscool@tuxfamily.org> writes:

> Le mardi 30 décembre 2008, Junio C Hamano a écrit :
>>
>> * cc/bisect-replace (Mon Nov 24 22:20:30 2008 +0100) 9 commits
>>  - bisect: add "--no-replace" option to bisect without using replace
>>    refs
>>  - rev-list: make it possible to disable replacing using "--no-
>>    bisect-replace"
>>  - bisect: use "--bisect-replace" options when checking merge bases
>>  - merge-base: add "--bisect-replace" option to use fixed up revs
>>  - commit: add "bisect_replace_all" prototype to "commit.h"
>>  - rev-list: add "--bisect-replace" to list revisions with fixed up
>>    history
>>  - Documentation: add "git bisect replace" documentation
>>  - bisect: add test cases for "git bisect replace"
>>  - bisect: add "git bisect replace" subcommand
>>
>> I think a mechanism like this should be added to replace grafts, 
>
> The problem with replacing grafts is that a graft can specify many parents 
> for one commit while a ref associates only one object to a name.

Sorry, maybe I misunderstood your implementation.  What I thought we
discussed during GitTogether was to write out the object name of the
replacement object in refs/replace/<sha1>.

When the caller asks read_sha1_file() for an object whose object name is
<sha1>, you see if there is refs/replace/<sha1> in the repository, and
read the ref to learn the object name of the object that replaces it.  And
you return that as if it is the original object.

So if your commit cca1704897e7fdb182f68d4c48a437c5d7bc5203 looks like:

    tree 7ccf394b2e80536442703e0013bf0dde86547e08
    parent 3827210b91a7d363ea67bcf0b9c6ee1c91d2f3c5
    author Johannes Schindelin <Johannes.Schindelin@gmx.de> 1230919672 +0100
    committer Junio C Hamano <gitster@pobox.com> 1230931180 -0800

    git wrapper: Make while loop more reader-friendly
    ...

and you would want to lie about its author (or add/subtract different
parent lines, or record a fixed-up tree, or whatever), you first prepare a
replacement commit object:

    $ R=$(git cat-file commit cca17048 |
      sed -e 's/Johannes /&E /' |
      git hash-object -t commit --stdin -w)
    $ git cat-file commit $R
    tree 7ccf394b2e80536442703e0013bf0dde86547e08
    parent 3827210b91a7d363ea67bcf0b9c6ee1c91d2f3c5
    author Johannes E Schindelin <Johannes.Schindelin@gmx.de> 1230919672 +0100
    committer Junio C Hamano <gitster@pobox.com> 1230931180 -0800

    git wrapper: Make while loop more reader-friendly
    ...

and then tell git to replace the original object with this one:

    $ git update-ref refs/replace/$(git rev-parse cca17048) $R

With such a layout, if your arrange the object reachability traverser
(e.g. fsck, pack-objects, bundle and prune) ignore refs/replace mechanism,
while everybody else pay attention to it, you will be able to safely
transfer the "graft" information via usual clone/fetch/push mechanism,
while making things like log, bisect and show just work, pretending as if
the commit cca17048 were made by JES and not by JS.

Re: What's cooking in git.git (Dec 2008, #04; Mon, 29)

[Christian Couder]

Le samedi 3 janvier 2009, Junio C Hamano a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
> > Le mardi 30 décembre 2008, Junio C Hamano a écrit :
> >> * cc/bisect-replace (Mon Nov 24 22:20:30 2008 +0100) 9 commits
> >>  - bisect: add "--no-replace" option to bisect without using replace
> >>    refs
> >>  - rev-list: make it possible to disable replacing using "--no-
> >>    bisect-replace"
> >>  - bisect: use "--bisect-replace" options when checking merge bases
> >>  - merge-base: add "--bisect-replace" option to use fixed up revs
> >>  - commit: add "bisect_replace_all" prototype to "commit.h"
> >>  - rev-list: add "--bisect-replace" to list revisions with fixed up
> >>    history
> >>  - Documentation: add "git bisect replace" documentation
> >>  - bisect: add test cases for "git bisect replace"
> >>  - bisect: add "git bisect replace" subcommand
> >>
> >> I think a mechanism like this should be added to replace grafts,
> >
> > The problem with replacing grafts is that a graft can specify many
> > parents for one commit while a ref associates only one object to a
> > name.
>
> Sorry, maybe I misunderstood your implementation.  What I thought we
> discussed during GitTogether was to write out the object name of the
> replacement object in refs/replace/<sha1>.
>
> When the caller asks read_sha1_file() for an object whose object name is
> <sha1>, you see if there is refs/replace/<sha1> in the repository, and
> read the ref to learn the object name of the object that replaces it. 
> And you return that as if it is the original object.

Ok. When I first implemented "bisect replace" I saw that I could reuse the 
graft fix-up mechanism. And as you talked about replacing grafts, I thought 
that you wanted the implementation to use that mechanism instead of adding 
a different one.

But I agree that it may be more powerfull and generic to replace objects the 
way you describe it. So I will work on that.

Thanks,
Christian.