What's cooking in git.git (topics)

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

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

* 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

Just my toy at this moment.

----------------------------------------------------------------
[Graduated to 'master']

* dp/clean-fix (Fri Mar 7 21:56:56 2008 -0800) 7 commits
 + git-clean: add tests for relative path
 + git-clean: correct printing relative path
 + Make private quote_path() in wt-status.c available as
   quote_path_relative()
 + Revert part of d089eba (setup: sanitize absolute and funny paths
   in get_pathspec())
 + Revert part of 1abf095 (git-add: adjust to the get_pathspec()
   changes)
 + Revert part of 744dacd (builtin-mv: minimum fix to avoid losing
   files)
 + get_pathspec(): die when an out-of-tree path is given

* sp/fetch-optim (Mon Mar 3 22:27:40 2008 -0500) 11 commits
 + Teach git-fetch to exploit server side automatic tag following
 + Teach fetch-pack/upload-pack about --include-tag
 + git-pack-objects: Automatically pack annotated tags if object was
   packed
 + Teach git-fetch to grab a tag at the same time as a commit
 + Make git-fetch follow tags we already have objects for sooner
 + Teach upload-pack to log the received need lines to an fd
 + Free the path_lists used to find non-local tags in git-fetch
 + Allow builtin-fetch's find_non_local_tags to append onto a list
 + Ensure tail pointer gets setup correctly when we fetch HEAD only
 + Remove unnecessary delaying of free_refs(ref_map) in builtin-fetch
 + Remove unused variable in builtin-fetch find_non_local_tags

* ml/submodule-add-existing (Tue Mar 4 20:15:02 2008 -0500) 1 commit
 + git-submodule - Allow adding a submodule in-place

* jc/describe-always (Sun Mar 2 08:51:57 2008 -0800) 1 commit
 + describe --always: fall back to showing an abbreviated object name

* aw/maint-shortlog-blank-lines (Wed Mar 5 14:24:10 2008 +0000) 1 commit
 + shortlog: take the first populated line of the description

* jn/gitweb-pickaxe (Wed Mar 5 09:31:55 2008 +0100) 1 commit
 + gitweb: Fix and simplify pickaxe search

* cr/reset-parseopt (Tue Mar 4 23:11:34 2008 +0100) 1 commit
 + Make builtin-reset.c use parse_options.

* mr/compat-snprintf (Wed Mar 5 16:46:13 2008 +0100) 1 commit
 + Add compat/snprintf.c for systems that return bogus

* jc/am (Tue Mar 4 00:25:06 2008 -0800) 3 commits
 + am: --rebasing
 + am: remove support for -d .dotest
 + am: read from the right mailbox when started from a subdirectory

* ph/parseopt (Sun Mar 2 11:35:56 2008 +0100) 2 commits
 + parse-options: new option type to treat an option-like parameter
   as an argument.
 + parse-opt: bring PARSE_OPT_HIDDEN and NONEG to git-rev-parse --
   parseopt

----------------------------------------------------------------
[Actively Cooking]

* lt/unpack-trees (Fri Mar 7 13:48:40 2008 -0800) 10 commits
 + unpack_trees(): minor memory leak fix in unused destination index
 + Make 'unpack_trees()' have a separate source and destination index
 + Make 'unpack_trees()' take the index to work on as an argument
 + Add 'const' where appropriate to index handling functions
 + Fix tree-walking compare_entry() in the presense of --prefix
 + Move 'unpack_trees()' over to 'traverse_trees()' interface
 + Make 'traverse_trees()' traverse conflicting DF entries in
   parallel
 + Add return value to 'traverse_tree()' callback
 + Make 'traverse_tree()' use linked structure rather than 'const
   char *base'
 + Add 'df_name_compare()' helper function

* js/remote (Sat Mar 8 23:40:42 2008 +0100) 8 commits
 + builtin remote rm: remove symbolic refs, too
 + remote: fix "update [group...]"
 + remote show: Clean up connection correctly if object fetch wasn't
   done
 + builtin-remote: prune remotes correctly that were added with --
   mirror
 + Make git-remote a builtin
 + Test "git remote show" and "git remote prune"
 + parseopt: add flag to stop on first non option
 + path-list: add functions to work with unsorted lists

Slated for 1.5.5, but probably needs more time to mature.

* jc/unpack-careful (Fri Mar 7 08:39:53 2008 +0100) 5 commits
 + t5300: add test for "index-pack --strict"
 + receive-pack: allow using --strict mode for unpacking objects
 + unpack-objects: fix --strict handling
 + t5300: add test for "unpack-objects --strict"
 + unpack-objects: prevent writing of inconsistent objects

This would re-instate the "unpack-objects --strict" but we probably should
not do this before 1.5.5.

* py/submodule (Sat Mar 8 02:27:19 2008 +0800) 4 commits
 - git-submodule summary: documentation
 - git-submodule summary: limit summary size
 - git-submodule summary: show commit summary
 - git-submodule summary: code framework

Looking better.  With tests it should be mergeable to 'next'.

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

* nd/worktree (Sun Mar 2 17:35:43 2008 +0700) 10 commits
 - Additional tests to capture worktree special cases
 - Documentation: update api-builtin and api-setup
 - Make setup_git_directory() auto-setup worktree if found
 - builtin-archive: mark unused prefix "unused_prefix"
 - Completely move out worktree setup from
   setup_git_directory_gently()
 - http-push: Avoid calling setup_git_directory() twice
 - Make setup_work_tree() return new prefix
 - Make get_git_dir() and 'git rev-parse --git-dir' absolute path
 - Make sure setup_git_directory is called before accessing
   repository
 - "git read-tree -m" and the like require worktree

Every time we touch work-tree stuff we seem to unstabilize; this round
seems more solid but I am still treading cautiously.  Not sure if we want
this for 1.5.5.

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

* jc/rename (Fri Mar 7 14:03:19 2008 -0800) 2 commits
 - diffcore-rename: make file_table available outside exact rename
   detection
 + Optimize rename detection for a huge diff

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 - diff: make --dirstat binary-file safe

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 - Teach GIT-VERSION-GEN about the .git file
 - Teach git-submodule.sh about the .git file
 - Teach resolve_gitlink_ref() about the .git file
 - Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  I am not sure if we should merge this to
'next' before 1.5.5.  Most active people will be on 'next' and
if we have this there, the resulting 1.5.5 release might end up
having issues that come from differences this one introduces.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 - sha1-lookup: make selection of 'middle' less aggressive
 - sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 5 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive
 + expose a helper function peel_to_type().
 + merge-recursive: split low-level merge functions out.

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time now.

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

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

* cc/help (Tue Mar 11 08:51:12 2008 +0100) 3 commits
 + help: implement multi-valued "man.viewer" config option
 + Documentation: help: describe 'man.viewer' config variable
 + help: add "man.viewer" config var to use "woman" or "konqueror"

* ph/maint-quiltimport (Sat Mar 8 19:27:09 2008 +0100) 1 commit
 + git-quiltimport: better parser to grok "enhanced" series files.

* mr/autoconf-fread (Tue Mar 11 09:48:34 2008 +0100) 1 commit
 + autoconf: Test FREAD_READS_DIRECTORIES

* db/diff-to-fp (Mon Mar 10 13:58:26 2008 -0400) 2 commits
 - wt-status.c: no need for dup() dance anymore
 - Write diff output to a file in struct diff_options

All of these can be in 1.5.5 (they may or may not need fix-ups); let's
close the 1.5.5 merge window now with these.

----------------------------------------------------------------
[Graduated to 'master']

* lt/unpack-trees (Fri Mar 7 13:48:40 2008 -0800) 10 commits
 + unpack_trees(): minor memory leak fix in unused destination index
 + Make 'unpack_trees()' have a separate source and destination index
 + Make 'unpack_trees()' take the index to work on as an argument
 + Add 'const' where appropriate to index handling functions
 + Fix tree-walking compare_entry() in the presense of --prefix
 + Move 'unpack_trees()' over to 'traverse_trees()' interface
 + Make 'traverse_trees()' traverse conflicting DF entries in
   parallel
 + Add return value to 'traverse_tree()' callback
 + Make 'traverse_tree()' use linked structure rather than 'const
   char *base'
 + Add 'df_name_compare()' helper function

* js/remote (Sat Mar 8 23:40:42 2008 +0100) 9 commits
 + "remote update": print remote name being fetched from
 + builtin remote rm: remove symbolic refs, too
 + remote: fix "update [group...]"
 + remote show: Clean up connection correctly if object fetch wasn't
   done
 + builtin-remote: prune remotes correctly that were added with --
   mirror
 + Make git-remote a builtin
 + Test "git remote show" and "git remote prune"
 + parseopt: add flag to stop on first non option
 + path-list: add functions to work with unsorted lists

----------------------------------------------------------------
[Actively Cooking]

* py/submodule (Tue Mar 11 21:52:19 2008 +0800) 5 commits
 + git-submodule summary: test
 + git-submodule summary: documentation
 + git-submodule summary: limit summary size
 + git-submodule summary: show commit summary
 + git-submodule summary: code framework

I didn't see anybody very supportive for this series, but I do not think
this regresses existing other subcommands to "git submodule", so let's
merge this to 'master' before 1.5.5 and see how useful submodule users
find this.

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

* nd/worktree (Sun Mar 2 17:35:43 2008 +0700) 10 commits
 - Additional tests to capture worktree special cases
 - Documentation: update api-builtin and api-setup
 - Make setup_git_directory() auto-setup worktree if found
 - builtin-archive: mark unused prefix "unused_prefix"
 - Completely move out worktree setup from
   setup_git_directory_gently()
 - http-push: Avoid calling setup_git_directory() twice
 - Make setup_work_tree() return new prefix
 - Make get_git_dir() and 'git rev-parse --git-dir' absolute path
 - Make sure setup_git_directory is called before accessing
   repository
 - "git read-tree -m" and the like require worktree

Every time we touch work-tree stuff we seem to unstabilize; this round
seems more solid but I am still treading cautiously.  Not sure if we want
this for 1.5.5.

* jc/unpack-careful (Fri Mar 7 08:39:53 2008 +0100) 5 commits
 + t5300: add test for "index-pack --strict"
 + receive-pack: allow using --strict mode for unpacking objects
 + unpack-objects: fix --strict handling
 + t5300: add test for "unpack-objects --strict"
 + unpack-objects: prevent writing of inconsistent objects

This would re-instate the "unpack-objects --strict" but we probably should
not do this before 1.5.5.

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

* jc/rename (Fri Mar 7 14:03:19 2008 -0800) 2 commits
 - diffcore-rename: make file_table available outside exact rename
   detection
 + Optimize rename detection for a huge diff

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 - diff: make --dirstat binary-file safe

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 - Teach GIT-VERSION-GEN about the .git file
 - Teach git-submodule.sh about the .git file
 - Teach resolve_gitlink_ref() about the .git file
 - Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  I am not sure if we should merge this to
'next' before 1.5.5.  Most active people will be on 'next' and
if we have this there, the resulting 1.5.5 release might end up
having issues that come from differences this one introduces.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 - sha1-lookup: make selection of 'middle' less aggressive
 - sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time 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

Just my toy at this moment.

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

[Johannes Schindelin]

Hi,

On Wed, 12 Mar 2008, Junio C Hamano wrote:

> * nd/worktree (Sun Mar 2 17:35:43 2008 +0700) 10 commits
>  - Additional tests to capture worktree special cases
>  - Documentation: update api-builtin and api-setup
>  - Make setup_git_directory() auto-setup worktree if found
>  - builtin-archive: mark unused prefix "unused_prefix"
>  - Completely move out worktree setup from
>    setup_git_directory_gently()
>  - http-push: Avoid calling setup_git_directory() twice
>  - Make setup_work_tree() return new prefix
>  - Make get_git_dir() and 'git rev-parse --git-dir' absolute path
>  - Make sure setup_git_directory is called before accessing
>    repository
>  - "git read-tree -m" and the like require worktree
> 
> Every time we touch work-tree stuff we seem to unstabilize; this round 
> seems more solid but I am still treading cautiously.  Not sure if we 
> want this for 1.5.5.

I am sure we do not want this for 1.5.5.

It is too complicated a patch series to be obviously correct, and as I 
said earlier, a few design goals are not to my liking, such as trying to 
separate git_dir from work_tree logic with a sledgehammer.

Ciao,
Dscho

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

The merge window for 1.5.5 is closed as of tonight, except for the
promised git-gui (0.10) and gitk updates, and topics still cooking in
'next', and 1.5.5-rc0 will be tagged shortly.

After that we will have quite a lot of regression fixes ahead of us, I am
afraid.  Since v1.5.4, a few commands have been reimplemented or made
built-ins (checkout, remote, merge-recursive), and these inevitably
involve "growing pains".

While I am reasonably confident that we have long caught showstopper
regressions in key features of these commands while they were cooking in
'next', I am sure there would remain regressions here and there in the
periphery.  It is unavoidable.  POSIX-only people may say "why rewrite, if
it involves this much pain", but like it or not, there are people stuck on
unfortunate platforms that cannot run scripted versions well enough.

Let's see if our regular contributors are as good at fixing their own
screw-ups as they are good at coming up with new code, and hope that we
can keep this rc cycle manageably short.  Touch wood...

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

* jc/makefile (Wed Mar 12 01:46:26 2008 -0700) 2 commits
 - Makefile: flatten enumeration of headers, objects and programs
 - Makefile: DIFF_OBJS is not special at all these days

I promised to do this immediately after -rc0, so this will shortly be in
'next' and then in 'master'.

* jk/portable (Wed Mar 12 17:42:43 2008 -0400) 13 commits
 + t7505: use SHELL_PATH in hook
 + t9112: add missing #!/bin/sh header
 + filter-branch: use $SHELL_PATH instead of 'sh'
 + filter-branch: don't use xargs -0
 + add NO_EXTERNAL_GREP build option
 + t6000lib: tr portability fix
 + t4020: don't use grep -a
 + add test_cmp function for test scripts
 + remove use of "tail -n 1" and "tail -1"
 + grep portability fix: don't use "-e" or "-q"
 + more tr portability test script fixes
 + t0050: perl portability fix
 + tr portability fixes

Initially triggered by Solaris porting effort but these are harmless
portability changes.  Perhaps in 1.5.5, perhaps immediately after that.

----------------------------------------------------------------
[Dropped]

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 . tests: convert "cmp" and "cmp -s" to test_cmp
 . tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

----------------------------------------------------------------
[Graduated to 'master']

* ph/maint-quiltimport (Wed Mar 12 21:07:19 2008 -0700) 2 commits
 + quiltimport: fix misquoting of parsed -p<num> parameter
 + git-quiltimport: better parser to grok "enhanced" series files.

* mr/autoconf-fread (Tue Mar 11 09:48:34 2008 +0100) 1 commit
 + autoconf: Test FREAD_READS_DIRECTORIES

----------------------------------------------------------------
[Actively Cooking]

* cc/help (Thu Mar 13 19:15:30 2008 -0700) 6 commits
 + Documentation/git-help: typofix
 + help: warn if specified 'man.viewer' is unsupported, instead of
   erroring out
 + Documentation: help: explain 'man.viewer' multiple values
 + help: implement multi-valued "man.viewer" config option
 + Documentation: help: describe 'man.viewer' config variable
 + help: add "man.viewer" config var to use "woman" or "konqueror"

* db/diff-to-fp (Mon Mar 10 13:58:26 2008 -0400) 2 commits
 + wt-status.c: no need for dup() dance anymore
 + Write diff output to a file in struct diff_options

* py/submodule (Wed Mar 12 09:30:01 2008 +0100) 6 commits
 + git-submodule summary: fix that some "wc" flavors produce leading
   spaces
 + git-submodule summary: test
 + git-submodule summary: documentation
 + git-submodule summary: limit summary size
 + git-submodule summary: show commit summary
 + git-submodule summary: code framework

I didn't see anybody very supportive for this series, but I do not think
this regresses existing other subcommands to "git submodule", so let's
merge this to 'master' before 1.5.5 and see how useful submodule users
find this.

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

* nd/worktree (Sun Mar 2 17:35:43 2008 +0700) 10 commits
 - Additional tests to capture worktree special cases
 - Documentation: update api-builtin and api-setup
 - Make setup_git_directory() auto-setup worktree if found
 - builtin-archive: mark unused prefix "unused_prefix"
 - Completely move out worktree setup from
   setup_git_directory_gently()
 - http-push: Avoid calling setup_git_directory() twice
 - Make setup_work_tree() return new prefix
 - Make get_git_dir() and 'git rev-parse --git-dir' absolute path
 - Make sure setup_git_directory is called before accessing
   repository
 - "git read-tree -m" and the like require worktree

Every time we touch work-tree stuff we seem to unstabilize; this round
seems more solid but I am still treading cautiously.  Not sure if we want
this for 1.5.5.

* jc/unpack-careful (Fri Mar 7 08:39:53 2008 +0100) 5 commits
 + t5300: add test for "index-pack --strict"
 + receive-pack: allow using --strict mode for unpacking objects
 + unpack-objects: fix --strict handling
 + t5300: add test for "unpack-objects --strict"
 + unpack-objects: prevent writing of inconsistent objects

This would re-instate the "unpack-objects --strict" but we probably should
not do this before 1.5.5.

* jc/rename (Fri Mar 7 14:03:19 2008 -0800) 2 commits
 - diffcore-rename: make file_table available outside exact rename
   detection
 + Optimize rename detection for a huge diff

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 - diff: make --dirstat binary-file safe

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 - Teach GIT-VERSION-GEN about the .git file
 - Teach git-submodule.sh about the .git file
 - Teach resolve_gitlink_ref() about the .git file
 - Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  I am not sure if we should merge this to
'next' before 1.5.5.  Most active people will be on 'next' and
if we have this there, the resulting 1.5.5 release might end up
having issues that come from differences this one introduces.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 - sha1-lookup: make selection of 'middle' less aggressive
 - sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time 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

Just my toy at this moment.

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

Since we tagged -rc0, we've seen regression fixes at a reasonable rate.
At -rc1 tonight, I think we are fairly in good shape.

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

* fl/send-email-outside (Fri Mar 14 18:29:30 2008 +0100) 4 commits
 + send-email: Don't require to be called in a repository
 + Git.pm: Don't require repository instance for ident
 + Git.pm: Don't require a repository instance for config
 + var: Don't require to be in a git repository.

People couldn't invoke "git send-email" from outside their repositories,
but this series allows them to.  I do not think it is urgent, though.
This does not look risky, even though it touches Git.pm that is shared
with other things.  This has been cooking in 'next' for some time and we
haven't heard about breakages caused by this.  Will probably be the first
thing to be merged in 'master' post 1.5.5.

* jc/rebase (Sat Mar 15 13:17:42 2008 -0700) 1 commit
 + rebase [--onto O] A B: omit needless checkout

We used to "git checkout B && git rebase A" internally to implement this,
which meant the work tree was smudged one time too many.  This is probably
a safe optimization, but it case after -rc0 and is not really a must-have
fix.  One of the first after post 1.5.5.

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 - Make git-add behave more sensibly in a case-insensitive
   environment
 - When adding files to the index, add support for case-independent
   matches
 - Make unpack-tree update removed files before any updated files
 - Make branch merging aware of underlying case-insensitive
   filsystems
 - Add 'core.ignorecase' option
 - Make hash_name_lookup able to do case-independent lookups
 - Make "index_name_exists()" return the cache_entry it found
 - Move name hashing functions into a file of its own
 - Make unpack_trees_options bit flags actual bitfields

The beginning of ASCII-only case insensitive filesystem support.  It is
not complete yet, though.  E.g. if you enable core.ignorecase in t0050,
the merge test fails.

* gs/pretty-hexval (Fri Mar 21 10:05:06 2008 -0500) 1 commit
 + pretty.c: add %x00 format specifier.

Adds a generic "insert any byte value" to --pretty=format:<> specifier.

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

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this, but because I have met no real user with shared repository
workflow who complained on this issue, I think this is not urgent.

----------------------------------------------------------------
[Graduated to 'master']

* cc/help (Thu Mar 13 19:15:30 2008 -0700) 6 commits
 + Documentation/git-help: typofix
 + help: warn if specified 'man.viewer' is unsupported, instead of
   erroring out
 + Documentation: help: explain 'man.viewer' multiple values
 + help: implement multi-valued "man.viewer" config option
 + Documentation: help: describe 'man.viewer' config variable
 + help: add "man.viewer" config var to use "woman" or "konqueror"

There are some leftover bits posted after -rc0, but I think they can
wait.

* db/diff-to-fp (Mon Mar 10 13:58:26 2008 -0400) 2 commits
 + wt-status.c: no need for dup() dance anymore
 + Write diff output to a file in struct diff_options

* py/submodule (Wed Mar 12 09:30:01 2008 +0100) 6 commits
 + git-submodule summary: fix that some "wc" flavors produce leading
   spaces
 + git-submodule summary: test
 + git-submodule summary: documentation
 + git-submodule summary: limit summary size
 + git-submodule summary: show commit summary
 + git-submodule summary: code framework

I didn't see anybody very supportive for this series, but I do not think
this regresses existing other subcommands to "git submodule", so let's see
how useful submodule users find this.  Maybe they have improvement ideas
for its output before we decide post 1.5.5 if it is a good idea to include
it in "git status" output.

* jc/makefile (Wed Mar 12 01:46:26 2008 -0700) 2 commits
 - Makefile: flatten enumeration of headers, objects and programs
 - Makefile: DIFF_OBJS is not special at all these days

I promised to do this immediately after -rc0, so this will shortly be in
'next' and then in 'master'.

* jk/portable (Wed Mar 12 17:42:43 2008 -0400) 13 commits
 + t7505: use SHELL_PATH in hook
 + t9112: add missing #!/bin/sh header
 + filter-branch: use $SHELL_PATH instead of 'sh'
 + filter-branch: don't use xargs -0
 + add NO_EXTERNAL_GREP build option
 + t6000lib: tr portability fix
 + t4020: don't use grep -a
 + add test_cmp function for test scripts
 + remove use of "tail -n 1" and "tail -1"
 + grep portability fix: don't use "-e" or "-q"
 + more tr portability test script fixes
 + t0050: perl portability fix
 + tr portability fixes

Initially triggered by Solaris porting effort but these are harmless
portability changes.  Perhaps in 1.5.5, perhaps immediately after that.

----------------------------------------------------------------
[Dropped]

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 . tests: convert "cmp" and "cmp -s" to test_cmp
 . tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

* nd/worktree (Sun Mar 2 17:35:43 2008 +0700) 10 commits
 . Additional tests to capture worktree special cases
 . Documentation: update api-builtin and api-setup
 . Make setup_git_directory() auto-setup worktree if found
 . builtin-archive: mark unused prefix "unused_prefix"
 . Completely move out worktree setup from
   setup_git_directory_gently()
 . http-push: Avoid calling setup_git_directory() twice
 . Make setup_work_tree() return new prefix
 . Make get_git_dir() and 'git rev-parse --git-dir' absolute path
 . Make sure setup_git_directory is called before accessing
   repository
 . "git read-tree -m" and the like require worktree

Every time we touch work-tree stuff we seem to have unstabilized things.
This is excluded from 'pu' for now although I still have copies.

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

* jc/unpack-careful (Fri Mar 7 08:39:53 2008 +0100) 5 commits
 + t5300: add test for "index-pack --strict"
 + receive-pack: allow using --strict mode for unpacking objects
 + unpack-objects: fix --strict handling
 + t5300: add test for "unpack-objects --strict"
 + unpack-objects: prevent writing of inconsistent objects

This would re-instate the "unpack-objects --strict" but we probably should
not do this before 1.5.5.

* jc/rename (Fri Mar 7 14:03:19 2008 -0800) 2 commits
 - diffcore-rename: make file_table available outside exact rename
   detection
 + Optimize rename detection for a huge diff

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 - diff: make --dirstat binary-file safe

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 - Teach GIT-VERSION-GEN about the .git file
 - Teach git-submodule.sh about the .git file
 - Teach resolve_gitlink_ref() about the .git file
 - Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  I am not sure if we should merge this to
'next' before 1.5.5.  Most active people will be on 'next' and
if we have this there, the resulting 1.5.5 release might end up
having issues that come from differences this one introduces.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 - sha1-lookup: make selection of 'middle' less aggressive
 - sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time 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

Just my toy at this moment.

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

[Samuel Tardieu]

I don't see your MIME/Content-Type fix in the list (adding the
required headers even in presence of user headers). Did I overlook
something?

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

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

[Junio C Hamano]

Samuel Tardieu <sam@rfc1149.net> writes:

> I don't see your MIME/Content-Type fix in the list (adding the
> required headers even in presence of user headers). Did I overlook
> something?

Do you mean 6bf4f1b (format-patch: generate MIME header as needed even
when there is format.header, 2008-03-14)?

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

[Samuel Tardieu]

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

Junio> Do you mean 6bf4f1b (format-patch: generate MIME header as
Junio> needed even when there is format.header, 2008-03-14)?

Yup. I hadn't seen it was in master and main already :)

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

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

[Steffen Prohaska]

On Sun, 23 Mar 2008, Junio C Hamano wrote:

> * lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
>  - Make git-add behave more sensibly in a case-insensitive
>    environment
>  - When adding files to the index, add support for case-independent
>    matches
>  - Make unpack-tree update removed files before any updated files
>  - Make branch merging aware of underlying case-insensitive
>    filsystems
>  - Add 'core.ignorecase' option
>  - Make hash_name_lookup able to do case-independent lookups
>  - Make "index_name_exists()" return the cache_entry it found
>  - Move name hashing functions into a file of its own
>  - Make unpack_trees_options bit flags actual bitfields
> 
> The beginning of ASCII-only case insensitive filesystem support.  It is
> not complete yet, though.  E.g. if you enable core.ignorecase in t0050,
> the merge test fails.

The merge test passes for me (on hfs+).  The "git mv" test still fails;
Linus made clear that "git mv" is not yet fixed.

            Steffen

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

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> The merge test passes for me (on hfs+).  The "git mv" test still fails;
> Linus made clear that "git mv" is not yet fixed.

I was actually talking about the case with your patch applied to t0050 on
case sensitive systems.

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

[Govind Salinas]

On Sun, Mar 23, 2008 at 5:08 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
>  * gs/pretty-hexval (Fri Mar 21 10:05:06 2008 -0500) 1 commit
>   + pretty.c: add %x00 format specifier.
>
>  Adds a generic "insert any byte value" to --pretty=format:<> specifier.
>
I also sent out the following patch that could be put in instead of or in
addition to this one.  The both solve my problem in different ways.

Thanks,
Govind.

---
From: Govind Salinas <blix@sophiasuchtig.com>
Date: Sun, 23 Mar 2008 16:02:11 -0500
Subject: [PATCH] log-tree.c:  Make log_tree_diff_flush() honor line_termination.

Signed-off-by: Govind Salinas <blix@sophiasuchtig.com>
---
 log-tree.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/log-tree.c b/log-tree.c
index 608f697..5f55683 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -338,7 +338,7 @@ int log_tree_diff_flush(struct rev_info *opt)
 			int pch = DIFF_FORMAT_DIFFSTAT | DIFF_FORMAT_PATCH;
 			if ((pch & opt->diffopt.output_format) == pch)
 				printf("---");
-			putchar('\n');
+			putchar(opt->diffopt.line_termination);
 		}
 	}
 	diff_flush(&opt->diffopt);
-- 
1.5.4.4.550.g77e21.dirty

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

[Junio C Hamano]

"Govind Salinas" <blix@sophiasuchtig.com> writes:

> I also sent out the following patch that could be put in instead of...

I had an impression that that change would break the existing output that
somebody other than you are depending on.

I personally think it is plausible that everybody wants the new behaviour
your patch propose, but that kind of change is not appropriate for 1.5.5
cycle (might be Ok for 1.6.0 after we see agreements on the list), and
definitely not something we would want to apply after -rc0.

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

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

* dd/cvsserver (Thu Mar 27 23:18:35 2008 +0100) 7 commits
 - cvsserver: Use the user part of the email in log and annotate
   results
 - cvsserver: Add test for update -p
 - cvsserver: Implement update -p (print to stdout)
 - cvsserver: Add a few tests for 'status' command
 - cvsserver: Do not include status output for subdirectories if -l
   is passed
 - cvsserver: Only print the file part of the filename in status
   header
 - cvsserver: Respond to the 'editors' and 'watchers' commands

The changes seem clean and should affect only locking related client
commands, so even though this is a new _feature_, I am inclined to merge
this in 1.5.5.  Testing by interested parties are encouraged.

* mb/prune (Mon Mar 24 23:20:51 2008 -0700) 4 commits
 + builtin-prune: protect objects listed on the command line
 + builtin-prune.c: use parse_options()
 + Add tests for git-prune
 + parse-options.c: introduce OPT_DATE

"git prune $this $that" lost its ability to protect $this and $that from
getting pruned when it was rewritten in C; this attempts to resurrect it.
This maybe is 1.5.5 material.

* jk/add-i-mode (Thu Mar 27 03:32:25 2008 -0400) 2 commits
 + add--interactive: allow user to choose mode update
 + add--interactive: ignore mode change in 'p'atch command

New feature, will probably be part of the release after 1.5.5

* gp/gitweb (Wed Mar 26 18:11:19 2008 +0000) 1 commit
 + gitweb: fallback to system-wide config file if default config does
   not exist

New feature, will probably be part of the release after 1.5.5

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

* gs/pretty-hexval (Fri Mar 21 10:05:06 2008 -0500) 1 commit
 + pretty.c: add %x00 format specifier.

Adds a generic "insert any byte value" to --pretty=format:<> specifier.
New feature, will probably be part of the release after 1.5.5

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

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this, but because I have met no real user with shared repository
workflow who complained on this issue, I think this is not urgent.

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

* fl/send-email-outside (Fri Mar 14 18:29:30 2008 +0100) 4 commits
 + send-email: Don't require to be called in a repository
 + Git.pm: Don't require repository instance for ident
 + Git.pm: Don't require a repository instance for config
 + var: Don't require to be in a git repository.

People couldn't invoke "git send-email" from outside their repositories,
but this series allows them to.  I do not think it is urgent, though.
This does not look risky, even though it touches Git.pm that is shared
with other things.  This has been cooking in 'next' for some time and we
haven't heard about breakages caused by this.  Will probably be the first
thing to be merged in 'master' post 1.5.5.

* jc/rebase (Sat Mar 15 13:17:42 2008 -0700) 1 commit
 + rebase [--onto O] A B: omit needless checkout

We used to "git checkout B && git rebase A" internally to implement this,
which meant the work tree was smudged one time too many.  This is probably
a safe optimization, but it case after -rc0 and is not really a must-have
fix.  One of the first after post 1.5.5.

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 - Make git-add behave more sensibly in a case-insensitive
   environment
 - When adding files to the index, add support for case-independent
   matches
 - Make unpack-tree update removed files before any updated files
 - Make branch merging aware of underlying case-insensitive
   filsystems
 - Add 'core.ignorecase' option
 - Make hash_name_lookup able to do case-independent lookups
 - Make "index_name_exists()" return the cache_entry it found
 - Move name hashing functions into a file of its own
 - Make unpack_trees_options bit flags actual bitfields

The beginning of ASCII-only case insensitive filesystem support.

* jc/unpack-careful (Fri Mar 7 08:39:53 2008 +0100) 5 commits
 + t5300: add test for "index-pack --strict"
 + receive-pack: allow using --strict mode for unpacking objects
 + unpack-objects: fix --strict handling
 + t5300: add test for "unpack-objects --strict"
 + unpack-objects: prevent writing of inconsistent objects

This would re-instate the "unpack-objects --strict" but we probably should
not do this before 1.5.5.

* jc/rename (Fri Mar 7 14:03:19 2008 -0800) 2 commits
 - diffcore-rename: make file_table available outside exact rename
   detection
 + Optimize rename detection for a huge diff

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 - diff: make --dirstat binary-file safe

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 - Teach GIT-VERSION-GEN about the .git file
 - Teach git-submodule.sh about the .git file
 - Teach resolve_gitlink_ref() about the .git file
 - Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  I am not sure if we should merge this to
'next' before 1.5.5.  Most active people will be on 'next' and
if we have this there, the resulting 1.5.5 release might end up
having issues that come from differences this one introduces.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 - sha1-lookup: make selection of 'middle' less aggressive
 - sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time 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

Just my toy at this moment.

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

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

* bc/mktag (Thu Mar 27 11:16:04 2008 -0500) 1 commit
 + mktag.c: improve verification of tagger field and tests

This is not very urgent but not complex nor risky enough to be worth
holding back.  Will merge before 1.5.5.

* je/cvsserver (Thu Mar 27 14:02:14 2008 -0700) 1 commit
 + Allow git-cvsserver database table name prefix to be specified.

The changes seem clean; even though this is a new _feature_, I am inclined
to merge this in 1.5.5.  Testing by interested parties are encouraged.

* bc/filter-branch (Wed Mar 26 10:47:09 2008 -0500) 1 commit
 - filter-branch.sh: support nearly proper tag name filtering

New feature, will probably be part of the release after 1.5.5

* js/filter-branch (Mon Mar 31 09:14:15 2008 +0200) 2 commits
 + filter-branch: Fix renaming a directory in the tree-filter
 + filter-branch: Test renaming directories in a tree-filter

Fix for 1.5.5; I ran out of time this weekend to merge this.

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

* mb/prune (Mon Mar 24 23:20:51 2008 -0700) 4 commits
 + builtin-prune: protect objects listed on the command line
 + builtin-prune.c: use parse_options()
 + Add tests for git-prune
 + parse-options.c: introduce OPT_DATE

"git prune $this $that" lost its ability to protect $this and $that from
getting pruned when it was rewritten in C; this attempts to resurrect it.
This maybe is 1.5.5 material.

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

* dd/cvsserver (Thu Mar 27 23:18:35 2008 +0100) 7 commits
 + cvsserver: Use the user part of the email in log and annotate
   results
 + cvsserver: Add test for update -p
 + cvsserver: Implement update -p (print to stdout)
 + cvsserver: Add a few tests for 'status' command
 + cvsserver: Do not include status output for subdirectories if -l
   is passed
 + cvsserver: Only print the file part of the filename in status
   header
 + cvsserver: Respond to the 'editors' and 'watchers' commands

The changes seem clean and should affect only locking related client
commands, so even though this is a new _feature_, I am inclined to merge
this in 1.5.5.  Testing by interested parties are encouraged.

* pb/cvsserver (Sun Mar 16 20:00:21 2008 +0100) 1 commit
 + git-cvsserver: handle change type T

This should be 1.5.5 material.

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

* jk/add-i-mode (Thu Mar 27 03:32:25 2008 -0400) 2 commits
 + add--interactive: allow user to choose mode update
 + add--interactive: ignore mode change in 'p'atch command

New feature, will probably be part of the release after 1.5.5

* gp/gitweb (Wed Mar 26 18:11:19 2008 +0000) 1 commit
 + gitweb: fallback to system-wide config file if default config does
   not exist

New feature, will probably be part of the release after 1.5.5

* gs/pretty-hexval (Fri Mar 21 10:05:06 2008 -0500) 1 commit
 + pretty.c: add %x00 format specifier.

Adds a generic "insert any byte value" to --pretty=format:<> specifier.
New feature, will probably be part of the release after 1.5.5

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

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this, but because I have met no real user with shared repository
workflow who complained on this issue, I think this is not urgent.

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

* fl/send-email-outside (Fri Mar 14 18:29:30 2008 +0100) 4 commits
 + send-email: Don't require to be called in a repository
 + Git.pm: Don't require repository instance for ident
 + Git.pm: Don't require a repository instance for config
 + var: Don't require to be in a git repository.

People couldn't invoke "git send-email" from outside their repositories,
but this series allows them to.  I do not think it is urgent, though.
This does not look risky, even though it touches Git.pm that is shared
with other things.  This has been cooking in 'next' for some time and we
haven't heard about breakages caused by this.  Will probably be the first
thing to be merged in 'master' post 1.5.5.

* jc/rebase (Sat Mar 15 13:17:42 2008 -0700) 1 commit
 + rebase [--onto O] A B: omit needless checkout

We used to "git checkout B && git rebase A" internally to implement this,
which meant the work tree was smudged one time too many.  This is probably
a safe optimization, but it case after -rc0 and is not really a must-have
fix.  One of the first after post 1.5.5.

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 - Make git-add behave more sensibly in a case-insensitive
   environment
 - When adding files to the index, add support for case-independent
   matches
 - Make unpack-tree update removed files before any updated files
 - Make branch merging aware of underlying case-insensitive
   filsystems
 - Add 'core.ignorecase' option
 - Make hash_name_lookup able to do case-independent lookups
 - Make "index_name_exists()" return the cache_entry it found
 - Move name hashing functions into a file of its own
 - Make unpack_trees_options bit flags actual bitfields

The beginning of ASCII-only case insensitive filesystem support.

* jc/unpack-careful (Fri Mar 7 08:39:53 2008 +0100) 5 commits
 + t5300: add test for "index-pack --strict"
 + receive-pack: allow using --strict mode for unpacking objects
 + unpack-objects: fix --strict handling
 + t5300: add test for "unpack-objects --strict"
 + unpack-objects: prevent writing of inconsistent objects

This would re-instate the "unpack-objects --strict" but we probably should
not do this before 1.5.5.

* jc/rename (Fri Mar 7 14:03:19 2008 -0800) 2 commits
 - diffcore-rename: make file_table available outside exact rename
   detection
 + Optimize rename detection for a huge diff

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 - diff: make --dirstat binary-file safe

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 - Teach GIT-VERSION-GEN about the .git file
 - Teach git-submodule.sh about the .git file
 - Teach resolve_gitlink_ref() about the .git file
 - Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  I am not sure if we should merge this to
'next' before 1.5.5.  Most active people will be on 'next' and
if we have this there, the resulting 1.5.5 release might end up
having issues that come from differences this one introduces.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 - sha1-lookup: make selection of 'middle' less aggressive
 - sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time 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

Just my toy at this moment.

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

With a handful topics graduated to "master", we hopefully will have the
final 1.5.5 soon.

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

* mv/defer-gc (Wed Apr 2 21:35:11 2008 +0200) 3 commits
 - contrib/hooks: add an example pre-auto-gc hook
 - Documentation/hooks: add pre-auto-gc hook
 - git-gc --auto: add pre-auto-gc hook

A new hook to stop "git gc --auto" from running.

* bc/filter-branch (Wed Mar 26 10:47:09 2008 -0500) 1 commit
 - filter-branch.sh: support nearly proper tag name filtering

New feature, will probably be part of the release after 1.5.5

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

* bc/mktag (Thu Mar 27 11:16:04 2008 -0500) 1 commit
 + mktag.c: improve verification of tagger field and tests

* je/cvsserver (Thu Mar 27 14:02:14 2008 -0700) 1 commit
 + Allow git-cvsserver database table name prefix to be specified.

* dd/cvsserver (Thu Mar 27 23:18:35 2008 +0100) 7 commits
 + cvsserver: Use the user part of the email in log and annotate
   results
 + cvsserver: Add test for update -p
 + cvsserver: Implement update -p (print to stdout)
 + cvsserver: Add a few tests for 'status' command
 + cvsserver: Do not include status output for subdirectories if -l
   is passed
 + cvsserver: Only print the file part of the filename in status
   header
 + cvsserver: Respond to the 'editors' and 'watchers' commands

* pb/cvsserver (Sun Mar 16 20:00:21 2008 +0100) 1 commit
 + git-cvsserver: handle change type T

* js/filter-branch (Mon Mar 31 09:14:15 2008 +0200) 2 commits
 + filter-branch: Fix renaming a directory in the tree-filter
 + filter-branch: Test renaming directories in a tree-filter

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

* jk/add-i-mode (Thu Mar 27 03:32:25 2008 -0400) 2 commits
 + add--interactive: allow user to choose mode update
 + add--interactive: ignore mode change in 'p'atch command

New feature, will probably be part of the release after 1.5.5

* gp/gitweb (Wed Mar 26 18:11:19 2008 +0000) 1 commit
 + gitweb: fallback to system-wide config file if default config does
   not exist

New feature, will probably be part of the release after 1.5.5

* gs/pretty-hexval (Fri Mar 21 10:05:06 2008 -0500) 1 commit
 + pretty.c: add %x00 format specifier.

Adds a generic "insert any byte value" to --pretty=format:<> specifier.
New feature, will probably be part of the release after 1.5.5

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

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this, but because I have met no real user with shared repository
workflow who complained on this issue, I think this is not urgent.

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

* fl/send-email-outside (Fri Mar 14 18:29:30 2008 +0100) 4 commits
 + send-email: Don't require to be called in a repository
 + Git.pm: Don't require repository instance for ident
 + Git.pm: Don't require a repository instance for config
 + var: Don't require to be in a git repository.

People couldn't invoke "git send-email" from outside their repositories,
but this series allows them to.  I do not think it is urgent, though.
This does not look risky, even though it touches Git.pm that is shared
with other things.  This has been cooking in 'next' for some time and we
haven't heard about breakages caused by this.  Will probably be the first
thing to be merged in 'master' post 1.5.5.

* jc/rebase (Sat Mar 15 13:17:42 2008 -0700) 1 commit
 + rebase [--onto O] A B: omit needless checkout

We used to "git checkout B && git rebase A" internally to implement this,
which meant the work tree was smudged one time too many.  This is probably
a safe optimization, but it case after -rc0 and is not really a must-have
fix.  One of the first after post 1.5.5.

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 - Make git-add behave more sensibly in a case-insensitive
   environment
 - When adding files to the index, add support for case-independent
   matches
 - Make unpack-tree update removed files before any updated files
 - Make branch merging aware of underlying case-insensitive
   filsystems
 - Add 'core.ignorecase' option
 - Make hash_name_lookup able to do case-independent lookups
 - Make "index_name_exists()" return the cache_entry it found
 - Move name hashing functions into a file of its own
 - Make unpack_trees_options bit flags actual bitfields

The beginning of ASCII-only case insensitive filesystem support.

* jc/unpack-careful (Fri Mar 7 08:39:53 2008 +0100) 5 commits
 + t5300: add test for "index-pack --strict"
 + receive-pack: allow using --strict mode for unpacking objects
 + unpack-objects: fix --strict handling
 + t5300: add test for "unpack-objects --strict"
 + unpack-objects: prevent writing of inconsistent objects

This would re-instate the "unpack-objects --strict" but we probably should
not do this before 1.5.5.

* jc/rename (Fri Mar 7 14:03:19 2008 -0800) 2 commits
 - diffcore-rename: make file_table available outside exact rename
   detection
 + Optimize rename detection for a huge diff

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 - diff: make --dirstat binary-file safe

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 - Teach GIT-VERSION-GEN about the .git file
 - Teach git-submodule.sh about the .git file
 - Teach resolve_gitlink_ref() about the .git file
 - Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 - sha1-lookup: make selection of 'middle' less aggressive
 - sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time 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

Just my toy at this moment.

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

[Kristian Høgsberg]

On Fri, 2008-04-04 at 11:24 -0700, Junio C Hamano wrote:
> Here are the topics that have been cooking.  Commits prefixed
> with '-' are only in 'pu' while commits prefixed with '+' are
> in 'next'.
> 
> The topics list the commits in reverse chronological order.
> 
> With a handful topics graduated to "master", we hopefully will have
> the
> final 1.5.5 soon.

What happened to builtin-clone?  I know I just threw it over the fence,
but Daniel picked it up and got it a lot closer to working?  Did it fall
through the cracks or is it just 1.5.6 material?

Kristian

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

[Junio C Hamano]

Kristian Høgsberg <krh@redhat.com> writes:

> On Fri, 2008-04-04 at 11:24 -0700, Junio C Hamano wrote:
>> Here are the topics that have been cooking.  Commits prefixed
>> with '-' are only in 'pu' while commits prefixed with '+' are
>> in 'next'.
>> 
>> The topics list the commits in reverse chronological order.
>> 
>> With a handful topics graduated to "master", we hopefully will have the
>> final 1.5.5 soon.
>
> What happened to builtin-clone?

Nothing.

> ... I know I just threw it over the fence,
> but Daniel picked it up and got it a lot closer to working?  Did it fall
> through the cracks or is it just 1.5.6 material?

If I recall correctly, "a lot closer to working" happened way after 1.5.5
merge window closed, so it definitely is not 1.5.5 material.

Judging from the fact that we recently had to deal with the fallouts of C
rewrites that happened during the 1.5.4 timeframe, I would have to say
that any C rewrite of a substantial and important program needs to be
cooked at least for one (or preferably two cycles, especially we are
trying to have shorter cycles) in 'next'.

So at this point, I optimistically say that it has a good chance of being
deeply in 'next' and all the active git people would hopefully be using
it, by the time 1.5.6 (or perhaps that is named 1.6.0, depending on what
else we will do) ships, but I cannot say much more than that.  It very
much depends on how hard the code has been scrutinized already at this
point; I haven't personally looked at it in any serious depth yet.

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

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1314 bytes --]

Hi,

On Fri, 4 Apr 2008, Junio C Hamano wrote:

> Kristian Høgsberg <krh@redhat.com> writes:
> 
> > ... I know I just threw it over the fence, but Daniel picked it up and 
> > got it a lot closer to working?  Did it fall through the cracks or is 
> > it just 1.5.6 material?
> 
> If I recall correctly, "a lot closer to working" happened way after 
> 1.5.5 merge window closed, so it definitely is not 1.5.5 material.
> 
> Judging from the fact that we recently had to deal with the fallouts of 
> C rewrites that happened during the 1.5.4 timeframe, I would have to say 
> that any C rewrite of a substantial and important program needs to be 
> cooked at least for one (or preferably two cycles, especially we are 
> trying to have shorter cycles) in 'next'.

That would mean that you'd have to merge it into 'next'.  And rather 
sooner than later, since everything else would lead to a dragging out of 
the timeline.

As it happens, until you called out the 'please test master' phase, I was 
running with builtin clone, and did not find it lacking.  Although I have 
to admit that I have some cleanups, and I haven't merged with Daniel in a 
long time.  And I do not do anything particularly fancy, such as shallow 
clone or shared clone.

Ciao,
Dscho "who hopes that the please-test-master phase is over soon"

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

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Fri, 4 Apr 2008, Junio C Hamano wrote:
>
>> Judging from the fact that we recently had to deal with the fallouts of 
>> C rewrites that happened during the 1.5.4 timeframe, I would have to say 
>> that any C rewrite of a substantial and important program needs to be 
>> cooked at least for one (or preferably two cycles, especially we are 
>> trying to have shorter cycles) in 'next'.
>
> That would mean that you'd have to merge it into 'next'.  And rather 
> sooner than later, since everything else would lead to a dragging out of 
> the timeline.

Yes, which means somebody needs to present a mergeable history rather
sooner than later, and that somebody does not have to be me ;-)

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

Caution. "next" has been rebuilt with the remaining topics on top of
"master".  "maint" is still for 1.5.4.X maintenance track for tonight.

A rough timeline from now on.

 * Brown paper back fixes, if any, for 1.5.5.1 (2008-04-16).

 * Discussion and review on new feature and enhancement patch series
   begins.  Please resubmit things that you were cooking in your head
   during 1.5.5-rc period after cleaning up and retesting.

 * 1.5.6 merge window closes (2008-05-14).

 * Fixes of 'master' continues; 1.5.6-rc0 gets tagged (2008-05-21).

 * 1.5.6 Final (2008-06-08).

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

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 6 commits
 - merge: remove deprecated summary and diffstat options and config
   variables
 - merge, pull: add '--(no-)log' command line option
 - fmt-merge-msg: add '--(no-)log' options and 'merge.log' config
   variable
 - add 'merge.stat' config variable
 - merge, pull: introduce '--(no-)stat' option
 - doc: moved merge.* config variables into separate merge-config.txt

I tried to fix its too-eager deprecation.  The last one needs re-review;
it should remove "these are still supported but will be removed" comments
that earlier ones add, and must be held back until 1.6.0 or later.

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 - git-blame --reverse
 - builtin-blame.c: allow more than 16 parents
 - builtin-blame.c: move prepare_final() into a separate function.
 - rev-list --children
 - revision traversal: --children option

The reverse blame I talked about earlier.

* jc/lstat (Sun Mar 30 12:39:25 2008 -0700) 3 commits
 - diff-files: mark an index entry we know is up-to-date as such
 - write_index(): optimize ce_smudge_racily_clean_entry() calls with
   CE_UPTODATE
 - lstat: introduce a wrapper xlstat

Further reduce redundant lstat(2) calls during "git status" and other
common operations.

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

* jc/rebase (Sat Mar 15 13:17:42 2008 -0700) 1 commit
 + rebase [--onto O] A B: omit needless checkout

We used to "git checkout B && git rebase A" internally to implement this,
which meant the work tree was smudged one time too many.

* gs/pretty-hexval (Fri Mar 21 10:05:06 2008 -0500) 1 commit
 + pretty.c: add %x00 format specifier.

Adds a generic "insert any byte value" to --pretty=format:<> specifier.

* jk/add-i-mode (Thu Mar 27 03:32:25 2008 -0400) 2 commits
 + add--interactive: allow user to choose mode update
 + add--interactive: ignore mode change in 'p'atch command

Allows mode change "pseudo hunk" to be staged separately.

NOTE NOTE NOTE!  It might be interesting to extend the idea of this patch
to treat "new file" as a pseudo hunk to record the much talked about
"intent to add".  That is, add a new command (or a new submode to patch
subcommand) that lets you add a file that is so far untracked, but only
with its mode and e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 which is the
blob object name for an _empty_ blob.  After such an operation is done,
"git diff" will show the new contents of the file you build in your work
tree that you _could_ commit with "git commit -a".

* fl/send-email-outside (Fri Mar 14 18:29:30 2008 +0100) 4 commits
 + send-email: Don't require to be called in a repository
 + Git.pm: Don't require repository instance for ident
 + Git.pm: Don't require a repository instance for config
 + var: Don't require to be in a git repository.

People couldn't invoke "git send-email" from outside their repositories,
but this series allows them to.

* mk/unpack-careful (Fri Mar 7 08:39:53 2008 +0100) 5 commits
 + t5300: add test for "index-pack --strict"
 + receive-pack: allow using --strict mode for unpacking objects
 + unpack-objects: fix --strict handling
 + t5300: add test for "unpack-objects --strict"
 + unpack-objects: prevent writing of inconsistent objects

This would re-instate the "unpack-objects --strict".

* gp/gitweb (Sat Apr 5 16:37:18 2008 +0000) 2 commits
 + gitweb: fallback to system-wide config file (fixup)
 + gitweb: fallback to system-wide config file if default config does
   not exist

* jc/rename (Fri Mar 7 14:03:19 2008 -0800) 1 commit
 + Optimize rename detection for a huge diff

This makes memory consumption of the rename detection operation for a huge
diff (that is, a change that touches many many files).  I've been running
with this for quite a while in my day-job repository without adverse
effects.

----------------------------------------------------------------
[Actively Cooking]

* mv/defer-gc (Wed Apr 2 21:35:11 2008 +0200) 3 commits
 + contrib/hooks: add an example pre-auto-gc hook
 + Documentation/hooks: add pre-auto-gc hook
 + git-gc --auto: add pre-auto-gc hook

A new hook to stop "git gc --auto" from running.

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

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.  There recently was a problem report that had a scent of this
issue which turned out to be a false alarm (it was about http-push which
does not do the native pack protocol optimization and the reporter was
pushing into an empty repository which needs full transfer anyway).

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 + diff: make --dirstat binary-file safe

The current "dirstat" does totally wrong thing when the set of files
changed includes a binary one.  This uses the same similarity evaluation
code as rename heuristics uses to treat text and binary the same way.

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 + Make git-add behave more sensibly in a case-insensitive
   environment
 + When adding files to the index, add support for case-independent
   matches
 + Make unpack-tree update removed files before any updated files
 + Make branch merging aware of underlying case-insensitive
   filsystems
 + Add 'core.ignorecase' option
 + Make hash_name_lookup able to do case-independent lookups
 + Make "index_name_exists()" return the cache_entry it found
 + Move name hashing functions into a file of its own
 + Make unpack_trees_options bit flags actual bitfields

The beginning of case insensitive filesystem support, currently
ASCII-only.

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 + Teach GIT-VERSION-GEN about the .git file
 + Teach git-submodule.sh about the .git file
 + Teach resolve_gitlink_ref() about the .git file
 + Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 + sha1-lookup: make selection of 'middle' less aggressive
 + sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven, so let's prove
it or revert it by giving it a bit more exposure.

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

Some of these will start moving to "next", some I may have to ask for
clean-up and resubmission for further discussion.  Also the topics raised
during the 1.5.5-rc freeze period should be rebased, cleaned-up and
resubmit for discussion and review for inclusion in 1.5.6.

* bc/filter-branch (Wed Mar 26 10:47:09 2008 -0500) 1 commit
 - filter-branch.sh: support nearly proper tag name filtering

Instead of discarding signed tags, this demotes them to simply annotated,
which is technically not that different from signed tags.

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

* jc/rename-file-table (Fri Mar 7 14:03:19 2008 -0800) 1 commit
 - diffcore-rename: make file_table available outside exact rename
   detection

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time 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

Just my toy at this moment.

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

Caution. "next" has been rebuilt with the remaining topics on top of
"master".

A rough timeline from now on.

 * Brown paper back fixes, if any, for 1.5.5.1 (2008-04-16).

 * Discussion and review on new feature and enhancement patch series
   begins.  Please resubmit things that you were cooking in your head
   during 1.5.5-rc period after cleaning up and retesting.

 * 1.5.6 merge window closes (2008-05-14).

 * Fixes of 'master' continues; 1.5.6-rc0 gets tagged (2008-05-21).

 * 1.5.6 Final (2008-06-08).

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

* mk/color (Wed Apr 9 21:32:06 2008 +0200) 1 commit
 + Use color.ui variable in scripts too

* jk/remote-default-show (Wed Apr 9 11:15:51 2008 -0400) 1 commit
 + git-remote: show all remotes with "git remote show"

* jc/terminator-separator (Mon Apr 7 17:11:34 2008 -0700) 1 commit
 + log: teach "terminator" vs "separator" mode to "--pretty=format"

* js/decorate (Mon Apr 7 14:41:12 2008 +0100) 2 commits
 - pretty=format: Add %d to show decoration
 - decorate: use "const struct object"

* jk/fetch-status (Wed Apr 9 20:11:52 2008 -0400) 1 commit
 + git-fetch: always show status of non-tracking-ref fetches

* py/submodule (Sat Apr 12 23:05:33 2008 +0800) 3 commits
 + builtin-status: Add tests for submodule summary
 + builtin-status: submodule summary support
 + git-submodule summary: --for-status option

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


----------------------------------------------------------------
[Actively Cooking]

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 6 commits
 - merge: remove deprecated summary and diffstat options and config
   variables
 + merge, pull: add '--(no-)log' command line option
 + fmt-merge-msg: add '--(no-)log' options and 'merge.log' config
   variable
 + add 'merge.stat' config variable
 + merge, pull: introduce '--(no-)stat' option
 + doc: moved merge.* config variables into separate merge-config.txt

I fixed its too-eager deprecation.  The last one needs to be held back, as
it actually removes the support for features that the main part of the
series deprecates, until 1.6.0 or later.

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.

* jc/lstat (Sun Mar 30 12:39:25 2008 -0700) 2 commits
 + diff-files: mark an index entry we know is up-to-date as such
 + write_index(): optimize ce_smudge_racily_clean_entry() calls with
   CE_UPTODATE

Further reduce redundant lstat(2) calls during "git status" and other
common operations.

* mv/defer-gc (Wed Apr 2 21:35:11 2008 +0200) 3 commits
 + contrib/hooks: add an example pre-auto-gc hook
 + Documentation/hooks: add pre-auto-gc hook
 + git-gc --auto: add pre-auto-gc hook

A new hook to stop "git gc --auto" from running.

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

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.  There recently was a problem report that had a scent of this
issue which turned out to be a false alarm (it was about http-push which
does not do the native pack protocol optimization and the reporter was
pushing into an empty repository which needs full transfer anyway).

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 + diff: make --dirstat binary-file safe

The current "dirstat" does totally wrong thing when the set of files
changed includes a binary one.  This uses the same similarity evaluation
code as rename heuristics uses to treat text and binary the same way.

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 + Make git-add behave more sensibly in a case-insensitive
   environment
 + When adding files to the index, add support for case-independent
   matches
 + Make unpack-tree update removed files before any updated files
 + Make branch merging aware of underlying case-insensitive
   filsystems
 + Add 'core.ignorecase' option
 + Make hash_name_lookup able to do case-independent lookups
 + Make "index_name_exists()" return the cache_entry it found
 + Move name hashing functions into a file of its own
 + Make unpack_trees_options bit flags actual bitfields

The beginning of case insensitive filesystem support, currently
ASCII-only.

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 + Teach GIT-VERSION-GEN about the .git file
 + Teach git-submodule.sh about the .git file
 + Teach resolve_gitlink_ref() about the .git file
 + Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 + sha1-lookup: make selection of 'middle' less aggressive
 + sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven, so let's prove
it or revert it by giving it a bit more exposure.

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

* bc/filter-branch (Wed Mar 26 10:47:09 2008 -0500) 1 commit
 - filter-branch.sh: support nearly proper tag name filtering

Instead of discarding signed tags, this demotes them to simply annotated,
which is technically not that different from signed tags.

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

* jc/rename-file-table (Fri Mar 7 14:03:19 2008 -0800) 1 commit
 - diffcore-rename: make file_table available outside exact rename
   detection

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time now.

* jc/lstat-debug (Thu Mar 27 16:56:53 2008 -0700) 3 commits
 - lstat: introduce a wrapper xlstat

* 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

Just my toy at this moment.

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

[Jeff King]

On Mon, Apr 14, 2008 at 12:00:50AM -0700, Junio C Hamano wrote:

> * jk/fetch-status (Wed Apr 9 20:11:52 2008 -0400) 1 commit
>  + git-fetch: always show status of non-tracking-ref fetches

I have been out of touch for a few days. My plan had been to come back
with a new version that suppressed the status on pull, but I haven't
seen anyone screaming about the change, so maybe it should just be left.

-Peff

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

Caution. "next" has been rebuilt with the remaining topics on top of
"master".

A rough timeline from now on.

 * 1.5.5.1 this Sunday, with what's in 'maint' tonight.

 * Discussion and review on new feature and enhancement patch series
   begins.  Please resubmit things that you were cooking in your head
   during 1.5.5-rc period after cleaning up and retesting.

 * 1.5.6 merge window closes (2008-05-14).

 * Fixes of 'master' continues; 1.5.6-rc0 gets tagged (2008-05-21).

 * 1.5.6 Final (2008-06-08).

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

* ho/shared (Wed Apr 16 11:34:24 2008 +0300) 1 commit
 + Make core.sharedRepository more generic

Looked Ok, and will start cooking soon.

* pb/remote-mirror-config (Thu Apr 17 13:17:20 2008 +0200) 1 commit
 - Add a remote.*.mirror configuration option

I haven't gave this very careful review yet.

* ap/svn (Tue Apr 15 21:04:18 2008 -0400) 3 commits
 - git-svn: add documentation for --add-author-from option.
 - git-svn: Add --add-author-from option.
 - git-svn: add documentation for --use-log-author option.

Eric requested a new set of tests for this series.

* lh/branch-merged (Fri Apr 18 18:30:15 2008 +0200) 3 commits
 - Add tests for `branch --[no-]merged`
 - git-branch.txt: compare --contains, --merged and --no-merged
 - git-branch: add support for --merged and --no-merged

Looked Ok, and will start cooking soon.

* py/submodule-2 (Wed Apr 16 22:19:31 2008 +0800) 1 commit
 - git-submodule: Extract functions module_info and module_url

I am a bit slow reviewing this series; only managed to queue the first one
so far.

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

----------------------------------------------------------------
[Actively Cooking]

* mk/color (Wed Apr 9 21:32:06 2008 +0200) 1 commit
 + Use color.ui variable in scripts too

* jk/remote-default-show (Wed Apr 9 11:15:51 2008 -0400) 1 commit
 + git-remote: show all remotes with "git remote show"

* jc/terminator-separator (Mon Apr 7 17:11:34 2008 -0700) 1 commit
 + log: teach "terminator" vs "separator" mode to "--pretty=format"

* jk/fetch-status (Wed Apr 9 20:11:52 2008 -0400) 1 commit
 + git-fetch: always show status of non-tracking-ref fetches

* py/submodule (Sat Apr 12 23:05:33 2008 +0800) 3 commits
 + builtin-status: Add tests for submodule summary
 + builtin-status: submodule summary support
 + git-submodule summary: --for-status option

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 6 commits
 - merge: remove deprecated summary and diffstat options and config
   variables
 + merge, pull: add '--(no-)log' command line option
 + fmt-merge-msg: add '--(no-)log' options and 'merge.log' config
   variable
 + add 'merge.stat' config variable
 + merge, pull: introduce '--(no-)stat' option
 + doc: moved merge.* config variables into separate merge-config.txt

I fixed its too-eager deprecation.  The last one needs to be held back, as
it actually removes the support for features that the main part of the
series deprecates, until 1.6.0 or later.

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.

* jc/lstat (Sun Mar 30 12:39:25 2008 -0700) 2 commits
 + diff-files: mark an index entry we know is up-to-date as such
 + write_index(): optimize ce_smudge_racily_clean_entry() calls with
   CE_UPTODATE

Further reduce redundant lstat(2) calls during "git status" and other
common operations.

* mv/defer-gc (Wed Apr 2 21:35:11 2008 +0200) 3 commits
 + contrib/hooks: add an example pre-auto-gc hook
 + Documentation/hooks: add pre-auto-gc hook
 + git-gc --auto: add pre-auto-gc hook

A new hook to stop "git gc --auto" from running.

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

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.  There recently was a problem report that had a scent of this
issue which turned out to be a false alarm (it was about http-push which
does not do the native pack protocol optimization and the reporter was
pushing into an empty repository which needs full transfer anyway).

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 + diff: make --dirstat binary-file safe

The current "dirstat" does totally wrong thing when the set of files
changed includes a binary one.  This uses the same similarity evaluation
code as rename heuristics uses to treat text and binary the same way.

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 + Make git-add behave more sensibly in a case-insensitive
   environment
 + When adding files to the index, add support for case-independent
   matches
 + Make unpack-tree update removed files before any updated files
 + Make branch merging aware of underlying case-insensitive
   filsystems
 + Add 'core.ignorecase' option
 + Make hash_name_lookup able to do case-independent lookups
 + Make "index_name_exists()" return the cache_entry it found
 + Move name hashing functions into a file of its own
 + Make unpack_trees_options bit flags actual bitfields

The beginning of case insensitive filesystem support, currently
ASCII-only.

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 + Teach GIT-VERSION-GEN about the .git file
 + Teach git-submodule.sh about the .git file
 + Teach resolve_gitlink_ref() about the .git file
 + Add platform-independent .git "symlink"

The idea and the implementation seem Ok, but this leaves
distinct feeling that it is a solution still waiting for a user
(e.g. "git submodule" enhancements to take advantage of this
facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was
bound to the superproject).

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 + sha1-lookup: make selection of 'middle' less aggressive
 + sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven, so let's prove
it or revert it by giving it a bit more exposure.

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

* js/decorate (Mon Apr 7 14:41:12 2008 +0100) 2 commits
 - pretty=format: Add %d to show decoration
 - decorate: use "const struct object"

This has stalled, after a petered-out discussion.

* bc/filter-branch (Wed Mar 26 10:47:09 2008 -0500) 1 commit
 - filter-branch.sh: support nearly proper tag name filtering

Instead of discarding signed tags, this demotes them to simply annotated,
which is technically not that different from signed tags.  There was an
objection if what this claims to do is the right thing to do to begin
with.  Also I haven't verified if it does what it claims to do.

Comments?

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

* jc/rename-file-table (Fri Mar 7 14:03:19 2008 -0800) 1 commit
 - diffcore-rename: make file_table available outside exact rename
   detection

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time now.

* jc/lstat-debug (Thu Mar 27 16:56:53 2008 -0700) 3 commits
 - lstat: introduce a wrapper xlstat

* 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

Just my toy at this moment.

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

[Johannes Schindelin]

Hi,

On Sat, 19 Apr 2008, Junio C Hamano wrote:

> ----------------------------------------------------------------
> [On Hold]
> 
> * js/decorate (Mon Apr 7 14:41:12 2008 +0100) 2 commits
>  - pretty=format: Add %d to show decoration
>  - decorate: use "const struct object"
> 
> This has stalled, after a petered-out discussion.

I am not personally interested, but I thought that it was easy enough to 
do.  So let's just scrap it, the mailing list has it should anybody need 
it in the future.

Ciao,
Dscho

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

[Lars Hjemli]

On Sat, Apr 19, 2008 at 10:19 AM, Junio C Hamano <gitster@pobox.com> wrote:
>  * lh/branch-merged (Fri Apr 18 18:30:15 2008 +0200) 3 commits
>   - Add tests for `branch --[no-]merged`
>   - git-branch.txt: compare --contains, --merged and --no-merged
>   - git-branch: add support for --merged and --no-merged

I notice that you moved the test script into t3201 while still adding
t3202, which probably wasn't your intent.

Would you like me to resend the patches with your fixups to tests and
docs (and maybe even squash them into a single patch)?

--
larsh

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

[Junio C Hamano]

"Lars Hjemli" <hjemli@gmail.com> writes:

> On Sat, Apr 19, 2008 at 10:19 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>  * lh/branch-merged (Fri Apr 18 18:30:15 2008 +0200) 3 commits
>>   - Add tests for `branch --[no-]merged`
>>   - git-branch.txt: compare --contains, --merged and --no-merged
>>   - git-branch: add support for --merged and --no-merged
>
> I notice that you moved the test script into t3201 while still adding
> t3202, which probably wasn't your intent.
>
> Would you like me to resend the patches with your fixups to tests and
> docs (and maybe even squash them into a single patch)?

Thanks, but it's easy enough for me to amend the tip of lh/branch-merged
to drop t3202 and that should be sufficient.

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

[Brandon Casey]

Junio C Hamano wrote:

> * bc/filter-branch (Wed Mar 26 10:47:09 2008 -0500) 1 commit
>  - filter-branch.sh: support nearly proper tag name filtering
> 
> Instead of discarding signed tags, this demotes them to simply annotated,
> which is technically not that different from signed tags.

I just want to point out that this patch is not exclusively about signed
tags.

The patch is about retaining annotated tags rather than demoting them to
light-weight tag references as is done currently for _all_ annotated tags,
signed and unsigned. When rewriting signed tags, the signature is stripped
so that we don't write a tag with a bogus signature.

-brandon

What's cooking in git.git (topics)

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

Note.

    Some commits on 'pu' have [comment] in front of their title, primarily
    to remind myself not to accidentally merge them to 'next' before
    issues are resolved.  They will be amended either by replacement patch
    from the author, or when the issue raised on the list gets refuted
    convincingly enough to justify the original patch (in which case only
    the comment like "[questionable???]"  will be removed without changing
    the tree of the commit).

The topics list the commits in reverse chronological order.

A rough timeline from now on.

 * Discussion and review on new feature and enhancement patch series
   begins.  Please resubmit things that you were cooking in your head
   during 1.5.5-rc period after cleaning up and retesting.

 * 1.5.6 merge window closes (2008-05-14).

 * Fixes of 'master' continues; 1.5.6-rc0 gets tagged (2008-05-21).

 * 1.5.6 Final (2008-06-08).

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

* js/rebase-i-sequencer (Mon Apr 14 02:21:09 2008 +0200) 13 commits
 + Add option --preserve-tags
 + Teach rebase interactive the tag command
 + Add option --first-parent
 + Do rebase with preserve merges with advanced TODO list
 + Select all lines with fake-editor
 + Unify the length of $SHORT* and the commits in the TODO list
 + Teach rebase interactive the merge command
 + Move redo merge code in a function
 + Teach rebase interactive the reset command
 + Teach rebase interactive the mark command
 + Move cleanup code into it's own function
 + Don't append default merge message to -m message
 + fake-editor: output TODO list if unchanged

This may complement the proposed "sequencer" GSoC project.

* db/clone-in-c (Thu Apr 17 19:32:43 2008 -0400) 8 commits
 - [mess] Build in clone
 - [strdup() and other clean-ups needed] Provide API access to
   init_db()
 - [waiting for response] Add a function to set a non-default work
   tree
 - Allow for having for_each_ref() list extra refs
 - Have a constant extern refspec for "--tags"
 - Add a library function to add an alternate to the alternates file
 - Add a lockfile function to append to a file
 - Mark the list of refs to fetch as const

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

* mk/color (Wed Apr 9 21:32:06 2008 +0200) 1 commit
 + Use color.ui variable in scripts too

* jk/remote-default-show (Wed Apr 9 11:15:51 2008 -0400) 1 commit
 + git-remote: show all remotes with "git remote show"

* jc/terminator-separator (Mon Apr 7 17:11:34 2008 -0700) 1 commit
 + log: teach "terminator" vs "separator" mode to "--pretty=format"

* py/submodule (Sat Apr 12 23:05:33 2008 +0800) 3 commits
 + builtin-status: Add tests for submodule summary
 + builtin-status: submodule summary support
 + git-submodule summary: --for-status option

* mv/defer-gc (Wed Apr 2 21:35:11 2008 +0200) 3 commits
 + contrib/hooks: add an example pre-auto-gc hook
 + Documentation/hooks: add pre-auto-gc hook
 + git-gc --auto: add pre-auto-gc hook

A new hook to stop "git gc --auto" from running.

* jc/dirstat (Tue Feb 12 17:06:58 2008 -0800) 1 commit
 + diff: make --dirstat binary-file safe

The current "dirstat" does totally wrong thing when the set of files
changed includes a binary one.  This uses the same similarity evaluation
code as rename heuristics uses to treat text and binary the same way.

* jc/sha1-lookup (Sun Dec 30 03:13:27 2007 -0800) 2 commits
 + sha1-lookup: make selection of 'middle' less aggressive
 + sha1-lookup: more memory efficient search in sorted list of SHA-1

Micro-optimization whose real world benefit is not proven, so let's prove
it or revert it by giving it a bit more exposure.

----------------------------------------------------------------
[Actively Cooking]

* pb/remote-mirror-config (Thu Apr 17 13:17:20 2008 +0200) 1 commit
 + Add a remote.*.mirror configuration option

* ho/shared (Wed Apr 16 11:34:24 2008 +0300) 1 commit
 + Make core.sharedRepository more generic

* lh/branch-merged (Fri Apr 18 18:30:15 2008 +0200) 3 commits
 + Add tests for `branch --[no-]merged`
 + git-branch.txt: compare --contains, --merged and --no-merged
 + git-branch: add support for --merged and --no-merged

* jk/fetch-status (Wed Apr 9 20:11:52 2008 -0400) 1 commit
 + git-fetch: always show status of non-tracking-ref fetches

This changes reporting behaviour of one-shot "git pull $url $branch",
which would affect long-time users in integrator role (that's you, Linus
;-).  Let's see if we hear anybody screaming.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 6 commits
 - merge: remove deprecated summary and diffstat options and config
   variables
 + merge, pull: add '--(no-)log' command line option
 + fmt-merge-msg: add '--(no-)log' options and 'merge.log' config
   variable
 + add 'merge.stat' config variable
 + merge, pull: introduce '--(no-)stat' option
 + doc: moved merge.* config variables into separate merge-config.txt

The last one needs to be held back, as it actually removes the support for
features that the main part of the series deprecates, until 1.6.0 or
later.

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.

* jc/lstat (Sun Mar 30 12:39:25 2008 -0700) 2 commits
 + diff-files: mark an index entry we know is up-to-date as such
 + write_index(): optimize ce_smudge_racily_clean_entry() calls with
   CE_UPTODATE

Further reduce redundant lstat(2) calls during "git status" and other
common operations.

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

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.  There recently was a problem report that had a scent of this
issue which turned out to be a false alarm (it was about http-push which
does not do the native pack protocol optimization and the reporter was
pushing into an empty repository which needs full transfer anyway).

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 + Make git-add behave more sensibly in a case-insensitive
   environment
 + When adding files to the index, add support for case-independent
   matches
 + Make unpack-tree update removed files before any updated files
 + Make branch merging aware of underlying case-insensitive
   filsystems
 + Add 'core.ignorecase' option
 + Make hash_name_lookup able to do case-independent lookups
 + Make "index_name_exists()" return the cache_entry it found
 + Move name hashing functions into a file of its own
 + Make unpack_trees_options bit flags actual bitfields

The beginning of case insensitive filesystem support, currently
ASCII-only.

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 + Teach GIT-VERSION-GEN about the .git file
 + Teach git-submodule.sh about the .git file
 + Teach resolve_gitlink_ref() about the .git file
 + Add platform-independent .git "symlink"

There was a GSoC project idea to enhance "git submodule" to take advantage
of this facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was bound to
the superproject, but it appears nobody took it.

* bc/filter-branch (Wed Mar 26 10:47:09 2008 -0500) 1 commit
 + filter-branch.sh: support nearly proper tag name filtering

Instead of discarding annotated and/or signed tags, this keeps them and
demotes the signed ones to simply annotated.  It issues warning when it
does this demotion.  I think the behaviour is sensible.

----------------------------------------------------------------
[Dropped]

* js/decorate (Mon Apr 7 14:41:12 2008 +0100) 2 commits
 . pretty=format: Add %d to show decoration
 . decorate: use "const struct object"

Per author's lack of interest

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

* ap/svn (Tue Apr 15 21:04:18 2008 -0400) 3 commits
 - git-svn: add documentation for --add-author-from option.
 - git-svn: Add --add-author-from option.
 - git-svn: add documentation for --use-log-author option.

Eric requested a new set of tests for this series.

* py/submodule-2 (Wed Apr 16 22:19:31 2008 +0800) 1 commit
 - git-submodule: Extract functions module_info and module_url

I only managed to queue the first one so far.

It does not help motivating me reviewing the series that the overall tone
of it is to ignore .git/config more and make .gitmodules take more active
role, either.  I have already said number of times why that is not a good
idea and why it is against the overall submodule design.

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time now.

* jc/lstat-debug (Thu Mar 27 16:56:53 2008 -0700) 1 commit
 - lstat: introduce a wrapper xlstat

* 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

Just my toy at this moment.

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

[Ping Yin]

On Tue, Apr 22, 2008 at 6:03 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Here are the topics that have been cooking.  Commits prefixed
>  with '-' are only in 'pu' while commits prefixed with '+' are
>  in 'next'.
>

>
> * py/submodule-2 (Wed Apr 16 22:19:31 2008 +0800) 1 commit
>   - git-submodule: Extract functions module_info and module_url
>
>
> I only managed to queue the first one so far.
>
>  It does not help motivating me reviewing the series that the overall tone
>  of it is to ignore .git/config more and make .gitmodules take more active
>  role, either.  I have already said number of times why that is not a good
>  idea and why it is against the overall submodule design.

I summarize junio's points that says $GIT_DIR/config is authoritative.

1. .gitmodules shouldn't be authoritative and should be just a hint
   to fill $GIT_DIR/config because

   a) url may be rewritten with different protocol, such as from
     "http://" to "git://"
   b) url may be total different between .gitmodules and
      $GIT_DIR/config

2. When going back to an old HEAD of super project and do
   "git submodule update", the url recorded in .gitmodules may be
   stale or not existent anymore, so we should refer to
   $GIT_DIR/config for the right url.

3. We can record what contents we've seen in the .gitmodules, so that
   we can give users a chance to adjust what is in $GIT_DIR/config
   when we notice the entry in .gitmodules has changed.

Any others?

However, i argue the fall back strategy (say fall back to .gitmodules
when we can't find an entries in $GIT_DIR/config) doesn't break the
authority and isn't in contrast with the cases above. It just attachs
more importance to .gitmodules and can make the world better in most
cases.

For 1.a, i think we can keep these entries in .gitmodules, and use
"url.<thisurl>.insteadof = <otherurl>" to override the urls.

For 1.b, i think this is a rare case. And we can override these urls
in $GIT_DIR/config. However, in many cases, we havn't to do that.

For 2, i think it is also a rare case. And before going back, we can
override the urls in $GIT_DIR/config.

For 3, i havn't found a good way to do that. And it doesn't conflict
with the fall back strategy (say, wh

So, my conclusion

* 1.b, 2 and 3 are all rare cases, and these cases don't conflict with
  the fall back strategy

* 1.a is a usual case, and fallback + 'url insteadOf" will make things
  better

* The most common case is that most (even all) entries in .gitmodules
  are the same as entires in $GIT_DIR/config. So with fallback, we
  don't have to copy entries from .gitmodules to $GIT_DIR/config.

* And, in a central environment, i think it's common that the super
  project and sub project use the same protocol. So if we use relative
  urls in .gitmodules, when changing the url protocol the super
  project, the urls in .gitmodules needn't change and can be
  dynamically expanded with the url of the super project (Of course,
  after applying the 2nd patch of this series)


-- 
Ping Yin

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

[Josef Weidendorfer]

On Tuesday 22 April 2008, Ping Yin wrote:
> On Tue, Apr 22, 2008 at 6:03 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >  It does not help motivating me reviewing the series that the overall tone
> >  of it is to ignore .git/config more and make .gitmodules take more active
> >  role, either.  I have already said number of times why that is not a good
> >  idea and why it is against the overall submodule design.
> 
> I summarize junio's points that says $GIT_DIR/config is authoritative.
>
> [...]
> 
> Any others?

A reason you did not mention is security:
You never want your .git/config to be changed behind your back, which
effectivly is the case when using the versioned .gitmodules information
(similar problem as with a .gitconfig in-tree).

Another one:
From a design point of view, submodule URLs are project meta information
unrelated to source history. So, actually, I think it was wrong to put
submodule URLs (even hints only) into the versioned .gitmodules files (*).

The main reason for .gitmodules is to store submodule information which
has to be in sync with commits, such as a submodule name related to some
path where the submodule happens to be checked out in a given commit, and
also related to some config entry holding the URL to allow for fetch/pull.
The idea is that submodules have an identity in the supermodule (in contrast
to files in git), such that related configuration keeps valid when moving
submodules around. This needs simultanous adjusting the path attribute in
.gitmodules when a submodule is moved.

Josef

(*) IMHO, it would be far better if such project meta/policy information could
be in its own history (e.g. branch "gitconfig" to allow for easy propagation
at clone/fetch time). However, any such configuration should need
explicit interaction by the user to take over project config into the
local git config (e.g. via a "git config merge gitconfig:config" after
inspecting via "git show gitconfig:config").

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

[Ping Yin]

On Tue, Apr 22, 2008 at 10:55 PM, Josef Weidendorfer
<Josef.Weidendorfer@gmx.de> wrote:
> On Tuesday 22 April 2008, Ping Yin wrote:
>  > On Tue, Apr 22, 2008 at 6:03 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> > >  It does not help motivating me reviewing the series that the overall tone
>  > >  of it is to ignore .git/config more and make .gitmodules take more active
>  > >  role, either.  I have already said number of times why that is not a good
>  > >  idea and why it is against the overall submodule design.
>  >
>  > I summarize junio's points that says $GIT_DIR/config is authoritative.
>  >
>  > [...]
>  >
>  > Any others?
>
>  A reason you did not mention is security:
>  You never want your .git/config to be changed behind your back, which
>  effectivly is the case when using the versioned .gitmodules information
>  (similar problem as with a .gitconfig in-tree).

As discussed in another thread about in-tree .gitconfig, security
issues only arise on limited configuration entries. However, there are
no entries in .gitmodules falling into any of these entries.

>
>  Another one:
>  From a design point of view, submodule URLs are project meta information
>  unrelated to source history. So, actually, I think it was wrong to put
>  submodule URLs (even hints only) into the versioned .gitmodules files (*).

But now it actually acts as hints and we don't find a better way. I
just propose that the hints become the good default.

>
>  The main reason for .gitmodules is to store submodule information which
>  has to be in sync with commits, such as a submodule name related to some
>  path where the submodule happens to be checked out in a given commit, and
>  also related to some config entry holding the URL to allow for fetch/pull.
>  The idea is that submodules have an identity in the supermodule (in contrast
>  to files in git), such that related configuration keeps valid when moving
>  submodules around. This needs simultanous adjusting the path attribute in
>  .gitmodules when a submodule is moved.

If we go back to a old HEAD or switch to another branch with changed
path for a submodule,  what should 'git submodule update' do?
I think entries in .gitmodules should take precedence.

So url in $GIT_DIR/config is authoritative, and path in .gitmodules is
authoritative.




-- 
Ping Yin

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

[Johannes Schindelin]

Hi,

On Wed, 23 Apr 2008, Ping Yin wrote:

> If we go back to a old HEAD or switch to another branch with changed 
> path for a submodule, what should 'git submodule update' do? I think 
> entries in .gitmodules should take precedence.

Literally the most common reason for a _different_ .gitmodules in an older 
revision is that the repository was moved to another machine.

In this case, your suggestion is actively wrong.

Ciao,
Dscho

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

[Ping Yin]

On Wed, Apr 23, 2008 at 1:28 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
>
>  On Wed, 23 Apr 2008, Ping Yin wrote:
>
>  > If we go back to a old HEAD or switch to another branch with changed
>  > path for a submodule, what should 'git submodule update' do? I think
>  > entries in .gitmodules should take precedence.
>
>  Literally the most common reason for a _different_ .gitmodules in an older
>  revision is that the repository was moved to another machine.
>
>  In this case, your suggestion is actively wrong.
>
Another common reason is the adjustment of repository directory in the
central environment
so i said *path*, not *url*. I agree what Josef said in the the
following reply: "It makes no sense to have submodule path
configuration in .git/config, as it has to be in sync with the current
commit". So it should be bettter to store path info only in
.gitmodules instead of $GIT_DIR/config


-- 
Ping Yin

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

[Ping Yin]

On Wed, Apr 23, 2008 at 9:27 AM, Ping Yin <pkufranky@gmail.com> wrote:
>
> On Wed, Apr 23, 2008 at 1:28 AM, Johannes Schindelin
>  <Johannes.Schindelin@gmx.de> wrote:
>  > Hi,
>  >
>  >
>  >  On Wed, 23 Apr 2008, Ping Yin wrote:
>  >
>  >  > If we go back to a old HEAD or switch to another branch with changed
>  >  > path for a submodule, what should 'git submodule update' do? I think
>  >  > entries in .gitmodules should take precedence.
>  >
>  >  Literally the most common reason for a _different_ .gitmodules in an older
>  >  revision is that the repository was moved to another machine.
>  >
>  >  In this case, your suggestion is actively wrong.
>  >
>  Another common reason is the adjustment of repository directory in the
>  central environment

I'm wrong, this is the case that  *url* changes.

>  so i said *path*, not *url*. I agree what Josef said in the the
>  following reply: "It makes no sense to have submodule path
>  configuration in .git/config, as it has to be in sync with the current
>  commit". So it should be bettter to store path info only in
>  .gitmodules instead of $GIT_DIR/config
>

The case that *path* changes is the submodule is moved to a new path
in some commit. But it is a very rare case.


-- 
Ping Yin

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

[Josef Weidendorfer]

On Tuesday 22 April 2008, Ping Yin wrote:
> >  A reason you did not mention is security:
> >  You never want your .git/config to be changed behind your back, which
> >  effectivly is the case when using the versioned .gitmodules information
> >  (similar problem as with a .gitconfig in-tree).
> 
> As discussed in another thread about in-tree .gitconfig, security
> issues only arise on limited configuration entries. However, there are
> no entries in .gitmodules falling into any of these entries.

Hmm... At least, it can be very annoying when git fetches data from repositories
you did not expect, only because submodule URLs change via this
fallback mechanism. Perhaps it is a little far reached, but suppose a project
changes its URL, and the old one becomes occupied by a malicious person.
The problem is that the URL with the now malicious repository is bound in the
history of the project. For sure, you do not want to fetch from that old repository
by accident, after you did a checkout of an old commit. And there would be no
way to protect other people from this malicious repository other than rewriting
the whole history.

> >  Another one:
> >  From a design point of view, submodule URLs are project meta information
> >  unrelated to source history. So, actually, I think it was wrong to put
> >  submodule URLs (even hints only) into the versioned .gitmodules files (*).
> 
> But now it actually acts as hints and we don't find a better way. I
> just propose that the hints become the good default.

For me this sounds like: Now that we have made this bad decision, it does
not matter to make it even worse.

What was the motivation for this fallback mechanism?

In any way, it is preferable to always use the correct URL for submodules.
Thus, when the URL ever changes in the projects livetime (covered by
git history), you want to have the correct URL in your .git/config
(not to accidently use the wrong URL when checking out an old commit).
But then, the fallback mechanism does not trigger anyway.

> >  The main reason for .gitmodules is to store submodule information which
> >  has to be in sync with commits, such as a submodule name related to some
> >  path where the submodule happens to be checked out in a given commit, and
> >  also related to some config entry holding the URL to allow for fetch/pull.
> >  The idea is that submodules have an identity in the supermodule (in contrast
> >  to files in git), such that related configuration keeps valid when moving
> >  submodules around. This needs simultanous adjusting the path attribute in
> >  .gitmodules when a submodule is moved.
> 
> If we go back to a old HEAD or switch to another branch with changed
> path for a submodule,  what should 'git submodule update' do?
> I think entries in .gitmodules should take precedence.

Of course. It makes no sense to have submodule path configuration in .git/config,
as it has to be in sync with the current commit. That has nothing to do with
precedence. The same is true for .gitattributes, for example.

> So url in $GIT_DIR/config is authoritative, and path in .gitmodules is
> authoritative.

No.
These are totally different types of configurations.

Josef

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

[Ping Yin]

On Wed, Apr 23, 2008 at 2:07 AM, Josef Weidendorfer
<Josef.Weidendorfer@gmx.de> wrote:
> On Tuesday 22 April 2008, Ping Yin wrote:
>
> > >  A reason you did not mention is security:
>  > >  You never want your .git/config to be changed behind your back, which
>  > >  effectivly is the case when using the versioned .gitmodules information
>  > >  (similar problem as with a .gitconfig in-tree).
>  >
>  > As discussed in another thread about in-tree .gitconfig, security
>  > issues only arise on limited configuration entries. However, there are
>  > no entries in .gitmodules falling into any of these entries.
>
>  Hmm... At least, it can be very annoying when git fetches data from repositories
>  you did not expect, only because submodule URLs change via this
>  fallback mechanism. Perhaps it is a little far reached, but suppose a project
>  changes its URL, and the old one becomes occupied by a malicious person.
>  The problem is that the URL with the now malicious repository is bound in the
>  history of the project.

It is always bound now without the fallback patch :)

>  For sure, you do not want to fetch from that old repository
>  by accident, after you did a checkout of an old commit. And there would be no
>  way to protect other people from this malicious repository other than rewriting
>  the whole history.

I wonder how the *malicious* repository can hurt us since only the
commit recorded in commit of the super project will be checked out.

>
>
>  > >  Another one:
>  > >  From a design point of view, submodule URLs are project meta information
>  > >  unrelated to source history. So, actually, I think it was wrong to put
>  > >  submodule URLs (even hints only) into the versioned .gitmodules files (*).
>  >
>  > But now it actually acts as hints and we don't find a better way. I
>  > just propose that the hints become the good default.
>
>  For me this sounds like: Now that we have made this bad decision, it does
>  not matter to make it even worse.

I should be like: Now that we have made a bad decision (if it is), we
have to improve it to make life better before we can find a better
solution.

>
>  What was the motivation for this fallback mechanism?
>
>  In any way, it is preferable to always use the correct URL for submodules.
>  Thus, when the URL ever changes in the projects livetime (covered by
>  git history), you want to have the correct URL in your .git/config
>  (not to accidently use the wrong URL when checking out an old commit).
>  But then, the fallback mechanism does not trigger anyway.

I havn't found yet how an incorrect URL can hurt us. The worst case i
can imagine is the failure of "git submodule update".

Two of the most common cases which can result in an incorrect/stale url is

 * the repository has been moved to another machine
 * the directory structure of upstream repositories has changed

However, there are also cases that the old version of url in
.gitmodules is correct.

Think about the case that the reposotory maintainer has decided to
replace current submodule with a totoally different one. In this case,
when back to the old HEAD, the url in .gitmodules is correct while url
in $GIT_DIR/config is incorrect.

So, when error happens, we can't judge which url is correct. So just
let the user make the decision by refering the change history of
.gitmodules or asking the repository maintainer.


-- 
Ping Yin

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

[Fedor Sergeev]

On Wed, 23 Apr 2008, Ping Yin wrote:
> On Wed, Apr 23, 2008 at 2:07 AM, Josef Weidendorfer
>>  Hmm... At least, it can be very annoying when git fetches data from repositories
>>  you did not expect, only because submodule URLs change via this
>>  fallback mechanism. Perhaps it is a little far reached, but suppose a project
>>  changes its URL, and the old one becomes occupied by a malicious person.
>>  The problem is that the URL with the now malicious repository is bound in the
>>  history of the project.
>
> It is always bound now without the fallback patch :)
>
>>  For sure, you do not want to fetch from that old repository
>>  by accident, after you did a checkout of an old commit. And there would be no
>>  way to protect other people from this malicious repository other than rewriting
>>  the whole history.
>
> I wonder how the *malicious* repository can hurt us since only the
> commit recorded in commit of the super project will be checked out.

If one manages to hack on repository one can modify it enormous amount of 
ways, including spoofing on SHA (providing wrong contents for it - does 
git verify that when getting a pack?), utilizing bugs in git etc...

I doubt somebody would spend that much of an effort but you know,
you can not be paranoid *enough* :)

regards,
   Fedor.

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

[Ping Yin]

On Wed, Apr 23, 2008 at 3:47 PM, Fedor Sergeev <Fedor.Sergeev@sun.com> wrote:
> On Wed, 23 Apr 2008, Ping Yin wrote:
>
> >
> > On Wed, Apr 23, 2008 at 2:07 AM, Josef Weidendorfer
> >
> >
> > >  Hmm... At least, it can be very annoying when git fetches data from
> repositories
> > >  you did not expect, only because submodule URLs change via this
> > >  fallback mechanism. Perhaps it is a little far reached, but suppose a
> project
> > >  changes its URL, and the old one becomes occupied by a malicious
> person.
> > >  The problem is that the URL with the now malicious repository is bound
> in the
> > >  history of the project.
> > >
> >
> > It is always bound now without the fallback patch :)
> >
> >
> > >  For sure, you do not want to fetch from that old repository
> > >  by accident, after you did a checkout of an old commit. And there would
> be no
> > >  way to protect other people from this malicious repository other than
> rewriting
> > >  the whole history.
> > >
> >
> > I wonder how the *malicious* repository can hurt us since only the
> > commit recorded in commit of the super project will be checked out.
> >
>
>  If one manages to hack on repository one can modify it enormous amount of
> ways, including spoofing on SHA (providing wrong contents for it - does git
> verify that when getting a pack?), utilizing bugs in git etc...

Doable? I dunno.



-- 
Ping Yin

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

[Robin Rosenberg]

onsdagen den 23 april 2008 09.47.57 skrev Fedor Sergeev:
> If one manages to hack on repository one can modify it enormous amount of
> ways, including spoofing on SHA (providing wrong contents for it - does
> git verify that when getting a pack?), utilizing bugs in git etc...

The pack transfer protocol does not transfer the SHA of objects, only the 
contents is transferred. The SHA-1 is (has to be since it is not sent) 
reconstructed on the receiving end.

-- robin

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

[Fedor Sergeev]

On Wed, 23 Apr 2008, Robin Rosenberg wrote:

> onsdagen den 23 april 2008 09.47.57 skrev Fedor Sergeev:
>> If one manages to hack on repository one can modify it enormous amount of
>> ways, including spoofing on SHA (providing wrong contents for it - does
>> git verify that when getting a pack?), utilizing bugs in git etc...
>
> The pack transfer protocol does not transfer the SHA of objects, only the
> contents is transferred. The SHA-1 is (has to be since it is not sent)
> reconstructed on the receiving end.

Thats nice. Then I agree its difficult to spoil superproject out of 
submodule other than it just does not checkout.

regards,
   Fedor.

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

[Michele Ballabio]

On Tuesday 22 April 2008, Junio C Hamano wrote:
> * mv/defer-gc (Wed Apr 2 21:35:11 2008 +0200) 3 commits
>  + contrib/hooks: add an example pre-auto-gc hook
>  + Documentation/hooks: add pre-auto-gc hook
>  + git-gc --auto: add pre-auto-gc hook
> 
> A new hook to stop "git gc --auto" from running.

About "git gc --auto", there was a patch sometime ago:

	[PATCH] commit: resurrect "gc --auto" at the end

http://marc.info/?l=git&m=120716427130606&w=2

Was it dropped?

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

[Junio C Hamano]

Michele Ballabio <barra_cuda@katamail.com> writes:

> On Tuesday 22 April 2008, Junio C Hamano wrote:
>> * mv/defer-gc (Wed Apr 2 21:35:11 2008 +0200) 3 commits
>>  + contrib/hooks: add an example pre-auto-gc hook
>>  + Documentation/hooks: add pre-auto-gc hook
>>  + git-gc --auto: add pre-auto-gc hook
>> 
>> A new hook to stop "git gc --auto" from running.
>
> About "git gc --auto", there was a patch sometime ago:
>
> 	[PATCH] commit: resurrect "gc --auto" at the end
>
> http://marc.info/?l=git&m=120716427130606&w=2
>
> Was it dropped?

In the thread, addition of an extra hook to "gc --auto" wasdiscussed.  It
was judged conditionally Ok as long as nobody assumes "gc --auto" is
ultra-cheap.  We used to have a "gc --auto" at the end of git-commit which
violated that condition, but we do not have that anymore.

The patch resurrects the behaviour that makes the extra hook possibly
unacceptable again, dosn't it?

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

[Michele Ballabio]

On Wednesday 23 April 2008, Junio C Hamano wrote:
> In the thread, addition of an extra hook to "gc --auto" wasdiscussed.  It
> was judged conditionally Ok as long as nobody assumes "gc --auto" is
> ultra-cheap.  We used to have a "gc --auto" at the end of git-commit which
> violated that condition, but we do not have that anymore.
> 
> The patch resurrects the behaviour that makes the extra hook possibly
> unacceptable again, dosn't it?

Yes. I thought there was an unwanted change in behavior in git-commit.
Sorry for the noise.

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

A rough timeline from now on.

 * Discussion and review on new feature and enhancement patch series
   begins.  Please resubmit things that you were cooking in your head
   during 1.5.5-rc period after cleaning up and retesting.

 * 1.5.6 merge window closes (2008-05-14).

 * Fixes of 'master' continues; 1.5.6-rc0 gets tagged (2008-05-21).

 * 1.5.6 Final (2008-06-08).

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

* db/learn-HEAD (Sat Apr 26 15:53:12 2008 -0400) 2 commits
 - Make ls-remote http://... list HEAD, like for git://...
 - Make walker.fetch_ref() take a struct ref.

* cc/help (Fri Apr 25 08:25:41 2008 +0200) 5 commits
 - documentation: web--browse: add a note about konqueror
 - documentation: help: add info about "man.<tool>.cmd" config var
 - help: use "man.<tool>.cmd" as custom man viewer command
 - documentation: help: add "man.<tool>.path" config variable
 - help: use man viewer path from "man.<tool>.path" config var

* jn/webfeed (Sun Apr 20 22:09:48 2008 +0200) 1 commit
 + gitweb: Use feed link according to current view

* ar/batch-cat (Wed Apr 23 15:17:53 2008 -0400) 11 commits
 - git-svn: Speed up fetch
 - Git.pm: Add hash_and_insert_object and cat_blob
 - Git.pm: Add command_bidi_pipe and command_close_bidi_pipe
 - git-hash-object: Add --stdin-paths option
 - Add more tests for git hash-object
 - Move git-hash-object tests from t5303 to t1007
 - git-cat-file: Add --batch option
 - git-cat-file: Add --batch-check option
 - git-cat-file: Make option parsing a little more flexible
 - git-cat-file: Small refactor of cmd_cat_file
 - <<REJECT>> Add tests for git cat-file

* lt/dirmatch-optim (Sat Apr 19 14:22:38 2008 -0700) 1 commit
 + Optimize match_pathspec() to avoid fnmatch()

* dm/cherry-pick-s (Sat Apr 26 15:14:28 2008 -0500) 1 commit
 + Allow cherry-pick (and revert) to add signoff line

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

* ho/shared (Wed Apr 16 11:34:24 2008 +0300) 1 commit
 + Make core.sharedRepository more generic

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

* pb/remote-mirror-config (Thu Apr 17 13:17:20 2008 +0200) 1 commit
 + Add a remote.*.mirror configuration option

* lh/branch-merged (Fri Apr 18 18:30:15 2008 +0200) 3 commits
 + Add tests for `branch --[no-]merged`
 + git-branch.txt: compare --contains, --merged and --no-merged
 + git-branch: add support for --merged and --no-merged

* jk/fetch-status (Wed Apr 9 20:11:52 2008 -0400) 1 commit
 + git-fetch: always show status of non-tracking-ref fetches

This changes reporting behaviour of one-shot "git pull $url $branch",
which would affect long-time users in integrator role (that's you, Linus
;-).  Let's see if we hear anybody screaming.

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 + Teach GIT-VERSION-GEN about the .git file
 + Teach git-submodule.sh about the .git file
 + Teach resolve_gitlink_ref() about the .git file
 + Add platform-independent .git "symlink"

There was a GSoC project idea to enhance "git submodule" to take advantage
of this facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was bound to
the superproject, but it appears nobody took it.

* bc/filter-branch (Wed Mar 26 10:47:09 2008 -0500) 1 commit
 + filter-branch.sh: support nearly proper tag name filtering

Instead of discarding annotated and/or signed tags, this keeps them and
demotes the signed ones to simply annotated.  It issues warning when it
does this demotion.  I think the behaviour is sensible.

* jc/lstat (Sun Mar 30 12:39:25 2008 -0700) 2 commits
 + diff-files: mark an index entry we know is up-to-date as such
 + write_index(): optimize ce_smudge_racily_clean_entry() calls with
   CE_UPTODATE

Further reduce redundant lstat(2) calls during "git status" and other
common operations.

----------------------------------------------------------------
[Actively Cooking]

* js/rebase-i-sequencer (Fri Apr 25 22:50:53 2008 -0700) 14 commits
 + rebase -i: update the implementation of 'mark' command
 + Add option --preserve-tags
 + Teach rebase interactive the tag command
 + Add option --first-parent
 + Do rebase with preserve merges with advanced TODO list
 + Select all lines with fake-editor
 + Unify the length of $SHORT* and the commits in the TODO list
 + Teach rebase interactive the merge command
 + Move redo merge code in a function
 + Teach rebase interactive the reset command
 + Teach rebase interactive the mark command
 + Move cleanup code into it's own function
 + Don't append default merge message to -m message
 + fake-editor: output TODO list if unchanged

This may complement the proposed "sequencer" GSoC project.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 6 commits
 - merge: remove deprecated summary and diffstat options and config
   variables
 + merge, pull: add '--(no-)log' command line option
 + fmt-merge-msg: add '--(no-)log' options and 'merge.log' config
   variable
 + add 'merge.stat' config variable
 + merge, pull: introduce '--(no-)stat' option
 + doc: moved merge.* config variables into separate merge-config.txt

The last one needs to be held back, as it actually removes the support for
features that the main part of the series deprecates, until 1.6.0 or
later.

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.

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

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.  There recently was a problem report that had a scent of this
issue which turned out to be a false alarm (it was about http-push which
does not do the native pack protocol optimization and the reporter was
pushing into an empty repository which needs full transfer anyway).

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 + Make git-add behave more sensibly in a case-insensitive
   environment
 + When adding files to the index, add support for case-independent
   matches
 + Make unpack-tree update removed files before any updated files
 + Make branch merging aware of underlying case-insensitive
   filsystems
 + Add 'core.ignorecase' option
 + Make hash_name_lookup able to do case-independent lookups
 + Make "index_name_exists()" return the cache_entry it found
 + Move name hashing functions into a file of its own
 + Make unpack_trees_options bit flags actual bitfields

The beginning of case insensitive filesystem support, currently
ASCII-only.

----------------------------------------------------------------
[Dropped]


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

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* db/clone-in-c (Thu Apr 17 19:32:43 2008 -0400) 8 commits
 - [mess] Build in clone
 - [strdup() and other clean-ups needed] Provide API access to
   init_db()
 - [waiting for response] Add a function to set a non-default work
   tree
 - Allow for having for_each_ref() list extra refs
 - Have a constant extern refspec for "--tags"
 - Add a library function to add an alternate to the alternates file
 - Add a lockfile function to append to a file
 - Mark the list of refs to fetch as const

There were a few comments and suggestions to the ones near the tip that
need to be addressed.  Earlier ones look Ok.

* ap/svn (Tue Apr 15 21:04:18 2008 -0400) 3 commits
 - git-svn: add documentation for --add-author-from option.
 - git-svn: Add --add-author-from option.
 - git-svn: add documentation for --use-log-author option.

Eric requested a new set of tests for this series.

* py/submodule-2 (Wed Apr 16 22:19:31 2008 +0800) 1 commit
 - git-submodule: Extract functions module_info and module_url

Not going well.

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time now.

* jc/lstat-debug (Thu Mar 27 16:56:53 2008 -0700) 1 commit
 - lstat: introduce a wrapper xlstat

* 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

Just my toy at this moment.

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

[Ping Yin]

On Sun, Apr 27, 2008 at 2:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>  * py/submodule-2 (Wed Apr 16 22:19:31 2008 +0800) 1 commit
>   - git-submodule: Extract functions module_info and module_url
>
>  Not going well.
>

Hmm, i wonder how this series can go well. Or this series is totoally
bad and should be discarded.


Ping Yin

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

It's been a while since the last issue of this series.  I've been
swamped, and haven't had a chance to spend enough time on reviewing and
accepting patches.

A good news is that the tip of 'pu' tonight passes all the test --- it has
been broken for some time.

A rough timeline from now on.

 * Discussion and review on new feature and enhancement patch series
   begins.  Please resubmit things that you were cooking in your head
   during 1.5.5-rc period after cleaning up and retesting.

 * 1.5.6 merge window closes (2008-05-14).

 * Fixes of 'master' continues; 1.5.6-rc0 gets tagged (2008-05-21).

 * 1.5.6 Final (2008-06-08).

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

* bd/tests (Sun May 4 01:38:00 2008 -0400) 10 commits
 + Rename the test trash directory to contain spaces.
 + Fix tests breaking when checkout path contains shell
   metacharacters
 + Don't use the 'export NAME=value' in the test scripts.
 + lib-git-svn.sh: Fix quoting issues with paths containing shell
   metacharacters
 + test-lib.sh: Fix some missing path quoting
 + Use test_set_editor in t9001-send-email.sh
 + test-lib.sh: Add a test_set_editor function to safely set $VISUAL
 + git-send-email.perl: Handle shell metacharacters in $EDITOR
   properly
 + config.c: Escape backslashes in section names properly
 + git-rebase.sh: Fix --merge --abort failures when path contains
   whitespace

Making sure the tools quote paths correctly and work inside a directory
whose pathname contains whitespace.  Thanks Bryan, and thanks J6t for
reviewing and testing.

* np/pack (Fri May 2 15:11:51 2008 -0400) 7 commits
 + pack-objects: fix early eviction for max depth delta objects
 + pack-objects: allow for early delta deflating
 + pack-objects: move compression code in a separate function
 + pack-objects: clean up write_object() a bit
 + pack-objects: simplify the condition associated with --all-
   progress
 + pack-objects: remove some double negative logic
 + pack-objects: small cleanup

Every time Nico tweaks pack generation, something good comes out ;-).

* py/diff-submodule (Sat May 3 17:24:28 2008 -0700) 5 commits
 + is_racy_timestamp(): do not check timestamp for gitlinks
 + diff-lib.c: rename check_work_tree_entity()
 + diff: a submodule not checked out is not modified
 + Add t7506 to test submodule related functions for git-status
 + t4027: test diff for submodule with empty directory

A submodule that is not checked out is not modified, but was mistaken as
being removed.  Thanks Ping for tests and fixes.

* cc/hooks-doc (Fri May 2 05:30:47 2008 +0200) 1 commit
 - Documentation: rename "hooks.txt" to "githooks.txt" and make it a
   man page

I've looked at but not applied most of the patches in the series that
built on top of this.  I think it probably is a good goal to make
everything _accessible_ as manual pages, but at the same time I do not
exactly like the HTML rendered results of material that are not really
manual pages.  E.g. "Everyday" looks much worse to me.

At least, the categorization of sections 1/5/7 should be straightened
out.  diffcore is not about "file format" at all and do not belong to
section 5, for example.

* pb/push (Mon Apr 28 11:32:12 2008 -0400) 1 commit
 - add special "matching refs" refspec

This first patch is a good enhancement without hurting any existing users.
We need a staged introduction of the second and later patches, and many
people including me did not agree the later ones in the series are
desirable.

* mv/format-cc (Tue Apr 29 12:56:47 2008 +0200) 3 commits
 + Add tests for sendemail.cc configuration variable
 + git-send-email: add a new sendemail.cc configuration variable
 + git-format-patch: add a new format.cc configuration variable

* as/graph (Mon May 5 00:57:03 2008 -0700) 4 commits
 - graph API: eliminate unnecessary indentation
 - log and rev-list: add --graph option
 - Add history graph API
 - revision API: split parent rewriting and parent printing options

Draw "tig 'g'" graph without tig ;-)

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 4 commits
 - diff: enable "too large a rename" warning when -M/-C is explicitly
   asked for
 + diff: make "too many files" rename warning optional
 + bump rename limit defaults
 + add merge.renamelimit config option

The documentation part of this series partly depends on another series,
but I am expecting both to graduate smoothly to 'master' reasonably soon.

* sv/first-parent (Sun Apr 27 19:32:46 2008 +0200) 1 commit
 + Simplify and fix --first-parent implementation

* gp/bisect-fix (Mon May 5 07:43:00 2008 +0000) 1 commit
 + git-bisect.sh: don't accidentally override existing branch
   "bisect"

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

* pb/remote-mirror-config (Thu Apr 17 13:17:20 2008 +0200) 1 commit
 + Add a remote.*.mirror configuration option

* lh/branch-merged (Fri Apr 18 18:30:15 2008 +0200) 3 commits
 + Add tests for `branch --[no-]merged`
 + git-branch.txt: compare --contains, --merged and --no-merged
 + git-branch: add support for --merged and --no-merged

* jk/fetch-status (Wed Apr 9 20:11:52 2008 -0400) 1 commit
 + git-fetch: always show status of non-tracking-ref fetches

This changes reporting behaviour of one-shot "git pull $url $branch",
which would affect long-time users in integrator role (that's you, Linus
;-).  Let's see if we hear anybody screaming.

* lh/git-file (Wed Feb 20 23:13:16 2008 +0100) 4 commits
 + Teach GIT-VERSION-GEN about the .git file
 + Teach git-submodule.sh about the .git file
 + Teach resolve_gitlink_ref() about the .git file
 + Add platform-independent .git "symlink"

There was a GSoC project idea to enhance "git submodule" to take advantage
of this facility to preserve the subrepository while switching between a
revision with a submodule and another before the submodule was bound to
the superproject, but it appears nobody took it.

* bc/filter-branch (Wed Mar 26 10:47:09 2008 -0500) 1 commit
 + filter-branch.sh: support nearly proper tag name filtering

Instead of discarding annotated and/or signed tags, this keeps them and
demotes the signed ones to simply annotated.  It issues warning when it
does this demotion.  I think the behaviour is sensible.

* jc/lstat (Sun Mar 30 12:39:25 2008 -0700) 2 commits
 + diff-files: mark an index entry we know is up-to-date as such
 + write_index(): optimize ce_smudge_racily_clean_entry() calls with
   CE_UPTODATE

Further reduce redundant lstat(2) calls during "git status" and other
common operations.

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

* lt/dirmatch-optim (Sat Apr 19 14:22:38 2008 -0700) 1 commit
 + Optimize match_pathspec() to avoid fnmatch()

* dm/cherry-pick-s (Sat Apr 26 15:14:28 2008 -0500) 1 commit
 + Allow cherry-pick (and revert) to add signoff line

* cc/help (Fri Apr 25 08:25:41 2008 +0200) 5 commits
 + documentation: web--browse: add a note about konqueror
 + documentation: help: add info about "man.<tool>.cmd" config var
 + help: use "man.<tool>.cmd" as custom man viewer command
 + documentation: help: add "man.<tool>.path" config variable
 + help: use man viewer path from "man.<tool>.path" config var

* jn/webfeed (Sun Apr 20 22:09:48 2008 +0200) 1 commit
 + gitweb: Use feed link according to current view

----------------------------------------------------------------
[Actively Cooking]

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 + Use perl instead of tac
 + Fix t3404 assumption that `wc -l` does not use whitespace.
 + rebase -i: Use : in expr command instead of match.
 + rebase -i: update the implementation of 'mark' command
 + Add option --preserve-tags
 + Teach rebase interactive the tag command
 + Add option --first-parent
 + Do rebase with preserve merges with advanced TODO list
 + Select all lines with fake-editor
 + Unify the length of $SHORT* and the commits in the TODO list
 + Teach rebase interactive the merge command
 + Move redo merge code in a function
 + Teach rebase interactive the reset command
 + Teach rebase interactive the mark command
 + Move cleanup code into it's own function
 + Don't append default merge message to -m message
 + fake-editor: output TODO list if unchanged

This may complement the proposed "sequencer" GSoC project.  Dscho seems to
have quite a strong objection to the 'mark' syntax and mechanism being
unnecessarily complex.  Let's wait and see if a less complex but equally
expressive alternative materializes...

* db/learn-HEAD (Sat Apr 26 15:53:12 2008 -0400) 2 commits
 + Make ls-remote http://... list HEAD, like for git://...
 + Make walker.fetch_ref() take a struct ref.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 6 commits
 - merge: remove deprecated summary and diffstat options and config
   variables
 + merge, pull: add '--(no-)log' command line option
 + fmt-merge-msg: add '--(no-)log' options and 'merge.log' config
   variable
 + add 'merge.stat' config variable
 + merge, pull: introduce '--(no-)stat' option
 + doc: moved merge.* config variables into separate merge-config.txt

The last one needs to be held back, as it actually removes the support for
features that the main part of the series deprecates, until 1.6.0 or
later.

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.
This may help a GSoC project that wants to gather statistical overview of
the history.

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

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.  There recently was a problem report that had a scent of this
issue which turned out to be a false alarm (it was about http-push which
does not do the native pack protocol optimization and the reporter was
pushing into an empty repository which needs full transfer anyway).

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 + Make git-add behave more sensibly in a case-insensitive
   environment
 + When adding files to the index, add support for case-independent
   matches
 + Make unpack-tree update removed files before any updated files
 + Make branch merging aware of underlying case-insensitive
   filsystems
 + Add 'core.ignorecase' option
 + Make hash_name_lookup able to do case-independent lookups
 + Make "index_name_exists()" return the cache_entry it found
 + Move name hashing functions into a file of its own
 + Make unpack_trees_options bit flags actual bitfields

The beginning of case insensitive filesystem support, currently
ASCII-only.

----------------------------------------------------------------
[Dropped]

* ap/svn (Tue Apr 15 21:04:18 2008 -0400) 3 commits
 . git-svn: add documentation for --add-author-from option.
 . git-svn: Add --add-author-from option.
 . git-svn: add documentation for --use-log-author option.

Eric requested a new set of tests for this series which never came.  I am
still holding onto the tip of the topic in case we can resurrect it, but
it is not merged to 'pu'.

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

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* db/clone-in-c (Sun Apr 27 13:39:30 2008 -0400) 8 commits
 - Build in clone
 - Provide API access to init_db()
 - Add a function to set a non-default work tree
 - Allow for having for_each_ref() list extra refs
 - Have a constant extern refspec for "--tags"
 - Add a library function to add an alternate to the alternates file
 - Add a lockfile function to append to a file
 - Mark the list of refs to fetch as const

I'd really want this in 1.5.6; will merge to 'next' after giving a final
pass sometime this week.

* ar/batch-cat (Wed Apr 23 15:17:47 2008 -0400) 5 commits
 - git-cat-file: Add --batch option
 - git-cat-file: Add --batch-check option
 - git-cat-file: Make option parsing a little more flexible
 - git-cat-file: Small refactor of cmd_cat_file
 - Add tests for git cat-file

I fixed up the problematic shell script in the first patch in the series
but later one introduced the same problematic constructs in another file,
at which point I gave up and discarded the rest.  At least it now passes
its own testsuite without breaking others.

* jc/test (Thu Feb 21 21:17:54 2008 -0800) 2 commits
 - tests: convert "cmp" and "cmp -s" to test_cmp
 - tests: test_cmp helper function

This one may be more elaborate, but Jeff's patch is much simpler.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour by not using
merge-recursive, but unfortunately has stalled for some time now.

* jc/lstat-debug (Thu Mar 27 16:56:53 2008 -0700) 1 commit
 - lstat: introduce a wrapper xlstat

* 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

Just my toy at this moment.

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

[Junio C Hamano]

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

> [Dropped]
>
> * ap/svn (Tue Apr 15 21:04:18 2008 -0400) 3 commits
>  . git-svn: add documentation for --add-author-from option.
>  . git-svn: Add --add-author-from option.
>  . git-svn: add documentation for --use-log-author option.
>
> Eric requested a new set of tests for this series which never came.  I am
> still holding onto the tip of the topic in case we can resurrect it, but
> it is not merged to 'pu'.

I usually try hard not to do this kind of thing as it would encourage a
misconception that I'll tie any and all loose ends (which I obviously do
not have infinite amount of time and energy that is necessary), but I've
decided to add a skeleton for necessary tests to get the ball rolling.

Here is a sample output from the test sequence (the log message from the
last one):

    commit 0bc699cbd72810f85a0200c7197022b50e8298ed
    Author: A U Thor <author@example.com>
    Date:   Mon May 12 21:28:26 2008 +0000

        fourth

        From: A U Thor <author@example.com>


        git-svn-id: file:///git.git/t/trash directory/svnrepo@4 23bf1e2a-19bf-478a-b023-e66a9e40421e

I am not sure if adding the "From: " line as a trailer, with two blank
line after it before the git-svn-id line, is the intended format for the
final log message.  Maybe it is meant to go before the commit log message
with a blank line after it.  Maybe it is meant to be a trailer, one blank
line before and after it and then git-svn-id line (in whcih case we have
one blank after it too many).  I genuinely do not know what is intended.

If this is the intended output, please say so.  Otherwise please fix it as
needed, and add tests for the final format specification as well, so that
later changes will not break it.

Thanks.

-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 12 May 2008 14:53:40 -0700
Subject: [PATCH] git-svn: add test for --add-author-from and --use-log-author

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 t/t9122-git-svn-author.sh |   73 +++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 73 insertions(+), 0 deletions(-)
 create mode 100755 t/t9122-git-svn-author.sh

diff --git a/t/t9122-git-svn-author.sh b/t/t9122-git-svn-author.sh
new file mode 100755
index 0000000..d9a784b
--- /dev/null
+++ b/t/t9122-git-svn-author.sh
@@ -0,0 +1,73 @@
+#!/bin/sh
+
+test_description='git svn authorship'
+. ./lib-git-svn.sh
+
+test_expect_success 'setup svn repository' '
+	svn checkout "$svnrepo" work.svn &&
+	(
+		cd work.svn &&
+		echo >file
+		svn add file
+		svn commit -m "first commit" file
+	)
+
+'
+
+test_expect_success 'interact with it via git-svn' '
+
+	mkdir work.git &&
+	(
+		cd work.git &&
+		git svn init "$svnrepo"
+		git svn fetch &&
+
+		echo modification >file &&
+		test_tick &&
+		git commit -a -m second &&
+
+		test_tick &&
+		git svn dcommit &&
+
+		echo "further modification" >file &&
+		test_tick &&
+		git commit -a -m third &&
+
+		test_tick &&
+		git svn --add-author-from dcommit &&
+
+		echo "yet further modification" >file &&
+		test_tick &&
+		git commit -a -m fourth &&
+
+		test_tick &&
+		git svn --add-author-from --use-log-author dcommit &&
+
+		git log &&
+
+		git show -s HEAD^^ >../actual.2 &&
+		git show -s HEAD^  >../actual.3 &&
+		git show -s HEAD   >../actual.4
+
+	) &&
+
+	# Make sure that --add-author-from without --use-log-author
+	# did not affect the authorship information
+	myself=$(grep "^Author: " actual.2) &&
+	unaffected=$(grep "^Author: " actual.3) &&
+	test "z$myself" = "z$unaffected" &&
+
+	# Make sure lack of --add-author-from did not add cruft
+	! grep "^    From: A U Thor " actual.2 &&
+
+	# Make sure --add-author-from added cruft
+	grep "^    From: A U Thor " actual.3 &&
+	grep "^    From: A U Thor " actual.4 &&
+
+	# Make sure --add-author-from with --use-log-author affected
+	# the authorship information
+	grep "^Author: A U Thor " actual.4
+
+'
+
+test_done
-- 
1.5.5.1.328.g8abfd

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

[Junio C Hamano]

Adam, I am very sorry, but the message was misdirected.

I'm resending it now to ask for comments from Avery.

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

It's been a while since the last issue of this series.  I've been
swamped, and haven't had a chance to spend enough time on reviewing and
accepting patches.

A rough timeline from now on.

 * Will merge the remaining topics already on 'next', and perhaps accept a
   handful minor topics that are not yet in.

 * Fixes of 'master' continues; 1.5.6-rc0 gets tagged (2008-05-21).

 * 1.5.6 Final (2008-06-08).

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

* bc/tag (Fri May 9 00:03:35 2008 -0500) 3 commits
 - ident.c: New function valid_ident for checking ident string
   formatting
 - Make mktag a builtin
 - mktag.c: adjust verify_tag parameters

I stopped looking at this after hitting an unappliable patch --- will need
to take a look at it again.

* js/config-cb (Wed May 14 18:46:53 2008 +0100) 1 commit
 - Provide git_config with a callback-data parameter

This needs to wait until most of the other things graduate for 1.5.6;
luckily, unlike the other "path-list" changes, misconversions is much
easier to catch for this change and I am not worried about it.

* ds/branch-auto-rebase (Sat May 10 15:36:29 2008 -0700) 1 commit
 + Allow tracking branches to set up rebase by default.

For 1.5.6.

* bc/repack (Wed May 14 01:33:53 2008 -0400) 5 commits
 + let pack-objects do the writing of unreachable objects as loose
   objects
 + add a force_object_loose() function
 + builtin-gc.c: deprecate --prune, it now really has no effect
 + git-gc: always use -A when manually repacking
 + repack: modify behavior of -A option to leave unreferenced objects
   unpacked

For 1.5.6.

* sp/ignorecase (Sun May 11 18:16:42 2008 +0200) 4 commits
 - t0050: Add test for case insensitive add
 - t0050: Set core.ignorecase case to activate case insensitivity
 - t0050: Test autodetect core.ignorecase
 - git-init: autodetect core.ignorecase

This unfortunately seems to break on natively case sensitive filesystems.

* ar/add-unreadable (Mon May 12 19:59:23 2008 +0200) 5 commits
 + Add a config option to ignore errors for git-add
 + Add a test for git-add --ignore-errors
 + Add --ignore-errors to git-add to allow it to skip files with read
   errors
 + Extend interface of add_files_to_cache to allow ignore indexing
   errors
 + Make the exit code of add_file_to_index actually useful

* jc/diff-words (Sun May 11 12:33:48 2008 -0700) 2 commits
 - diff --color-words: a bit of tweak
 - diff --color-words reimplementation


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

* lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits
 + Make git-add behave more sensibly in a case-insensitive
   environment
 + When adding files to the index, add support for case-independent
   matches
 + Make unpack-tree update removed files before any updated files
 + Make branch merging aware of underlying case-insensitive
   filsystems
 + Add 'core.ignorecase' option
 + Make hash_name_lookup able to do case-independent lookups
 + Make "index_name_exists()" return the cache_entry it found
 + Move name hashing functions into a file of its own
 + Make unpack_trees_options bit flags actual bitfields

The beginning of case insensitive filesystem support, currently
ASCII-only.

* db/learn-HEAD (Sat Apr 26 15:53:12 2008 -0400) 2 commits
 + Make ls-remote http://... list HEAD, like for git://...
 + Make walker.fetch_ref() take a struct ref.

* cc/help (Fri Apr 25 08:25:41 2008 +0200) 5 commits
 + documentation: web--browse: add a note about konqueror
 + documentation: help: add info about "man.<tool>.cmd" config var
 + help: use "man.<tool>.cmd" as custom man viewer command
 + documentation: help: add "man.<tool>.path" config variable
 + help: use man viewer path from "man.<tool>.path" config var

* dm/cherry-pick-s (Sat Apr 26 15:14:28 2008 -0500) 1 commit
 + Allow cherry-pick (and revert) to add signoff line

* lt/dirmatch-optim (Sat Apr 19 14:22:38 2008 -0700) 1 commit
 + Optimize match_pathspec() to avoid fnmatch()

* jn/webfeed (Sun Apr 20 22:09:48 2008 +0200) 1 commit
 + gitweb: Use feed link according to current view

* gp/bisect-fix (Mon May 5 07:43:00 2008 +0000) 1 commit
 + git-bisect.sh: don't accidentally override existing branch
   "bisect"

* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 3 commits
 + diff: make "too many files" rename warning optional
 + bump rename limit defaults
 + add merge.renamelimit config option

* py/diff-submodule (Sat May 3 17:24:28 2008 -0700) 5 commits
 + is_racy_timestamp(): do not check timestamp for gitlinks
 + diff-lib.c: rename check_work_tree_entity()
 + diff: a submodule not checked out is not modified
 + Add t7506 to test submodule related functions for git-status
 + t4027: test diff for submodule with empty directory

A submodule that is not checked out is not modified, but was mistaken as
being removed.  Thanks Ping for tests and fixes.

* cc/hooks-doc (Fri May 2 05:30:47 2008 +0200) 1 commit
 + Documentation: rename "hooks.txt" to "githooks.txt" and make it a
   man page

* mv/format-cc (Tue Apr 29 12:56:47 2008 +0200) 3 commits
 + Add tests for sendemail.cc configuration variable
 + git-send-email: add a new sendemail.cc configuration variable
 + git-format-patch: add a new format.cc configuration variable

* bd/tests (Sun May 4 01:38:00 2008 -0400) 10 commits
 + Rename the test trash directory to contain spaces.
 + Fix tests breaking when checkout path contains shell
   metacharacters
 + Don't use the 'export NAME=value' in the test scripts.
 + lib-git-svn.sh: Fix quoting issues with paths containing shell
   metacharacters
 + test-lib.sh: Fix some missing path quoting
 + Use test_set_editor in t9001-send-email.sh
 + test-lib.sh: Add a test_set_editor function to safely set $VISUAL
 + git-send-email.perl: Handle shell metacharacters in $EDITOR
   properly
 + config.c: Escape backslashes in section names properly
 + git-rebase.sh: Fix --merge --abort failures when path contains
   whitespace

Making sure the tools quote paths correctly and work inside a directory
whose pathname contains whitespace.  Thanks Bryan, and thanks J6t for
reviewing and testing.

* sb/committer (Sun May 4 18:04:51 2008 +0200) 3 commits
 + commit: Show committer if automatic
 + commit: Show author if different from committer
 + Preparation to call determine_author_info from prepare_to_commit

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

* as/graph (Mon May 5 00:57:03 2008 -0700) 4 commits
 + graph API: eliminate unnecessary indentation
 + log and rev-list: add --graph option
 + Add history graph API
 + revision API: split parent rewriting and parent printing options

Draw "tig 'g'" graph without tig ;-)

* np/pack (Fri May 2 15:11:51 2008 -0400) 7 commits
 + pack-objects: fix early eviction for max depth delta objects
 + pack-objects: allow for early delta deflating
 + pack-objects: move compression code in a separate function
 + pack-objects: clean up write_object() a bit
 + pack-objects: simplify the condition associated with --all-
   progress
 + pack-objects: remove some double negative logic
 + pack-objects: small cleanup

Every time Nico tweaks pack generation, something good comes out ;-).

* db/clone-in-c (Sun Apr 27 13:39:30 2008 -0400) 8 commits
 + Build in clone
 + Provide API access to init_db()
 + Add a function to set a non-default work tree
 + Allow for having for_each_ref() list extra refs
 + Have a constant extern refspec for "--tags"
 + Add a library function to add an alternate to the alternates file
 + Add a lockfile function to append to a file
 + Mark the list of refs to fetch as const

For 1.5.6; please give it a good beating.

----------------------------------------------------------------
[Actively Cooking]

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

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.

This needs debugging.

* ap/svn (Mon May 12 17:09:49 2008 -0700) 4 commits
 + git-svn: add test for --add-author-from and --use-log-author
 + git-svn: add documentation for --add-author-from option.
 + git-svn: Add --add-author-from option.
 + git-svn: add documentation for --use-log-author option.

Some tweak for output might be needed, I dunno.

* sv/first-parent (Mon May 12 17:12:36 2008 +0200) 2 commits
 + revision.c: really honor --first-parent
 + Simplify and fix --first-parent implementation

----------------------------------------------------------------
[Stalled]

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the tip commit on the series).

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 + Use perl instead of tac
 + Fix t3404 assumption that `wc -l` does not use whitespace.
 + rebase -i: Use : in expr command instead of match.
 + rebase -i: update the implementation of 'mark' command
 + Add option --preserve-tags
 + Teach rebase interactive the tag command
 + Add option --first-parent
 + Do rebase with preserve merges with advanced TODO list
 + Select all lines with fake-editor
 + Unify the length of $SHORT* and the commits in the TODO list
 + Teach rebase interactive the merge command
 + Move redo merge code in a function
 + Teach rebase interactive the reset command
 + Teach rebase interactive the mark command
 + Move cleanup code into it's own function
 + Don't append default merge message to -m message
 + fake-editor: output TODO list if unchanged

This may complement the proposed "sequencer" GSoC project.  Dscho seems to
have quite a strong objection to the 'mark' syntax and mechanism being
unnecessarily complex.  Let's wait and see if a less complex but equally
expressive alternative materializes...

* ar/batch-cat (Wed Apr 23 15:17:47 2008 -0400) 5 commits
 - git-cat-file: Add --batch option
 - git-cat-file: Add --batch-check option
 - git-cat-file: Make option parsing a little more flexible
 - git-cat-file: Small refactor of cmd_cat_file
 - Add tests for git cat-file

I fixed up the problematic shell script in the first patch in the series
but later one introduced the same problematic constructs in another file,
at which point I gave up and discarded the rest.  At least it now passes
its own testsuite without breaking others.

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

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 - merge: remove deprecated summary and diffstat options and config
   variables

This needs to be held back, as it actually removes the support for
features that the main part of the series deprecates, until 1.6.0 or
later.

* pb/push (Mon Apr 28 11:32:12 2008 -0400) 1 commit
 + add special "matching refs" refspec

This first patch is a good enhancement without hurting any existing users.
We need a staged introduction of the second and later patches, and many
people including me did not agree the later ones in the series are
desirable.

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time 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

Just my toy at this moment.

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

[Daniel Barkalow]

On Wed, 14 May 2008, Junio C Hamano wrote:

> * db/clone-in-c (Sun Apr 27 13:39:30 2008 -0400) 8 commits
>  + Build in clone
>  + Provide API access to init_db()
>  + Add a function to set a non-default work tree
>  + Allow for having for_each_ref() list extra refs
>  + Have a constant extern refspec for "--tags"
>  + Add a library function to add an alternate to the alternates file
>  + Add a lockfile function to append to a file
>  + Mark the list of refs to fetch as const
> 
> For 1.5.6; please give it a good beating.

Last time, you said you were going to review this again; did you review it 
and find nothing to comment on, decide to just make sure it gets a 
beating, or are you still planning to review it more? (Just wondering so I 
can try to arrange to have time to respond to comments if there's going to 
be a bunch)

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

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> Last time, you said you were going to review this again; did you review it 
> and find nothing to comment on, decide to just make sure it gets a 
> beating, or are you still planning to review it more? (Just wondering so I 
> can try to arrange to have time to respond to comments if there's going to 
> be a bunch)

I did not have any further nitpicks on either design nor code in particular.

But keep in mind that I won't be the single source of review comments ;-).
.

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

[Steffen Prohaska]

On Wed, 14 May 2008, Junio C Hamano wrote:

> 
> For 1.5.6.
> 
> * sp/ignorecase (Sun May 11 18:16:42 2008 +0200) 4 commits
>  - t0050: Add test for case insensitive add
>  - t0050: Set core.ignorecase case to activate case insensitivity
>  - t0050: Test autodetect core.ignorecase
>  - git-init: autodetect core.ignorecase
> 
> This unfortunately seems to break on natively case sensitive filesystems.


>From 92ec8c8a12cdc45a69f6612af340a8ce50976ab1 Mon Sep 17 00:00:00 2001
From: Steffen Prohaska <prohaska@zib.de>
Date: Thu, 15 May 2008 07:19:54 +0200
Subject: [PATCH] t0050: Fix merge test on case sensitive file systems

On a case sensitive filesystem, "git reset --hard" might refuse to
overwrite a file whose name differs only by case, even if
core.ignorecase is set.  It is not clear which circumstances cause this
behavior.  This commit simply works around the problem by removing
the case changing file before running "git reset --hard".

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 t/t0050-filesystem.sh |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
index 0e33c4b..c5360e2 100755
--- a/t/t0050-filesystem.sh
+++ b/t/t0050-filesystem.sh
@@ -72,6 +72,8 @@ $test_case 'rename (case change)' '
 
 $test_case 'merge (case change)' '
 
+	rm -f CamelCase &&
+	rm -f camelcase &&
 	git reset --hard initial &&
 	git merge topic
 
-- 
1.5.5.1.349.g99d0

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

It's been a while since the last issue of this series.  I've been
swamped, and haven't had a chance to spend enough time on reviewing and
accepting patches.

A rough timeline from now on.

 * Fixes of 'master' continues; 1.5.6-rc0 gets tagged (2008-05-21 -- need
   to slip til the weekend).

 * 1.5.6 Final (2008-06-08).

There are a few known breakages I want to see addressed that are not in
here before 1.5.6 (no not any new features but pure bugfixes).

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

* js/config-cb (Wed May 14 18:46:53 2008 +0100) 1 commit
 - Provide git_config with a callback-data parameter

This needs to wait until most of the other things graduate for 1.5.6;
luckily, unlike the other "path-list" changes, misconversions is much
easier to catch for this change and I am not worried about it.

* jc/apply-whitespace (Sat May 17 02:02:44 2008 -0700) 3 commits
 + builtin-apply: do not declare patch is creation when we do not
   know it
 + builtin-apply: accept patch to an empty file
 + builtin-apply: typofix

We were loose when parsing a patch that adds contents to an empty file.
This fix would be nice to have in 1.5.6.

* js/mailinfo (Fri May 16 14:03:30 2008 +0100) 1 commit
 - <<PARK - BASE64 and QP still broken>> mailsplit and mailinfo:
   gracefully handle NUL characters

When "am" processes a patch that modifies a line with NUL, we used to
chomp the patch line there, resulting in rejects.  This patch fixes the
issue partially, only when the message is not encoded in BASE64 nor
Quoted-Printable.

* mo/cvsserver (Wed May 14 22:35:48 2008 -0600) 3 commits
 + git-cvsserver: add ability to guess -kb from contents
 + implement gitcvs.usecrlfattr
 + git-cvsserver: add mechanism for managing working tree and current
   directory

CVS interoperability improvements, for 1.5.6

* js/cvsexportcommit (Wed May 14 15:29:49 2008 +0100) 2 commits
 + cvsexportcommit: introduce -W for shared working trees (between
   Git and CVS)
 + cvsexportcommit: chomp only removes trailing whitespace

CVS interoperability improvements, for 1.5.6

* ar/t6031 (Sun May 18 16:57:27 2008 +0200) 1 commit
 + Fix t6031 on filesystems without working exec bit

* jc/unpack-trees-reword (Sat May 17 12:03:49 2008 -0700) 1 commit
 + unpack-trees: allow Porcelain to give different error messages

* jc/add-n-u (Wed May 21 12:04:34 2008 -0700) 1 commit
 + "git-add -n -u" should not add but just report

* js/ignore-submodule (Wed May 14 18:03:59 2008 +0100) 3 commits
 + Ignore dirty submodule states during rebase and stash
 + Teach update-index about --ignore-submodules
 + diff options: Introduce --ignore-submodules

The above are all fixes, meant for 1.5.6.

* dr/ceiling (Fri May 16 00:27:28 2008 +0100) 1 commit
 - Add support for GIT_CEILING_DIRECTORIES

I haven't had a chance to take a look at the updated series myself.

* jc/diff-words (Sun May 11 12:33:48 2008 -0700) 2 commits
 - diff --color-words: a bit of tweak
 - diff --color-words reimplementation

This series did not pan out well.  I briefly thought that perhaps I should
discard them and replace with the "not just whitespace" one from Ping Yin
first, hoping that we can clean the overall logic up later, but perhaps
the whole thing can get a fresh restart after 1.5.6.

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

* ar/add-unreadable (Mon May 12 19:59:23 2008 +0200) 5 commits
 + Add a config option to ignore errors for git-add
 + Add a test for git-add --ignore-errors
 + Add --ignore-errors to git-add to allow it to skip files with read
   errors
 + Extend interface of add_files_to_cache to allow ignore indexing
   errors
 + Make the exit code of add_file_to_index actually useful

When you sometimes have unreadable path in your own work tree, this allows
you to ignore failures to index such path with "git add".  Philosophically
that whole notion is wrong ("why should you be adding such a file to begin
with"), but this has practical value of working around insane systems that
locks out the access by the user to a file when the file is in use by
somebody else.

I am somewhat skeptical about the last one that enables such a workaround
on a permanent basis, though.

* ds/branch-auto-rebase (Sat May 10 15:36:29 2008 -0700) 1 commit
 + Allow tracking branches to set up rebase by default.

For 1.5.6.

* as/graph (Mon May 5 00:57:03 2008 -0700) 4 commits
 + graph API: eliminate unnecessary indentation
 + log and rev-list: add --graph option
 + Add history graph API
 + revision API: split parent rewriting and parent printing options

Draw "tig 'g'" graph without tig ;-)

* np/pack (Fri May 2 15:11:51 2008 -0400) 7 commits
 + pack-objects: fix early eviction for max depth delta objects
 + pack-objects: allow for early delta deflating
 + pack-objects: move compression code in a separate function
 + pack-objects: clean up write_object() a bit
 + pack-objects: simplify the condition associated with --all-
   progress
 + pack-objects: remove some double negative logic
 + pack-objects: small cleanup

Every time Nico tweaks pack generation, something good comes out ;-).

* sv/first-parent (Mon May 12 17:12:36 2008 +0200) 2 commits
 + revision.c: really honor --first-parent
 + Simplify and fix --first-parent implementation


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

* sp/ignorecase (Thu May 15 07:19:54 2008 +0200) 5 commits
 + t0050: Fix merge test on case sensitive file systems
 + t0050: Add test for case insensitive add
 + t0050: Set core.ignorecase case to activate case insensitivity
 + t0050: Test autodetect core.ignorecase
 + git-init: autodetect core.ignorecase

For 1.5.6.

* bc/repack (Thu May 15 22:37:31 2008 -0400) 6 commits
 + Documentation/git-repack.txt: document new -A behaviour
 + let pack-objects do the writing of unreachable objects as loose
   objects
 + add a force_object_loose() function
 + builtin-gc.c: deprecate --prune, it now really has no effect
 + git-gc: always use -A when manually repacking
 + repack: modify behavior of -A option to leave unreferenced objects
   unpacked

For 1.5.6.

* db/clone-in-c (Tue May 20 14:15:14 2008 -0400) 11 commits
 + clone: fall back to copying if hardlinking fails
 + builtin-clone.c: Need to closedir() in copy_or_link_directory()
 + builtin-clone: fix initial checkout
 + Build in clone
 + Provide API access to init_db()
 + Add a function to set a non-default work tree
 + Allow for having for_each_ref() list extra refs
 + Have a constant extern refspec for "--tags"
 + Add a library function to add an alternate to the alternates file
 + Add a lockfile function to append to a file
 + Mark the list of refs to fetch as const

For 1.5.6.

* pb/push (Mon Apr 28 11:32:12 2008 -0400) 1 commit
 + add special "matching refs" refspec

This first patch is a good enhancement without hurting any existing users.
We need a staged introduction of the second and later patches, and many
people including me did not agree the later ones in the series are
desirable.

----------------------------------------------------------------
[Stalled]

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

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.

This needs debugging.

* ap/svn (Mon May 12 17:09:49 2008 -0700) 4 commits
 + git-svn: add test for --add-author-from and --use-log-author
 + git-svn: add documentation for --add-author-from option.
 + git-svn: Add --add-author-from option.
 + git-svn: add documentation for --use-log-author option.

Some tweak for output might be needed, I dunno.

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the tip commit on the series).

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 + Use perl instead of tac
 + Fix t3404 assumption that `wc -l` does not use whitespace.
 + rebase -i: Use : in expr command instead of match.
 + rebase -i: update the implementation of 'mark' command
 + Add option --preserve-tags
 + Teach rebase interactive the tag command
 + Add option --first-parent
 + Do rebase with preserve merges with advanced TODO list
 + Select all lines with fake-editor
 + Unify the length of $SHORT* and the commits in the TODO list
 + Teach rebase interactive the merge command
 + Move redo merge code in a function
 + Teach rebase interactive the reset command
 + Teach rebase interactive the mark command
 + Move cleanup code into it's own function
 + Don't append default merge message to -m message
 + fake-editor: output TODO list if unchanged

This may complement the proposed "sequencer" GSoC project.  Dscho seems to
have quite a strong objection to the 'mark' syntax and mechanism being
unnecessarily complex.  Let's wait and see if a less complex but equally
expressive alternative materializes...

* ar/batch-cat (Wed Apr 23 15:17:47 2008 -0400) 5 commits
 - git-cat-file: Add --batch option
 - git-cat-file: Add --batch-check option
 - git-cat-file: Make option parsing a little more flexible
 - git-cat-file: Small refactor of cmd_cat_file
 - Add tests for git cat-file

The series was meant to speed up git-svn by avoiding many individual
invocations of git-cat-file.

I fixed up the problematic shell script in the first patch in the series
but later one introduced the same problematic constructs in another file,
at which point I gave up and discarded the rest.  At least it now passes
its own testsuite without breaking others.  The remainder needs to be
resubmit for the entire series to be usable for git-svn.

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

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 - merge: remove deprecated summary and diffstat options and config
   variables

This needs to be held back, as it actually removes the support for
features that the main part of the series deprecates, until 1.6.0 or
later.

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time 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

Just my toy at this moment.

----------------------------------------------------------------
[Dropped]

* bc/tag (Fri May 9 00:03:35 2008 -0500) 3 commits
 - ident.c: New function valid_ident for checking ident string
   formatting
 - Make mktag a builtin
 - mktag.c: adjust verify_tag parameters

The goal of the series was to unify the internal implementation of
git-mktag and git-tag but the patches did not quite apply.  Needs
rebase/resubmit.

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

[Johannes Schindelin]

Hi,

On Wed, 21 May 2008, Junio C Hamano wrote:

> * js/config-cb (Wed May 14 18:46:53 2008 +0100) 1 commit
>  - Provide git_config with a callback-data parameter
> 
> This needs to wait until most of the other things graduate for 1.5.6; 
> luckily, unlike the other "path-list" changes, misconversions is much 
> easier to catch for this change and I am not worried about it.

Just let me know when to resubmit, and against what branch(es).

> * js/mailinfo (Fri May 16 14:03:30 2008 +0100) 1 commit
>  - <<PARK - BASE64 and QP still broken>> mailsplit and mailinfo:
>    gracefully handle NUL characters
> 
> When "am" processes a patch that modifies a line with NUL, we used to
> chomp the patch line there, resulting in rejects.  This patch fixes the
> issue partially, only when the message is not encoded in BASE64 nor
> Quoted-Printable.

Like I said, I would be happy if Tommy took care of that patch.

> * js/ignore-submodule (Wed May 14 18:03:59 2008 +0100) 3 commits
>  + Ignore dirty submodule states during rebase and stash
>  + Teach update-index about --ignore-submodules
>  + diff options: Introduce --ignore-submodules

I haven't heard back from you about renaming that option.  I think I 
suggested --non-gitlinks or something equally discouraging for 
porcelain users.

> * as/graph (Mon May 5 00:57:03 2008 -0700) 4 commits
>  + graph API: eliminate unnecessary indentation
>  + log and rev-list: add --graph option
>  + Add history graph API
>  + revision API: split parent rewriting and parent printing options
> 
> Draw "tig 'g'" graph without tig ;-)

I am a big fan of this feature.

> * db/clone-in-c (Tue May 20 14:15:14 2008 -0400) 11 commits
>  + clone: fall back to copying if hardlinking fails
>  + builtin-clone.c: Need to closedir() in copy_or_link_directory()
>  + builtin-clone: fix initial checkout
>  + Build in clone
>  + Provide API access to init_db()
>  + Add a function to set a non-default work tree
>  + Allow for having for_each_ref() list extra refs
>  + Have a constant extern refspec for "--tags"
>  + Add a library function to add an alternate to the alternates file
>  + Add a lockfile function to append to a file
>  + Mark the list of refs to fetch as const

Fingers crossed.

> * js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
>  + Use perl instead of tac
>  + Fix t3404 assumption that `wc -l` does not use whitespace.
>  + rebase -i: Use : in expr command instead of match.
>  + rebase -i: update the implementation of 'mark' command
>  + Add option --preserve-tags
>  + Teach rebase interactive the tag command
>  + Add option --first-parent
>  + Do rebase with preserve merges with advanced TODO list
>  + Select all lines with fake-editor
>  + Unify the length of $SHORT* and the commits in the TODO list
>  + Teach rebase interactive the merge command
>  + Move redo merge code in a function
>  + Teach rebase interactive the reset command
>  + Teach rebase interactive the mark command
>  + Move cleanup code into it's own function
>  + Don't append default merge message to -m message
>  + fake-editor: output TODO list if unchanged
> 
> This may complement the proposed "sequencer" GSoC project.  Dscho seems 
> to have quite a strong objection to the 'mark' syntax and mechanism 
> being unnecessarily complex.  Let's wait and see if a less complex but 
> equally expressive alternative materializes...

Yeah, I know.  My backlog is growing and growing.

Ciao,
Dscho

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

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> * js/config-cb (Wed May 14 18:46:53 2008 +0100) 1 commit
>>  - Provide git_config with a callback-data parameter
>> 
>> This needs to wait until most of the other things graduate for 1.5.6; 
>> luckily, unlike the other "path-list" changes, misconversions is much 
>> easier to catch for this change and I am not worried about it.
>
> Just let me know when to resubmit, and against what branch(es).

It is probably easier for me to munge the original submission from you
when I decide to tag -rc0, adjusting any potential new callers (I do not
think of any offhand in diff between master and next).  We will need a
quiescent time for this kind of change, and that way we will get such a
quiescent window by definition.

>> * js/mailinfo (Fri May 16 14:03:30 2008 +0100) 1 commit
>>  - <<PARK - BASE64 and QP still broken>> mailsplit and mailinfo:
>>    gracefully handle NUL characters
>> 
>> When "am" processes a patch that modifies a line with NUL, we used to
>> chomp the patch line there, resulting in rejects.  This patch fixes the
>> issue partially, only when the message is not encoded in BASE64 nor
>> Quoted-Printable.

> Like I said, I would be happy if Tommy took care of that patch.

I dunno.  Is it likely to happen?  I'd take a look at it myself when I
have a chance.

>> * js/ignore-submodule (Wed May 14 18:03:59 2008 +0100) 3 commits
>>  + Ignore dirty submodule states during rebase and stash
>>  + Teach update-index about --ignore-submodules
>>  + diff options: Introduce --ignore-submodules
>
> I haven't heard back from you about renaming that option.  I think I 
> suggested --non-gitlinks or something equally discouraging for 
> porcelain users.

The name is fine.  I had more trouble with what it does, rather, what it
doesn't --- it does not ignore typechange that involve a gitlink if I
recall correctly.

>> * db/clone-in-c (Tue May 20 14:15:14 2008 -0400) 11 commits
>>  + clone: fall back to copying if hardlinking fails
>>  + builtin-clone.c: Need to closedir() in copy_or_link_directory()
>>  + builtin-clone: fix initial checkout
>>  + Build in clone
>>  + Provide API access to init_db()
>>  + Add a function to set a non-default work tree
>>  + Allow for having for_each_ref() list extra refs
>>  + Have a constant extern refspec for "--tags"
>>  + Add a library function to add an alternate to the alternates file
>>  + Add a lockfile function to append to a file
>>  + Mark the list of refs to fetch as const
>
> Fingers crossed.

Rather, uncross them and type a few more tests ;-)?

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

[Daniel Barkalow]

On Thu, 22 May 2008, Junio C Hamano wrote:

> >> * db/clone-in-c (Tue May 20 14:15:14 2008 -0400) 11 commits
> >>  + clone: fall back to copying if hardlinking fails
> >>  + builtin-clone.c: Need to closedir() in copy_or_link_directory()
> >>  + builtin-clone: fix initial checkout
> >>  + Build in clone
> >>  + Provide API access to init_db()
> >>  + Add a function to set a non-default work tree
> >>  + Allow for having for_each_ref() list extra refs
> >>  + Have a constant extern refspec for "--tags"
> >>  + Add a library function to add an alternate to the alternates file
> >>  + Add a lockfile function to append to a file
> >>  + Mark the list of refs to fetch as const
> >
> > Fingers crossed.
> 
> Rather, uncross them and type a few more tests ;-)?

There are a few tests from Johan that didn't get in, which I'd had in my 
tree but didn't send because I don't have a good process in place for 
sending patches I'm not the author of. I'm pretty sure they pass, but I 
haven't checked recently. I'll send them in a moment.

	-Daniel
*This .sig left intentionally blank*

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

[Stephan Beyer]

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

Hi,

> > * js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
esp.
> >  + Teach rebase interactive the merge command
> >  + Teach rebase interactive the reset command
> >  + Teach rebase interactive the mark command
[...]
>
> Yeah, I know.  My backlog is growing and growing.

I think, this week we get the git-sequencer "spec" ready to be sent
to the list.
Then there's a new thread to discuss ;-)

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

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

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

It's been a while since the last issue of this series.  I've been
swamped, and haven't had a chance to spend enough time on reviewing and
accepting patches.

A rough timeline from now on.

 * 1.5.6-rc0 has been tagged.  Expect a few minor breakages ;-)

 * Fixes of 'master' continues, with newer -rcX tagged every once in a
   while.

 * 1.5.6 Final (2008-06-08).

There are a few known breakages I want to see addressed that are not in
here before 1.5.6 (no not any new features but pure bugfixes).

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

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 - Introduce fast forward option only
 - Head reduction before selecting merge strategy
 - Restructure git-merge.sh
 - Introduce -ff=<fast forward option>
 - New merge tests
 - Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C but it appears
neither will happen by 1.5.6 anyway.

* jc/diff-no-no-index (Fri May 23 22:28:56 2008 -0700) 3 commits
 + "git diff": do not ignore index without --no-index
 + diff-files: do not play --no-index games
 + tests: do not use implicit "git diff --no-index"

This was done in response to recently discovered interaction with stgit;
we were too eater to invoke --no-index behaviour without being asked.
Currently it even drops the behaviour when you ask to compare two paths
that are outside of git work tree if your current directory is inside it,
which I think could safely resurrect, and then the whole thing will be
ready for 1.5.6.

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

* js/config-cb (Wed May 14 18:46:53 2008 +0100) 1 commit
 + Provide git_config with a callback-data parameter

* jc/apply-whitespace (Sat May 17 02:02:44 2008 -0700) 3 commits
 + builtin-apply: do not declare patch is creation when we do not
   know it
 + builtin-apply: accept patch to an empty file
 + builtin-apply: typofix

We were loose when parsing a patch that adds contents to an empty file.
This fix would be nice to have in 1.5.6.

* js/mailinfo (Fri May 16 14:03:30 2008 +0100) 3 commits
 + mailsplit: minor clean-up in read_line_with_nul()
 + mailinfo: apply the same fix not to lose NULs in BASE64 and QP
   codepaths
 + mailsplit and mailinfo: gracefully handle NUL characters

When "am" processes a patch that modifies a line with NUL, we used to
chomp the patch line there, resulting in rejects.  This patch fixes the
issue partially, only when the message is not encoded in BASE64 nor
Quoted-Printable.  I suspect its handling of a MIME attachment may still
wrong, but otherwise this should fix the breakage reported earlier.

* mo/cvsserver (Wed May 14 22:35:48 2008 -0600) 3 commits
 + git-cvsserver: add ability to guess -kb from contents
 + implement gitcvs.usecrlfattr
 + git-cvsserver: add mechanism for managing working tree and current
   directory

* js/cvsexportcommit (Wed May 14 15:29:49 2008 +0100) 2 commits
 + cvsexportcommit: introduce -W for shared working trees (between
   Git and CVS)
 + cvsexportcommit: chomp only removes trailing whitespace

CVS interoperability improvements.

* ar/t6031 (Sun May 18 16:57:27 2008 +0200) 1 commit
 + Fix t6031 on filesystems without working exec bit

* jc/unpack-trees-reword (Sat May 17 12:03:49 2008 -0700) 1 commit
 + unpack-trees: allow Porcelain to give different error messages

Makes safety message from "git checkout switch-to-this-branch" a bit
easier to read, and opens up the possibility to reword messages from other
commands that use unpack-trees machinery.

* jc/add-n-u (Wed May 21 12:04:34 2008 -0700) 1 commit
 + "git-add -n -u" should not add but just report

* js/ignore-submodule (Wed May 14 18:03:59 2008 +0100) 3 commits
 + Ignore dirty submodule states during rebase and stash
 + Teach update-index about --ignore-submodules
 + diff options: Introduce --ignore-submodules

* sp/ignorecase (Thu May 15 07:19:54 2008 +0200) 5 commits
 + t0050: Fix merge test on case sensitive file systems
 + t0050: Add test for case insensitive add
 + t0050: Set core.ignorecase case to activate case insensitivity
 + t0050: Test autodetect core.ignorecase
 + git-init: autodetect core.ignorecase

* bc/repack (Thu May 15 22:37:31 2008 -0400) 6 commits
 + Documentation/git-repack.txt: document new -A behaviour
 + let pack-objects do the writing of unreachable objects as loose
   objects
 + add a force_object_loose() function
 + builtin-gc.c: deprecate --prune, it now really has no effect
 + git-gc: always use -A when manually repacking
 + repack: modify behavior of -A option to leave unreferenced objects
   unpacked

* db/clone-in-c (Tue May 20 14:15:14 2008 -0400) 11 commits
 + clone: fall back to copying if hardlinking fails
 + builtin-clone.c: Need to closedir() in copy_or_link_directory()
 + builtin-clone: fix initial checkout
 + Build in clone
 + Provide API access to init_db()
 + Add a function to set a non-default work tree
 + Allow for having for_each_ref() list extra refs
 + Have a constant extern refspec for "--tags"
 + Add a library function to add an alternate to the alternates file
 + Add a lockfile function to append to a file
 + Mark the list of refs to fetch as const

* pb/push (Mon Apr 28 11:32:12 2008 -0400) 1 commit
 + add special "matching refs" refspec

This first patch is a good enhancement without hurting any existing users.
We need a staged introduction of the second and later patches, and many
people including me did not agree the later ones in the series are
desirable.

* ap/svn (Mon May 12 17:09:49 2008 -0700) 4 commits
 + git-svn: add test for --add-author-from and --use-log-author
 + git-svn: add documentation for --add-author-from option.
 + git-svn: Add --add-author-from option.
 + git-svn: add documentation for --use-log-author option.

Some tweak for output might be needed, but I'll leave that to actual
git-svn users.

* ar/batch-cat (Wed Apr 23 15:17:47 2008 -0400) 13 commits
 + change quoting in test t1006-cat-file.sh
 + builtin-cat-file.c: use parse_options()
 + git-svn: Speed up fetch
 + Git.pm: Add hash_and_insert_object and cat_blob
 + Git.pm: Add command_bidi_pipe and command_close_bidi_pipe
 + git-hash-object: Add --stdin-paths option
 + Add more tests for git hash-object
 + Move git-hash-object tests from t5303 to t1007
 + git-cat-file: Add --batch option
 + git-cat-file: Add --batch-check option
 + git-cat-file: Make option parsing a little more flexible
 + git-cat-file: Small refactor of cmd_cat_file
 + Add tests for git cat-file

The series is meant to speed up git-svn by avoiding many individual
invocations of git-cat-file, started by Adam Roben and finished by Michele
Ballabio.

----------------------------------------------------------------
[Stalled]

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

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.

This needs debugging.

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the tip commit on the series).

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 + Use perl instead of tac
 + Fix t3404 assumption that `wc -l` does not use whitespace.
 + rebase -i: Use : in expr command instead of match.
 + rebase -i: update the implementation of 'mark' command
 + Add option --preserve-tags
 + Teach rebase interactive the tag command
 + Add option --first-parent
 + Do rebase with preserve merges with advanced TODO list
 + Select all lines with fake-editor
 + Unify the length of $SHORT* and the commits in the TODO list
 + Teach rebase interactive the merge command
 + Move redo merge code in a function
 + Teach rebase interactive the reset command
 + Teach rebase interactive the mark command
 + Move cleanup code into it's own function
 + Don't append default merge message to -m message
 + fake-editor: output TODO list if unchanged

This may complement the proposed "sequencer" GSoC project.  Dscho seems to
have quite a strong objection to the 'mark' syntax and mechanism being
unnecessarily complex.  Let's wait and see if a less complex but equally
expressive alternative materializes...

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

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 - Eliminate an unnecessary chdir("..")
 - Add support for GIT_CEILING_DIRECTORIES
 - Fold test-absolute-path into test-path-utils
 - Implement normalize_absolute_path

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

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 - merge: remove deprecated summary and diffstat options and config
   variables

This needs to be held back, as it actually removes the support for
features that the main part of the series deprecates, until 1.6.0 or
later.

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time 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

Just my toy at this moment.

* jc/diff-words (Sun May 11 12:33:48 2008 -0700) 2 commits
 - diff --color-words: a bit of tweak
 - diff --color-words reimplementation

This series did not pan out well.  I briefly thought that perhaps I should
discard them and replace with the "not just whitespace" one from Ping Yin
first, hoping that we can clean the overall logic up later, but perhaps
the whole thing can get a fresh restart after 1.5.6.  I'll drop this
altogether the next round.

[PATCH] git-diff: allow --no-index semantics a bit more

[Junio C Hamano]

Even when inside a git work tree, if two paths are given and at least one
is clearly outside the work tree, it cannot be a request to diff a tracked
path anyway; allow such an invocation to use --no-index semantics.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 > * jc/diff-no-no-index (Fri May 23 22:28:56 2008 -0700) 3 commits
 >  + "git diff": do not ignore index without --no-index
 >  + diff-files: do not play --no-index games
 >  + tests: do not use implicit "git diff --no-index"
 >
 > This was done in response to recently discovered interaction with stgit;
 > we were too eater to invoke --no-index behaviour without being asked.
 > Currently it even drops the behaviour when you ask to compare two paths
 > that are outside of git work tree if your current directory is inside it,
 > which I think could safely resurrect, and then the whole thing will be
 > ready for 1.5.6.

 And this should hopefully be enough.

 diff-no-index.c |   39 ++++++++++++++++++++++++++++++++-------
 1 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/diff-no-index.c b/diff-no-index.c
index 1b57fee..b1ae791 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -144,6 +144,25 @@ static int queue_diff(struct diff_options *o,
 	}
 }
 
+static int path_outside_repo(const char *path)
+{
+	/*
+	 * We have already done setup_git_directory_gently() so we
+	 * know we are inside a git work tree already.
+	 */
+	const char *work_tree;
+	size_t len;
+
+	if (!is_absolute_path(path))
+		return 0;
+	work_tree = get_git_work_tree();
+	len = strlen(work_tree);
+	if (strncmp(path, work_tree, len) ||
+	    (path[len] != '\0' && path[len] != '/'))
+		return 1;
+	return 0;
+}
+
 void diff_no_index(struct rev_info *revs,
 		   int argc, const char **argv,
 		   int nongit, const char *prefix)
@@ -162,13 +181,19 @@ void diff_no_index(struct rev_info *revs,
 			break;
 	}
 
-	/*
-	 * No explicit --no-index, but "git diff --opts A B" outside
-	 * a git repository is a cute hack to support.
-	 */
-	if (!no_index && !nongit)
-		return;
-
+	if (!no_index && !nongit) {
+		/*
+		 * Inside a git repository, without --no-index.  Only
+		 * when a path outside the repository is given,
+		 * e.g. "git diff /var/tmp/[12]", or "git diff
+		 * Makefile /var/tmp/Makefile", allow it to be used as
+		 * a colourful "diff" replacement.
+		 */
+		if ((argc != i + 2) ||
+		    (!path_outside_repo(argv[i]) &&
+		     !path_outside_repo(argv[i+1])))
+			return;
+	}
 	if (argc != i + 2)
 		die("git diff %s takes two paths",
 		    no_index ? "--no-index" : "[--no-index]");
-- 
1.5.6.rc0.13.g2d392

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

It's been a while since the last issue of this series.  I've been
swamped, and haven't had a chance to spend enough time on reviewing and
accepting patches.

A rough timeline from now on.

 * Fixes of 'master' continues, with newer -rcX tagged every once in a
   while.

 * 1.5.6 Final (2008-06-08 -- likely to slip by a week or so, though).

There are a few known breakages I want to see addressed that are not in
here before 1.5.6 (no not any new features but pure bugfixes).

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

* jc/checkout (Wed May 28 16:11:16 2008 -0700) 5 commits
 - PARK: NUL hack to entry
 - checkout: "best effort" checkout
 - unpack_trees(): allow callers to differentiate worktree errors
   from merge errors
 - checkout: consolidate reset_{to_new,clean_to_new|()
 - checkout: make reset_clean_to_new() not die by itself

* lr/init-bare (Wed May 28 19:53:57 2008 +0100) 1 commit
 - git-init: accept --bare option

This makes both "git --bare init" and "git init --bare" work, which would
reduce confusion.  I am tempted to include it in 1.5.6.  Comments?

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

* jc/diff-no-no-index (Mon May 26 22:35:07 2008 -0700) 5 commits
 + git diff --no-index: default to page like other diff frontends
 + git-diff: allow  --no-index semantics a bit more
 + "git diff": do not ignore index without --no-index
 + diff-files: do not play --no-index games
 + tests: do not use implicit "git diff --no-index"

This was done in response to recently discovered interaction with stgit;
we were too eater to invoke --no-index behaviour without being asked.

----------------------------------------------------------------
[Stalled]

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

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.

This needs debugging.

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the tip commit on the series).

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 + Use perl instead of tac
 + Fix t3404 assumption that `wc -l` does not use whitespace.
 + rebase -i: Use : in expr command instead of match.
 + rebase -i: update the implementation of 'mark' command
 + Add option --preserve-tags
 + Teach rebase interactive the tag command
 + Add option --first-parent
 + Do rebase with preserve merges with advanced TODO list
 + Select all lines with fake-editor
 + Unify the length of $SHORT* and the commits in the TODO list
 + Teach rebase interactive the merge command
 + Move redo merge code in a function
 + Teach rebase interactive the reset command
 + Teach rebase interactive the mark command
 + Move cleanup code into it's own function
 + Don't append default merge message to -m message
 + fake-editor: output TODO list if unchanged

This may complement the proposed "sequencer" GSoC project.  Dscho seems to
have quite a strong objection to the 'mark' syntax and mechanism being
unnecessarily complex.  Let's wait and see if a less complex but equally
expressive alternative materializes...

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 - Introduce fast forward option only
 - Head reduction before selecting merge strategy
 - Restructure git-merge.sh
 - Introduce -ff=<fast forward option>
 - New merge tests
 - Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C but it appears
neither will happen by 1.5.6 anyway.

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 - Eliminate an unnecessary chdir("..")
 - Add support for GIT_CEILING_DIRECTORIES
 - Fold test-absolute-path into test-path-utils
 - Implement normalize_absolute_path

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

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 - merge: remove deprecated summary and diffstat options and config
   variables

This needs to be held back, as it actually removes the support for
features that the main part of the series deprecates, until 1.6.0 or
later.

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time 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

Just my toy at this moment.

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

[Jon Loeliger]

Junio C Hamano wrote:
> Here are the topics that have been cooking.  Commits prefixed
> with '-' are only in 'pu' while commits prefixed with '+' are
> in 'next'.
> 
>
> * js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
>  + Use perl instead of tac
>  + Fix t3404 assumption that `wc -l` does not use whitespace.
>  + rebase -i: Use : in expr command instead of match.
>  + rebase -i: update the implementation of 'mark' command
>  + Add option --preserve-tags
>  + Teach rebase interactive the tag command
>  + Add option --first-parent
>  + Do rebase with preserve merges with advanced TODO list
>  + Select all lines with fake-editor
>  + Unify the length of $SHORT* and the commits in the TODO list
>  + Teach rebase interactive the merge command
>  + Move redo merge code in a function
>  + Teach rebase interactive the reset command
>  + Teach rebase interactive the mark command
>  + Move cleanup code into it's own function
>  + Don't append default merge message to -m message
>  + fake-editor: output TODO list if unchanged
> 
> This may complement the proposed "sequencer" GSoC project.  Dscho seems to
> have quite a strong objection to the 'mark' syntax and mechanism being
> unnecessarily complex.  Let's wait and see if a less complex but equally
> expressive alternative materializes...


Well, there are the two not-quite facetious suggestions
I made off list to Junio.  Granted, he though they would
be overkill (too), but I guess I could make them here for
the general record in any case.

One suggestion was to make a procedural model out of
the commit graph and allow something like this:

    b :- pick(B)
    x :- merge(pick(A), b)
    y :- merge(pick(C), b)
    z :- merge(x, y)

My second and semi-equivallent suggestion was to
allow a lisp-like notation:

    (merge (merge (pick A)
                  (pick B)
           (merge (pick B)
                  (pick C)

As Junio observed, even that could be beyond what most
casual git rebase -i users are willing to do to a sequencer
edit stream before getting down to business.

Ah well. :-)

jdl

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

[Stephan Beyer]

Hi,

> One suggestion was to make a procedural model out of
> the commit graph and allow something like this:
>
>    b :- pick(B)
>    x :- merge(pick(A), b)
>    y :- merge(pick(C), b)
>    z :- merge(x, y)

Nice idea.  But imho too hard for casual users.
Someone who has to learn a new language won't use the tool.

> My second and semi-equivallent suggestion was to
> allow a lisp-like notation:
>
>    (merge (merge (pick A)
>                  (pick B)
>           (merge (pick B)
>                  (pick C)

You forgot some right parenthesis here ;-)
...which shows, that it is also not easy enough for users.

Or is it intentional?

:)
Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

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

[Steven Grimm]

On May 30, 2008, at 1:44 PM, Junio C Hamano wrote:
> [Stalled]
>
> * dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
> - Eliminate an unnecessary chdir("..")
> - Add support for GIT_CEILING_DIRECTORIES
> - Fold test-absolute-path into test-path-utils
> - Implement normalize_absolute_path


The most recent version of this patch seemed to come and go without  
any commentary one way or the other. What are people's objections to  
it as it stands now?

-Steve

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

It's been a while since the last issue of this series.  I've been
swamped, and haven't had a chance to spend enough time on reviewing and
accepting patches.

A rough timeline from now on.

 * Fixes of 'master' continues, with newer -rcX tagged every once in a
   while.  I'd like to tag -rc1 in a few days.

 * 1.5.6 Final (2008-06-08 -- likely to slip by a week or so, though).

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

* lw/gitweb (Sat May 31 16:19:24 2008 +0200) 2 commits
 - gitweb: use Git.pm, and use its parse_rev method for
   git_get_head_hash
 - perl/Git.pm: add parse_rev method

I do not necessarily think it is an improvement to name the operation
called as "rev-parse" at the plumbing layer with a different name
"get_hash" as the later round of this series does.

As I mentioned on the list, I think the "PERL5LIB fix" I squashed in was a
misguided workaround to a wrong problem; if we are making gitweb.perl to
use Git.pm, I think we should do the same GITPERLLIB trick we do to other
perl scripts for consistency.

I've looked at the Git.pm testsuite that uses Test::More briefly but
hadn't really reviewed it.  Is Test::More commonly used, considered solid
and widely available?

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

* lw/test-fix (Sat May 31 23:11:21 2008 +0200) 1 commit
 + t/test-lib.sh: resolve symlinks in working directory, for pathname
   comparisons

* sb/am-tests (Sun Jun 1 00:11:43 2008 +0200) 2 commits
 + Merge t4150-am-subdir.sh and t4151-am.sh into t4150-am.sh
 + Add test cases for git-am

* lt/pack-sync (Fri May 30 08:54:46 2008 -0700) 2 commits
 + Remove now unnecessary 'sync()' calls
 + Make pack creation always fsync() the result

* sp/remote (Sun Jun 1 00:28:04 2008 -0400) 3 commits
 + Make "git-remote rm" delete refs acccording to fetch specs
 + Make "git-remote prune" delete refs according to fetch specs
 + Remove unused remote_prefix member in builtin-remote

"git-remote" had an unwarranted assumption that everybody uses
refs/remotes/$it namespace to track remote repository called $it.  This
series is a reasonable fix to it.

* np/pack-check (Thu May 29 17:34:50 2008 -0400) 1 commit
 + make verify-pack a bit more useful with bad packs

* lr/init-bare (Wed May 28 19:53:57 2008 +0100) 1 commit
 + git-init: accept --bare option

This makes both "git --bare init" and "git init --bare" work, which would
reduce confusion.

* jc/checkout (Wed May 28 16:11:16 2008 -0700) 4 commits
 + checkout: "best effort" checkout
 + unpack_trees(): allow callers to differentiate worktree errors
   from merge errors
 + checkout: consolidate reset_{to_new,clean_to_new|()
 + checkout: make reset_clean_to_new() not die by itself

This "fix" seems to help real-world users.

* jb/reset-q (Sat May 31 18:10:58 2008 -0700) 1 commit
 + git-reset: honor -q and do not show progress message

----------------------------------------------------------------
[Stalled]

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

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.

This needs debugging.

* jc/blame (Wed Apr 2 22:17:53 2008 -0700) 5 commits
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the tip commit on the series).

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 + Use perl instead of tac
 + Fix t3404 assumption that `wc -l` does not use whitespace.
 + rebase -i: Use : in expr command instead of match.
 + rebase -i: update the implementation of 'mark' command
 + Add option --preserve-tags
 + Teach rebase interactive the tag command
 + Add option --first-parent
 + Do rebase with preserve merges with advanced TODO list
 + Select all lines with fake-editor
 + Unify the length of $SHORT* and the commits in the TODO list
 + Teach rebase interactive the merge command
 + Move redo merge code in a function
 + Teach rebase interactive the reset command
 + Teach rebase interactive the mark command
 + Move cleanup code into it's own function
 + Don't append default merge message to -m message
 + fake-editor: output TODO list if unchanged

This may complement the proposed "sequencer" GSoC project.  Dscho seems to
have quite a strong objection to the 'mark' syntax and mechanism being
unnecessarily complex.  Let's wait and see if a less complex but equally
expressive alternative materializes...

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 - Introduce fast forward option only
 - Head reduction before selecting merge strategy
 - Restructure git-merge.sh
 - Introduce -ff=<fast forward option>
 - New merge tests
 - Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C but it appears
neither will happen by 1.5.6 anyway.

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 - Eliminate an unnecessary chdir("..")
 - Add support for GIT_CEILING_DIRECTORIES
 - Fold test-absolute-path into test-path-utils
 - Implement normalize_absolute_path

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

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 - merge: remove deprecated summary and diffstat options and config
   variables

This needs to be held back, as it actually removes the support for
features that the main part of the series deprecates, until 1.6.0 or
later.

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time 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

Just my toy at this moment.

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

[Jakub Narebski]

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

> I've looked at the Git.pm testsuite that uses Test::More briefly but
> hadn't really reviewed it.  Is Test::More commonly used, considered solid
> and widely available?

It is part of perl-5.8.6-24 RPM package in Fedora Core 4.
It is mentioned in http://www.perlfoundation.org/perl5/index.cgi?testing
 
> ----------------------------------------------------------------
> [Graduated to "master"]
> 
> * lr/init-bare (Wed May 28 19:53:57 2008 +0100) 1 commit
>  + git-init: accept --bare option
> 
> This makes both "git --bare init" and "git init --bare" work, which would
> reduce confusion.

Nice.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Sebastian Bober]

On Mon, Jun 02, 2008 at 12:58:03AM -0700, Junio C Hamano wrote:
> 
> I've looked at the Git.pm testsuite that uses Test::More briefly but
> hadn't really reviewed it.  Is Test::More commonly used, considered solid
> and widely available?

yes it is on all three points. It is the most commonly used test module
for Perl, used by thousands of CPAN distributions. Test::More is
delivered as core module since 5.8.0 or 5.6.2, so is widely deployed. It
is actively maintained and is integrated in a test framework that allows
the use and development of further "plug-in" test modules. With that
it's conceivable to write a test module specifically for git and its
usage scenarios.

Regards,
  Sebastian

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

[Johannes Schindelin]

Hi,

On Mon, 2 Jun 2008, Junio C Hamano wrote:

> * sp/remote (Sun Jun 1 00:28:04 2008 -0400) 3 commits
>  + Make "git-remote rm" delete refs acccording to fetch specs
>  + Make "git-remote prune" delete refs according to fetch specs
>  + Remove unused remote_prefix member in builtin-remote
> 
> "git-remote" had an unwarranted assumption that everybody uses 
> refs/remotes/$it namespace to track remote repository called $it.  This 
> series is a reasonable fix to it.

AFAIR this limitation was already in the scripted version, and I tried to 
wrap my head around lifting it.  However, I did not end up with the 
brillian analysis of Shawn, and was almost sending a reply contradicting 
his logic.  However, I agree with Shawn that it is the same issue as 
contradicting fetches, so if it leads to problems, it is a pilot error.

_However_, I still try to come up with some attic for deleted refs.  It is 
not just a matter of moving the logs to a different namespace because of 
D/F conflicts.

Ciao,
Dscho

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

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> _However_, I still try to come up with some attic for deleted refs.  It is 
> not just a matter of moving the logs to a different namespace because of 
> D/F conflicts.

Record the delete at the end of the reflog so we have a date/time
record and the last SHA-1 value, just in case it doesn't match up
with the most recent reflog entry (e.g. user ran some legacy tool
that just redirect git-commit-tree output to the branch itself).

Take the SHA-1 hash of the reflog now that the final entry is
written.  Rename the file to .git/attic/$sha1 and call it a day.
I thought about compressing the file too, but its not worth saving
the disk space here and it would make tools that inspect the attic
expensive to run.

The attic can be easily cleaned out by looking at the timestamp of
the last record of each file.  Attic log files older than X days can
be removed.  This is better than reading the modification time of
the file as we don't have to worry about some copy tool not saving
the modification time if the user moves/copies the repository.

That's all the easy stuff.

The hard stuff is:

- Should the commits listed in attic reflogs be considered reachable
  when we pack, prune or fsck?  Commits in a reflog are, even if
  they aren't reachable from a transport perspective.

- What command gets the extra options to see what branches are in
  the attic and when they got there?

- What command gets the extra option to recover a branch from the
  attic?

- When we recover a branch from the attic is it sufficient to recover
  it to the name it had at time of deletion?  Should we allow you to
  recover it to a different name?

- Is it sufficient to make you recover the branch from the attic
  before you can access the rest of its reflog with porcelain?

- What do we do if we recover a branch with stale reflog entries
  and the attic is deemed to not be reachable (see above).

-- 
Shawn.

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

[Johannes Schindelin]

Hi,

On Mon, 2 Jun 2008, Shawn O. Pearce wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > _However_, I still try to come up with some attic for deleted refs.  
> > It is not just a matter of moving the logs to a different namespace 
> > because of D/F conflicts.
> 
> Record the delete at the end of the reflog so we have a date/time record 
> and the last SHA-1 value, just in case it doesn't match up with the most 
> recent reflog entry (e.g. user ran some legacy tool that just redirect 
> git-commit-tree output to the branch itself).

That's obvious.

> Take the SHA-1 hash of the reflog now that the final entry is written.  
> Rename the file to .git/attic/$sha1 and call it a day. I thought about 
> compressing the file too, but its not worth saving the disk space here 
> and it would make tools that inspect the attic expensive to run.
> 
> The attic can be easily cleaned out by looking at the timestamp of the 
> last record of each file.  Attic log files older than X days can be 
> removed.  This is better than reading the modification time of the file 
> as we don't have to worry about some copy tool not saving the 
> modification time if the user moves/copies the repository.

I actually would prefer to have the logs in the .git/logs/ directory, so 
that I can easily reuse all existing reflog handling.

After sending the mail, I actually got an idea:

	.git/logs/attic/<timestamp>/<refname>

I think this should work without problems.  In that case, git-gc also 
handles the garbage collection.

> The hard stuff is:
> 
> - Should the commits listed in attic reflogs be considered reachable 
>   when we pack, prune or fsck?  Commits in a reflog are, even if they 
>   aren't reachable from a transport perspective.

Yes, they should.  That is the whole purpose of keeping the reflogs: I 
want to be able to resurrect the branch, if I deleted it by accident.

> - What command gets the extra options to see what branches are in the 
>   attic and when they got there?

I'd like to have them listed with the other reflogs.

> - What command gets the extra option to recover a branch from the attic?

None.  It is the user's responsibility to use the information wisely.

git branch resurrected attic/<bla>/refs/heads/accidentally-deleted@{1}

> - When we recover a branch from the attic is it sufficient to recover it 
>   to the name it had at time of deletion?  Should we allow you to 
>   recover it to a different name?

See above.  I think resurrecting under the same name would not necessarily 
be the most frequent operation on deleted refs.

> - Is it sufficient to make you recover the branch from the attic before 
>   you can access the rest of its reflog with porcelain?
> 
> - What do we do if we recover a branch with stale reflog entries
>   and the attic is deemed to not be reachable (see above).

I'll just go with my idea, implement it, and post it here for discussion.

Ciao,
Dscho

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

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> After sending the mail, I actually got an idea:
>
> 	.git/logs/attic/<timestamp>/<refname>
>
> I think this should work without problems.  In that case, git-gc also 
> handles the garbage collection.

I do not like that particular color of the bikeshed, but I'd agree that it
certainly is the easiest route from both the implementation and the design
point of view.  All of the "hard stuff" Shawn mentions goes away, and you 
are left with only one new "hard stuff", which is much easier to solve:

 - Should there be a way to really remove the archived reflog?

And my answer is "yes, a new subcommand to 'git-reflog' to list and
another subcommand to remove one".

As to default behaviour, probably we would by default archive any local
branches, and _not_ archive other things like remote trackers and tags.  A
new configuration variable reflog.archive = {none,heads,all} would be
honored and absense of it defaults to reflog.archive = heads.

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

[Johannes Schindelin]

Hi,

On Mon, 2 Jun 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > After sending the mail, I actually got an idea:
> >
> > 	.git/logs/attic/<timestamp>/<refname>
> >
> > I think this should work without problems.  In that case, git-gc also 
> > handles the garbage collection.
> 
> I do not like that particular color of the bikeshed, but I'd agree that 
> it certainly is the easiest route from both the implementation and the 
> design point of view.

Okay, how about "deleted-%d.%m.%Y-%H:%M:%S" instead of "attic/%s"?

> All of the "hard stuff" Shawn mentions goes away, and you are left with 
> only one new "hard stuff", which is much easier to solve:
> 
>  - Should there be a way to really remove the archived reflog?
> 
> And my answer is "yes, a new subcommand to 'git-reflog' to list and
> another subcommand to remove one".

You mean a subcommand to list just the refs that exist in the deleted-* 
namespace?

As to remove one, how about:

	 git reflog --expire=now --expire-unreachable=now \
		deleted-<date>/<refname>

Hmm?

> As to default behaviour, probably we would by default archive any local 
> branches, and _not_ archive other things like remote trackers and tags.  

Unfortunately, this is exactly what I need: remote trackers and tags.  
Since I have to delete branches from repo.or.cz as long as the pruning of 
forked projects' objects does not work correctly.

> A new configuration variable reflog.archive = {none,heads,all} would be 
> honored and absense of it defaults to reflog.archive = heads.

Sure, that makes sense.  I'd just "git config --global reflog.archive 
all".

Ciao,
Dscho

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

[Johannes Schindelin]

Hi,

On Mon, 2 Jun 2008, Johannes Schindelin wrote:

> On Mon, 2 Jun 2008, Junio C Hamano wrote:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 
> > > After sending the mail, I actually got an idea:
> > >
> > > 	.git/logs/attic/<timestamp>/<refname>

Just tried that, and for obvious reasons it fails the testsuite: Git is 
just too darned fast.

Ciao,
Dscho

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

It's been a while since the last issue of this series.  I've been
swamped, and haven't had a chance to spend enough time on reviewing and
accepting patches.

A rough timeline from now on.

 * 1.5.6-rc3 this weekend.

 * 1.5.6 Final (2008-06-20).

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

* jn/web (Tue Jun 10 19:21:44 2008 +0200) 2 commits
 - gitweb: Separate generating 'sort by' table header
 - gitweb: Separate filling list of projects info

* rs/archive-ignore (Sun Jun 8 18:42:33 2008 +0200) 1 commit
 + Teach new attribute 'export-ignore' to git-archive

* rg/gitweb (Fri Jun 6 09:53:32 2008 +0200) 1 commit
 + gitweb: remove git_blame and rename git_blame2 to git_blame

* kh/update-ref (Tue Jun 3 01:34:53 2008 +0200) 2 commits
 + Make old sha1 optional with git update-ref -d
 + Clean up builtin-update-ref's option parsing

* mo/status-untracked (Thu Jun 5 14:47:50 2008 +0200) 3 commits
 - Add configuration option for default untracked files mode
 - Add argument 'no' commit/status option -u|--untracked-files
 - Add an optional <mode> argument to commit/status -u|--untracked-
   files option

* rs/attr (Sun Jun 8 17:16:11 2008 +0200) 1 commit
 + Ignore .gitattributes in bare repositories

* sr/tests (Sun Jun 8 16:04:35 2008 +0200) 3 commits
 + Hook up the result aggregation in the test makefile.
 + A simple script to parse the results from the testcases
 + Modify test-lib.sh to output stats to t/test-results/*

None of the above are 1.5.6 material, except for the "ignore
.gitattributes file in bare repositories" from René, which I think we
should have.

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

Nothing this week.

----------------------------------------------------------------
[Stalled]

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

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.

This needs debugging.

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 + Use perl instead of tac
 + Fix t3404 assumption that `wc -l` does not use whitespace.
 + rebase -i: Use : in expr command instead of match.
 + rebase -i: update the implementation of 'mark' command
 + Add option --preserve-tags
 + Teach rebase interactive the tag command
 + Add option --first-parent
 + Do rebase with preserve merges with advanced TODO list
 + Select all lines with fake-editor
 + Unify the length of $SHORT* and the commits in the TODO list
 + Teach rebase interactive the merge command
 + Move redo merge code in a function
 + Teach rebase interactive the reset command
 + Teach rebase interactive the mark command
 + Move cleanup code into it's own function
 + Don't append default merge message to -m message
 + fake-editor: output TODO list if unchanged

This may complement the proposed "sequencer" GSoC project.  Dscho seems to
have quite a strong objection to the 'mark' syntax and mechanism being
unnecessarily complex.  Let's wait and see if a less complex but equally
expressive alternative materializes...

It is very likely that this whole thing will be reverted from 'next' and
be replaced with the new sequenser series during 1.6.0 cycle.

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 - Introduce fast forward option only
 - Head reduction before selecting merge strategy
 - Restructure git-merge.sh
 - Introduce -ff=<fast forward option>
 - New merge tests
 - Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C but it appears
neither will happen by 1.5.6 anyway.

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 - Eliminate an unnecessary chdir("..")
 - Add support for GIT_CEILING_DIRECTORIES
 - Fold test-absolute-path into test-path-utils
 - Implement normalize_absolute_path

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

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 - merge: remove deprecated summary and diffstat options and config
   variables

This needs to be held back, as it actually removes the support for
features that the main part of the series deprecates, until 1.6.0 or
later.

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time 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

Just my toy at this moment.

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

It's been a while since the last issue of this series.  I've been
swamped, and haven't had a chance to spend enough time on reviewing and
accepting patches.

A rough timeline from now on.

 * 1.5.6 Final (late this week).

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

* jh/clone-packed-refs (Sun Jun 15 16:06:16 2008 +0200) 4 commits
 - Teach "git clone" to pack refs
 - Prepare testsuite for a "git clone" that packs refs
 - Move pack_refs() and friends into libgit
 - Incorporate fetched packs in future object traversal

Would be helpful cloning from a repository with insanely large number of
refs.

* jc/reflog-expire (Sun Jun 15 23:48:46 2008 -0700) 1 commit
 - Per-ref reflog expiry configuration

Perhaps a good foundation for optionally unexpirable stash.

* lw/perlish (Tue Jun 17 08:59:51 2008 +0200) 2 commits
 - Git.pm: add test suite
 - t/test-lib.sh: add test_external and test_external_without_stderr

IO::String dependency is a bit worrysome, and the error diagnostic could
hopefully be made more obvious, but I do not have a fundamental objection
to this series.

* jk/test (Sat Jun 14 03:28:07 2008 -0400) 5 commits
 + enable whitespace checking of test scripts
 + avoid trailing whitespace in zero-change diffstat lines
 + avoid whitespace on empty line in automatic usage message
 + mask necessary whitespace policy violations in test scripts
 + fix whitespace violations in test scripts

Tightens whitespace rules for t/*.sh scripts.

* pb/fast-export (Wed Jun 11 13:17:04 2008 +0200) 1 commit
 - builtin-fast-export: Add importing and exporting of revision marks

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

* rs/attr (Sun Jun 8 17:16:11 2008 +0200) 1 commit
 + Ignore .gitattributes in bare repositories

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

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

Allows common ancestor negotiation for git-push to help people with shared
repository workflow in certain minority situations.  The lack of protocol
support has been bugging me for quite some time, and that was the reason I
did this.

This needs debugging.

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 + Use perl instead of tac
 + Fix t3404 assumption that `wc -l` does not use whitespace.
 + rebase -i: Use : in expr command instead of match.
 + rebase -i: update the implementation of 'mark' command
 + Add option --preserve-tags
 + Teach rebase interactive the tag command
 + Add option --first-parent
 + Do rebase with preserve merges with advanced TODO list
 + Select all lines with fake-editor
 + Unify the length of $SHORT* and the commits in the TODO list
 + Teach rebase interactive the merge command
 + Move redo merge code in a function
 + Teach rebase interactive the reset command
 + Teach rebase interactive the mark command
 + Move cleanup code into it's own function
 + Don't append default merge message to -m message
 + fake-editor: output TODO list if unchanged

It is very likely that this whole thing will be reverted from 'next' and
be replaced with the new sequenser series during 1.6.0 cycle.

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 - Introduce fast forward option only
 - Head reduction before selecting merge strategy
 - Restructure git-merge.sh
 - Introduce -ff=<fast forward option>
 - New merge tests
 - Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C.  There is no
fundamental reason to favor one over the other, so I'll be torn after
1.5.6 happens, but not before.

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 - Eliminate an unnecessary chdir("..")
 - Add support for GIT_CEILING_DIRECTORIES
 - Fold test-absolute-path into test-path-utils
 - Implement normalize_absolute_path

* jn/web (Tue Jun 10 19:21:44 2008 +0200) 2 commits
 - gitweb: Separate generating 'sort by' table header
 - gitweb: Separate filling list of projects info

* rs/archive-ignore (Sun Jun 8 18:42:33 2008 +0200) 1 commit
 + Teach new attribute 'export-ignore' to git-archive

* rg/gitweb (Fri Jun 6 09:53:32 2008 +0200) 1 commit
 + gitweb: remove git_blame and rename git_blame2 to git_blame

* kh/update-ref (Tue Jun 3 01:34:53 2008 +0200) 2 commits
 + Make old sha1 optional with git update-ref -d
 + Clean up builtin-update-ref's option parsing

* mo/status-untracked (Thu Jun 5 14:47:50 2008 +0200) 3 commits
 - Add configuration option for default untracked files mode
 - Add argument 'no' commit/status option -u|--untracked-files
 - Add an optional <mode> argument to commit/status -u|--untracked-
   files option

* sr/tests (Sun Jun 8 16:04:35 2008 +0200) 3 commits
 + Hook up the result aggregation in the test makefile.
 + A simple script to parse the results from the testcases
 + Modify test-lib.sh to output stats to t/test-results/*

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

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 - merge: remove deprecated summary and diffstat options and config
   variables

This needs to be held back, as it actually removes the support for
features that the main part of the series deprecates, until 1.6.0 or
later.

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 - Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time 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

Just my toy at this moment.

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

[Johan Herland]

On Wednesday 18 June 2008, Junio C Hamano wrote:
> [New Topics]
>
> * jh/clone-packed-refs (Sun Jun 15 16:06:16 2008 +0200) 4 commits
>  - Teach "git clone" to pack refs
>  - Prepare testsuite for a "git clone" that packs refs
>  - Move pack_refs() and friends into libgit
>  - Incorporate fetched packs in future object traversal
>
> Would be helpful cloning from a repository with insanely large number of
> refs.

The first 3 patches (i.e. the bottom 3 in the above list) might be 
considered general cleanup patches, and are independent of each other (i.e. 
you might want to include them on their own merit, independently of patch 
#4).

The final patch doesn't make any difference for "regular" repos (e.g. 
git.git with ~200 refs) on Linux (see below). But once the number of refs 
increase, the difference becomes obvious.

Here are some numbers to give some more context:

All tests done on 64-bit quad-core Linux, cloning locally (hard-linked):

~200 refs (git.git):
current next:    0.2s
w/above patches: 0.2s

~1000 refs (test repo):
current next:    0.16s
w/above patches: 0.05s

~11000 refs (test repo):
current next:    1.3s
w/above patches: 0.3s

~26000 refs (actual repo at $dayjob):
current next:    3.2s
w/above patches: 0.8s


Regards,

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

It already is beginning to become clear what 1.6.0 will look like.  What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements.  But bigger changes will be:

 * MinGW will be in.

 * /usr/bin/git-cat-file is no more.  The bulk of the git commands will
   move to /usr/libexec/git-core/ or somesuch.

 * git-merge will be rewritten in C.

Currently tip of 'pu' is broken and does not pass tests, as j6t/mingw has
interaction with dr/ceiling and jc/merge-theirs has interaction with
mv/merge-in-c.

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

* jc/merge-theirs (Fri Jun 20 00:17:59 2008 -0700) 2 commits
 - git-merge-recursive-{ours,theirs}
 - git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends may need to change, though.

* lt/racy-empty (Tue Jun 10 10:44:43 2008 -0700) 1 commit
 + racy-git: an empty blob has a fixed object name

* ph/mergetool (Mon Jun 16 17:33:41 2008 -0600) 1 commit
 + Remove the use of '--' in merge program invocation

* j6t/mingw (Sat Nov 17 20:48:14 2007 +0100) 38 commits
 - compat/pread.c: Add a forward declaration to fix a warning
 - Windows: Fix ntohl() related warnings about printf formatting
 - Windows: TMP and TEMP environment variables specify a temporary
   directory.
 - Windows: Make 'git help -a' work.
 - Windows: Work around an oddity when a pipe with no reader is
   written to.
 - Windows: Make the pager work.
 - When installing, be prepared that template_dir may be relative.
 - Windows: Use a relative default template_dir and ETC_GITCONFIG
 - Windows: Compute the fallback for exec_path from the program
   invocation.
 - Turn builtin_exec_path into a function.
 - Windows: Use a customized struct stat that also has the st_blocks
   member.
 - Windows: Add a custom implementation for utime().
 - Windows: Add a new lstat and fstat implementation based on Win32
   API.
 - Windows: Implement a custom spawnve().
 - Windows: Implement wrappers for gethostbyname(), socket(), and
   connect().
 - Windows: Work around incompatible sort and find.
 - Windows: Implement asynchronous functions as threads.
 - Windows: Disambiguate DOS style paths from SSH URLs.
 - Windows: A rudimentary poll() emulation.
 - Windows: Change the name of hook scripts to make them not
   executable.
 - Windows: Implement start_command().
 - Windows: A pipe() replacement whose ends are not inherited to
   children.
 - Windows: Wrap execve so that shell scripts can be invoked.
 - Windows: Implement setitimer() and sigaction().
 - Windows: Fix PRIuMAX definition.
 - Windows: Implement gettimeofday().
 - Windows: Handle absolute paths in
   safe_create_leading_directories().
 - Windows: Treat Windows style path names.
 - setup.c: Prepare for Windows directory separators.
 - Windows: Work around misbehaved rename().
 - Windows: always chmod(, 0666) before unlink().
 - Windows: A minimal implemention of getpwuid().
 - Windows: Implement a wrapper of the open() function.
 - Windows: Strip ".exe" from the program name.
 - Windows: Use the Windows style PATH separator ';'.
 - Add target architecture MinGW.
 - Compile some programs only conditionally.
 - Add compat/regex.[ch] and compat/fnmatch.[ch].

No explanation is necessary ;-).

* sn/static (Thu Jun 19 08:21:11 2008 +0900) 2 commits
 + config.c: make git_env_bool() static
 + environment.c: remove unused function

* lt/config-fsync (Wed Jun 18 15:18:44 2008 -0700) 4 commits
 + Add config option to enable 'fsync()' of object files
 + Split up default "i18n" and "branch" config parsing into helper
   routines
 + Split up default "user" config parsing into helper routine
 + Split up default "core" config parsing into helper routine

* lw/gitweb (Thu Jun 19 22:03:21 2008 +0200) 1 commit
 + gitweb: standarize HTTP status codes

* mv/merge-in-c (Fri Jun 20 01:22:36 2008 +0200) 11 commits
 - Add new test to ensure git-merge handles more than 25 refs.
 - Build in merge
 - Introduce filter_independent() in commit.c
 - Introduce get_octopus_merge_bases() in commit.c
 - git-fmt-merge-msg: make it usable from other builtins
 - Move read_cache_unmerged() to read-cache.c
 - parseopt: add a new PARSE_OPT_ARGV0_IS_AN_OPTION option
 - Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 - Move parse-options's skip_prefix() to git-compat-util.h
 - Move commit_list_count() to commit.c
 - Move split_cmdline() to alias.c

* jc/maint-combine-diff-pre-context (Wed Jun 18 23:59:41 2008 -0700) 1 commit
 + diff -c/--cc: do not include uninteresting deletion before leading
   context

* lt/maint-gitdir-relative (Thu Jun 19 12:34:06 2008 -0700) 1 commit
 + Make git_dir a path relative to work_tree in setup_work_tree()

----------------------------------------------------------------
[Actively Cooking]

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 + Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 + Eliminate an unnecessary chdir("..")
 + Add support for GIT_CEILING_DIRECTORIES
 + Fold test-absolute-path into test-path-utils
 + Implement normalize_absolute_path

* jn/web (Tue Jun 10 19:21:44 2008 +0200) 2 commits
 + gitweb: Separate generating 'sort by' table header
 + gitweb: Separate filling list of projects info

* rs/archive-ignore (Sun Jun 8 18:42:33 2008 +0200) 1 commit
 + Teach new attribute 'export-ignore' to git-archive

* rg/gitweb (Fri Jun 6 09:53:32 2008 +0200) 1 commit
 + gitweb: remove git_blame and rename git_blame2 to git_blame

* kh/update-ref (Tue Jun 3 01:34:53 2008 +0200) 2 commits
 + Make old sha1 optional with git update-ref -d
 + Clean up builtin-update-ref's option parsing

* mo/status-untracked (Thu Jun 5 14:47:50 2008 +0200) 3 commits
 + Add configuration option for default untracked files mode
 + Add argument 'no' commit/status option -u|--untracked-files
 + Add an optional <mode> argument to commit/status -u|--untracked-
   files option

* sr/tests (Sun Jun 8 16:04:35 2008 +0200) 3 commits
 + Hook up the result aggregation in the test makefile.
 + A simple script to parse the results from the testcases
 + Modify test-lib.sh to output stats to t/test-results/*

* jh/clone-packed-refs (Sun Jun 15 16:06:16 2008 +0200) 4 commits
 + Teach "git clone" to pack refs
 + Prepare testsuite for a "git clone" that packs refs
 + Move pack_refs() and friends into libgit
 + Incorporate fetched packs in future object traversal

This is useful when cloning from a repository with insanely large number
of refs.

* jc/reflog-expire (Sun Jun 15 23:48:46 2008 -0700) 1 commit
 - Per-ref reflog expiry configuration

Perhaps a good foundation for optionally unexpirable stash.  As 1.6.0 will
be a good time to make backward incompatible changes, we might make expiry
period of stash 'never' in new repositories.  Needs a concensus.

* lw/perlish (Thu Jun 19 22:32:49 2008 +0200) 2 commits
 + Git.pm: add test suite
 + t/test-lib.sh: add test_external and test_external_without_stderr

Beginning of regression tests for Perl part of the system.

* jk/test (Sat Jun 14 03:28:07 2008 -0400) 5 commits
 + enable whitespace checking of test scripts
 + avoid trailing whitespace in zero-change diffstat lines
 + avoid whitespace on empty line in automatic usage message
 + mask necessary whitespace policy violations in test scripts
 + fix whitespace violations in test scripts

Tightens whitespace rules for t/*.sh scripts.

* pb/fast-export (Wed Jun 11 13:17:04 2008 +0200) 1 commit
 + builtin-fast-export: Add importing and exporting of revision marks

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

Nothing today but expect many small ones to come out of 'next' this
weekend.

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

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.

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

Kicked back to 'pu' for now.

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 - Use perl instead of tac
 - Fix t3404 assumption that `wc -l` does not use whitespace.
 - rebase -i: Use : in expr command instead of match.
 - rebase -i: update the implementation of 'mark' command
 - Add option --preserve-tags
 - Teach rebase interactive the tag command
 - Add option --first-parent
 - Do rebase with preserve merges with advanced TODO list
 - Select all lines with fake-editor
 - Unify the length of $SHORT* and the commits in the TODO list
 - Teach rebase interactive the merge command
 - Move redo merge code in a function
 - Teach rebase interactive the reset command
 - Teach rebase interactive the mark command
 - Move cleanup code into it's own function
 - Don't append default merge message to -m message
 - fake-editor: output TODO list if unchanged

It is very likely that this whole thing will be reverted from 'next' and
be replaced with the new sequenser series during 1.6.0 cycle.

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 - Introduce fast forward option only
 - Head reduction before selecting merge strategy
 - Restructure git-merge.sh
 - Introduce -ff=<fast forward option>
 - New merge tests
 - Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C.

* 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/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 - WIP: rethink replay merge
 - Start using replay-tree merge in cherry-pick
 - revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time 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

Just my toy at this moment.

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

[Miklos Vajna]

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

On Sat, Jun 21, 2008 at 02:44:50AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> * nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
>  + Move all dashed-form commands to libexecdir
> 
> Scheduled for 1.6.0.
> 
> * jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
>  - Prepare execv_git_cmd() for removal of builtins from the
>    filesystem
>  - git-shell: accept "git foo" form
> 
> We do not plan to remove git-foo form completely from the filesystem at
> this point, but git-shell may need to be updated.

I may be wrong, but given that git-upload-pack/receive-pack is now not
in PATH, I think it will be problematic to do a pull/push in case the
server runs next, the client is 1.5.6 and the user has git-shell as
shell, for example.

Or have I missed something?

Thanks

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

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

[Junio C Hamano]

Miklos Vajna <vmiklos@frugalware.org> writes:

> On Sat, Jun 21, 2008 at 02:44:50AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
>> * nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
>>  + Move all dashed-form commands to libexecdir
>> 
>> Scheduled for 1.6.0.
>> 
>> * jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
>>  - Prepare execv_git_cmd() for removal of builtins from the
>>    filesystem
>>  - git-shell: accept "git foo" form
>> 
>> We do not plan to remove git-foo form completely from the filesystem at
>> this point, but git-shell may need to be updated.
>
> I may be wrong, but given that git-upload-pack/receive-pack is now not
> in PATH, I think it will be problematic to do a pull/push in case the
> server runs next, the client is 1.5.6 and the user has git-shell as
> shell, for example.

The idea of the "shell: accept 'git foo' form" patch is that as long as
the server end consistently use the same version (i.e. git-shell is from
'next' and it knows where the rest of git is installed), things should
work fine.  I've merged them to 'next' and pushed it out so that you can
try it.

I do not use git-shell in production setting (I do have one user account
whose login shell is git-shell from 'next' I use purely for testing), and
I do not know how much use it has seen in the real world.  My cursory
sanity-check ("cvs -d :ext:thatuser@myhost:/path/ co --help", and "git
ls-remote ssh://thatuser@myhost/path/")  seems to be Ok with $(bindir)
that has only git, gitk and nothing else.

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

[Pieter de Bie]

On 24 jun 2008, at 09:59, Junio C Hamano wrote:

> The idea of the "shell: accept 'git foo' form" patch is that as long  
> as
> the server end consistently use the same version (i.e. git-shell is  
> from
> 'next' and it knows where the rest of git is installed), things should
> work fine.  I've merged them to 'next' and pushed it out so that you  
> can
> try it.

Any clone / push operation fails if you use current next:

Vienna:bin pieter$ git --version
git version 1.5.6.129.g274ea
Vienna:bin pieter$ git clone localhost:project/bonnenteller
Initialize bonnenteller/.git
Initialized empty Git repository in /opt/git/bin/bonnenteller/.git/
Password:
bash: git-upload-pack: command not found
fatal: The remote end hung up unexpectedly

I think that is what Miklos meant. Also, I think the client sends the  
command to execute on the remote side. At least for v1.5.5 clients and  
before, that is "git-upload-pack". As this is not in PATH, that  
command will fail on any server that runs v1.5.6 and has the libexec  
dir.

- Pieter

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

[Pieter de Bie]

On 24 jun 2008, at 10:12, Pieter de Bie wrote:

> I think that is what Miklos meant. Also, I think the client sends  
> the command to execute on the remote side. At least for v1.5.5  
> clients and before, that is "git-upload-pack". As this is not in  
> PATH, that command will fail on any server that runs v1.5.6 and has  
> the libexec dir.

That is supposed to be "v1.5.6" and "v1.6.0" respectively.

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

[Miklos Vajna]

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

On Tue, Jun 24, 2008 at 10:12:28AM +0200, Pieter de Bie <pdebie@ai.rug.nl> wrote:
> Vienna:bin pieter$ git --version
> git version 1.5.6.129.g274ea
> Vienna:bin pieter$ git clone localhost:project/bonnenteller
> Initialize bonnenteller/.git
> Initialized empty Git repository in /opt/git/bin/bonnenteller/.git/
> Password:
> bash: git-upload-pack: command not found
> fatal: The remote end hung up unexpectedly
> 
> I think that is what Miklos meant.

Exactly. Thanks for the good description.

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

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

[Johannes Schindelin]

Hi,

On Tue, 24 Jun 2008, Miklos Vajna wrote:

> On Tue, Jun 24, 2008 at 10:12:28AM +0200, Pieter de Bie <pdebie@ai.rug.nl> wrote:
> > Vienna:bin pieter$ git --version
> > git version 1.5.6.129.g274ea
> > Vienna:bin pieter$ git clone localhost:project/bonnenteller
> > Initialize bonnenteller/.git
> > Initialized empty Git repository in /opt/git/bin/bonnenteller/.git/
> > Password:
> > bash: git-upload-pack: command not found
> > fatal: The remote end hung up unexpectedly
> > 
> > I think that is what Miklos meant.
> 
> Exactly. Thanks for the good description.

AFAICT these are fixed with ed99a225(Merge branch 'jc/dashless' into 
next).

Ciao,
Dscho

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

[Miklos Vajna]

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

On Tue, Jun 24, 2008 at 05:25:57PM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > Vienna:bin pieter$ git --version
> > > git version 1.5.6.129.g274ea
> > > Vienna:bin pieter$ git clone localhost:project/bonnenteller
> > > Initialize bonnenteller/.git
> > > Initialized empty Git repository in /opt/git/bin/bonnenteller/.git/
> > > Password:
> > > bash: git-upload-pack: command not found
> > > fatal: The remote end hung up unexpectedly
> > > 
> > > I think that is what Miklos meant.
> > 
> > Exactly. Thanks for the good description.
> 
> AFAICT these are fixed with ed99a225(Merge branch 'jc/dashless' into 
> next).

Using fc48199 ("Merge branch 'master' into next", which includes
ed99a225) on the server, v1.5.6 on the client, I get: 

$ git clone server:/home/vmiklos/git/test next
Initialize next/.git
Initialized empty Git repository in /home/vmiklos/scm/git/next/.git/
vmiklos@server's password:
bash: git-upload-pack: command not found
fatal: The remote end hung up unexpectedly

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

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

[Johannes Schindelin]

Hi,

On Tue, 24 Jun 2008, Miklos Vajna wrote:

> On Tue, Jun 24, 2008 at 05:25:57PM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > Vienna:bin pieter$ git --version
> > > > git version 1.5.6.129.g274ea
> > > > Vienna:bin pieter$ git clone localhost:project/bonnenteller
> > > > Initialize bonnenteller/.git
> > > > Initialized empty Git repository in /opt/git/bin/bonnenteller/.git/
> > > > Password:
> > > > bash: git-upload-pack: command not found
> > > > fatal: The remote end hung up unexpectedly
> > > > 
> > > > I think that is what Miklos meant.
> > > 
> > > Exactly. Thanks for the good description.
> > 
> > AFAICT these are fixed with ed99a225(Merge branch 'jc/dashless' into 
> > next).
> 
> Using fc48199 ("Merge branch 'master' into next", which includes
> ed99a225) on the server, v1.5.6 on the client, I get: 
> 
> $ git clone server:/home/vmiklos/git/test next
> Initialize next/.git
> Initialized empty Git repository in /home/vmiklos/scm/git/next/.git/
> vmiklos@server's password:
> bash: git-upload-pack: command not found
> fatal: The remote end hung up unexpectedly

Hmm.  Probably the client needs to be newer, too.  This is going to be 
painful.  Junio?

Sorry for the noise,
Dscho

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

[Jakub Narebski]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 24 Jun 2008, Miklos Vajna wrote:
> > 
> > Using fc48199 ("Merge branch 'master' into next", which includes
> > ed99a225) on the server, v1.5.6 on the client, I get: 
> > 
> > $ git clone server:/home/vmiklos/git/test next
> > Initialize next/.git
> > Initialized empty Git repository in /home/vmiklos/scm/git/next/.git/
> > vmiklos@server's password:
> > bash: git-upload-pack: command not found
> > fatal: The remote end hung up unexpectedly
> 
> Hmm.  Probably the client needs to be newer, too.  This is going to be 
> painful.  Junio?

It looks like git-upload-pack and git-receive-pack would
have to be left in $PATH, at least till old clients die
of old age ;-)

git-shell hackery won't solve problem, because not everybody is using
git-shell.
-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Johannes Schindelin]

Hi,

On Tue, 24 Jun 2008, Jakub Narebski wrote:

> git-shell hackery won't solve problem, because not everybody is using 
> git-shell.

The problem is not git-shell vs git potty.

The problem is that not everybody magically updates their clients to ask 
for dash-less form.

Ciao,
Dscho

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

[Jakub Narebski]

Hello!

Johannes Schindelin wrote:
> On Tue, 24 Jun 2008, Jakub Narebski wrote:
> 
> > git-shell hackery won't solve problem, because not everybody is using 
> > git-shell.
> 
> The problem is not git-shell vs git potty.
> 
> The problem is that not everybody magically updates their clients to ask 
> for dash-less form.

What I meant here by "git-shell hackery" was for git-shell to
automagically redirect request for "git-receive-pack" to "git receive-pack"
(or "$GIT_EXEC_PATH/git-receive-pack").

But, as I said, it isn't complete solution.  Leaving git-*-pack in $PATH
for the time being (what I said) is.
-- 
Jakub Narebski
Poland

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

[Jakub Narebski]

On Tue, 24 Jun 2008, Johannes Schindelin wrote:
> Hi,
> 
> On Tue, 24 Jun 2008, Jakub Narebski wrote:
> 
> > git-shell hackery won't solve problem, because not everybody is using 
> > git-shell.
> 
> The problem is not git-shell vs git potty.
> 
> The problem is that not everybody magically updates their clients to ask 
> for dash-less form.

With git-shell even if client uses dashed form it can find git commands
("hackery" is too strong a word for having git-shell search $GIT_EXEC_PATH).
But if one uses only SSH, server must have dashed form in a $PATH

-- 
Jakub Narebski
Poland

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

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> Using fc48199 ("Merge branch 'master' into next", which includes
>> ed99a225) on the server, v1.5.6 on the client, I get: 
>> 
>> $ git clone server:/home/vmiklos/git/test next
>> Initialize next/.git
>> Initialized empty Git repository in /home/vmiklos/scm/git/next/.git/
>> vmiklos@server's password:
>> bash: git-upload-pack: command not found
>> fatal: The remote end hung up unexpectedly
>
> Hmm.  Probably the client needs to be newer, too.  This is going to be 
> painful.  Junio?

Even with maint client accessing an account with next git-shell as its
login shell, I do not get the above failure.

Is git-shell installed and configured correctly at all in Miklos's setup?
Why does the other side say "bash: git-upload-pack" when login shell is
git-shell and not bash?

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

[Miklos Vajna]

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

On Tue, Jun 24, 2008 at 01:44:34PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> >> bash: git-upload-pack: command not found
> >> fatal: The remote end hung up unexpectedly
> >
> > Hmm.  Probably the client needs to be newer, too.  This is going to be 
> > painful.  Junio?
> 
> Even with maint client accessing an account with next git-shell as its
> login shell, I do not get the above failure.
> 
> Is git-shell installed and configured correctly at all in Miklos's setup?
> Why does the other side say "bash: git-upload-pack" when login shell is
> git-shell and not bash?

Sorry for the confusion, this is not about git-shell at all. I have
bash as the shell on the server, obviously.

So, in case the server runs next, the client runs master, and I try to
clone via ssh, I get the above error.

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

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

[Junio C Hamano]

Miklos Vajna <vmiklos@frugalware.org> writes:

> On Tue, Jun 24, 2008 at 01:44:34PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
>> >> bash: git-upload-pack: command not found
>> >> fatal: The remote end hung up unexpectedly
>> >
>> > Hmm.  Probably the client needs to be newer, too.  This is going to be 
>> > painful.  Junio?
>> 
>> Even with maint client accessing an account with next git-shell as its
>> login shell, I do not get the above failure.
>> 
>> Is git-shell installed and configured correctly at all in Miklos's setup?
>> Why does the other side say "bash: git-upload-pack" when login shell is
>> git-shell and not bash?
>
> Sorry for the confusion, this is not about git-shell at all. I have
> bash as the shell on the server, obviously.
>
> So, in case the server runs next, the client runs master, and I try to
> clone via ssh, I get the above error.

Ah, there is not much we can do in that case then.  git-upload-pack is
what the client asks you to run, and if you do not have it in the path,
you can (1) either make sure it is on the path, (2) have the client be
more explicit when asking for git-upload-pack (--upload-pack=$where), or
(3) leave the minimum git-* binaries that can remotely be launched
directly in the usual $PATH.

It most likely makes sense to do (3) anyway.  upload-pack, receive-pack,
anything else?

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

[Miklos Vajna]

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

On Tue, Jun 24, 2008 at 04:16:36PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> It most likely makes sense to do (3) anyway.  upload-pack, receive-pack,
> anything else?

I think that's all.

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

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

[Junio C Hamano]

Miklos Vajna <vmiklos@frugalware.org> writes:

> On Tue, Jun 24, 2008 at 04:16:36PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
>> It most likely makes sense to do (3) anyway.  upload-pack, receive-pack,
>> anything else?
>
> I think that's all.

Then that would be this patch on top of nd/dashless topic.

 Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 929136b..babf16b 100644
--- a/Makefile
+++ b/Makefile
@@ -1268,7 +1268,7 @@ install: all
 	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
 	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
 	$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
-	$(INSTALL) git$X '$(DESTDIR_SQ)$(bindir_SQ)'
+	$(INSTALL) git$X git-upload-pack$X git-receive-pack$X '$(DESTDIR_SQ)$(bindir_SQ)'
 	$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
 	$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
 ifndef NO_TCLTK

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

[しらいしななこ]

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

> Miklos Vajna <vmiklos@frugalware.org> writes:
>
>> On Tue, Jun 24, 2008 at 04:16:36PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
>>> It most likely makes sense to do (3) anyway.  upload-pack, receive-pack,
>>> anything else?
>>
>> I think that's all.
>
> Then that would be this patch on top of nd/dashless topic.
>
>  Makefile |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 929136b..babf16b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1268,7 +1268,7 @@ install: all
>  	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
>  	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
>  	$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
> -	$(INSTALL) git$X '$(DESTDIR_SQ)$(bindir_SQ)'
> +	$(INSTALL) git$X git-upload-pack$X git-receive-pack$X '$(DESTDIR_SQ)$(bindir_SQ)'
>  	$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
>  	$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
>  ifndef NO_TCLTK

Doesn't "git archive --remote=<repo>" also execute git program on a remote machine?

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

[PATCH] Keep some git-* programs in $(bindir)

[Junio C Hamano]

Otherwise remote executions directly over ssh won't find them as they used
to.  --upload-pack and --receive-pack options _could_ be used on the
client side, but things should keep working out-of-box for older clients.

Later versions of clients (fetch-pack and send-pack) probably could start
asking for these programs with dashless form, but that is a different
topic.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * しらいしななこ <nanako3@lavabit.com> writes:
 > Doesn't "git archive --remote=<repo>" also execute git program on a remote machine?

 Ok, how about this?

 Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 929136b..742e7d3 100644
--- a/Makefile
+++ b/Makefile
@@ -1268,7 +1268,7 @@ install: all
 	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
 	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
 	$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
-	$(INSTALL) git$X '$(DESTDIR_SQ)$(bindir_SQ)'
+	$(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-archive$X '$(DESTDIR_SQ)$(bindir_SQ)'
 	$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
 	$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
 ifndef NO_TCLTK
-- 
1.5.6.56.g29b0d

[PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Junio C Hamano]

The daemon expects to see the dashed form and we cannot change older
servers.  But when invoking programs on the remote end over SSH, the
command line the client side build is under client's control.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * This I haven't even compile tested at all, but it feels right.  We
   probably should do this before bindir=>libexecdir move; as long as this
   is in place on the client side the version running on the server end
   should not matter.

 connect.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/connect.c b/connect.c
index e92af29..fd1da26 100644
--- a/connect.c
+++ b/connect.c
@@ -589,6 +589,10 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
 	conn = xcalloc(1, sizeof(*conn));
 
 	strbuf_init(&cmd, MAX_CMD_LEN);
+	if (protocol != PROTO_GIT && !strncmp(prog, "git-", 4)) {
+		strbuf_addstr(&cmd, "git ");
+		prog += 4;
+	}
 	strbuf_addstr(&cmd, prog);
 	strbuf_addch(&cmd, ' ');
 	sq_quote_buf(&cmd, path);
-- 
1.5.6.56.g29b0d

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> The daemon expects to see the dashed form and we cannot change older
> servers.  But when invoking programs on the remote end over SSH, the
> command line the client side build is under client's control.
...
> diff --git a/connect.c b/connect.c
> index e92af29..fd1da26 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -589,6 +589,10 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
>  	conn = xcalloc(1, sizeof(*conn));
>  
>  	strbuf_init(&cmd, MAX_CMD_LEN);
> +	if (protocol != PROTO_GIT && !strncmp(prog, "git-", 4)) {
> +		strbuf_addstr(&cmd, "git ");
> +		prog += 4;
> +	}

Nack on that implementation.

I think this is a problem for systems based on say gitosis,
or some pattern like it.  Day-job doesn't use gitosis, but
has switched to a Perl based forced ssh tool that smells a
lot like gitosis.  Gitosis is popular.

github probably uses something similar.  But nobody knows (or
probably cares) since they don't release their source.

gitosis is likely looking for "$git-upload-pack '(.*)'$" to be
in the $SSH_ORIGINAL_COMMAND environment variable, if you send
"git upload-pack 'path.git'" I think its going to reject.

What's really bad about your patch is you cannot work around it as a
user by setting --upload-pack on the command line, or in the config,
because down at the very deepest level you are switching the "git-"
to "git " and ignoring what the user has supplied you.

Sorry, but I think this change needs to go higher up, to the default
values that --upload-pack and remote.$name.uploadpack override,
so the user can at least work around it when we break her ability
to use github, gitosis, or anything like it.

-- 
Shawn.

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Sorry, but I think this change needs to go higher up, to the default
> values that --upload-pack and remote.$name.uploadpack override,
> so the user can at least work around it when we break her ability
> to use github, gitosis, or anything like it.

Well, the thing is, "higher up" would not have enough clue to see if it
needs to give dashed form (for git-daemon) or space form (for ssh), so
that suggestion won't help much.

I do not care too much about closed source service, but gitosis should be
able to update the pattern to allow "git[ -]upload-pack" reasonably
easily.

Any other suggestions that is workable?

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > Sorry, but I think this change needs to go higher up, to the default
> > values that --upload-pack and remote.$name.uploadpack override,
> > so the user can at least work around it when we break her ability
> > to use github, gitosis, or anything like it.
> 
> Well, the thing is, "higher up" would not have enough clue to see if it
> needs to give dashed form (for git-daemon) or space form (for ssh), so
> that suggestion won't help much.

Actually I'd go the other direction.  Allow the higher up level
to supply "git upload-pack" and convert it to git- for the git://
protocol.  Possible patch below.

> I do not care too much about closed source service, but gitosis should be
> able to update the pattern to allow "git[ -]upload-pack" reasonably
> easily.

Pasky also has to update:

$ git ls-remote --upload-pack='git upload-pack' repo.or.cz:/srv/git/egit.git
fatal: unrecognized command 'git upload-pack '/srv/git/egit.git''
fatal: The remote end hung up unexpectedly

;-)
 
> Any other suggestions that is workable?

diff --git a/builtin-clone.c b/builtin-clone.c
index 5c5acb4..98d0f0f 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -37,7 +37,7 @@ static int option_quiet, option_no_checkout, option_bare;
 static int option_local, option_no_hardlinks, option_shared;
 static char *option_template, *option_reference, *option_depth;
 static char *option_origin = NULL;
-static char *option_upload_pack = "git-upload-pack";
+static char *option_upload_pack = "git upload-pack";
 
 static struct option builtin_clone_options[] = {
 	OPT__QUIET(&option_quiet),
@@ -58,7 +58,7 @@ static struct option builtin_clone_options[] = {
 	OPT_STRING('o', "origin", &option_origin, "branch",
 		   "use <branch> instead or 'origin' to track upstream"),
 	OPT_STRING('u', "upload-pack", &option_upload_pack, "path",
-		   "path to git-upload-pack on the remote"),
+		   "path to git upload-pack on the remote"),
 	OPT_STRING(0, "depth", &option_depth, "depth",
 		    "create a shallow clone of that depth"),
 
diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index f4dbcf0..b0efd01 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -14,7 +14,7 @@ static int transfer_unpack_limit = -1;
 static int fetch_unpack_limit = -1;
 static int unpack_limit = 100;
 static struct fetch_pack_args args = {
-	/* .uploadpack = */ "git-upload-pack",
+	/* .uploadpack = */ "git upload-pack",
 };
 
 static const char fetch_pack_usage[] =
diff --git a/connect.c b/connect.c
index e92af29..dbabd93 100644
--- a/connect.c
+++ b/connect.c
@@ -576,8 +576,8 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
 		 * from extended components with a NUL byte.
 		 */
 		packet_write(fd[1],
-			     "%s %s%chost=%s%c",
-			     prog, path, 0,
+			     "git-%s %s%chost=%s%c",
+			     prog + 4, path, 0,
 			     target_host, 0);
 		free(target_host);
 		free(url);
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 695a409..0f82a93 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -255,10 +255,10 @@ get_uploadpack () {
 	case "$data_source" in
 	config)
 		uplp=$(git config --get "remote.$1.uploadpack")
-		echo ${uplp:-git-upload-pack}
+		echo ${uplp:-git upload-pack}
 		;;
 	*)
-		echo "git-upload-pack"
+		echo "git upload-pack"
 		;;
 	esac
 }
diff --git a/transport.c b/transport.c
index 3ff8519..351b7f5 100644
--- a/transport.c
+++ b/transport.c
@@ -762,10 +762,10 @@ struct transport *transport_get(struct remote *remote, const char *url)
 
 		data->thin = 1;
 		data->conn = NULL;
-		data->uploadpack = "git-upload-pack";
+		data->uploadpack = "git upload-pack";
 		if (remote && remote->uploadpack)
 			data->uploadpack = remote->uploadpack;
-		data->receivepack = "git-receive-pack";
+		data->receivepack = "git receive-pack";
 		if (remote && remote->receivepack)
 			data->receivepack = remote->receivepack;
 	}

-- 
Shawn.

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

>> Any other suggestions that is workable?
>
> diff --git a/builtin-clone.c b/builtin-clone.c
> index 5c5acb4..98d0f0f 100644
> --- a/builtin-clone.c
> +++ b/builtin-clone.c
> @@ -37,7 +37,7 @@ static int option_quiet, option_no_checkout, option_bare;

<< a patch to conditionally change "git-program" default to "git program"
snipped >>

How would that help client that talk with git-daemon, unlike what I sent
earlier?

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Junio C Hamano]

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

> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
>>> Any other suggestions that is workable?
>>
>> diff --git a/builtin-clone.c b/builtin-clone.c
>> index 5c5acb4..98d0f0f 100644
>> --- a/builtin-clone.c
>> +++ b/builtin-clone.c
>> @@ -37,7 +37,7 @@ static int option_quiet, option_no_checkout, option_bare;
>
> << a patch to conditionally change "git-program" default to "git program"
> snipped >>

Typofix: s/cond/uncond/;

> How would that help client that talk with git-daemon, unlike what I sent
> earlier?

If we force --upload-pack workaround to _everybody_ we are already lost.

Also I think the previous one still lets you work it around by giving a
full path, like "/usr/local/bin/git-upload-pack", because "/usr" does not
match "git-" ;-)

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Junio C Hamano]

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

> If we force --upload-pack workaround to _everybody_ we are already lost.
>
> Also I think the previous one still lets you work it around by giving a
> full path, like "/usr/local/bin/git-upload-pack", because "/usr" does not
> match "git-" ;-)

Ok, let's map this out seriously.

* 1.6.0 will install the server-side programs in $(bindir) so that 
  people coming over ssh will find them on the $PATH

* In 1.6.0 (and 1.5.6.1), we will change "git daemon" to accept both
  "git-program" and "git program" forms.  When the spaced form is used, it
  will behave as if the dashed form is requested.  This is a prerequisite
  for client side change to start asking for "git program".

* In the near future, there will no client-side change.  "git-program"
  will be asked for.

* 6 months after 1.6.0 ships, hopefully all the deployed server side will
  be running that version or newer.  Client side will start asking for
  "git program" by default, but we can still override with --upload-pack
  and friends.

* 12 months after client side changes, everybody will be running that
  version or newer.  We stop installing the server side programs in
  $(bindir) but people coming over ssh will be asking for "git program"
  and "git" will be on the $PATH so there is no issue.

The above 6 and 12 are yanked out of thin air and I am of course open to
tweaking them, but I think the above order of events would be workable.

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > If we force --upload-pack workaround to _everybody_ we are already lost.
> >
> > Also I think the previous one still lets you work it around by giving a
> > full path, like "/usr/local/bin/git-upload-pack", because "/usr" does not
> > match "git-" ;-)
> 
> Ok, let's map this out seriously.

This plan makes a lot of sense to me.  I'm behind it.  For whatever
that means.  At least I'll shutup and stop making noise about this
issue if you take this approach.  :-)

 
> * 1.6.0 will install the server-side programs in $(bindir) so that 
>   people coming over ssh will find them on the $PATH
> 
> * In 1.6.0 (and 1.5.6.1), we will change "git daemon" to accept both
>   "git-program" and "git program" forms.  When the spaced form is used, it
>   will behave as if the dashed form is requested.  This is a prerequisite
>   for client side change to start asking for "git program".
> 
> * In the near future, there will no client-side change.  "git-program"
>   will be asked for.
> 
> * 6 months after 1.6.0 ships, hopefully all the deployed server side will
>   be running that version or newer.  Client side will start asking for
>   "git program" by default, but we can still override with --upload-pack
>   and friends.
> 
> * 12 months after client side changes, everybody will be running that
>   version or newer.  We stop installing the server side programs in
>   $(bindir) but people coming over ssh will be asking for "git program"
>   and "git" will be on the $PATH so there is no issue.
> 
> The above 6 and 12 are yanked out of thin air and I am of course open to
> tweaking them, but I think the above order of events would be workable.

Yea, 6 and 12 seem like a good idea.  Its a couple of releases and
gives people time to migrate their server installations.

-- 
Shawn.

[PATCH] daemon: accept "git program" as well

[Junio C Hamano]

This is a step to futureproof git-daemon to accept clients that
ask for "git upload-pack" and friends, instead of using the more
traditional dash-form "git-upload-pack".  By allowing both, it
makes the client side easier to handle, as it makes "git" the only
thing necessary to be on $PATH when invoking the remote command
directly via ssh.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 "Shawn O. Pearce" <spearce@spearce.org> writes:

 > Junio C Hamano <gitster@pobox.com> wrote:
 >
 >> Ok, let's map this out seriously.
 >
 > This plan makes a lot of sense to me.  I'm behind it.  For whatever
 > that means.  At least I'll shutup and stop making noise about this
 > issue if you take this approach.  :-)
 >  
 >> * 1.6.0 will install the server-side programs in $(bindir) so that 
 >>   people coming over ssh will find them on the $PATH
 >> 
 >> * In 1.6.0 (and 1.5.6.1), we will change "git daemon" to accept both
 >>   "git-program" and "git program" forms.  When the spaced form is used, it
 >>   will behave as if the dashed form is requested.  This is a prerequisite
 >>   for client side change to start asking for "git program".
 >> 
 >> * In the near future, there will no client-side change.  "git-program"
 >>   will be asked for.
 >> 
 >> * 6 months after 1.6.0 ships, hopefully all the deployed server side will
 >>   be running that version or newer.  Client side will start asking for
 >>   "git program" by default, but we can still override with --upload-pack
 >>   and friends.
 >> 
 >> * 12 months after client side changes, everybody will be running that
 >>   version or newer.  We stop installing the server side programs in
 >>   $(bindir) but people coming over ssh will be asking for "git program"
 >>   and "git" will be on the $PATH so there is no issue.
 >> 
 >> The above 6 and 12 are yanked out of thin air and I am of course open to
 >> tweaking them, but I think the above order of events would be workable.
 >
 > Yea, 6 and 12 seem like a good idea.  Its a couple of releases and
 > gives people time to migrate their server installations.

 So this obviously needs to be queued to 'maint' to be included in 1.5.6.1
 and 1.6.0.

 daemon.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/daemon.c b/daemon.c
index 63cd12c..621c567 100644
--- a/daemon.c
+++ b/daemon.c
@@ -586,7 +586,7 @@ static int execute(struct sockaddr *addr)
 	for (i = 0; i < ARRAY_SIZE(daemon_service); i++) {
 		struct daemon_service *s = &(daemon_service[i]);
 		int namelen = strlen(s->name);
-		if (!prefixcmp(line, "git-") &&
+		if ((!prefixcmp(line, "git-") || !prefixcmp(line, "git ")) &&
 		    !strncmp(s->name, line + 4, namelen) &&
 		    line[namelen + 4] == ' ') {
 			/*

[PATCH] Make clients ask for "git program" over ssh and local transport

[Junio C Hamano]

This will allow server side programs such as upload-pack to be installed
outside $PATH.  Connections to git-daemon still ask for "git-program" to
retain backward compatibility for daemons before 1.5.6.1 and 1.6.0.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * This is essentially your patch.  This can be in 1.6.0 clients and it
   should also be in 1.5.6.1 as people might keep ancient clients to talk
   to new servers that won't have anything but "git" on $PATH.

 builtin-clone.c      |    2 +-
 builtin-fetch-pack.c |    2 +-
 connect.c            |   10 ++++++++--
 git-parse-remote.sh  |    4 ++--
 transport.c          |    4 ++--
 5 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/builtin-clone.c b/builtin-clone.c
index 7190952..2f3e9c9 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -36,7 +36,7 @@ static int option_quiet, option_no_checkout, option_bare;
 static int option_local, option_no_hardlinks, option_shared;
 static char *option_template, *option_reference, *option_depth;
 static char *option_origin = NULL;
-static char *option_upload_pack = "git-upload-pack";
+static char *option_upload_pack = "git upload-pack";
 
 static struct option builtin_clone_options[] = {
 	OPT__QUIET(&option_quiet),
diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index de1e8d1..a5f21f9 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -14,7 +14,7 @@ static int transfer_unpack_limit = -1;
 static int fetch_unpack_limit = -1;
 static int unpack_limit = 100;
 static struct fetch_pack_args args = {
-	/* .uploadpack = */ "git-upload-pack",
+	/* .uploadpack = */ "git upload-pack",
 };
 
 static const char fetch_pack_usage[] =
diff --git a/connect.c b/connect.c
index e92af29..4a32ba4 100644
--- a/connect.c
+++ b/connect.c
@@ -567,6 +567,8 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
 		 * cannot connect.
 		 */
 		char *target_host = xstrdup(host);
+		const char *program_prefix = "";
+
 		if (git_use_proxy(host))
 			git_proxy_connect(fd, host);
 		else
@@ -575,9 +577,13 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
 		 * Separate original protocol components prog and path
 		 * from extended components with a NUL byte.
 		 */
+		if (!prefixcmp(prog, "git ")) {
+			program_prefix = "git-";
+			prog += 4;
+		}
 		packet_write(fd[1],
-			     "%s %s%chost=%s%c",
-			     prog, path, 0,
+			     "%s%s %s%chost=%s%c",
+			     program_prefix, prog, path, 0,
 			     target_host, 0);
 		free(target_host);
 		free(url);
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 695a409..0f82a93 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -255,10 +255,10 @@ get_uploadpack () {
 	case "$data_source" in
 	config)
 		uplp=$(git config --get "remote.$1.uploadpack")
-		echo ${uplp:-git-upload-pack}
+		echo ${uplp:-git upload-pack}
 		;;
 	*)
-		echo "git-upload-pack"
+		echo "git upload-pack"
 		;;
 	esac
 }
diff --git a/transport.c b/transport.c
index 3ff8519..351b7f5 100644
--- a/transport.c
+++ b/transport.c
@@ -762,10 +762,10 @@ struct transport *transport_get(struct remote *remote, const char *url)
 
 		data->thin = 1;
 		data->conn = NULL;
-		data->uploadpack = "git-upload-pack";
+		data->uploadpack = "git upload-pack";
 		if (remote && remote->uploadpack)
 			data->uploadpack = remote->uploadpack;
-		data->receivepack = "git-receive-pack";
+		data->receivepack = "git receive-pack";
 		if (remote && remote->receivepack)
 			data->receivepack = remote->receivepack;
 	}
-- 
1.5.6.86.ge2da6

[PATCH] Ask for "git program" even against git-daemon

[Junio C Hamano]

This drops backward compatibility support to ask for "git-program"
form when talking to git-daemon.  Now all git native requests use
"git program" form over ssh, local and git transports.

This needs to be held back until everybody runs git-daemon from 1.5.6.1 or
1.6.0 or newer.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * According to the roadmap we exchanged earlier, this should happen in a
   major release (that increments the second dewey-decimal digit from the
   left) that ships at least 6 months after 1.5.6.1 and 1.6.0 (which will
   have the "git daemon preparation" patch included) are released.

 connect.c |    9 ++-------
 1 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/connect.c b/connect.c
index 4a32ba4..f2e72c2 100644
--- a/connect.c
+++ b/connect.c
@@ -567,7 +567,6 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
 		 * cannot connect.
 		 */
 		char *target_host = xstrdup(host);
-		const char *program_prefix = "";
 
 		if (git_use_proxy(host))
 			git_proxy_connect(fd, host);
@@ -577,13 +576,9 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
 		 * Separate original protocol components prog and path
 		 * from extended components with a NUL byte.
 		 */
-		if (!prefixcmp(prog, "git ")) {
-			program_prefix = "git-";
-			prog += 4;
-		}
 		packet_write(fd[1],
-			     "%s%s %s%chost=%s%c",
-			     program_prefix, prog, path, 0,
+			     "%s %s%chost=%s%c",
+			     prog, path, 0,
 			     target_host, 0);
 		free(target_host);
 		free(url);
-- 
1.5.6.86.ge2da6

Re: [PATCH] Ask for "git program" even against git-daemon

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> This drops backward compatibility support to ask for "git-program"
> form when talking to git-daemon.  Now all git native requests use
> "git program" form over ssh, local and git transports.
> 
> This needs to be held back until everybody runs git-daemon from 1.5.6.1 or
> 1.6.0 or newer.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  * According to the roadmap we exchanged earlier, this should happen in a
>    major release (that increments the second dewey-decimal digit from the
>    left) that ships at least 6 months after 1.5.6.1 and 1.6.0 (which will
>    have the "git daemon preparation" patch included) are released.

Agreed about holding back.

But I wonder if this patch is even worth it at some later point
in time.  Are we also going to change git-daemon to stop accepting
"git-" form?  Is it a worthwhile change?

-- 
Shawn.

Re: [PATCH] Ask for "git program" even against git-daemon

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Junio C Hamano <gitster@pobox.com> wrote:
> ...
>>  * According to the roadmap we exchanged earlier, this should happen in a
>>    major release (that increments the second dewey-decimal digit from the
>>    left) that ships at least 6 months after 1.5.6.1 and 1.6.0 (which will
>>    have the "git daemon preparation" patch included) are released.
>
> Agreed about holding back.
>
> But I wonder if this patch is even worth it at some later point
> in time.  Are we also going to change git-daemon to stop accepting
> "git-" form?  Is it a worthwhile change?

This was merely responding to...

    From: "Shawn O. Pearce" <spearce@spearce.org>
    Subject: Re: [PATCH] Keep some git-* programs in $(bindir)
    Date: Wed, 25 Jun 2008 00:37:41 -0400
    Message-ID: <20080625043741.GD11793@spearce.org>

    Daniel Barkalow <barkalow@iabervon.org> wrote:
    > ...
    > Should they use "git upload-pack" or should they look for their helper 
    > programs in a libexec dir? I don't think that either of these programs is 
    > useful to run independantly, but I don't know if finding a program that 
    > doesn't go in $PATH on a remote machine is going to be any fun.

    IMHO they should in the future use "git upload-pack".


I do not mind not doing this at all.  Remember, I am the one with more
inertia than anybody else here (holding back backward incompatible
innovations is what maintainers do).

Oh, that inertia does not have much to do with actual body weight, if
anybody is wondering ;-)

Re: [PATCH] Ask for "git program" even against git-daemon

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> >
> > But I wonder if this patch is even worth it at some later point
> > in time.  Are we also going to change git-daemon to stop accepting
> > "git-" form?  Is it a worthwhile change?
> 
> This was merely responding to...
> 
>     From: "Shawn O. Pearce" <spearce@spearce.org>
>     Subject: Re: [PATCH] Keep some git-* programs in $(bindir)
>     Date: Wed, 25 Jun 2008 00:37:41 -0400
>     Message-ID: <20080625043741.GD11793@spearce.org>
> 
>     Daniel Barkalow <barkalow@iabervon.org> wrote:
>     > ...
>     > Should they use "git upload-pack" [...]
> 
>     IMHO they should in the future use "git upload-pack".

Sorry I wasn't clear. I was talking about the SSH transport only.
For git:// we could just always send git-upload-pack, like your
transitional patch does.  Then we stay compatible with even very
old git:// servers.

-- 
Shawn.

Re: [PATCH] Ask for "git program" even against git-daemon

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Junio C Hamano <gitster@pobox.com> wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>> >
>> > But I wonder if this patch is even worth it at some later point
>> > in time.  Are we also going to change git-daemon to stop accepting
>> > "git-" form?  Is it a worthwhile change?
>> 
>> This was merely responding to...
>> 
>>     From: "Shawn O. Pearce" <spearce@spearce.org>
>>     Subject: Re: [PATCH] Keep some git-* programs in $(bindir)
>>     Date: Wed, 25 Jun 2008 00:37:41 -0400
>>     Message-ID: <20080625043741.GD11793@spearce.org>
>> 
>>     Daniel Barkalow <barkalow@iabervon.org> wrote:
>>     > ...
>>     > Should they use "git upload-pack" [...]
>> 
>>     IMHO they should in the future use "git upload-pack".
>
> Sorry I wasn't clear. I was talking about the SSH transport only.
> For git:// we could just always send git-upload-pack, like your
> transitional patch does.  Then we stay compatible with even very
> old git:// servers.

Ok, if that is the plan, then we wouldn't even need to futureproof
git-daemon at all.

Not having to change anything is good ;-).

Re: [PATCH] Make clients ask for "git program" over ssh and local transport

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> This will allow server side programs such as upload-pack to be installed
> outside $PATH.  Connections to git-daemon still ask for "git-program" to
> retain backward compatibility for daemons before 1.5.6.1 and 1.6.0.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  * This is essentially your patch.  This can be in 1.6.0 clients and it
>    should also be in 1.5.6.1 as people might keep ancient clients to talk
>    to new servers that won't have anything but "git" on $PATH.

Ack.  Thanks for cleaning up the code in connect.c to not segfault
or send garbage.

I think you want to squash this in as well:

diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index d76260c..f693a6d 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -12,7 +12,7 @@ static const char send_pack_usage[] =
 "  --all and explicit <ref> specification are mutually exclusive.";
 
 static struct send_pack_args args = {
-	/* .receivepack = */ "git-receive-pack",
+	/* .receivepack = */ "git receive-pack",
 };
 
 /*
 

-- 
Shawn.

Re: [PATCH] daemon: accept "git program" as well

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> This is a step to futureproof git-daemon to accept clients that
> ask for "git upload-pack" and friends, instead of using the more
> traditional dash-form "git-upload-pack".  By allowing both, it
> makes the client side easier to handle, as it makes "git" the only
> thing necessary to be on $PATH when invoking the remote command
> directly via ssh.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Obviously correct.  Ack.  Thanks Junio.


>  So this obviously needs to be queued to 'maint' to be included in 1.5.6.1
>  and 1.6.0.
> 
>  daemon.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/daemon.c b/daemon.c
> index 63cd12c..621c567 100644
> --- a/daemon.c
> +++ b/daemon.c
> @@ -586,7 +586,7 @@ static int execute(struct sockaddr *addr)
>  	for (i = 0; i < ARRAY_SIZE(daemon_service); i++) {
>  		struct daemon_service *s = &(daemon_service[i]);
>  		int namelen = strlen(s->name);
> -		if (!prefixcmp(line, "git-") &&
> +		if ((!prefixcmp(line, "git-") || !prefixcmp(line, "git ")) &&
>  		    !strncmp(s->name, line + 4, namelen) &&
>  		    line[namelen + 4] == ' ') {
>  			/*

-- 
Shawn.

Re: [PATCH] daemon: accept "git program" as well

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Junio C Hamano <gitster@pobox.com> wrote:
>> This is a step to futureproof git-daemon to accept clients that
>> ask for "git upload-pack" and friends, instead of using the more
>> traditional dash-form "git-upload-pack".  By allowing both, it
>> makes the client side easier to handle, as it makes "git" the only
>> thing necessary to be on $PATH when invoking the remote command
>> directly via ssh.
>> 
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> Obviously correct.  Ack.  Thanks Junio.

By the way I looked at gitosis (Tommi CC'ed).

    http://repo.or.cz/w/gitosis.git?a=blob;f=gitosis/serve.py;h=c0b7135bf45305ee1079b0dcab3b4ed1ce988aab;hb=38561aa6a51a2ef6cc04aa119481df62d213ffa4

In gitosis/serve.py, there are COMMANDS_READONLY and COMMANDS_WRITE array
that holds 'git-upload-pack' and 'git-receive-pack' commands, and they are
compared with user commands after doing:

	verb, args = command.split(None, 1)

(and "verb" is looked up in the set of valid commands).  It should not be
too involved to notice verb is 'git' and then re-split the args part to
see if they are upload-pack/receive-pack, which would be the equivalent
change to this patch.  It needs to be done before the clients are
updated.

Re: [PATCH] daemon: accept "git program" as well

[Tommi Virtanen]

On Wed, Jun 25, 2008 at 04:26:46PM -0700, Junio C Hamano wrote:
> By the way I looked at gitosis (Tommi CC'ed).
> 
>     http://repo.or.cz/w/gitosis.git?a=blob;f=gitosis/serve.py;h=c0b7135bf45305ee1079b0dcab3b4ed1ce988aab;hb=38561aa6a51a2ef6cc04aa119481df62d213ffa4
> 
> In gitosis/serve.py, there are COMMANDS_READONLY and COMMANDS_WRITE array
> that holds 'git-upload-pack' and 'git-receive-pack' commands, and they are
> compared with user commands after doing:

Yeah, that's pretty much a trivial change, doing it now to future-proof
gitosis.

-- 
:(){ :|:&};:

Re: [PATCH] daemon: accept "git program" as well

[Olivier Marin]

Hi,

Tommi Virtanen a écrit :
> On Wed, Jun 25, 2008 at 04:26:46PM -0700, Junio C Hamano wrote:
>>
>> In gitosis/serve.py, there are COMMANDS_READONLY and COMMANDS_WRITE array
>> that holds 'git-upload-pack' and 'git-receive-pack' commands, and they are
>> compared with user commands after doing:
> 
> Yeah, that's pretty much a trivial change, doing it now to future-proof
> gitosis.
> 

This just happened to me with a dashless client, so I tried your patch but it
does not work. The problem comes from git-shell that do not support dashless
argument, yet (IOW: git shell -c 'git upload-pack ...' give an error).

The following patch on top of yours fix the problem. The s/git-shell/git shell/
part is not really necessary, but why not?

diff --git a/gitosis/serve.py b/gitosis/serve.py
index 9a91fcb..5aac355 100644
--- a/gitosis/serve.py
+++ b/gitosis/serve.py
@@ -21,12 +21,10 @@ ALLOW_RE = re.compile("^'/*(?P<path>[a-zA-Z0-9][a-zA-Z0-9@._-]*(/[a-zA-Z0-9][a-z
 
 COMMANDS_READONLY = [
     'git-upload-pack',
-    'git upload-pack',
     ]
 
 COMMANDS_WRITE = [
     'git-receive-pack',
-    'git receive-pack',
     ]
 
 class ServingError(Exception):
@@ -75,7 +73,7 @@ def serve(
             # all known "git foo" commands take one argument; improve
             # if/when needed
             raise UnknownCommandError()
-        verb = '%s %s' % (verb, subverb)
+        verb = '%s-%s' % (verb, subverb)
 
     if (verb not in COMMANDS_WRITE
         and verb not in COMMANDS_READONLY):
@@ -201,6 +199,6 @@ class Main(app.App):
             sys.exit(1)
 
         main_log.debug('Serving %s', newcmd)
-        os.execvp('git-shell', ['git-shell', '-c', newcmd])
-        main_log.error('Cannot execute git-shell.')
+        os.execvp('git', ['git', 'shell', '-c', newcmd])
+        main_log.error('Cannot execute git.')
         sys.exit(1)


Olivier.

Re: [PATCH] daemon: accept "git program" as well

[Junio C Hamano]

Olivier Marin <dkr+ml.git@free.fr> writes:

> Hi,
>
> Tommi Virtanen a écrit :
>> On Wed, Jun 25, 2008 at 04:26:46PM -0700, Junio C Hamano wrote:
>>>
>>> In gitosis/serve.py, there are COMMANDS_READONLY and COMMANDS_WRITE array
>>> that holds 'git-upload-pack' and 'git-receive-pack' commands, and they are
>>> compared with user commands after doing:
>> 
>> Yeah, that's pretty much a trivial change, doing it now to future-proof
>> gitosis.
>> 
>
> This just happened to me with a dashless client, so I tried your patch but it
> does not work. The problem comes from git-shell that do not support dashless
> argument, yet (IOW: git shell -c 'git upload-pack ...' give an error).
>
> The following patch on top of yours fix the problem. The s/git-shell/git shell/
> part is not really necessary, but why not?
>
> diff --git a/gitosis/serve.py b/gitosis/serve.py
> index 9a91fcb..5aac355 100644
> --- a/gitosis/serve.py
> +++ b/gitosis/serve.py
> @@ -21,12 +21,10 @@ ALLOW_RE = re.compile("^'/*(?P<path>[a-zA-Z0-9][a-zA-Z0-9@._-]*(/[a-zA-Z0-9][a-z
>  
>  COMMANDS_READONLY = [
>      'git-upload-pack',
> -    'git upload-pack',
>      ]
>  
>  COMMANDS_WRITE = [
>      'git-receive-pack',
> -    'git receive-pack',
>      ]
>  
>  class ServingError(Exception):
> @@ -75,7 +73,7 @@ def serve(
>              # all known "git foo" commands take one argument; improve
>              # if/when needed
>              raise UnknownCommandError()
> -        verb = '%s %s' % (verb, subverb)
> +        verb = '%s-%s' % (verb, subverb)
>  
>      if (verb not in COMMANDS_WRITE
>          and verb not in COMMANDS_READONLY):
> @@ -201,6 +199,6 @@ class Main(app.App):
>              sys.exit(1)
>  
>          main_log.debug('Serving %s', newcmd)
> -        os.execvp('git-shell', ['git-shell', '-c', newcmd])
> -        main_log.error('Cannot execute git-shell.')
> +        os.execvp('git', ['git', 'shell', '-c', newcmd])
> +        main_log.error('Cannot execute git.')
>          sys.exit(1)

Hmm, Tommi, if you are doing command sanitizing yourself, is there a
reason to still invoke the command via git-shell?

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Theodore Tso]

On Tue, Jun 24, 2008 at 10:27:07PM -0700, Junio C Hamano wrote:
> Ok, let's map this out seriously.
> 
> * 1.6.0 will install the server-side programs in $(bindir) so that 
>   people coming over ssh will find them on the $PATH
> 
> * In 1.6.0 (and 1.5.6.1), we will change "git daemon" to accept both
>   "git-program" and "git program" forms.  When the spaced form is used, it
>   will behave as if the dashed form is requested.  This is a prerequisite
>   for client side change to start asking for "git program".
> 
> * In the near future, there will no client-side change.  "git-program"
>   will be asked for.
> 
> * 6 months after 1.6.0 ships, hopefully all the deployed server side will
>   be running that version or newer.  Client side will start asking for
>   "git program" by default, but we can still override with --upload-pack
>   and friends.
> 
> * 12 months after client side changes, everybody will be running that
>   version or newer.  We stop installing the server side programs in
>   $(bindir) but people coming over ssh will be asking for "git program"
>   and "git" will be on the $PATH so there is no issue.
> 
> The above 6 and 12 are yanked out of thin air and I am of course open to
> tweaking them, but I think the above order of events would be workable.

Is that really 6 and 12 months, or "6/12 months or at the next major
release boundary, whichever is later".  i.e., would make some of these
changes as part of a minor dot release, such as having the client side
change what it starts asking for in 1.6.3 or some such?  Presumably
the earliest that change would happen is 1.7, and the earliest to make
the server side installation changes is 1.8, right?  Or did you really
mean a hard 6/12 months, regardless of release cycle issues?

       	    	 	 	       	       - Ted

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Junio C Hamano]

Theodore Tso <tytso@mit.edu> writes:

> On Tue, Jun 24, 2008 at 10:27:07PM -0700, Junio C Hamano wrote:
> ...
>> The above 6 and 12 are yanked out of thin air and I am of course open to
>> tweaking them, but I think the above order of events would be workable.
>
> Is that really 6 and 12 months, or "6/12 months or at the next major
> release boundary, whichever is later".

Sigh... I thought you by now knew me better than that...

Yes, I didn't say it explicitly because I thought it was too obvious,
which was a mistake.  These except for the ones that are preparation (such
as "prepare daemon so that future clients can ask with non-dash forms")
need to happen at release boundaries, but these 6/12 months figures set
the minimums.  E.g. even if we had 6 week release cycles and 1.7.0 were to
be done 6 weeks after 1.6.0, that is still too early for the client side
to switch asking for "git program".

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> > "Shawn O. Pearce" <spearce@spearce.org> writes:
> >
> >>> Any other suggestions that is workable?
> >>
> >> diff --git a/builtin-clone.c b/builtin-clone.c
> >> index 5c5acb4..98d0f0f 100644
> >> --- a/builtin-clone.c
> >> +++ b/builtin-clone.c
> >> @@ -37,7 +37,7 @@ static int option_quiet, option_no_checkout, option_bare;
> >
> > << a patch to conditionally change "git-program" default to "git program"
> > snipped >>

Shouldn't "git upload-pack" work on the server side as far back as
0.99.9k?  That's back really old.  And my patch fixed "git " to be
"git-" when talking to git-daemon, thus keeping clients compatible
with all current git:// servers.

For SSH servers that can't handle "git upload-pack" the user can
change it to --upload-pack=git-upload-pack and get back to the
old behavior, until the server operator can upgrade.

Your patch doesn't offer that work around on the client side.
 
> Typofix: s/cond/uncond/;
> 
> > How would that help client that talk with git-daemon, unlike what I sent
> > earlier?

Check my change in git_connect again:

diff --git a/connect.c b/connect.c
index e92af29..dbabd93 100644
--- a/connect.c
+++ b/connect.c
@@ -576,8 +576,8 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
 		 * from extended components with a NUL byte.
 		 */
 		packet_write(fd[1],
-			     "%s %s%chost=%s%c",
-			     prog, path, 0,
+			     "git-%s %s%chost=%s%c",
+			     prog + 4, path, 0,
 			     target_host, 0);
 		free(target_host);
 		free(url);

Its buggy if the user tried to do "git ls-remote --upload-pack=crp git://"
but if this is the direction we want to go we can obviously work out a
better method of forcing "git " to be "git-" when talking to git-daemon.

> If we force --upload-pack workaround to _everybody_ we are already lost.
> 
> Also I think the previous one still lets you work it around by giving a
> full path, like "/usr/local/bin/git-upload-pack", because "/usr" does not
> match "git-" ;-)

Please tell me, where is git-upload-pack on repo.or.cz?

$ ssh repo.or.cz which git-upload-pack
fatal: unrecognized command 'which git-upload-pack'

I doubt I can pass it '/usr/local/bin/git-upload-pack' and get it
to work too.  So I don't think this is a good work around.

Obviously pasky will fix repo.or.cz to accept both at some point
in the near future, likely before 1.6.0 releases, because he's cool
like that.  Not everyone is.

Please don't make 1.6.0 unavailable to end-users because their
server operator can't currently accept "git upload-pack" without
giving them a workaround to force "git-upload-pack" over SSH.

-- 
Shawn.

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Junio C Hamano <gitster@pobox.com> wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>> > "Shawn O. Pearce" <spearce@spearce.org> writes:
>> >
>> >>> Any other suggestions that is workable?
>> >>
>> >> diff --git a/builtin-clone.c b/builtin-clone.c
>> >> index 5c5acb4..98d0f0f 100644
>> >> --- a/builtin-clone.c
>> >> +++ b/builtin-clone.c
>> >> @@ -37,7 +37,7 @@ static int option_quiet, option_no_checkout, option_bare;
>> >
>> > << a patch to conditionally change "git-program" default to "git program"
>> > snipped >>
>
> Shouldn't "git upload-pack" work on the server side as far back as
> 0.99.9k?

Yeah, I missed the patch to connect.c that was buried among other changes.
Sorry.

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Pasky also has to update:
>
> $ git ls-remote --upload-pack='git upload-pack' repo.or.cz:/srv/git/egit.git
> fatal: unrecognized command 'git upload-pack '/srv/git/egit.git''
> fatal: The remote end hung up unexpectedly

Of course.  I am assuming that he runs git-shell for user account, and
that's what the change in 'next' is about.

Re: [PATCH] Keep some git-* programs in $(bindir)

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
>  * しらいしななこ <nanako3@lavabit.com> writes:
>  > Doesn't "git archive --remote=<repo>" also execute git program on a remote machine?
> 
> diff --git a/Makefile b/Makefile
> index 929136b..742e7d3 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1268,7 +1268,7 @@ install: all
>  	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
>  	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
>  	$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
> -	$(INSTALL) git$X '$(DESTDIR_SQ)$(bindir_SQ)'
> +	$(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-archive$X '$(DESTDIR_SQ)$(bindir_SQ)'

I think you mean git-upload-archive, given what daemon.c says.
Or line 34 of builtin-archive.c, which calls git-upload-archive
by way of git_connect().

-- 
Shawn.

Re: [PATCH] Keep some git-* programs in $(bindir)

[Daniel Barkalow]

On Tue, 24 Jun 2008, Junio C Hamano wrote:

> Otherwise remote executions directly over ssh won't find them as they used
> to.  --upload-pack and --receive-pack options _could_ be used on the
> client side, but things should keep working out-of-box for older clients.
> 
> Later versions of clients (fetch-pack and send-pack) probably could start
> asking for these programs with dashless form, but that is a different
> topic.

Should they use "git upload-pack" or should they look for their helper 
programs in a libexec dir? I don't think that either of these programs is 
useful to run independantly, but I don't know if finding a program that 
doesn't go in $PATH on a remote machine is going to be any fun.

	-Daniel
*This .sig lefti ntentionally blank*

Re: [PATCH] Keep some git-* programs in $(bindir)

[Shawn O. Pearce]

Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Tue, 24 Jun 2008, Junio C Hamano wrote:
> 
> > Otherwise remote executions directly over ssh won't find them as they used
> > to.  --upload-pack and --receive-pack options _could_ be used on the
> > client side, but things should keep working out-of-box for older clients.
> > 
> > Later versions of clients (fetch-pack and send-pack) probably could start
> > asking for these programs with dashless form, but that is a different
> > topic.
> 
> Should they use "git upload-pack" or should they look for their helper 
> programs in a libexec dir? I don't think that either of these programs is 
> useful to run independantly, but I don't know if finding a program that 
> doesn't go in $PATH on a remote machine is going to be any fun.

IMHO they should in the future use "git upload-pack".

But this may not work with all servers, especially those that
use $SSH_ORIGINAL_COMMAND to dispatch to the correct command,
or abort if the user tries to request something dangerous.
Gitosis comes to mind.

I'm not sure we can get away with doing this in 1.6.0 as it is
effectively a network protocol breakage.  We have thus far never
caused a newer client to fail talking to an older server.  I'm
not sure we should start doing that in 1.6.0.

My vote is we keep the dashed form of these 3 commands in the
$PATH during 1.6 and remove them in 1.7, but when we do it we
must ensure there is a way to still request dashed form found
through $PATH when passing --upload-pack as an argument.

-- 
Shawn.

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

[Shawn O. Pearce]

 <nanako3@lavabit.com> wrote:
> Quoting Junio C Hamano <gitster@pobox.com>:
> > Miklos Vajna <vmiklos@frugalware.org> writes:
> >> On Tue, Jun 24, 2008 at 04:16:36PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> >>> It most likely makes sense to do (3) anyway.  upload-pack, receive-pack,
> >>> anything else?
> >>
> >> I think that's all.
> >
> > Then that would be this patch on top of nd/dashless topic.
> >
> >  Makefile |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 929136b..babf16b 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1268,7 +1268,7 @@ install: all
> >  	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
> >  	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
> >  	$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
> > -	$(INSTALL) git$X '$(DESTDIR_SQ)$(bindir_SQ)'
> > +	$(INSTALL) git$X git-upload-pack$X git-receive-pack$X '$(DESTDIR_SQ)$(bindir_SQ)'
> >  	$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
> >  	$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
> >  ifndef NO_TCLTK
> 
> Doesn't "git archive --remote=<repo>" also execute git program on a remote machine?

Yes, it runs git-upload-archive on the remote side.  The three
primary services for the remote side are documented in daemon.c:

    403 static struct daemon_service daemon_service[] = {
    404     { "upload-archive", "uploadarch", upload_archive, 0, 1 },
    405     { "upload-pack", "uploadpack", upload_pack, 1, 1 },
    406     { "receive-pack", "receivepack", receive_pack, 0, 1 },
    407 };

(with git- prefixes).

IMHO all three need to be in $PATH, along with git and gitk, through
at least a major revision release cycle to give clients a chance to
upgrade to something that uses "git foo" rather than "git-foo" when
talking to the remote.

-- 
Shawn.

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

[Jakub Narebski]

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

> Ah, there is not much we can do in that case then.  git-upload-pack is
> what the client asks you to run, and if you do not have it in the path,
> you can (1) either make sure it is on the path, (2) have the client be
> more explicit when asking for git-upload-pack (--upload-pack=$where), or
> (3) leave the minimum git-* binaries that can remotely be launched
> directly in the usual $PATH.
> 
> It most likely makes sense to do (3) anyway.  upload-pack, receive-pack,
> anything else?

What does "git ls-remote server:/home/vmiklos/git/test" invoke on server? 

-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Shawn O. Pearce]

Jakub Narebski <jnareb@gmail.com> wrote:
> 
> What does "git ls-remote server:/home/vmiklos/git/test" invoke on server? 

FYI, it actually runs git-upload-pack, gets the list of advertised
refs, then closes the connection immediately.  The other side sees
the client hang up and just terminates silently, since the client
didn't "want" anything packed and sent.

-- 
Shawn.

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

[Miklos Vajna]

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

On Tue, Jun 24, 2008 at 05:11:44PM -0700, Jakub Narebski <jnareb@gmail.com> wrote:
> What does "git ls-remote server:/home/vmiklos/git/test" invoke on server? 

$ git ls-remote server:/home/vmiklos/git/test
bash: git-upload-pack: command not found
fatal: The remote end hung up unexpectedly

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

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

It already is beginning to become clear what 1.6.0 will look like.  What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements.  But bigger changes will be:

 * MinGW will be in.

 * /usr/bin/git-cat-file is no more.  The bulk of the git commands will
   move to /usr/libexec/git-core/ or somesuch.

 * git-merge will be rewritten in C.

Currently tip of 'pu' is broken and does not pass tests, as j6t/mingw has
interaction with dr/ceiling and jc/merge-theirs has interaction with
mv/merge-in-c.

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

* jc/rerere (Sun Jun 22 02:04:31 2008 -0700) 5 commits
 - rerere.autoupdate
 - t4200: fix rerere test
 - rerere: remove dubious "tail_optimization"
 - git-rerere: detect unparsable conflicts
 - rerere: rerere_created_at() and has_resolution() abstraction

* sb/rebase (Sun Jun 22 01:55:50 2008 +0200) 2 commits
 + t3404: stricter tests for git-rebase--interactive
 + api-builtin.txt: update and fix typo

* sb/maint-rebase (Sun Jun 22 16:07:02 2008 +0200) 1 commit
 + git-rebase.sh: Add check if rebase is in progress

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

* lw/gitweb (Thu Jun 19 22:03:21 2008 +0200) 1 commit
 + gitweb: standarize HTTP status codes

* lt/config-fsync (Wed Jun 18 15:18:44 2008 -0700) 4 commits
 + Add config option to enable 'fsync()' of object files
 + Split up default "i18n" and "branch" config parsing into helper
   routines
 + Split up default "user" config parsing into helper routine
 + Split up default "core" config parsing into helper routine

* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
 + Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

* sr/tests (Sun Jun 8 16:04:35 2008 +0200) 3 commits
 + Hook up the result aggregation in the test makefile.
 + A simple script to parse the results from the testcases
 + Modify test-lib.sh to output stats to t/test-results/*

* jh/clone-packed-refs (Sun Jun 15 16:06:16 2008 +0200) 4 commits
 + Teach "git clone" to pack refs
 + Prepare testsuite for a "git clone" that packs refs
 + Move pack_refs() and friends into libgit
 + Incorporate fetched packs in future object traversal

This is useful when cloning from a repository with insanely large number
of refs.

* lw/perlish (Thu Jun 19 22:32:49 2008 +0200) 2 commits
 + Git.pm: add test suite
 + t/test-lib.sh: add test_external and test_external_without_stderr

Beginning of regression tests for Perl part of the system.

----------------------------------------------------------------
[Actively Cooking]

* mv/merge-in-c (Sat Jun 21 19:15:35 2008 +0200) 14 commits
 - Add new test case to ensure git-merge reduces octopus parents when
   possible
 - Add new test case to ensure git-merge filters for independent
   parents
 - Build in merge
 - Introduce reduce_heads()
 - Introduce get_merge_bases_many()
 - Add new test to ensure git-merge handles more than 25 refs.
 - Introduce get_octopus_merge_bases() in commit.c
 - git-fmt-merge-msg: make it usable from other builtins
 - Move read_cache_unmerged() to read-cache.c
 - parseopt: add a new PARSE_OPT_ARGV0_IS_AN_OPTION option
 - Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 - Move parse-options's skip_prefix() to git-compat-util.h
 - Move commit_list_count() to commit.c
 - Move split_cmdline() to alias.c

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 - Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 - git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 + Eliminate an unnecessary chdir("..")
 + Add support for GIT_CEILING_DIRECTORIES
 + Fold test-absolute-path into test-path-utils
 + Implement normalize_absolute_path

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

* rs/archive-ignore (Sun Jun 8 18:42:33 2008 +0200) 1 commit
 + Teach new attribute 'export-ignore' to git-archive

* lt/racy-empty (Tue Jun 10 10:44:43 2008 -0700) 1 commit
 + racy-git: an empty blob has a fixed object name

* sn/static (Thu Jun 19 08:21:11 2008 +0900) 2 commits
 + config.c: make git_env_bool() static
 + environment.c: remove unused function

* jc/maint-combine-diff-pre-context (Wed Jun 18 23:59:41 2008 -0700) 1 commit
 + diff -c/--cc: do not include uninteresting deletion before leading
   context

* lt/maint-gitdir-relative (Thu Jun 19 12:34:06 2008 -0700) 1 commit
 + Make git_dir a path relative to work_tree in setup_work_tree()

* jn/web (Tue Jun 10 19:21:44 2008 +0200) 2 commits
 + gitweb: Separate generating 'sort by' table header
 + gitweb: Separate filling list of projects info

* rg/gitweb (Fri Jun 6 09:53:32 2008 +0200) 1 commit
 + gitweb: remove git_blame and rename git_blame2 to git_blame

* kh/update-ref (Tue Jun 3 01:34:53 2008 +0200) 2 commits
 + Make old sha1 optional with git update-ref -d
 + Clean up builtin-update-ref's option parsing

* mo/status-untracked (Thu Jun 5 14:47:50 2008 +0200) 3 commits
 + Add configuration option for default untracked files mode
 + Add argument 'no' commit/status option -u|--untracked-files
 + Add an optional <mode> argument to commit/status -u|--untracked-
   files option

* jk/test (Sat Jun 14 03:28:07 2008 -0400) 5 commits
 + enable whitespace checking of test scripts
 + avoid trailing whitespace in zero-change diffstat lines
 + avoid whitespace on empty line in automatic usage message
 + mask necessary whitespace policy violations in test scripts
 + fix whitespace violations in test scripts

Tightens whitespace rules for t/*.sh scripts.

* pb/fast-export (Wed Jun 11 13:17:04 2008 +0200) 1 commit
 + builtin-fast-export: Add importing and exporting of revision marks

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

* ph/mergetool (Mon Jun 16 17:33:41 2008 -0600) 1 commit
 + Remove the use of '--' in merge program invocation

Waiting for success reports from people who use various backends.

* j6t/mingw (Sat Nov 17 20:48:14 2007 +0100) 38 commits
 - compat/pread.c: Add a forward declaration to fix a warning
 - Windows: Fix ntohl() related warnings about printf formatting
 - Windows: TMP and TEMP environment variables specify a temporary
   directory.
 - Windows: Make 'git help -a' work.
 - Windows: Work around an oddity when a pipe with no reader is
   written to.
 - Windows: Make the pager work.
 - When installing, be prepared that template_dir may be relative.
 - Windows: Use a relative default template_dir and ETC_GITCONFIG
 - Windows: Compute the fallback for exec_path from the program
   invocation.
 - Turn builtin_exec_path into a function.
 - Windows: Use a customized struct stat that also has the st_blocks
   member.
 - Windows: Add a custom implementation for utime().
 - Windows: Add a new lstat and fstat implementation based on Win32
   API.
 - Windows: Implement a custom spawnve().
 - Windows: Implement wrappers for gethostbyname(), socket(), and
   connect().
 - Windows: Work around incompatible sort and find.
 - Windows: Implement asynchronous functions as threads.
 - Windows: Disambiguate DOS style paths from SSH URLs.
 - Windows: A rudimentary poll() emulation.
 - Windows: Change the name of hook scripts to make them not
   executable.
 - Windows: Implement start_command().
 - Windows: A pipe() replacement whose ends are not inherited to
   children.
 - Windows: Wrap execve so that shell scripts can be invoked.
 - Windows: Implement setitimer() and sigaction().
 - Windows: Fix PRIuMAX definition.
 - Windows: Implement gettimeofday().
 - Windows: Handle absolute paths in
   safe_create_leading_directories().
 - Windows: Treat Windows style path names.
 - setup.c: Prepare for Windows directory separators.
 - Windows: Work around misbehaved rename().
 - Windows: always chmod(, 0666) before unlink().
 - Windows: A minimal implemention of getpwuid().
 - Windows: Implement a wrapper of the open() function.
 - Windows: Strip ".exe" from the program name.
 - Windows: Use the Windows style PATH separator ';'.
 - Add target architecture MinGW.
 - Compile some programs only conditionally.
 - Add compat/regex.[ch] and compat/fnmatch.[ch].

No explanation is necessary ;-).  The series is probably 'next' worthy
as-is.

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

----------------------------------------------------------------
[Stalled/Needs more work]

* jc/reflog-expire (Sun Jun 15 23:48:46 2008 -0700) 1 commit
 - Per-ref reflog expiry configuration

Perhaps a good foundation for optionally unexpirable stash.  As 1.6.0 will
be a good time to make backward incompatible changes, we might make expiry
period of stash 'never' in new repositories.  Needs a concensus.

* jc/merge-theirs (Fri Jun 20 00:17:59 2008 -0700) 2 commits
 - git-merge-recursive-{ours,theirs}
 - git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends may need to change, though.

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.

----------------------------------------------------------------
[Dropped for now]

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 . Introduce fast forward option only
 . Head reduction before selecting merge strategy
 . Restructure git-merge.sh
 . Introduce -ff=<fast forward option>
 . New merge tests
 . Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C.

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 . Use perl instead of tac
 . Fix t3404 assumption that `wc -l` does not use whitespace.
 . rebase -i: Use : in expr command instead of match.
 . rebase -i: update the implementation of 'mark' command
 . Add option --preserve-tags
 . Teach rebase interactive the tag command
 . Add option --first-parent
 . Do rebase with preserve merges with advanced TODO list
 . Select all lines with fake-editor
 . Unify the length of $SHORT* and the commits in the TODO list
 . Teach rebase interactive the merge command
 . Move redo merge code in a function
 . Teach rebase interactive the reset command
 . Teach rebase interactive the mark command
 . Move cleanup code into it's own function
 . Don't append default merge message to -m message
 . fake-editor: output TODO list if unchanged

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 . WIP: rethink replay merge
 . Start using replay-tree merge in cherry-pick
 . revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time 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

Just my toy at this moment.

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

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

[Miklos Vajna]

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

On Mon, Jun 23, 2008 at 12:15:35AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> * mv/merge-in-c (Sat Jun 21 19:15:35 2008 +0200) 14 commits
>  - Add new test case to ensure git-merge reduces octopus parents when
>    possible
>  - Add new test case to ensure git-merge filters for independent
>    parents
>  - Build in merge
>  - Introduce reduce_heads()
>  - Introduce get_merge_bases_many()
>  - Add new test to ensure git-merge handles more than 25 refs.
>  - Introduce get_octopus_merge_bases() in commit.c
>  - git-fmt-merge-msg: make it usable from other builtins
>  - Move read_cache_unmerged() to read-cache.c
>  - parseopt: add a new PARSE_OPT_ARGV0_IS_AN_OPTION option
>  - Add new test to ensure git-merge handles pull.twohead and
>    pull.octopus
>  - Move parse-options's skip_prefix() to git-compat-util.h
>  - Move commit_list_count() to commit.c
>  - Move split_cmdline() to alias.c

"Add new test case to ensure git-merge reduces octopus parents when
possible" does exactly the same as "Add new test case to ensure
git-merge filters for independent parents", so I think you should drop
the later. Only the name of the test and the commit message differs, and
I think we want to avoid redundancy in the testsuite. ;-)

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

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.

It already is beginning to become clear what 1.6.0 will look like.  What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements.  But bigger changes will be:

 * MinGW will be in.

 * /usr/bin/git-cat-file is no more.  The bulk of the git commands will
   move to /usr/libexec/git-core/ or somesuch.

 * git-merge will be rewritten in C.

 * default pack and idx versions will be updated as scheduled for some
   time ago.

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

* ph/parseopt-step-blame (Tue Jun 24 11:12:12 2008 +0200) 7 commits
 - Migrate git-blame to parse-option partially.
 - parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
 - parse-opt: fake short strings for callers to believe in.
 - parse-opt: do not pring errors on unknown options, return -2
   intead.
 - parse-opt: create parse_options_step.
 - parse-opt: Export a non NORETURN usage dumper.
 - parse-opt: have parse_options_{start,end}.

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

* lw/gitweb (Thu Jun 19 22:03:21 2008 +0200) 1 commit
 + gitweb: standarize HTTP status codes

* lt/config-fsync (Wed Jun 18 15:18:44 2008 -0700) 4 commits
 + Add config option to enable 'fsync()' of object files
 + Split up default "i18n" and "branch" config parsing into helper
   routines
 + Split up default "user" config parsing into helper routine
 + Split up default "core" config parsing into helper routine

* nd/dashless (Tue Jun 24 19:58:11 2008 -0700) 2 commits
 + Keep some git-* programs in $(bindir)
 + Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  We'll leave server-side programs in $(bindir) 
so that ssh clients can ask for "git-program" and find them on the $PATH.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

* sr/tests (Sun Jun 8 16:04:35 2008 +0200) 3 commits
 + Hook up the result aggregation in the test makefile.
 + A simple script to parse the results from the testcases
 + Modify test-lib.sh to output stats to t/test-results/*

* jh/clone-packed-refs (Sun Jun 15 16:06:16 2008 +0200) 4 commits
 + Teach "git clone" to pack refs
 + Prepare testsuite for a "git clone" that packs refs
 + Move pack_refs() and friends into libgit
 + Incorporate fetched packs in future object traversal

This is useful when cloning from a repository with insanely large number
of refs.

* lw/perlish (Thu Jun 19 22:32:49 2008 +0200) 2 commits
 + Git.pm: add test suite
 + t/test-lib.sh: add test_external and test_external_without_stderr

Beginning of regression tests for Perl part of the system.

----------------------------------------------------------------
[Actively Cooking]

* mv/merge-in-c (Sat Jun 21 19:15:35 2008 +0200) 12 commits
 - Add new test case to ensure git-merge reduces octopus parents when
   possible
 - Build in merge
 - Introduce reduce_heads()
 - Introduce get_merge_bases_many()
 - Add new test to ensure git-merge handles more than 25 refs.
 - Introduce get_octopus_merge_bases() in commit.c
 - git-fmt-merge-msg: make it usable from other builtins
 - Move read_cache_unmerged() to read-cache.c
 - Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 - Move parse-options's skip_prefix() to git-compat-util.h
 - Move commit_list_count() to commit.c
 - Move split_cmdline() to alias.c

I dropped the change to parseopt in this series and fixed up the caller.

* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
 + Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 + git-shell: accept "git foo" form

We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 + Eliminate an unnecessary chdir("..")
 + Add support for GIT_CEILING_DIRECTORIES
 + Fold test-absolute-path into test-path-utils
 + Implement normalize_absolute_path

* jc/rerere (Sun Jun 22 02:04:31 2008 -0700) 5 commits
 - rerere.autoupdate
 - t4200: fix rerere test
 - rerere: remove dubious "tail_optimization"
 - git-rerere: detect unparsable conflicts
 - rerere: rerere_created_at() and has_resolution() abstraction

* sb/rebase (Sun Jun 22 01:55:50 2008 +0200) 2 commits
 + t3404: stricter tests for git-rebase--interactive
 + api-builtin.txt: update and fix typo

* sb/maint-rebase (Sun Jun 22 16:07:02 2008 +0200) 1 commit
 + git-rebase.sh: Add check if rebase is in progress

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


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

* ph/mergetool (Mon Jun 16 17:33:41 2008 -0600) 1 commit
 + Remove the use of '--' in merge program invocation

Waiting for success reports from people who use various backends.

* j6t/mingw (Sat Nov 17 20:48:14 2007 +0100) 39 commits
 - compat/pread.c: Add a forward declaration to fix a warning
 - Windows: Fix ntohl() related warnings about printf formatting
 - Windows: TMP and TEMP environment variables specify a temporary
   directory.
 - Windows: Make 'git help -a' work.
 - Windows: Work around an oddity when a pipe with no reader is
   written to.
 - Windows: Make the pager work.
 - When installing, be prepared that template_dir may be relative.
 - Windows: Use a relative default template_dir and ETC_GITCONFIG
 - Windows: Compute the fallback for exec_path from the program
   invocation.
 - Turn builtin_exec_path into a function.
 - Windows: Use a customized struct stat that also has the st_blocks
   member.
 - Windows: Add a custom implementation for utime().
 - Windows: Add a new lstat and fstat implementation based on Win32
   API.
 - Windows: Implement a custom spawnve().
 - Windows: Implement wrappers for gethostbyname(), socket(), and
   connect().
 - Windows: Work around incompatible sort and find.
 - Windows: Implement asynchronous functions as threads.
 - Windows: Disambiguate DOS style paths from SSH URLs.
 - Windows: A rudimentary poll() emulation.
 - Windows: Change the name of hook scripts to make them not
   executable.
 - Windows: Implement start_command().
 - Windows: A pipe() replacement whose ends are not inherited to
   children.
 - Windows: Wrap execve so that shell scripts can be invoked.
 - Windows: Implement setitimer() and sigaction().
 - Windows: Fix PRIuMAX definition.
 - Windows: Implement gettimeofday().
 - Make my_mktime() public and rename it to tm_to_time_t()
 - Windows: Work around misbehaved rename().
 - Windows: always chmod(, 0666) before unlink().
 - Windows: A minimal implemention of getpwuid().
 - Windows: Implement a wrapper of the open() function.
 - Windows: Strip ".exe" from the program name.
 - Windows: Handle absolute paths in
   safe_create_leading_directories().
 - Windows: Treat Windows style path names.
 - setup.c: Prepare for Windows directory separators.
 - Windows: Use the Windows style PATH separator ';'.
 - Add target architecture MinGW.
 - Compile some programs only conditionally.
 - Add compat/regex.[ch] and compat/fnmatch.[ch].

No explanation is necessary ;-).  The series is probably 'next' worthy
as-is, except that template renaming hack won't be needed anymore.

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

----------------------------------------------------------------
[Stalled/Needs more work]

* jc/reflog-expire (Sun Jun 15 23:48:46 2008 -0700) 1 commit
 - Per-ref reflog expiry configuration

Perhaps a good foundation for optionally unexpirable stash.  As 1.6.0 will
be a good time to make backward incompatible changes, we might make expiry
period of stash 'never' in new repositories.  Needs a concensus.

* jc/merge-theirs (Fri Jun 20 00:17:59 2008 -0700) 2 commits
 - git-merge-recursive-{ours,theirs}
 - git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends may need to change, though.

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.

----------------------------------------------------------------
[Dropped for now]

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 . Introduce fast forward option only
 . Head reduction before selecting merge strategy
 . Restructure git-merge.sh
 . Introduce -ff=<fast forward option>
 . New merge tests
 . Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C.

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 . Use perl instead of tac
 . Fix t3404 assumption that `wc -l` does not use whitespace.
 . rebase -i: Use : in expr command instead of match.
 . rebase -i: update the implementation of 'mark' command
 . Add option --preserve-tags
 . Teach rebase interactive the tag command
 . Add option --first-parent
 . Do rebase with preserve merges with advanced TODO list
 . Select all lines with fake-editor
 . Unify the length of $SHORT* and the commits in the TODO list
 . Teach rebase interactive the merge command
 . Move redo merge code in a function
 . Teach rebase interactive the reset command
 . Teach rebase interactive the mark command
 . Move cleanup code into it's own function
 . Don't append default merge message to -m message
 . fake-editor: output TODO list if unchanged

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 . WIP: rethink replay merge
 . Start using replay-tree merge in cherry-pick
 . revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time 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

Just my toy at this moment.

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

[PATCH] Make default expiration period of reflog used for stash infinite

[Junio C Hamano]

This makes the default expiration period for the reflog that implements
stash infinite.

The original behaviour to autoexpire old stashes can be restored by using
the gc.refs/stash.{reflogexpire,reflogexpireunreachable} configration
variables introduced by the previous commit.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 > [Stalled/Needs more work]
 >
 > * jc/reflog-expire (Sun Jun 15 23:48:46 2008 -0700) 1 commit
 >  - Per-ref reflog expiry configuration
 >
 > Perhaps a good foundation for optionally unexpirable stash.  As 1.6.0 will
 > be a good time to make backward incompatible changes, we might make expiry
 > period of stash 'never' in new repositories.  Needs a concensus.

 builtin-reflog.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/builtin-reflog.c b/builtin-reflog.c
index 0711728..125d455 100644
--- a/builtin-reflog.c
+++ b/builtin-reflog.c
@@ -441,6 +441,17 @@ static void set_reflog_expiry_param(struct cmd_reflog_expire_cb *cb, int slot, c
 		}
 	}
 
+	/*
+	 * If unconfigured, make stash never expire
+	 */
+	if (!strcmp(ref, "refs/stash")) {
+		if (!(slot & EXPIRE_TOTAL))
+			cb->expire_total = 0;
+		if (!(slot & EXPIRE_UNREACH))
+			cb->expire_unreachable = 0;
+		return;
+	}
+
 	/* Nothing matched -- use the default value */
 	if (!(slot & EXPIRE_TOTAL))
 		cb->expire_total = default_reflog_expire;
-- 
1.5.6.1.102.g8e69d

Re: [PATCH] Make default expiration period of reflog used for stash infinite

[Olivier Marin]

Junio C Hamano a écrit :
> This makes the default expiration period for the reflog that implements
> stash infinite.

I did not read the whole thread so maybe I missed something but I though you
wanted to apply Nanako's patch before?

The patch: http://article.gmane.org/gmane.comp.version-control.git/85055

Olivier.

Re: [PATCH] Make default expiration period of reflog used for stash infinite

[Junio C Hamano]

Olivier Marin <dkr+ml.git@free.fr> writes:

> Junio C Hamano a écrit :
>> This makes the default expiration period for the reflog that implements
>> stash infinite.
>
> I did not read the whole thread so maybe I missed something but I though you
> wanted to apply Nanako's patch before?
>
> The patch: http://article.gmane.org/gmane.comp.version-control.git/85055

Thanks for reminding, but I am of two minds about the change.

 (1) The change would untie the base tree of the stash from the history
     behind it and allow previously rewound tips of branches that these
     stashes were built on top of.  Without the patch, these otherwise
     unreachable commits will never be reclaimed.

 (2) Today, you can say "git log stash" (note the lack of "-g" option) to
     view the history behind the stash through two artificial commits that
     stash creates.  This will become impossible with the patch.

Probably I am worrying too much; I do not personally think the second
point matters in the real life.  If "git log stash" _were_ any useful,
it means the history behind the stash entries are not useless at all, but
in that case the user would be using regular branches to store them
anyway.

[PATCH] Disconnect stash from its base commit

[Nanako Shiraishi]

A stash records the state of the files in the working tree as a merge
between the HEAD and another commit that records the state of the index,
that in turn is a child commit of the HEAD commit.  In order to later
apply (or pop) the stash, however, only the tree objects of these three
commits are necessary.

This patch changes the structure of a stash to use a parentless new commit
that has the same tree as the HEAD commit, in place of the HEAD commit.
This way, a stash does not keep the history that leads to the HEAD commit
reachable, even if the stash is kept forever.

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---

 The patch in the message Olivier quoted alone will be insufficient.  This
 is an update to that patch.

 Documentation/git-stash.txt |   14 +++++++-------
 git-stash.sh                |    3 +++
 t/t3903-stash.sh            |    2 +-
 3 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 23ac331..17c65e9 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -101,18 +101,18 @@ DISCUSSION
 ----------
 
 A stash is represented as a commit whose tree records the state of the
-working directory, and its first parent is the commit at `HEAD` when
-the stash was created.  The tree of the second parent records the
+working directory, and its first parent is the commit that has the same
+tree as the `HEAD`.  The tree of the second parent records the
 state of the index when the stash is made, and it is made a child of
-the `HEAD` commit.  The ancestry graph looks like this:
+the first commit.  The ancestry graph looks like this:
 
             .----W
            /    /
-     -----H----I
+	  H*---I
 
-where `H` is the `HEAD` commit, `I` is a commit that records the state
-of the index, and `W` is a commit that records the state of the working
-tree.
+where `H{asterisk}` is a commit with the same tree as the `HEAD`, `I` is
+a commit that records the state of the index, and `W` is a commit that
+records the state of the working tree.
 
 
 EXAMPLES
diff --git a/git-stash.sh b/git-stash.sh
index 4938ade..8f374b3 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -54,6 +54,9 @@ create_stash () {
 	fi
 	msg=$(printf '%s: %s' "$branch" "$head")
 
+	# create the base commit that is parentless
+	b_commit=$(printf 'base of %s\n' "$msg" | git commit-tree "HEAD:")
+
 	# state of the index
 	i_tree=$(git write-tree) &&
 	i_commit=$(printf 'index on %s\n' "$msg" |
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 54d99ed..b083c04 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -32,7 +32,7 @@ index 0cfbf08..00750ed 100644
 EOF
 
 test_expect_success 'parents of stash' '
-	test $(git rev-parse stash^) = $(git rev-parse HEAD) &&
+	test $(git rev-parse stash^^{tree}) = $(git rev-parse HEAD^{tree}) &&
 	git diff stash^2..stash > output &&
 	test_cmp output expect
 '
-- 
1.5.6

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

Re: [PATCH] Disconnect stash from its base commit

[Johannes Schindelin]

Hi,

On Wed, 2 Jul 2008, Nanako Shiraishi wrote:

> A stash records the state of the files in the working tree as a merge 
> between the HEAD and another commit that records the state of the index, 
> that in turn is a child commit of the HEAD commit.  In order to later 
> apply (or pop) the stash, however, only the tree objects of these three 
> commits are necessary.
> 
> This patch changes the structure of a stash to use a parentless new 
> commit that has the same tree as the HEAD commit, in place of the HEAD 
> commit. This way, a stash does not keep the history that leads to the 
> HEAD commit reachable, even if the stash is kept forever.

May I register my suspicion that this is the wrong direction to go?

I actually find it quite nice that I can easily see in gitk where I 
spawned off a certain stash, indeed, how the recent stash history 
(manually specified with "stash@{0} stash@{1} stash@{2}" [*1*]), relates 
to the current branch's history.

Ciao,
Dscho

P.S.: I vaguely remember that I once wrote a patch to turn "stash@{0..2}" 
into exactly the same, but I do not remember why I did not follow up on 
it.  Was it refuted, or unwanted?

Re: [PATCH] Disconnect stash from its base commit

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> This patch changes the structure of a stash to use a parentless new 
>> commit that has the same tree as the HEAD commit, in place of the HEAD 
>> commit. This way, a stash does not keep the history that leads to the 
>> HEAD commit reachable, even if the stash is kept forever.
>
> May I register my suspicion that this is the wrong direction to go?
>
> I actually find it quite nice that I can easily see in gitk where I 
> spawned off a certain stash, indeed, how the recent stash history 
> (manually specified with "stash@{0} stash@{1} stash@{2}" [*1*]), relates 
> to the current branch's history.

A stash may primarily be for applying the change to random place, but
where it was created is not a useless information.  The very original use
case that was in the discussion "git stash" (actually its original form
"git save") was first posted was "I am in the middle of something, and get
interrupted.  Stash the changes away to switch branches to deal with the
emergency for a while so that I can later come back to where I was, and I
want both saving away and coming back easy operations".  A stash _can_ be
applied to any random other state, but "coming back" is very much part of
what it should have supported, and not recording the base commit means we
would lose that capability.

	Side note.  In addition to the current "stash apply" and "stash
	pop", "stash branch $stash newbranchname" that does

        	git checkout -b newbranchanme $stash^

	(i.e. create a new branch starting from the state you were in)
	might be a good ingredient to support a more git-like workflow to
	resume.  If your original branch gained extra commits, was
	rewound, or was rebased during the emergency/distraction, you may
	not have anywhere to apply/pop the stash without conflicts when
	you want to "come back" with normal

        	git checkout somebranch && git stash pop

	But that imaginary "stash branch" command would always give you
	the exact state you were in and creates a clean fork to finish
	what you were doing, and continue.

So the base commit is an integral part of what a stash is, and I agree
with you that an unexpiring stash that pins the whole history beind it is
a feature.  It is not unncessary cruft that accumulates that we need to
worry about.

Re: [PATCH] Disconnect stash from its base commit

[Abhijit Menon-Sen]

At 2008-07-02 12:01:35 -0700, gitster@pobox.com wrote:
>
> 	But that imaginary "stash branch" command would always give you
> 	the exact state you were in and creates a clean fork to finish
> 	what you were doing, and continue.

Nice idea. Something as simple as the appended diff?

I reversed the stash/branch arguments so that one need specify only the
branch name. Playing with it a little, it feels very useful.

-- ams

diff --git a/git-stash.sh b/git-stash.sh
index 4938ade..d5ecd24 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -218,6 +218,21 @@ drop_stash () {
 	git rev-parse --verify "$ref_stash@{0}" > /dev/null 2>&1 || clear_stash
 }
 
+apply_to_branch () {
+	have_stash || die 'Nothing to apply'
+
+	test -n "$1" || die 'No branch name specified'
+	branch=$1
+
+	if test -z "$2"
+	then
+		set x "$ref_stash@{0}"
+	fi
+	stash=$2
+
+	git-checkout -b $branch $stash^ && apply_stash $stash
+}
+
 # Main command set
 case "$1" in
 list)
@@ -264,6 +279,10 @@ pop)
 		drop_stash "$@"
 	fi
 	;;
+branch)
+	shift
+	apply_to_branch "$@"
+	;;
 *)
 	if test $# -eq 0
 	then

Re: [PATCH] Disconnect stash from its base commit

[Junio C Hamano]

Abhijit Menon-Sen <ams@toroid.org> writes:

> At 2008-07-02 12:01:35 -0700, gitster@pobox.com wrote:
>>
>> 	But that imaginary "stash branch" command would always give you
>> 	the exact state you were in and creates a clean fork to finish
>> 	what you were doing, and continue.
>
> Nice idea. Something as simple as the appended diff?
>
> I reversed the stash/branch arguments so that one need specify only the
> branch name. Playing with it a little, it feels very useful.

I'd further suggest to delete the stash automatically when you create a
new branch out of it.

[PATCH] Implement "git stash branch <newbranch> <stash>"

[Abhijit Menon-Sen]

Restores the stashed state on a new branch rooted at the commit on which
the stash was originally created, so that conflicts caused by subsequent
changes on the original branch can be dealt with.

(Thanks to Junio for this nice idea.)
---
 Documentation/git-stash.txt |   19 ++++++++++++++++++-
 git-stash.sh                |   21 +++++++++++++++++++++
 2 files changed, 39 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 23ac331..cfc1c28 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -8,8 +8,11 @@ git-stash - Stash the changes in a dirty working directory away
 SYNOPSIS
 --------
 [verse]
-'git stash' (list | show [<stash>] | apply [<stash>] | clear | drop [<stash>] | pop [<stash>])
+'git stash' list
+'git stash' (show | apply | drop | pop ) [<stash>]
+'git stash' branch <branchname> [<stash>]
 'git stash' [save [<message>]]
+'git stash' clear
 
 DESCRIPTION
 -----------
@@ -81,6 +84,20 @@ tree's changes, but also the index's ones. However, this can fail, when you
 have conflicts (which are stored in the index, where you therefore can no
 longer apply the changes as they were originally).
 
+branch <branchname> [<stash>]::
+
+	Creates and checks out a new branch named `<branchname>` starting from
+	the commit at which the `<stash>` was originally created, applies the
+	changes recorded in `<stash>` to the new working tree, and drops the
+	`<stash>` if that completes successfully. When no `<stash>` is given,
+	applies the latest one.
++
+This is useful if the branch on which you ran `git stash save` has
+changed enough that `git stash apply` fails due to conflicts. Since
+the stash is applied on top of the commit that was HEAD at the time
+`git stash` was run, it restores the originally stashed state with
+no conflicts.
+
 clear::
 	Remove all the stashed states. Note that those states will then
 	be subject to pruning, and may be difficult or impossible to recover.
diff --git a/git-stash.sh b/git-stash.sh
index 4938ade..8e50b03 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -218,6 +218,23 @@ drop_stash () {
 	git rev-parse --verify "$ref_stash@{0}" > /dev/null 2>&1 || clear_stash
 }
 
+apply_to_branch () {
+	have_stash || die 'Nothing to apply'
+
+	test -n "$1" || die 'No branch name specified'
+	branch=$1
+
+	if test -z "$2"
+	then
+		set x "$ref_stash@{0}"
+	fi
+	stash=$2
+
+	git-checkout -b $branch $stash^ &&
+	apply_stash $stash &&
+	drop_stash $stash
+}
+
 # Main command set
 case "$1" in
 list)
@@ -264,6 +281,10 @@ pop)
 		drop_stash "$@"
 	fi
 	;;
+branch)
+	shift
+	apply_to_branch "$@"
+	;;
 *)
 	if test $# -eq 0
 	then
-- 
1.5.6

Re: [PATCH] Implement "git stash branch <newbranch> <stash>"

[Junio C Hamano]

Abhijit Menon-Sen <ams@toroid.org> writes:

> +branch <branchname> [<stash>]::
> +
> +	Creates and checks out a new branch named `<branchname>` starting from
> +	the commit at which the `<stash>` was originally created, applies the
> +	changes recorded in `<stash>` to the new working tree, and drops the
> +	`<stash>` if that completes successfully. When no `<stash>` is given,
> +	applies the latest one.
> ++
> +This is useful if the branch on which you ran `git stash save` has
> +changed enough that `git stash apply` fails due to conflicts. Since
> +the stash is applied on top of the commit that was HEAD at the time
> +`git stash` was run, it restores the originally stashed state with
> +no conflicts.

Perhaps we would want to replay the stash always with --index for this
application.  By definition this will be conflict-free both in the index
and in the working tree.

I've also toyed with an idea to make <branchname> optional, and detach the
HEAD if <branchname> is not given.  It would be a useful mode of operation
but one problem is that it is _not_ an operation that should be called
"branch" anymore.

[PATCH] Implement "git stash branch <newbranch> <stash>"

[Abhijit Menon-Sen]

Restores the stashed state on a new branch rooted at the commit on which
the stash was originally created, so that conflicts caused by subsequent
changes on the original branch can be dealt with.

(Thanks to Junio for this nice idea.)

Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
---
 Documentation/git-stash.txt |   19 ++++++++++++++++++-
 git-stash.sh                |   21 +++++++++++++++++++++
 2 files changed, 39 insertions(+), 1 deletions(-)

(Reposting with --index and the missing Signed-off-by added.)

diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 23ac331..a4cbd0c 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -8,8 +8,11 @@ git-stash - Stash the changes in a dirty working directory away
 SYNOPSIS
 --------
 [verse]
-'git stash' (list | show [<stash>] | apply [<stash>] | clear | drop [<stash>] | pop [<stash>])
+'git stash' list
+'git stash' (show | apply | drop | pop ) [<stash>]
+'git stash' branch <branchname> [<stash>]
 'git stash' [save [<message>]]
+'git stash' clear
 
 DESCRIPTION
 -----------
@@ -81,6 +84,20 @@ tree's changes, but also the index's ones. However, this can fail, when you
 have conflicts (which are stored in the index, where you therefore can no
 longer apply the changes as they were originally).
 
+branch <branchname> [<stash>]::
+
+	Creates and checks out a new branch named `<branchname>` starting from
+	the commit at which the `<stash>` was originally created, applies the
+	changes recorded in `<stash>` to the new working tree and index, then
+	drops the `<stash>` if that completes successfully. When no `<stash>`
+	is given, applies the latest one.
++
+This is useful if the branch on which you ran `git stash save` has
+changed enough that `git stash apply` fails due to conflicts. Since
+the stash is applied on top of the commit that was HEAD at the time
+`git stash` was run, it restores the originally stashed state with
+no conflicts.
+
 clear::
 	Remove all the stashed states. Note that those states will then
 	be subject to pruning, and may be difficult or impossible to recover.
diff --git a/git-stash.sh b/git-stash.sh
index 4938ade..889445c 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -218,6 +218,23 @@ drop_stash () {
 	git rev-parse --verify "$ref_stash@{0}" > /dev/null 2>&1 || clear_stash
 }
 
+apply_to_branch () {
+	have_stash || die 'Nothing to apply'
+
+	test -n "$1" || die 'No branch name specified'
+	branch=$1
+
+	if test -z "$2"
+	then
+		set x "$ref_stash@{0}"
+	fi
+	stash=$2
+
+	git-checkout -b $branch $stash^ &&
+	apply_stash --index $stash &&
+	drop_stash $stash
+}
+
 # Main command set
 case "$1" in
 list)
@@ -264,6 +281,10 @@ pop)
 		drop_stash "$@"
 	fi
 	;;
+branch)
+	shift
+	apply_to_branch "$@"
+	;;
 *)
 	if test $# -eq 0
 	then
-- 
1.5.6

[PATCH v3] Implement "git stash branch <newbranch> <stash>"

[Abhijit Menon-Sen]

Restores the stashed state on a new branch rooted at the commit on which
the stash was originally created, so that conflicts caused by subsequent
changes on the original branch can be dealt with.

(Thanks to Junio for this nice idea.)

Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
---
Reposting as requested with a new test included.

 Documentation/git-stash.txt |   19 ++++++++++++++++++-
 git-stash.sh                |   21 +++++++++++++++++++++
 t/t3903-stash.sh            |   24 ++++++++++++++++++++++++
 3 files changed, 63 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 23ac331..a4cbd0c 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -8,8 +8,11 @@ git-stash - Stash the changes in a dirty working directory away
 SYNOPSIS
 --------
 [verse]
-'git stash' (list | show [<stash>] | apply [<stash>] | clear | drop [<stash>] | pop [<stash>])
+'git stash' list
+'git stash' (show | apply | drop | pop) [<stash>]
+'git stash' branch <branchname> [<stash>]
 'git stash' [save [<message>]]
+'git stash' clear
 
 DESCRIPTION
 -----------
@@ -81,6 +84,20 @@ tree's changes, but also the index's ones. However, this can fail, when you
 have conflicts (which are stored in the index, where you therefore can no
 longer apply the changes as they were originally).
 
+branch <branchname> [<stash>]::
+
+	Creates and checks out a new branch named `<branchname>` starting from
+	the commit at which the `<stash>` was originally created, applies the
+	changes recorded in `<stash>` to the new working tree and index, then
+	drops the `<stash>` if that completes successfully. When no `<stash>`
+	is given, applies the latest one.
++
+This is useful if the branch on which you ran `git stash save` has
+changed enough that `git stash apply` fails due to conflicts. Since
+the stash is applied on top of the commit that was HEAD at the time
+`git stash` was run, it restores the originally stashed state with
+no conflicts.
+
 clear::
 	Remove all the stashed states. Note that those states will then
 	be subject to pruning, and may be difficult or impossible to recover.
diff --git a/git-stash.sh b/git-stash.sh
index 4938ade..889445c 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -218,6 +218,23 @@ drop_stash () {
 	git rev-parse --verify "$ref_stash@{0}" > /dev/null 2>&1 || clear_stash
 }
 
+apply_to_branch () {
+	have_stash || die 'Nothing to apply'
+
+	test -n "$1" || die 'No branch name specified'
+	branch=$1
+
+	if test -z "$2"
+	then
+		set x "$ref_stash@{0}"
+	fi
+	stash=$2
+
+	git-checkout -b $branch $stash^ &&
+	apply_stash --index $stash &&
+	drop_stash $stash
+}
+
 # Main command set
 case "$1" in
 list)
@@ -264,6 +281,10 @@ pop)
 		drop_stash "$@"
 	fi
 	;;
+branch)
+	shift
+	apply_to_branch "$@"
+	;;
 *)
 	if test $# -eq 0
 	then
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 54d99ed..6d89218 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -117,4 +117,28 @@ test_expect_success 'stash pop' '
 	test 0 = $(git stash list | wc -l)
 '
 
+cat > expect << EOF
+diff --git a/file b/file
+index 7601807..5716ca5 100644
+--- a/file
++++ b/file
+@@ -1 +1 @@
+-baz
++bar
+EOF
+
+test_expect_success 'stash apply' '
+	echo foo > file &&
+	git commit file -m first
+	echo bar > file &&
+	git stash &&
+	echo baz > file &&
+	git commit file -m second &&
+	git stash branch stashbranch &&
+	git commit file -m alternate\ second &&
+	git diff master..stashbranch > output &&
+	test_cmp output expect &&
+	test 0 = $(git stash list | wc -l)
+'
+
 test_done
-- 
1.5.6

Re: [PATCH v3] Implement "git stash branch <newbranch> <stash>"

[Johannes Schindelin]

Hi,

On Sun, 6 Jul 2008, Abhijit Menon-Sen wrote:

> Restores the stashed state on a new branch rooted at the commit on which
> the stash was originally created, so that conflicts caused by subsequent
> changes on the original branch can be dealt with.
> 
> (Thanks to Junio for this nice idea.)
> 
> Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
> ---
> Reposting as requested with a new test included.

AFAICS the previous version is in 'next' already: 
656b50345239293929ad8c639c5f1941c6b867ad

Hth,
Dscho

[PATCH] Add a test for "git stash branch"

[Abhijit Menon-Sen]

Make sure that applying the stash to a new branch after a conflicting
change doesn't result in an error when you try to commit.

Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
---

At 2008-07-06 14:54:44 +0200, Johannes.Schindelin@gmx.de wrote:
>
> AFAICS the previous version is in 'next' already: 
> 656b50345239293929ad8c639c5f1941c6b867ad

Oh, I see, thanks. I misunderstood the request. Here's a separate patch
to just add the test.

Sorry for the noise.

-- ams

 t/t3903-stash.sh |   24 ++++++++++++++++++++++++
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 54d99ed..6d89218 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -117,4 +117,28 @@ test_expect_success 'stash pop' '
 	test 0 = $(git stash list | wc -l)
 '
 
+cat > expect << EOF
+diff --git a/file b/file
+index 7601807..5716ca5 100644
+--- a/file
++++ b/file
+@@ -1 +1 @@
+-baz
++bar
+EOF
+
+test_expect_success 'stash apply' '
+	echo foo > file &&
+	git commit file -m first
+	echo bar > file &&
+	git stash &&
+	echo baz > file &&
+	git commit file -m second &&
+	git stash branch stashbranch &&
+	git commit file -m alternate\ second &&
+	git diff master..stashbranch > output &&
+	test_cmp output expect &&
+	test 0 = $(git stash list | wc -l)
+'
+
 test_done
-- 
1.5.6

Re: [PATCH] Add a test for "git stash branch"

[Junio C Hamano]

Abhijit Menon-Sen <ams@toroid.org> writes:

> At 2008-07-06 14:54:44 +0200, Johannes.Schindelin@gmx.de wrote:
>>
>> AFAICS the previous version is in 'next' already: 
>> 656b50345239293929ad8c639c5f1941c6b867ad
>
> Oh, I see, thanks. I misunderstood the request. Here's a separate patch
> to just add the test.

Oh, there is no misunderstanding.  You couldn't have possibly known if the
main body of the patch will go to 'next' or just be dropped when I said
"you might also want to have tests" to you.

> +test_expect_success 'stash apply' '
> +	echo foo > file &&
> +	git commit file -m first
> +	echo bar > file &&
> +	git stash &&
> +	echo baz > file &&
> +	git commit file -m second &&
> +	git stash branch stashbranch &&
> +	git commit file -m alternate\ second &&
> +	git diff master..stashbranch > output &&
> +	test_cmp output expect &&
> +	test 0 = $(git stash list | wc -l)
> +'

The title is probably not 'stash apply' but 'stash branch'.  Don't you
want to also validate that:

 - "stash branch" command switched to the new branch "stashbranch"?

 - before making "alternate second", the index and the working tree have
   expected contents?  and

 - the final shape of the history looks correctly forked (i.e.
   "stashbranch" branches at the commit before "-m second" commit was
   made)?

>  test_done
> -- 
> 1.5.6

[PATCH v2] Add a test for "git stash branch"

[Abhijit Menon-Sen]

Make sure that applying the stash to a new branch after a conflicting
change doesn't result in an error when you try to commit.

Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
---

At 2008-07-06 12:53:02 -0700, gitster@pobox.com wrote:
>
> The title is probably not 'stash apply' but 'stash branch'.

Fixed, thanks.

> Don't you want to also validate that: [...]

Done.

-- ams

 t/t3903-stash.sh |   61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 61 insertions(+), 0 deletions(-)

diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 54d99ed..bd1cdab 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -117,4 +117,65 @@ test_expect_success 'stash pop' '
 	test 0 = $(git stash list | wc -l)
 '
 
+cat > expect << EOF
+diff --git a/file2 b/file2
+new file mode 100644
+index 0000000..1fe912c
+--- /dev/null
++++ b/file2
+@@ -0,0 +1 @@
++bar2
+EOF
+
+cat > expect1 << EOF
+diff --git a/file b/file
+index 257cc56..5716ca5 100644
+--- a/file
++++ b/file
+@@ -1 +1 @@
+-foo
++bar
+EOF
+
+cat > expect2 << EOF
+diff --git a/file b/file
+index 7601807..5716ca5 100644
+--- a/file
++++ b/file
+@@ -1 +1 @@
+-baz
++bar
+diff --git a/file2 b/file2
+new file mode 100644
+index 0000000..1fe912c
+--- /dev/null
++++ b/file2
+@@ -0,0 +1 @@
++bar2
+EOF
+
+test_expect_success 'stash branch' '
+	echo foo > file &&
+	git commit file -m first
+	echo bar > file &&
+	echo bar2 > file2 &&
+	git add file2 &&
+	git stash &&
+	echo baz > file &&
+	git commit file -m second &&
+	git stash branch stashbranch &&
+	test refs/heads/stashbranch = $(git symbolic-ref HEAD) &&
+	test $(git rev-parse HEAD) = $(git rev-parse master^) &&
+	git diff --cached > output &&
+	test_cmp output expect &&
+	git diff > output &&
+	test_cmp output expect1 &&
+	git add file &&
+	git commit -m alternate\ second &&
+	git diff master..stashbranch &&
+	git diff master..stashbranch > output &&
+	test_cmp output expect2 &&
+	test 0 = $(git stash list | wc -l)
+'
+
 test_done
-- 
1.5.6

[PATCH] Teach git-merge to pass -X<option> to the backend strategy module

[Junio C Hamano]

Distinguishing slight variation of modes of operation between the vanilla
merge-recursive and merge-recursive-ours by the command name may have been
an easy way to experiment, but we should bite the bullet and allow backend
specific options to be given by the end user.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 > [Stalled/Needs more work]
 >
 > * jc/merge-theirs (Fri Jun 20 00:17:59 2008 -0700) 2 commits
 >  - git-merge-recursive-{ours,theirs}
 >  - git-merge-file --ours, --theirs
 >
 > Punting a merge by discarding your own work in conflicting parts but still
 > salvaging the parts that are cleanly automerged.  It is likely that this
 > will result in nonsense mishmash, but somehow often people want this, so
 > here they are.  The interface to the backends may need to change, though.

 Makefile                     |    3 ---
 builtin-merge-recursive.c    |   23 +++++++++++++++--------
 git-merge.sh                 |   11 ++++++++---
 t/t6034-merge-ours-theirs.sh |    4 ++--
 4 files changed, 25 insertions(+), 16 deletions(-)

diff --git a/Makefile b/Makefile
index 82d2892..b003e3e 100644
--- a/Makefile
+++ b/Makefile
@@ -304,8 +304,6 @@ BUILT_INS += git-format-patch$X
 BUILT_INS += git-fsck-objects$X
 BUILT_INS += git-get-tar-commit-id$X
 BUILT_INS += git-init$X
-BUILT_INS += git-merge-recursive-ours$X
-BUILT_INS += git-merge-recursive-theirs$X
 BUILT_INS += git-merge-subtree$X
 BUILT_INS += git-peek-remote$X
 BUILT_INS += git-repo-config$X
@@ -1383,7 +1381,6 @@ check-docs::
 	do \
 		case "$$v" in \
 		git-merge-octopus | git-merge-ours | git-merge-recursive | \
-		git-merge-recursive-ours | git-merge-recursive-theirs | \
 		git-merge-resolve | git-merge-stupid | git-merge-subtree | \
 		git-fsck-objects | git-init-db | \
 		git-?*--?* ) continue ;; \
diff --git a/builtin-merge-recursive.c b/builtin-merge-recursive.c
index a355e7a..6541e16 100644
--- a/builtin-merge-recursive.c
+++ b/builtin-merge-recursive.c
@@ -1407,12 +1407,6 @@ int cmd_merge_recursive(int argc, const char **argv, const char *prefix)
 		if (8 < namelen &&
 		    !strcmp(argv[0] + namelen - 8, "-subtree"))
 			merge_recursive_variants = MERGE_RECURSIVE_SUBTREE;
-		else if (5 < namelen &&
-			 !strcmp(argv[0] + namelen - 5, "-ours"))
-			merge_recursive_variants = MERGE_RECURSIVE_OURS;
-		else if (7 < namelen &&
-			 !strcmp(argv[0] + namelen - 7, "-theirs"))
-			merge_recursive_variants = MERGE_RECURSIVE_THEIRS;
 	}
 
 	git_config(merge_config, NULL);
@@ -1423,8 +1417,21 @@ int cmd_merge_recursive(int argc, const char **argv, const char *prefix)
 		die("Usage: %s <base>... -- <head> <remote> ...\n", argv[0]);
 
 	for (i = 1; i < argc; ++i) {
-		if (!strcmp(argv[i], "--"))
-			break;
+		const char *arg = argv[i];
+
+		if (!prefixcmp(arg, "--")) {
+			if (!arg[2])
+				break;
+			if (!strcmp(arg+2, "ours"))
+				merge_recursive_variants = MERGE_RECURSIVE_OURS;
+			else if (!strcmp(arg+2, "theirs"))
+				merge_recursive_variants = MERGE_RECURSIVE_THEIRS;
+			else if (!strcmp(arg+2, "subtree"))
+				merge_recursive_variants = MERGE_RECURSIVE_SUBTREE;
+			else
+				die("Unknown option %s", arg);
+			continue;
+		}
 		if (bases_count < sizeof(bases)/sizeof(*bases))
 			bases[bases_count++] = argv[i];
 	}
diff --git a/git-merge.sh b/git-merge.sh
index 39b5cd9..d475852 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -17,6 +17,7 @@ commit               perform a commit if the merge succeeds (default)
 ff                   allow fast forward (default)
 s,strategy=          merge strategy to use
 m,message=           message to be used for the merge commit (if any)
+X=                   pass merge strategy specific options
 "
 
 SUBDIRECTORY_OK=Yes
@@ -31,12 +32,12 @@ LF='
 '
 
 all_strategies='recur recursive octopus resolve stupid ours subtree'
-all_strategies="$all_strategies recursive-ours recursive-theirs"
 default_twohead_strategies='recursive'
 default_octopus_strategies='octopus'
 no_fast_forward_strategies='subtree ours'
-no_trivial_strategies='recursive recur subtree ours recursive-ours recursive-theirs'
+no_trivial_strategies='recursive recur subtree ours'
 use_strategies=
+backend_option=
 
 allow_fast_forward=t
 allow_trivial_merge=t
@@ -187,6 +188,10 @@ parse_config () {
 			merge_msg="$1"
 			have_message=t
 			;;
+		-X)
+			shift
+			backend_option="$backend_option --$1"
+			;;
 		--)
 			shift
 			break ;;
@@ -451,7 +456,7 @@ do
     # Remember which strategy left the state in the working tree
     wt_strategy=$strategy
 
-    git-merge-$strategy $common -- "$head_arg" "$@"
+    git-merge-$strategy $backend_option $common -- "$head_arg" "$@"
     exit=$?
     if test "$no_commit" = t && test "$exit" = 0
     then
diff --git a/t/t6034-merge-ours-theirs.sh b/t/t6034-merge-ours-theirs.sh
index 56a9247..91f0f63 100755
--- a/t/t6034-merge-ours-theirs.sh
+++ b/t/t6034-merge-ours-theirs.sh
@@ -35,7 +35,7 @@ test_expect_success 'plain recursive - should conflict' '
 
 test_expect_success 'recursive favouring theirs' '
 	git reset --hard master &&
-	git merge -s recursive-theirs side &&
+	git merge -s recursive -Xtheirs side &&
 	! grep nine file &&
 	grep nueve file &&
 	! grep 9 file &&
@@ -45,7 +45,7 @@ test_expect_success 'recursive favouring theirs' '
 
 test_expect_success 'recursive favouring ours' '
 	git reset --hard master &&
-	git merge -s recursive-ours side &&
+	git merge -s recursive -Xours side &&
 	grep nine file &&
 	! grep nueve file &&
 	! grep 9 file &&
-- 
1.5.6.1.102.g8e69d

Re: [PATCH] Teach git-merge to pass -X<option> to the backend strategy module

[Jakub Narebski]

Junio C Hamano wrote:

> diff --git a/git-merge.sh b/git-merge.sh
> index 39b5cd9..d475852 100755
> --- a/git-merge.sh
> +++ b/git-merge.sh
> @@ -17,6 +17,7 @@ commit               perform a commit if the merge succeeds (default)
>  ff                   allow fast forward (default)
>  s,strategy=          merge strategy to use
>  m,message=           message to be used for the merge commit (if any)
> +X=                   pass merge strategy specific options
>  "

You have updated usage for git-merge, but didn't update manpages
(Documentation).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH] Teach git-merge to pass -X<option> to the backend strategy module

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano wrote:
>
>> diff --git a/git-merge.sh b/git-merge.sh
>> index 39b5cd9..d475852 100755
>> --- a/git-merge.sh
>> +++ b/git-merge.sh
>> @@ -17,6 +17,7 @@ commit               perform a commit if the merge succeeds (default)
>>  ff                   allow fast forward (default)
>>  s,strategy=          merge strategy to use
>>  m,message=           message to be used for the merge commit (if any)
>> +X=                   pass merge strategy specific options
>>  "
>
> You have updated usage for git-merge, but didn't update manpages
> (Documentation).

Patches welcome ;-)

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

[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 topics list the commits in reverse chronological order.  The topics
meant to be applied to the maintenance series have "maint-" in their
names.

It already is beginning to become clear what 1.6.0 will look like.  What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements.  Bigger changes will be:

 * MinGW will be in.

 * /usr/bin/git-cat-file is no more.  The bulk of the git commands will
   move to /usr/libexec/git-core/ or somesuch.

 * git-merge will be rewritten in C.

 * default pack and idx versions will be updated as scheduled for some
   time ago.

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

* jk/maint-fetch-ref-hier (Thu Jun 26 23:59:50 2008 -0400) 1 commit
 + fetch: report local storage errors in status table

When the remote used to have "foo" branch but now has "foo/bar", fetch
refuses to delete the existing remote tracking branch "foo" to create a
new remote tracking branch "foo/bar", but the error message was
confusing.

* jc/maint-reset (Wed Jun 25 18:16:36 2008 -0700) 1 commit
 + Allow "git-reset path" when unambiguous

We used to require "git-reset -- path" even when there is no ambiguity
(i.e. path cannot be mistaken as a valid tree-ish and it is a filename in
the work tree).

* js/maint-clone-insteadof (Fri Jun 27 13:56:05 2008 +0100) 1 commit
 . clone: respect url.insteadOf setting in global configs

"git clone" does not honor "url.InsteadOf" in $HOME/.gitconfig; Daniel
seems to have ideas for a better fix than this, but this is worth fixing
on 'maint'.

* tr/send-email-ssl (Thu Jun 26 23:03:21 2008 +0200) 2 commits
 + git-send-email: prevent undefined variable warnings if no
   encryption is set
 + git-send-email: add support for TLS via Net::SMTP::SSL

* kb/send-email-fifo (Wed Jun 25 15:44:40 2008 -0700) 1 commit
 + git-send-email: Accept fifos as well as files

Two minor send-email feature enhancements for 1.6.0.

* jc/checkdiff (Thu Jun 26 16:08:05 2008 -0700) 6 commits
 + Update sample pre-commit hook to use "diff --check"
 + diff --check: detect leftover conflict markers
 + Teach "diff --check" about new blank lines at end
 + checkdiff: pass diff_options to the callback
 + check_and_emit_line(): rename and refactor
 + diff --check: explain why we do not care whether old side is
   binary

Allows us to replace the sample pre-commit hook that was not aware of the
line termination convention per path nor newer whitespace breakage rules.

* np/pack-default (Wed Jun 25 00:25:53 2008 -0400) 2 commits
 + pack.indexversion config option now defaults to 2
 + repack.usedeltabaseoffset config option now defaults to "true"

Updates the default value for pack.indexversion to 2 and use delta-base
offset encoding of the packfiles by default.

* js/apply-recount (Fri Jun 27 18:43:09 2008 +0100) 1 commit
 + Allow git-apply to recount the lines in a hunk (AKA recountdiff)

A good ingredient for implementing "apply --edit".

* dz/apply-again (Fri Jun 27 14:39:12 2008 -0400) 1 commit
 + git-apply: handle a patch that touches the same path more than
   once better

Allows us to feed a patch that touches the same path more than once.

* ph/parseopt-step-blame (Tue Jun 24 11:12:12 2008 +0200) 7 commits
 - Migrate git-blame to parse-option partially.
 - parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
 - parse-opt: fake short strings for callers to believe in.
 - parse-opt: do not pring errors on unknown options, return -2
   intead.
 - parse-opt: create parse_options_step.
 - parse-opt: Export a non NORETURN usage dumper.
 - parse-opt: have parse_options_{start,end}.

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

* nd/dashless (Tue Jun 24 19:58:11 2008 -0700) 2 commits
 + Keep some git-* programs in $(bindir)
 + Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  We'll leave server-side programs in $(bindir) 
so that ssh clients can ask for "git-program" and find them on the $PATH.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 4 commits
 + Revert "Make clients ask for "git program" over ssh and local
   transport"
 + Make clients ask for "git program" over ssh and local transport
 + Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 + git-shell: accept "git foo" form

----------------------------------------------------------------
[Actively Cooking]

* jc/reflog-expire (Sat Jun 28 22:24:49 2008 -0700) 2 commits
 - Make default expiration period of reflog used for stash infinite
 - Per-ref reflog expiry configuration

As 1.6.0 will be a good time to make backward incompatible changes, the
tip commit makes the default expiry period of stash 'never', unless you
configure them to expire explicitly using gc.refs/stash.* variables.
Needs consensus, but I am guessing that enough people would want stash
that does not expire.

* jc/merge-theirs (Sat Jun 28 17:28:22 2008 -0700) 3 commits
 - Teach git-merge to pass -X<option> to the backend strategy module
 - git-merge-recursive-{ours,theirs}
 - git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends is updated so that you can
say "git merge -Xours -s recursive other" now.

* j6t/mingw (Sat Nov 17 20:48:14 2007 +0100) 38 commits
 + compat/pread.c: Add a forward declaration to fix a warning
 + Windows: Fix ntohl() related warnings about printf formatting
 + Windows: TMP and TEMP environment variables specify a temporary
   directory.
 + Windows: Make 'git help -a' work.
 + Windows: Work around an oddity when a pipe with no reader is
   written to.
 + Windows: Make the pager work.
 + When installing, be prepared that template_dir may be relative.
 + Windows: Use a relative default template_dir and ETC_GITCONFIG
 + Windows: Compute the fallback for exec_path from the program
   invocation.
 + Turn builtin_exec_path into a function.
 + Windows: Use a customized struct stat that also has the st_blocks
   member.
 + Windows: Add a custom implementation for utime().
 + Windows: Add a new lstat and fstat implementation based on Win32
   API.
 + Windows: Implement a custom spawnve().
 + Windows: Implement wrappers for gethostbyname(), socket(), and
   connect().
 + Windows: Work around incompatible sort and find.
 + Windows: Implement asynchronous functions as threads.
 + Windows: Disambiguate DOS style paths from SSH URLs.
 + Windows: A rudimentary poll() emulation.
 + Windows: Implement start_command().
 + Windows: A pipe() replacement whose ends are not inherited to
   children.
 + Windows: Wrap execve so that shell scripts can be invoked.
 + Windows: Implement setitimer() and sigaction().
 + Windows: Fix PRIuMAX definition.
 + Windows: Implement gettimeofday().
 + Make my_mktime() public and rename it to tm_to_time_t()
 + Windows: Work around misbehaved rename().
 + Windows: always chmod(, 0666) before unlink().
 + Windows: A minimal implemention of getpwuid().
 + Windows: Implement a wrapper of the open() function.
 + Windows: Strip ".exe" from the program name.
 + Windows: Handle absolute paths in
   safe_create_leading_directories().
 + Windows: Treat Windows style path names.
 + setup.c: Prepare for Windows directory separators.
 + Windows: Use the Windows style PATH separator ';'.
 + Add target architecture MinGW.
 + Compile some programs only conditionally.
 + Add compat/regex.[ch] and compat/fnmatch.[ch].

No explanation necessary ;-)

* mv/merge-in-c (Sat Jun 28 04:38:19 2008 +0200) 13 commits
 - Build in merge
 - Add new test case to ensure git-merge prepends the custom merge
   message
 - Add new test case to ensure git-merge reduces octopus parents when
   possible
 - Introduce reduce_heads()
 - Introduce get_merge_bases_many()
 - Add new test to ensure git-merge handles more than 25 refs.
 - Introduce get_octopus_merge_bases() in commit.c
 - git-fmt-merge-msg: make it usable from other builtins
 - Move read_cache_unmerged() to read-cache.c
 - Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 - Move parse-options's skip_prefix() to git-compat-util.h
 - Move commit_list_count() to commit.c
 - Move split_cmdline() to alias.c

The last one is a huge patch and it will take some time to review and get
details sorted out.

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 + Eliminate an unnecessary chdir("..")
 + Add support for GIT_CEILING_DIRECTORIES
 + Fold test-absolute-path into test-path-utils
 + Implement normalize_absolute_path

* jc/rerere (Sun Jun 22 02:04:31 2008 -0700) 5 commits
 + rerere.autoupdate
 + t4200: fix rerere test
 + rerere: remove dubious "tail_optimization"
 + git-rerere: detect unparsable conflicts
 + rerere: rerere_created_at() and has_resolution() abstraction

A new configuration will allow paths that have been resolved cleanly by
rerere to be updated in the index automatically.

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

* sb/rebase (Sun Jun 22 01:55:50 2008 +0200) 2 commits
 + t3404: stricter tests for git-rebase--interactive
 + api-builtin.txt: update and fix typo

* sb/maint-rebase (Sun Jun 22 16:07:02 2008 +0200) 1 commit
 + git-rebase.sh: Add check if rebase is in progress

* lw/gitweb (Thu Jun 19 22:03:21 2008 +0200) 1 commit
 + gitweb: standarize HTTP status codes

* lt/config-fsync (Wed Jun 18 15:18:44 2008 -0700) 4 commits
 + Add config option to enable 'fsync()' of object files
 + Split up default "i18n" and "branch" config parsing into helper
   routines
 + Split up default "user" config parsing into helper routine
 + Split up default "core" config parsing into helper routine

* sr/tests (Sun Jun 8 16:04:35 2008 +0200) 3 commits
 + Hook up the result aggregation in the test makefile.
 + A simple script to parse the results from the testcases
 + Modify test-lib.sh to output stats to t/test-results/*

* jh/clone-packed-refs (Sun Jun 15 16:06:16 2008 +0200) 4 commits
 + Teach "git clone" to pack refs
 + Prepare testsuite for a "git clone" that packs refs
 + Move pack_refs() and friends into libgit
 + Incorporate fetched packs in future object traversal

This is useful when cloning from a repository with insanely large number
of refs.

* lw/perlish (Thu Jun 19 22:32:49 2008 +0200) 2 commits
 + Git.pm: add test suite
 + t/test-lib.sh: add test_external and test_external_without_stderr

Beginning of regression tests for Perl part of the system.

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

* ph/mergetool (Mon Jun 16 17:33:41 2008 -0600) 1 commit
 + Remove the use of '--' in merge program invocation

Waiting for success reports from people who use various backends.

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

----------------------------------------------------------------
[Stalled/Needs more work]

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.

----------------------------------------------------------------
[Dropped for now]

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 . Introduce fast forward option only
 . Head reduction before selecting merge strategy
 . Restructure git-merge.sh
 . Introduce -ff=<fast forward option>
 . New merge tests
 . Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C.

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 . Use perl instead of tac
 . Fix t3404 assumption that `wc -l` does not use whitespace.
 . rebase -i: Use : in expr command instead of match.
 . rebase -i: update the implementation of 'mark' command
 . Add option --preserve-tags
 . Teach rebase interactive the tag command
 . Add option --first-parent
 . Do rebase with preserve merges with advanced TODO list
 . Select all lines with fake-editor
 . Unify the length of $SHORT* and the commits in the TODO list
 . Teach rebase interactive the merge command
 . Move redo merge code in a function
 . Teach rebase interactive the reset command
 . Teach rebase interactive the mark command
 . Move cleanup code into it's own function
 . Don't append default merge message to -m message
 . fake-editor: output TODO list if unchanged

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 . WIP: rethink replay merge
 . Start using replay-tree merge in cherry-pick
 . revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time 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

Just my toy at this moment.

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

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

[Linus Torvalds]

On Sun, 29 Jun 2008, Junio C Hamano wrote:
> 
>  * /usr/bin/git-cat-file is no more.  The bulk of the git commands will
>    move to /usr/libexec/git-core/ or somesuch.

Every time I read this note I do a double-take.

To me, the first sentence means that 'cat-file' command is gone. Then, the 
second sentence is just gibberish. And since I understand what you _want_ 
to say, I then go back and parse it properly, and know that you don't 
actually mean that git-cat-file is removed, but that it's removed from 
being accessible under that name in the path.

So to avoid my double-take, and hopefully avoid confusion for other 
people, can you please make your status report rephrase that thing.

Maybe just say

 * Do not install all git subcommands as 'git-xyzzy' files in the user 
   path. This avoids unnecessary hardlinks (or copies on systems that do 
   not support links), and enforces the 'git xyzzy' syntax.

   Subcommands that aren't builtins now get installed in
   /usr/libexec/git-core/ or somesuch.

(I haven't looked at the series, but I _assume_ it also avoids installing 
the builtin subcommands entirely when not necessary, ie "git-cat-file" 
really _is_ gone, but it's not because the "cat-file" command itself is 
gone).

Hmm? Or maybe it's just me who gets confused by the phrasing.

		Linus

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

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> Maybe just say
>
>  * Do not install all git subcommands as 'git-xyzzy' files in the user 
>    path. This avoids unnecessary hardlinks (or copies on systems that do 
>    not support links), and enforces the 'git xyzzy' syntax.
>
>    Subcommands that aren't builtins now get installed in
>    /usr/libexec/git-core/ or somesuch.

Thanks.

> (I haven't looked at the series, but I _assume_ it also avoids installing 
> the builtin subcommands entirely when not necessary, ie "git-cat-file" 
> really _is_ gone, but it's not because the "cat-file" command itself is 
> gone).

It is actually a fairly long road ahead.

In 1.6.0, most of them will be moved to /usr/libexec/git-core/, so that
really old scripts end users may have can be more easily kept working by
simply saying:

	PATH=$(git --exec-path):$PATH

early, without doing "s/git-/git /g".

Current git clients run git-upload-pack and friends in "git-xyzzy" form
when accessing remote repositories directly over ssh, so in 1.6.0 we will
have to leave these server side programs in $(bindir) as well.

git-shell and gitosis is being updated to accept "git upload-pack" form as
well, and after older versions of these programs die out, we can update
the clients to ask for remote side programs without dash.

None of the server side programs is built-in, so we could start the
hardlink removal independent from this transition (iow, "Only subcommands
that aren't builtin will be installed in libexec, builtins are not on the
disk anywhere" could happen now), but I'd prefer to keep changes in each
steps small to minimize impacts to the end users' environments.

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

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> To me, the first sentence means that 'cat-file' command is gone....

Here is a replacement I am preparing, taken from the draft release notes
to 1.6.0:

 * With the default Makefile settings, most of the programs will be
   installed outside your $PATH, except for "git", "gitk", "git-gui" and
   some server side programs that need to be accessible for technical
   reasons.  Invoking a git subcommand as "git-xyzzy" from the command
   line has been deprecated since early 2006 (and officially announced in
   1.5.4 release notes); use of them from your scripts after adding
   output from "git --exec-path" to the $PATH will still be supported in
   1.6.0, but users are again strongly encouraged to adjust their
   scripts to use "git xyzzy" form, as we will stop installing
   "git-xyzzy" hardlinks for built-in commands in later releases.

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

[Pieter de Bie]

On 29 jun 2008, at 22:11, Junio C Hamano wrote:

> use of them from your scripts after adding
>   output from "git --exec-path" to the $PATH will still be supported  
> in
>   1.6.0, but users are again strongly encouraged to adjust their
>   scripts to use "git xyzzy" form, as we will stop installing
>   "git-xyzzy" hardlinks for built-in commands in later releases.

I think msysgit doesn't (didn't?) install the hardlinks to conserve  
space,
as Windows doesn't support hard links. Perhaps we should mention that
as well?

- Pieter

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

[Johannes Schindelin]

Hi,

On Sun, 29 Jun 2008, Pieter de Bie wrote:

> On 29 jun 2008, at 22:11, Junio C Hamano wrote:
> 
> >  use of them from your scripts after adding output from "git 
> >  --exec-path" to the $PATH will still be supported in 1.6.0, but users 
> >  are again strongly encouraged to adjust their scripts to use "git 
> >  xyzzy" form, as we will stop installing "git-xyzzy" hardlinks for 
> >  built-in commands in later releases.
> 
> I think msysgit doesn't (didn't?) install the hardlinks to conserve 
> space, as Windows doesn't support hard links.

Please do not spread FUD.  Where available, we install hardlinks.

And even if we did not, given that we do not yet actively support MinGW, I 
think your suggestion is a bit early, to say the least.

Ciao,
Dscho

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

[Steffen Prohaska]

On Jun 29, 2008, at 10:15 PM, Pieter de Bie wrote:

>
> On 29 jun 2008, at 22:11, Junio C Hamano wrote:
>
>> use of them from your scripts after adding
>>  output from "git --exec-path" to the $PATH will still be supported  
>> in
>>  1.6.0, but users are again strongly encouraged to adjust their
>>  scripts to use "git xyzzy" form, as we will stop installing
>>  "git-xyzzy" hardlinks for built-in commands in later releases.
>
> I think msysgit doesn't (didn't?) install the hardlinks to conserve  
> space,
> as Windows doesn't support hard links. Perhaps we should mention that
> as well?

Windows does support hardlinks and msysgit uses them.

	Steffen

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

[Jeff King]

On Sun, Jun 29, 2008 at 01:55:13AM -0700, Junio C Hamano wrote:

> * jk/maint-fetch-ref-hier (Thu Jun 26 23:59:50 2008 -0400) 1 commit
>  + fetch: report local storage errors in status table
> 
> When the remote used to have "foo" branch but now has "foo/bar", fetch
> refuses to delete the existing remote tracking branch "foo" to create a
> new remote tracking branch "foo/bar", but the error message was
> confusing.

Where do we want to take this? The conversation went something like:

   me: here's a patch where we hint about "remote prune"
  you: why not just fix the refs, it's no worse than a rewind
   me: we kill reflogs, so it is different than a rewind
  you: oh, right

So I'm not sure if that was "Oh, right, it's not a good idea to remove
the conflicting ref" or "Oh, right, but it's probably still fine."

-Peff

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Sun, Jun 29, 2008 at 01:55:13AM -0700, Junio C Hamano wrote:
>
>> * jk/maint-fetch-ref-hier (Thu Jun 26 23:59:50 2008 -0400) 1 commit
>>  + fetch: report local storage errors in status table
>> 
>> When the remote used to have "foo" branch but now has "foo/bar", fetch
>> refuses to delete the existing remote tracking branch "foo" to create a
>> new remote tracking branch "foo/bar", but the error message was
>> confusing.
>
> Where do we want to take this? The conversation went something like:
>
>    me: here's a patch where we hint about "remote prune"
>   you: why not just fix the refs, it's no worse than a rewind
>    me: we kill reflogs, so it is different than a rewind
>   you: oh, right
>
> So I'm not sure if that was "Oh, right, it's not a good idea to remove
> the conflicting ref" or "Oh, right, but it's probably still fine."

It is "Oh right, it is Ok.  Let's cook it in 'next', have it in 'master'
and then backmerge to 'maint'".

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

[Jeff King]

On Sun, Jun 29, 2008 at 10:31:00PM -0700, Junio C Hamano wrote:

> > Where do we want to take this? The conversation went something like:
> >
> >    me: here's a patch where we hint about "remote prune"
> >   you: why not just fix the refs, it's no worse than a rewind
> >    me: we kill reflogs, so it is different than a rewind
> >   you: oh, right
> >
> > So I'm not sure if that was "Oh, right, it's not a good idea to remove
> > the conflicting ref" or "Oh, right, but it's probably still fine."
> 
> It is "Oh right, it is Ok.  Let's cook it in 'next', have it in 'master'
> and then backmerge to 'maint'".

Sorry if I'm being slow, but what is "it" here? The "warning" patch I
sent, or a to-be-posted patch that deletes the conflicting ref?

-Peff

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Sun, Jun 29, 2008 at 10:31:00PM -0700, Junio C Hamano wrote:
>
>> > Where do we want to take this? The conversation went something like:
>> >
>> >    me: here's a patch where we hint about "remote prune"
>> >   you: why not just fix the refs, it's no worse than a rewind
>> >    me: we kill reflogs, so it is different than a rewind
>> >   you: oh, right
>> >
>> > So I'm not sure if that was "Oh, right, it's not a good idea to remove
>> > the conflicting ref" or "Oh, right, but it's probably still fine."
>> 
>> It is "Oh right, it is Ok.  Let's cook it in 'next', have it in 'master'
>> and then backmerge to 'maint'".
>
> Sorry if I'm being slow, but what is "it" here? The "warning" patch I
> sent, or a to-be-posted patch that deletes the conflicting ref?

Sorry, my fingers outpaced my brain and gave you gibberish.

	Oh right, we should hint about "remote prune" and stop there, at
	least for now, as it is not nice to just delete the refs and lose
	their reflogs without user's consent.

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.  The topics
meant to be applied to the maintenance series have "maint-" in their
names.

It already is beginning to become clear what 1.6.0 will look like.  What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements.  Bigger changes will be:

 * MinGW will be in.

 * With the default Makefile settings, most of the programs will be
   installed outside your $PATH, except for "git", "gitk", "git-gui" and
   some server side programs that need to be accessible for technical
   reasons.  Invoking a git subcommand as "git-xyzzy" from the command
   line has been deprecated since early 2006 (and officially announced in
   1.5.4 release notes); use of them from your scripts after adding
   output from "git --exec-path" to the $PATH will still be supported in
   1.6.0, but users are again strongly encouraged to adjust their
   scripts to use "git xyzzy" form, as we will stop installing
   "git-xyzzy" hardlinks for built-in commands in later releases.

 * git-merge will be rewritten in C.

 * default pack and idx versions will be updated as scheduled for some
   time ago.

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

* nd/dashless (Tue Jun 24 19:58:11 2008 -0700) 2 commits
 + Keep some git-* programs in $(bindir)
 + Move all dashed-form commands to libexecdir

Scheduled for 1.6.0.  We'll leave server-side programs in $(bindir) so
that ssh clients can ask for "git-program" and find them on the $PATH.
Next major release after 1.6.0 would most likely remove the hardlinks to
built-in commands, but not yet.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 4 commits
 + Revert "Make clients ask for "git program" over ssh and local
   transport"
 + Make clients ask for "git program" over ssh and local transport
 + Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 + git-shell: accept "git foo" form

----------------------------------------------------------------
[Actively Cooking]

* jk/maint-fetch-ref-hier (Fri Jun 27 00:01:41 2008 -0400) 2 commits
 + fetch: give a hint to the user when local refs fail to update
 + fetch: report local storage errors in status table

When the remote used to have "foo" branch but now has "foo/bar", fetch
refuses to delete the existing remote tracking branch "foo" to create a
new remote tracking branch "foo/bar", but the error message was
confusing.

* jc/maint-reset (Wed Jun 25 18:16:36 2008 -0700) 1 commit
 + Allow "git-reset path" when unambiguous

We used to require "git-reset -- path" even when there is no ambiguity
(i.e. path cannot be mistaken as a valid tree-ish and it is a filename in
the work tree).

* js/maint-clone-insteadof (Fri Jun 27 13:55:23 2008 +0100) 2 commits
 + clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
 + clone: respect url.insteadOf setting in global configs

"git clone" did not honor "url.InsteadOf" in $HOME/.gitconfig.  I think
Daniel's "Let's get rid of internal use of GIT_CONFIG" makes sense (even
though it feels very scary), and it would make the solution much simpler,
but it came late and it is already past my bedtime, so...

* tr/send-email-ssl (Thu Jun 26 23:03:21 2008 +0200) 2 commits
 + git-send-email: prevent undefined variable warnings if no
   encryption is set
 + git-send-email: add support for TLS via Net::SMTP::SSL

* kb/send-email-fifo (Wed Jun 25 15:44:40 2008 -0700) 1 commit
 + git-send-email: Accept fifos as well as files

Two minor send-email feature enhancements for 1.6.0.

* jc/checkdiff (Sun Jun 29 16:49:06 2008 -0400) 7 commits
 + Fix t4017-diff-retval for white-space from wc
 + Update sample pre-commit hook to use "diff --check"
 + diff --check: detect leftover conflict markers
 + Teach "diff --check" about new blank lines at end
 + checkdiff: pass diff_options to the callback
 + check_and_emit_line(): rename and refactor
 + diff --check: explain why we do not care whether old side is
   binary

Allows us to replace the sample pre-commit hook that was not aware of the
line termination convention per path nor newer whitespace breakage rules.

* np/pack-default (Wed Jun 25 00:25:53 2008 -0400) 2 commits
 + pack.indexversion config option now defaults to 2
 + repack.usedeltabaseoffset config option now defaults to "true"

Updates the default value for pack.indexversion to 2 and use delta-base
offset encoding of the packfiles by default.

* js/apply-recount (Fri Jun 27 18:43:09 2008 +0100) 1 commit
 + Allow git-apply to recount the lines in a hunk (AKA recountdiff)

A good ingredient for implementing "apply --edit".

* dz/apply-again (Fri Jun 27 14:39:12 2008 -0400) 1 commit
 + git-apply: handle a patch that touches the same path more than
   once better

Allows us to feed a patch that touches the same path more than once.

* jc/reflog-expire (Sat Jun 28 22:24:49 2008 -0700) 2 commits
 - Make default expiration period of reflog used for stash infinite
 - Per-ref reflog expiry configuration

As 1.6.0 will be a good time to make backward incompatible changes, the
tip commit makes the default expiry period of stash 'never', unless you
configure them to expire explicitly using gc.refs/stash.* variables.
Needs consensus, but I am guessing that enough people would want stash
that does not expire.

* jc/merge-theirs (Sat Jun 28 17:28:22 2008 -0700) 3 commits
 + Teach git-merge to pass -X<option> to the backend strategy module
 + git-merge-recursive-{ours,theirs}
 + git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends is updated so that you can
say "git merge -Xours -s recursive other" now.

* j6t/mingw (Sat Nov 17 20:48:14 2007 +0100) 38 commits
 + compat/pread.c: Add a forward declaration to fix a warning
 + Windows: Fix ntohl() related warnings about printf formatting
 + Windows: TMP and TEMP environment variables specify a temporary
   directory.
 + Windows: Make 'git help -a' work.
 + Windows: Work around an oddity when a pipe with no reader is
   written to.
 + Windows: Make the pager work.
 + When installing, be prepared that template_dir may be relative.
 + Windows: Use a relative default template_dir and ETC_GITCONFIG
 + Windows: Compute the fallback for exec_path from the program
   invocation.
 + Turn builtin_exec_path into a function.
 + Windows: Use a customized struct stat that also has the st_blocks
   member.
 + Windows: Add a custom implementation for utime().
 + Windows: Add a new lstat and fstat implementation based on Win32
   API.
 + Windows: Implement a custom spawnve().
 + Windows: Implement wrappers for gethostbyname(), socket(), and
   connect().
 + Windows: Work around incompatible sort and find.
 + Windows: Implement asynchronous functions as threads.
 + Windows: Disambiguate DOS style paths from SSH URLs.
 + Windows: A rudimentary poll() emulation.
 + Windows: Implement start_command().
 + Windows: A pipe() replacement whose ends are not inherited to
   children.
 + Windows: Wrap execve so that shell scripts can be invoked.
 + Windows: Implement setitimer() and sigaction().
 + Windows: Fix PRIuMAX definition.
 + Windows: Implement gettimeofday().
 + Make my_mktime() public and rename it to tm_to_time_t()
 + Windows: Work around misbehaved rename().
 + Windows: always chmod(, 0666) before unlink().
 + Windows: A minimal implemention of getpwuid().
 + Windows: Implement a wrapper of the open() function.
 + Windows: Strip ".exe" from the program name.
 + Windows: Handle absolute paths in
   safe_create_leading_directories().
 + Windows: Treat Windows style path names.
 + setup.c: Prepare for Windows directory separators.
 + Windows: Use the Windows style PATH separator ';'.
 + Add target architecture MinGW.
 + Compile some programs only conditionally.
 + Add compat/regex.[ch] and compat/fnmatch.[ch].

No explanation necessary ;-)

* mv/merge-in-c (Mon Jun 30 03:39:58 2008 +0200) 13 commits
 - Build in merge
 - Add new test case to ensure git-merge prepends the custom merge
   message
 - Add new test case to ensure git-merge reduces octopus parents when
   possible
 - Introduce reduce_heads()
 - Introduce get_merge_bases_many()
 - Add new test to ensure git-merge handles more than 25 refs.
 - Introduce get_octopus_merge_bases() in commit.c
 - git-fmt-merge-msg: make it usable from other builtins
 - Move read_cache_unmerged() to read-cache.c
 - Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 - Move parse-options's skip_prefix() to git-compat-util.h
 - Move commit_list_count() to commit.c
 - Move split_cmdline() to alias.c

The last one is still in flux.

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 + Eliminate an unnecessary chdir("..")
 + Add support for GIT_CEILING_DIRECTORIES
 + Fold test-absolute-path into test-path-utils
 + Implement normalize_absolute_path

* jc/rerere (Sun Jun 22 02:04:31 2008 -0700) 5 commits
 + rerere.autoupdate
 + t4200: fix rerere test
 + rerere: remove dubious "tail_optimization"
 + git-rerere: detect unparsable conflicts
 + rerere: rerere_created_at() and has_resolution() abstraction

A new configuration will allow paths that have been resolved cleanly by
rerere to be updated in the index automatically.

* ph/parseopt-step-blame (Tue Jun 24 11:12:12 2008 +0200) 7 commits
 - Migrate git-blame to parse-option partially.
 - parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
 - parse-opt: fake short strings for callers to believe in.
 - parse-opt: do not pring errors on unknown options, return -2
   intead.
 - parse-opt: create parse_options_step.
 - parse-opt: Export a non NORETURN usage dumper.
 - parse-opt: have parse_options_{start,end}.

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

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

* ph/mergetool (Mon Jun 16 17:33:41 2008 -0600) 1 commit
 + Remove the use of '--' in merge program invocation

Waiting for success reports from people who use various backends.

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

----------------------------------------------------------------
[Stalled/Needs more work]

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.

----------------------------------------------------------------
[Dropped for now]

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 . Introduce fast forward option only
 . Head reduction before selecting merge strategy
 . Restructure git-merge.sh
 . Introduce -ff=<fast forward option>
 . New merge tests
 . Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C.

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 . Use perl instead of tac
 . Fix t3404 assumption that `wc -l` does not use whitespace.
 . rebase -i: Use : in expr command instead of match.
 . rebase -i: update the implementation of 'mark' command
 . Add option --preserve-tags
 . Teach rebase interactive the tag command
 . Add option --first-parent
 . Do rebase with preserve merges with advanced TODO list
 . Select all lines with fake-editor
 . Unify the length of $SHORT* and the commits in the TODO list
 . Teach rebase interactive the merge command
 . Move redo merge code in a function
 . Teach rebase interactive the reset command
 . Teach rebase interactive the mark command
 . Move cleanup code into it's own function
 . Don't append default merge message to -m message
 . fake-editor: output TODO list if unchanged

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 . WIP: rethink replay merge
 . Start using replay-tree merge in cherry-pick
 . revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time 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

Just my toy at this moment.

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

How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics))

[Steffen Prohaska]

On Jun 30, 2008, at 11:08 AM, Junio C Hamano wrote:

> * MinGW will be in.


If this is done, we should be able to create the msysgit release  
directly
from Junio's master.  Hannes changes alone, however, are not sufficient,
because some commits have been parked in 4msysgit.  Now that MinGW is
on Junio's next and Junio's next is also on 4msysgit's next, it it easy
to see how much is left to do by running:

    git diff --stat junio/next..4msysgit/next

junio is a remote pointing to git://git.kernel.org/pub/scm/git/git.git.
4msysgit is a remote pointing to git://repo.or.cz/git/mingw/ 
4msysgit.git.
I attached the output below.

How should we proceed to get rid of the differences?

Should we prepare and send patches directly to the official git list  
now?
Should we wait until the first MinGW branch is on master?
Should we prepare a whole patch series?  Maybe Hannes would maintain  
this
patch series.

I have not yet looked at the remaining differences in detail.  I expect
most of them to be trivial.  But some might require discussion on the
list, so at some point we should send the patches to the official list.

	Steffen


$ git diff --stat junio/next..4msysgit/next
  Makefile                               |   23 ++-
  README.MinGW                           |   77 ++++++++
  RelNotes                               |    1 -
  builtin-fetch-pack.c                   |    3 +-
  builtin-tag.c                          |   14 ++
  builtin-verify-tag.c                   |    2 +
  cache.h                                |    2 +
  check-builtins.sh                      |    2 +-
  compat/mingw.c                         |    4 +-
  compat/winansi.c                       |  309 +++++++++++++++++++++++ 
+++++++++
  connect.c                              |    5 +-
  convert.c                              |    4 +
  fast-import.c                          |    2 +
  git-add--interactive.perl              |    2 +-
  git-compat-util.h                      |    7 +
  git-parse-remote.sh                    |    3 +-
  gitk-git/Makefile                      |    4 +
  gitk-git/gitk                          |    2 +
  help.c                                 |   30 +++-
  path.c                                 |   13 ++
  read-cache.c                           |    5 +
  setup.c                                |    7 +-
  t/t0000-basic.sh                       |   31 +++-
  t/t0001-init.sh                        |    2 +-
  t/t0004-unwritable.sh                  |    7 +
  t/t1002-read-tree-m-u-2way.sh          |    6 +
  t/t1003-read-tree-prefix.sh            |    4 +
  t/t1004-read-tree-m-u-wf.sh            |    2 +
  t/t1300-repo-config.sh                 |    1 +
  t/t1301-shared-repo.sh                 |    4 +
  t/t2001-checkout-cache-clash.sh        |    2 +
  t/t2003-checkout-cache-mkdir.sh        |    4 +
  t/t2004-checkout-cache-temp.sh         |    2 +
  t/t2007-checkout-symlink.sh            |    7 +
  t/t2100-update-cache-badpath.sh        |    2 +
  t/t2201-add-update-typechange.sh       |   11 +-
  t/t3000-ls-files-others.sh             |    1 +
  t/t3010-ls-files-killed-modified.sh    |    7 +
  t/t3100-ls-tree-restrict.sh            |   12 ++
  t/t3200-branch.sh                      |    2 +
  t/t3700-add.sh                         |   10 +
  t/t3901-i18n-patch.sh                  |    4 +
  t/t3903-stash.sh                       |   12 +-
  t/t4004-diff-rename-symlink.sh         |    7 +
  t/t4008-diff-break-rewrite.sh          |    4 +
  t/t4011-diff-symlink.sh                |    7 +
  t/t4023-diff-rename-typechange.sh      |    5 +
  t/t4109-apply-multifrag.sh             |    4 +
  t/t4110-apply-scan.sh                  |    4 +
  t/t4114-apply-typechange.sh            |    5 +
  t/t4115-apply-symlink.sh               |    7 +
  t/t4116-apply-reverse.sh               |    3 +-
  t/t4122-apply-symlink-inside.sh        |    7 +
  t/t4150-am.sh                          |    6 +-
  t/t5000-tar-tree.sh                    |    7 +
  t/t5300-pack-object.sh                 |   62 +++----
  t/t5502-quickfetch.sh                  |    3 +
  t/t5503-tagfollow.sh                   |   25 +++-
  t/t5505-remote.sh                      |    3 +
  t/t5511-refspec.sh                     |   11 +-
  t/t5512-ls-remote.sh                   |    3 +
  t/t5520-pull.sh                        |    1 +
  t/t5530-upload-pack-error.sh           |    1 +
  t/t7004-tag.sh                         |    5 +-
  t/t7005-editor.sh                      |    1 +
  t/t7201-co.sh                          |    6 +-
  t/t7401-submodule-summary.sh           |   30 ++--
  t/t7501-commit.sh                      |    1 +
  t/t7502-status.sh                      |    4 +
  t/t7503-pre-commit-hook.sh             |    6 +
  t/t7504-commit-msg-hook.sh             |    6 +
  t/t9001-send-email.sh                  |    4 +
  t/t9200-git-cvsexportcommit.sh         |    4 +
  t/t9500-gitweb-standalone-no-errors.sh |    3 +
  t/test-lib.sh                          |   17 ++
  templates/Makefile                     |    3 +
  utf8.c                                 |    7 +
  utf8.h                                 |    4 -
  78 files changed, 844 insertions(+), 86 deletions(-)

Re: [msysGit] How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics))

[Johannes Sixt]

On Montag, 30. Juni 2008, Steffen Prohaska wrote:
> On Jun 30, 2008, at 11:08 AM, Junio C Hamano wrote:
> > * MinGW will be in.
>
> If this is done, we should be able to create the msysgit release
> directly
> from Junio's master.  Hannes changes alone, however, are not sufficient,
> because some commits have been parked in 4msysgit.  Now that MinGW is
> on Junio's next and Junio's next is also on 4msysgit's next, it it easy
> to see how much is left to do by running:
>
>     git diff --stat junio/next..4msysgit/next
>
> junio is a remote pointing to git://git.kernel.org/pub/scm/git/git.git.
> 4msysgit is a remote pointing to git://repo.or.cz/git/mingw/
> 4msysgit.git.
> I attached the output below.
>
> How should we proceed to get rid of the differences?
>
> Should we prepare and send patches directly to the official git list
> now?
> Should we wait until the first MinGW branch is on master?
> Should we prepare a whole patch series?  Maybe Hannes would maintain
> this
> patch series.

Until 1.6.0 is released, a number of _required_ patches will have to be 
included. There are two sorts of them:

* Patches that touch generic code, like replacing c == '/' by is_dir_sep(c).

* Patches that are purly Windows specific.

The former I intend to submit to the mailing list directly and as soon as 
possible (but if I can intervene on newly submitted patches early so that a 
fixup is not even necessary, then even better). The latter I intend to 
collect in a branch and submit as a batch. Let's see how this works out.

Then there are the extra patches in 4msysgit. From my POV, they are not 
_required_ because I can appearently work with git on Windows without them. I 
think some of them are not necessary. Can we go through them again?

And then there are the patches to the t/ directory. I do not target them for 
1.6.0, but I do want to prepare another series with them.

-- Hannes

Re: How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics))

[Clifford Caoile]

Hi:

On Tue, Jul 1, 2008 at 3:47 AM, Johannes Sixt <johannes.sixt@telecom.at> wrote:
>
> On Montag, 30. Juni 2008, Steffen Prohaska wrote:
>> On Jun 30, 2008, at 11:08 AM, Junio C Hamano wrote:
>> > * MinGW will be in.
>>
>> How should we proceed to get rid of the differences?
> ...
> Then there are the extra patches in 4msysgit. From my POV, they are not
> _required_ because I can appearently work with git on Windows without them. I
> think some of them are not necessary. Can we go through them again?

As one of the extra patches in 4msysgit, there is the cca/git.el
branch [1] which I contributed [2] previously for Emacs git.el users
on Windows. However I have not gotten any feedback whatsoever, so
perhaps parking it in 4msysgit is not appropriate. I plan to
separately to host these patch(es). Please ignore it or remove it at
your convenience.

References:
[1] http://repo.or.cz/w/git/mingw/4msysgit.git?a=shortlog;h=refs/heads/cca/git.el
[2] http://thread.gmane.org/gmane.comp.version-control.msysgit/2140

Best regards,
Clifford Caoile

Re: How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics))

[Steffen Prohaska]

On Jun 30, 2008, at 8:47 PM, Johannes Sixt wrote:

> Then there are the extra patches in 4msysgit. From my POV, they are  
> not
> _required_ because I can appearently work with git on Windows  
> without them. I
> think some of them are not necessary. Can we go through them again?


I'll send a patch series in reply to this mail that contains the
following patches:

  [PATCH 01/12] Fake reencoding success under NO_ICONV instead of  
returning NULL.
  [PATCH 02/12] Do not complain about "no common commits" in an empty  
repo
  [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures
  [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds.
  [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in  
default browser
  [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)
  [PATCH 07/12] Fixed text file auto-detection: treat EOF character  
032 at the end of file as printable
  [PATCH 08/12] fast-import: MinGW does not have getppid().  So do not  
print it.
  [PATCH 09/12] We need to check for msys as well as Windows in add-- 
interactive.
  [PATCH 10/12] Add ANSI control code emulation for the Windows console
  [PATCH 11/12] verify_path(): do not allow absolute paths
  [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next

This series would bring *.{c,h,sh,perl} on Junio's next to 4msysgit/ 
next,
except for some minor differences (whitespace, comments, a workaround in
git-parse-remote.sh).

	Steffen

[PATCH 01/12] Fake reencoding success under NO_ICONV instead of returning NULL.

[Steffen Prohaska]

From: Johannes Sixt <johannes.sixt@telecom.at>

git-am when invoked from git-rebase seems to rely on successful conversion.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 utf8.c |    7 +++++++
 utf8.h |    4 ----
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/utf8.c b/utf8.c
index dc37353..b07d43e 100644
--- a/utf8.c
+++ b/utf8.c
@@ -388,4 +388,11 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e
 	iconv_close(conv);
 	return out;
 }
+#else
+char *reencode_string(const char *in, const char *out_encoding, const char *in_encoding)
+{
+	if (!in_encoding)
+		return NULL;
+	return xstrdup(in);
+}
 #endif
diff --git a/utf8.h b/utf8.h
index 98cce1b..f22ef31 100644
--- a/utf8.h
+++ b/utf8.h
@@ -10,10 +10,6 @@ int is_encoding_utf8(const char *name);
 
 int print_wrapped_text(const char *text, int indent, int indent2, int len);
 
-#ifndef NO_ICONV
 char *reencode_string(const char *in, const char *out_encoding, const char *in_encoding);
-#else
-#define reencode_string(a,b,c) NULL
-#endif
 
 #endif
-- 
1.5.6.1.255.g32571

[PATCH 02/12] Do not complain about "no common commits" in an empty repo

[Steffen Prohaska]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

If the repo is empty, we know that already, thank you very much.
So shut fetch-pack up about that case.

Fixes issue 3, too.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 builtin-fetch-pack.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index f4dbcf0..2175c6d 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -309,7 +309,8 @@ done:
 		}
 		flushes--;
 	}
-	return retval;
+	/* it is no error to fetch into a completely empty repo */
+	return count ? retval : 0;
 }
 
 static struct commit_list *complete;
-- 
1.5.6.1.255.g32571

[PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures

[Steffen Prohaska]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

On Windows, gpg outputs CR/LF signatures.  But since the tag
messages are already stripped of the CR by stripspace(), it is
arguably nicer to do the same for the tag signature.  Actually,
this patch does not look for CR/LF, but strips all CRs
from the signature.

[ spr: ported code to use strbuf ]

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 builtin-tag.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/builtin-tag.c b/builtin-tag.c
index e675206..77977ba 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -241,6 +241,20 @@ static int do_sign(struct strbuf *buffer)
 	if (finish_command(&gpg) || !len || len < 0)
 		return error("gpg failed to sign the tag");
 
+#ifdef __MINGW32__
+	/* strip CR from the line endings */
+	{
+		int i, j;
+		for (i = j = 0; i < buffer->len; i++)
+			if (buffer->buf[i] != '\r') {
+				if (i != j)
+					buffer->buf[j] = buffer->buf[i];
+				j++;
+			}
+		strbuf_setlen(buffer, j);
+	}
+#endif
+
 	return 0;
 }
 
-- 
1.5.6.1.255.g32571

[PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds.

[Steffen Prohaska]

From: Marius Storm-Olsen <mstormo_git@storm-olsen.com>

SIGPIPE isn't supported in MinGW.

Signed-off-by: Marius Storm-Olsen <mstormo_git@storm-olsen.com>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 builtin-verify-tag.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/builtin-verify-tag.c b/builtin-verify-tag.c
index 92eaa89..540e3b9 100644
--- a/builtin-verify-tag.c
+++ b/builtin-verify-tag.c
@@ -100,9 +100,11 @@ int cmd_verify_tag(int argc, const char **argv, const char *prefix)
 		i++;
 	}
 
+#ifndef __MINGW32__
 	/* sometimes the program was terminated because this signal
 	 * was received in the process of writing the gpg input: */
 	signal(SIGPIPE, SIG_IGN);
+#endif	
 	while (i < argc)
 		if (verify_tag(argv[i++], verbose))
 			had_error = 1;
-- 
1.5.6.1.255.g32571

[PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser

[Steffen Prohaska]

The implementation directly calls the Win32 API to launch the browser.
Note that the specific directory layout of msysgit is required.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 cache.h |    2 ++
 help.c  |   28 ++++++++++++++++++++++++++++
 path.c  |   13 +++++++++++++
 3 files changed, 43 insertions(+), 0 deletions(-)

diff --git a/cache.h b/cache.h
index 0d8edda..958d257 100644
--- a/cache.h
+++ b/cache.h
@@ -529,6 +529,8 @@ const char *make_nonrelative_path(const char *path);
 const char *make_relative_path(const char *abs, const char *base);
 int normalize_absolute_path(char *buf, const char *path);
 int longest_ancestor_length(const char *path, const char *prefix_list);
+/* Convert slashes to backslashes on Windows. */
+char *make_native_separator(char *path);
 
 /* Read and unpack a sha1 file into memory, write memory to a sha1 file */
 extern int sha1_object_info(const unsigned char *, unsigned long *);
diff --git a/help.c b/help.c
index ca9632b..811f8db 100644
--- a/help.c
+++ b/help.c
@@ -9,6 +9,7 @@
 #include "common-cmds.h"
 #include "parse-options.h"
 #include "run-command.h"
+#include "dir.h"
 
 static struct man_viewer_list {
 	struct man_viewer_list *next;
@@ -28,7 +29,11 @@ enum help_format {
 };
 
 static int show_all = 0;
+#ifdef __MINGW32__
+static enum help_format help_format = HELP_FORMAT_WEB;
+#else
 static enum help_format help_format = HELP_FORMAT_MAN;
+#endif
 static struct option builtin_help_options[] = {
 	OPT_BOOLEAN('a', "all", &show_all, "print all available commands"),
 	OPT_SET_INT('m', "man", &help_format, "show man page", HELP_FORMAT_MAN),
@@ -644,12 +649,35 @@ static void get_html_page_path(struct strbuf *page_path, const char *page)
 
 static void show_html_page(const char *git_cmd)
 {
+#ifdef __MINGW32__
+	const char* exec_path = git_exec_path();
+	char *htmlpath = make_native_separator(
+			   mkpath("%s/../doc/git/html/%s.html"
+				  , exec_path
+				  , git_cmd)
+			 );
+	if (!file_exists(htmlpath)) {
+		htmlpath = make_native_separator(
+			      mkpath("%s/../doc/git/html/git-%s.html"
+				     , exec_path
+				     , git_cmd)
+			   );
+		if (!file_exists(htmlpath)) {
+			fprintf(stderr, "Can't find HTML help for '%s'.\n"
+				, git_cmd);
+			exit(1);
+		}
+	}
+	printf("Launching default browser to display HTML help ...\n");
+	ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
+#else
 	const char *page = cmd_to_page(git_cmd);
 	struct strbuf page_path; /* it leaks but we exec bellow */
 
 	get_html_page_path(&page_path, page);
 
 	execl_git_cmd("web--browse", "-c", "help.browser", page_path.buf, NULL);
+#endif
 }
 
 void help_unknown_cmd(const char *cmd)
diff --git a/path.c b/path.c
index 5983255..2a4a76a 100644
--- a/path.c
+++ b/path.c
@@ -439,3 +439,16 @@ int longest_ancestor_length(const char *path, const char *prefix_list)
 
 	return max_len;
 }
+
+char *make_native_separator(char* path) {
+#ifdef __MINGW32__
+	char* c;
+	for (c = path; *c; c++) {
+		if (*c == '/')
+			*c = '\\';
+	}
+	return path;
+#else
+	return path;
+#endif
+}
-- 
1.5.6.1.255.g32571

[PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

[Steffen Prohaska]

From: Edward Z. Yang <edwardzyang@thewritingpot.com>

PuTTY requires -P while OpenSSH requires -p; if plink is detected
as GIT_SSH, use the alternate flag.

Signed-off-by: Edward Z. Yang <edwardzyang@thewritingpot.com>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 connect.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/connect.c b/connect.c
index 574f42f..0d007f3 100644
--- a/connect.c
+++ b/connect.c
@@ -599,11 +599,13 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
 	conn->argv = arg = xcalloc(6, sizeof(*arg));
 	if (protocol == PROTO_SSH) {
 		const char *ssh = getenv("GIT_SSH");
+		int putty = ssh && strstr(ssh, "plink");
 		if (!ssh) ssh = "ssh";
 
 		*arg++ = ssh;
 		if (port) {
-			*arg++ = "-p";
+			/* P is for PuTTY, p is for OpenSSH */
+			*arg++ = putty ? "-P" : "-p";
 			*arg++ = port;
 		}
 		*arg++ = host;
-- 
1.5.6.1.255.g32571

[PATCH 07/12] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable

[Steffen Prohaska]

From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>

Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 convert.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/convert.c b/convert.c
index 1c66844..f24ac25 100644
--- a/convert.c
+++ b/convert.c
@@ -61,6 +61,10 @@ static void gather_stats(const char *buf, unsigned long size, struct text_stat *
 		else
 			stats->printable++;
 	}
+
+	// If file ends with EOF then don't count this EOF as non-printable
+	if ( size >= 1 && buf[size-1] == '\032' )
+		stats->nonprintable--;
 }
 
 /*
-- 
1.5.6.1.255.g32571

[PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it.

[Steffen Prohaska]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 fast-import.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/fast-import.c b/fast-import.c
index e72b286..271b93c 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -391,7 +391,9 @@ static void write_crash_report(const char *err)
 
 	fprintf(rpt, "fast-import crash report:\n");
 	fprintf(rpt, "    fast-import process: %d\n", getpid());
+#ifndef __MINGW32__
 	fprintf(rpt, "    parent process     : %d\n", getppid());
+#endif
 	fprintf(rpt, "    at %s\n", show_date(time(NULL), 0, DATE_LOCAL));
 	fputc('\n', rpt);
 
-- 
1.5.6.1.255.g32571

[PATCH 09/12] We need to check for msys as well as Windows in add--interactive.

[Steffen Prohaska]

From: Mike Pape <dotzenlabs@gmail.com>

Signed-off-by: Mike Pape <dotzenlabs@gmail.com>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 git-add--interactive.perl |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 903953e..78a64e6 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -42,7 +42,7 @@ sub colored {
 my $patch_mode;
 
 sub run_cmd_pipe {
-	if ($^O eq 'MSWin32') {
+	if ($^O eq 'MSWin32' || $^O eq 'msys') {
 		my @invalid = grep {m/[":*]/} @_;
 		die "$^O does not support: @invalid\n" if @invalid;
 		my @args = map { m/ /o ? "\"$_\"": $_ } @_;
-- 
1.5.6.1.255.g32571

[PATCH 10/12] Add ANSI control code emulation for the Windows console

[Steffen Prohaska]

From: Peter <git@peter.is-a-geek.org>

This adds only the minimum necessary to keep git pull/merge's diffstat from
wrapping. Notably absent is support for the K (erase) operation, and support
for POSIX write.

Cygwin does not need the WIN_ANSI define, since it has its own (more complete)
ANSI emulation.

Signed-off-by: Peter Harris <git@peter.is-a-geek.org>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 Makefile          |    6 +
 compat/winansi.c  |  309 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 git-compat-util.h |    7 ++
 3 files changed, 322 insertions(+), 0 deletions(-)
 create mode 100644 compat/winansi.c

diff --git a/Makefile b/Makefile
index 5914e1a..a7f2dcb 100644
--- a/Makefile
+++ b/Makefile
@@ -737,6 +737,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
 	NO_SVN_TESTS = YesPlease
 	NO_PERL_MAKEMAKER = YesPlease
 	NO_POSIX_ONLY_PROGRAMS = YesPlease
+	WIN_ANSI = YesPlease
 	COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -DNOGDI -Icompat
 	COMPAT_CFLAGS += -DSNPRINTF_SIZE_CORR=1
 	COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
@@ -981,6 +982,11 @@ ifdef NO_EXTERNAL_GREP
 	BASIC_CFLAGS += -DNO_EXTERNAL_GREP
 endif
 
+ifdef WIN_ANSI
+	COMPAT_CFLAGS += -DWIN_ANSI
+	COMPAT_OBJS += compat/winansi.o
+endif
+
 ifeq ($(TCLTK_PATH),)
 NO_TCLTK=NoThanks
 endif
diff --git a/compat/winansi.c b/compat/winansi.c
new file mode 100644
index 0000000..86c3fd2
--- /dev/null
+++ b/compat/winansi.c
@@ -0,0 +1,309 @@
+#include <windows.h>
+#include "../git-compat-util.h"
+
+/*
+ Functions to be wrapped:
+*/
+#undef printf
+#undef fputs
+
+/*
+ ANSI codes to implement: m, K
+*/
+
+static HANDLE console;
+static WORD plain_attr;
+static WORD attr;
+static int negative;
+
+static void init(void)
+{
+    CONSOLE_SCREEN_BUFFER_INFO sbi;
+
+    static int initialized = 0;
+    if (initialized)
+	return;
+
+    console = GetStdHandle(STD_OUTPUT_HANDLE);
+    if (console == INVALID_HANDLE_VALUE)
+	console = NULL;
+
+    if (!console)
+	return;
+
+    GetConsoleScreenBufferInfo(console, &sbi);
+    attr = plain_attr = sbi.wAttributes;
+    negative = 0;
+
+    initialized = 1;
+}
+
+
+#define FOREGROUND_ALL (FOREGROUND_RED | FOREGROUND_GREEN | FOREGROUND_BLUE)
+#define BACKGROUND_ALL (BACKGROUND_RED | BACKGROUND_GREEN | BACKGROUND_BLUE)
+
+static void set_console_attr(void)
+{
+    WORD attributes = attr;
+    if (negative) {
+	attributes &= ~FOREGROUND_ALL;
+	attributes &= ~BACKGROUND_ALL;
+
+	/* This could probably use a bitmask instead of a series of ifs */
+	if (attr & FOREGROUND_RED)
+	    attributes |= BACKGROUND_RED;
+	if (attr & FOREGROUND_GREEN)
+	    attributes |= BACKGROUND_GREEN;
+	if (attr & FOREGROUND_BLUE)
+	    attributes |= BACKGROUND_BLUE;
+
+	if (attr & BACKGROUND_RED)
+	    attributes |= FOREGROUND_RED;
+	if (attr & BACKGROUND_GREEN)
+	    attributes |= FOREGROUND_GREEN;
+	if (attr & BACKGROUND_BLUE)
+	    attributes |= FOREGROUND_BLUE;
+    }
+    SetConsoleTextAttribute(console, attributes);
+}
+
+static const char *set_attr(const char *str)
+{
+    const char *func;
+    size_t len = strspn(str, "0123456789;");
+    func = str + len;
+
+    switch (*func) {
+    case 'm':
+	do {
+	    long val = strtol(str, (char **)&str, 10);
+	    switch (val) {
+	    case 0: /* reset */
+		attr = plain_attr;
+		negative = 0;
+		break;
+	    case 1: /* bold */
+		attr |= FOREGROUND_INTENSITY;
+		break;
+	    case 2:  /* faint */
+	    case 22: /* normal */
+		attr &= ~FOREGROUND_INTENSITY;
+		break;
+	    case 3:  /* italic */
+		/* Unsupported */
+		break;
+	    case 4:  /* underline */
+	    case 21: /* double underline */
+		/* Wikipedia says this flag does nothing */
+		/* Furthermore, mingw doesn't define this flag
+		attr |= COMMON_LVB_UNDERSCORE; */
+		break;
+	    case 24: /* no underline */
+		/* attr &= ~COMMON_LVB_UNDERSCORE; */
+		break;
+	    case 5:  /* slow blink */
+	    case 6:  /* fast blink */
+		/* We don't have blink, but we do have background intensity */
+		attr |= BACKGROUND_INTENSITY;
+		break;
+	    case 25: /* no blink */
+		attr &= ~BACKGROUND_INTENSITY;
+		break;
+	    case 7:  /* negative */
+		negative = 1;
+		break;
+	    case 27: /* positive */
+		negative = 0;
+		break;
+	    case 8:  /* conceal */
+	    case 28: /* reveal */
+		/* Unsupported */
+		break;
+	    case 30: /* Black */
+		attr &= ~FOREGROUND_ALL;
+		break;
+	    case 31: /* Red */
+		attr &= ~FOREGROUND_ALL;
+		attr |= FOREGROUND_RED;
+		break;
+	    case 32: /* Green */
+		attr &= ~FOREGROUND_ALL;
+		attr |= FOREGROUND_GREEN;
+		break;
+	    case 33: /* Yellow */
+		attr &= ~FOREGROUND_ALL;
+		attr |= FOREGROUND_RED | FOREGROUND_GREEN;
+		break;
+	    case 34: /* Blue */
+		attr &= ~FOREGROUND_ALL;
+		attr |= FOREGROUND_BLUE;
+		break;
+	    case 35: /* Magenta */
+		attr &= ~FOREGROUND_ALL;
+		attr |= FOREGROUND_RED | FOREGROUND_BLUE;
+		break;
+	    case 36: /* Cyan */
+		attr &= ~FOREGROUND_ALL;
+		attr |= FOREGROUND_GREEN | FOREGROUND_BLUE;
+		break;
+	    case 37: /* White */
+		attr |= FOREGROUND_RED | FOREGROUND_GREEN | FOREGROUND_BLUE;
+		break;
+	    case 38: /* Unknown */
+		break;
+	    case 39: /* reset */
+		attr &= ~FOREGROUND_ALL;
+		attr |= (plain_attr & FOREGROUND_ALL);
+		break;
+	    case 40: /* Black */
+		attr &= ~BACKGROUND_ALL;
+		break;
+	    case 41: /* Red */
+		attr &= ~BACKGROUND_ALL;
+		attr |= BACKGROUND_RED;
+		break;
+	    case 42: /* Green */
+		attr &= ~BACKGROUND_ALL;
+		attr |= BACKGROUND_GREEN;
+		break;
+	    case 43: /* Yellow */
+		attr &= ~BACKGROUND_ALL;
+		attr |= BACKGROUND_RED | BACKGROUND_GREEN;
+		break;
+	    case 44: /* Blue */
+		attr &= ~BACKGROUND_ALL;
+		attr |= BACKGROUND_BLUE;
+		break;
+	    case 45: /* Magenta */
+		attr &= ~BACKGROUND_ALL;
+		attr |= BACKGROUND_RED | BACKGROUND_BLUE;
+		break;
+	    case 46: /* Cyan */
+		attr &= ~BACKGROUND_ALL;
+		attr |= BACKGROUND_GREEN | BACKGROUND_BLUE;
+		break;
+	    case 47: /* White */
+		attr |= BACKGROUND_RED | BACKGROUND_GREEN | BACKGROUND_BLUE;
+		break;
+	    case 48: /* Unknown */
+		break;
+	    case 49: /* reset */
+		attr &= ~BACKGROUND_ALL;
+		attr |= (plain_attr & BACKGROUND_ALL);
+		break;
+	    default:
+		/* Unsupported code */
+		break;
+	    }
+	    str++;
+	} while (*(str-1) == ';');
+
+	set_console_attr();
+	break;
+    case 'K':
+	/* TODO */
+	break;
+    default:
+	/* Unsupported code */
+	break;
+    }
+
+    return func + 1;
+}
+
+static int ansi_emulate(const char *str, FILE *stream)
+{
+    int rv = 0;
+    const char *pos = str;
+
+    while (*pos) {
+	pos = strstr(str, "\033[");
+	if (pos) {
+	    size_t len = pos - str;
+
+	    if (len) {
+		size_t output_len = fwrite(str, 1, len, stream);
+		rv += output_len;
+		if (output_len < len)
+		    return rv;
+	    }
+
+	    str = pos + 2;
+	    rv += 2;
+
+	    fflush(stream);
+
+	    pos = set_attr(str);
+	    rv += pos - str;
+	    str = pos;
+	} else {
+	    rv += strlen(str);
+	    fputs(str, stream);
+	    return rv;
+	}
+    }
+    return rv;
+}
+
+int git_fputs(const char *str, FILE *stream)
+{
+    int rv;
+
+    init();
+
+    if (!console)
+	return fputs(str, stream);
+
+    if (!isatty(fileno(stream)))
+	return fputs(str, stream);
+
+    rv = ansi_emulate(str, stream);
+
+    if (rv >= 0)
+	return 0;
+    else
+	return EOF;
+}
+
+int git_printf(const char *format, ...)
+{
+    va_list list;
+
+    char small_buf[256];
+    char *buf = small_buf;
+    int len, rv;
+
+    init();
+
+    if (!console)
+	goto abort;
+
+    if (!isatty(fileno(stdout)))
+	goto abort;
+
+    va_start(list, format);
+    len = vsnprintf(small_buf, sizeof(small_buf), format, list);
+    va_end(list);
+
+    if (len > sizeof(small_buf) - 1) {
+	buf = malloc(len + 1);
+	if (!buf)
+	    goto abort;
+
+	va_start(list, format);
+	len = vsnprintf(buf, len + 1, format, list);
+	va_end(list);
+    }
+
+    rv = ansi_emulate(buf, stdout);
+
+    if (buf != small_buf)
+	free(buf);
+    return rv;
+
+abort:
+    va_start(list, format);
+    rv = vprintf(format, list);
+    va_end(list);
+    return rv;
+}
diff --git a/git-compat-util.h b/git-compat-util.h
index 545df59..fc5168e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -357,4 +357,11 @@ void git_qsort(void *base, size_t nmemb, size_t size,
 # define FORCE_DIR_SET_GID 0
 #endif
 
+#ifdef WIN_ANSI
+extern int git_fputs(const char *str, FILE *stream);
+extern int git_printf(const char *format, ...) __attribute__((format (printf, 1, 2)));
+#define fputs git_fputs
+#define printf(...) git_printf(__VA_ARGS__)
+#endif
+
 #endif
-- 
1.5.6.1.255.g32571

[PATCH 11/12] verify_path(): do not allow absolute paths

[Steffen Prohaska]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 read-cache.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/read-cache.c b/read-cache.c
index f83de8c..cb130ef 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -650,6 +650,11 @@ int verify_path(const char *path)
 {
 	char c;
 
+#ifdef __MINGW32__
+	if (is_absolute_path(path))
+		return error("Cannot handle absolute path: %s", path);
+#endif
+
 	goto inside;
 	for (;;) {
 		if (!c)
-- 
1.5.6.1.255.g32571

[PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next

[Steffen Prohaska]

From: Johannes Sixt <johannes.sixt@telecom.at>

Hannes,
You introduced "minoffset" in 861429a7c37c7.  Here is your original
message:

'''
An earlier patch has implemented getcwd() so that it converts the
drive letter into the POSIX-like path that is used internally by
MinGW (C:\foo => /c/foo), but this style does not work outside
the MinGW shell. It is better to just convert the backslashes
to forward slashes and handle the drive letter explicitly.
'''

Dmitry replaced setenv() with set_git_dir in 855f254b2b5b08.
Here is his original message:

'''
git clone was failing with 'invalid object name HEAD' if ran from
cmd.exe directly

environment.c caches results of many getenv calls.
Under MinGW setenv(X) invalidates all previous values returned by
getenv(X)
so cached values become dangling pointers.

Replaced all setenv(GIT_DIR, ...) with set_git_dir

Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
'''
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 setup.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/setup.c b/setup.c
index 6cf9094..1fd30c4 100644
--- a/setup.c
+++ b/setup.c
@@ -381,6 +381,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
 	const char *gitdirenv;
 	const char *gitfile_dir;
 	int len, offset, ceil_offset;
+	int minoffset = 0;
 
 	/*
 	 * Let's assume that we are in a git repository.
@@ -431,6 +432,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
 
 	if (!getcwd(cwd, sizeof(cwd)-1))
 		die("Unable to read current working directory");
+	if (has_dos_drive_prefix(cwd))
+		minoffset = 2;
 
 	ceil_offset = longest_ancestor_length(cwd, env_ceiling_dirs);
 	if (ceil_offset < 0 && has_dos_drive_prefix(cwd))
@@ -461,11 +464,11 @@ const char *setup_git_directory_gently(int *nongit_ok)
 			inside_git_dir = 1;
 			if (!work_tree_env)
 				inside_work_tree = 0;
-			setenv(GIT_DIR_ENVIRONMENT, ".", 1);
+			set_git_dir(".");
 			check_repository_format_gently(nongit_ok);
 			return NULL;
 		}
-		while (--offset > ceil_offset && cwd[offset] != '/');
+		while (offset > minoffset && --offset > ceil_offset && cwd[offset] != '/');
 		if (offset <= ceil_offset) {
 			if (nongit_ok) {
 				if (chdir(cwd))
-- 
1.5.6.1.255.g32571

Re: [msysGit] [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next

[Johannes Schindelin]

Hi,

On Wed, 2 Jul 2008, Steffen Prohaska wrote:

> 
> From: Johannes Sixt <johannes.sixt@telecom.at>
> 
> Hannes,
> You introduced "minoffset" in 861429a7c37c7.

AFAICT it was redone differently in 'next', because 'next' has this 
ceiling dir thingie, which allows a different (much smaller) patch.

It might be more sensible to base your patch series on 'next'...

Ciao,
Dscho

Re: [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next

[Steffen Prohaska]

On Jul 2, 2008, at 6:17 PM, Johannes Schindelin wrote:

> On Wed, 2 Jul 2008, Steffen Prohaska wrote:
>
>>
>> From: Johannes Sixt <johannes.sixt@telecom.at>
>>
>> Hannes,
>> You introduced "minoffset" in 861429a7c37c7.
>
> AFAICT it was redone differently in 'next', because 'next' has this
> ceiling dir thingie, which allows a different (much smaller) patch.
>
> It might be more sensible to base your patch series on 'next'...

Hmm.. it is based on next.  But obviously I needed to merge
mingw's master to 4msysgit's master and resolve conflicts.
Maybe I made the wrong decisions then.

Hannes,
If you believe that your setup.c is good, then I'll copy your version
to 4msysgit's master.

	Steffen

Re: [msysGit] Re: [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next

[Johannes Sixt]

On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> On Jul 2, 2008, at 6:17 PM, Johannes Schindelin wrote:
> > On Wed, 2 Jul 2008, Steffen Prohaska wrote:
> >> From: Johannes Sixt <johannes.sixt@telecom.at>
> >>
> >> Hannes,
> >> You introduced "minoffset" in 861429a7c37c7.
> >
> > AFAICT it was redone differently in 'next', because 'next' has this
> > ceiling dir thingie, which allows a different (much smaller) patch.
> >
> > It might be more sensible to base your patch series on 'next'...
>
> Hmm.. it is based on next.  But obviously I needed to merge
> mingw's master to 4msysgit's master and resolve conflicts.
> Maybe I made the wrong decisions then.
>
> Hannes,
> If you believe that your setup.c is good, then I'll copy your version
> to 4msysgit's master.

The setup.c in mingw.git (and soon Junio's master) and Junio's next are 
_different_, but both are correct. If you reverse-apply the patch you 
presented here, then you get the version from Junio's next, which is a good 
state.

[ Of course, the result will work only as long as you do not set 
GIT_CEILING_DIRECTORIES, because we haven't taken care of the helper 
functions that this feature uses, longest_ancestor_length() and 
normalize_path(). ]

We have debated about set_git_dir(".") in the past. mingw.git doesn't have it, 
and it works (for me). I don't know what it is needed for.

-- Hannes

Re: [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next

[Steffen Prohaska]

On Jul 2, 2008, at 9:32 PM, Johannes Sixt wrote:

> On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
>> On Jul 2, 2008, at 6:17 PM, Johannes Schindelin wrote:
>>> On Wed, 2 Jul 2008, Steffen Prohaska wrote:
>>>> From: Johannes Sixt <johannes.sixt@telecom.at>
>>>>
>>>> Hannes,
>>>> You introduced "minoffset" in 861429a7c37c7.
>>>
>>> AFAICT it was redone differently in 'next', because 'next' has this
>>> ceiling dir thingie, which allows a different (much smaller) patch.
>>>
>>> It might be more sensible to base your patch series on 'next'...
>>
>> Hmm.. it is based on next.  But obviously I needed to merge
>> mingw's master to 4msysgit's master and resolve conflicts.
>> Maybe I made the wrong decisions then.
>>
>> Hannes,
>> If you believe that your setup.c is good, then I'll copy your version
>> to 4msysgit's master.
>
> The setup.c in mingw.git (and soon Junio's master) and Junio's next  
> are
> _different_, but both are correct. If you reverse-apply the patch you
> presented here, then you get the version from Junio's next, which is  
> a good
> state.

Ok, I'll wait until Junio's master has the changes and will remove
the changes to 4msysgit then.

	Steffen

Re: [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> On Jul 2, 2008, at 9:32 PM, Johannes Sixt wrote:
>
>> The setup.c in mingw.git (and soon Junio's master) and Junio's next
>> are
>> _different_, but both are correct. If you reverse-apply the patch you
>> presented here, then you get the version from Junio's next, which is
>> a good
>> state.
>
> Ok, I'll wait until Junio's master has the changes and will remove
> the changes to 4msysgit then.

There will be a slight difference between the setup.c in soon-to-be master
and j6t/mingw (14086b0), due to recent optimization already on 'master'
from Linus, 044bbbc (Make git_dir a path relative to work_tree in
setup_work_tree(), 2008-06-19).

diff --git a/setup.c b/setup.c
index 8bb7b10..cc3fb38 100644
--- a/setup.c
+++ b/setup.c
@@ -308,9 +308,10 @@ void setup_work_tree(void)
 	work_tree = get_git_work_tree();
 	git_dir = get_git_dir();
 	if (!is_absolute_path(git_dir))
-		set_git_dir(make_absolute_path(git_dir));
+		git_dir = make_absolute_path(git_dir);
 	if (!work_tree || chdir(work_tree))
 		die("This operation must be run in a work tree");
+	set_git_dir(make_relative_path(git_dir, work_tree));
 	initialized = 1;
 }
 

Re: [PATCH 11/12] verify_path(): do not allow absolute paths

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>

No commit log message?  Justification?

Re: [PATCH 11/12] verify_path(): do not allow absolute paths

[Steffen Prohaska]

On Jul 2, 2008, at 11:21 AM, Junio C Hamano wrote:

> Steffen Prohaska <prohaska@zib.de> writes:
>
>> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
>
> No commit log message?  Justification?

Hannes,
Do we still need this change in verify_path().  I am not sure.
Maybe it should be reverted in 4msysgit?

	Steffen

Re: [PATCH 11/12] verify_path(): do not allow absolute paths

[Johannes Schindelin]

Hi,

On Wed, 2 Jul 2008, Junio C Hamano wrote:

> Steffen Prohaska <prohaska@zib.de> writes:
> 
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> 
> No commit log message?  Justification?

Justification: adding absolute paths was not caught properly on Windows, 
and this was the easiest patch.

However, IIRC, in the meantime we are nice to the user, and allow absolute 
paths (which we turn into a relative path, or error out if it is not under 
the current working directory).

Steffen, can you revert the patch and verify that my memory does not fail 
me?

Ciao,
Dscho

Re: [PATCH 11/12] verify_path(): do not allow absolute paths

[Steffen Prohaska]

On Jul 2, 2008, at 6:15 PM, Johannes Schindelin wrote:

> Hi,
>
> On Wed, 2 Jul 2008, Junio C Hamano wrote:
>
>> Steffen Prohaska <prohaska@zib.de> writes:
>>
>>> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>>> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
>>
>> No commit log message?  Justification?
>
> Justification: adding absolute paths was not caught properly on  
> Windows,
> and this was the easiest patch.
>
> However, IIRC, in the meantime we are nice to the user, and allow  
> absolute
> paths (which we turn into a relative path, or error out if it is not  
> under
> the current working directory).
>
> Steffen, can you revert the patch and verify that my memory does not  
> fail
> me?

Is

    git add /c/msysgit/git/read-cache.c

an appropriate test?

It fails with

    error: 'c:/msysgit/git/read-cache.c' is outside repository

no matter if the commit is reverted or not.

	Steffen

Re: [PATCH 11/12] verify_path(): do not allow absolute paths

[Johannes Schindelin]

Hi,

On Wed, 2 Jul 2008, Steffen Prohaska wrote:

> On Jul 2, 2008, at 6:15 PM, Johannes Schindelin wrote:
> 
> >On Wed, 2 Jul 2008, Junio C Hamano wrote:
> >
> > >Steffen Prohaska <prohaska@zib.de> writes:
> > >
> > > >Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 
> > > >Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> > >
> > >No commit log message?  Justification?
> >
> >Justification: adding absolute paths was not caught properly on 
> >Windows, and this was the easiest patch.
> >
> >However, IIRC, in the meantime we are nice to the user, and allow 
> >absolute paths (which we turn into a relative path, or error out if it 
> >is not under the current working directory).
> >
> >Steffen, can you revert the patch and verify that my memory does not 
> >fail me?
> 
> Is
> 
>   git add /c/msysgit/git/read-cache.c
> 
> an appropriate test?
> 
> It fails with
> 
>   error: 'c:/msysgit/git/read-cache.c' is outside repository
> 
> no matter if the commit is reverted or not.

Yes, that is enough.  It proves that the patch 11/12 is unnecessary and 
should be removed from 4msysgit.git.

Thanks,
Dscho

Re: [msysGit] [PATCH 10/12] Add ANSI control code emulation for the Windows console

[Johannes Sixt]

On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> This adds only the minimum necessary to keep git pull/merge's diffstat from
> wrapping. Notably absent is support for the K (erase) operation, and
> support for POSIX write.

If I understand the patch correctly, it won't affect output that goes to the 
pager; only text that goes directly to the console would be colored. This is 
a start. I think I'll queue this in mingw.git.

-- Hannes

Re: [msysGit] [PATCH 10/12] Add ANSI control code emulation for the Windows console

[Peter Harris]

On Wed, Jul 2, 2008 at 3:17 PM, Johannes Sixt wrote:
> On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
>> This adds only the minimum necessary to keep git pull/merge's diffstat from
>> wrapping. Notably absent is support for the K (erase) operation, and
>> support for POSIX write.
>
> If I understand the patch correctly, it won't affect output that goes to the
> pager; only text that goes directly to the console would be colored.

Yes, that is correct.

Note that an MSYS bash/rxvt is effectively considered a pager by this
patch, since it fails the isatty() test. This is actually a good
thing: MSYS has better ANSI support anyway.

Peter Harris

Re: [msysGit] [PATCH 10/12] Add ANSI control code emulation for the Windows console

[Johannes Sixt]

On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> This adds only the minimum necessary to keep git pull/merge's diffstat from
> wrapping. Notably absent is support for the K (erase) operation, and
> support for POSIX write.

I've tested this patch, and it is no longer ready for prime-time in its 
current form. It doesn't do what it advertises (colorize diffstat of merge) 
because the diff machinery since some time now uses fprintf, not printf, so 
the replacements are not called and escape characters are left in the console 
window.

> +#ifdef WIN_ANSI
> +extern int git_fputs(const char *str, FILE *stream);
> +extern int git_printf(const char *format, ...) __attribute__((format
> (printf, 1, 2))); +#define fputs git_fputs
> +#define printf(...) git_printf(__VA_ARGS__)
> +#endif
> +
>  #endif

Put this (without #ifdef WIN_ANSI) in mingw.h and don't change the Makefile.

-- Hannes

Re: [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it.

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> diff --git a/fast-import.c b/fast-import.c
> index e72b286..271b93c 100644
> --- a/fast-import.c
> +++ b/fast-import.c
> @@ -391,7 +391,9 @@ static void write_crash_report(const char *err)
>  
>  	fprintf(rpt, "fast-import crash report:\n");
>  	fprintf(rpt, "    fast-import process: %d\n", getpid());
> +#ifndef __MINGW32__
>  	fprintf(rpt, "    parent process     : %d\n", getppid());
> +#endif
>  	fprintf(rpt, "    at %s\n", show_date(time(NULL), 0, DATE_LOCAL));
>  	fputc('\n', rpt);
>  
> -- 
> 1.5.6.1.255.g32571

It does not matter too much for this part that writes crash report, but
keeping the file format the same across platforms will make it easier for
tools to read output, so as a general principle, I think this is a
suboptimal solution to the issue.  How about throwing something like this
in MinGW specific header files?

        #define getppid() 0

Re: [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it.

[Steffen Prohaska]

On Jul 2, 2008, at 11:20 AM, Junio C Hamano wrote:

> Steffen Prohaska <prohaska@zib.de> writes:
>
>> diff --git a/fast-import.c b/fast-import.c
>> index e72b286..271b93c 100644
>> --- a/fast-import.c
>> +++ b/fast-import.c
>> @@ -391,7 +391,9 @@ static void write_crash_report(const char *err)
>>
>> 	fprintf(rpt, "fast-import crash report:\n");
>> 	fprintf(rpt, "    fast-import process: %d\n", getpid());
>> +#ifndef __MINGW32__
>> 	fprintf(rpt, "    parent process     : %d\n", getppid());
>> +#endif
>> 	fprintf(rpt, "    at %s\n", show_date(time(NULL), 0, DATE_LOCAL));
>> 	fputc('\n', rpt);
>>
>> --  
>> 1.5.6.1.255.g32571
>
> It does not matter too much for this part that writes crash report,  
> but
> keeping the file format the same across platforms will make it  
> easier for
> tools to read output, so as a general principle, I think this is a
> suboptimal solution to the issue.  How about throwing something like  
> this
> in MinGW specific header files?
>
>        #define getppid() 0

Hannes added something similar to the compat layer, so this commit
is no longer needed.  I'll remove it from the series and revert it
in 4msysgit.

	Steffen

Re: [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it.

[Johannes Schindelin]

Hi,

On Wed, 2 Jul 2008, Junio C Hamano wrote:

> Steffen Prohaska <prohaska@zib.de> writes:
> 
> > diff --git a/fast-import.c b/fast-import.c
> > index e72b286..271b93c 100644
> > --- a/fast-import.c
> > +++ b/fast-import.c
> > @@ -391,7 +391,9 @@ static void write_crash_report(const char *err)
> >  
> >  	fprintf(rpt, "fast-import crash report:\n");
> >  	fprintf(rpt, "    fast-import process: %d\n", getpid());
> > +#ifndef __MINGW32__
> >  	fprintf(rpt, "    parent process     : %d\n", getppid());
> > +#endif
> >  	fprintf(rpt, "    at %s\n", show_date(time(NULL), 0, DATE_LOCAL));
> >  	fputc('\n', rpt);
> >  
> > -- 
> > 1.5.6.1.255.g32571
> 
> It does not matter too much for this part that writes crash report, but
> keeping the file format the same across platforms will make it easier for
> tools to read output, so as a general principle, I think this is a
> suboptimal solution to the issue.  How about throwing something like this
> in MinGW specific header files?
> 
>         #define getppid() 0

Of course, we could also implement it, using NtQueryInformationProcess() 
as suggested by Google.

Ciao,
Dscho

		

Re: [PATCH 07/12] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
>
> Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> ---
>  convert.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/convert.c b/convert.c
> index 1c66844..f24ac25 100644
> --- a/convert.c
> +++ b/convert.c
> @@ -61,6 +61,10 @@ static void gather_stats(const char *buf, unsigned long size, struct text_stat *
>  		else
>  			stats->printable++;
>  	}
> +
> +	// If file ends with EOF then don't count this EOF as non-printable
> +	if ( size >= 1 && buf[size-1] == '\032' )
> +		stats->nonprintable--;

Style.

I debated for 5 seconds with myself if this should be inside #ifdef, but
doing this everywhere would give us reproducibility --- otherwise the
resulting project won't be cross platform, so I think the intention of
this change is good.

[PATCH] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable

[Steffen Prohaska]

From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>

Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 convert.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/convert.c b/convert.c
index 352b69d..78efed8 100644
--- a/convert.c
+++ b/convert.c
@@ -61,6 +61,10 @@ static void gather_stats(const char *buf, unsigned long size, struct text_stat *
 		else
 			stats->printable++;
 	}
+
+	/* If file ends with EOF then don't count this EOF as non-printable. */
+	if (size >= 1 && buf[size-1] == '\032')
+		stats->nonprintable--;
 }
 
 /*
-- 
1.5.6.1.282.gd8a0d

Re: [PATCH] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable

[Johannes Schindelin]

Hi,

On Fri, 11 Jul 2008, Steffen Prohaska wrote:

> From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
> 
> Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> ---
>  convert.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/convert.c b/convert.c
> index 352b69d..78efed8 100644
> --- a/convert.c
> +++ b/convert.c
> @@ -61,6 +61,10 @@ static void gather_stats(const char *buf, unsigned long size, struct text_stat *
>  		else
>  			stats->printable++;
>  	}
> +
> +	/* If file ends with EOF then don't count this EOF as non-printable. */
> +	if (size >= 1 && buf[size-1] == '\032')
> +		stats->nonprintable--;

This is one of the things that are very specific to Windows and should not 
affect other people.

Ciao,
Dscho

P.S.: this is one of the examples why I would like to discuss things that 
are Windows-only on the msysGit list, until we have a consensus there.  We 
have a few Git experts there, you and Hannes in particular, which cover 
that side, but also some Windows experts such as Peter and Marius, and we 
should not need to have that discussion on a list where people are not 
expected to care about Windows _at all_.

Re: [PATCH] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable

[Steffen Prohaska]

On Jul 11, 2008, at 8:42 PM, Johannes Schindelin wrote:

> On Fri, 11 Jul 2008, Steffen Prohaska wrote:
>
>> From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
>>
>> Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
>> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
>> ---
>> convert.c |    4 ++++
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/convert.c b/convert.c
>> index 352b69d..78efed8 100644
>> --- a/convert.c
>> +++ b/convert.c
>> @@ -61,6 +61,10 @@ static void gather_stats(const char *buf,  
>> unsigned long size, struct text_stat *
>> 		else
>> 			stats->printable++;
>> 	}
>> +
>> +	/* If file ends with EOF then don't count this EOF as non- 
>> printable. */
>> +	if (size >= 1 && buf[size-1] == '\032')
>> +		stats->nonprintable--;
>
> This is one of the things that are very specific to Windows and  
> should not
> affect other people.

Does this mean you are opposed to this change?

Junio thinks that "the intention of this change is good" [1].  Hence,
I cleaned up the style and re-send the patch.

[1] http://article.gmane.org/gmane.comp.version-control.git/87122

	Steffen

Re: [PATCH] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable

[Johannes Schindelin]

Hi,

On Fri, 11 Jul 2008, Steffen Prohaska wrote:

> On Jul 11, 2008, at 8:42 PM, Johannes Schindelin wrote:
> 
> >On Fri, 11 Jul 2008, Steffen Prohaska wrote:
> >
> > >From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
> > >
> > >Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
> > >Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> > >---
> > >convert.c |    4 ++++
> > >1 files changed, 4 insertions(+), 0 deletions(-)
> > >
> > >diff --git a/convert.c b/convert.c
> > >index 352b69d..78efed8 100644
> > >--- a/convert.c
> > >+++ b/convert.c
> > >@@ -61,6 +61,10 @@ static void gather_stats(const char *buf, unsigned long
> > >size, struct text_stat *
> > >  else
> > > 		stats->printable++;
> > >	}
> > >+
> > >+	/* If file ends with EOF then don't count this EOF as non-printable.
> > >*/
> > >+	if (size >= 1 && buf[size-1] == '\032')
> > >+		stats->nonprintable--;
> >
> >This is one of the things that are very specific to Windows and should not
> >affect other people.
> 
> Does this mean you are opposed to this change?

Hrm.  Thinking about it again, this _could_ help Unix people who 
collaborate with DOS people.

OTOH it will just hide the fact that text files were committed that 
contain silly characters.

On the third hand, this code path affects only people who set autocrlf.

Well, I guess they asked for it, kind of.

Ciao,
Dscho

Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

[Johannes Sixt]

On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> From: Edward Z. Yang <edwardzyang@thewritingpot.com>
>
> PuTTY requires -P while OpenSSH requires -p; if plink is detected
> as GIT_SSH, use the alternate flag.
>
> Signed-off-by: Edward Z. Yang <edwardzyang@thewritingpot.com>
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> ---
>  connect.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/connect.c b/connect.c
> index 574f42f..0d007f3 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -599,11 +599,13 @@ struct child_process *git_connect(int fd[2], const
> char *url_orig, conn->argv = arg = xcalloc(6, sizeof(*arg));
>  	if (protocol == PROTO_SSH) {
>  		const char *ssh = getenv("GIT_SSH");
> +		int putty = ssh && strstr(ssh, "plink");
>  		if (!ssh) ssh = "ssh";
>
>  		*arg++ = ssh;
>  		if (port) {
> -			*arg++ = "-p";
> +			/* P is for PuTTY, p is for OpenSSH */
> +			*arg++ = putty ? "-P" : "-p";
>  			*arg++ = port;
>  		}
>  		*arg++ = host;

What about installing a wrapper script, plinkssh, that does this:

#!/bin/bash

if test "$1" = -p; then
	port="-P $2"
	shift; shift
fi

exec plink $port "$@"

and require plink users to set GIT_SSH=plinkssh?

-- Hannes

Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

[Johannes Schindelin]

Hi,

On Wed, 2 Jul 2008, Johannes Sixt wrote:

> On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> > From: Edward Z. Yang <edwardzyang@thewritingpot.com>
> >
> > PuTTY requires -P while OpenSSH requires -p; if plink is detected
> > as GIT_SSH, use the alternate flag.
> >
> > Signed-off-by: Edward Z. Yang <edwardzyang@thewritingpot.com>
> > Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> > ---
> >  connect.c |    4 +++-
> >  1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > diff --git a/connect.c b/connect.c
> > index 574f42f..0d007f3 100644
> > --- a/connect.c
> > +++ b/connect.c
> > @@ -599,11 +599,13 @@ struct child_process *git_connect(int fd[2], const
> > char *url_orig, conn->argv = arg = xcalloc(6, sizeof(*arg));
> >  	if (protocol == PROTO_SSH) {
> >  		const char *ssh = getenv("GIT_SSH");
> > +		int putty = ssh && strstr(ssh, "plink");
> >  		if (!ssh) ssh = "ssh";
> >
> >  		*arg++ = ssh;
> >  		if (port) {
> > -			*arg++ = "-p";
> > +			/* P is for PuTTY, p is for OpenSSH */
> > +			*arg++ = putty ? "-P" : "-p";
> >  			*arg++ = port;
> >  		}
> >  		*arg++ = host;
> 
> What about installing a wrapper script, plinkssh, that does this:
> 
> #!/bin/bash
> 
> if test "$1" = -p; then
> 	port="-P $2"
> 	shift; shift
> fi
> 
> exec plink $port "$@"
> 
> and require plink users to set GIT_SSH=plinkssh?

I like that better than this special-casing of plink.

Ciao,
Dscho

Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

[Steffen Prohaska]

On Jul 3, 2008, at 1:10 PM, Johannes Schindelin wrote:

> On Wed, 2 Jul 2008, Johannes Sixt wrote:
>
>> On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
>>> From: Edward Z. Yang <edwardzyang@thewritingpot.com>
>>>
>>> PuTTY requires -P while OpenSSH requires -p; if plink is detected
>>> as GIT_SSH, use the alternate flag.
>>>
>>> Signed-off-by: Edward Z. Yang <edwardzyang@thewritingpot.com>
>>> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
>>> ---
>>> connect.c |    4 +++-
>>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/connect.c b/connect.c
>>> index 574f42f..0d007f3 100644
>>> --- a/connect.c
>>> +++ b/connect.c
>>> @@ -599,11 +599,13 @@ struct child_process *git_connect(int fd[2],  
>>> const
>>> char *url_orig, conn->argv = arg = xcalloc(6, sizeof(*arg));
>>> 	if (protocol == PROTO_SSH) {
>>> 		const char *ssh = getenv("GIT_SSH");
>>> +		int putty = ssh && strstr(ssh, "plink");
>>> 		if (!ssh) ssh = "ssh";
>>>
>>> 		*arg++ = ssh;
>>> 		if (port) {
>>> -			*arg++ = "-p";
>>> +			/* P is for PuTTY, p is for OpenSSH */
>>> +			*arg++ = putty ? "-P" : "-p";
>>> 			*arg++ = port;
>>> 		}
>>> 		*arg++ = host;
>>
>> What about installing a wrapper script, plinkssh, that does this:
>>
>> #!/bin/bash
>>
>> if test "$1" = -p; then
>> 	port="-P $2"
>> 	shift; shift
>> fi
>>
>> exec plink $port "$@"
>>
>> and require plink users to set GIT_SSH=plinkssh?
>
> I like that better than this special-casing of plink.


I'd prefer to change connect.c.  plinkssh would introduce another
dependency on the shell, while our overall goal is to avoid shell as
much as possible on Windows, no?  Edward's solution also looks more
obvious to me than the plinkssh wrapper script.

	Steffen

Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

[Junio C Hamano]

Johannes Sixt <johannes.sixt@telecom.at> writes:

> What about installing a wrapper script, plinkssh, that does this:
>
> #!/bin/bash
>
> if test "$1" = -p; then
> 	port="-P $2"
> 	shift; shift
> fi
>
> exec plink $port "$@"
>
> and require plink users to set GIT_SSH=plinkssh?

That's quite a nice solution with absolute minimum impact.

Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

[Steffen Prohaska]

On Jul 4, 2008, at 11:18 AM, Junio C Hamano wrote:

> Johannes Sixt <johannes.sixt@telecom.at> writes:
>
>> What about installing a wrapper script, plinkssh, that does this:
>>
>> #!/bin/bash
>>
>> if test "$1" = -p; then
>> 	port="-P $2"
>> 	shift; shift
>> fi
>>
>> exec plink $port "$@"
>>
>> and require plink users to set GIT_SSH=plinkssh?
>
> That's quite a nice solution with absolute minimum impact.

It has minimum impact on the source code of git.  The same is not
true, however, for the git user and the installer on Windows:

  - The proposed plinkssh requires that plink is in the PATH.  This is
    not necessarily the case on Windows.  If plink is not in the PATH,
    then the user needs to modify plinkssh.

  - The msysgit installer supports setting GIT_SSH to the full path
    of plink.  It automatically detects this path based on Putty's
    entries in the Windows registry.  If we choose the plinkssh
    solution the installer has to be modified.

Setting '-P' in connect.c would have some impact on the git source,
but would avoid changes elsewhere.

	Steffen

Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

[Clifford Caoile]

Hi:

On Fri, Jul 4, 2008 at 6:29 PM, Steffen Prohaska <prohaska@zib.de> wrote:
>
> On Jul 4, 2008, at 11:18 AM, Junio C Hamano wrote:
>
>> Johannes Sixt <johannes.sixt@telecom.at> writes:
>>
>>> What about installing a wrapper script, plinkssh, that does this:
>>
>> That's quite a nice solution with absolute minimum impact.
>
> It has minimum impact on the source code of git.  The same is not
> true, however, for the git user and the installer on Windows:
>
>  - The proposed plinkssh requires that plink is in the PATH.  This is
>   not necessarily the case on Windows.  If plink is not in the PATH,
>   then the user needs to modify plinkssh.
>
>  - The msysgit installer supports setting GIT_SSH to the full path
>   of plink.  It automatically detects this path based on Putty's
>   entries in the Windows registry.  If we choose the plinkssh
>   solution the installer has to be modified.

How about we create one more global environment variable
MSYSGIT_REAL_PLINK which points to the Windows plink during
installation? Then we set the GIT_SSH to the plinkssh, and the
proposed plinkssh can point to MSYSGIT_REAL_PLINK?

+ # fall back to plink if MSYSGIT_REAL_PLINK is not defined
+ # and hope plink is in the path
+ plink=${MSYSGIT_REAL_PLINK:-plink}

- exec plink $port "$@"
+ exec ${plink} $port "$@"

Perhaps I have traded one problem for another, because the msysgit
user still has to be aware of MSYSGIT_REAL_PLINK (at least she doesn't
have to set it up). And of course, the installer has to be modified to
accommodate plinkssh and my proposal.

Best regards,
Clifford Caoile

Re: [msysGit] Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

[Edward Z. Yang]

Clifford Caoile wrote:
> Perhaps I have traded one problem for another, because the msysgit
> user still has to be aware of MSYSGIT_REAL_PLINK (at least she doesn't
> have to set it up). And of course, the installer has to be modified to
> accommodate plinkssh and my proposal.

This feels unnecessarily complicated.

What would be cool is if we could just set GIT_SSH to plinkssh 
-path-to-plink "C:\Path\To\plink.exe" (obviously a shorter flag or 
something). Unfortunately, this doesn't seem to work with Git's current 
command argument handling.

Re: [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> +/* Convert slashes to backslashes on Windows. */
> +char *make_native_separator(char *path);

Makes one onder why it is not inside #ifdef, but presumably it is no-op on
other platforms (which is fine, better than fine)?

>  static int show_all = 0;
> +#ifdef __MINGW32__
> +static enum help_format help_format = HELP_FORMAT_WEB;
> +#else
>  static enum help_format help_format = HELP_FORMAT_MAN;
> +#endif

That's Ugly isn't it?  Can't you do this with Makefile macro without
#ifdef please?

> @@ -644,12 +649,35 @@ static void get_html_page_path(struct strbuf *page_path, const char *page)
>  
>  static void show_html_page(const char *git_cmd)
>  {
> +#ifdef __MINGW32__
> +	const char* exec_path = git_exec_path();
> +	char *htmlpath = make_native_separator(
> +			   mkpath("%s/../doc/git/html/%s.html"
> +				  , exec_path
> +				  , git_cmd)
> +			 );
> +	if (!file_exists(htmlpath)) {
> +		htmlpath = make_native_separator(
> +			      mkpath("%s/../doc/git/html/git-%s.html"
> +				     , exec_path
> +				     , git_cmd)
> +			   );
> +		if (!file_exists(htmlpath)) {
> +			fprintf(stderr, "Can't find HTML help for '%s'.\n"
> +				, git_cmd);
> +			exit(1);
> +		}
> +	}
> +	printf("Launching default browser to display HTML help ...\n");
> +	ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
> +#else
>  	const char *page = cmd_to_page(git_cmd);
>  	struct strbuf page_path; /* it leaks but we exec bellow */
>  
>  	get_html_page_path(&page_path, page);
>  
>  	execl_git_cmd("web--browse", "-c", "help.browser", page_path.buf, NULL);
> +#endif
>  }

Hmm.  The above almost makes me barf and suggest making them two totally
separate functions (i.e. introduce a new "show_html_page_on_windows()"
function and do not bother us Unix folks ;-).

But I suspect your code is not beyond salvaging.  Why is the htmlpath
computed by hand in this function, instead of having the port specific
implementation hidden inside get_html_page_path() function?

About the execution part, isn't it the matter of using "open" (whatever
that is) as one of the supported backend for web--browse to unify these
two independent case arms?

Re: [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser

[Johannes Sixt]

On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> The implementation directly calls the Win32 API to launch the browser.
> Note that the specific directory layout of msysgit is required.

> +#ifdef __MINGW32__
> +	const char* exec_path = git_exec_path();
> +	char *htmlpath = make_native_separator(
> +			   mkpath("%s/../doc/git/html/%s.html"
> +				  , exec_path
> +				  , git_cmd)
> +			 );
> +	if (!file_exists(htmlpath)) {
> +		htmlpath = make_native_separator(
> +			      mkpath("%s/../doc/git/html/git-%s.html"
> +				     , exec_path
> +				     , git_cmd)
> +			   );
> +		if (!file_exists(htmlpath)) {
> +			fprintf(stderr, "Can't find HTML help for '%s'.\n"
> +				, git_cmd);
> +			exit(1);
> +		}
> +	}
> +	printf("Launching default browser to display HTML help ...\n");
> +	ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
> +#else

Can't we move this part into git-web--browse.sh? It should be a matter of 
calling

	start $htmlpath

(and msys-1.0.dll would convert slashes to backslashes for us).

-- Hannes

Re: [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser

[Steffen Prohaska]

On Jul 2, 2008, at 8:57 PM, Johannes Sixt wrote:

> On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
>> The implementation directly calls the Win32 API to launch the  
>> browser.
>> Note that the specific directory layout of msysgit is required.
>
>> +#ifdef __MINGW32__
>> +	const char* exec_path = git_exec_path();
>> +	char *htmlpath = make_native_separator(
>> +			   mkpath("%s/../doc/git/html/%s.html"
>> +				  , exec_path
>> +				  , git_cmd)
>> +			 );
>> +	if (!file_exists(htmlpath)) {
>> +		htmlpath = make_native_separator(
>> +			      mkpath("%s/../doc/git/html/git-%s.html"
>> +				     , exec_path
>> +				     , git_cmd)
>> +			   );
>> +		if (!file_exists(htmlpath)) {
>> +			fprintf(stderr, "Can't find HTML help for '%s'.\n"
>> +				, git_cmd);
>> +			exit(1);
>> +		}
>> +	}
>> +	printf("Launching default browser to display HTML help ...\n");
>> +	ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
>> +#else
>
> Can't we move this part into git-web--browse.sh? It should be a  
> matter of
> calling
>
> 	start $htmlpath
>
> (and msys-1.0.dll would convert slashes to backslashes for us).

I try to avoid the shell as much as possible on Windows.

How about the two following patches:

  [PATCH 1/2] help.c: Add support for htmldir relative to  
git_exec_path()
  [PATCH 2/2] help (Windows): Display HTML in default browser using  
Win32 API

I'll send them as replies to this mail.

	Steffen

	

[PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path()

[Steffen Prohaska]

If htmldir (in the Makefile) is a relative path, this path will be
interpreted relative to git_exec_path.  This can be used to create an
installation that can be moved to a different directory without
re-compiling.  The Windows installer (msysgit) is an example for such
a setup.

Note that the Makefile maps htmldir to the define GIT_HTML_PATH.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 help.c |   14 +++++++++++---
 1 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/help.c b/help.c
index ca9632b..5586e1d 100644
--- a/help.c
+++ b/help.c
@@ -634,12 +634,20 @@ static void get_html_page_path(struct strbuf *page_path, const char *page)
 {
 	struct stat st;
 
+	const char* html_path = GIT_HTML_PATH;
+	if (!is_absolute_path(html_path)) {
+		struct strbuf d = STRBUF_INIT;
+		strbuf_addf(&d, "%s/%s", git_exec_path(), html_path);
+		html_path = strbuf_detach(&d, NULL);
+	}
+
 	/* Check that we have a git documentation directory. */
-	if (stat(GIT_HTML_PATH "/git.html", &st) || !S_ISREG(st.st_mode))
-		die("'%s': not a documentation directory.", GIT_HTML_PATH);
+	if (stat(mkpath("%s/git.html", html_path), &st)
+	    || !S_ISREG(st.st_mode))
+		die("'%s': not a documentation directory.", html_path);
 
 	strbuf_init(page_path, 0);
-	strbuf_addf(page_path, GIT_HTML_PATH "/%s.html", page);
+	strbuf_addf(page_path, "%s/%s.html", html_path, page);
 }
 
 static void show_html_page(const char *git_cmd)
-- 
1.5.6.1.282.gd8a0d

[PATCH 2/2] help (Windows): Display HTML in default browser using Win32 API

[Steffen Prohaska]

The Win32 API is now called directly to launch the system's default
browser for displaying HTML help pages instead of launching a shell to
execute git-web--browser.  Avoiding the MSYS' bash when possible is good
because it avoids potential path translation issues.  In this case it is
not too hard to avoid launching a shell, so let's avoid it.

This commit also adds make_native_separator() to convert slashes to
backslashes on Windows.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 cache.h |    2 ++
 help.c  |   18 ++++++++++++++++++
 path.c  |   18 ++++++++++++++++++
 3 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/cache.h b/cache.h
index 35a9132..747581f 100644
--- a/cache.h
+++ b/cache.h
@@ -527,6 +527,8 @@ static inline int is_absolute_path(const char *path)
 const char *make_absolute_path(const char *path);
 const char *make_nonrelative_path(const char *path);
 const char *make_relative_path(const char *abs, const char *base);
+/* Convert slashes to backslashes on Windows.  no-op on other platforms. */
+const char *make_native_separator(const char *path);
 
 /* Read and unpack a sha1 file into memory, write memory to a sha1 file */
 extern int sha1_object_info(const unsigned char *, unsigned long *);
diff --git a/help.c b/help.c
index 5586e1d..8fcd644 100644
--- a/help.c
+++ b/help.c
@@ -9,6 +9,7 @@
 #include "common-cmds.h"
 #include "parse-options.h"
 #include "run-command.h"
+#include "dir.h"
 
 static struct man_viewer_list {
 	struct man_viewer_list *next;
@@ -650,6 +651,19 @@ static void get_html_page_path(struct strbuf *page_path, const char *page)
 	strbuf_addf(page_path, "%s/%s.html", html_path, page);
 }
 
+#ifdef __MINGW32__
+static void open_html_win(const char *unixpath)
+{
+	const char *htmlpath = make_native_separator(mkpath("%s",unixpath));
+	if (!file_exists(htmlpath)) {
+		fprintf(stderr, "HTML file '%s' does not exist.\n", htmlpath);
+		exit(1);
+	}
+	printf("Launching default browser to display HTML help ...\n");
+	ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
+}
+#endif
+
 static void show_html_page(const char *git_cmd)
 {
 	const char *page = cmd_to_page(git_cmd);
@@ -657,7 +671,11 @@ static void show_html_page(const char *git_cmd)
 
 	get_html_page_path(&page_path, page);
 
+#ifdef __MINGW32__
+	open_html_win(page_path.buf);
+#else
 	execl_git_cmd("web--browse", "-c", "help.browser", page_path.buf, NULL);
+#endif
 }
 
 void help_unknown_cmd(const char *cmd)
diff --git a/path.c b/path.c
index 496123c..9f2bd91 100644
--- a/path.c
+++ b/path.c
@@ -343,3 +343,21 @@ const char *make_relative_path(const char *abs, const char *base)
 	strcpy(buf, abs + baselen);
 	return buf;
 }
+
+const char *make_native_separator(const char* path) {
+#ifdef __MINGW32__
+	static char buf[PATH_MAX + 1];
+	char* c;
+
+	if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
+		die ("Too long path: %.*s", 60, path);
+
+	for (c = buf; *c; c++) {
+		if (*c == '/')
+			*c = '\\';
+	}
+	return buf;
+#else
+	return path;
+#endif
+}
-- 
1.5.6.1.282.gd8a0d

Re: [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path()

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> If htmldir (in the Makefile) is a relative path, this path will be
> interpreted relative to git_exec_path.  This can be used to create an
> installation that can be moved to a different directory without
> re-compiling.  The Windows installer (msysgit) is an example for such
> a setup.
> ...
> +	const char* html_path = GIT_HTML_PATH;

Style.  Asterisk sticks to the variable, not type.

> +	if (!is_absolute_path(html_path)) {
> +		struct strbuf d = STRBUF_INIT;
> +		strbuf_addf(&d, "%s/%s", git_exec_path(), html_path);
> +		html_path = strbuf_detach(&d, NULL);
> +	}

I've seen similar "if $this (which is usually an absolute) is relative, it
is taken as relative to git_exec_path" solution employed elsewhere in the
MinGW series, and I think it makes sense, even though initially I thought
it was somewhat hacky.

Could you check if there are copy-and-pasted duplicated code you can
factor out before continuing this direction?  I suspect templates and
etc/gitconfig are specified in similar fashion, and it would probably be
easier to maintain if you define once:

	char *system_path(const char *specified)
        {
        	if (is_absolute_path(specified))
	                return specified;
		... strbuf dance ...
                return strbuf_detach(...);
        }

and use it like this:

	const char *html_path = system_path(GIT_HTML_PATH);

Re: [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path()

[Johannes Schindelin]

Hi,

On Fri, 4 Jul 2008, Junio C Hamano wrote:

> Could you check if there are copy-and-pasted duplicated code you can 
> factor out before continuing this direction?

Note also that Hannes tried very hard to get rid of those ugly "#ifdef 
__MINGW32__"s by declaring/overriding functions in git-compat-util.h.

I think that is such a good practice that we should not stop here.

Ciao,
Dscho

Re: [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path()

[Steffen Prohaska]

On Jul 4, 2008, at 2:35 PM, Johannes Schindelin wrote:

> On Fri, 4 Jul 2008, Junio C Hamano wrote:
>
>> Could you check if there are copy-and-pasted duplicated code you can
>> factor out before continuing this direction?
>
> Note also that Hannes tried very hard to get rid of those ugly "#ifdef
> __MINGW32__"s by declaring/overriding functions in git-compat-util.h.
>
> I think that is such a good practice that we should not stop here.

I'll send three patches that address Junio's and Dscho's comments:

  [PATCH 1/3] Move code interpreting path relative to exec-dir to new  
function system_path()
  [PATCH 2/3] help.c: Add support for htmldir relative to  
git_exec_path()
  [PATCH 3/3] help (Windows): Display HTML in default browser using  
Windows' shell API


Hannes,
the patches I'll send probably conflict with your planned work on
GIT_EXEC_PATH that has been discussed on the msysgit list.  I think
you could built on my series and modify system_path().

	Steffen

[PATCH 1/3] Move code interpreting path relative to exec-dir to new function system_path()

[Steffen Prohaska]

Expanding system paths relative to git_exec_path can be used for
creating an installation that can be moved to a different directory
without re-compiling.  We use this approach for template_dir and the
system wide gitconfig.  The Windows installer (msysgit) is an example
for such a setup.

This commit moves common code to a new function system_path().  System
paths that are to be interpreted relative to git_exec_path are passed to
system_path() and the return value is used instead of the original path.
system_path() prefixes a relative path with git_exec_path and leaves
absolute paths unmodified.  For example, we now write

    template_dir = system_path(DEFAULT_GIT_TEMPLATE_DIR);

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 builtin-init-db.c |   14 ++------------
 cache.h           |    1 +
 config.c          |   11 ++---------
 path.c            |   11 +++++++++++
 4 files changed, 16 insertions(+), 21 deletions(-)

diff --git a/builtin-init-db.c b/builtin-init-db.c
index e23b843..5ba213a 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -115,18 +115,8 @@ static void copy_templates(const char *template_dir)
 
 	if (!template_dir)
 		template_dir = getenv(TEMPLATE_DIR_ENVIRONMENT);
-	if (!template_dir) {
-		/*
-		 * if the hard-coded template is relative, it is
-		 * interpreted relative to the exec_dir
-		 */
-		template_dir = DEFAULT_GIT_TEMPLATE_DIR;
-		if (!is_absolute_path(template_dir)) {
-			struct strbuf d = STRBUF_INIT;
-			strbuf_addf(&d, "%s/%s", git_exec_path(), template_dir);
-			template_dir = strbuf_detach(&d, NULL);
-		}
-	}
+	if (!template_dir)
+		template_dir = system_path(DEFAULT_GIT_TEMPLATE_DIR);
 	strcpy(template_path, template_dir);
 	template_len = strlen(template_path);
 	if (template_path[template_len-1] != '/') {
diff --git a/cache.h b/cache.h
index 0d8edda..dafa265 100644
--- a/cache.h
+++ b/cache.h
@@ -529,6 +529,7 @@ const char *make_nonrelative_path(const char *path);
 const char *make_relative_path(const char *abs, const char *base);
 int normalize_absolute_path(char *buf, const char *path);
 int longest_ancestor_length(const char *path, const char *prefix_list);
+extern const char *system_path(const char *path);
 
 /* Read and unpack a sha1 file into memory, write memory to a sha1 file */
 extern int sha1_object_info(const unsigned char *, unsigned long *);
diff --git a/config.c b/config.c
index 2862cc4..1e066c7 100644
--- a/config.c
+++ b/config.c
@@ -581,15 +581,8 @@ int git_config_from_file(config_fn_t fn, const char *filename, void *data)
 const char *git_etc_gitconfig(void)
 {
 	static const char *system_wide;
-	if (!system_wide) {
-		system_wide = ETC_GITCONFIG;
-		if (!is_absolute_path(system_wide)) {
-			/* interpret path relative to exec-dir */
-			struct strbuf d = STRBUF_INIT;
-			strbuf_addf(&d, "%s/%s", git_exec_path(), system_wide);
-			system_wide = strbuf_detach(&d, NULL);
-		}
-	}
+	if (!system_wide)
+		system_wide = system_path(ETC_GITCONFIG);
 	return system_wide;
 }
 
diff --git a/path.c b/path.c
index 5983255..141496e 100644
--- a/path.c
+++ b/path.c
@@ -11,6 +11,7 @@
  * which is what it's designed for.
  */
 #include "cache.h"
+#include "exec_cmd.h"
 
 static char bad_path[] = "/bad-path/";
 
@@ -439,3 +440,13 @@ int longest_ancestor_length(const char *path, const char *prefix_list)
 
 	return max_len;
 }
+
+const char *system_path(const char *path)
+{
+	if (!is_absolute_path(path)) {
+		struct strbuf d = STRBUF_INIT;
+		strbuf_addf(&d, "%s/%s", git_exec_path(), path);
+		path = strbuf_detach(&d, NULL);
+	}
+	return path;
+}
-- 
1.5.6.1.282.gd8a0d

[PATCH 2/3] help.c: Add support for htmldir relative to git_exec_path()

[Steffen Prohaska]

If htmldir (in the Makefile) is a relative path, this path will now be
interpreted relative to git_exec_path.  This can be used to create an
installation that can be moved to a different directory without
re-compiling.  The Windows installer (msysgit) is an example for such
a setup.

Note that the Makefile maps htmldir to the define GIT_HTML_PATH.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 help.c |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/help.c b/help.c
index ca9632b..0f055bf 100644
--- a/help.c
+++ b/help.c
@@ -633,13 +633,15 @@ static void show_info_page(const char *git_cmd)
 static void get_html_page_path(struct strbuf *page_path, const char *page)
 {
 	struct stat st;
+	const char *html_path = system_path(GIT_HTML_PATH);
 
 	/* Check that we have a git documentation directory. */
-	if (stat(GIT_HTML_PATH "/git.html", &st) || !S_ISREG(st.st_mode))
-		die("'%s': not a documentation directory.", GIT_HTML_PATH);
+	if (stat(mkpath("%s/git.html", html_path), &st)
+	    || !S_ISREG(st.st_mode))
+		die("'%s': not a documentation directory.", html_path);
 
 	strbuf_init(page_path, 0);
-	strbuf_addf(page_path, GIT_HTML_PATH "/%s.html", page);
+	strbuf_addf(page_path, "%s/%s.html", html_path, page);
 }
 
 static void show_html_page(const char *git_cmd)
-- 
1.5.6.1.282.gd8a0d

[PATCH 3/3] help (Windows): Display HTML in default browser using Windows' shell API

[Steffen Prohaska]

The system's default browser for displaying HTML help pages is now used
directly on Windows, instead of launching git-web--browser, which
requires a Unix shell.  Avoiding MSYS' bash when possible is good
because it avoids potential path translation issues.  In this case it is
not too hard to avoid launching a shell, so let's avoid it.

The Windows-specific code is implemented in compat/mingw.c to avoid
platform-specific code in the main code base.  On Windows, open_html is
provided as a define.  If open_html is not defined, git-web--browse is
used.  This approach avoids platform-specific ifdefs by using
per-function ifdefs.  The "ifndef open_html" together with the
introductory comment should sufficiently warn developers, so that they
hopefully will not break this mechanism.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 compat/mingw.c |   21 +++++++++++++++++++++
 compat/mingw.h |    3 +++
 help.c         |   14 +++++++++++++-
 3 files changed, 37 insertions(+), 1 deletions(-)

diff --git a/compat/mingw.c b/compat/mingw.c
index 3a05fe7..f7ef545 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1017,3 +1017,24 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler)
 	timer_fn = handler;
 	return old;
 }
+
+static const char *make_backslash_path(const char* path) {
+	static char buf[PATH_MAX + 1];
+	char* c;
+
+	if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
+		die ("Too long path: %.*s", 60, path);
+
+	for (c = buf; *c; c++) {
+		if (*c == '/')
+			*c = '\\';
+	}
+	return buf;
+}
+
+void mingw_open_html(const char *unixpath)
+{
+	const char *htmlpath = make_backslash_path(unixpath);
+	printf("Launching default browser to display HTML ...\n");
+	ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
+}
diff --git a/compat/mingw.h b/compat/mingw.h
index 6bc049a..136361e 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -193,6 +193,9 @@ static inline unsigned int git_ntohl(unsigned int x)
 sig_handler_t mingw_signal(int sig, sig_handler_t handler);
 #define signal mingw_signal
 
+void mingw_open_html(const char *path);
+#define open_html mingw_open_html
+
 /*
  * git specific compatibility
  */
diff --git a/help.c b/help.c
index 0f055bf..18116f3 100644
--- a/help.c
+++ b/help.c
@@ -644,6 +644,18 @@ static void get_html_page_path(struct strbuf *page_path, const char *page)
 	strbuf_addf(page_path, "%s/%s.html", html_path, page);
 }
 
+/*
+ * If open_html is not defined in a platform-specific way (see for
+ * example compat/mingw.h), we use the script web--browse to display
+ * HTML.
+ */
+#ifndef open_html
+void open_html(const char* path)
+{
+	execl_git_cmd("web--browse", "-c", "help.browser", path, NULL);
+}
+#endif
+
 static void show_html_page(const char *git_cmd)
 {
 	const char *page = cmd_to_page(git_cmd);
@@ -651,7 +663,7 @@ static void show_html_page(const char *git_cmd)
 
 	get_html_page_path(&page_path, page);
 
-	execl_git_cmd("web--browse", "-c", "help.browser", page_path.buf, NULL);
+	open_html(page_path.buf);
 }
 
 void help_unknown_cmd(const char *cmd)
-- 
1.5.6.1.282.gd8a0d

Re: [PATCH 3/3] help (Windows): Display HTML in default browser using Windows' shell API

[Steffen Prohaska]

On Jul 11, 2008, at 9:28 AM, Steffen Prohaska wrote:

> +
> +static const char *make_backslash_path(const char* path) {
> +	static char buf[PATH_MAX + 1];
> +	char* c;

Style :-(.  I'll send a fixed patch in a minute.


> +#ifndef open_html
> +void open_html(const char* path)
> +{

It'll fix this too.

	Steffen

[PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API

[Steffen Prohaska]

The system's default browser for displaying HTML help pages is now used
directly on Windows, instead of launching git-web--browser, which
requires a Unix shell.  Avoiding MSYS' bash when possible is good
because it avoids potential path translation issues.  In this case it is
not too hard to avoid launching a shell, so let's avoid it.

The Windows-specific code is implemented in compat/mingw.c to avoid
platform-specific code in the main code base.  On Windows, open_html is
provided as a define.  If open_html is not defined, git-web--browse is
used.  This approach avoids platform-specific ifdefs by using
per-function ifdefs.  The "ifndef open_html" together with the
introductory comment should sufficiently warn developers, so that they
hopefully will not break this mechanism.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 compat/mingw.c |   21 +++++++++++++++++++++
 compat/mingw.h |    3 +++
 help.c         |   14 +++++++++++++-
 3 files changed, 37 insertions(+), 1 deletions(-)

diff --git a/compat/mingw.c b/compat/mingw.c
index 3a05fe7..0ca73f7 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1017,3 +1017,24 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler)
 	timer_fn = handler;
 	return old;
 }
+
+static const char *make_backslash_path(const char *path) {
+	static char buf[PATH_MAX + 1];
+	char *c;
+
+	if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
+		die ("Too long path: %.*s", 60, path);
+
+	for (c = buf; *c; c++) {
+		if (*c == '/')
+			*c = '\\';
+	}
+	return buf;
+}
+
+void mingw_open_html(const char *unixpath)
+{
+	const char *htmlpath = make_backslash_path(unixpath);
+	printf("Launching default browser to display HTML ...\n");
+	ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
+}
diff --git a/compat/mingw.h b/compat/mingw.h
index 6bc049a..136361e 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -193,6 +193,9 @@ static inline unsigned int git_ntohl(unsigned int x)
 sig_handler_t mingw_signal(int sig, sig_handler_t handler);
 #define signal mingw_signal
 
+void mingw_open_html(const char *path);
+#define open_html mingw_open_html
+
 /*
  * git specific compatibility
  */
diff --git a/help.c b/help.c
index 0f055bf..52d39b8 100644
--- a/help.c
+++ b/help.c
@@ -644,6 +644,18 @@ static void get_html_page_path(struct strbuf *page_path, const char *page)
 	strbuf_addf(page_path, "%s/%s.html", html_path, page);
 }
 
+/*
+ * If open_html is not defined in a platform-specific way (see for
+ * example compat/mingw.h), we use the script web--browse to display
+ * HTML.
+ */
+#ifndef open_html
+void open_html(const char *path)
+{
+	execl_git_cmd("web--browse", "-c", "help.browser", path, NULL);
+}
+#endif
+
 static void show_html_page(const char *git_cmd)
 {
 	const char *page = cmd_to_page(git_cmd);
@@ -651,7 +663,7 @@ static void show_html_page(const char *git_cmd)
 
 	get_html_page_path(&page_path, page);
 
-	execl_git_cmd("web--browse", "-c", "help.browser", page_path.buf, NULL);
+	open_html(page_path.buf);
 }
 
 void help_unknown_cmd(const char *cmd)
-- 
1.5.6.1.282.gd8a0d

Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> diff --git a/compat/mingw.c b/compat/mingw.c
> index 3a05fe7..0ca73f7 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -1017,3 +1017,24 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler)
> ...
> +void mingw_open_html(const char *unixpath)
> +{
> +	const char *htmlpath = make_backslash_path(unixpath);
> +	printf("Launching default browser to display HTML ...\n");
> +	ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
> +}

Do you mean to have that printf() or is it a leftover debugging statement?

Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API

[Steffen Prohaska]

On Jul 12, 2008, at 5:26 AM, Junio C Hamano wrote:

> Steffen Prohaska <prohaska@zib.de> writes:
>
>> diff --git a/compat/mingw.c b/compat/mingw.c
>> index 3a05fe7..0ca73f7 100644
>> --- a/compat/mingw.c
>> +++ b/compat/mingw.c
>> @@ -1017,3 +1017,24 @@ sig_handler_t mingw_signal(int sig,  
>> sig_handler_t handler)
>> ...
>> +void mingw_open_html(const char *unixpath)
>> +{
>> +	const char *htmlpath = make_backslash_path(unixpath);
>> +	printf("Launching default browser to display HTML ...\n");
>> +	ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
>> +}
>
> Do you mean to have that printf() or is it a leftover debugging  
> statement?

I mean to have it.  It takes some time until a fresh browser starts up
if no browser has been running before.  Impatient people (like me) could
start believing that nothing would happen.  But this certainly depends
on your machine.  I run Windows inside a virtual machine on a Laptop,
which is probably rather slow compared to a desktop machine running
Windows natively.

	Steffen

Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

>> Do you mean to have that printf() or is it a leftover debugging
>> statement?
>
> I mean to have it.

Ok, I was just checking.  Unless other Windows users complain, will apply
as-is.  As you might guess, I am completely neutral on this one.

Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API

[Johannes Sixt]

Zitat von Junio C Hamano <gitster@pobox.com>:

> Steffen Prohaska <prohaska@zib.de> writes:
>
> >> Do you mean to have that printf() or is it a leftover debugging
> >> statement?
> >
> > I mean to have it.
>
> Ok, I was just checking.  Unless other Windows users complain, will apply
> as-is.  As you might guess, I am completely neutral on this one.

I'm working on followups to this series, and it turns out to be more
convenient to have system_path() in exec_cmd.c instead of path.c.
It'll make sense if I resend the series with an updated version of 1/3
(instead of a patch that merely moves the function around).

-- Hannes

Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API

[Junio C Hamano]

Johannes Sixt <johannes.sixt@telecom.at> writes:

> Zitat von Junio C Hamano <gitster@pobox.com>:
>
>> Steffen Prohaska <prohaska@zib.de> writes:
>>
>> >> Do you mean to have that printf() or is it a leftover debugging
>> >> statement?
>> >
>> > I mean to have it.
>>
>> Ok, I was just checking.  Unless other Windows users complain, will apply
>> as-is.  As you might guess, I am completely neutral on this one.
>
> I'm working on followups to this series, and it turns out to be more
> convenient to have system_path() in exec_cmd.c instead of path.c.
> It'll make sense if I resend the series with an updated version of 1/3
> (instead of a patch that merely moves the function around).

Ok, will drop these three patches and wait for replacement from yours to
appear, and then we will see which ones to apply.

[PATCH] Move code interpreting path relative to exec-dir to new function system_path()

[Johannes Sixt]

From: Steffen Prohaska <prohaska@zib.de>

Expanding system paths relative to git_exec_path can be used for
creating an installation that can be moved to a different directory
without re-compiling.  We use this approach for template_dir and the
system wide gitconfig.  The Windows installer (msysgit) is an example
for such a setup.

This commit moves common code to a new function system_path().  System
paths that are to be interpreted relative to git_exec_path are passed to
system_path() and the return value is used instead of the original path.
system_path() prefixes a relative path with git_exec_path and leaves
absolute paths unmodified.  For example, we now write

    template_dir = system_path(DEFAULT_GIT_TEMPLATE_DIR);

[j6t: moved from path.c to exec_cmd.c]

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 builtin-init-db.c |   14 ++------------
 config.c          |   11 ++---------
 exec_cmd.c        |   10 ++++++++++
 exec_cmd.h        |    2 +-
 4 files changed, 15 insertions(+), 22 deletions(-)

diff --git a/builtin-init-db.c b/builtin-init-db.c
index e23b843..5ba213a 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -115,18 +115,8 @@ static void copy_templates(const char *template_dir)
 
 	if (!template_dir)
 		template_dir = getenv(TEMPLATE_DIR_ENVIRONMENT);
-	if (!template_dir) {
-		/*
-		 * if the hard-coded template is relative, it is
-		 * interpreted relative to the exec_dir
-		 */
-		template_dir = DEFAULT_GIT_TEMPLATE_DIR;
-		if (!is_absolute_path(template_dir)) {
-			struct strbuf d = STRBUF_INIT;
-			strbuf_addf(&d, "%s/%s", git_exec_path(), template_dir);
-			template_dir = strbuf_detach(&d, NULL);
-		}
-	}
+	if (!template_dir)
+		template_dir = system_path(DEFAULT_GIT_TEMPLATE_DIR);
 	strcpy(template_path, template_dir);
 	template_len = strlen(template_path);
 	if (template_path[template_len-1] != '/') {
diff --git a/config.c b/config.c
index 2862cc4..1e066c7 100644
--- a/config.c
+++ b/config.c
@@ -581,15 +581,8 @@ int git_config_from_file(config_fn_t fn, const char *filename, void *data)
 const char *git_etc_gitconfig(void)
 {
 	static const char *system_wide;
-	if (!system_wide) {
-		system_wide = ETC_GITCONFIG;
-		if (!is_absolute_path(system_wide)) {
-			/* interpret path relative to exec-dir */
-			struct strbuf d = STRBUF_INIT;
-			strbuf_addf(&d, "%s/%s", git_exec_path(), system_wide);
-			system_wide = strbuf_detach(&d, NULL);
-		}
-	}
+	if (!system_wide)
+		system_wide = system_path(ETC_GITCONFIG);
 	return system_wide;
 }
 
diff --git a/exec_cmd.c b/exec_cmd.c
index da04efe..8899e31 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -40,6 +40,16 @@ static const char *builtin_exec_path(void)
 #endif
 }
 
+const char *system_path(const char *path)
+{
+	if (!is_absolute_path(path)) {
+		struct strbuf d = STRBUF_INIT;
+		strbuf_addf(&d, "%s/%s", git_exec_path(), path);
+		path = strbuf_detach(&d, NULL);
+	}
+	return path;
+}
+
 void git_set_argv_exec_path(const char *exec_path)
 {
 	argv_exec_path = exec_path;
diff --git a/exec_cmd.h b/exec_cmd.h
index a892355..7eb94e5 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -6,6 +6,6 @@ extern const char* git_exec_path(void);
 extern void setup_path(const char *);
 extern int execv_git_cmd(const char **argv); /* NULL terminated */
 extern int execl_git_cmd(const char *cmd, ...);
-
+extern const char *system_path(const char *path);
 
 #endif /* GIT_EXEC_CMD_H */
-- 
1.5.6.2.300.ga3a9

[PATCH] help.c: Add support for htmldir relative to git_exec_path()

[Johannes Sixt]

From: Steffen Prohaska <prohaska@zib.de>

If htmldir (in the Makefile) is a relative path, this path will now be
interpreted relative to git_exec_path.  This can be used to create an
installation that can be moved to a different directory without
re-compiling.  The Windows installer (msysgit) is an example for such
a setup.

Note that the Makefile maps htmldir to the define GIT_HTML_PATH.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 help.c |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/help.c b/help.c
index ca9632b..0f055bf 100644
--- a/help.c
+++ b/help.c
@@ -633,13 +633,15 @@ static void show_info_page(const char *git_cmd)
 static void get_html_page_path(struct strbuf *page_path, const char *page)
 {
 	struct stat st;
+	const char *html_path = system_path(GIT_HTML_PATH);
 
 	/* Check that we have a git documentation directory. */
-	if (stat(GIT_HTML_PATH "/git.html", &st) || !S_ISREG(st.st_mode))
-		die("'%s': not a documentation directory.", GIT_HTML_PATH);
+	if (stat(mkpath("%s/git.html", html_path), &st)
+	    || !S_ISREG(st.st_mode))
+		die("'%s': not a documentation directory.", html_path);
 
 	strbuf_init(page_path, 0);
-	strbuf_addf(page_path, GIT_HTML_PATH "/%s.html", page);
+	strbuf_addf(page_path, "%s/%s.html", html_path, page);
 }
 
 static void show_html_page(const char *git_cmd)
-- 
1.5.6.2.300.ga3a9

[PATCH] help (Windows): Display HTML in default browser using Windows' shell API

[Johannes Sixt]

From: Steffen Prohaska <prohaska@zib.de>

The system's default browser for displaying HTML help pages is now used
directly on Windows, instead of launching git-web--browser, which
requires a Unix shell.  Avoiding MSYS' bash when possible is good
because it avoids potential path translation issues.  In this case it is
not too hard to avoid launching a shell, so let's avoid it.

The Windows-specific code is implemented in compat/mingw.c to avoid
platform-specific code in the main code base.  On Windows, open_html is
provided as a define.  If open_html is not defined, git-web--browse is
used.  This approach avoids platform-specific ifdefs by using
per-function ifdefs.  The "ifndef open_html" together with the
introductory comment should sufficiently warn developers, so that they
hopefully will not break this mechanism.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 compat/mingw.c |   21 +++++++++++++++++++++
 compat/mingw.h |    3 +++
 help.c         |   14 +++++++++++++-
 3 files changed, 37 insertions(+), 1 deletions(-)

diff --git a/compat/mingw.c b/compat/mingw.c
index 3a05fe7..0ca73f7 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1017,3 +1017,24 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler)
 	timer_fn = handler;
 	return old;
 }
+
+static const char *make_backslash_path(const char *path) {
+	static char buf[PATH_MAX + 1];
+	char *c;
+
+	if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
+		die ("Too long path: %.*s", 60, path);
+
+	for (c = buf; *c; c++) {
+		if (*c == '/')
+			*c = '\\';
+	}
+	return buf;
+}
+
+void mingw_open_html(const char *unixpath)
+{
+	const char *htmlpath = make_backslash_path(unixpath);
+	printf("Launching default browser to display HTML ...\n");
+	ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
+}
diff --git a/compat/mingw.h b/compat/mingw.h
index 6bc049a..5a3bcee 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -202,6 +202,9 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler);
 #define PATH_SEP ';'
 #define PRIuMAX "I64u"
 
+void mingw_open_html(const char *path);
+#define open_html mingw_open_html
+
 /*
  * helpers
  */
diff --git a/help.c b/help.c
index 0f055bf..52d39b8 100644
--- a/help.c
+++ b/help.c
@@ -644,6 +644,18 @@ static void get_html_page_path(struct strbuf *page_path, const char *page)
 	strbuf_addf(page_path, "%s/%s.html", html_path, page);
 }
 
+/*
+ * If open_html is not defined in a platform-specific way (see for
+ * example compat/mingw.h), we use the script web--browse to display
+ * HTML.
+ */
+#ifndef open_html
+void open_html(const char *path)
+{
+	execl_git_cmd("web--browse", "-c", "help.browser", path, NULL);
+}
+#endif
+
 static void show_html_page(const char *git_cmd)
 {
 	const char *page = cmd_to_page(git_cmd);
@@ -651,7 +663,7 @@ static void show_html_page(const char *git_cmd)
 
 	get_html_page_path(&page_path, page);
 
-	execl_git_cmd("web--browse", "-c", "help.browser", page_path.buf, NULL);
+	open_html(page_path.buf);
 }
 
 void help_unknown_cmd(const char *cmd)
-- 
1.5.6.2.300.ga3a9

[PATCH] Fix relative built-in paths to be relative to the command invocation

[Johannes Sixt]

$(gitexecdir) (as defined in the Makefile) has gained another path
component, but the relative paths in the MINGW section of the Makefile,
which are interpreted relative to it, do not account for it.

Instead of adding another ../ in front of the path, we change the code that
constructs the absolute paths to do it relative to the command's directory,
which is essentially $(bindir). We do it this way because we will also
allow a relative $(gitexecdir) later.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 Makefile       |    2 +-
 exec_cmd.c     |   14 ++++++++++----
 exec_cmd.h     |    3 ++-
 git.c          |    5 ++---
 receive-pack.c |    2 +-
 shell.c        |    4 ++--
 upload-pack.c  |    2 +-
 7 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/Makefile b/Makefile
index 4796565..2bdb9bf 100644
--- a/Makefile
+++ b/Makefile
@@ -1301,7 +1301,7 @@ remove-dashes:
 ### Installation rules
 
 ifeq ($(firstword $(subst /, ,$(template_dir))),..)
-template_instdir = $(gitexecdir)/$(template_dir)
+template_instdir = $(shell cd '$(bindir_SQ)/$(template_dir_SQ)' && pwd)
 else
 template_instdir = $(template_dir)
 endif
diff --git a/exec_cmd.c b/exec_cmd.c
index 8899e31..45f92eb 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -5,6 +5,7 @@
 
 extern char **environ;
 static const char *argv_exec_path;
+static const char *argv0_path;
 
 static const char *builtin_exec_path(void)
 {
@@ -42,14 +43,19 @@ static const char *builtin_exec_path(void)
 
 const char *system_path(const char *path)
 {
-	if (!is_absolute_path(path)) {
+	if (!is_absolute_path(path) && argv0_path) {
 		struct strbuf d = STRBUF_INIT;
-		strbuf_addf(&d, "%s/%s", git_exec_path(), path);
+		strbuf_addf(&d, "%s/%s", argv0_path, path);
 		path = strbuf_detach(&d, NULL);
 	}
 	return path;
 }
 
+void git_set_argv0_path(const char *path)
+{
+	argv0_path = path;
+}
+
 void git_set_argv_exec_path(const char *exec_path)
 {
 	argv_exec_path = exec_path;
@@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char *path)
 	}
 }
 
-void setup_path(const char *cmd_path)
+void setup_path(void)
 {
 	const char *old_path = getenv("PATH");
 	struct strbuf new_path;
@@ -94,7 +100,7 @@ void setup_path(const char *cmd_path)
 	add_path(&new_path, argv_exec_path);
 	add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
 	add_path(&new_path, builtin_exec_path());
-	add_path(&new_path, cmd_path);
+	add_path(&new_path, argv0_path);
 
 	if (old_path)
 		strbuf_addstr(&new_path, old_path);
diff --git a/exec_cmd.h b/exec_cmd.h
index 7eb94e5..0c46cd5 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -2,8 +2,9 @@
 #define GIT_EXEC_CMD_H
 
 extern void git_set_argv_exec_path(const char *exec_path);
+extern void git_set_argv0_path(const char *path);
 extern const char* git_exec_path(void);
-extern void setup_path(const char *);
+extern void setup_path(void);
 extern int execv_git_cmd(const char **argv); /* NULL terminated */
 extern int execl_git_cmd(const char *cmd, ...);
 extern const char *system_path(const char *path);
diff --git a/git.c b/git.c
index 7075533..b90c358 100644
--- a/git.c
+++ b/git.c
@@ -470,7 +470,6 @@ int main(int argc, const char **argv)
 {
 	const char *cmd = argv[0] && *argv[0] ? argv[0] : "git-help";
 	char *slash = (char *)cmd + strlen(cmd);
-	const char *cmd_path = NULL;
 	int done_alias = 0;
 
 	/*
@@ -483,7 +482,7 @@ int main(int argc, const char **argv)
 	while (cmd <= slash && !is_dir_sep(*slash));
 	if (cmd <= slash) {
 		*slash++ = 0;
-		cmd_path = cmd;
+		git_set_argv0_path(cmd);
 		cmd = slash;
 	}
 
@@ -527,7 +526,7 @@ int main(int argc, const char **argv)
 	 * environment, and the $(gitexecdir) from the Makefile at build
 	 * time.
 	 */
-	setup_path(cmd_path);
+	setup_path();
 
 	while (1) {
 		/* See if it's an internal command */
diff --git a/receive-pack.c b/receive-pack.c
index fa653b4..d44c19e 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -482,7 +482,7 @@ int main(int argc, char **argv)
 	if (!dir)
 		usage(receive_pack_usage);
 
-	setup_path(NULL);
+	setup_path();
 
 	if (!enter_repo(dir, 0))
 		die("'%s': unable to chdir or not a git archive", dir);
diff --git a/shell.c b/shell.c
index 91ca7de..6a48de0 100644
--- a/shell.c
+++ b/shell.c
@@ -15,7 +15,7 @@ static int do_generic_cmd(const char *me, char *arg)
 {
 	const char *my_argv[4];
 
-	setup_path(NULL);
+	setup_path();
 	if (!arg || !(arg = sq_dequote(arg)))
 		die("bad argument");
 	if (prefixcmp(me, "git-"))
@@ -37,7 +37,7 @@ static int do_cvs_cmd(const char *me, char *arg)
 	if (!arg || strcmp(arg, "server"))
 		die("git-cvsserver only handles server: %s", arg);
 
-	setup_path(NULL);
+	setup_path();
 	return execv_git_cmd(cvsserver_argv);
 }
 
diff --git a/upload-pack.c b/upload-pack.c
index 9f82941..c911e70 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -638,7 +638,7 @@ int main(int argc, char **argv)
 	if (i != argc-1)
 		usage(upload_pack_usage);
 
-	setup_path(NULL);
+	setup_path();
 
 	dir = argv[i];
 
-- 
1.5.6.2.300.ga3a9

[PATCH] Allow the built-in exec path to be relative to the command invocation path

[Johannes Sixt]

If GIT_EXEC_PATH (the macro that is defined in the Makefile) is relative,
it is interpreted relative to the command's invocation path, which usually
is $(bindir).

The Makefile rules were written with the assumption that $(gitexecdir) is
an absolute path. We introduce a separate variable that names the
(absolute) installation directory.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 Makefile   |   23 +++++++++++++++--------
 exec_cmd.c |   38 ++------------------------------------
 2 files changed, 17 insertions(+), 44 deletions(-)

diff --git a/Makefile b/Makefile
index 2bdb9bf..3593e6f 100644
--- a/Makefile
+++ b/Makefile
@@ -1307,10 +1307,17 @@ template_instdir = $(template_dir)
 endif
 export template_instdir
 
+ifeq ($(firstword $(subst /, ,$(gitexecdir))),..)
+gitexec_instdir = $(shell cd '$(bindir_SQ)/$(gitexecdir_SQ)' && pwd)
+else
+gitexec_instdir = $(gitexecdir)
+endif
+gitexec_instdir_SQ = $(subst ','\'',$(gitexec_instdir))
+
 install: all
 	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
-	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
-	$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
+	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+	$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
 	$(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X '$(DESTDIR_SQ)$(bindir_SQ)'
 	$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
 	$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
@@ -1318,18 +1325,18 @@ ifndef NO_TCLTK
 	$(MAKE) -C gitk-git install
 	$(MAKE) -C git-gui install
 endif
-	if test 'z$(bindir_SQ)' != 'z$(gitexecdir_SQ)'; \
+	if test 'z$(bindir_SQ)' != 'z$(gitexec_instdir_SQ)'; \
 	then \
 		ln -f '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
-			'$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' || \
+			'$(DESTDIR_SQ)$(gitexec_instdir_SQ)/git$X' || \
 		cp '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
-			'$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
+			'$(DESTDIR_SQ)$(gitexec_instdir_SQ)/git$X'; \
 	fi
-	$(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
+	$(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p' ;)
 ifneq (,$X)
-	$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
+	$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p';)
 endif
-	./check_bindir 'z$(bindir_SQ)' 'z$(gitexecdir_SQ)' '$(DESTDIR_SQ)$(bindir_SQ)/git-shell$X'
+	./check_bindir 'z$(bindir_SQ)' 'z$(gitexec_instdir_SQ)' '$(DESTDIR_SQ)$(bindir_SQ)/git-shell$X'
 
 install-doc:
 	$(MAKE) -C Documentation install
diff --git a/exec_cmd.c b/exec_cmd.c
index 45f92eb..c236034 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -7,40 +7,6 @@ extern char **environ;
 static const char *argv_exec_path;
 static const char *argv0_path;
 
-static const char *builtin_exec_path(void)
-{
-#ifndef __MINGW32__
-	return GIT_EXEC_PATH;
-#else
-	int len;
-	char *p, *q, *sl;
-	static char *ep;
-	if (ep)
-		return ep;
-
-	len = strlen(_pgmptr);
-	if (len < 2)
-		return ep = ".";
-
-	p = ep = xmalloc(len+1);
-	q = _pgmptr;
-	sl = NULL;
-	/* copy program name, turn '\\' into '/', skip last part */
-	while ((*p = *q)) {
-		if (*q == '\\' || *q == '/') {
-			*p = '/';
-			sl = p;
-		}
-		p++, q++;
-	}
-	if (sl)
-		*sl = '\0';
-	else
-		ep[0] = '.', ep[1] = '\0';
-	return ep;
-#endif
-}
-
 const char *system_path(const char *path)
 {
 	if (!is_absolute_path(path) && argv0_path) {
@@ -75,7 +41,7 @@ const char *git_exec_path(void)
 		return env;
 	}
 
-	return builtin_exec_path();
+	return system_path(GIT_EXEC_PATH);
 }
 
 static void add_path(struct strbuf *out, const char *path)
@@ -99,7 +65,7 @@ void setup_path(void)
 
 	add_path(&new_path, argv_exec_path);
 	add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
-	add_path(&new_path, builtin_exec_path());
+	add_path(&new_path, system_path(GIT_EXEC_PATH));
 	add_path(&new_path, argv0_path);
 
 	if (old_path)
-- 
1.5.6.2.300.ga3a9

[PATCH] Allow add_path() to add non-existent directories to the path

[Johannes Sixt]

This function had used make_absolute_path(); but this function dies if
the directory that contains the entry whose relative path was supplied in
the argument does not exist. This is a problem if the argument is, for
example, "../libexec/git-core", and that "../libexec" does not exist.

Since the resolution of symbolic links is not required for elements in
PATH, we can fall back to using make_nonrelative_path(), which simply
prepends $PWD to the path.

We have to move make_nonrelative_path() alongside make_absolute_path() in
abspath.c so that git-shell can be linked. See 5b8e6f85f.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 abspath.c  |   36 ++++++++++++++++++++++++++++++++++++
 exec_cmd.c |    2 +-
 path.c     |   36 ------------------------------------
 3 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/abspath.c b/abspath.c
index 4f95a95..99ee1af 100644
--- a/abspath.c
+++ b/abspath.c
@@ -66,3 +66,39 @@ const char *make_absolute_path(const char *path)
 
 	return buf;
 }
+
+static const char *get_pwd_cwd(void)
+{
+	static char cwd[PATH_MAX + 1];
+	char *pwd;
+	struct stat cwd_stat, pwd_stat;
+	if (getcwd(cwd, PATH_MAX) == NULL)
+		return NULL;
+	pwd = getenv("PWD");
+	if (pwd && strcmp(pwd, cwd)) {
+		stat(cwd, &cwd_stat);
+		if (!stat(pwd, &pwd_stat) &&
+		    pwd_stat.st_dev == cwd_stat.st_dev &&
+		    pwd_stat.st_ino == cwd_stat.st_ino) {
+			strlcpy(cwd, pwd, PATH_MAX);
+		}
+	}
+	return cwd;
+}
+
+const char *make_nonrelative_path(const char *path)
+{
+	static char buf[PATH_MAX + 1];
+
+	if (is_absolute_path(path)) {
+		if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
+			die ("Too long path: %.*s", 60, path);
+	} else {
+		const char *cwd = get_pwd_cwd();
+		if (!cwd)
+			die("Cannot determine the current working directory");
+		if (snprintf(buf, PATH_MAX, "%s/%s", cwd, path) >= PATH_MAX)
+			die ("Too long path: %.*s", 60, path);
+	}
+	return buf;
+}
diff --git a/exec_cmd.c b/exec_cmd.c
index c236034..0ed768d 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -50,7 +50,7 @@ static void add_path(struct strbuf *out, const char *path)
 		if (is_absolute_path(path))
 			strbuf_addstr(out, path);
 		else
-			strbuf_addstr(out, make_absolute_path(path));
+			strbuf_addstr(out, make_nonrelative_path(path));
 
 		strbuf_addch(out, PATH_SEP);
 	}
diff --git a/path.c b/path.c
index 5983255..16c1d01 100644
--- a/path.c
+++ b/path.c
@@ -291,42 +291,6 @@ int adjust_shared_perm(const char *path)
 	return 0;
 }
 
-static const char *get_pwd_cwd(void)
-{
-	static char cwd[PATH_MAX + 1];
-	char *pwd;
-	struct stat cwd_stat, pwd_stat;
-	if (getcwd(cwd, PATH_MAX) == NULL)
-		return NULL;
-	pwd = getenv("PWD");
-	if (pwd && strcmp(pwd, cwd)) {
-		stat(cwd, &cwd_stat);
-		if (!stat(pwd, &pwd_stat) &&
-		    pwd_stat.st_dev == cwd_stat.st_dev &&
-		    pwd_stat.st_ino == cwd_stat.st_ino) {
-			strlcpy(cwd, pwd, PATH_MAX);
-		}
-	}
-	return cwd;
-}
-
-const char *make_nonrelative_path(const char *path)
-{
-	static char buf[PATH_MAX + 1];
-
-	if (is_absolute_path(path)) {
-		if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
-			die ("Too long path: %.*s", 60, path);
-	} else {
-		const char *cwd = get_pwd_cwd();
-		if (!cwd)
-			die("Cannot determine the current working directory");
-		if (snprintf(buf, PATH_MAX, "%s/%s", cwd, path) >= PATH_MAX)
-			die ("Too long path: %.*s", 60, path);
-	}
-	return buf;
-}
-
 const char *make_relative_path(const char *abs, const char *base)
 {
 	static char buf[PATH_MAX + 1];
-- 
1.5.6.2.300.ga3a9

Re: [PATCH] Allow add_path() to add non-existent directories to the path

[Johannes Sixt]

Johannes Sixt schrieb:
> +static const char *get_pwd_cwd(void)
> +{
> +	static char cwd[PATH_MAX + 1];
> +	char *pwd;
> +	struct stat cwd_stat, pwd_stat;
> +	if (getcwd(cwd, PATH_MAX) == NULL)
> +		return NULL;
> +	pwd = getenv("PWD");
> +	if (pwd && strcmp(pwd, cwd)) {
> +		stat(cwd, &cwd_stat);
> +		if (!stat(pwd, &pwd_stat) &&
> +		    pwd_stat.st_dev == cwd_stat.st_dev &&
> +		    pwd_stat.st_ino == cwd_stat.st_ino) {
> +			strlcpy(cwd, pwd, PATH_MAX);

git-bash users on Windows, please test this patch. The problem is that
with our custom stat implementation st_dev and st_ino are not reliable. It
 works in my setup because $PWD is not set and this branch is never
entered, but with bash it makes a difference.

-- Hannes

Re: [PATCH] Allow the built-in exec path to be relative to the command invocation path

[Johannes Schindelin]

Hi,

On Sun, 13 Jul 2008, Johannes Sixt wrote:

> [a patch series, with 3 patches from Steffen]

Wow.  I like this demonstration how a nice patch series looks like.

Ciao,
Dscho

Re: [PATCH] Fix relative built-in paths to be relative to the command invocation

[Johannes Schindelin]

Hi,

On Sun, 13 Jul 2008, Johannes Sixt wrote:

> diff --git a/Makefile b/Makefile
> index 4796565..2bdb9bf 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1301,7 +1301,7 @@ remove-dashes:
>  ### Installation rules
>  
>  ifeq ($(firstword $(subst /, ,$(template_dir))),..)
> -template_instdir = $(gitexecdir)/$(template_dir)
> +template_instdir = $(shell cd '$(bindir_SQ)/$(template_dir_SQ)' && pwd)

What is this for?  Did the original line stop working?

> diff --git a/exec_cmd.c b/exec_cmd.c
> index 8899e31..45f92eb 100644
> --- a/exec_cmd.c
> +++ b/exec_cmd.c
> @@ -5,6 +5,7 @@
>  
>  extern char **environ;
>  static const char *argv_exec_path;
> +static const char *argv0_path;
>  
>  static const char *builtin_exec_path(void)
>  {
> @@ -42,14 +43,19 @@ static const char *builtin_exec_path(void)
>  
>  const char *system_path(const char *path)
>  {
> -	if (!is_absolute_path(path)) {
> +	if (!is_absolute_path(path) && argv0_path) {
>  		struct strbuf d = STRBUF_INIT;
> -		strbuf_addf(&d, "%s/%s", git_exec_path(), path);
> +		strbuf_addf(&d, "%s/%s", argv0_path, path);
>  		path = strbuf_detach(&d, NULL);
>  	}
>  	return path;
>  }
>  
> +void git_set_argv0_path(const char *path)
> +{
> +	argv0_path = path;
> +}
> +
>  void git_set_argv_exec_path(const char *exec_path)
>  {
>  	argv_exec_path = exec_path;
> @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char *path)
>  	}
>  }
>  
> -void setup_path(const char *cmd_path)
> +void setup_path(void)

It seems to me that this patch would not do anything different, but with 
less code change, if setup_path() would set argv0_path, and not a new 
function was introduced.

Ciao,
Dscho

Re: [PATCH] Fix relative built-in paths to be relative to the command invocation

[Johannes Sixt]

Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>:

> Hi,
>
> On Sun, 13 Jul 2008, Johannes Sixt wrote:
>
> > diff --git a/Makefile b/Makefile
> > index 4796565..2bdb9bf 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1301,7 +1301,7 @@ remove-dashes:
> >  ### Installation rules
> >
> >  ifeq ($(firstword $(subst /, ,$(template_dir))),..)
> > -template_instdir = $(gitexecdir)/$(template_dir)
> > +template_instdir = $(shell cd '$(bindir_SQ)/$(template_dir_SQ)' && pwd)
>
> What is this for?  Did the original line stop working?

I could just have changed $(gitexecdir) to $(bindir), but in the
make-execpath-relative patch we will need the normalized gitexec_instdir
because its value is compared to $(bindir). So the extra $(shell...) in
_this_ patch is only that the final result looks consistent.

> > diff --git a/exec_cmd.c b/exec_cmd.c
> > index 8899e31..45f92eb 100644
> > --- a/exec_cmd.c
> > +++ b/exec_cmd.c
> > @@ -5,6 +5,7 @@
> >
> >  extern char **environ;
> >  static const char *argv_exec_path;
> > +static const char *argv0_path;
> >
> >  static const char *builtin_exec_path(void)
> >  {
> > @@ -42,14 +43,19 @@ static const char *builtin_exec_path(void)
> >
> >  const char *system_path(const char *path)
> >  {
> > -	if (!is_absolute_path(path)) {
> > +	if (!is_absolute_path(path) && argv0_path) {
> >  		struct strbuf d = STRBUF_INIT;
> > -		strbuf_addf(&d, "%s/%s", git_exec_path(), path);
> > +		strbuf_addf(&d, "%s/%s", argv0_path, path);
> >  		path = strbuf_detach(&d, NULL);
> >  	}
> >  	return path;
> >  }
> >
> > +void git_set_argv0_path(const char *path)
> > +{
> > +	argv0_path = path;
> > +}
> > +
> >  void git_set_argv_exec_path(const char *exec_path)
> >  {
> >  	argv_exec_path = exec_path;
> > @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char
> *path)
> >  	}
> >  }
> >
> > -void setup_path(const char *cmd_path)
> > +void setup_path(void)
>
> It seems to me that this patch would not do anything different, but with
> less code change, if setup_path() would set argv0_path, and not a new
> function was introduced.

This is just to play a safe game. I had it that way, but I decided to have
the call to the new git_set_argv0_path() early in git.c because the call
to setup_path() in git.c is very late, and it could happen that we call
system_path() (which needs argv0_path) before that. Although I didn't audit
the code whether this really happens.

-- Hannes

Re: [PATCH] Fix relative built-in paths to be relative to the command invocation

[Johannes Schindelin]

Hi,

On Mon, 14 Jul 2008, Johannes Sixt wrote:

> Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> 
> > On Sun, 13 Jul 2008, Johannes Sixt wrote:
> >
> > > @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char
> > > *path)
> > >  	}
> > >  }
> > >
> > > -void setup_path(const char *cmd_path)
> > > +void setup_path(void)
> >
> > It seems to me that this patch would not do anything different, but 
> > with less code change, if setup_path() would set argv0_path, and not a 
> > new function was introduced.
> 
> This is just to play a safe game. I had it that way, but I decided to have
> the call to the new git_set_argv0_path() early in git.c because the call
> to setup_path() in git.c is very late, and it could happen that we call
> system_path() (which needs argv0_path) before that. Although I didn't audit
> the code whether this really happens.

Well, okay... I would have rather seen it not change (since there was no 
bug to fix), or as a separate patch, but it's Junio's call.

Ciao,
Dscho

Re: [PATCH] Fix relative built-in paths to be relative to the command invocation

[Johannes Sixt]

On Montag, 14. Juli 2008, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 14 Jul 2008, Johannes Sixt wrote:
> > Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > > On Sun, 13 Jul 2008, Johannes Sixt wrote:
> > > > @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char
> > > > *path)
> > > >  	}
> > > >  }
> > > >
> > > > -void setup_path(const char *cmd_path)
> > > > +void setup_path(void)
> > >
> > > It seems to me that this patch would not do anything different, but
> > > with less code change, if setup_path() would set argv0_path, and not a
> > > new function was introduced.
> >
> > This is just to play a safe game. I had it that way, but I decided to
> > have the call to the new git_set_argv0_path() early in git.c because the
> > call to setup_path() in git.c is very late, and it could happen that we
> > call system_path() (which needs argv0_path) before that. Although I
> > didn't audit the code whether this really happens.
>
> Well, okay... I would have rather seen it not change (since there was no
> bug to fix), or as a separate patch, but it's Junio's call.

I investigated this, and, yes, there indeed are calls to system_path() before 
setup_path(), for example:

 commit_pager_choice
   setup_pager
     git_config
       git_etc_gitconfig
         system_path(ETC_GITCONFIG)

Junio, do you want git_set_argv0_path() in a separate patch?

-- Hannes

Re: [PATCH] Fix relative built-in paths to be relative to the command invocation

[Junio C Hamano]

Johannes Sixt <johannes.sixt@telecom.at> writes:

> On Montag, 14. Juli 2008, Johannes Schindelin wrote:
>> Hi,
>>
>> On Mon, 14 Jul 2008, Johannes Sixt wrote:
>> > Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> > > On Sun, 13 Jul 2008, Johannes Sixt wrote:
>> > > > @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char
>> > > > *path)
>> > > >  	}
>> > > >  }
>> > > >
>> > > > -void setup_path(const char *cmd_path)
>> > > > +void setup_path(void)
>> > >
>> > > It seems to me that this patch would not do anything different, but
>> > > with less code change, if setup_path() would set argv0_path, and not a
>> > > new function was introduced.
>> >
>> > This is just to play a safe game. I had it that way, but I decided to
>> > have the call to the new git_set_argv0_path() early in git.c because the
>> > call to setup_path() in git.c is very late, and it could happen that we
>> > call system_path() (which needs argv0_path) before that. Although I
>> > didn't audit the code whether this really happens.
>>
>> Well, okay... I would have rather seen it not change (since there was no
>> bug to fix), or as a separate patch, but it's Junio's call.
>
> I investigated this, and, yes, there indeed are calls to system_path() before 
> setup_path(), for example:
>
>  commit_pager_choice
>    setup_pager
>      git_config
>        git_etc_gitconfig
>          system_path(ETC_GITCONFIG)
>
> Junio, do you want git_set_argv0_path() in a separate patch?

I think that would be easier to explain in the commit log what is going
on, if it is a separate patch.

Re: [PATCH] Fix relative built-in paths to be relative to the command invocation

[Johannes Sixt]

Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>:

> Hi,
>
> On Sun, 13 Jul 2008, Johannes Sixt wrote:
>
> > diff --git a/Makefile b/Makefile
> > index 4796565..2bdb9bf 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1301,7 +1301,7 @@ remove-dashes:
> >  ### Installation rules
> >
> >  ifeq ($(firstword $(subst /, ,$(template_dir))),..)
> > -template_instdir = $(gitexecdir)/$(template_dir)
> > +template_instdir = $(shell cd '$(bindir_SQ)/$(template_dir_SQ)' && pwd)
>
> What is this for?  Did the original line stop working?

Hmpf! This new line doesn't work in the intended way if the installation
destination does not exist. I'll have to find a better solution...

-- Hannes

[PATCH 0/5] replacement for the part of js/more-win that is in pu

[Johannes Sixt]

The interdiff to js/more-win is below. It is mostly the changes
of 1/5.

Johannes Sixt (5):
      Makefile: Normalize $(bindir) and $(gitexecdir) before comparing
      Record the command invocation path early
      Fix relative built-in paths to be relative to the command
         invocation
      Allow the built-in exec path to be relative to the command
         invocation path
      Allow add_path() to add non-existent directories to the path


 Makefile       |   33 +++++++++++++++++-----------
 abspath.c      |   36 ++++++++++++++++++++++++++++++
 exec_cmd.c     |   54 +++++++++++----------------------------------
 exec_cmd.h     |    3 +-
 git.c          |    5 +--
 path.c         |   36 ------------------------------
 receive-pack.c |    2 +-
 shell.c        |    4 +-
 upload-pack.c  |    2 +-
 9 files changed, 77 insertions(+), 98 deletions(-)


diff --git a/Makefile b/Makefile
index 3593e6f..4df6423 100644
--- a/Makefile
+++ b/Makefile
@@ -1301,14 +1301,14 @@ remove-dashes:
 ### Installation rules
 
 ifeq ($(firstword $(subst /, ,$(template_dir))),..)
-template_instdir = $(shell cd '$(bindir_SQ)/$(template_dir_SQ)' && pwd)
+template_instdir = $(bindir)/$(template_dir)
 else
 template_instdir = $(template_dir)
 endif
 export template_instdir
 
 ifeq ($(firstword $(subst /, ,$(gitexecdir))),..)
-gitexec_instdir = $(shell cd '$(bindir_SQ)/$(gitexecdir_SQ)' && pwd)
+gitexec_instdir = $(bindir)/$(gitexecdir)
 else
 gitexec_instdir = $(gitexecdir)
 endif
@@ -1325,18 +1325,18 @@ ifndef NO_TCLTK
 	$(MAKE) -C gitk-git install
 	$(MAKE) -C git-gui install
 endif
-	if test 'z$(bindir_SQ)' != 'z$(gitexec_instdir_SQ)'; \
-	then \
-		ln -f '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
-			'$(DESTDIR_SQ)$(gitexec_instdir_SQ)/git$X' || \
-		cp '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
-			'$(DESTDIR_SQ)$(gitexec_instdir_SQ)/git$X'; \
-	fi
-	$(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p' ;)
 ifneq (,$X)
 	$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p';)
 endif
-	./check_bindir 'z$(bindir_SQ)' 'z$(gitexec_instdir_SQ)' '$(DESTDIR_SQ)$(bindir_SQ)/git-shell$X'
+	bindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \
+	execdir=$$(cd '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' && pwd) && \
+	if test "z$$bindir" != "z$$execdir"; \
+	then \
+		ln -f "$$bindir/git$X" "$$execdir/git$X" || \
+		cp "$$bindir/git$X" "$$execdir/git$X"; \
+	fi && \
+	{ $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \
+	./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-shell$X"
 
 install-doc:
 	$(MAKE) -C Documentation install

[PATCH 1/5] Makefile: Normalize $(bindir) and $(gitexecdir) before comparing

[Johannes Sixt]

The install target needs to check whether the user has opted to make
$(gitexecdir) equal to $(bindir). It did so by a straight string
comparison. Since we are going to allow a relative $(gitexecdir), we have
to normalize paths before comparison, which we do with $(cd there && pwd).

The normalized paths are stored in shell variables. These we can now
reuse in the subsequent install statements, which conveniently shortens
the lines a bit.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 Makefile |   18 +++++++++---------
 1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/Makefile b/Makefile
index 4796565..4de9271 100644
--- a/Makefile
+++ b/Makefile
@@ -1318,18 +1318,18 @@ ifndef NO_TCLTK
 	$(MAKE) -C gitk-git install
 	$(MAKE) -C git-gui install
 endif
-	if test 'z$(bindir_SQ)' != 'z$(gitexecdir_SQ)'; \
-	then \
-		ln -f '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
-			'$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' || \
-		cp '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
-			'$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
-	fi
-	$(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
 ifneq (,$X)
 	$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
 endif
-	./check_bindir 'z$(bindir_SQ)' 'z$(gitexecdir_SQ)' '$(DESTDIR_SQ)$(bindir_SQ)/git-shell$X'
+	bindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \
+	execdir=$$(cd '$(DESTDIR_SQ)$(gitexecdir_SQ)' && pwd) && \
+	if test "z$$bindir" != "z$$execdir"; \
+	then \
+		ln -f "$$bindir/git$X" "$$execdir/git$X" || \
+		cp "$$bindir/git$X" "$$execdir/git$X"; \
+	fi && \
+	{ $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \
+	./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-shell$X"
 
 install-doc:
 	$(MAKE) -C Documentation install
-- 
1.5.6.3.323.g1e58

[PATCH 2/5] Record the command invocation path early

[Johannes Sixt]

We will need the command invocation path in system_path(). This path was
passed to setup_path(), but  system_path() can be called earlier, for
example via:

    main
      commit_pager_choice
        setup_pager
          git_config
            git_etc_gitconfig
              system_path

Therefore, we introduce git_set_argv0_path() and call it as soon as
possible.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 exec_cmd.c     |   10 ++++++++--
 exec_cmd.h     |    3 ++-
 git.c          |    5 ++---
 receive-pack.c |    2 +-
 shell.c        |    4 ++--
 upload-pack.c  |    2 +-
 6 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/exec_cmd.c b/exec_cmd.c
index 8899e31..dedb01d 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -5,6 +5,7 @@
 
 extern char **environ;
 static const char *argv_exec_path;
+static const char *argv0_path;
 
 static const char *builtin_exec_path(void)
 {
@@ -50,6 +51,11 @@ const char *system_path(const char *path)
 	return path;
 }
 
+void git_set_argv0_path(const char *path)
+{
+	argv0_path = path;
+}
+
 void git_set_argv_exec_path(const char *exec_path)
 {
 	argv_exec_path = exec_path;
@@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char *path)
 	}
 }
 
-void setup_path(const char *cmd_path)
+void setup_path(void)
 {
 	const char *old_path = getenv("PATH");
 	struct strbuf new_path;
@@ -94,7 +100,7 @@ void setup_path(const char *cmd_path)
 	add_path(&new_path, argv_exec_path);
 	add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
 	add_path(&new_path, builtin_exec_path());
-	add_path(&new_path, cmd_path);
+	add_path(&new_path, argv0_path);
 
 	if (old_path)
 		strbuf_addstr(&new_path, old_path);
diff --git a/exec_cmd.h b/exec_cmd.h
index 7eb94e5..0c46cd5 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -2,8 +2,9 @@
 #define GIT_EXEC_CMD_H
 
 extern void git_set_argv_exec_path(const char *exec_path);
+extern void git_set_argv0_path(const char *path);
 extern const char* git_exec_path(void);
-extern void setup_path(const char *);
+extern void setup_path(void);
 extern int execv_git_cmd(const char **argv); /* NULL terminated */
 extern int execl_git_cmd(const char *cmd, ...);
 extern const char *system_path(const char *path);
diff --git a/git.c b/git.c
index 7075533..b90c358 100644
--- a/git.c
+++ b/git.c
@@ -470,7 +470,6 @@ int main(int argc, const char **argv)
 {
 	const char *cmd = argv[0] && *argv[0] ? argv[0] : "git-help";
 	char *slash = (char *)cmd + strlen(cmd);
-	const char *cmd_path = NULL;
 	int done_alias = 0;
 
 	/*
@@ -483,7 +482,7 @@ int main(int argc, const char **argv)
 	while (cmd <= slash && !is_dir_sep(*slash));
 	if (cmd <= slash) {
 		*slash++ = 0;
-		cmd_path = cmd;
+		git_set_argv0_path(cmd);
 		cmd = slash;
 	}
 
@@ -527,7 +526,7 @@ int main(int argc, const char **argv)
 	 * environment, and the $(gitexecdir) from the Makefile at build
 	 * time.
 	 */
-	setup_path(cmd_path);
+	setup_path();
 
 	while (1) {
 		/* See if it's an internal command */
diff --git a/receive-pack.c b/receive-pack.c
index fa653b4..d44c19e 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -482,7 +482,7 @@ int main(int argc, char **argv)
 	if (!dir)
 		usage(receive_pack_usage);
 
-	setup_path(NULL);
+	setup_path();
 
 	if (!enter_repo(dir, 0))
 		die("'%s': unable to chdir or not a git archive", dir);
diff --git a/shell.c b/shell.c
index 91ca7de..6a48de0 100644
--- a/shell.c
+++ b/shell.c
@@ -15,7 +15,7 @@ static int do_generic_cmd(const char *me, char *arg)
 {
 	const char *my_argv[4];
 
-	setup_path(NULL);
+	setup_path();
 	if (!arg || !(arg = sq_dequote(arg)))
 		die("bad argument");
 	if (prefixcmp(me, "git-"))
@@ -37,7 +37,7 @@ static int do_cvs_cmd(const char *me, char *arg)
 	if (!arg || strcmp(arg, "server"))
 		die("git-cvsserver only handles server: %s", arg);
 
-	setup_path(NULL);
+	setup_path();
 	return execv_git_cmd(cvsserver_argv);
 }
 
diff --git a/upload-pack.c b/upload-pack.c
index 9f82941..c911e70 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -638,7 +638,7 @@ int main(int argc, char **argv)
 	if (i != argc-1)
 		usage(upload_pack_usage);
 
-	setup_path(NULL);
+	setup_path();
 
 	dir = argv[i];
 
-- 
1.5.6.3.323.g1e58

[PATCH 3/5] Fix relative built-in paths to be relative to the command invocation

[Johannes Sixt]

$(gitexecdir) (as defined in the Makefile) has gained another path
component, but the relative paths in the MINGW section of the Makefile,
which are interpreted relative to it, do not account for it.

Instead of adding another ../ in front of the path, we change the code that
constructs the absolute paths to do it relative to the command's directory,
which is essentially $(bindir). We do it this way because we will also
allow a relative $(gitexecdir) later.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 Makefile   |    2 +-
 exec_cmd.c |    4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 4de9271..b9ea0ea 100644
--- a/Makefile
+++ b/Makefile
@@ -1301,7 +1301,7 @@ remove-dashes:
 ### Installation rules
 
 ifeq ($(firstword $(subst /, ,$(template_dir))),..)
-template_instdir = $(gitexecdir)/$(template_dir)
+template_instdir = $(bindir)/$(template_dir)
 else
 template_instdir = $(template_dir)
 endif
diff --git a/exec_cmd.c b/exec_cmd.c
index dedb01d..45f92eb 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -43,9 +43,9 @@ static const char *builtin_exec_path(void)
 
 const char *system_path(const char *path)
 {
-	if (!is_absolute_path(path)) {
+	if (!is_absolute_path(path) && argv0_path) {
 		struct strbuf d = STRBUF_INIT;
-		strbuf_addf(&d, "%s/%s", git_exec_path(), path);
+		strbuf_addf(&d, "%s/%s", argv0_path, path);
 		path = strbuf_detach(&d, NULL);
 	}
 	return path;
-- 
1.5.6.3.323.g1e58

[PATCH 4/5] Allow the built-in exec path to be relative to the command invocation path

[Johannes Sixt]

If GIT_EXEC_PATH (the macro that is defined in the Makefile) is relative,
it is interpreted relative to the command's invocation path, which usually
is $(bindir).

The Makefile rules were written with the assumption that $(gitexecdir) is
an absolute path. We introduce a separate variable that names the
(absolute) installation directory.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 Makefile   |   15 +++++++++++----
 exec_cmd.c |   38 ++------------------------------------
 2 files changed, 13 insertions(+), 40 deletions(-)

diff --git a/Makefile b/Makefile
index b9ea0ea..4df6423 100644
--- a/Makefile
+++ b/Makefile
@@ -1307,10 +1307,17 @@ template_instdir = $(template_dir)
 endif
 export template_instdir
 
+ifeq ($(firstword $(subst /, ,$(gitexecdir))),..)
+gitexec_instdir = $(bindir)/$(gitexecdir)
+else
+gitexec_instdir = $(gitexecdir)
+endif
+gitexec_instdir_SQ = $(subst ','\'',$(gitexec_instdir))
+
 install: all
 	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
-	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
-	$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
+	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+	$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
 	$(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X '$(DESTDIR_SQ)$(bindir_SQ)'
 	$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
 	$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
@@ -1319,10 +1326,10 @@ ifndef NO_TCLTK
 	$(MAKE) -C git-gui install
 endif
 ifneq (,$X)
-	$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
+	$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p';)
 endif
 	bindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \
-	execdir=$$(cd '$(DESTDIR_SQ)$(gitexecdir_SQ)' && pwd) && \
+	execdir=$$(cd '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' && pwd) && \
 	if test "z$$bindir" != "z$$execdir"; \
 	then \
 		ln -f "$$bindir/git$X" "$$execdir/git$X" || \
diff --git a/exec_cmd.c b/exec_cmd.c
index 45f92eb..c236034 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -7,40 +7,6 @@ extern char **environ;
 static const char *argv_exec_path;
 static const char *argv0_path;
 
-static const char *builtin_exec_path(void)
-{
-#ifndef __MINGW32__
-	return GIT_EXEC_PATH;
-#else
-	int len;
-	char *p, *q, *sl;
-	static char *ep;
-	if (ep)
-		return ep;
-
-	len = strlen(_pgmptr);
-	if (len < 2)
-		return ep = ".";
-
-	p = ep = xmalloc(len+1);
-	q = _pgmptr;
-	sl = NULL;
-	/* copy program name, turn '\\' into '/', skip last part */
-	while ((*p = *q)) {
-		if (*q == '\\' || *q == '/') {
-			*p = '/';
-			sl = p;
-		}
-		p++, q++;
-	}
-	if (sl)
-		*sl = '\0';
-	else
-		ep[0] = '.', ep[1] = '\0';
-	return ep;
-#endif
-}
-
 const char *system_path(const char *path)
 {
 	if (!is_absolute_path(path) && argv0_path) {
@@ -75,7 +41,7 @@ const char *git_exec_path(void)
 		return env;
 	}
 
-	return builtin_exec_path();
+	return system_path(GIT_EXEC_PATH);
 }
 
 static void add_path(struct strbuf *out, const char *path)
@@ -99,7 +65,7 @@ void setup_path(void)
 
 	add_path(&new_path, argv_exec_path);
 	add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
-	add_path(&new_path, builtin_exec_path());
+	add_path(&new_path, system_path(GIT_EXEC_PATH));
 	add_path(&new_path, argv0_path);
 
 	if (old_path)
-- 
1.5.6.3.323.g1e58

[PATCH 5/5] Allow add_path() to add non-existent directories to the path

[Johannes Sixt]

This function had used make_absolute_path(); but this function dies if
the directory that contains the entry whose relative path was supplied in
the argument does not exist. This is a problem if the argument is, for
example, "../libexec/git-core", and that "../libexec" does not exist.

Since the resolution of symbolic links is not required for elements in
PATH, we can fall back to using make_nonrelative_path(), which simply
prepends $PWD to the path.

We have to move make_nonrelative_path() alongside make_absolute_path() in
abspath.c so that git-shell can be linked. See 5b8e6f85f.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 abspath.c  |   36 ++++++++++++++++++++++++++++++++++++
 exec_cmd.c |    2 +-
 path.c     |   36 ------------------------------------
 3 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/abspath.c b/abspath.c
index 4f95a95..0d56124 100644
--- a/abspath.c
+++ b/abspath.c
@@ -66,3 +66,39 @@ const char *make_absolute_path(const char *path)
 
 	return buf;
 }
+
+static const char *get_pwd_cwd(void)
+{
+	static char cwd[PATH_MAX + 1];
+	char *pwd;
+	struct stat cwd_stat, pwd_stat;
+	if (getcwd(cwd, PATH_MAX) == NULL)
+		return NULL;
+	pwd = getenv("PWD");
+	if (pwd && strcmp(pwd, cwd)) {
+		stat(cwd, &cwd_stat);
+		if (!stat(pwd, &pwd_stat) &&
+		    pwd_stat.st_dev == cwd_stat.st_dev &&
+		    pwd_stat.st_ino == cwd_stat.st_ino) {
+			strlcpy(cwd, pwd, PATH_MAX);
+		}
+	}
+	return cwd;
+}
+
+const char *make_nonrelative_path(const char *path)
+{
+	static char buf[PATH_MAX + 1];
+
+	if (is_absolute_path(path)) {
+		if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
+			die("Too long path: %.*s", 60, path);
+	} else {
+		const char *cwd = get_pwd_cwd();
+		if (!cwd)
+			die("Cannot determine the current working directory");
+		if (snprintf(buf, PATH_MAX, "%s/%s", cwd, path) >= PATH_MAX)
+			die("Too long path: %.*s", 60, path);
+	}
+	return buf;
+}
diff --git a/exec_cmd.c b/exec_cmd.c
index c236034..0ed768d 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -50,7 +50,7 @@ static void add_path(struct strbuf *out, const char *path)
 		if (is_absolute_path(path))
 			strbuf_addstr(out, path);
 		else
-			strbuf_addstr(out, make_absolute_path(path));
+			strbuf_addstr(out, make_nonrelative_path(path));
 
 		strbuf_addch(out, PATH_SEP);
 	}
diff --git a/path.c b/path.c
index 504eae0..9df447b 100644
--- a/path.c
+++ b/path.c
@@ -291,42 +291,6 @@ int adjust_shared_perm(const char *path)
 	return 0;
 }
 
-static const char *get_pwd_cwd(void)
-{
-	static char cwd[PATH_MAX + 1];
-	char *pwd;
-	struct stat cwd_stat, pwd_stat;
-	if (getcwd(cwd, PATH_MAX) == NULL)
-		return NULL;
-	pwd = getenv("PWD");
-	if (pwd && strcmp(pwd, cwd)) {
-		stat(cwd, &cwd_stat);
-		if (!stat(pwd, &pwd_stat) &&
-		    pwd_stat.st_dev == cwd_stat.st_dev &&
-		    pwd_stat.st_ino == cwd_stat.st_ino) {
-			strlcpy(cwd, pwd, PATH_MAX);
-		}
-	}
-	return cwd;
-}
-
-const char *make_nonrelative_path(const char *path)
-{
-	static char buf[PATH_MAX + 1];
-
-	if (is_absolute_path(path)) {
-		if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX)
-			die ("Too long path: %.*s", 60, path);
-	} else {
-		const char *cwd = get_pwd_cwd();
-		if (!cwd)
-			die("Cannot determine the current working directory");
-		if (snprintf(buf, PATH_MAX, "%s/%s", cwd, path) >= PATH_MAX)
-			die ("Too long path: %.*s", 60, path);
-	}
-	return buf;
-}
-
 const char *make_relative_path(const char *abs, const char *base)
 {
 	static char buf[PATH_MAX + 1];
-- 
1.5.6.3.323.g1e58

Re: [PATCH 0/5] replacement for the part of js/more-win that is in pu

[Johannes Sixt]

Johannes Sixt schrieb:
> The interdiff to js/more-win is below. It is mostly the changes
> of 1/5.
> 
> Johannes Sixt (5):
>       Makefile: Normalize $(bindir) and $(gitexecdir) before comparing
>       Record the command invocation path early
>       Fix relative built-in paths to be relative to the command
>          invocation
>       Allow the built-in exec path to be relative to the command
>          invocation path
>       Allow add_path() to add non-existent directories to the path

I retract this series and also the earlier version (the part that is in pu).

If I had done due diligence, I could have found out earlier that it does
not solve the problem it tried to solve. Appologies for the noise. :-(

The series tries to derive the exec-path from argv[0] (if the built-in
path is relative). But if a command is invoked from CMD on Windows,
argv[0] doesn't have a path, there is only the program name, "git.exe". In
the past, we relied on the global variable _pgmptr (only Windows's C
runtime has this), which does contain the full path, and if we set

   gitexecdir = $(bindir)

in the Makefile, then we get a working git.exe, but we put back all
commands into $PATH.

-- Hannes

Re: [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path()

[Johannes Sixt]

Zitat von Steffen Prohaska <prohaska@zib.de>:
>
> On Jul 4, 2008, at 2:35 PM, Johannes Schindelin wrote:
>
> > On Fri, 4 Jul 2008, Junio C Hamano wrote:
> >
> >> Could you check if there are copy-and-pasted duplicated code you can
> >> factor out before continuing this direction?
> >
> > Note also that Hannes tried very hard to get rid of those ugly "#ifdef
> > __MINGW32__"s by declaring/overriding functions in git-compat-util.h.
> >
> > I think that is such a good practice that we should not stop here.
>
> I'll send three patches that address Junio's and Dscho's comments:
>
>   [PATCH 1/3] Move code interpreting path relative to exec-dir to new
> function system_path()
>   [PATCH 2/3] help.c: Add support for htmldir relative to
> git_exec_path()
>   [PATCH 3/3] help (Windows): Display HTML in default browser using
> Windows' shell API
>
>
> Hannes,
> the patches I'll send probably conflict with your planned work on
> GIT_EXEC_PATH that has been discussed on the msysgit list.  I think
> you could built on my series and modify system_path().

Thanks. I haven't done a lot in that direction, yet, so your patches will be
helpful.

But according to the conclusion of our recent discussion

http://thread.gmane.org/gmane.comp.version-control.msysgit/2633/focus=2669

I shall modify system_path() to construct paths relative to the git executable,
which is essentially Makefile's $(bindir), not git_exec_path().

-- Hannes

Re: [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds.

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> From: Marius Storm-Olsen <mstormo_git@storm-olsen.com>
>
> SIGPIPE isn't supported in MinGW.

Shouldn't #ifdef be on SIGPIPE not on __MINGW32__?

> @@ -100,9 +100,11 @@ int cmd_verify_tag(int argc, const char **argv, const char *prefix)
>  		i++;
>  	}
>  
> +#ifndef __MINGW32__
>  	/* sometimes the program was terminated because this signal
>  	 * was received in the process of writing the gpg input: */
>  	signal(SIGPIPE, SIG_IGN);
> +#endif	

Re: [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds.

[Marius Storm-Olsen]

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

Junio C Hamano said the following on 02.07.2008 11:22:
> Steffen Prohaska <prohaska@zib.de> writes:
> 
>> From: Marius Storm-Olsen <mstormo_git@storm-olsen.com>
>>
>> SIGPIPE isn't supported in MinGW.
> 
> Shouldn't #ifdef be on SIGPIPE not on __MINGW32__?

That's certainly a good suggestion. :-)

-- 
.marius [@] storm-olsen [.com]
'if you know what you're doing, it's not research'


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds.

[Steffen Prohaska]

On Jul 2, 2008, at 12:03 PM, Marius Storm-Olsen wrote:

> Junio C Hamano said the following on 02.07.2008 11:22:
>> Steffen Prohaska <prohaska@zib.de> writes:
>>> From: Marius Storm-Olsen <mstormo_git@storm-olsen.com>
>>>
>>> SIGPIPE isn't supported in MinGW.
>> Shouldn't #ifdef be on SIGPIPE not on __MINGW32__?
>
> That's certainly a good suggestion. :-)

I reverted this in 4msysgit and will remove the patch from the
series.

	Steffen

Re: [msysGit] [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures

[Johannes Sixt]

On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> On Windows, gpg outputs CR/LF signatures.  But since the tag
> messages are already stripped of the CR by stripspace(), it is
> arguably nicer to do the same for the tag signature.  Actually,
> this patch does not look for CR/LF, but strips all CRs
> from the signature.
>
> [ spr: ported code to use strbuf ]
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> ---
>  builtin-tag.c |   14 ++++++++++++++
>  1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-tag.c b/builtin-tag.c
> index e675206..77977ba 100644
> --- a/builtin-tag.c
> +++ b/builtin-tag.c
> @@ -241,6 +241,20 @@ static int do_sign(struct strbuf *buffer)
>  	if (finish_command(&gpg) || !len || len < 0)
>  		return error("gpg failed to sign the tag");
>
> +#ifdef __MINGW32__
> +	/* strip CR from the line endings */
> +	{
> +		int i, j;
> +		for (i = j = 0; i < buffer->len; i++)
> +			if (buffer->buf[i] != '\r') {
> +				if (i != j)
> +					buffer->buf[j] = buffer->buf[i];
> +				j++;
> +			}
> +		strbuf_setlen(buffer, j);
> +	}
> +#endif
> +
>  	return 0;
>  }

Do we need the #ifdef __MINGW32__? Can't we just strip CRs unconditionally? It 
shouldn't hurt on Unix anyway.

-- Hannes

Re: [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures

[Johannes Schindelin]

Hi,

On Wed, 2 Jul 2008, Johannes Sixt wrote:

> On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > On Windows, gpg outputs CR/LF signatures.  But since the tag
> > messages are already stripped of the CR by stripspace(), it is
> > arguably nicer to do the same for the tag signature.  Actually,
> > this patch does not look for CR/LF, but strips all CRs
> > from the signature.
> >
> > [ spr: ported code to use strbuf ]
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> > ---
> >  builtin-tag.c |   14 ++++++++++++++
> >  1 files changed, 14 insertions(+), 0 deletions(-)
> >
> > diff --git a/builtin-tag.c b/builtin-tag.c
> > index e675206..77977ba 100644
> > --- a/builtin-tag.c
> > +++ b/builtin-tag.c
> > @@ -241,6 +241,20 @@ static int do_sign(struct strbuf *buffer)
> >  	if (finish_command(&gpg) || !len || len < 0)
> >  		return error("gpg failed to sign the tag");
> >
> > +#ifdef __MINGW32__
> > +	/* strip CR from the line endings */
> > +	{
> > +		int i, j;
> > +		for (i = j = 0; i < buffer->len; i++)
> > +			if (buffer->buf[i] != '\r') {
> > +				if (i != j)
> > +					buffer->buf[j] = buffer->buf[i];
> > +				j++;
> > +			}
> > +		strbuf_setlen(buffer, j);
> > +	}
> > +#endif
> > +
> >  	return 0;
> >  }
> 
> Do we need the #ifdef __MINGW32__? Can't we just strip CRs unconditionally? It 
> shouldn't hurt on Unix anyway.

I agree, and I would even like to refactor this into its own function.  
Probably even move it to strbuf.[ch].

Ciao,
Dscho

[PATCH] Convert CR/LF to LF in tag signatures

[Steffen Prohaska]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

On Windows, gpg outputs CR/LF signatures.  But since the tag messages
are already stripped of the CR by stripspace(), it is arguably nicer
to do the same for the tag signature.  Actually, this patch does not
look for CR/LF, but strips all CRs from the signature.  It does so not
only on Windows but on all platforms to keep the code simpler.

[ spr: ported code to use strbuf ]

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 builtin-tag.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/builtin-tag.c b/builtin-tag.c
index 3c97c69..a70922b 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -202,6 +202,7 @@ static int do_sign(struct strbuf *buffer)
 	const char *args[4];
 	char *bracket;
 	int len;
+	int i, j;
 
 	if (!*signingkey) {
 		if (strlcpy(signingkey, git_committer_info(IDENT_ERROR_ON_NO_NAME),
@@ -241,6 +242,15 @@ static int do_sign(struct strbuf *buffer)
 	if (finish_command(&gpg) || !len || len < 0)
 		return error("gpg failed to sign the tag");
 
+	/* Strip CR from the line endings, in case we are on Windows. */
+	for (i = j = 0; i < buffer->len; i++)
+		if (buffer->buf[i] != '\r') {
+			if (i != j)
+				buffer->buf[j] = buffer->buf[i];
+			j++;
+		}
+	strbuf_setlen(buffer, j);
+
 	return 0;
 }
 
-- 
1.5.6.1.282.gd8a0d

Re: [PATCH 02/12] Do not complain about "no common commits" in an empty repo

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> If the repo is empty, we know that already, thank you very much.
> So shut fetch-pack up about that case.

Two complaints.

 * What does this have to do with Windows port?  Please don't hide a
   general interface change in a larger and mostly unrelated topic.

 * Do you think people can tell without reading the code in larger context
   outside the patch and this commit log text if you are talking about the
   case you fetch _into_ an empty repository, or if you are attempting to
   fetch _from_ an empty repository, or what?  Please try to be a bit
   easier for _readers_.  Being more redundant and verbose is better than
   being too concise.

About the first point, "no common commits" is just a friendly reminder and
not even an error.  When you see it, you will learn to expect looooooooong
download session.

I personally happen to agree with the logic of this patch, though --- if
you are fetching into an empty repository, you would already expect that
the download is as big as the other end anyway, so you would not need to
be further reminded about that.

But that is just one-man's opinion.  Maybe somebody knows a reason why I
am (and the logic I am agreeing with is) wrong.  Maybe not.  So make the
"remainder of Windows port" series 11 commits, and send this as a general
interface fix via the normal channel to be discussed, please.

Re: [PATCH 02/12] Do not complain about "no common commits" in an empty repo

[Steffen Prohaska]

On Jul 2, 2008, at 10:58 AM, Junio C Hamano wrote:

> Steffen Prohaska <prohaska@zib.de> writes:
>
>> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>>
>> If the repo is empty, we know that already, thank you very much.
>> So shut fetch-pack up about that case.
>
> Two complaints.

You are right, although I didn't intend to "hide" the patch.  I just
went through the differences between the mainline and 4msysgit and
collected a patch series with all changes I found.  I sent this series
to the list, so that the remaining differences do not get lost
unrecognized.

I didn't mean to bother you with incomplete patches.  Maybe I should
have made my intention clearer by prefixing the subject lines with
WIP (or something similar).  Apologies.


> * What does this have to do with Windows port?  Please don't hide a
>   general interface change in a larger and mostly unrelated topic.

I remember that users of msysgit's net installer complaint about this
warning.  The warning appeared as part of the output of a sequence of
automatically executed commands.  Without context, the users did not
understand what the warning means.


> * Do you think people can tell without reading the code in larger  
> context
>   outside the patch and this commit log text if you are talking  
> about the
>   case you fetch _into_ an empty repository, or if you are  
> attempting to
>   fetch _from_ an empty repository, or what?  Please try to be a bit
>   easier for _readers_.  Being more redundant and verbose is better  
> than
>   being too concise.
>
> About the first point, "no common commits" is just a friendly  
> reminder and
> not even an error.  When you see it, you will learn to expect  
> looooooooong
> download session.
>
> I personally happen to agree with the logic of this patch, though  
> --- if
> you are fetching into an empty repository, you would already expect  
> that
> the download is as big as the other end anyway, so you would not  
> need to
> be further reminded about that.
>
> But that is just one-man's opinion.  Maybe somebody knows a reason  
> why I
> am (and the logic I am agreeing with is) wrong.  Maybe not.  So make  
> the
> "remainder of Windows port" series 11 commits, and send this as a  
> general
> interface fix via the normal channel to be discussed, please.


Dscho, will you send it?  You are the original author.
	
	Steffen

Re: [PATCH 02/12] Do not complain about "no common commits" in an empty repo

[Johannes Schindelin]

Hi,

On Wed, 2 Jul 2008, Steffen Prohaska wrote:

> Dscho, will you send it?  You are the original author.

Done,
Dscho

Re: [PATCH 01/12] Fake reencoding success under NO_ICONV instead of returning NULL.

[Johannes Sixt]

On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
> From: Johannes Sixt <johannes.sixt@telecom.at>
>
> git-am when invoked from git-rebase seems to rely on successful conversion.

> diff --git a/utf8.h b/utf8.h
> index 98cce1b..f22ef31 100644
> --- a/utf8.h
> +++ b/utf8.h
> @@ -10,10 +10,6 @@ int is_encoding_utf8(const char *name);
>
>  int print_wrapped_text(const char *text, int indent, int indent2, int
> len);
>
> -#ifndef NO_ICONV
>  char *reencode_string(const char *in, const char *out_encoding, const char
> *in_encoding); -#else
> -#define reencode_string(a,b,c) NULL
> -#endif
>
>  #endif

I don't think that this is still needed. It dates back to the origins of 
mingw.git, at which time I did not have a working libiconv.

-- Hannes

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

[Kristian Høgsberg]

On Mon, 2008-06-30 at 02:08 -0700, Junio C Hamano wrote:
> Here are the topics that have been cooking.  Commits prefixed
> with '-' are only in 'pu' while commits prefixed with '+' are
> in 'next'.
> 
> The topics list the commits in reverse chronological order.  The topics
> meant to be applied to the maintenance series have "maint-" in their
> names.
> 
> It already is beginning to become clear what 1.6.0 will look like.  What's
> already in 'next' all are well intentioned (I do not guarantee they are
> already bug-free --- that is what cooking them in 'next' is for) and are
> good set of feature enhancements.  Bigger changes will be:
> 
>  * MinGW will be in.
> 
>  * With the default Makefile settings, most of the programs will be
>    installed outside your $PATH, except for "git", "gitk", "git-gui" and
>    some server side programs that need to be accessible for technical
>    reasons.  Invoking a git subcommand as "git-xyzzy" from the command
>    line has been deprecated since early 2006 (and officially announced in
>    1.5.4 release notes); use of them from your scripts after adding
>    output from "git --exec-path" to the $PATH will still be supported in
>    1.6.0, but users are again strongly encouraged to adjust their
>    scripts to use "git xyzzy" form, as we will stop installing
>    "git-xyzzy" hardlinks for built-in commands in later releases.
> 
>  * git-merge will be rewritten in C.
> 
>  * default pack and idx versions will be updated as scheduled for some
>    time ago.

A small detail I've suggested scheduling for 1.6 before is removing (or
rather, stop creating) the empty .git/branches directory.  How does that
sound?

cheers,
Kristian

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

[Jakub Narebski]

Kristian Høgsberg <krh@redhat.com> writes:

> 
> A small detail I've suggested scheduling for 1.6 before is removing (or
> rather, stop creating) the empty .git/branches directory.  How does that
> sound?

Perhaps also stop creating .git/description (remove
'templates/this--description' file), now that it is mentioned in
gitweb/README and/or gitweb/INSTALL?

(Do you want a patch?)
-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Kristian Høgsberg <krh@redhat.com> writes:
>
>> 
>> A small detail I've suggested scheduling for 1.6 before is removing (or
>> rather, stop creating) the empty .git/branches directory.  How does that
>> sound?
>
> Perhaps also stop creating .git/description (remove
> 'templates/this--description' file), now that it is mentioned in
> gitweb/README and/or gitweb/INSTALL?
>
> (Do you want a patch?)

Not yet.  I would first like to see a justification that makes sense.

I do not see much connection between your mentioning the file in README
and the file's removal.  You currently say "By default it is set to ..."
and you would have to change it to "By default it does not exist so you
have to create one".  Does it have much difference?  Either way the user
needs to open the file with the editor and edit it, and the current file
at least says "Please edit me".  I am not sure if removal is an
improvement.

The sample templates/hooks--update.sample seems to check if the contents
of the description file makes sense, without even checking if it exists.
That also needs to be updated.

Actually, the sample hook should be updated independent of this issue.
I'd suggest to simply remove the check from the sample hook.  Setting
description and installing the hook is part of the initial public
repository deployment task, and once the description is set, the hook does
not have to check it over and over again.  Allowing arrival of new commits
while the description is not set won't hurt anything (somebody would
notice and tell "please set a better description" to the repository owner,
and doing so at that point will fix things without anybody having to redo
any old pushes), and forbidding push from the hook for lack of description
does not make any sense.

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

[Junio C Hamano]

Kristian Høgsberg <krh@redhat.com> writes:

> On Mon, 2008-06-30 at 02:08 -0700, Junio C Hamano wrote:
> ...
>> It already is beginning to become clear what 1.6.0 will look like.  What's
>> already in 'next' all are well intentioned (I do not guarantee they are
>> already bug-free --- that is what cooking them in 'next' is for) and are
>> good set of feature enhancements.  Bigger changes will be:
> ...
> A small detail I've suggested scheduling for 1.6 before is removing (or
> rather, stop creating) the empty .git/branches directory.  How does that
> sound?

What's the benefit of the removal that outweighs the downside?  I can
imagine two contradicting voices from new end users.

 (1) With current git, I ran "git init" and I have an empty
     .git/branches/, but my remote information created with "git clone"
     and "git remote add" all go to .git/config these days.  Why do I have
     to have this empty directory that I do not use?

 (2) It is documented that "git fetch" can use files in .git/branches/ as
     the source specification, but when I ran "git init", it does not
     create the directory with Kristian's git. I need to do an extra
     "mkdir .git/branches/" myself.  Why?

You are obviously coming from the former camp, but do you have a good
answer to people from the other camp?

I do not recall if Cogito required to have .git/branches created by us or
it can create it on demand if we don't.  If the latter, that would be
great, otherwise remaining users would be in the latter camp as well, and
we may have to make sure Cogito is really dead already (or wait for it to
die), or Cogito gets updated for its remaining users to tolerate the
initial lack of the directory (and wait for that version percolates down
to the users).

Some people rely on (or at least "like") the convenience of being able to
create a single-liner file in .git/branches/ to easily add, and remove
such a file to easily remove where they integrate from.  This is
especially so when they have dozens of source repositories to fetch from.
I do not think we want to remove support for .git/branches as a way to
specify fetch sources (this is why I am CC'ing Andrew who I know uses
branches, and Stephen who is also a heavy integrator even though I do not
know if he is in branches camp or uses more modern style), but they now
have to do an extra "mkdir .git/branches" after "git init" to continue
their workflow if we adopt the change you are proposing here.  It is not a
big deal, but it still is a backward incompatible change.

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

[Andrew Morton]

On Mon, 30 Jun 2008 15:15:52 -0700
Junio C Hamano <gitster@pobox.com> wrote:

> Some people rely on (or at least "like") the convenience of being able to
> create a single-liner file in .git/branches/ to easily add, and remove
> such a file to easily remove where they integrate from.  This is
> especially so when they have dozens of source repositories to fetch from.
> I do not think we want to remove support for .git/branches as a way to
> specify fetch sources (this is why I am CC'ing Andrew who I know uses
> branches, and Stephen who is also a heavy integrator even though I do not
> know if he is in branches camp or uses more modern style), but they now
> have to do an extra "mkdir .git/branches" after "git init" to continue
> their workflow if we adopt the change you are proposing here.  It is not a
> big deal, but it still is a backward incompatible change.

I do find the more compact format of .git/branches/git-foo to be
convenient.  For example, my scripts go looking in there for the URL
and add that to the patch changelog so that people can reconstruct -mm's
git-foo.patch from the relevant git tree.

That being said,

- It wouldn't bother me to have to type `mkdir .git/branches' after
  `git init'!

- It's bad to have the same info in two places, and to have to
  support two different ways of doing the same thing for ever.  So I
  could understand a wish to remove .git/branches/ support completely. 
  I'll cope :)

  For me the biggest part of migrating would be working out what on
  earth the format of the new files is.  Maybe it's documented
  somewhere undiscoverable, dunno.

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

[Johannes Schindelin]

Hi,

On Mon, 30 Jun 2008, Andrew Morton wrote:

> - It's bad to have the same info in two places, and to have to
>   support two different ways of doing the same thing for ever.

It is actually worse: we have three places.

>   For me the biggest part of migrating would be working out what on
>   earth the format of the new files is.  Maybe it's documented
>   somewhere undiscoverable, dunno.

The easiest way is to

	git config remote.$NICKNAME.url $URL

where you said

	echo $URL > .git/branches/$NICKNAME

Actually, you might even like this command better:

	git remote add $NICKNAME $URL

Many ways to go to Rome,
Dscho

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

[Petr Baudis]

On Mon, Jun 30, 2008 at 03:15:52PM -0700, Junio C Hamano wrote:
> I do not recall if Cogito required to have .git/branches created by us or
> it can create it on demand if we don't.  If the latter, that would be
> great, otherwise remaining users would be in the latter camp as well, and
> we may have to make sure Cogito is really dead already (or wait for it to
> die), or Cogito gets updated for its remaining users to tolerate the
> initial lack of the directory (and wait for that version percolates down
> to the users).

Cogito is getting somewhat broken by removing of the git- plumbing from
$PATH anyway (you have to hack around it; and I'm not saying it's bad
thing).

But it is actually quite resilient against this kind of stuff (as it was
constructed to be able to run on very rudimental repositories dating
early to the dawn of time). All versions supporting .git/branches [*] will
autocreate the .git/branches directory if missing.

[*] .git/branches was actually called .git/remotes even earlier; yay,
how rich our history is. ;-)

> Some people rely on (or at least "like") the convenience of being able to
> create a single-liner file in .git/branches/ to easily add, and remove
> such a file to easily remove where they integrate from.  This is
> especially so when they have dozens of source repositories to fetch from.
> I do not think we want to remove support for .git/branches as a way to
> specify fetch sources (this is why I am CC'ing Andrew who I know uses
> branches, and Stephen who is also a heavy integrator even though I do not
> know if he is in branches camp or uses more modern style), but they now
> have to do an extra "mkdir .git/branches" after "git init" to continue
> their workflow if we adopt the change you are proposing here.  It is not a
> big deal, but it still is a backward incompatible change.

Now, I think it would be nice to keep backward compatibility here. I'm
still _regularly_ running into people who still use Cogito (and it's not
because they know me :-)) and are only now doing the switch, or only
planning to yet.

(On the other hand, using Git on repositories created by old Git
versions or Cogito can be quite a confusing experience for non-expert
users - things related to remote repositories behave differently to what
the documentation describes, obviously.  Maybe it _would_ be reasonable
option to do something radical when hitting old repository, like
"(Re-)clone me for non-confusing user experience, pretty please, or
git-config force_old_repo 1 if you know what are you doing.")

-- 
				Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson

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

[Stephen Rothwell]

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

On Mon, 30 Jun 2008 15:15:52 -0700 Junio C Hamano <gitster@pobox.com> wrote:
>
> branches, and Stephen who is also a heavy integrator even though I do not
> know if he is in branches camp or uses more modern style), but they now

I use "git remote add" for each new repository and haven't had anything
in the branches directory of any of my trees for a long time ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

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

[Kristian Høgsberg]

On Mon, 2008-06-30 at 15:15 -0700, Junio C Hamano wrote:
> Kristian Høgsberg <krh@redhat.com> writes:
> 
> > On Mon, 2008-06-30 at 02:08 -0700, Junio C Hamano wrote:
> > ...
> >> It already is beginning to become clear what 1.6.0 will look like.  What's
> >> already in 'next' all are well intentioned (I do not guarantee they are
> >> already bug-free --- that is what cooking them in 'next' is for) and are
> >> good set of feature enhancements.  Bigger changes will be:
> > ...
> > A small detail I've suggested scheduling for 1.6 before is removing (or
> > rather, stop creating) the empty .git/branches directory.  How does that
> > sound?
> 
> What's the benefit of the removal that outweighs the downside?  I can
> imagine two contradicting voices from new end users.
> 
>  (1) With current git, I ran "git init" and I have an empty
>      .git/branches/, but my remote information created with "git clone"
>      and "git remote add" all go to .git/config these days.  Why do I have
>      to have this empty directory that I do not use?

Yeah, that's one reason, my main problem with .git/branches is that for
a user that wants to learn about git and peeks into .git it's pretty
confusing.  "I wonder where and how git stores the information about
branches... oh look, .git/branches, that must it... hmm, wait no..."
Git is still getting a lot of bad-mouthing for being hard to learn and
inconsitent.  I think it makes sense to push git towards consistency and
simplicity (where is doesn't affect the flexibility) and this seemed
like a tiny step towards that.  As Dscho mentioned we have two other
ways of accomplishing what .git/branches did, so maybe it makes sense to
retire this one?

>  (2) It is documented that "git fetch" can use files in .git/branches/ as
>      the source specification, but when I ran "git init", it does not
>      create the directory with Kristian's git. I need to do an extra
>      "mkdir .git/branches/" myself.  Why?

We could just change the documentation to ask the user to create
the .git/branches directory if they want to use that feature.

> You are obviously coming from the former camp, but do you have a good
> answer to people from the other camp?
> 
> I do not recall if Cogito required to have .git/branches created by us or
> it can create it on demand if we don't.  If the latter, that would be
> great, otherwise remaining users would be in the latter camp as well, and
> we may have to make sure Cogito is really dead already (or wait for it to
> die), or Cogito gets updated for its remaining users to tolerate the
> initial lack of the directory (and wait for that version percolates down
> to the users).
> 
> Some people rely on (or at least "like") the convenience of being able to
> create a single-liner file in .git/branches/ to easily add, and remove
> such a file to easily remove where they integrate from.  This is
> especially so when they have dozens of source repositories to fetch from.
> I do not think we want to remove support for .git/branches as a way to
> specify fetch sources (this is why I am CC'ing Andrew who I know uses
> branches, and Stephen who is also a heavy integrator even though I do not
> know if he is in branches camp or uses more modern style), but they now
> have to do an extra "mkdir .git/branches" after "git init" to continue
> their workflow if we adopt the change you are proposing here.  It is not a
> big deal, but it still is a backward incompatible change.

Yeah... I have to confess, that when I suggested removing it, I was
under the impression that git didn't use .git/branches, but only created
it to be nice to cogito.  I just read the code in remote.c that deals
with .git/branches and understand that it's still used by git.  From the
feedback from Stephen, Andrew and Pasky, it looks like we can drop
the .git/branches from the template for 1.6 and maybe in the future, we
could drop the .git/branches support entirely.  Dunno.

cheers,
Kristian

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

[Jeff King]

On Mon, Jun 30, 2008 at 02:08:56AM -0700, Junio C Hamano wrote:

> * js/apply-recount (Fri Jun 27 18:43:09 2008 +0100) 1 commit
>  + Allow git-apply to recount the lines in a hunk (AKA recountdiff)
> 
> A good ingredient for implementing "apply --edit".

Thomas,

Now that this is in next, maybe it is a good time to repost the
add--interactive patch (it should be independent of Dscho's 2/2 "add -e"
patch).

-Peff

[PATCH] git-add--interactive: manual hunk editing mode

[Thomas Rast]

Adds a new option 'e' to the 'add -p' command loop that lets you edit
the current hunk in your favourite editor.

If the resulting patch applies cleanly, the edited hunk will
immediately be marked for staging. If it does not apply cleanly, you
will be given an opportunity to edit again. If all lines of the hunk
are removed, then the edit is aborted and the hunk is left unchanged.

Applying the changed hunk(s) relies on Johannes Schindelin's new
--recount option for git-apply.

Note that the "real patch" test intentionally uses
  (echo e; echo n; echo d) | git add -p
even though the 'n' and 'd' are superfluous at first sight.  They
serve to get out of the interaction loop if git add -p wrongly
concludes the patch does not apply.

Many thanks to Jeff King <peff@peff.net> for lots of help and
suggestions.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---

Jeff King wrote:
> Now that this is in next, maybe it is a good time to repost the
> add--interactive patch (it should be independent of Dscho's 2/2 "add -e"
> patch).

It is independent, so I suppose you're right.  (Dscho mentioned in
passing he might repost "add -e" himself.)

- Thomas

 Documentation/git-add.txt  |    1 +
 git-add--interactive.perl  |  124 +++++++++++++++++++++++++++++++++++++++++++-
 t/t3701-add-interactive.sh |   67 ++++++++++++++++++++++++
 3 files changed, 191 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index c6de028..1d8d209 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -246,6 +246,7 @@ patch::
        k - leave this hunk undecided, see previous undecided hunk
        K - leave this hunk undecided, see previous hunk
        s - split the current hunk into smaller hunks
+       e - manually edit the current hunk
        ? - print help
 +
 After deciding the fate for all hunks, if there is any hunk
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 903953e..6bb117a 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -2,6 +2,7 @@
 
 use strict;
 use Git;
+use File::Temp;
 
 my $repo = Git->repository();
 
@@ -18,6 +19,18 @@ my ($fraginfo_color) =
 	$diff_use_color ? (
 		$repo->get_color('color.diff.frag', 'cyan'),
 	) : ();
+my ($diff_plain_color) =
+	$diff_use_color ? (
+		$repo->get_color('color.diff.plain', ''),
+	) : ();
+my ($diff_old_color) =
+	$diff_use_color ? (
+		$repo->get_color('color.diff.old', 'red'),
+	) : ();
+my ($diff_new_color) =
+	$diff_use_color ? (
+		$repo->get_color('color.diff.new', 'green'),
+	) : ();
 
 my $normal_color = $repo->get_color("", "reset");
 
@@ -770,6 +783,104 @@ sub coalesce_overlapping_hunks {
 	return @out;
 }
 
+sub color_diff {
+	return map {
+		colored((/^@/  ? $fraginfo_color :
+			 /^\+/ ? $diff_new_color :
+			 /^-/  ? $diff_old_color :
+			 $diff_plain_color),
+			$_);
+	} @_;
+}
+
+sub edit_hunk_manually {
+	my ($oldtext) = @_;
+
+	my $t = File::Temp->new(
+		TEMPLATE => $repo->repo_path . "/git-hunk-edit.XXXXXX",
+		SUFFIX => '.diff'
+	);
+	print $t "# Manual hunk edit mode -- see bottom for a quick guide\n";
+	print $t @$oldtext;
+	print $t <<EOF;
+# ---
+# To remove '-' lines, make them ' ' lines (context).
+# To remove '+' lines, delete them.
+# Lines starting with # will be removed.
+#
+# If the patch applies cleanly, the edited hunk will immediately be
+# marked for staging. If it does not apply cleanly, you will be given
+# an opportunity to edit again. If all lines of the hunk are removed,
+# then the edit is aborted and the hunk is left unchanged.
+EOF
+	close $t;
+
+	my $editor = $ENV{GIT_EDITOR} || $repo->config("core.editor")
+		|| $ENV{VISUAL} || $ENV{EDITOR} || "vi";
+	system('sh', '-c', $editor.' "$@"', $editor, $t);
+
+	open my $fh, '<', $t
+		or die "failed to open hunk edit file for reading: " . $!;
+	my @newtext = grep { !/^#/ } <$fh>;
+	close $fh;
+
+	# Abort if nothing remains
+	if (!grep { /\S/ } @newtext) {
+		return undef;
+	}
+
+	# Reinsert the first hunk header if the user accidentally deleted it
+	if ($newtext[0] !~ /^@/) {
+		unshift @newtext, $oldtext->[0];
+	}
+	return \@newtext;
+}
+
+sub diff_applies {
+	my $fh;
+	open $fh, '| git apply --recount --cached --check';
+	for my $h (@_) {
+		print $fh @{$h->{TEXT}};
+	}
+	return close $fh;
+}
+
+sub prompt_yesno {
+	my ($prompt) = @_;
+	while (1) {
+		print colored $prompt_color, $prompt;
+		my $line = <STDIN>;
+		return 0 if $line =~ /^n/i;
+		return 1 if $line =~ /^y/i;
+	}
+}
+
+sub edit_hunk_loop {
+	my ($head, $hunk, $ix) = @_;
+	my $text = $hunk->[$ix]->{TEXT};
+
+	while (1) {
+		$text = edit_hunk_manually($text);
+		if (!defined $text) {
+			return undef;
+		}
+		my $newhunk = { TEXT => $text, USE => 1 };
+		if (diff_applies($head,
+				 @{$hunk}[0..$ix-1],
+				 $newhunk,
+				 @{$hunk}[$ix+1..$#{$hunk}])) {
+			$newhunk->{DISPLAY} = [color_diff(@{$text})];
+			return $newhunk;
+		}
+		else {
+			prompt_yesno(
+				'Your edited hunk does not apply. Edit again '
+				. '(saying "no" discards!) [y/n]? '
+				) or return undef;
+		}
+	}
+}
+
 sub help_patch_cmd {
 	print colored $help_color, <<\EOF ;
 y - stage this hunk
@@ -781,6 +892,7 @@ J - leave this hunk undecided, see next hunk
 k - leave this hunk undecided, see previous undecided hunk
 K - leave this hunk undecided, see previous hunk
 s - split the current hunk into smaller hunks
+e - manually edit the current hunk
 ? - print help
 EOF
 }
@@ -846,6 +958,7 @@ sub patch_update_file {
 
 	$num = scalar @hunk;
 	$ix = 0;
+	my $need_recount = 0;
 
 	while (1) {
 		my ($prev, $next, $other, $undecided, $i);
@@ -885,6 +998,7 @@ sub patch_update_file {
 		if (hunk_splittable($hunk[$ix]{TEXT})) {
 			$other .= '/s';
 		}
+		$other .= '/e';
 		for (@{$hunk[$ix]{DISPLAY}}) {
 			print;
 		}
@@ -949,6 +1063,13 @@ sub patch_update_file {
 				$num = scalar @hunk;
 				next;
 			}
+			elsif ($line =~ /^e/) {
+				my $newhunk = edit_hunk_loop($head, \@hunk, $ix);
+				if (defined $newhunk) {
+					splice @hunk, $ix, 1, $newhunk;
+					$need_recount = 1;
+				}
+			}
 			else {
 				help_patch_cmd($other);
 				next;
@@ -1002,7 +1123,8 @@ sub patch_update_file {
 	if (@result) {
 		my $fh;
 
-		open $fh, '| git apply --cached';
+		open $fh, '| git apply --cached'
+			. ($need_recount ? ' --recount' : '');
 		for (@{$head->{TEXT}}, @result) {
 			print $fh $_;
 		}
diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
index fae64ea..e95663d 100755
--- a/t/t3701-add-interactive.sh
+++ b/t/t3701-add-interactive.sh
@@ -66,6 +66,73 @@ test_expect_success 'revert works (commit)' '
 	grep "unchanged *+3/-0 file" output
 '
 
+cat >expected <<EOF
+EOF
+cat >fake_editor.sh <<EOF
+EOF
+chmod a+x fake_editor.sh
+test_set_editor "$(pwd)/fake_editor.sh"
+test_expect_success 'dummy edit works' '
+	(echo e; echo a) | git add -p &&
+	git diff > diff &&
+	test_cmp expected diff
+'
+
+cat >patch <<EOF
+@@ -1,1 +1,4 @@
+ this
++patch
+-doesn't
+ apply
+EOF
+echo "#!$SHELL_PATH" >fake_editor.sh
+cat >>fake_editor.sh <<\EOF
+mv -f "$1" oldpatch &&
+mv -f patch "$1"
+EOF
+chmod a+x fake_editor.sh
+test_set_editor "$(pwd)/fake_editor.sh"
+test_expect_success 'bad edit rejected' '
+	git reset &&
+	(echo e; echo n; echo d) | git add -p >output &&
+	grep "hunk does not apply" output
+'
+
+cat >patch <<EOF
+this patch
+is garbage
+EOF
+test_expect_success 'garbage edit rejected' '
+	git reset &&
+	(echo e; echo n; echo d) | git add -p >output &&
+	grep "hunk does not apply" output
+'
+
+cat >patch <<EOF
+@@ -1,0 +1,0 @@
+ baseline
++content
++newcontent
++lines
+EOF
+cat >expected <<EOF
+diff --git a/file b/file
+index b5dd6c9..f910ae9 100644
+--- a/file
++++ b/file
+@@ -1,4 +1,4 @@
+ baseline
+ content
+-newcontent
++more
+ lines
+EOF
+test_expect_success 'real edit works' '
+	(echo e; echo n; echo d) | git add -p &&
+	git diff >output &&
+	test_cmp expected output
+'
+
 if test "$(git config --bool core.filemode)" = false
 then
     say 'skipping filemode tests (filesystem does not properly support modes)'
-- 
1.5.4.5

Re: [PATCH] git-add--interactive: manual hunk editing mode

[Johannes Schindelin]

Hi,

On Tue, 1 Jul 2008, Thomas Rast wrote:

> (Dscho mentioned in passing he might repost "add -e" himself.)

He will not :-)

Ciao,
Dscho

Re: [PATCH] git-add--interactive: manual hunk editing mode

[Junio C Hamano]

Thomas Rast <trast@student.ethz.ch> writes:

> Jeff King wrote:
>> Now that this is in next, maybe it is a good time to repost the
>> add--interactive patch (it should be independent of Dscho's 2/2 "add -e"
>> patch).
>
> It is independent, so I suppose you're right.  (Dscho mentioned in
> passing he might repost "add -e" himself.)

Thanks, both.

Re: [PATCH] git-add--interactive: manual hunk editing mode

[Junio C Hamano]

Thomas Rast <trast@student.ethz.ch> writes:

> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index 903953e..6bb117a 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -2,6 +2,7 @@
>  
>  use strict;
>  use Git;
> +use File::Temp;

People with minimum Perl installation should still be able to use "add -i"
as long as they do not use 'e' subcommand, shouldn't they?  Shouldn't we
do something like:

	my $can_use_temp = eval {
        	require File::Temp;
                1;
	};

and disable 'e' subcommand unless $can_use_temp?

> +sub edit_hunk_manually {
> +	my ($oldtext) = @_;
> +
> +	my $t = File::Temp->new(
> +		TEMPLATE => $repo->repo_path . "/git-hunk-edit.XXXXXX",
> +		SUFFIX => '.diff'
> +	);
> +	print $t "# Manual hunk edit mode -- see bottom for a quick guide\n";
> +	print $t @$oldtext;
> +	print $t <<EOF;
> +# ---
> +# To remove '-' lines, make them ' ' lines (context).
> +# To remove '+' lines, delete them.
> +# Lines starting with # will be removed.

Don't you want to say "Do not touch lines that begin with ' '"?

> +	# Reinsert the first hunk header if the user accidentally deleted it
> +	if ($newtext[0] !~ /^@/) {
> +		unshift @newtext, $oldtext->[0];
> +	}

Hmm, perhaps not even giving the "@@ ... @@" lines to the editor would be
a more robust solution?

> +sub diff_applies {
> +	my $fh;
> +	open $fh, '| git apply --recount --cached --check';
> +	for my $h (@_) {
> +		print $fh @{$h->{TEXT}};
> +	}
> +	return close $fh;

Have to wonder where the potential error message would go, and if it would
confuse the end users...

> @@ -1002,7 +1123,8 @@ sub patch_update_file {
>  	if (@result) {
>  		my $fh;
>  
> -		open $fh, '| git apply --cached';
> +		open $fh, '| git apply --cached'
> +			. ($need_recount ? ' --recount' : '');
>  		for (@{$head->{TEXT}}, @result) {
>  			print $fh $_;
>  		}

I recall that the original "add--interactive" carefully counted numbers in
hunks it reassembles (as it can let you split and then you can choose to
use both parts, which requires it to merge overlapping hunks back), but if
you are going to use --recount anyway, perhaps we can discard that logic?
It may make the patch application less robust, though.  I dunno.

An alternative, and probably more robust, approach would be to recount
what we have in @{$mode->{TEXT}}, after letting the user edit some of
them, so that "add--interactive" still knows what it is doing after
applying your patch without having to rely on "apply --recount".

Re: [PATCH] git-add--interactive: manual hunk editing mode

[Thomas Rast]

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

Junio C Hamano wrote:
> 
> People with minimum Perl installation should still be able to use "add -i"
> as long as they do not use 'e' subcommand, shouldn't they?  Shouldn't we
> do something like:
[...]
> and disable 'e' subcommand unless $can_use_temp?

I can just call the temporary editing file something constant, like
the commit message already is.  I don't care much about that point,
and honestly assumed File::Temp came with every Perl (it's in
perl-base here).

> > +# To remove '-' lines, make them ' ' lines (context).
> > +# To remove '+' lines, delete them.
> > +# Lines starting with # will be removed.
> 
> Don't you want to say "Do not touch lines that begin with ' '"?

Why?  You can make them '-' instead if you really want to :-)

> > +	# Reinsert the first hunk header if the user accidentally deleted it
> 
> Hmm, perhaps not even giving the "@@ ... @@" lines to the editor would be
> a more robust solution?

I originally left it there because Emacs automatically recounts the
header, and it also reminds the user of the function the hunk applies
to.

> > +	open $fh, '| git apply --recount --cached --check';
> 
> Have to wonder where the potential error message would go, and if it would
> confuse the end users...

To the terminal.  If we eat that error message, the user gets
absolutely no indication as to _what_ might be wrong with the edited
patch, so I kind of deliberately left it there.

Then again the message from git-apply is not exactly transparent
either.

> I recall that the original "add--interactive" carefully counted numbers in
> hunks it reassembles (as it can let you split and then you can choose to
> use both parts, which requires it to merge overlapping hunks back), but if
> you are going to use --recount anyway, perhaps we can discard that logic?

We briefly talked about that[1], but Jeff thought it should be a
separate patch, and I agree.  Can't sneakily rip out two dozen lines
of otherwise unrelated code in my feature patch, can I?

> It may make the patch application less robust, though.  I dunno.

I've become convinced it can't, apart from making it less likely to
trip over bugs in the script itself of course.

> An alternative, and probably more robust, approach would be to recount
> what we have in @{$mode->{TEXT}}, after letting the user edit some of
> them, so that "add--interactive" still knows what it is doing after
> applying your patch without having to rely on "apply --recount".

You lost me here.  Why recount the mode part?

If you mean the _hunk_ headers, that's what the first three versions
of this patch did, at the expense of a lot of code complication (and
now that git-apply implements --recount, actually _duplication_).

- Thomas


[1] http://article.gmane.org/gmane.comp.version-control.git/84698

-- 
Thomas Rast
trast@student.ethz.ch


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] git-add--interactive: manual hunk editing mode

[Junio C Hamano]

Thomas Rast <trast@student.ethz.ch> writes:

> Junio C Hamano wrote:
> ...
>> > +# To remove '-' lines, make them ' ' lines (context).
>> > +# To remove '+' lines, delete them.
>> > +# Lines starting with # will be removed.
>> 
>> Don't you want to say "Do not touch lines that begin with ' '"?
>
> Why?  You can make them '-' instead if you really want to :-)

If you change '-' to ' ', or remove '+', then you are temporarily
reverting the change you have made since HEAD to your working tree copy.
If you do not change anything, you are taking something that was in your
working tree copy.  Both are simpler and easier to explain operations.

Once you allow changing ' ' to '-' or insert '+' at random places,
however, you are letting the user commit lines that is neither from HEAD
nor from the working tree.

If the goal of "e" action in "add -i" is to support that operation (I am
not saying that it is a bad thing to support), you have to deal with an
issue that your patch so far did not have to deal with, and it would
require a much larger change to the way how "add -i" is structured.

When you give the user a hunk like this to edit:

  @@ -4,9 +4,6 @@ GIT v1.6.0 Release Notes
   User visible changes
   --------------------

  -[[Note that none of these are not merged to 'master' as of this writing
  -but they will be before 1.6.0 happens]]
  -
   With the default Makefile settings, most of the programs are now
   installed outside your $PATH, except for "git", "gitk", "git-gui" and
   some server side programs that need to be accessible for technical

the user may want to change the line before the line that has "User
visible changes", or the lines toward the end of the hunk. The user may
want to edit the line that ends with "for technical" for rewording the
sentence, but the rest of the sentence is outside the context, and these
lines somehow needs to be summoned to the editing session for completing
the updated sentence.  In order to support that, you need to be able to
extend the context on demand in either direction, beyond the original "git
diff" output you captured in $hunk[$i]{TEXT} (sorry, I misspelled this as
$mode->{TEXT} in the previous message).

Once you start to do that, you would need to worry about the case where
the hunk extended to include later lines overlaps with the hunk after the
one we are currently looking at, and run coalesce_overlapping_hunks to
concatenate them into a larger single hunk.  But to be able to do that,
you would need to keep track of the number of lines in a hunk yourself
anyway, which would mean that you cannot rely on --recount anymore.  The
extension recently made to "git apply" becomes redundant and unused code.

In short, declaring that you are supporting the use to change ' ' to '-'
means you are opening a whole can of worms, and I asked the question
because I did not know if you are really prepared to deal with it.

Re: [PATCH] git-add--interactive: manual hunk editing mode

[Jeff King]

On Tue, Jul 01, 2008 at 10:39:58PM -0700, Junio C Hamano wrote:

> > +use File::Temp;
> 
> People with minimum Perl installation should still be able to use "add -i"
> as long as they do not use 'e' subcommand, shouldn't they?  Shouldn't we
> do something like:
> 
> 	my $can_use_temp = eval {
>         	require File::Temp;
>                 1;
> 	};
> 
> and disable 'e' subcommand unless $can_use_temp?

According to Module::CoreList, File::Temp has shipped as part of core
perl since 5.006001. "add -i" doesn't work with perl < 5.6 already due to
things like 3-argument open.

So if the problem is "old perl", I don't think it is an issue. Are there
modern perl installations in the wild that don't have File::Temp?

-Peff

Re: [PATCH] git-add--interactive: manual hunk editing mode

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> According to Module::CoreList, File::Temp has shipped as part of core
> perl since 5.006001. "add -i" doesn't work with perl < 5.6 already due to
> things like 3-argument open.
>
> So if the problem is "old perl", I don't think it is an issue. Are there
> modern perl installations in the wild that don't have File::Temp?

The thing is, I think I heard quite similar explanation why Test::More is
safe to use when the patch to add t/t9700 was submit.  Then what happened?

Re: [PATCH] git-add--interactive: manual hunk editing mode

[Jeff King]

On Wed, Jul 02, 2008 at 01:08:09AM -0700, Junio C Hamano wrote:

> > So if the problem is "old perl", I don't think it is an issue. Are there
> > modern perl installations in the wild that don't have File::Temp?
> 
> The thing is, I think I heard quite similar explanation why Test::More is
> safe to use when the patch to add t/t9700 was submit.  Then what happened?

ISTR the Test::More problem was reported by Linus, who is a Fedora user?
I tried searching for any reasonable information on which of the core
perl modules are installed by default on Fedora systems, but didn't come
up with anything useful.

I really have no clue as to what is out there, and I suspect we must
either play it totally safe, or push the limits and wait for people to
complain about breakage.

-Peff

Re: [PATCH] git-add--interactive: manual hunk editing mode

[Johannes Schindelin]

Hi,

On Wed, 2 Jul 2008, Jeff King wrote:

> On Wed, Jul 02, 2008 at 01:08:09AM -0700, Junio C Hamano wrote:
> 
> > > So if the problem is "old perl", I don't think it is an issue. Are 
> > > there modern perl installations in the wild that don't have 
> > > File::Temp?
> > 
> > The thing is, I think I heard quite similar explanation why Test::More 
> > is safe to use when the patch to add t/t9700 was submit.  Then what 
> > happened?
> 
> ISTR the Test::More problem was reported by Linus, who is a Fedora user? 
> I tried searching for any reasonable information on which of the core 
> perl modules are installed by default on Fedora systems, but didn't come 
> up with anything useful.
> 
> I really have no clue as to what is out there, and I suspect we must 
> either play it totally safe, or push the limits and wait for people to 
> complain about breakage.

I wonder why bother trying to import things when you do not need them to 
begin with!  I mean, it is _obvious_ that in this case, we want .git/ to 
be writable _anyway_, so why not stick with a fixed name in that?

Ciao,
Dscho

Re: [PATCH] git-add--interactive: manual hunk editing mode

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> I wonder why bother trying to import things when you do not need them to 
> begin with!  I mean, it is _obvious_ that in this case, we want .git/ to 
> be writable _anyway_, so why not stick with a fixed name in that?

Good suggestion -- I love that simplicity.  Thomas?

[PATCH 0/3] git-add--interactive: use --recount, editing

[Thomas Rast]

Junio C Hamano wrote:
> 
> I recall that the original "add--interactive" carefully counted numbers in
> hunks it reassembles (as it can let you split and then you can choose to
> use both parts, which requires it to merge overlapping hunks back), but if
> you are going to use --recount anyway, perhaps we can discard that logic?
> It may make the patch application less robust, though.  I dunno.

This series takes it a bit further.  I played around with 'apply', and
it seems there is no reason to even merge the hunks.  (It would be
great if someone who knows builtin-apply.c could confirm this.)  So we
can get rid of all recounting except for the correct splitting
boundaries.  These are the first two patches.

Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > I wonder why bother trying to import things when you do not need them to 
> > begin with!  I mean, it is _obvious_ that in this case, we want .git/ to 
> > be writable _anyway_, so why not stick with a fixed name in that?
> 
> Good suggestion -- I love that simplicity.  Thomas?

Well, changed that back.

Apart from that, no real changes to 3/3, but the $needs_recount code
has become unnecessary because 1/3 already forces --recount.

- Thomas



 Documentation/git-add.txt  |    1 +
 git-add--interactive.perl  |  203 ++++++++++++++++++++++---------------------
 t/t3701-add-interactive.sh |   67 +++++++++++++++
 3 files changed, 172 insertions(+), 99 deletions(-)

[PATCH 1/3] git-add--interactive: replace hunk recounting with apply --recount

[Thomas Rast]

We recounted the postimage offsets to compensate for hunks that were
not selected.  Now apply --recount can do the job for us.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
 git-add--interactive.perl |   30 +++---------------------------
 1 files changed, 3 insertions(+), 27 deletions(-)

diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 903953e..e1964a5 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -970,39 +970,15 @@ sub patch_update_file {
 		push @result, @{$mode->{TEXT}};
 	}
 	for (@hunk) {
-		my $text = $_->{TEXT};
-		my ($o_ofs, $o_cnt, $n_ofs, $n_cnt) =
-		    parse_hunk_header($text->[0]);
-
-		if (!$_->{USE}) {
-			# We would have added ($n_cnt - $o_cnt) lines
-			# to the postimage if we were to use this hunk,
-			# but we didn't.  So the line number that the next
-			# hunk starts at would be shifted by that much.
-			$n_lofs -= ($n_cnt - $o_cnt);
-			next;
-		}
-		else {
-			if ($n_lofs) {
-				$n_ofs += $n_lofs;
-				$text->[0] = ("@@ -$o_ofs" .
-					      (($o_cnt != 1)
-					       ? ",$o_cnt" : '') .
-					      " +$n_ofs" .
-					      (($n_cnt != 1)
-					       ? ",$n_cnt" : '') .
-					      " @@\n");
-			}
-			for (@$text) {
-				push @result, $_;
-			}
+		if ($_->{USE}) {
+			push @result, @{$_->{TEXT}};
 		}
 	}
 
 	if (@result) {
 		my $fh;
 
-		open $fh, '| git apply --cached';
+		open $fh, '| git apply --cached --recount';
 		for (@{$head->{TEXT}}, @result) {
 			print $fh $_;
 		}
-- 
1.5.6.1.276.gde9a

[PATCH 2/3] git-add--interactive: remove hunk coalescing

[Thomas Rast]

Current git-apply has no trouble at all applying chunks that have
overlapping context, as produced by the splitting feature. So we can
drop the manual coalescing.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
 git-add--interactive.perl |   89 ---------------------------------------------
 1 files changed, 0 insertions(+), 89 deletions(-)

diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index e1964a5..a4234d3 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -682,93 +682,6 @@ sub split_hunk {
 	return @split;
 }
 
-sub find_last_o_ctx {
-	my ($it) = @_;
-	my $text = $it->{TEXT};
-	my ($o_ofs, $o_cnt) = parse_hunk_header($text->[0]);
-	my $i = @{$text};
-	my $last_o_ctx = $o_ofs + $o_cnt;
-	while (0 < --$i) {
-		my $line = $text->[$i];
-		if ($line =~ /^ /) {
-			$last_o_ctx--;
-			next;
-		}
-		last;
-	}
-	return $last_o_ctx;
-}
-
-sub merge_hunk {
-	my ($prev, $this) = @_;
-	my ($o0_ofs, $o0_cnt, $n0_ofs, $n0_cnt) =
-	    parse_hunk_header($prev->{TEXT}[0]);
-	my ($o1_ofs, $o1_cnt, $n1_ofs, $n1_cnt) =
-	    parse_hunk_header($this->{TEXT}[0]);
-
-	my (@line, $i, $ofs, $o_cnt, $n_cnt);
-	$ofs = $o0_ofs;
-	$o_cnt = $n_cnt = 0;
-	for ($i = 1; $i < @{$prev->{TEXT}}; $i++) {
-		my $line = $prev->{TEXT}[$i];
-		if ($line =~ /^\+/) {
-			$n_cnt++;
-			push @line, $line;
-			next;
-		}
-
-		last if ($o1_ofs <= $ofs);
-
-		$o_cnt++;
-		$ofs++;
-		if ($line =~ /^ /) {
-			$n_cnt++;
-		}
-		push @line, $line;
-	}
-
-	for ($i = 1; $i < @{$this->{TEXT}}; $i++) {
-		my $line = $this->{TEXT}[$i];
-		if ($line =~ /^\+/) {
-			$n_cnt++;
-			push @line, $line;
-			next;
-		}
-		$ofs++;
-		$o_cnt++;
-		if ($line =~ /^ /) {
-			$n_cnt++;
-		}
-		push @line, $line;
-	}
-	my $head = ("@@ -$o0_ofs" .
-		    (($o_cnt != 1) ? ",$o_cnt" : '') .
-		    " +$n0_ofs" .
-		    (($n_cnt != 1) ? ",$n_cnt" : '') .
-		    " @@\n");
-	@{$prev->{TEXT}} = ($head, @line);
-}
-
-sub coalesce_overlapping_hunks {
-	my (@in) = @_;
-	my @out = ();
-
-	my ($last_o_ctx);
-
-	for (grep { $_->{USE} } @in) {
-		my $text = $_->{TEXT};
-		my ($o_ofs) = parse_hunk_header($text->[0]);
-		if (defined $last_o_ctx &&
-		    $o_ofs <= $last_o_ctx) {
-			merge_hunk($out[-1], $_);
-		}
-		else {
-			push @out, $_;
-		}
-		$last_o_ctx = find_last_o_ctx($out[-1]);
-	}
-	return @out;
-}
 
 sub help_patch_cmd {
 	print colored $help_color, <<\EOF ;
@@ -962,8 +875,6 @@ sub patch_update_file {
 		}
 	}
 
-	@hunk = coalesce_overlapping_hunks(@hunk);
-
 	my $n_lofs = 0;
 	my @result = ();
 	if ($mode->{USE}) {
-- 
1.5.6.1.276.gde9a

[PATCH 3/3] git-add--interactive: manual hunk editing mode

[Thomas Rast]

Adds a new option 'e' to the 'add -p' command loop that lets you edit
the current hunk in your favourite editor.

If the resulting patch applies cleanly, the edited hunk will
immediately be marked for staging. If it does not apply cleanly, you
will be given an opportunity to edit again. If all lines of the hunk
are removed, then the edit is aborted and the hunk is left unchanged.

Applying the changed hunk(s) relies on Johannes Schindelin's new
--recount option for git-apply.

Note that the "real patch" test intentionally uses
  (echo e; echo n; echo d) | git add -p
even though the 'n' and 'd' are superfluous at first sight.  They
serve to get out of the interaction loop if git add -p wrongly
concludes the patch does not apply.

Many thanks to Jeff King <peff@peff.net> for lots of help and
suggestions.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
 Documentation/git-add.txt  |    1 +
 git-add--interactive.perl  |  119 ++++++++++++++++++++++++++++++++++++++++++++
 t/t3701-add-interactive.sh |   67 +++++++++++++++++++++++++
 3 files changed, 187 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 011a743..46dd56c 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -236,6 +236,7 @@ patch::
        k - leave this hunk undecided, see previous undecided hunk
        K - leave this hunk undecided, see previous hunk
        s - split the current hunk into smaller hunks
+       e - manually edit the current hunk
        ? - print help
 +
 After deciding the fate for all hunks, if there is any hunk
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index a4234d3..801d7c0 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -18,6 +18,18 @@ my ($fraginfo_color) =
 	$diff_use_color ? (
 		$repo->get_color('color.diff.frag', 'cyan'),
 	) : ();
+my ($diff_plain_color) =
+	$diff_use_color ? (
+		$repo->get_color('color.diff.plain', ''),
+	) : ();
+my ($diff_old_color) =
+	$diff_use_color ? (
+		$repo->get_color('color.diff.old', 'red'),
+	) : ();
+my ($diff_new_color) =
+	$diff_use_color ? (
+		$repo->get_color('color.diff.new', 'green'),
+	) : ();
 
 my $normal_color = $repo->get_color("", "reset");
 
@@ -683,6 +695,105 @@ sub split_hunk {
 }
 
 
+sub color_diff {
+	return map {
+		colored((/^@/  ? $fraginfo_color :
+			 /^\+/ ? $diff_new_color :
+			 /^-/  ? $diff_old_color :
+			 $diff_plain_color),
+			$_);
+	} @_;
+}
+
+sub edit_hunk_manually {
+	my ($oldtext) = @_;
+
+	my $hunkfile = $repo->repo_path . "/addp-hunk-edit.diff";
+	my $fh;
+	open $fh, '>', $hunkfile
+		or die "failed to open hunk edit file for writing: " . $!;
+	print $fh "# Manual hunk edit mode -- see bottom for a quick guide\n";
+	print $fh @$oldtext;
+	print $fh <<EOF;
+# ---
+# To remove '-' lines, make them ' ' lines (context).
+# To remove '+' lines, delete them.
+# Lines starting with # will be removed.
+#
+# If the patch applies cleanly, the edited hunk will immediately be
+# marked for staging. If it does not apply cleanly, you will be given
+# an opportunity to edit again. If all lines of the hunk are removed,
+# then the edit is aborted and the hunk is left unchanged.
+EOF
+	close $fh;
+
+	my $editor = $ENV{GIT_EDITOR} || $repo->config("core.editor")
+		|| $ENV{VISUAL} || $ENV{EDITOR} || "vi";
+	system('sh', '-c', $editor.' "$@"', $editor, $hunkfile);
+
+	open $fh, '<', $hunkfile
+		or die "failed to open hunk edit file for reading: " . $!;
+	my @newtext = grep { !/^#/ } <$fh>;
+	close $fh;
+	unlink $hunkfile;
+
+	# Abort if nothing remains
+	if (!grep { /\S/ } @newtext) {
+		return undef;
+	}
+
+	# Reinsert the first hunk header if the user accidentally deleted it
+	if ($newtext[0] !~ /^@/) {
+		unshift @newtext, $oldtext->[0];
+	}
+	return \@newtext;
+}
+
+sub diff_applies {
+	my $fh;
+	open $fh, '| git apply --recount --cached --check';
+	for my $h (@_) {
+		print $fh @{$h->{TEXT}};
+	}
+	return close $fh;
+}
+
+sub prompt_yesno {
+	my ($prompt) = @_;
+	while (1) {
+		print colored $prompt_color, $prompt;
+		my $line = <STDIN>;
+		return 0 if $line =~ /^n/i;
+		return 1 if $line =~ /^y/i;
+	}
+}
+
+sub edit_hunk_loop {
+	my ($head, $hunk, $ix) = @_;
+	my $text = $hunk->[$ix]->{TEXT};
+
+	while (1) {
+		$text = edit_hunk_manually($text);
+		if (!defined $text) {
+			return undef;
+		}
+		my $newhunk = { TEXT => $text, USE => 1 };
+		if (diff_applies($head,
+				 @{$hunk}[0..$ix-1],
+				 $newhunk,
+				 @{$hunk}[$ix+1..$#{$hunk}])) {
+			$newhunk->{DISPLAY} = [color_diff(@{$text})];
+			return $newhunk;
+		}
+		else {
+			prompt_yesno(
+				'Your edited hunk does not apply. Edit again '
+				. '(saying "no" discards!) [y/n]? '
+				) or return undef;
+		}
+	}
+}
+
 sub help_patch_cmd {
 	print colored $help_color, <<\EOF ;
 y - stage this hunk
@@ -694,6 +805,7 @@ J - leave this hunk undecided, see next hunk
 k - leave this hunk undecided, see previous undecided hunk
 K - leave this hunk undecided, see previous hunk
 s - split the current hunk into smaller hunks
+e - manually edit the current hunk
 ? - print help
 EOF
 }
@@ -798,6 +910,7 @@ sub patch_update_file {
 		if (hunk_splittable($hunk[$ix]{TEXT})) {
 			$other .= '/s';
 		}
+		$other .= '/e';
 		for (@{$hunk[$ix]{DISPLAY}}) {
 			print;
 		}
@@ -862,6 +975,12 @@ sub patch_update_file {
 				$num = scalar @hunk;
 				next;
 			}
+			elsif ($line =~ /^e/) {
+				my $newhunk = edit_hunk_loop($head, \@hunk, $ix);
+				if (defined $newhunk) {
+					splice @hunk, $ix, 1, $newhunk;
+				}
+			}
 			else {
 				help_patch_cmd($other);
 				next;
diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
index fae64ea..e95663d 100755
--- a/t/t3701-add-interactive.sh
+++ b/t/t3701-add-interactive.sh
@@ -66,6 +66,73 @@ test_expect_success 'revert works (commit)' '
 	grep "unchanged *+3/-0 file" output
 '
 
+cat >expected <<EOF
+EOF
+cat >fake_editor.sh <<EOF
+EOF
+chmod a+x fake_editor.sh
+test_set_editor "$(pwd)/fake_editor.sh"
+test_expect_success 'dummy edit works' '
+	(echo e; echo a) | git add -p &&
+	git diff > diff &&
+	test_cmp expected diff
+'
+
+cat >patch <<EOF
+@@ -1,1 +1,4 @@
+ this
++patch
+-doesn't
+ apply
+EOF
+echo "#!$SHELL_PATH" >fake_editor.sh
+cat >>fake_editor.sh <<\EOF
+mv -f "$1" oldpatch &&
+mv -f patch "$1"
+EOF
+chmod a+x fake_editor.sh
+test_set_editor "$(pwd)/fake_editor.sh"
+test_expect_success 'bad edit rejected' '
+	git reset &&
+	(echo e; echo n; echo d) | git add -p >output &&
+	grep "hunk does not apply" output
+'
+
+cat >patch <<EOF
+this patch
+is garbage
+EOF
+test_expect_success 'garbage edit rejected' '
+	git reset &&
+	(echo e; echo n; echo d) | git add -p >output &&
+	grep "hunk does not apply" output
+'
+
+cat >patch <<EOF
+@@ -1,0 +1,0 @@
+ baseline
++content
++newcontent
++lines
+EOF
+cat >expected <<EOF
+diff --git a/file b/file
+index b5dd6c9..f910ae9 100644
+--- a/file
++++ b/file
+@@ -1,4 +1,4 @@
+ baseline
+ content
+-newcontent
++more
+ lines
+EOF
+test_expect_success 'real edit works' '
+	(echo e; echo n; echo d) | git add -p &&
+	git diff >output &&
+	test_cmp expected output
+'
+
 if test "$(git config --bool core.filemode)" = false
 then
     say 'skipping filemode tests (filesystem does not properly support modes)'
-- 
1.5.6.1.276.gde9a

Re: [PATCH 2/3] git-add--interactive: remove hunk coalescing

[Junio C Hamano]

Thomas Rast <trast@student.ethz.ch> writes:

> Current git-apply has no trouble at all applying chunks that have
> overlapping context, as produced by the splitting feature. So we can
> drop the manual coalescing.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
>  git-add--interactive.perl |   89 ---------------------------------------------
>  1 files changed, 0 insertions(+), 89 deletions(-)
>
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index e1964a5..a4234d3 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -682,93 +682,6 @@ sub split_hunk {
>  	return @split;
>  }
>  
> -sub find_last_o_ctx {
> ...
> -}
> -
> -sub merge_hunk {
> ...
> -}
> -
> -sub coalesce_overlapping_hunks {
> ...
> -}
>  
>  sub help_patch_cmd {
>  	print colored $help_color, <<\EOF ;
> @@ -962,8 +875,6 @@ sub patch_update_file {
>  		}
>  	}
>  
> -	@hunk = coalesce_overlapping_hunks(@hunk);
> -
>  	my $n_lofs = 0;
>  	my @result = ();
>  	if ($mode->{USE}) {
> -- 
> 1.5.6.1.276.gde9a

I think [1/3] makes sense as we trust --recount anyway (and more
importantly if the user did not muck with the patch --recount would be a
no-op), but I am not sure about this one.  I suspect this change reduces
the precision and safety of the patch application, especially when the
user does not edit hunks.

When you "[s]plit" a hunk like this:

	@@ -n,7 +m,6 @@
         con
         text
        -deleted preimage
        +replaced postimage
	 more
	 line of context
        -deleted another
	 context

into two, we prepare these two hunks internally:

	@@ -n,5 +m,5 @@
         con
         text
        -deleted preimage
        +replaced postimage
	 more
         line of context

	@@ -l,4 +k,3 @@  -- l=n+5, k=m+5
	 more
         line of context
        -deleted another
	 context

So that applying only one piece without applying the other would still
have correct context to locate where to apply.  However, if the user says
"I want to apply both after all", we would need to remove the overlap when
merge them back.  If you don't, you would be feeding a nonsense patch to
"git apply" that goes back in context.

Blindly concatenating the above two and feeding them to "git apply" *may*
happen to work by accident, not by design.  This very much feels like a
hack of "This works most of the time for me, your mileage may vary" kind,
which we would want to avoid when we can.

Re: [PATCH 2/3] git-add--interactive: remove hunk coalescing

[Junio C Hamano]

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

> Blindly concatenating the above two and feeding them to "git apply" *may*
> happen to work by accident, not by design.  This very much feels like a
> hack of "This works most of the time for me, your mileage may vary" kind,
> which we would want to avoid when we can.

Well, I changed my mind.  Let's run with this and see what happens.

The patch application is hunk-by-hunk in nature anyway, and if the user
munges the trailing context of the first half of an originally-single hunk
and the leading context of the latter half in an inconsistent way, we
would notice the problem anyway.

Re: [PATCH 2/3] git-add--interactive: remove hunk coalescing

[Thomas Rast]

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

Junio C Hamano wrote:
> 
> > Blindly concatenating the above two and feeding them to "git apply" *may*
> > happen to work by accident, not by design.  This very much feels like a
> > hack of "This works most of the time for me, your mileage may vary" kind,
> > which we would want to avoid when we can.
> 
> Well, I changed my mind.  Let's run with this and see what happens.

In support of this being a feature of git-apply, notice that it even
handles the situation correctly where the context of a hunk has been
influenced by previous hunks, as in

@@ -1,2 +1,3 @@
 foo
+quux
 bar
@@ -1,3 +1,4 @@
 foo
 quux
+abc
 bar

With Don Zickus' recent patch, it also handles patches that go over
the same file twice.

- Thomas

-- 
Thomas Rast
trast@student.ethz.ch




[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH 2/3] git-add--interactive: remove hunk coalescing

[Junio C Hamano]

Thomas Rast <trast@student.ethz.ch> writes:

> Junio C Hamano wrote:
>> 
>> > Blindly concatenating the above two and feeding them to "git apply" *may*
>> > happen to work by accident, not by design.  This very much feels like a
>> > hack of "This works most of the time for me, your mileage may vary" kind,
>> > which we would want to avoid when we can.
>> 
>> Well, I changed my mind.  Let's run with this and see what happens.
>
> In support of this being a feature of git-apply, notice that it even
> handles the situation correctly where the context of a hunk has been
> influenced by previous hunks, as in...

That's what meant by my earlier "application is hunk-by-hunk in nature"
and we are in agreement.  The fact it works that way is not quite by
design and close to being "by accident", but I do not foresee anybody
changing it in the near future, so...

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.  The topics
meant to be applied to the maintenance series have "maint-" in their
names.

It already is beginning to become clear what 1.6.0 will look like.  What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements.  Bigger changes will be:

 * MinGW will be in.

 * With the default Makefile settings, most of the programs will be
   installed outside your $PATH, except for "git", "gitk", "git-gui" and
   some server side programs that need to be accessible for technical
   reasons.  Invoking a git subcommand as "git-xyzzy" from the command
   line has been deprecated since early 2006 (and officially announced in
   1.5.4 release notes); use of them from your scripts after adding
   output from "git --exec-path" to the $PATH will still be supported in
   1.6.0, but users are again strongly encouraged to adjust their
   scripts to use "git xyzzy" form, as we will stop installing
   "git-xyzzy" hardlinks for built-in commands in later releases.

 * git-merge will be rewritten in C.

 * default pack and idx versions will be updated as scheduled for some
   time ago.

 * GIT_CONFIG, which was only documented as affecting "git config", but
   actually affected all git commands, now only affects "git config".
   GIT_LOCAL_CONFIG, also only documented as affecting "git config" and
   not different from GIT_CONFIG in a useful way, is removed.

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

* js/import-zip (Mon Jun 30 19:50:44 2008 +0100) 1 commit
 + Add another fast-import example, this time for .zip files

* js/apply-root (Tue Jul 1 00:44:47 2008 +0100) 1 commit
 + Teach "git apply" to prepend a prefix with "--root=<root>"

* db/no-git-config (Mon Jun 30 03:37:47 2008 -0400) 1 commit
 + Only use GIT_CONFIG in "git config", not other programs

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

* j6t/mingw (Sat Nov 17 20:48:14 2007 +0100) 38 commits
 + compat/pread.c: Add a forward declaration to fix a warning
 + Windows: Fix ntohl() related warnings about printf formatting
 + Windows: TMP and TEMP environment variables specify a temporary
   directory.
 + Windows: Make 'git help -a' work.
 + Windows: Work around an oddity when a pipe with no reader is
   written to.
 + Windows: Make the pager work.
 + When installing, be prepared that template_dir may be relative.
 + Windows: Use a relative default template_dir and ETC_GITCONFIG
 + Windows: Compute the fallback for exec_path from the program
   invocation.
 + Turn builtin_exec_path into a function.
 + Windows: Use a customized struct stat that also has the st_blocks
   member.
 + Windows: Add a custom implementation for utime().
 + Windows: Add a new lstat and fstat implementation based on Win32
   API.
 + Windows: Implement a custom spawnve().
 + Windows: Implement wrappers for gethostbyname(), socket(), and
   connect().
 + Windows: Work around incompatible sort and find.
 + Windows: Implement asynchronous functions as threads.
 + Windows: Disambiguate DOS style paths from SSH URLs.
 + Windows: A rudimentary poll() emulation.
 + Windows: Implement start_command().
 + Windows: A pipe() replacement whose ends are not inherited to
   children.
 + Windows: Wrap execve so that shell scripts can be invoked.
 + Windows: Implement setitimer() and sigaction().
 + Windows: Fix PRIuMAX definition.
 + Windows: Implement gettimeofday().
 + Make my_mktime() public and rename it to tm_to_time_t()
 + Windows: Work around misbehaved rename().
 + Windows: always chmod(, 0666) before unlink().
 + Windows: A minimal implemention of getpwuid().
 + Windows: Implement a wrapper of the open() function.
 + Windows: Strip ".exe" from the program name.
 + Windows: Handle absolute paths in
   safe_create_leading_directories().
 + Windows: Treat Windows style path names.
 + setup.c: Prepare for Windows directory separators.
 + Windows: Use the Windows style PATH separator ';'.
 + Add target architecture MinGW.
 + Compile some programs only conditionally.
 + Add compat/regex.[ch] and compat/fnmatch.[ch].

No explanation necessary ;-)

----------------------------------------------------------------
[Actively Cooking]

* jc/reflog-expire (Sat Jun 28 22:24:49 2008 -0700) 2 commits
 - Make default expiration period of reflog used for stash infinite
 - Per-ref reflog expiry configuration

As 1.6.0 will be a good time to make backward incompatible changes, the
tip commit makes the default expiry period of stash 'never', unless you
configure them to expire explicitly using gc.refs/stash.* variables.
Needs consensus, but I am guessing that enough people would want stash
that does not expire.

We may want to change the commit topology used to represent a stash, as
proposed in $gmane/85055 by Nana earlier.

* jc/merge-theirs (Mon Jun 30 22:18:57 2008 -0700) 4 commits
 - Make "subtree" part more orthogonal to the rest of merge-
   recursive.
 + Teach git-merge to pass -X<option> to the backend strategy module
 + git-merge-recursive-{ours,theirs}
 + git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends is updated so that you can
say "git merge -Xours -Xsubtree=foo/bar/baz -s recursive other" now.

* mv/merge-in-c (Tue Jul 1 04:37:50 2008 +0200) 14 commits
 - Build in merge
 - git-commit-tree: make it usable from other builtins
 - Add new test case to ensure git-merge prepends the custom merge
   message
 - Add new test case to ensure git-merge reduces octopus parents when
   possible
 - Introduce reduce_heads()
 - Introduce get_merge_bases_many()
 - Add new test to ensure git-merge handles more than 25 refs.
 - Introduce get_octopus_merge_bases() in commit.c
 - git-fmt-merge-msg: make it usable from other builtins
 - Move read_cache_unmerged() to read-cache.c
 - Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 - Move parse-options's skip_prefix() to git-compat-util.h
 - Move commit_list_count() to commit.c
 - Move split_cmdline() to alias.c

I think this is getting there.  Will be in 'next' soon.

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 + Eliminate an unnecessary chdir("..")
 + Add support for GIT_CEILING_DIRECTORIES
 + Fold test-absolute-path into test-path-utils
 + Implement normalize_absolute_path

* jc/rerere (Sun Jun 22 02:04:31 2008 -0700) 5 commits
 + rerere.autoupdate
 + t4200: fix rerere test
 + rerere: remove dubious "tail_optimization"
 + git-rerere: detect unparsable conflicts
 + rerere: rerere_created_at() and has_resolution() abstraction

A new configuration will allow paths that have been resolved cleanly by
rerere to be updated in the index automatically.

* ph/parseopt-step-blame (Tue Jun 24 11:12:12 2008 +0200) 7 commits
 - Migrate git-blame to parse-option partially.
 - parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
 - parse-opt: fake short strings for callers to believe in.
 - parse-opt: do not print errors on unknown options, return -2
   intead.
 - parse-opt: create parse_options_step.
 - parse-opt: Export a non NORETURN usage dumper.
 - parse-opt: have parse_options_{start,end}.

I recall Pierre said something about cleaning up the last one when he
finds time, but other than that vague recollection, I lost track of this
series.  I am tempted to fork a few topics off of the penúltimo one to
convert a few more commands as examples and merge the result to 'next'.

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

* ph/mergetool (Mon Jun 16 17:33:41 2008 -0600) 1 commit
 + Remove the use of '--' in merge program invocation

I got tired of waiting for success reports from people who use various
backends.  We will hear breakages if this breaks things anyway, and if it
does, it is a fairly simple single patch to revert.

* nd/dashless (Tue Jun 24 19:58:11 2008 -0700) 2 commits
 + Keep some git-* programs in $(bindir)
 + Move all dashed-form commands to libexecdir

We'll leave server-side programs in $(bindir) so that ssh clients can ask
for "git-program" and find them on the $PATH.  Next major release after
1.6.0 would most likely remove the hardlinks to built-in commands, but not
yet.

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
 + Prepare execv_git_cmd() for removal of builtins from the
   filesystem
 + git-shell: accept "git foo" form

The botched "client asks 'git foo'" is not included.  It will be long
after everybody runs 1.6.0.

* jk/maint-fetch-ref-hier (Fri Jun 27 00:01:41 2008 -0400) 2 commits
 + fetch: give a hint to the user when local refs fail to update
 + fetch: report local storage errors in status table

When the remote used to have "foo" branch but now has "foo/bar", fetch
refuses to delete the existing remote tracking branch "foo" to create a
new remote tracking branch "foo/bar", but the error message was
confusing.

Need to backmerge to 'maint' after a while.

* jc/maint-reset (Wed Jun 25 18:16:36 2008 -0700) 1 commit
 + Allow "git-reset path" when unambiguous

We used to require "git-reset -- path" even when there is no ambiguity
(i.e. path cannot be mistaken as a valid tree-ish and it is a filename in
the work tree).

Need to backmerge to 'maint' after a while.

* js/maint-clone-insteadof (Fri Jun 27 13:55:23 2008 +0100) 2 commits
 + clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
 + clone: respect url.insteadOf setting in global configs

"git clone" did not honor "url.InsteadOf" in $HOME/.gitconfig.  I think
Daniel's "Let's get rid of internal use of GIT_CONFIG" makes sense (even
though it feels very scary), and it would make the solution much simpler,
but these two are independently good fix for now.  I'll queue GIT_CONFIG
one in 'next' and when it graduates the unsetenv() solution in these will
become no-op.

* tr/send-email-ssl (Thu Jun 26 23:03:21 2008 +0200) 2 commits
 + git-send-email: prevent undefined variable warnings if no
   encryption is set
 + git-send-email: add support for TLS via Net::SMTP::SSL

* kb/send-email-fifo (Wed Jun 25 15:44:40 2008 -0700) 1 commit
 + git-send-email: Accept fifos as well as files

Two minor send-email feature enhancements.

* jc/checkdiff (Sun Jun 29 16:49:06 2008 -0400) 7 commits
 + Fix t4017-diff-retval for white-space from wc
 + Update sample pre-commit hook to use "diff --check"
 + diff --check: detect leftover conflict markers
 + Teach "diff --check" about new blank lines at end
 + checkdiff: pass diff_options to the callback
 + check_and_emit_line(): rename and refactor
 + diff --check: explain why we do not care whether old side is
   binary

Allows us to replace the sample pre-commit hook that was not aware of the
line termination convention per path nor newer whitespace breakage rules.

* np/pack-default (Wed Jun 25 00:25:53 2008 -0400) 2 commits
 + pack.indexversion config option now defaults to 2
 + repack.usedeltabaseoffset config option now defaults to "true"

Updates the default value for pack.indexversion to 2 and use delta-base
offset encoding of the packfiles by default.

* js/apply-recount (Fri Jun 27 18:43:09 2008 +0100) 1 commit
 + Allow git-apply to recount the lines in a hunk (AKA recountdiff)

A good ingredient for implementing "apply --edit".

* dz/apply-again (Fri Jun 27 14:39:12 2008 -0400) 1 commit
 + git-apply: handle a patch that touches the same path more than
   once better

Allows us to feed a patch that touches the same path more than once.

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

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet.

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
 + Revert "Make clients ask for "git program" over ssh and local
   transport"
 + Make clients ask for "git program" over ssh and local transport

This is the "botched" one.  Will be resurrected during 1.7.0 or 1.8.0
timeframe.

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

----------------------------------------------------------------
[Stalled/Needs more work]

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.

----------------------------------------------------------------
[Dropped for now]

* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
 . Introduce fast forward option only
 . Head reduction before selecting merge strategy
 . Restructure git-merge.sh
 . Introduce -ff=<fast forward option>
 . New merge tests
 . Documentation for joining more than two histories

This will interfere with Miklos's rewrite of merge to C.

* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
 . Use perl instead of tac
 . Fix t3404 assumption that `wc -l` does not use whitespace.
 . rebase -i: Use : in expr command instead of match.
 . rebase -i: update the implementation of 'mark' command
 . Add option --preserve-tags
 . Teach rebase interactive the tag command
 . Add option --first-parent
 . Do rebase with preserve merges with advanced TODO list
 . Select all lines with fake-editor
 . Unify the length of $SHORT* and the commits in the TODO list
 . Teach rebase interactive the merge command
 . Move redo merge code in a function
 . Teach rebase interactive the reset command
 . Teach rebase interactive the mark command
 . Move cleanup code into it's own function
 . Don't append default merge message to -m message
 . fake-editor: output TODO list if unchanged

* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
 . WIP: rethink replay merge
 . Start using replay-tree merge in cherry-pick
 . revert/cherry-pick: start refactoring call to merge_recursive

This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time 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

Just my toy at this moment.

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

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.  The topics
meant to be applied to the maintenance series have "maint-" in their
names.

It already is beginning to become clear what 1.6.0 will look like.  What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements.  Bigger changes will be:

 * Port for MinGW.

 * With the default Makefile settings, most of the programs will be
   installed outside your $PATH, except for "git", "gitk", "git-gui" and
   some server side programs that need to be accessible for technical
   reasons.  Invoking a git subcommand as "git-xyzzy" from the command
   line has been deprecated since early 2006 (and officially announced in
   1.5.4 release notes); use of them from your scripts after adding
   output from "git --exec-path" to the $PATH will still be supported in
   1.6.0, but users are again strongly encouraged to adjust their
   scripts to use "git xyzzy" form, as we will stop installing
   "git-xyzzy" hardlinks for built-in commands in later releases.

 * git-merge will be rewritten in C.

 * default pack and idx versions will be updated as scheduled for some
   time ago.

 * GIT_CONFIG, which was only documented as affecting "git config", but
   actually affected all git commands, now only affects "git config".
   GIT_LOCAL_CONFIG, also only documented as affecting "git config" and
   not different from GIT_CONFIG in a useful way, is removed.

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

* js/maint-daemon-syslog (Thu Jul 3 16:27:24 2008 +0100) 1 commit
 - [PARKED improvement suggested not rolled in] git daemon: avoid
   calling syslog() from a signal handler

This will eventually appear in 'maint'; currently parked on 'pu', though.

* jc/report-tracking (Sun Jul 6 02:54:56 2008 -0700) 5 commits
 - branch -r -v: do not spit out garbage
 + stat_tracking_info(): clear object flags used during counting
 + git-branch -v: show the remote tracking statistics
 + git-status: show the remote tracking statistics
 + Refactor "tracking statistics" code used by "git checkout"

Makes the "your branch is ahead of the tracked one by N commits" logic and
messages available to other commands; status and branch are updated.

* sg/stash-k-i (Fri Jun 27 16:37:15 2008 +0200) 1 commit
 - stash: introduce 'stash save --keep-index' option

One weakness of our "partial commit" workflow support used to be that the
user can incrementally build what is to be committed in the index but that
state cannot be tested as a whole in the working tree.  This allows you to
temporarily stash the remaining changes in the working tree so that the
index state before running "stash save --keep-index" can be seen in the
working tree to be tested and then committed.  A recommended workflow to
use after that commit is made needs to be documented (and support needs to
be added if necessary).

* tr/add-i-e (Thu Jul 3 00:00:00 2008 +0200) 3 commits
 + git-add--interactive: manual hunk editing mode
 + git-add--interactive: remove hunk coalescing
 + git-add--interactive: replace hunk recounting with apply --recount

Adds 'e/dit' action to interactive add command.

* am/stash-branch (Thu Jul 3 11:46:05 2008 +0530) 1 commit
 + Implement "git stash branch <newbranch> <stash>"

Creates a new branch out of the stashed state, after returning from the
interrupt that forced you to create the stash in the first place.

* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
 - Ignore graft during object transfer [broken wrt shallow clones]

Cloning or fetching from a repository from grafts did not send objects
that are hidden by grafts, but the commits in the resulting repository do
need these to pass fsck.  This fixes object transfer to ignore grafts.

Another fix is needed to git-prune so that it ignores grafts but treats
commits that are mentioned in grafts as reachable.

* jk/pager-config (Thu Jul 3 07:46:57 2008 -0400) 1 commit
 - Allow per-command pager config

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

* js/import-zip (Mon Jun 30 19:50:44 2008 +0100) 1 commit
 + Add another fast-import example, this time for .zip files

* js/apply-root (Wed Jul 2 15:28:22 2008 -0700) 2 commits
 + apply --root: thinkofix.
 + Teach "git apply" to prepend a prefix with "--root=<root>"

* db/no-git-config (Mon Jun 30 03:37:47 2008 -0400) 1 commit
 + Only use GIT_CONFIG in "git config", not other programs

* jc/reflog-expire (Sat Jun 28 22:24:49 2008 -0700) 2 commits
 + Make default expiration period of reflog used for stash infinite
 + Per-ref reflog expiry configuration

As 1.6.0 will be a good time to make backward incompatible changes, the
tip commit makes the default expiry period of stash 'never', unless you
configure them to expire explicitly using gc.refs/stash.* variables.
Needs consensus, but I am guessing that enough people would want stash
that does not expire.

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 + Eliminate an unnecessary chdir("..")
 + Add support for GIT_CEILING_DIRECTORIES
 + Fold test-absolute-path into test-path-utils
 + Implement normalize_absolute_path

This still feels "because we can", not "because we need to", but it came
from somebody who had the need to, and I do not think it hurts people
without the environment variable set.

* jc/rerere (Sun Jun 22 02:04:31 2008 -0700) 5 commits
 + rerere.autoupdate
 + t4200: fix rerere test
 + rerere: remove dubious "tail_optimization"
 + git-rerere: detect unparsable conflicts
 + rerere: rerere_created_at() and has_resolution() abstraction

A new configuration will allow paths that have been resolved cleanly by
rerere to be updated in the index automatically.

To me, this is "because we can", but was something requested by Ingo, so
presumably some people may feel it useful in their workflow.

----------------------------------------------------------------
[Actively Cooking]

* mv/merge-in-c (Tue Jul 1 04:37:50 2008 +0200) 15 commits
 - [REJECT -- over-abuse of path-list] Build in merge
 + Fix t7601-merge-pull-config.sh on AIX
 + git-commit-tree: make it usable from other builtins
 + Add new test case to ensure git-merge prepends the custom merge
   message
 + Add new test case to ensure git-merge reduces octopus parents when
   possible
 + Introduce reduce_heads()
 + Introduce get_merge_bases_many()
 + Add new test to ensure git-merge handles more than 25 refs.
 + Introduce get_octopus_merge_bases() in commit.c
 + git-fmt-merge-msg: make it usable from other builtins
 + Move read_cache_unmerged() to read-cache.c
 + Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 + Move parse-options's skip_prefix() to git-compat-util.h
 + Move commit_list_count() to commit.c
 + Move split_cmdline() to alias.c

The last one is still not quite there, I am afraid.

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

* j6t/mingw (Sat Nov 17 20:48:14 2007 +0100) 38 commits
 + compat/pread.c: Add a forward declaration to fix a warning
 + Windows: Fix ntohl() related warnings about printf formatting
 + Windows: TMP and TEMP environment variables specify a temporary
   directory.
 + Windows: Make 'git help -a' work.
 + Windows: Work around an oddity when a pipe with no reader is
   written to.
 + Windows: Make the pager work.
 + When installing, be prepared that template_dir may be relative.
 + Windows: Use a relative default template_dir and ETC_GITCONFIG
 + Windows: Compute the fallback for exec_path from the program
   invocation.
 + Turn builtin_exec_path into a function.
 + Windows: Use a customized struct stat that also has the st_blocks
   member.
 + Windows: Add a custom implementation for utime().
 + Windows: Add a new lstat and fstat implementation based on Win32
   API.
 + Windows: Implement a custom spawnve().
 + Windows: Implement wrappers for gethostbyname(), socket(), and
   connect().
 + Windows: Work around incompatible sort and find.
 + Windows: Implement asynchronous functions as threads.
 + Windows: Disambiguate DOS style paths from SSH URLs.
 + Windows: A rudimentary poll() emulation.
 + Windows: Implement start_command().
 + Windows: A pipe() replacement whose ends are not inherited to
   children.
 + Windows: Wrap execve so that shell scripts can be invoked.
 + Windows: Implement setitimer() and sigaction().
 + Windows: Fix PRIuMAX definition.
 + Windows: Implement gettimeofday().
 + Make my_mktime() public and rename it to tm_to_time_t()
 + Windows: Work around misbehaved rename().
 + Windows: always chmod(, 0666) before unlink().
 + Windows: A minimal implemention of getpwuid().
 + Windows: Implement a wrapper of the open() function.
 + Windows: Strip ".exe" from the program name.
 + Windows: Handle absolute paths in
   safe_create_leading_directories().
 + Windows: Treat Windows style path names.
 + setup.c: Prepare for Windows directory separators.
 + Windows: Use the Windows style PATH separator ';'.
 + Add target architecture MinGW.
 + Compile some programs only conditionally.
 + Add compat/regex.[ch] and compat/fnmatch.[ch].

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

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet.  Perhaps
in 1.7.0.

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
 + Revert "Make clients ask for "git program" over ssh and local
   transport"
 + Make clients ask for "git program" over ssh and local transport

This is the "botched" one.  Will be resurrected during 1.7.0 or 1.8.0
timeframe.

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

----------------------------------------------------------------
[Stalled/Needs more work]

* ph/parseopt-step-blame (Tue Jun 24 11:12:12 2008 +0200) 7 commits
 - Migrate git-blame to parse-option partially.
 + parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
 + parse-opt: fake short strings for callers to believe in.
 + parse-opt: do not print errors on unknown options, return -2
   intead.
 + parse-opt: create parse_options_step.
 + parse-opt: Export a non NORETURN usage dumper.
 + parse-opt: have parse_options_{start,end}.

I recall Pierre said something about cleaning up the last one when he
finds time, but other than that vague recollection, I lost track of this
series.  I am tempted to fork a few topics off of the penúltimo one to
convert a few more commands as examples and merge the result to 'next'.

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.

* jc/merge-theirs (Mon Jun 30 22:18:57 2008 -0700) 5 commits
 + Make "subtree" part more orthogonal to the rest of merge-
   recursive.
 + Teach git-pull to pass -X<option> to git-merge
 + Teach git-merge to pass -X<option> to the backend strategy module
 + git-merge-recursive-{ours,theirs}
 + git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends is updated so that you can
say "git merge -Xours -Xsubtree=foo/bar/baz -s recursive other" now.

The -X<option> part may change, Dscho mentions that a single-letter -X
that take stuck option is against syntax rules, and I think he's right.

This is more "because we can", not "because we need to".

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

[Johannes Schindelin]

Hi,

On Sun, 6 Jul 2008, Junio C Hamano wrote:

> * js/apply-root (Wed Jul 2 15:28:22 2008 -0700) 2 commits
>  + apply --root: thinkofix.
>  + Teach "git apply" to prepend a prefix with "--root=<root>"

If we want to call this "--directory=<root>" instead, we should do it 
before that commit hits master.

Ciao,
Dscho

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

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Sun, 6 Jul 2008, Junio C Hamano wrote:
>
>> * js/apply-root (Wed Jul 2 15:28:22 2008 -0700) 2 commits
>>  + apply --root: thinkofix.
>>  + Teach "git apply" to prepend a prefix with "--root=<root>"
>
> If we want to call this "--directory=<root>" instead, we should do it 
> before that commit hits master.

Yeah, perhaps like this?

-- >8 --
git-apply --directory: make --root more similar to GNU diff

Applying a patch in the directory that is different from what the patch
records is done with --directory option in GNU diff.  The --root option we
introduced previously does the same, and we can call it the same way to
give users more familiar feel.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/git-apply.txt |    8 ++++++--
 builtin-apply.c             |    4 ++--
 t/t4128-apply-root.sh       |    8 ++++----
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index 63fce53..3cd3179 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -14,7 +14,7 @@ SYNOPSIS
 	  [--allow-binary-replacement | --binary] [--reject] [-z]
 	  [-pNUM] [-CNUM] [--inaccurate-eof] [--cached]
 	  [--whitespace=<nowarn|warn|fix|error|error-all>]
-	  [--exclude=PATH] [--root=<root>] [--verbose] [<patch>...]
+	  [--exclude=PATH] [--directory=<root>] [--verbose] [<patch>...]
 
 DESCRIPTION
 -----------
@@ -177,9 +177,13 @@ behavior:
 	current patch being applied will be printed. This option will cause
 	additional information to be reported.
 
---root=<root>::
+--directory=<root>::
 	Prepend <root> to all filenames.  If a "-p" argument was passed, too,
 	it is applied before prepending the new root.
++
+For example, a patch that talks about updating `a/git-gui.sh` to `b/git-gui.sh`
+can be applied to the file in the working tree `modules/git-gui/git-gui.sh` by
+running `git apply --directory=modules/git-gui`.
 
 Configuration
 -------------
diff --git a/builtin-apply.c b/builtin-apply.c
index 6c3db60..c242bbd 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -3130,8 +3130,8 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)
 			inaccurate_eof = 1;
 			continue;
 		}
-		if (!prefixcmp(arg, "--root=")) {
-			arg += strlen("--root=");
+		if (!prefixcmp(arg, "--directory=")) {
+			arg += strlen("--directory=");
 			root_len = strlen(arg);
 			if (root_len && arg[root_len - 1] != '/') {
 				char *new_root;
diff --git a/t/t4128-apply-root.sh b/t/t4128-apply-root.sh
index b650245..2dd0c75 100755
--- a/t/t4128-apply-root.sh
+++ b/t/t4128-apply-root.sh
@@ -23,18 +23,18 @@ diff a/bla/blub/dir/file b/bla/blub/dir/file
 +Bello
 EOF
 
-test_expect_success 'apply --root -p (1)' '
+test_expect_success 'apply --directory -p (1)' '
 
-	git apply --root=some/sub -p3 --index patch &&
+	git apply --directory=some/sub -p3 --index patch &&
 	test Bello = $(git show :some/sub/dir/file) &&
 	test Bello = $(cat some/sub/dir/file)
 
 '
 
-test_expect_success 'apply --root -p (2) ' '
+test_expect_success 'apply --directory -p (2) ' '
 
 	git reset --hard initial &&
-	git apply --root=some/sub/ -p3 --index patch &&
+	git apply --directory=some/sub/ -p3 --index patch &&
 	test Bello = $(git show :some/sub/dir/file) &&
 	test Bello = $(cat some/sub/dir/file)
 

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.  The topics
meant to be applied to the maintenance series have "maint-" in their
names.

It already is beginning to become clear what 1.6.0 will look like.  What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements.  Bigger changes will be:

 * Port for MinGW.

 * With the default Makefile settings, most of the programs will be
   installed outside your $PATH, except for "git", "gitk", "git-gui" and
   some server side programs that need to be accessible for technical
   reasons.  Invoking a git subcommand as "git-xyzzy" from the command
   line has been deprecated since early 2006 (and officially announced in
   1.5.4 release notes); use of them from your scripts after adding
   output from "git --exec-path" to the $PATH will still be supported in
   1.6.0, but users are again strongly encouraged to adjust their
   scripts to use "git xyzzy" form, as we will stop installing
   "git-xyzzy" hardlinks for built-in commands in later releases.

 * git-merge will be rewritten in C.

 * default pack and idx versions will be updated as scheduled for some
   time ago.

 * GIT_CONFIG, which was only documented as affecting "git config", but
   actually affected all git commands, now only affects "git config".
   GIT_LOCAL_CONFIG, also only documented as affecting "git config" and
   not different from GIT_CONFIG in a useful way, is removed.

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

* jc/rebase-orig-head (Mon Jul 7 00:16:38 2008 -0700) 1 commit
 + Teach "am" and "rebase" to mark the original position with
   ORIG_HEAD

* sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
 . Migrate git-am to use git-sequencer
 . Add git-sequencer test suite (t3350)
 . Add git-sequencer prototype documentation
 . Add git-sequencer shell prototype

* js/pick-root (Fri Jul 4 16:19:52 2008 +0100) 1 commit
 + Allow cherry-picking root commits

* ab/bundle (Sat Jul 5 17:26:40 2008 -0400) 1 commit
 + Teach git-bundle to read revision arguments from stdin like git-
   rev-list.

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

* js/apply-root (Sun Jul 6 18:36:01 2008 -0700) 3 commits
 + git-apply --directory: make --root more similar to GNU diff
 + apply --root: thinkofix.
 + Teach "git apply" to prepend a prefix with "--root=<root>"

* jc/reflog-expire (Sat Jun 28 22:24:49 2008 -0700) 2 commits
 + Make default expiration period of reflog used for stash infinite
 + Per-ref reflog expiry configuration

As 1.6.0 will be a good time to make backward incompatible changes, the
tip commit makes the default expiry period of stash 'never', unless you
configure them to expire explicitly using gc.refs/stash.* variables.
Needs consensus, but I am guessing that enough people would want stash
that does not expire.

* jk/pager-config (Thu Jul 3 07:46:57 2008 -0400) 1 commit
 + Allow per-command pager config

----------------------------------------------------------------
[Actively Cooking]

* sg/stash-k-i (Fri Jun 27 16:37:15 2008 +0200) 1 commit
 + stash: introduce 'stash save --keep-index' option

One weakness of our "partial commit" workflow support used to be that the
user can incrementally build what is to be committed in the index but that
state cannot be tested as a whole in the working tree.  This allows you to
temporarily stash the remaining changes in the working tree so that the
index state before running "stash save --keep-index" can be seen in the
working tree to be tested and then committed.

* am/stash-branch (Mon Jul 7 02:50:10 2008 +0530) 2 commits
 + Add a test for "git stash branch"
 + Implement "git stash branch <newbranch> <stash>"

Creates a new branch out of the stashed state, after returning from the
interrupt that forced you to create the stash in the first place.

* tr/add-i-e (Thu Jul 3 00:00:00 2008 +0200) 3 commits
 + git-add--interactive: manual hunk editing mode
 + git-add--interactive: remove hunk coalescing
 + git-add--interactive: replace hunk recounting with apply --recount

Adds 'e/dit' action to interactive add command.

* jc/report-tracking (Sun Jul 6 02:54:56 2008 -0700) 5 commits
 + branch -r -v: do not spit out garbage
 + stat_tracking_info(): clear object flags used during counting
 + git-branch -v: show the remote tracking statistics
 + git-status: show the remote tracking statistics
 + Refactor "tracking statistics" code used by "git checkout"

Makes the "your branch is ahead of the tracked one by N commits" logic and
messages available to other commands; status and branch are updated.

* jc/merge-theirs (Mon Jun 30 22:18:57 2008 -0700) 5 commits
 + Make "subtree" part more orthogonal to the rest of merge-
   recursive.
 + Teach git-pull to pass -X<option> to git-merge
 + Teach git-merge to pass -X<option> to the backend strategy module
 + git-merge-recursive-{ours,theirs}
 + git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends is updated so that you can
say "git merge -Xours -Xsubtree=foo/bar/baz -s recursive other" now.

The -X<option> part may change, Dscho mentions that a single-letter -X
that take stuck option is against syntax rules, and I think he's right.

This is more "because we can", not "because we need to".

* mv/merge-in-c (Mon Jul 7 19:24:20 2008 +0200) 15 commits
 - Build in merge
 + Fix t7601-merge-pull-config.sh on AIX
 + git-commit-tree: make it usable from other builtins
 + Add new test case to ensure git-merge prepends the custom merge
   message
 + Add new test case to ensure git-merge reduces octopus parents when
   possible
 + Introduce reduce_heads()
 + Introduce get_merge_bases_many()
 + Add new test to ensure git-merge handles more than 25 refs.
 + Introduce get_octopus_merge_bases() in commit.c
 + git-fmt-merge-msg: make it usable from other builtins
 + Move read_cache_unmerged() to read-cache.c
 + Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 + Move parse-options's skip_prefix() to git-compat-util.h
 + Move commit_list_count() to commit.c
 + Move split_cmdline() to alias.c

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

* js/import-zip (Mon Jun 30 19:50:44 2008 +0100) 1 commit
 + Add another fast-import example, this time for .zip files

* db/no-git-config (Mon Jun 30 03:37:47 2008 -0400) 1 commit
 + Only use GIT_CONFIG in "git config", not other programs

* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
 + Eliminate an unnecessary chdir("..")
 + Add support for GIT_CEILING_DIRECTORIES
 + Fold test-absolute-path into test-path-utils
 + Implement normalize_absolute_path

* jc/rerere (Sun Jun 22 02:04:31 2008 -0700) 5 commits
 + rerere.autoupdate
 + t4200: fix rerere test
 + rerere: remove dubious "tail_optimization"
 + git-rerere: detect unparsable conflicts
 + rerere: rerere_created_at() and has_resolution() abstraction

A new configuration will allow paths that have been resolved cleanly by
rerere to be updated in the index automatically.

* js/maint-daemon-syslog (Thu Jul 3 16:27:24 2008 +0100) 1 commit
 + git daemon: avoid calling syslog() from a signal handler

Meant for 'maint' as well.

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

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet.  Perhaps
in 1.7.0.

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
 + Revert "Make clients ask for "git program" over ssh and local
   transport"
 + Make clients ask for "git program" over ssh and local transport

This is the "botched" one.  Will be resurrected during 1.7.0 or 1.8.0
timeframe.

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

----------------------------------------------------------------
[Stalled/Needs more work]

* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
 - [BROKEN wrt shallow clones] Ignore graft during object transfer

Cloning or fetching from a repository from grafts did not send objects
that are hidden by grafts, but the commits in the resulting repository do
need these to pass fsck.  This fixes object transfer to ignore grafts.

Another fix is needed to git-prune so that it ignores grafts but treats
commits that are mentioned in grafts as reachable.

* ph/parseopt-step-blame (Tue Jun 24 11:12:12 2008 +0200) 7 commits
 - Migrate git-blame to parse-option partially.
 + parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
 + parse-opt: fake short strings for callers to believe in.
 + parse-opt: do not print errors on unknown options, return -2
   intead.
 + parse-opt: create parse_options_step.
 + parse-opt: Export a non NORETURN usage dumper.
 + parse-opt: have parse_options_{start,end}.

I recall Pierre said something about cleaning up the last one when he
finds time, but other than that vague recollection, I lost track of this
series.  I am tempted to fork a few topics off of the penúltimo one to
convert a few more commands as examples and merge the result to 'next'.

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.  The topics
meant to be applied to the maintenance series have "maint-" in their
names.

It already is beginning to become clear what 1.6.0 will look like.  What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements.  Bigger changes will be:

 * Port for MinGW.

 * With the default Makefile settings, most of the programs will be
   installed outside your $PATH, except for "git", "gitk", "git-gui" and
   some server side programs that need to be accessible for technical
   reasons.  Invoking a git subcommand as "git-xyzzy" from the command
   line has been deprecated since early 2006 (and officially announced in
   1.5.4 release notes); use of them from your scripts after adding
   output from "git --exec-path" to the $PATH will still be supported in
   1.6.0, but users are again strongly encouraged to adjust their
   scripts to use "git xyzzy" form, as we will stop installing
   "git-xyzzy" hardlinks for built-in commands in later releases.

 * git-merge will be rewritten in C.

 * default pack and idx versions will be updated as scheduled for some
   time ago.

 * GIT_CONFIG, which was only documented as affecting "git config", but
   actually affected all git commands, now only affects "git config".
   GIT_LOCAL_CONFIG, also only documented as affecting "git config" and
   not different from GIT_CONFIG in a useful way, is removed.

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

* xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
 + Teach git-merge -X<option> again.
 + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
 + builtin-merge.c: use parse_options_step() "incremental parsing"
   machinery
 + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next

I've described what this is in a separate message.

* jc/branch-merged (Tue Jul 8 17:55:47 2008 -0700) 3 commits
 + branch --merged/--no-merged: allow specifying arbitrary commit
 + branch --contains: default to HEAD
 + parse-options: add PARSE_OPT_LASTARG_DEFAULT flag

This builds on top of the parse-options enhancement series that
has been cooking in 'next' for some time.

* rs/imap (Wed Jul 9 22:29:02 2008 +0100) 5 commits
 + Documentation: Improve documentation for git-imap-send(1)
 + imap-send.c: more style fixes
 + imap-send.c: style fixes
 + git-imap-send: Support SSL
 + git-imap-send: Allow the program to be run from subdirectories of
   a git tree

* om/rerere-careful (Mon Jul 7 14:42:48 2008 +0200) 1 commit
 + builtin-rerere: more carefully find conflict markers

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

* js/pick-root (Fri Jul 4 16:19:52 2008 +0100) 1 commit
 + Allow cherry-picking root commits

* ab/bundle (Sat Jul 5 17:26:40 2008 -0400) 1 commit
 + Teach git-bundle to read revision arguments from stdin like git-
   rev-list.

* sg/stash-k-i (Tue Jul 8 00:40:56 2008 -0700) 2 commits
 + Documentation: tweak use case in "git stash save --keep-index"
 + stash: introduce 'stash save --keep-index' option

One weakness of our "partial commit" workflow support used to be that the
user can incrementally build what is to be committed in the index but that
state cannot be tested as a whole in the working tree.  This allows you to
temporarily stash the remaining changes in the working tree so that the
index state before running "stash save --keep-index" can be seen in the
working tree to be tested and then committed.

* am/stash-branch (Mon Jul 7 02:50:10 2008 +0530) 2 commits
 + Add a test for "git stash branch"
 + Implement "git stash branch <newbranch> <stash>"

Creates a new branch out of the stashed state, after returning from the
interrupt that forced you to create the stash in the first place.

* tr/add-i-e (Thu Jul 3 00:00:00 2008 +0200) 3 commits
 + git-add--interactive: manual hunk editing mode
 + git-add--interactive: remove hunk coalescing
 + git-add--interactive: replace hunk recounting with apply --recount

Adds 'e/dit' action to interactive add command.

* jc/report-tracking (Sun Jul 6 02:54:56 2008 -0700) 5 commits
 + branch -r -v: do not spit out garbage
 + stat_tracking_info(): clear object flags used during counting
 + git-branch -v: show the remote tracking statistics
 + git-status: show the remote tracking statistics
 + Refactor "tracking statistics" code used by "git checkout"

Makes the "your branch is ahead of the tracked one by N commits" logic and
messages available to other commands; status and branch are updated.

----------------------------------------------------------------
[Actively Cooking]

* jc/rebase-orig-head (Tue Jul 8 00:12:22 2008 -0400) 2 commits
 + Documentation: mention ORIG_HEAD in am, merge, and rebase
 + Teach "am" and "rebase" to mark the original position with
   ORIG_HEAD

* ph/parseopt-step-blame (Wed Jul 9 23:38:34 2008 +0200) 18 commits
 + revisions: refactor handle_revision_opt into parse_revision_opt.
 + git-shortlog: migrate to parse-options partially.
 + git-blame: fix lapsus
 + git-blame: migrate to incremental parse-option [2/2]
 + git-blame: migrate to incremental parse-option [1/2]
 + revisions: split handle_revision_opt() from setup_revisions()
 + Merge branch 'jc/blame' (early part) into HEAD
 + parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
 + parse-opt: fake short strings for callers to believe in.
 + parse-opt: do not print errors on unknown options, return -2
   intead.
 + parse-opt: create parse_options_step.
 + parse-opt: Export a non NORETURN usage dumper.
 + parse-opt: have parse_options_{start,end}.
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

Became active again ;-) This probably is ready for 'master' already,
except for the last two which I only looked at the patch and have not
used heavily in production yet.

* jc/merge-theirs (Mon Jun 30 22:18:57 2008 -0700) 5 commits
 + Make "subtree" part more orthogonal to the rest of merge-
   recursive.
 + Teach git-pull to pass -X<option> to git-merge
 + Teach git-merge to pass -X<option> to the backend strategy module
 + git-merge-recursive-{ours,theirs}
 + git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends is updated so that you can
say "git merge -Xours -Xsubtree=foo/bar/baz -s recursive other" now.

* mv/merge-in-c (Mon Jul 7 19:24:20 2008 +0200) 15 commits
 + Build in merge
 + Fix t7601-merge-pull-config.sh on AIX
 + git-commit-tree: make it usable from other builtins
 + Add new test case to ensure git-merge prepends the custom merge
   message
 + Add new test case to ensure git-merge reduces octopus parents when
   possible
 + Introduce reduce_heads()
 + Introduce get_merge_bases_many()
 + Add new test to ensure git-merge handles more than 25 refs.
 + Introduce get_octopus_merge_bases() in commit.c
 + git-fmt-merge-msg: make it usable from other builtins
 + Move read_cache_unmerged() to read-cache.c
 + Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 + Move parse-options's skip_prefix() to git-compat-util.h
 + Move commit_list_count() to commit.c
 + Move split_cmdline() to alias.c

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

* js/apply-root (Sun Jul 6 18:36:01 2008 -0700) 3 commits
 + git-apply --directory: make --root more similar to GNU diff
 + apply --root: thinkofix.
 + Teach "git apply" to prepend a prefix with "--root=<root>"

* jc/reflog-expire (Sat Jun 28 22:24:49 2008 -0700) 2 commits
 + Make default expiration period of reflog used for stash infinite
 + Per-ref reflog expiry configuration

As 1.6.0 will be a good time to make backward incompatible changes, the
tip commit makes the default expiry period of stash 'never', unless you
configure them to expire explicitly using gc.refs/stash.* variables.
Needs consensus, but I am guessing that enough people would want stash
that does not expire.

* jk/pager-config (Thu Jul 3 07:46:57 2008 -0400) 1 commit
 + Allow per-command pager config

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

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet.  Perhaps
in 1.7.0.

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
 + Revert "Make clients ask for "git program" over ssh and local
   transport"
 + Make clients ask for "git program" over ssh and local transport

This is the "botched" one.  Will be resurrected during 1.7.0 or 1.8.0
timeframe.

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

----------------------------------------------------------------
[Stalled/Needs more work]

* sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
 . Migrate git-am to use git-sequencer
 . Add git-sequencer test suite (t3350)
 . Add git-sequencer prototype documentation
 . Add git-sequencer shell prototype

* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
 - [BROKEN wrt shallow clones] Ignore graft during object transfer

Cloning or fetching from a repository from grafts did not send objects
that are hidden by grafts, but the commits in the resulting repository do
need these to pass fsck.  This fixes object transfer to ignore grafts.

Another fix is needed to git-prune so that it ignores grafts but treats
commits that are mentioned in grafts as reachable.

* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
 - blame: show "previous" information in --porcelain/--incremental
   format
 - git-blame: refactor code to emit "porcelain format" output
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

The blame that finds where each line in the original lines moved to.  This
may help a GSoC project that wants to gather statistical overview of the
history.  The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).

The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.  The topics
meant to be merged to the maintenance series have "maint-" in their names.

I think most of the important stuff is already in 'next'.  Let's start
talking about closing the merge window for 1.6.0.

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

* sb/dashless (Sun Jul 13 15:36:15 2008 +0200) 3 commits
 - Make usage strings dash-less
 - t/: Use "test_must_fail git" instead of "! git"
 - t/test-lib.sh: exit with small negagive int is ok with
   test_must_fail

* mv/dashless (Fri Jul 11 02:12:06 2008 +0200) 4 commits
 - make remove-dashes: apply to scripts and programs as well, not
   just to builtins
 - git-bisect: use dash-less form on git bisect log
 - t1007-hash-object.sh: use quotes for the test description
 - t0001-init.sh: change confusing directory name

* sp/maint-bash-completion-optim (Mon Jul 14 00:22:03 2008 +0000) 1 commit
 + bash completion: Append space after file names have been completed

Early parts are already merged to 'master' and need to be merged down to
maint as well, as this is about a "performance bug" that has been with us
almost forever.

* ag/rewrite_one (Sat Jul 12 22:00:57 2008 +0400) 1 commit
 + Fix quadratic performance in rewrite_one.

* sp/win (Fri Jul 11 18:52:42 2008 +0200) 3 commits
 + We need to check for msys as well as Windows in add--interactive.
 + Convert CR/LF to LF in tag signatures
 + Fixed text file auto-detection: treat EOF character 032 at the end
   of file as printable

* js/merge-rr (Sat Jul 12 15:56:19 2008 +0100) 2 commits
 + Move MERGE_RR from .git/rr-cache/ into .git/
 + builtin-rerere: more carefully find conflict markers

* sb/rerere-lib (Wed Jul 9 14:58:57 2008 +0200) 2 commits
 + rerere: Separate libgit and builtin functions
 + builtin-rerere: more carefully find conflict markers

* ls/mailinfo (Sun Jul 13 20:30:12 2008 +0200) 3 commits
 - git-mailinfo: use strbuf's instead of fixed buffers
 - Add some useful functions for strbuf manipulation.
 - Make some strbuf_*() struct strbuf arguments const.

* gi/cherry-cache (Sat Jul 12 20:14:51 2008 -0700) 1 commit
 - cherry: cache patch-ids to avoid repeating work

This does not seem to pass tests even on its own.

* js/maint-pretty-mailmap (Sat Jul 12 00:28:18 2008 +0100) 1 commit
 + Add pretty format %aN which gives the author name, respecting
   .mailmap

* js/more-win (Sun Jul 13 22:31:23 2008 +0200) 6 commits
 - Allow add_path() to add non-existent directories to the path
 - Allow the built-in exec path to be relative to the command
   invocation path
 - Fix relative built-in paths to be relative to the command
   invocation
 + help (Windows): Display HTML in default browser using Windows'
   shell API
 + help.c: Add support for htmldir relative to git_exec_path()
 + Move code interpreting path relative to exec-dir to new function
   system_path()

The earlier parts are obvious; Dscho seemed to have some comments on the
later ones that are in 'pu'.

* lw/gitweb (Fri Jul 11 03:11:48 2008 +0200) 3 commits
 - gitweb: use new Git::Repo API, and add optional caching
 - Add new Git::Repo API
 - gitweb: add test suite with Test::WWW::Mechanize::CGI

This does not pass t9710, at least for me X-<.

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

* jc/rebase-orig-head (Tue Jul 8 00:12:22 2008 -0400) 2 commits
 + Documentation: mention ORIG_HEAD in am, merge, and rebase
 + Teach "am" and "rebase" to mark the original position with
   ORIG_HEAD

* jc/branch-merged (Tue Jul 8 17:55:47 2008 -0700) 3 commits
 + branch --merged/--no-merged: allow specifying arbitrary commit
 + branch --contains: default to HEAD
 + parse-options: add PARSE_OPT_LASTARG_DEFAULT flag

This builds on top of the parse-options enhancement series that
has been cooking in 'next' for some time.

* om/rerere-careful (Mon Jul 7 14:42:48 2008 +0200) 1 commit
 + builtin-rerere: more carefully find conflict markers

* ls/maint-mailinfo-patch-label (Thu Jul 10 23:41:33 2008 +0200) 1 commit
 + git-mailinfo: Fix getting the subject from the in-body [PATCH]
   line

----------------------------------------------------------------
[Actively Cooking]

* xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
 + Teach git-merge -X<option> again.
 + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
 + builtin-merge.c: use parse_options_step() "incremental parsing"
   machinery
 + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next

I've described what this is in a separate message.

* rs/imap (Wed Jul 9 22:29:02 2008 +0100) 5 commits
 - Documentation: Improve documentation for git-imap-send(1)
 - imap-send.c: more style fixes
 - imap-send.c: style fixes
 - git-imap-send: Support SSL
 - git-imap-send: Allow the program to be run from subdirectories of
   a git tree

Some people seem to prefer having this feature available also with gnutls.
If such a patch materializes soon, that would be good, but otherwise I'll
merge this as-is to 'next'.  Such an enhancement can be done in-tree on
top of this series.

* jc/merge-theirs (Mon Jun 30 22:18:57 2008 -0700) 5 commits
 + Make "subtree" part more orthogonal to the rest of merge-
   recursive.
 + Teach git-pull to pass -X<option> to git-merge
 + Teach git-merge to pass -X<option> to the backend strategy module
 + git-merge-recursive-{ours,theirs}
 + git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends is updated so that you can
say "git merge -Xours -Xsubtree=foo/bar/baz -s recursive other" now.

* mv/merge-in-c (Sun Jul 13 08:13:55 2008 +0000) 19 commits
 + reduce_heads(): thinkofix
 + Add a new test for git-merge-resolve
 + t6021: add a new test for git-merge-resolve
 + Teach merge.log to "git-merge" again
 + Build in merge
 + Fix t7601-merge-pull-config.sh on AIX
 + git-commit-tree: make it usable from other builtins
 + Add new test case to ensure git-merge prepends the custom merge
   message
 + Add new test case to ensure git-merge reduces octopus parents when
   possible
 + Introduce reduce_heads()
 + Introduce get_merge_bases_many()
 + Add new test to ensure git-merge handles more than 25 refs.
 + Introduce get_octopus_merge_bases() in commit.c
 + git-fmt-merge-msg: make it usable from other builtins
 + Move read_cache_unmerged() to read-cache.c
 + Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 + Move parse-options's skip_prefix() to git-compat-util.h
 + Move commit_list_count() to commit.c
 + Move split_cmdline() to alias.c

Sverre seems to have a yet another fixup on top of this that came late and
I haven't looked at.

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

* js/pick-root (Fri Jul 4 16:19:52 2008 +0100) 1 commit
 + Allow cherry-picking root commits

* ab/bundle (Sat Jul 5 17:26:40 2008 -0400) 1 commit
 + Teach git-bundle to read revision arguments from stdin like git-
   rev-list.

* sg/stash-k-i (Tue Jul 8 00:40:56 2008 -0700) 2 commits
 + Documentation: tweak use case in "git stash save --keep-index"
 + stash: introduce 'stash save --keep-index' option

One weakness of our "partial commit" workflow support used to be that the
user can incrementally build what is to be committed in the index but that
state cannot be tested as a whole in the working tree.  This allows you to
temporarily stash the remaining changes in the working tree so that the
index state before running "stash save --keep-index" can be seen in the
working tree to be tested and then committed.

* am/stash-branch (Mon Jul 7 02:50:10 2008 +0530) 2 commits
 + Add a test for "git stash branch"
 + Implement "git stash branch <newbranch> <stash>"

Creates a new branch out of the stashed state, after returning from the
interrupt that forced you to create the stash in the first place.

* tr/add-i-e (Thu Jul 3 00:00:00 2008 +0200) 3 commits
 + git-add--interactive: manual hunk editing mode
 + git-add--interactive: remove hunk coalescing
 + git-add--interactive: replace hunk recounting with apply --recount

Adds 'e/dit' action to interactive add command.

* jc/report-tracking (Sun Jul 6 02:54:56 2008 -0700) 5 commits
 + branch -r -v: do not spit out garbage
 + stat_tracking_info(): clear object flags used during counting
 + git-branch -v: show the remote tracking statistics
 + git-status: show the remote tracking statistics
 + Refactor "tracking statistics" code used by "git checkout"

Makes the "your branch is ahead of the tracked one by N commits" logic and
messages available to other commands; status and branch are updated.

* ph/parseopt-step-blame (Wed Jul 9 23:38:34 2008 +0200) 18 commits
 + revisions: refactor handle_revision_opt into parse_revision_opt.
 + git-shortlog: migrate to parse-options partially.
 + git-blame: fix lapsus
 + git-blame: migrate to incremental parse-option [2/2]
 + git-blame: migrate to incremental parse-option [1/2]
 + revisions: split handle_revision_opt() from setup_revisions()
 + Merge branch 'jc/blame' (early part) into HEAD
 + parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
 + parse-opt: fake short strings for callers to believe in.
 + parse-opt: do not print errors on unknown options, return -2
   intead.
 + parse-opt: create parse_options_step.
 + parse-opt: Export a non NORETURN usage dumper.
 + parse-opt: have parse_options_{start,end}.
 + git-blame --reverse
 + builtin-blame.c: allow more than 16 parents
 + builtin-blame.c: move prepare_final() into a separate function.
 + rev-list --children
 + revision traversal: --children option

Became active again ;-) This probably is ready for 'master' already,
except for the last two which I only looked at the patch and have not
used heavily in production yet.

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

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet.  Perhaps
in 1.7.0.

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
 + Revert "Make clients ask for "git program" over ssh and local
   transport"
 + Make clients ask for "git program" over ssh and local transport

This is the "botched" one.  Will be resurrected during 1.7.0 or 1.8.0
timeframe.

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

----------------------------------------------------------------
[Stalled/Needs more work]

* sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
 . Migrate git-am to use git-sequencer
 . Add git-sequencer test suite (t3350)
 . Add git-sequencer prototype documentation
 . Add git-sequencer shell prototype

* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
 - [BROKEN wrt shallow clones] Ignore graft during object transfer

Cloning or fetching from a repository from grafts did not send objects
that are hidden by grafts, but the commits in the resulting repository do
need these to pass fsck.  This fixes object transfer to ignore grafts.

Another fix is needed to git-prune so that it ignores grafts but treats
commits that are mentioned in grafts as reachable.

* 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 is for peeling to see what's behind the blamed commit, which may or
may not help applications like gitweb.

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

[Junio C Hamano]

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

> * lw/gitweb (Fri Jul 11 03:11:48 2008 +0200) 3 commits
>  - gitweb: use new Git::Repo API, and add optional caching
>  - Add new Git::Repo API
>  - gitweb: add test suite with Test::WWW::Mechanize::CGI
>
> This does not pass t9710, at least for me X-<.

This is getting a bit boring and tiresome.  Obviously I haven't checked
what _else_ is missing because I did not install Carp::Always myself to my
system.

 t/t9710-perl-git-repo.sh |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/t9710-perl-git-repo.sh b/t/t9710-perl-git-repo.sh
index ca67b87..2da3cd8 100755
--- a/t/t9710-perl-git-repo.sh
+++ b/t/t9710-perl-git-repo.sh
@@ -6,8 +6,8 @@
 test_description='perl interface (Git/*.pm)'
 . ./test-lib.sh
 
-perl -MTest::More -e 0 2>/dev/null || {
-	say_color skip "Perl Test::More unavailable, skipping test"
+perl -MTest::More -MTest::Exception -MCarp::Always -e 0 2>/dev/null || {
+	say_color skip "Perl Test::{More,Exception}, Carp::Always unavailable, skipping test"
 	test_done
 }
 

Closing the merge window for 1.6.0

[Junio C Hamano]

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

> I think most of the important stuff is already in 'next'.  Let's start
> talking about closing the merge window for 1.6.0.

I think by the time we declare -rc0, we will have merged everything we
have in "Actively Cooking" list from tonight, perhaps except for the
"merge -Xtheirs", as there do not seem to be wide support for this
feature.  All the Windows bits and myriad of s/git-foo/git foo/ patches
submitted over the weekend and queued in next/pu, and various smallish
topics in "New Topics" list will hopefully all appear in 1.6.0.

In essence, I am saying that the merge window is more-or-less closed, from
the point of view of "what will be in, and what won't be"; of course some
of the topics may not be merged in their current shape without further
fixes.

The reason I say more-or-less is because I am aware of a handful of
patches that are not even in 'pu' yet:

 * A few patches from Mark Levedahl on git-submodule are still held in my
   inbox; I haven't decided what to do with them.

    Date: Wed,  9 Jul 2008 21:05:40 -0400
    Subject: [PATCH] git-submodule - make "submodule add" more strict, and document it
    Message-Id: <1215651941-3460-1-git-send-email-mlevedahl@gmail.com>

    Date: Wed,  9 Jul 2008 21:05:41 -0400
    Subject: [PATCH] git-submodule - register submodule URL if adding in place
    Message-ID: <1215651941-3460-2-git-send-email-mlevedahl@gmail.com>

   These two appeared at the end of a discussion, and as far as I can see,
   there wasn't any objection to them.  Unless somebody makes a convincing
   argument against them, I am inclined to include them in 1.6.0

 * Starting bisect with a forked good and bad pair, from Christian Couder,
   is not queued yet.  I think it is just the matter of Christian
   resending the two patches squashed (or me applying them while squashing
   them myself) --- I was busy cutting 1.5.6.3 release and tending other
   topics, and haven't got around to do so.

    Date: Thu, 10 Jul 2008 05:41:52 +0200
    Subject: [PATCH] bisect: test merge base if good rev is not an ancestor of bad rev
    Message-Id: <20080710054152.b051989c.chriscool@tuxfamily.org>

 * Alice and Bob prompt in tutorial, from Ian Katz, is not queued; they
   should be safe to directly apply to 'master'.  The only reason why I
   haven't is because it takes a lot of time to generate and concentration
   to eyeball the documentation markups to catch mistakes.

    Date: Thu, 10 Jul 2008 14:27:30 -0400
    Subject: Re: [PATCH] tutorial: prefix the prompts with names alice or bob,
	to make it clear who is doing what
    Message-ID: <dc5b80bf0807101127q63e3132fw207baf0d88db3d9d@mail.gmail.com>

    Subject: [PATCH] tutorial: clarify "pull" is "fetch + merge"
    Date: Thu, 10 Jul 2008 14:01:57 -0700
    Message-ID: <7vskuho3lm.fsf_-_@gitster.siamese.dyndns.org>

 * A git-svn patch from João Abecasis; I am waiting for Eric to act on it.

    Subject: [PATCH] git-svn: find-rev and rebase for SVN::Mirror repositories
    Date: Wed, 9 Jul 2008 03:08:27 +0100
    Message-ID: <7bf6f1d20807081908kdf9f615taa532ae579b457d7@mail.gmail.com>


Here is the draft release notes as of tonight.

----------------------------------------------------------------

GIT v1.6.0 Release Notes (draft)
================================

User visible changes
--------------------

With the default Makefile settings, most of the programs are now
installed outside your $PATH, except for "git", "gitk", "git-gui" and
some server side programs that need to be accessible for technical
reasons.  Invoking a git subcommand as "git-xyzzy" from the command
line has been deprecated since early 2006 (and officially announced in
1.5.4 release notes); use of them from your scripts after adding
output from "git --exec-path" to the $PATH is still supported in this
release, but users are again strongly encouraged to adjust their
scripts to use "git xyzzy" form, as we will stop installing
"git-xyzzy" hardlinks for built-in commands in later releases.

Source changes needed for porting to MinGW environment are now all in the
main git.git codebase.

By default, packfiles created with this version uses delta-base-offset
encoding introduced in v1.4.4.  Pack idx files are using version 2 that
allows larger packs and added robustness thanks to its CRC checking,
introduced in v1.5.2.

GIT_CONFIG, which was only documented as affecting "git config", but
actually affected all git commands, now only affects "git config".
GIT_LOCAL_CONFIG, also only documented as affecting "git config" and
not different from GIT_CONFIG in a useful way, is removed.

An ancient merge strategy "stupid" has been removed.


Updates since v1.5.6
--------------------

(subsystems)

* git-p4 in contrib learned "allowSubmit" configuration to control on
  which branch to allow "submit" subcommand.

* git-gui learned to stage changes per-line.

(portability)

* Changes for MinGW port have been merged, thanks to Johannes Sixt and
  gangs.

* Sample hook scripts shipped in templates/ are now suffixed with
  *.sample.  We used to prevent them from triggering by default by
  relying on the fact that we install them as unexecutable, but on
  some filesystems this approach does not work.  Instead of running
  "chmod +x" on them, the users who want to activate these samples
  as-is can now rename them dropping *.sample suffix.

* perl's in-place edit (-i) does not work well without backup files on Windows;
  some tests are rewritten to cope with this.

(documentation)

* Updated howto/update-hook-example

* Got rid of usage of "git-foo" from the tutorial and made typography
  more consistent.

* Disambiguating "--" between revs and paths is finally documented.

(performance, robustness, sanity etc.)

* even more documentation pages are now accessible via "man" and "git help".

* reduced excessive inlining to shrink size of the "git" binary.

* verify-pack checks the object CRC when using version 2 idx files.

* When an object is corrupt in a pack, the object became unusable even
  when the same object is available in a loose form,  We now try harder to
  fall back to these redundant objects when able.  In particular, "git
  repack -a -f" can be used to fix such a corruption as long as necessary
  objects are available.

* git-clone does not create refs in loose form anymore (it behaves as
  if you immediately ran git-pack-refs after cloning).  This will help
  repositories with insanely large number of refs.

* core.fsyncobjectfiles configuration can be used to ensure that the loose
  objects created will be fsync'ed (this is only useful on filesystems
  that does not order data writes properly).

* "git commit-tree" plumbing can make Octopus with more than 16 parents.
  "git commit" has been capable of this for quite some time.

(usability, bells and whistles)

* A new environment variable GIT_CEILING_DIRECTORIES can be used to stop
  the discovery process of the toplevel of working tree; this may be useful
  when you are working in a slow network disk and are outside any working tree,
  as bash-completion and "git help" may still need to run in these places.

* By default, stash entries never expire.  Set reflogexpire in [gc
  "refs/stash"] to a reasonable value to get traditional auto-expiration
  behaviour back

* Longstanding latency issue with bash completion script has been
  addressed.  This will need to be backmerged to 'maint' later.

* pager.<cmd> configuration variable can be used to enable/disable the
  default paging behaviour per command.

* "git-add -i" has a new action 'e/dit' to allow you edit the patch hunk
  manually.

* git-apply can handle a patch that touches the same path more than once
  much better than before.

* git-apply can be told not to trust the line counts recorded in the input
  patch but recount, with the new --recount option.

* git-apply can be told to apply a patch to a path deeper than what the
  patch records with --directory option.

* git-archive can be told to omit certain paths from its output using
  export-ignore attributes.

* With -v option, git-branch describes the remote tracking statistics
  similar to the way git-checkout reports by how many commits your branch
  is ahead/behind.

* git-bundle can read the revision arguments from the standard input.

* git-cherry-pick can replay a root commit now.

* git-clone can clone from a remote whose URL would be rewritten by
  configuration stored in $HOME/.gitconfig now.

* git-diff --check now checks leftover merge conflict markers.

* When remote side used to have branch 'foo' and git-fetch finds that now
  it has branch 'foo/bar', it refuses to lose the existing remote tracking
  branch and its reflog.  The error message has been improved to suggest
  pruning the remote if the user wants to proceed and get the latest set
  of branches from the remote, including such 'foo/bar'.

* fast-export learned to export and import marks file; this can be used to
  interface with fast-import incrementally.

* "git rerere" can be told to update the index with auto-reused resolution
  with rerere.autoupdate configuration variable.

* git-rev-list learned --children option to show child commits it
  encountered during the traversal, instead of shoing parent commits.

* git-send-mail can talk not just over SSL but over TLS now.

* "git-stash save" learned --keep-index option.  This lets you stash away the
  local changes and bring the changes staged in the index to your working
  tree for examination and testing.

* git-stash also learned branch subcommand to create a new branch out of
  stashed changes.

* git-status gives the remote tracking statistics similar to the way
  git-checkout reports by how many commits your branch is ahead/behind.

* You can tell "git status -u" to even more aggressively omit checking
  untracked files with --untracked-files=no.

* Original SHA-1 value for "update-ref -d" is optional now.

* Error codes from gitweb are made more descriptive where possible, rather
  than "403 forbidden" as we used to issue everywhere.

(internal)


Fixes since v1.5.6
------------------

All of the fixes in v1.5.6 maintenance series are included in
this release, unless otherwise noted.

 * "git fetch" into an empty repository used to remind the fetch will
   be huge by saying "no common commits", but it is already known by
   the user anyway (need to backport 8cb560f to 'maint').

---
exec >/var/tmp/1
O=v1.5.6.3-315-g10ce020
echo O=$(git describe refs/heads/master)
git shortlog --no-merges $O..refs/heads/master ^refs/heads/maint

Re: Closing the merge window for 1.6.0

[Johannes Sixt]

Junio C Hamano schrieb:
> * git-gui learned to stage changes per-line.

This has usability issues. In particular, it is impossible to stage only
the change "old1"->"new1" or unstage the change "old2"->"new2" of this hunk:

	@@ -1,4 +1,4 @@
	 ctxt1
	-old1
	-old2
	+new1
	+new2
	 ctxt2

Being able to do that was one of the goals, and I missed it :-( Since
that's my personal itch, I'll come up with a patch rather sooner than later.

-- Hannes

Re: Closing the merge window for 1.6.0

[Jakub Narebski]

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


> GIT v1.6.0 Release Notes (draft)
> ================================

> * By default, stash entries never expire.  Set reflogexpire in [gc
>   "refs/stash"] to a reasonable value to get traditional auto-expiration
>   behaviour back

And, of course, one can set up reflog expiration per ref or per 
ref type (for example never expiring stash, making expiration for
HEAD longer than default, and for remote-tracking branches shorter).
 

> * git-stash also learned branch subcommand to create a new branch out of
>   stashed changes.

Typography: wouldn't it be better to use "learned 'branch' subcommand"?
 
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Closing the merge window for 1.6.0

[Petr Baudis]

On Mon, Jul 14, 2008 at 12:50:48AM -0700, Junio C Hamano wrote:
> By default, packfiles created with this version uses delta-base-offset
> encoding introduced in v1.4.4.  Pack idx files are using version 2 that
> allows larger packs and added robustness thanks to its CRC checking,
> introduced in v1.5.2.

Oh, I thought this was some earlier change when I noticed it few days
ago on repo.or.cz, but seems there is still a chance to turn this over -
please reconsider...? :-)

Can't we by default use the version 2 only in case we actually _need_ to
store the larger packs? The CRC checking may be nice, but not critical,
and we could wait a bit more with it yet.

I'm saying this because I believe the best conservative upper bound for
backwards compatibility is Git version in Debian stable. It gets
probably the most stale from all the widely used software distributions
using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which
fails miserably on the new packs:

Getting alternates list for http://repo.or.cz/r/repo.git/
Getting pack list for http://repo.or.cz/r/repo.git/
Getting index for pack 5111285cac0f895cd9367c9939ced68e2c43dcc0
error: non-monotonic index
/usr/bin/git-fetch: line 297: 30402 Segmentation fault git-http-fetch -v -a "$head" "$remote/"

P.S.: AFAIK new Debian stable release is scheduled on Fall.

-- 
				Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce

Re: Closing the merge window for 1.6.0

[Johannes Schindelin]

Hi,

On Mon, 14 Jul 2008, Petr Baudis wrote:

> I'm saying this because I believe the best conservative upper bound for 
> backwards compatibility is Git version in Debian stable. It gets 
> probably the most stale from all the widely used software distributions 
> using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which 
> fails miserably on the new packs.

Can't we just hit Debian's Git maintainer with a clue bat or a bus, 
whichever is easier, and force them to upgrade _in_ Etch?  It's not like 
we haven't had _several_ stable releases in-between.

Ciao,
Dscho

Re: Closing the merge window for 1.6.0

[Gerrit Pape]

On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
> On Mon, 14 Jul 2008, Petr Baudis wrote:
> > I'm saying this because I believe the best conservative upper bound for 
> > backwards compatibility is Git version in Debian stable. It gets 
> > probably the most stale from all the widely used software distributions 
> > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which 
> > fails miserably on the new packs.
> 
> Can't we just hit Debian's Git maintainer with a clue bat or a bus, 

Please don't.  It wouldn't help, rather the opposite I think, espacially
the bus.  We don't introduce new upstream versions into a Debian stable
release, there's a great effort done for each stable release to reach
high quality integration of all the software packages available in
Debian.  Once that status is reached, only security fixes and criticial
usability fixes are added.

The freeze of the packages for the next stable release is planned a few
days from now, so it looks like Debian 'lenny' will include git 1.5.6.x.

Regards, Gerrit.

Re: Closing the merge window for 1.6.0

[Johannes Schindelin]

Hi,

On Mon, 14 Jul 2008, Gerrit Pape wrote:

> On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
> > On Mon, 14 Jul 2008, Petr Baudis wrote:
> > > I'm saying this because I believe the best conservative upper bound for 
> > > backwards compatibility is Git version in Debian stable. It gets 
> > > probably the most stale from all the widely used software distributions 
> > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which 
> > > fails miserably on the new packs.
> > 
> > Can't we just hit Debian's Git maintainer with a clue bat or a bus, 
> 
> Please don't.  It wouldn't help, rather the opposite I think, espacially
> the bus.

Heh.  It was a feeble attempt at humor production ;-)

> We don't introduce new upstream versions into a Debian stable release, 
> there's a great effort done for each stable release to reach high 
> quality integration of all the software packages available in Debian.  
> Once that status is reached, only security fixes and criticial usability 
> fixes are added.

If that is the case, we might need to think about fixing that segmentation 
fault to 1.4.4.5...  Which would be a minor pain in the donkey, I guess.

> The freeze of the packages for the next stable release is planned a few 
> days from now, so it looks like Debian 'lenny' will include git 1.5.6.x.

>From my memories of IRC, it seems that quite a few people do not even 
consider upgrading.

Ciao,
Dscho

Re: Closing the merge window for 1.6.0

[Nicolas Pitre]

On Mon, 14 Jul 2008, Gerrit Pape wrote:

> On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
> > On Mon, 14 Jul 2008, Petr Baudis wrote:
> > > I'm saying this because I believe the best conservative upper bound for 
> > > backwards compatibility is Git version in Debian stable. It gets 
> > > probably the most stale from all the widely used software distributions 
> > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which 
> > > fails miserably on the new packs.
> > 
> > Can't we just hit Debian's Git maintainer with a clue bat or a bus, 
> 
> Please don't.  It wouldn't help, rather the opposite I think, espacially
> the bus.  We don't introduce new upstream versions into a Debian stable
> release, there's a great effort done for each stable release to reach
> high quality integration of all the software packages available in
> Debian.  Once that status is reached, only security fixes and criticial
> usability fixes are added.

Please consider it as a critical usability problem.

Maybe we can release 1.4.5 with the ability to read index v2?  That 
wouldn't be hard to backport the reading part of it.


Nicolas

Re: Closing the merge window for 1.6.0

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> On Mon, 14 Jul 2008, Gerrit Pape wrote:
>
>> On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
>> > On Mon, 14 Jul 2008, Petr Baudis wrote:
>> > > I'm saying this because I believe the best conservative upper bound for 
>> > > backwards compatibility is Git version in Debian stable. It gets 
>> > > probably the most stale from all the widely used software distributions 
>> > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which 
>> > > fails miserably on the new packs.
>> > 
>> > Can't we just hit Debian's Git maintainer with a clue bat or a bus, 
>> 
>> Please don't.  It wouldn't help, rather the opposite I think, espacially
>> the bus.  We don't introduce new upstream versions into a Debian stable
>> release, there's a great effort done for each stable release to reach
>> high quality integration of all the software packages available in
>> Debian.  Once that status is reached, only security fixes and criticial
>> usability fixes are added.
>
> Please consider it as a critical usability problem.
>
> Maybe we can release 1.4.5 with the ability to read index v2?  That 
> wouldn't be hard to backport the reading part of it.

I am of two minds here.

On one hand, I am sympathetic to distros that want to give long time
support for ancient versions to keep working in an ever-changing new
world.  It is a wonderful thing that there are distros that aim for ultra
conservative stability, and I applaud them.

But as the upstream, we have our own deprecation schedule.  We should of
course plan carefully not to harm existing users of our releases, but
frankly speaking, 18 months since 1.4.4.4 was tagged (early January 2007)
is an eternity in git timescale.  Maybe we will slow down someday, and
this 18-month is not a set-in-stone rule in any way, but at this point
even without the packfile format issues, I personally think anything
before 1.5.0 is irrelevant --- maybe they are interesting as historical
curiosities, but not more than that.

We could:

	$ git checkout -b maint-1.4 v1.4.4.4
        $ git merge maint
        $ git tag v1.4.4.5

and push the result out.  While I would imagine that the end-user
experience after such a maintenance release would be very positive, that
is not something distros who really want to stay with a stale version for
a good reason would want to swallow ;-).

If we _were_ to keep v1.4.4.X series alive, serious backporting efforts
will be necessary.  For example, recent 'git-shell' futureproofing was
made not just to 1.5.6.X series but was backported to 1.5.4.X and 1.5.5.X,
and we would probably need to give it to 1.4.4.X as well.  What other
things are there that are missing in 1.4.4.X?  It would take nontrivial
engineering resource to even list them, let alone assessing how much
effort is required for such backporting and actually doing it.

The remotes/ layout, use of "git-add" for new contents (instead of only
new files), reflogs, detached HEAD, --pretty=format:%<blah>, bundles,
mergetool,...  all the things that a modern git workflow revolves around
and are described in the user manuals the users find on the net are not
found in 1.4.4.X series.  If a user of such a conservative distro needs to
work with a repository prepared on another platform with newer git,
perhaps crossmounted, should we backport "git branch -r" so that the user
can confortably work with remote tracking branches?  Should we backport
reflogs?

If a distro chooses to support its users whom they force to pin at 1.4.4.X
series, it's primarily _their_ choice.  I do not mind helping them in such
a backport, but the request has to come from the distro first with a
specific list of items that need to be supported.

Re: Closing the merge window for 1.6.0

[Teemu Likonen]

Junio C Hamano wrote (2008-07-14 12:00 -0700):

> Nicolas Pitre <nico@cam.org> writes:
> 
> > On Mon, 14 Jul 2008, Gerrit Pape wrote:

> >> > On Mon, 14 Jul 2008, Petr Baudis wrote:
> >> > > I'm saying this because I believe the best conservative upper
> >> > > bound for backwards compatibility is Git version in Debian
> >> > > stable. It gets 

> > Please consider it as a critical usability problem.
> >
> > Maybe we can release 1.4.5 with the ability to read index v2?  That
> > wouldn't be hard to backport the reading part of it.

> I am of two minds here.
> 
> On one hand, I am sympathetic to distros that want to give long time
> support for ancient versions to keep working in an ever-changing new
> world.  It is a wonderful thing that there are distros that aim for
> ultra conservative stability, and I applaud them.
> 
> But as the upstream, we have our own deprecation schedule.

As Debian stable (4.0 "Etch") and its git 1.4.4.4 was mentioned I'd like
to point out that git 1.5.6 is available for Etch users from
kind-of-semi-official <www.backports.org>. So I guess Debian stable
users aren't left completely behind. Git's web page already advertises
backports.org version for Etch.

Re: Closing the merge window for 1.6.0

[Martin Langhoff]

On Tue, Jul 15, 2008 at 7:19 AM, Teemu Likonen <tlikonen@iki.fi> wrote:
>> But as the upstream, we have our own deprecation schedule.
>
> As Debian stable (4.0 "Etch") and its git 1.4.4.4 was mentioned I'd like
> to point out that git 1.5.6 is available for Etch users from
> kind-of-semi-official <www.backports.org>. So I guess Debian stable
> users aren't left completely behind. Git's web page already advertises
> backports.org version for Etch.

I concur. Users of git on Etch are using backports AFAIK.

We still have the case of the "casual" user, who does not know much
about git, but installs it to clone & review a project's code. There,
if v1.4.4 complains with a useful message, the casual user will swear
a bit and grab a backport. If it dies a horrible uninformative death,
then we will get  bogus bug reports, flamage, the works.

cheers,



m
-- 
 martin.langhoff@gmail.com
 martin@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

Re: Closing the merge window for 1.6.0

[Petr Baudis]

On Mon, Jul 14, 2008 at 12:00:54PM -0700, Junio C Hamano wrote:
> But as the upstream, we have our own deprecation schedule.  We should of
> course plan carefully not to harm existing users of our releases, but
> frankly speaking, 18 months since 1.4.4.4 was tagged (early January 2007)
> is an eternity in git timescale.  Maybe we will slow down someday, and
> this 18-month is not a set-in-stone rule in any way, but at this point
> even without the packfile format issues, I personally think anything
> before 1.5.0 is irrelevant --- maybe they are interesting as historical
> curiosities, but not more than that.

Really, I think this is should be put into certain perspective:

	(i) This change is special since it affects client-server
	compatibility in bare repositories. AFAIK, none of the others
	you mention does this.

	(ii) The CRC checking is perhaps quite an improvement, but I
	don't think it is critical-to-have-just-now.

	(iii) Most importantly, this is not about waiting another few
	years for Debian to catch up, since the next stable release
	should really be upcoming rather soon:

		http://debian-community.org/LennyReleaseSchedule/

	(iv) These problems do not concern people who are currently
	_actively_ _working_ with Git; these people hopefully do not
	use 1.4 willingly and already use Git from backports.org.
	This is about user experience for casual users who are quite
	possibly interested only in read-only tracking of upstream
	using Git - these people will likely use default Debian Git
	version and that is okay, because frankly, for them, the
	1.5 improvements do not really matter much. This is also
	large class of prospective future real Git users and we might
	not want to ruin Git's reputation in their eyes.

-- 
				Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce

Re: Closing the merge window for 1.6.0

[Dmitry Potapov]

On Tue, Jul 15, 2008 at 11:20:23AM +0200, Petr Baudis wrote:
> 
> 	(iii) Most importantly, this is not about waiting another few
> 	years for Debian to catch up, since the next stable release
> 	should really be upcoming rather soon:
> 
> 		http://debian-community.org/LennyReleaseSchedule/

Even if Lenny will be released right on the scheduler (which I seriously
doubt), Etch will be around for another year. In fact, the last release
of oldstable (sarge) happened on April 12 this year.  Thus delaying of
indexversion=2 does not help much here. Anyone who is more or less
seriously about using Git grabs it from backports. The downside of
delaying is that any incompatible changes are much less welcome by users
during minor releases than major ones. People tend to read release notes
during major releases more carefully and think whether they prefer new
features or backward compatibility. This choice will not be the same for
anyone, but changing default settings on the major release is much more
appropriate than during minor ones.

> 
> 	(iv) These problems do not concern people who are currently
> 	_actively_ _working_ with Git; these people hopefully do not
> 	use 1.4 willingly and already use Git from backports.org.
> 	This is about user experience for casual users who are quite
> 	possibly interested only in read-only tracking of upstream
> 	using Git - these people will likely use default Debian Git
> 	version and that is okay, because frankly, for them, the
> 	1.5 improvements do not really matter much. This is also
> 	large class of prospective future real Git users and we might
> 	not want to ruin Git's reputation in their eyes.

I disagree. It is not Git does not support the old format, but it
switches on the new one as default on the next major release, which
is a sensible thing to do. Those repos that think that access for
Git 1.4 users is important for them can set indexformat=1. As to
prospective future real Git users, anyone who is trying to use Git
1.4 is going to hit by many usability issues that were resolved in
1.5; and there is no community support for Git 1.4 either -- you can
ask about any problem with Git 1.4 on this list, and the only answer
you'll get is that you should upgrade your Git. So, there is no way
for newcommers to start using Git 1.4 and be satisfied with it.

Finally, 18 months since 1.4.4 may not appear as a long time ago for
other projects that are being developed for many years, but for Git,
which was only 21 months when Git 1.4.4 was released, 18 months is
really very *long* time ago.

Dmitry

Re: Closing the merge window for 1.6.0

[Johannes Schindelin]

Hi,

On Tue, 15 Jul 2008, Dmitry Potapov wrote:

> Those repos that think that access for Git 1.4 users is important for 
> them can set indexformat=1.

Unfortunately, you place quite a high maintenance burden on the repository 
maintainers here.

>From the time balance sheet, it does not look good at all: a few minutes 
for Junio to change and commit, up to a few hours (because they missed it 
in the release notes) for probably more than hundred repository 
maintainers that are not subscribed to the Git mailing list.

And I absolutely agree with Pasky that this does _nothing_ in the vague 
direction of wielding a reputation of being easy to use.

Sure, we can make it easy on ourselves.  And it is just as easy to make it 
hard on others.  If you're okay with that, I am not.

Ciao,
Dscho

Re: Closing the merge window for 1.6.0

[Avery Pennarun]

On 7/15/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>  On Tue, 15 Jul 2008, Dmitry Potapov wrote:
>  > Those repos that think that access for Git 1.4 users is important for
>  > them can set indexformat=1.
>
> Unfortunately, you place quite a high maintenance burden on the repository
>  maintainers here.
>
>  From the time balance sheet, it does not look good at all: a few minutes
>  for Junio to change and commit, up to a few hours (because they missed it
>  in the release notes) for probably more than hundred repository
>  maintainers that are not subscribed to the Git mailing list.

To take this in a slightly different direction, what exactly is the
benefit of the new feature?  Apparently my git doesn't have it enabled
by default, and git works fine for me.  Am I missing out on something
that I should feel inferior about if my non-debian-etch running
friends(*) found out about it? :)

Have fun,

Avery

(*) Actually I compile my own git from source anyway.  I never want to
live without "git rebase -i" and "git add -p" ever again.  Life is too
short! :)

Re: Closing the merge window for 1.6.0

[Nicolas Pitre]

On Tue, 15 Jul 2008, Johannes Schindelin wrote:

> And I absolutely agree with Pasky that this does _nothing_ in the vague 
> direction of wielding a reputation of being easy to use.

Staying with git versions prior 1.5 isn't either.  In fact, git had a 
much harder time with its usability reputation in those days.  In other 
words, if some user of Debian is rebutted by the upgrade path for a later 
git version, then the awkwardness of git 1.4.4 UI will be even worse.

Anyway this is all hand waving until someone can come with some evidence 
that git 1.4.4 is actually used by a significant amount of people, and 
that those people depend on dumb transfer protocols.


Nicolas

Re: Closing the merge window for 1.6.0

[Sverre Rabbelier]

On Tue, Jul 15, 2008 at 6:26 PM, Nicolas Pitre <nico@cam.org> wrote:
> Anyway this is all hand waving until someone can come with some evidence
> that git 1.4.4 is actually used by a significant amount of people, and
> that those people depend on dumb transfer protocols.

Can't we add a msg to 1.4.4.x when it finds pack version 2 to upgrade
to 1.5.x? Gets rid of the problem all together while still giving the
user a reasonable message when it finds a repo version 2.
Hey, here's an idea, can't we have 1.4.4.x just give that msg for everything?

$cat git
#!/bin/sh

echo "Please upgrade to 1.5.x, version 1.4.x is no longer supported
nor should you even want to use it </cluebat>"

-- 
Cheers,

Sverre Rabbelier

Re: Closing the merge window for 1.6.0

[Petr Baudis]

On Tue, Jul 15, 2008 at 12:26:48PM -0400, Nicolas Pitre wrote:
> Anyway this is all hand waving until someone can come with some evidence 
> that git 1.4.4 is actually used by a significant amount of people, and 
> that those people depend on dumb transfer protocols.

That will be hard to produce. :-) _My_ personal story is that I have
Git-1.4.4.4 installed system-wide on repo.or.cz and follow git#next
locally, and quite panicked when I was inspecting some repositories
as root (using the system-wide Git) and these error messages popped up.
This may become a similar experience for others on multi-user systems
where people want to share work but don't realize that one of them has
Git installed locally and the other one doesn't. We can save them the
head-slapping and a bit of wasted life.

Out of interest, I did a simple statistics of HTTP user agents on
repo.or.cz; the dumb access does not seem very widely used overally,
it turns out. The stats begin at 19/May/2008:10:54:32 +0200. Here is the
breakdown, counting unique clients only:

# zgrep '"GET /r/.*/info/packs' /var/log/apache2/repo-access.log* | egrep -v bot\|slurp\|Gecko\|Opera |
	cut -d " " -f 1,12- | sed 's/\.g[a-f0-9]*\(\.dirty\)*"/"/' | sort -u |
	cut -d ' ' -f 2 | sort | uniq -c | sort -rn | head -n 50
   1501 "git/1.5.4.3"	<- Ubuntu Hardy (heh.. is just that it?)
    278 "git/1.5.5.1"	<- RHEL5 (ditto)
    151 "git/1.5.2.5"	<- Ubuntu Gutsy
    133 "git/1.5.5.3"	<- ? (maybe Gentoo ~x86 for some time)
    125 "git/1.5.4.5"	<- OpenSUSE 11.0, FC9, Gentoo x86, Dapper backports
    104 "git/1.5.6"	<- Debian Lenny
     94 "git/1.5.5"
     66 "git/1.5.3.7"
     63 "git/1.5.5.4"
     63 "git/1.5.5.1015"
     55 "git/1.5.2.4"	<- OpenSUSE 10.3
     51 "Mozilla/4.0 (compatible;)"	<- huh?
     42 "git/1.5.3.8"
     37 "git/1.5.5.GIT"
     37 "git/1.5.3.5.2229"
     34 "git/1.5.6.1"
     33 "git/1.5.3.6"	<- Feisty backports
     31 "git/1.5.4.1"
     30 "git/1.5.6.2"
     20 "git/1.5.6.GIT"
     18 "git/1.5.3"
     17 "git/1.5.2.2"
     17 "git/1.4.4.4"
     15 "git/1.5.6.1.1071"
     14 "git/1.5.3.3"
     13 "git/1.5.4.4"
     13 "git/1.5.4"
     11 "git/1.5.6.1062"
     11 "git/1.5.5.2"
     10 "git/1.5.5.1.316"

(I also got two 1.4.4.2 (feisty?) fetches from one client. No older
Git versions.)

So wrt. keeping backwards compatibility, this is not _very_ convincing,
I admit. ;-)

-- 
				Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce

Re: Closing the merge window for 1.6.0

[Dmitry Potapov]

On Tue, Jul 15, 2008 at 04:27:02PM +0100, Johannes Schindelin wrote:
> 
> >From the time balance sheet, it does not look good at all: a few minutes 
> for Junio to change and commit, up to a few hours (because they missed it 
> in the release notes) for probably more than hundred repository 
> maintainers that are not subscribed to the Git mailing list.

If you just grab sources and never read release notes, there is nothing
that can help you. If Git 1.6.0 is not the right moment to do these
changes then Git 1.6.1 is neither, regardless whether Debian will
release Lenny by that time or not. People do not upgrade their distro in
the day of release. Some upgraded to Etch not so long ago. So, should we
wait for another year till 1.7.0?

> 
> And I absolutely agree with Pasky that this does _nothing_ in the vague 
> direction of wielding a reputation of being easy to use.

I don't think Git 1.4 is easy to use. If you want Git that is easy to
use install Git 1.5.x. And, it is *much* easier to install Git from
backports then to deal with usability issues of Git 1.4 and the lack
of community support.  So, I don't see how this change may hurt.

> 
> Sure, we can make it easy on ourselves.  And it is just as easy to make it 
> hard on others.  If you're okay with that, I am not.

It has *nothing* to do with making easy on ourselves and hard on others.
The question here is what is the appropriate time to change these default
settings, and I believe that *major* releases are the appropriate time
while minor ones are not.


Dmitry

Re: Closing the merge window for 1.6.0

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Tue, 15 Jul 2008, Dmitry Potapov wrote:
>
>> Those repos that think that access for Git 1.4 users is important for 
>> them can set indexformat=1.
>
> Unfortunately, you place quite a high maintenance burden on the repository 
> maintainers here.
>
> From the time balance sheet, it does not look good at all: a few minutes 
> for Junio to change and commit, up to a few hours (because they missed it 
> in the release notes) for probably more than hundred repository 
> maintainers that are not subscribed to the Git mailing list.
>
> And I absolutely agree with Pasky that this does _nothing_ in the vague 
> direction of wielding a reputation of being easy to use.
>
> Sure, we can make it easy on ourselves.  And it is just as easy to make it 
> hard on others.  If you're okay with that, I am not.

I was not planning to comment on this issue further as the ball is in
Debian's court, but I think you are misguided.

We are not making anything hard on others.  Sticking to 1.4.4.4 codebase
is forced by Debian (for its policy) and choice made by its users (for not
knowing or using backports).  1.5.0 and later are vastly better and we
encourage users to update on every occassion we get.

I do not know the extent of the backporting effort necessary, the size of
potentially impacted population if Debian keeps shipping unpatched
1.4.4.4, nor how much Debian cares about supporting their 1.4.4.4 users
i.e. if they are willing and able to carry distro-only forward
compatibility patches, and knowing all of these is necessary before we
declare this is worth handling _ourselves_.  That is why I did not want to
take a definitive stance on this issue before hearing from the Debian
maintainer about them -- I said "Debian has to ask with list of items",
didn't I?

What troubles me the most is that you seem to be forgetting that we are
using git to manage our codebase.  Even if this turns out to be something
we would want to handle ourselves, it does not have to come from me.  If
you care that much, you could backport whatever change is appropriate to
keep 1.4.4.X codebase alive and arrange it to be published as 1.4.4.5.

In any case, it will _definitely_ *NOT* a few minutes of me nor anybody.
Release engineering takes quite a lot of time.

Re: Closing the merge window for 1.6.0

[Johannes Schindelin]

Hi,

On Tue, 15 Jul 2008, Junio C Hamano wrote:

> What troubles me the most is that you seem to be forgetting that we are 
> using git to manage our codebase.

I don't.  I have vivid memories of updating an ancient git repository of 
Git itself, which had some almost forgotten changes in it.  That was in 
the bad old days, when the version number did not even have a "1" in it.

It could not even fetch the current git.git.

I do _not_ want that to happen to anybody else, _even if_ we leave 1.4.4.4 
Behind as if it was an American Child.

Having said that, I do not have the resources to test and fix everything 
that may arise from Debian being seemingly unable to update to Git 1.5.  
So I agree completely that the ball is in Debian's half, and if they let 
it rot, it is sad, but I cannot help it.

Ciao,
Dscho

Re: Closing the merge window for 1.6.0

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Tue, 15 Jul 2008, Junio C Hamano wrote:
>
>> What troubles me the most is that you seem to be forgetting that we are 
>> using git to manage our codebase.
>
> I don't.  I have vivid memories of updating an ancient git repository of 
> Git itself, which had some almost forgotten changes in it.  That was in 
> the bad old days, when the version number did not even have a "1" in it.
>
> It could not even fetch the current git.git.
>
> I do _not_ want that to happen to anybody else, _even if_ we leave 1.4.4.4 
> Behind as if it was an American Child.

My reference to "git" was about "forking is easy".  We seem to have to
agree that talking is even cheaper, though ;-)

> Having said that, I do not have the resources to test and fix everything 
> that may arise from Debian being seemingly unable to update to Git 1.5.  

Heh, what happent to your earlier "a few minutes for Junio to change and
commit"?

Re: Closing the merge window for 1.6.0

[Johannes Schindelin]

Hi,

On Tue, 15 Jul 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > Having said that, I do not have the resources to test and fix 
> > everything that may arise from Debian being seemingly unable to update 
> > to Git 1.5.
> 
> Heh, what happent to your earlier "a few minutes for Junio to change and 
> commit"?

That was meant for the integration of the patch that makes the 
backwards-incompatible patch.

Not for the necessary forward-compatible changes.

Ciao,
Dscho

Re: Closing the merge window for 1.6.0

[Shawn O. Pearce]

Nicolas Pitre <nico@cam.org> wrote:
> On Mon, 14 Jul 2008, Gerrit Pape wrote:
> 
> > On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
> > > On Mon, 14 Jul 2008, Petr Baudis wrote:
> > > > I'm saying this because I believe the best conservative upper bound for 
> > > > backwards compatibility is Git version in Debian stable. It gets 
> > > > probably the most stale from all the widely used software distributions 
> > > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which 
> > > > fails miserably on the new packs.
> 
> Maybe we can release 1.4.5 with the ability to read index v2?  That 
> wouldn't be hard to backport the reading part of it.

If we consider that supporting 1.4.4.4 clients is still a priority,
due to the widespread distribution of that version in a popular
version of Debian, we shouldn't be rushing the index v2 or OFS_DELTA
functionality on by default in 1.6.0.  Instead we would wait until
Debian stable (and most other widely popular distributions) are on
a modern enough version of Git to understand this format.

Really.  As much as I'd love to see the switch to v2 made by default
I don't think we can/should do it unless the majority of the user
base will be able to grok it.  And Debian etch sounds like it won't.

-- 
Shawn.

Re: Closing the merge window for 1.6.0

[Nicolas Pitre]

On Tue, 15 Jul 2008, Shawn O. Pearce wrote:

> Nicolas Pitre <nico@cam.org> wrote:
> > On Mon, 14 Jul 2008, Gerrit Pape wrote:
> > 
> > > On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
> > > > On Mon, 14 Jul 2008, Petr Baudis wrote:
> > > > > I'm saying this because I believe the best conservative upper bound for 
> > > > > backwards compatibility is Git version in Debian stable. It gets 
> > > > > probably the most stale from all the widely used software distributions 
> > > > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which 
> > > > > fails miserably on the new packs.
> > 
> > Maybe we can release 1.4.5 with the ability to read index v2?  That 
> > wouldn't be hard to backport the reading part of it.
> 
> If we consider that supporting 1.4.4.4 clients is still a priority,
> due to the widespread distribution of that version in a popular
> version of Debian, we shouldn't be rushing the index v2 or OFS_DELTA
> functionality on by default in 1.6.0.  

OFS_DELTA is supported by 1.4.4.4 so that's a non issue.

> Instead we would wait until Debian stable (and most other widely 
> popular distributions) are on a modern enough version of Git to 
> understand this format.

I don't think we should have git development be dictated by some 
discutable policy from one distribution.

IMHO git prior 1.5.0 is so horrible as general usability goes, and so 
different from what everybody is discussing on the net, that no one sane 
should still be using it. Even ourselves (i.e. the git community) are 
not supporting git 1.4.4 anymore so this hardly can be a priority.

As far as I know, there is no other widely popular distribution other 
than Debian using git prior 1.5.0 in their latest release. If Debian 
people want to support git 1.4.4 although we called thatversion obsolete 
_long_ ago then that's their problem.  We should not be bound by that 
external policy to which we never agreed with.

Now I proposed a compromise which consists of making 1.4.4.4+1 able to 
cope with index v2.  That should fall into Debian's "major usability 
fix" category.  I think that is a far better compromize than delaying 
index v2 even further.

> Really.  As much as I'd love to see the switch to v2 made by default
> I don't think we can/should do it unless the majority of the user
> base will be able to grok it.  And Debian etch sounds like it won't.

I truly hope the majority of the user is _not_ using 1.4.4.4.  Otherwise 
I may only have pity for them.


Nicolas

Re: Closing the merge window for 1.6.0

[Petr Baudis]

  Hi,

On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
> On Mon, 14 Jul 2008, Petr Baudis wrote:
> 
> > I'm saying this because I believe the best conservative upper bound for 
> > backwards compatibility is Git version in Debian stable. It gets 
> > probably the most stale from all the widely used software distributions 
> > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which 
> > fails miserably on the new packs.
> 
> Can't we just hit Debian's Git maintainer with a clue bat or a bus, 
> whichever is easier, and force them to upgrade _in_ Etch?  It's not like 
> we haven't had _several_ stable releases in-between.

  the whole point of having a stable distribution is that random version
upgrades don't happen under your hands; sure, 1.4.4.4 can have plenty of
bugs, but it's buggy in a well-defined way, which is better than upgrade
to newer stable version, which may be less buggy, but in a different
way; also, by upgrading to newer version you might find various subtle
compatibility issues, etc.

  Upgrading to newer version, *especially* if it's over then 1.4 - 1.5
boundary, is not something you could seriously expect Debian to do.
At least I actually _hope_ so, as a sysadmin of a network of 40 etch
workstations.

-- 
				Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce

Re: Closing the merge window for 1.6.0

[Nick Andrew]

Petr Baudis <pasky <at> suse.cz> writes:

>   Upgrading to newer version, *especially* if it's over then 1.4 - 1.5
> boundary, is not something you could seriously expect Debian to do.
> At least I actually _hope_ so, as a sysadmin of a network of 40 etch
> workstations.

Perhaps Debian could add a "git1.5" package to the etch repository. That
will guarantee that no current etch users of git 1.4.4.4 will be affected,
and they can choose if they want, to install git1.5.

Nick.

Re: Closing the merge window for 1.6.0

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> Getting alternates list for http://repo.or.cz/r/repo.git/
> Getting pack list for http://repo.or.cz/r/repo.git/
> Getting index for pack 5111285cac0f895cd9367c9939ced68e2c43dcc0
> error: non-monotonic index
> /usr/bin/git-fetch: line 297: 30402 Segmentation fault git-http-fetch -v -a "$head" "$remote/"

Yeah, I think git-repack, git-gc, git-pack-objects and git-index-pack on
the server side need a knob to tell it to stay conservative because the
repository may be served over dumb protocols to avoid this problem.

That knob could even be called

	[repack]
        	usedeltabaseoffset = false
	[pack]
        	indexversion = 1

Re: Closing the merge window for 1.6.0

[Petr Baudis]

On Mon, Jul 14, 2008 at 12:16:26PM -0700, Junio C Hamano wrote:
> Yeah, I think git-repack, git-gc, git-pack-objects and git-index-pack on
> the server side need a knob to tell it to stay conservative because the
> repository may be served over dumb protocols to avoid this problem.
> 
> That knob could even be called
> 
> 	[repack]
>         	usedeltabaseoffset = false
> 	[pack]
>         	indexversion = 1

Can you please mention this in release notes? Until now, I actually
thought you're speaking about a hypothetical improvement, not a knob we
actually have. :-) (BTW, turning off the usedeltabaseoffset is not
critical at least Debian-wise, and I think that really is the oldest Git
in widespread use.)

Now, there is of course still the issue of default behaviour, but at
least my concern is somewhat eased now. :-)

-- 
				Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce

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

[Johannes Schindelin]

Hi,

On Sun, 13 Jul 2008, Junio C Hamano wrote:

> * js/more-win (Sun Jul 13 22:31:23 2008 +0200) 6 commits
>  - Allow add_path() to add non-existent directories to the path
>  - Allow the built-in exec path to be relative to the command
>    invocation path
>  - Fix relative built-in paths to be relative to the command
>    invocation
>  + help (Windows): Display HTML in default browser using Windows'
>    shell API
>  + help.c: Add support for htmldir relative to git_exec_path()
>  + Move code interpreting path relative to exec-dir to new function
>    system_path()
> 
> The earlier parts are obvious; Dscho seemed to have some comments on the
> later ones that are in 'pu'.

Just one, and it seems that the next patch patched that ;-)  Not really a 
showstopper.

> * mv/merge-in-c (Sun Jul 13 08:13:55 2008 +0000) 19 commits
>  + reduce_heads(): thinkofix

Hmm.  My earlier response to Sverre was based on an old "next", it seems.

Ciao,
Dscho

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

[Lea Wiemann]

Junio C Hamano wrote:
> * lw/gitweb (Fri Jul 11 03:11:48 2008 +0200) 3 commits
>  - Add new Git::Repo API
> 
> This does not pass t9710, at least for me X-<.

Yikes; I thought I had removed all instanced of Carp::Always (which I
had put in for development), but this one apparently slipped through.
It'll be fixed in the next version I post (which will also have the
dependency on the non-core Test::Exception package removed).

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

[Lea Wiemann]

Lea Wiemann wrote:
> It'll be fixed in the next version I post

By the way Junio, how do you prefer to get reposts of patch sequences?
Should I repost the whole sequence under a new common parent message, or
can I simply post v2 of each patch in the sequence as a followup to its
respective v1?

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

[Junio C Hamano]

Lea Wiemann <lewiemann@gmail.com> writes:

> Lea Wiemann wrote:
>> It'll be fixed in the next version I post
>
> By the way Junio, how do you prefer to get reposts of patch sequences?
> Should I repost the whole sequence under a new common parent message, or
> can I simply post v2 of each patch in the sequence as a followup to its
> respective v1?

I do not have major preference either way, but for a long series, I'd
prefer a resend to be independent from the previous series, i.e.

        [PATCH 0/3]
        .[PATCH 1/3]
        ..[PATCH 2/3]
        ...[PATCH 3/3]

        [PATCH 0/4 v2]
        .[PATCH 1/4 v2]
        ..[PATCH 2/4 v2]
        ...[PATCH 3/4 v2]
        ....[PATCH 4/4 v2]
        
I can live with the first one from the new series being a follow-up to the
first one from the old series, i.e.:

        [PATCH 0/3]
        .[PATCH 1/3]
        ..[PATCH 2/3]
        ...[PATCH 3/3]
        .[PATCH 0/4 v2]
        ..[PATCH 1/4 v2]
        ...[PATCH 2/4 v2]
        ....[PATCH 3/4 v2]
        .....[PATCH 4/4 v2]

but _not_ with this, i.e. N/M being followup to old N/M:

        [PATCH 0/3]
        .[PATCH 0/4 v2]
        .[PATCH 1/3]
        ..[PATCH 1/4 v2]
        ..[PATCH 2/3]
        ...[PATCH 2/4 v2]
        ...[PATCH 3/3]
        ....[PATCH 3/4 v2]
        .....[PATCH 4/4 v2]

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

[Geoffrey Irving]

On Sun, Jul 13, 2008 at 10:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Here are the topics that have been cooking.  Commits prefixed
> with '-' are only in 'pu' while commits prefixed with '+' are
> in 'next'.
>
> <snip>
>
> * gi/cherry-cache (Sat Jul 12 20:14:51 2008 -0700) 1 commit
>  - cherry: cache patch-ids to avoid repeating work
>
> This does not seem to pass tests even on its own.

The problem (beyond the basic problem of me not having tried running
the tests) is that the current caching code isn't taking into account
the changing values of diff_options.  t6007 computes a patch-id for a
commit with one value of options.paths, and then tries to compute a
_different_ patch-id for the same commit using a different value of
options.paths.

Here are a few different ways of fixing this:

1. Modify commit_patch_id in patch-ids.c to compute a sha1 of the
diff_options structure and xor it with the commit sha1 to get a truly
unique hash of the input.  This means the optimization can be safely
applied for all patch-id computations regardless of the diff_options.
I can add a diff_options_sha1 function in diff.[ch] to compute the
checksum.

2. Restrict commit_patch_id in patch-ids.c to apply the optimization
only if options.nr_paths is zero, and perhaps a few other conditions.
This is rather fragile, since it would mean that the cache would break
if someone decided to change the default diff options.

3. Add a flag in struct patch_ids defaulting to false which turns the
caching on or off, and manually set the flag to true in cmd_cherry.

I'd lean towards (1), but wanted to check before writing the code to
make sure that it's reasonable to treat diff_options as stable enough
that computing a sha1 hash of it makes sense.  According to "git help
patch-id", it is only "reasonable stable", which is sufficient as long
as we're confident that whenever the diff format changes, the
diff_options_sha1 function will be updated to reflect that change.

As an aside: is it correct that as long as the change is in pu, I
should be submitting complete (nonincremental) patches whenever I fix
bugs?

Thanks,
Geoffrey

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

[Johannes Schindelin]

Hi,

On Mon, 14 Jul 2008, Geoffrey Irving wrote:

> The problem (beyond the basic problem of me not having tried running the 
> tests) is that the current caching code isn't taking into account the 
> changing values of diff_options.  t6007 computes a patch-id for a commit 
> with one value of options.paths, and then tries to compute a _different_ 
> patch-id for the same commit using a different value of options.paths.
> 
> Here are a few different ways of fixing this:
> 
> 1. Modify commit_patch_id in patch-ids.c to compute a sha1 of the 
>    diff_options structure and xor it with the commit sha1 to get a truly 
>    unique hash of the input.  This means the optimization can be safely 
>    applied for all patch-id computations regardless of the diff_options.  
>    I can add a diff_options_sha1 function in diff.[ch] to compute the 
>    checksum.
> 
> 2. Restrict commit_patch_id in patch-ids.c to apply the optimization 
>    only if options.nr_paths is zero, and perhaps a few other conditions.  
>    This is rather fragile, since it would mean that the cache would 
>    break if someone decided to change the default diff options.

Funnily, (2) contradicts (1).  The patch id is _different_ when you have 
nr_paths > 0.  At least in the general case.

So what you propose in (1) will not work, unless you also hash the path 
names (in the correct order, otherwise you'll end up with two hashes).

OTOH I would be really surprised if you needed --cherry-pick with paths 
and/or diff options more than once for the same commits.  So the caching 
does not make sense to begin with (especially since we do not have a 
proper way of gc'ing it, right?).

So I'd suggest saving diff_opts before the command line parsing, and 
disable the cache when it is different _and/or_ (||) nr_paths.

Ciao,
Dscho

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

[Geoffrey Irving]

On Tue, Jul 15, 2008 at 2:22 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 14 Jul 2008, Geoffrey Irving wrote:
>
>> The problem (beyond the basic problem of me not having tried running the
>> tests) is that the current caching code isn't taking into account the
>> changing values of diff_options.  t6007 computes a patch-id for a commit
>> with one value of options.paths, and then tries to compute a _different_
>> patch-id for the same commit using a different value of options.paths.
>>
>> Here are a few different ways of fixing this:
>>
>> 1. Modify commit_patch_id in patch-ids.c to compute a sha1 of the
>>    diff_options structure and xor it with the commit sha1 to get a truly
>>    unique hash of the input.  This means the optimization can be safely
>>    applied for all patch-id computations regardless of the diff_options.
>>    I can add a diff_options_sha1 function in diff.[ch] to compute the
>>    checksum.
>>
>> 2. Restrict commit_patch_id in patch-ids.c to apply the optimization
>>    only if options.nr_paths is zero, and perhaps a few other conditions.
>>    This is rather fragile, since it would mean that the cache would
>>    break if someone decided to change the default diff options.
>
> Funnily, (2) contradicts (1).  The patch id is _different_ when you have
> nr_paths > 0.  At least in the general case.
>
> So what you propose in (1) will not work, unless you also hash the path
> names (in the correct order, otherwise you'll end up with two hashes).

The sha1 would include paths, of course, since it's part of diff_options.

> OTOH I would be really surprised if you needed --cherry-pick with paths
> and/or diff options more than once for the same commits.  So the caching
> does not make sense to begin with (especially since we do not have a
> proper way of gc'ing it, right?).
>
> So I'd suggest saving diff_opts before the command line parsing, and
> disable the cache when it is different _and/or_ (||) nr_paths.

I'll attach the patch to the other thread.

Geoffrey

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.  The topics
meant to be merged to the maintenance series have "maint-" in their names.

It so happens that the topics clearly separated between the ones that are
obviously ready for 1.6.0 and the others that aren't yet as of tonight.
It seems that it is a good time to draw that line and tag -rc0 tomorrow,
after merging the remaining topics in 'next'.

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

I could apply these directly to master, but I am just playing it safe.

* sp/maint-index-pack (Tue Jul 15 04:45:34 2008 +0000) 4 commits
 + index-pack: Honor core.deltaBaseCacheLimit when resolving deltas
 + index-pack: Track the object_entry that creates each base_data
 + index-pack: Chain the struct base_data on the stack for traversal
 + index-pack: Refactor base arguments of resolve_delta into a struct

* rs/rebase-checkout-not-so-quiet (Mon Jul 14 14:05:35 2008 -0700) 1 commit
 + git-rebase: report checkout failure

* ag/blame (Wed Jul 16 02:00:58 2008 +0400) 2 commits
 + Do not try to detect move/copy for entries below threshold.
 + Avoid rescanning unchanged entries in search for copies.

This gives a drastic performance improvement to "git-blame -C -C" with
quite straightforward and obvious code change.

* rs/archive (Mon Jul 14 21:22:05 2008 +0200) 6 commits
 + archive: remove extra arguments parsing code
 + archive: unify file attribute handling
 + archive: centralize archive entry writing
 + archive: add baselen member to struct archiver_args
 + add context pointer to read_tree_recursive()
 + archive: remove args member from struct archiver

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

* sb/dashless (Sun Jul 13 15:36:15 2008 +0200) 3 commits
 + Make usage strings dash-less
 + t/: Use "test_must_fail git" instead of "! git"
 + t/test-lib.sh: exit with small negagive int is ok with
   test_must_fail

* mv/dashless (Fri Jul 11 02:12:06 2008 +0200) 4 commits
 + make remove-dashes: apply to scripts and programs as well, not
   just to builtins
 + git-bisect: use dash-less form on git bisect log
 + t1007-hash-object.sh: use quotes for the test description
 + t0001-init.sh: change confusing directory name

* ls/mailinfo (Sun Jul 13 20:30:12 2008 +0200) 3 commits
 + git-mailinfo: use strbuf's instead of fixed buffers
 + Add some useful functions for strbuf manipulation.
 + Make some strbuf_*() struct strbuf arguments const.

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

* sp/maint-bash-completion-optim (Mon Jul 14 00:22:03 2008 +0000) 1 commit
 + bash completion: Append space after file names have been completed

Early parts were already merged to 'master' and need to be merged down to
maint as well, as this is about a "performance bug" that has been with us
almost forever.

* ag/rewrite_one (Sat Jul 12 22:00:57 2008 +0400) 1 commit
 + Fix quadratic performance in rewrite_one.

* sp/win (Fri Jul 11 18:52:42 2008 +0200) 3 commits
 + We need to check for msys as well as Windows in add--interactive.
 + Convert CR/LF to LF in tag signatures
 + Fixed text file auto-detection: treat EOF character 032 at the end
   of file as printable

* js/merge-rr (Sat Jul 12 15:56:19 2008 +0100) 2 commits
 + Move MERGE_RR from .git/rr-cache/ into .git/
 + builtin-rerere: more carefully find conflict markers

* sb/rerere-lib (Wed Jul 9 14:58:57 2008 +0200) 2 commits
 + rerere: Separate libgit and builtin functions
 + builtin-rerere: more carefully find conflict markers

* js/maint-pretty-mailmap (Sat Jul 12 00:28:18 2008 +0100) 1 commit
 + Add pretty format %aN which gives the author name, respecting
   .mailmap

* js/more-win (Sun Jul 13 22:31:23 2008 +0200) 3 commits
 + help (Windows): Display HTML in default browser using Windows'
   shell API
 + help.c: Add support for htmldir relative to git_exec_path()
 + Move code interpreting path relative to exec-dir to new function
   system_path()

* jc/rebase-orig-head (Tue Jul 8 00:12:22 2008 -0400) 2 commits
 + Documentation: mention ORIG_HEAD in am, merge, and rebase
 + Teach "am" and "rebase" to mark the original position with
   ORIG_HEAD

* jc/branch-merged (Tue Jul 8 17:55:47 2008 -0700) 3 commits
 + branch --merged/--no-merged: allow specifying arbitrary commit
 + branch --contains: default to HEAD
 + parse-options: add PARSE_OPT_LASTARG_DEFAULT flag

* om/rerere-careful (Mon Jul 7 14:42:48 2008 +0200) 1 commit
 + builtin-rerere: more carefully find conflict markers

* ls/maint-mailinfo-patch-label (Thu Jul 10 23:41:33 2008 +0200) 1 commit
 + git-mailinfo: Fix getting the subject from the in-body [PATCH]
   line

* mv/merge-in-c (Mon Jul 14 00:09:41 2008 -0700) 20 commits
 + reduce_heads(): protect from duplicate input
 + reduce_heads(): thinkofix
 + Add a new test for git-merge-resolve
 + t6021: add a new test for git-merge-resolve
 + Teach merge.log to "git-merge" again
 + Build in merge
 + Fix t7601-merge-pull-config.sh on AIX
 + git-commit-tree: make it usable from other builtins
 + Add new test case to ensure git-merge prepends the custom merge
   message
 + Add new test case to ensure git-merge reduces octopus parents when
   possible
 + Introduce reduce_heads()
 + Introduce get_merge_bases_many()
 + Add new test to ensure git-merge handles more than 25 refs.
 + Introduce get_octopus_merge_bases() in commit.c
 + git-fmt-merge-msg: make it usable from other builtins
 + Move read_cache_unmerged() to read-cache.c
 + Add new test to ensure git-merge handles pull.twohead and
   pull.octopus
 + Move parse-options's skip_prefix() to git-compat-util.h
 + Move commit_list_count() to commit.c
 + Move split_cmdline() to alias.c

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

* rs/imap (Wed Jul 9 22:29:02 2008 +0100) 5 commits
 - Documentation: Improve documentation for git-imap-send(1)
 - imap-send.c: more style fixes
 - imap-send.c: style fixes
 - git-imap-send: Support SSL
 - git-imap-send: Allow the program to be run from subdirectories of
   a git tree

Some people seem to prefer having this feature available also with gnutls.
If such a patch materializes soon, that would be good, but otherwise I'll
merge this as-is to 'next'.  Such an enhancement can be done in-tree on
top of this series.

* xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
 + Teach git-merge -X<option> again.
 + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
 + builtin-merge.c: use parse_options_step() "incremental parsing"
   machinery
 + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next

This needs to be merged to master iff/when merge-theirs gets merged,
but I do not think this series is widely supported, so both are on hold.

* jc/merge-theirs (Mon Jun 30 22:18:57 2008 -0700) 5 commits
 + Make "subtree" part more orthogonal to the rest of merge-
   recursive.
 + Teach git-pull to pass -X<option> to git-merge
 + Teach git-merge to pass -X<option> to the backend strategy module
 + git-merge-recursive-{ours,theirs}
 + git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends is updated so that you can
say "git merge -Xours -Xsubtree=foo/bar/baz -s recursive other" now.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet.  Perhaps
in 1.7.0.

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
 + Revert "Make clients ask for "git program" over ssh and local
   transport"
 + Make clients ask for "git program" over ssh and local transport

This is the "botched" one.  Will be resurrected during 1.7.0 or 1.8.0
timeframe.

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

----------------------------------------------------------------
[Stalled/Needs more work]

* gi/cherry-cache (Sat Jul 12 20:14:51 2008 -0700) 1 commit
 . cherry: cache patch-ids to avoid repeating work

* lw/gitweb (Fri Jul 11 03:11:48 2008 +0200) 3 commits
 . gitweb: use new Git::Repo API, and add optional caching
 . Add new Git::Repo API
 . gitweb: add test suite with Test::WWW::Mechanize::CGI

* sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
 . Migrate git-am to use git-sequencer
 . Add git-sequencer test suite (t3350)
 . Add git-sequencer prototype documentation
 . Add git-sequencer shell prototype

* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
 - [BROKEN wrt shallow clones] Ignore graft during object transfer

Cloning or fetching from a repository from grafts did not send objects
that are hidden by grafts, but the commits in the resulting repository do
need these to pass fsck.  This fixes object transfer to ignore grafts.

Another fix is needed to git-prune so that it ignores grafts but treats
commits that are mentioned in grafts as reachable.

* 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 is for peeling to see what's behind the blamed commit, which may or
may not help applications like gitweb.

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.  The topics
meant to be merged to the maintenance series have "maint-" in their names.

Right now 'next' is very thin.  After today's new topics, perhaps except
for the submodule stuff by Pasky, are merged to 'master', we will have the
1.6.0-rc0, and from there the usual pre-release freeze begins.

Due to increased activity level from people including GSoC students, I
expect 'next' to stay somewhat more active than previous rounds during the
1.6.0-rc cycle.  The request for people who usually follow 'next' is the
same as usual, though.  After -rc1 is tagged, please run 'master' for your
daily git use instead, in order to make sure 'master' does what it claims
to do without regression.

Tentative schedule, my wishful thinking:

 - 1.6.0-rc0 (Jul 20)
 - 1.6.0-rc1 (Jul 23)
 - 1.6.0-rc2 (Jul 30)
 - 1.6.0-rc3 (Aug  6)
 - 1.6.0     (Aug 10)

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

* jc/rerere-auto-more (Wed Jul 16 20:25:18 2008 -0700) 1 commit
 - rerere.autoupdate: change the message when autoupdate is in effect

This one is for Ingo.

This changes the message rerere issues after reusing previous conflict
resolution from "Resolved" to "Staged" when autoupdate option is in
effect.

It is envisioned that in practice, some auto resolutions are trickier and
iffier than others, and we would want to add a feature to mark individual
resolutions as "this is ok to autoupdate" or "do not autoupdate the result
using this resolution even when rerere.autoupdate is in effect" in the
future.  When that happens, these messages will make the distinction
clearer.

* ap/trackinfo (Wed Jul 16 15:19:27 2008 -0400) 1 commit
 - Reword "your branch has diverged..." lines to reduce line length

You saw the exchange on the list.  Queued is my "make it shorter and make
sure variable parts are closer to left edge of the screen" version but
better alternatives are welcome.  I suspect not many people would care too
much about details, as long as the message fits and does not waste screen
real estate.

* ns/am-abort (Wed Jul 16 19:39:10 2008 +0900) 1 commit
 - git am --abort

This one is for Ted; builds on top of the recent "am and rebase leaves
ORIG_HEAD just like reset, merge and pull does" rather nicely.

* pb/submodule (Wed Jul 16 21:11:40 2008 +0200) 7 commits
 - t7403: Submodule git mv, git rm testsuite
 - git rm: Support for removing submodules
 - git mv: Support moving submodules
 - submodule.*: Introduce simple C interface for submodule lookup by
   path
 - git submodule add: Fix naming clash handling
 - t7400: Add short "git submodule add" testsuite
 - git-mv: Remove dead code branch

Long overdue usability improvement series for submodule.  Very much
welcomed.  It would be nice to have some submodule improvements in 1.6.0.
Realistically speaking, however, I predict that it would take us a few
more rounds to hit 'next' with this, and it will not be in 'master' when
1.6.0 ships.

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

* sp/maint-index-pack (Tue Jul 15 04:45:34 2008 +0000) 4 commits
 + index-pack: Honor core.deltaBaseCacheLimit when resolving deltas
 + index-pack: Track the object_entry that creates each base_data
 + index-pack: Chain the struct base_data on the stack for traversal
 + index-pack: Refactor base arguments of resolve_delta into a struct

* rs/rebase-checkout-not-so-quiet (Mon Jul 14 14:05:35 2008 -0700) 1 commit
 + git-rebase: report checkout failure

* ag/blame (Wed Jul 16 02:00:58 2008 +0400) 2 commits
 + Do not try to detect move/copy for entries below threshold.
 + Avoid rescanning unchanged entries in search for copies.

This gives a drastic performance improvement to "git-blame -C -C" with
quite straightforward and obvious code change.

* rs/archive (Mon Jul 14 21:22:05 2008 +0200) 6 commits
 + archive: remove extra arguments parsing code
 + archive: unify file attribute handling
 + archive: centralize archive entry writing
 + archive: add baselen member to struct archiver_args
 + add context pointer to read_tree_recursive()
 + archive: remove args member from struct archiver

* sb/dashless (Sun Jul 13 15:36:15 2008 +0200) 3 commits
 + Make usage strings dash-less
 + t/: Use "test_must_fail git" instead of "! git"
 + t/test-lib.sh: exit with small negagive int is ok with
   test_must_fail

* mv/dashless (Fri Jul 11 02:12:06 2008 +0200) 4 commits
 + make remove-dashes: apply to scripts and programs as well, not
   just to builtins
 + git-bisect: use dash-less form on git bisect log
 + t1007-hash-object.sh: use quotes for the test description
 + t0001-init.sh: change confusing directory name

* ls/mailinfo (Sun Jul 13 20:30:12 2008 +0200) 3 commits
 + git-mailinfo: use strbuf's instead of fixed buffers
 + Add some useful functions for strbuf manipulation.
 + Make some strbuf_*() struct strbuf arguments const.

This actually had a tiny regression I did not discover until I merged it
to 'master', where a fixup has already been applied.

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

* rs/imap (Wed Jul 9 22:29:02 2008 +0100) 5 commits
 - Documentation: Improve documentation for git-imap-send(1)
 - imap-send.c: more style fixes
 - imap-send.c: style fixes
 - git-imap-send: Support SSL
 - git-imap-send: Allow the program to be run from subdirectories of
   a git tree

I said: "Some people seem to prefer having this feature available also
with gnutls.  If such a patch materializes soon, that would be good, but
otherwise I'll merge this as-is to 'next'.  Such an enhancement can be
done in-tree on top of this series."  Anybody?

* xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
 + Teach git-merge -X<option> again.
 + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
 + builtin-merge.c: use parse_options_step() "incremental parsing"
   machinery
 + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next

This needs to be merged to master iff/when merge-theirs gets merged,
but I do not think this series is widely supported, so both are on hold.

* jc/merge-theirs (Mon Jun 30 22:18:57 2008 -0700) 5 commits
 + Make "subtree" part more orthogonal to the rest of merge-
   recursive.
 + Teach git-pull to pass -X<option> to git-merge
 + Teach git-merge to pass -X<option> to the backend strategy module
 + git-merge-recursive-{ours,theirs}
 + git-merge-file --ours, --theirs

Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged.  It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are.  The interface to the backends is updated so that you can
say "git merge -Xours -Xsubtree=foo/bar/baz -s recursive other" now.

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet.  Perhaps
in 1.7.0.

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
 + Revert "Make clients ask for "git program" over ssh and local
   transport"
 + Make clients ask for "git program" over ssh and local transport

This is the "botched" one.  Will be resurrected during 1.7.0 or 1.8.0
timeframe.

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

----------------------------------------------------------------
[Stalled/Needs more work]

* gi/cherry-cache (Sat Jul 12 20:14:51 2008 -0700) 1 commit
 . cherry: cache patch-ids to avoid repeating work

The discussion suggested that the value of having the cache itself is
iffy, but I should pick up the updated one and look at it.

* lw/gitweb (Fri Jul 11 03:11:48 2008 +0200) 3 commits
 . gitweb: use new Git::Repo API, and add optional caching
 . Add new Git::Repo API
 . gitweb: add test suite with Test::WWW::Mechanize::CGI

* sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
 . Migrate git-am to use git-sequencer
 . Add git-sequencer test suite (t3350)
 . Add git-sequencer prototype documentation
 . Add git-sequencer shell prototype

I haven't looked at the updated series yet.  I should, but nobody else
seems to be looking at these patches, which is somewhat depressing but
understandable.  Summer is slower ;-)

* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
 - [BROKEN wrt shallow clones] Ignore graft during object transfer

Cloning or fetching from a repository from grafts did not send objects
that are hidden by grafts, but the commits in the resulting repository do
need these to pass fsck.  This fixes object transfer to ignore grafts.

Another fix is needed to git-prune so that it ignores grafts but treats
commits that are mentioned in grafts as reachable.

* 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 is for peeling the line from the blamed version to see what's behind
it, which may or may not help applications like gitweb.

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

[Stephan Beyer]

Hi,

Junio C Hamano wrote:
> * sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
>  . Migrate git-am to use git-sequencer
>  . Add git-sequencer test suite (t3350)
>  . Add git-sequencer prototype documentation
>  . Add git-sequencer shell prototype
> 
> I haven't looked at the updated series yet.  I should, but nobody else
> seems to be looking at these patches, which is somewhat depressing but
> understandable.  Summer is slower ;-)

imho there is no need to hurry, but if I can help, just tell me how.

Regards.

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

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

[Nanako Shiraishi]

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

> * xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
>  + Teach git-merge -X<option> again.
>  + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
>  + builtin-merge.c: use parse_options_step() "incremental parsing"
>    machinery
>  + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next
>
> This needs to be merged to master iff/when merge-theirs gets merged,
> but I do not think this series is widely supported, so both are on hold.

Why do you say it is not widely supported?  I may be wrong but I think you developed these patches after somebody from the mailing list asked for this feature.

You may find out people are enthusiastic about this only after you merge it to your master branch.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

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

[Junio C Hamano]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> Quoting Junio C Hamano <gitster@pobox.com>:
>
>> * xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
>>  + Teach git-merge -X<option> again.
>>  + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
>>  + builtin-merge.c: use parse_options_step() "incremental parsing"
>>    machinery
>>  + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next
>>
>> This needs to be merged to master iff/when merge-theirs gets merged,
>> but I do not think this series is widely supported, so both are on hold.
>
> Why do you say it is not widely supported?  I may be wrong but I think
> you developed these patches after somebody from the mailing list asked
> for this feature.

Well, for one thing, I do not believe in their cause.  As I wrote in the
log messages for these commits (actually not these above which is a series
for merge fixup, but the other topic), I do not think it is a sensible
thing to say "let's take as much automerge results as possible to salvage
our changes where they do not overlap with what the upstream did, but I
would give up our changes to places that the upstream also touched,
because I do not understand what they did well enough to be able to
resolve the merge conflicts correctly", and "merge -Xtheirs" is exactly
that.

That also was the reason I did not add any documentation to it.  But I do
like the change to the infrastructure to allow passing strategy-specific
options through git-merge and git-pull.  Perhaps I should write something
up, if only to salvage that -X<option> part, even though I am very much
inclined to discard -Xtheirs (and -Xours) part.

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

[Nanako Shiraishi]

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

> Well, for one thing, I do not believe in their cause.  As I wrote in the
> log messages for these commits (actually not these above which is a series
> for merge fixup, but the other topic), I do not think it is a sensible
> thing to say "let's take as much automerge results as possible to salvage
> our changes where they do not overlap with what the upstream did, but I
> would give up our changes to places that the upstream also touched,
> because I do not understand what they did well enough to be able to
> resolve the merge conflicts correctly", and "merge -Xtheirs" is exactly
> that.

I do not know if "I do not understand what they did well enough" is the only reason people would want to use that feature. Isn't it better to let people decide that for themselves?

> That also was the reason I did not add any documentation to it.  But I do
> like the change to the infrastructure to allow passing strategy-specific
> options through git-merge and git-pull.  Perhaps I should write something
> up, if only to salvage that -X<option> part, even though I am very much
> inclined to discard -Xtheirs (and -Xours) part.

I think such a documentation will help people to decide if 'theirs' option makes sense for their workflow.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

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

[Junio C Hamano]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> Quoting Junio C Hamano <gitster@pobox.com>:
>
>> ... I do not think it is a sensible
>> thing to say "let's take as much automerge results as possible to salvage
>> our changes where they do not overlap with what the upstream did, but I
>> would give up our changes to places that the upstream also touched,
>> because I do not understand what they did well enough to be able to
>> resolve the merge conflicts correctly", and "merge -Xtheirs" is exactly
>> that.
>
> I do not know if "I do not understand what they did well enough" is the
> only reason people would want to use that feature. Isn't it better to
> let people decide that for themselves?

We have been saying that we will give long enough rope to people, but at
the same time I believe there are things that the world is better without,
and a feature that would only encourage a bad workflow is one of them.
The way I try to tell such a (mis)feature from a feature that can be
useful to people other than myself is to ask people why they would want
such a feature and what their response to possible downsides of such a
feature.

Don't get me wrong.  Choice is good, and it is also good that some people
may choose differently from me.  After all, we are different people with
different workflows.

But they should be able to explain the reason why they choose something
clearly, at least well enough to convince themselves to choose it.  If
they can't come up with a rational explanation, it becomes an irrational
"because I want to" (and "because I can, now that you have already coded
it").  That leads to feeping creaturism and a bad feature that the world
is better without.

I haven't heard an explanation other than the one I said above, and I do
not think that explanation is rational.

	Side note. Even though I invented rerere and it turned out to be a
	great ti[mp]esaver, I do want to validate the reused resolution
	makes sense in the new context every time rerere does its job.
	Recently Ingo wanted the auto resolution to be staged
	automatically, and rerere.autoupdate was born.  I was initially
	very much against it, but his description of the workflow where it
	would be useful was convincing enough.  This "convincing" does not
	have to be "Yeah, it's useful to me as well; thanks for explaining
	it to me".  Even though my workflow might never be helped with
	such a feature, I can see that the different workflow he presented
	would be useful to people other than myself, and I could agree
	that the new feature would help such a workflow.  This was a good
	example of "choosing something I initially thought would be
	detrimental with a good reason, and with a good explanation making
	me realize that my initial thought was too narrow".

> I think such a documentation will help people to decide if 'theirs'
> option makes sense for their workflow.

So here it is.

-- >8 --
[PATCH] Document that merge strategies can now take their own options

Also document the recently added -Xtheirs, -Xours and -Xsubtree[=path]
options to the merge-recursive strategy.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/merge-options.txt    |    4 ++++
 Documentation/merge-strategies.txt |   26 ++++++++++++++++++++++++++
 2 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index ffbc6e9..96aec48 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -58,3 +58,7 @@
 	If there is no `-s` option, a built-in list of strategies
 	is used instead (`git-merge-recursive` when merging a single
 	head, `git-merge-octopus` otherwise).
+
+-X<option>::
+	Pass merge strategy specific option through to the merge
+	strategy.
diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
index 1276f85..39ff0a8 100644
--- a/Documentation/merge-strategies.txt
+++ b/Documentation/merge-strategies.txt
@@ -1,6 +1,11 @@
 MERGE STRATEGIES
 ----------------
 
+The merge mechanism ('git-merge' and 'git-pull' commands) allows the
+backend 'merge strategies' to be chosen with `-s` option.  Some strategies
+can also take their own options, which can be passed by giving `-X<option>`
+arguments to 'git-merge' and/or 'git-pull'.
+
 resolve::
 	This can only resolve two heads (i.e. the current branch
 	and another branch you pulled from) using 3-way merge
@@ -20,6 +25,27 @@ recursive::
 	Additionally this can detect and handle merges involving
 	renames.  This is the default merge strategy when
 	pulling or merging one branch.
++
+The 'recursive' strategy can take the following options:
+
+ours;;
+	This option forces conflicting hunks to be auto-resolved cleanly by
+	favoring 'our' version.  Changes from the other tree that do not
+	conflict with our side are reflected to the merge result.
++
+This should not be confused with the 'ours' merge strategy, which does not
+even look at what the other tree contains at all.  IOW, it discards everything
+the other tree did, declaring 'our' history contains all that happened in it.
+
+theirs;;
+	This is opposite of 'ours'.
+
+subtree[=path];;
+	This option is a more advanced form of 'subtree' strategy, where
+	the strategy makes a guess on how two trees must be shifted to
+	match with each other when merging.  Instead, the specified path
+	is prefixed (or stripped from the beginning) to make the shape of
+	two trees to match.
 
 octopus::
 	This resolves more than two-head case, but refuses to do
-- 
1.5.6.3.573.gd2d2

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

[Johannes Schindelin]

Hi,

On Fri, 18 Jul 2008, Junio C Hamano wrote:

> +The 'recursive' strategy can take the following options:
> +
> +ours;;

You still have not addressed the issue that you can specify multiple 
strategies, or even a single _wrong_ one.  So:

	$ git merge -s stupid -Xours

would not fail at all, but definitely not do the right thing either (it 
disobeys a direct command of the user).

Apart from having to choose different -X option names for the different 
backends, to avoid them from clashing when you specify multiple 
strategies, you also deprive the user from being able to try the _same_ 
backend with different options.

IOW all my objections to the -X option (even that it does not fit with our 
short option parsing paradigm) still apply.

We already have the "-S" wart, let's not add to that pile.

Ciao,
Dscho

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

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Fri, 18 Jul 2008, Junio C Hamano wrote:
>
>> +The 'recursive' strategy can take the following options:
>> +
>> +ours;;
>
> You still have not addressed the issue that you can specify multiple 
> strategies,...

Even though multiple -s parameters are supported, I know you have been
here long enough in git scene to remember how it came about.  I've seen
some third-party documents that talk about our ability to "try multiple
strategies and pick the best one" as one of the unique features, but
anybody who was there knows that it was just a failed experiment that we
did not bother removing.

The thing is, trying multiple strategies was a cute idea and it was quite
straightforward to implement.  But picking the best one is the much more
important part, and judging whose result is the best shouldn't be done
with just a naïve "how many conflicting paths remain there?" metric
(c.f. $gmane/87297 which talks about "stupid" but the argument is exactly
the same --- smaller number of conflicts may not necessarily be the
easiest to resolve nor the right resolution).  I would be surprised if
anybody uses multiple -s options in their daily workflow, even though I
would not be surprised if people tried to use it just as an experiment and
for its entertainment value once or maybe twice.  After all, I invented
the multiple strategy support for amusement, not from any practical real
world needs ;-)

So I do not consider that a convincing argument at all.

> ... or even a single _wrong_ one.  So:
>
> 	$ git merge -s stupid -Xours
>
> would not fail at all, but definitely not do the right thing either (it 
> disobeys a direct command of the user).

It does fail gracefully, though.

    $ git merge -s resolve -Xours next
    Trying really trivial in-index merge...
    error: Untracked working tree file '.gitattributes' would be overwritten by merge.
    Nope.
    fatal: Not a valid object name --ours
    Merge with strategy resolve failed.

I consider this falls into "You say it hurts?  Don't do that, then"
category.

The error message will naturally improve, once we teach the merge strategy
backends that they can be given --<option> in front of the usual
<base>... -- <ents>... parameters, and there is no risk of ambiguity
because no object names begin with a dash.

Having said all that, I do not have any reason to push for -Xours/theirs
myself.  I've made myself very clear from the beginning that what these
options do is a bad idea, just as "-s theirs" is a bad idea.  These
encourage a broken workflow and I do not see a clear upside, however
narrow, and you and Pasky seem to agree with me (heh, isn't it a rare
occasion that all three of us agree on something these days? ;-)

I won't shed tears to see them go.

However, I do think it is wrong to deny that it will eventually be
necessary for us to be able to pass strategy specific options via the
git-merge frontend driver to the strategy backend.  The primary reason why
I wrote "subtree" strategy to _guess_ how to shift trees was because there
was no way to pass "how the end user wants to shift them" to the strategy
backend over "pull -- merge -- merge-subtree" callchain.  Coming up with
the algorithm was fun, but that was secondary.

If we allow users to say -Xsubtree=<path>, it would be a true improvement
to a tool that is used in real life.  Unlike "multiple -s strategy"
support that I think nobody ever uses in practice (on which part of your
objection is based), "-s subtree" has been useful in real life, and you
can verify that claim easily by counting how many times I've used that in
git.git history yourself.

Even though I do not care deeply about the syntax (and if you do not like
the "-X" as the external option introducer, you are welcome to pick a
different notation and send in a patch), it would help for example the
vanilla "recursive" strategy to allow the user, when dealing with really
tricky merge, to influence the rename threshold score it uses by passing
it as a strategy-specific option.

As a conclusion of this discussion, I'll discard xx/merge-in-c-into-next
branch from "next", at the beginning of post-1.6.0 cycle.  We might in the
future need to resurrect only the -X<option> part to allow us to pass
strategy specific options (that are not "ours/theirs"), but there is no
immediate need for it, other than -Xsubtree=<path>.  If somebody wants to
step up and give the custom rename threshold to the recursive strategy,
keeping that code to do -X<option> might help that too, though.

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

[Johannes Schindelin]

Hi,

On Fri, 18 Jul 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Fri, 18 Jul 2008, Junio C Hamano wrote:
> >
> >> +The 'recursive' strategy can take the following options:
> >> +
> >> +ours;;
> >
> > You still have not addressed the issue that you can specify multiple 
> > strategies,...
> 
> Even though multiple -s parameters are supported, I know you have been 
> here long enough in git scene to remember how it came about.  I've seen 
> some third-party documents that talk about our ability to "try multiple 
> strategies and pick the best one" as one of the unique features, but 
> anybody who was there knows that it was just a failed experiment that we 
> did not bother removing.

I think that we made it hard for that experiment to succeed, by 
disallowing custom merge strategies.

See

http://git.or.cz/gitwiki/SoC2007Ideas#head-cfde15f16950c2579a89cc109762e911546e6fe3

for an idea that would make complete sense as a _fallback_ strategy.  
Fallback, because it is definitely too slow to be the default.

Yes, I agree, if all strategies fail, it is dubitable that we find a 
metric that will always find the "best" one.  But if one fails and the 
next one does not, it is obvious what is correct.

So I still feel that "-s subtree=<blabla>,recursive=theirs" would be a 
viable way to go.  And more intuitive than "-X".

I'll just ask Miklos what he thinks of the idea, and to write the patch if 
he likes it, once he's back from the saddle. :-)

Ciao,
Dscho

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

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Yes, I agree, if all strategies fail, it is dubitable that we find a 
> metric that will always find the "best" one.  But if one fails and the 
> next one does not, it is obvious what is correct.

Not at all.  Imagine the case where one of them is either ours or theirs.

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

[Johannes Schindelin]

Hi,

On Sat, 19 Jul 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > Yes, I agree, if all strategies fail, it is dubitable that we find a 
> > metric that will always find the "best" one.  But if one fails and the 
> > next one does not, it is obvious what is correct.
> 
> Not at all.  Imagine the case where one of them is either ours or 
> theirs.

But then it is not the _default_ at all!

It is what the _user_ _asked_ for.

So this is what the user gets.

With Git, the user is not ignored (like GNOME does, to "help" the user).  
With Git, the user _gets_ what she asked for, even if the question does 
not make sense.

Ciao,
Dscho

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

[Miklos Vajna]

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

On Sat, Jul 19, 2008 at 01:19:46PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> So I still feel that "-s subtree=<blabla>,recursive=theirs" would be a 
> viable way to go.  And more intuitive than "-X".
> 
> I'll just ask Miklos what he thinks of the idea, and to write the patch if 
> he likes it, once he's back from the saddle. :-)

I think there are three steps here.

First, currently you can specify multiple strategies in the config
(pull.twohead, pull.octopus) using a space separated list. If we want to
change it to a coma-separated list, should we care about backwards
compatibility? There are tests for this, but it's undocumented (and my
patch to document it was rejected, saying we should not encourage people
to use it).

Second, we could allow custom strategies, as we started to discuss here:

http://thread.gmane.org/gmane.comp.version-control.git/86584/focus=87684

Third, it would be nice to allow passing extra parameter(s) to the
backends, but I do not know what concept is the best here. The
strategy1=foo,stategy2=bar limits the input to a single string. Is that
enough? Given that recursive=theirs was considered harmful, we don't
have too much examples; for subtree the only parameter I could think of
is the path, so a string there is enough.

However, further strategies, like blame, could take more parameters,
like git blame -C<num> -M<othernum>. Or do I just overcomplicate it? ;-)

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

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

[Johannes Schindelin]

Hi,

On Sun, 20 Jul 2008, Miklos Vajna wrote:

> First, currently you can specify multiple strategies in the config
> (pull.twohead, pull.octopus) using a space separated list.

Oh, I did not mean to change that.  I just misremembered.

> Second, we could allow custom strategies, as we started to discuss here:
> 
> http://thread.gmane.org/gmane.comp.version-control.git/86584/focus=87684

In my opinion, this would make it easier for interested parties to start 
implementing that blame-based merge strategy I mentioned.

> Third, it would be nice to allow passing extra parameter(s) to the
> backends, but I do not know what concept is the best here. The
> strategy1=foo,stategy2=bar limits the input to a single string. Is that
> enough? Given that recursive=theirs was considered harmful, we don't
> have too much examples; for subtree the only parameter I could think of
> is the path, so a string there is enough.
> 
> However, further strategies, like blame, could take more parameters,
> like git blame -C<num> -M<othernum>. Or do I just overcomplicate it? ;-)

The common solution is like with gcc's -Wl option, which translates 
commata into spaces, like so: "-Wl,--machine,i386" is added as "--machine 
i386" to the linker command line.

Our own cvsimport implements the same principle:

	$ git cvsimport -p -b,HEAD

will only update the main branch.

Ciao,
Dscho

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

[Junio C Hamano]

Miklos Vajna <vmiklos@frugalware.org> writes:

> Third, it would be nice to allow passing extra parameter(s) to the
> backends, but I do not know what concept is the best here. The
> strategy1=foo,stategy2=bar limits the input to a single string. Is that
> enough? Given that recursive=theirs was considered harmful, we don't
> have too much examples;...

I personally think -sstrategy=string1,string2,... is simply a bad taste.

Why force yourself to parse things by having the users to concatenate
something that the user could give us separated?  If you care about the
order and association between strategy and their options, you can always
do:

	-s strategy1 -X option-1-for-strategy-1 -X option-2-for-strategy-1 \
	-s strategy2 -X option-1-for-strategy-2 ...

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

[Johannes Schindelin]

Hi,

On Sun, 20 Jul 2008, Junio C Hamano wrote:

> Miklos Vajna <vmiklos@frugalware.org> writes:
> 
> > Third, it would be nice to allow passing extra parameter(s) to the
> > backends, but I do not know what concept is the best here. The
> > strategy1=foo,stategy2=bar limits the input to a single string. Is that
> > enough? Given that recursive=theirs was considered harmful, we don't
> > have too much examples;...
> 
> I personally think -sstrategy=string1,string2,... is simply a bad taste.
> 
> Why force yourself to parse things by having the users to concatenate
> something that the user could give us separated?  If you care about the
> order and association between strategy and their options, you can always
> do:
> 
> 	-s strategy1 -X option-1-for-strategy-1 -X option-2-for-strategy-1 \
> 	-s strategy2 -X option-1-for-strategy-2 ...

You mean something like

	$ git merge -s subtree -X --path -X git-gui/ git-gui/master

Wow. :-)

Speechless,
Dscho

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

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> I personally think -sstrategy=string1,string2,... is simply a bad taste.
>> 
>> Why force yourself to parse things by having the users to concatenate
>> something that the user could give us separated?  If you care about the
>> order and association between strategy and their options, you can always
>> do:
>> 
>> 	-s strategy1 -X option-1-for-strategy-1 -X option-2-for-strategy-1 \
>> 	-s strategy2 -X option-1-for-strategy-2 ...
>
> You mean something like
>
> 	$ git merge -s subtree -X --path -X git-gui/ git-gui/master
>
> Wow. :-)

I would envision it to be more like:

	$ git merge -s subtree -Xpath=git-gui git-gui/master

which git-merge internally would turn into:

	$ git-merge-subtree --path=git-gui HEAD -- OURS THEIRS

That way both the external command line (that the end users do care about)
and the internal one (that the strategy programmer would care about) look
a lot more sensible than your command line, don't they?

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

[Sverre Rabbelier]

On Sun, Jul 20, 2008 at 9:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> You mean something like
>>
>>       $ git merge -s subtree -X --path -X git-gui/ git-gui/master
>>
>> Wow. :-)
>
> I would envision it to be more like:
>
>        $ git merge -s subtree -Xpath=git-gui git-gui/master

Whatever happened to quotes?

        $ git merge -s subtree -Xpath="git-gui git-gui/master"

-- 
Cheers,

Sverre Rabbelier

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

[Miklos Vajna]

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

On Sun, Jul 20, 2008 at 10:03:24PM +0200, Sverre Rabbelier <alturin@gmail.com> wrote:
> On Sun, Jul 20, 2008 at 9:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >> You mean something like
> >>
> >>       $ git merge -s subtree -X --path -X git-gui/ git-gui/master
> >>
> >> Wow. :-)
> >
> > I would envision it to be more like:
> >
> >        $ git merge -s subtree -Xpath=git-gui git-gui/master
> 
> Whatever happened to quotes?
> 
>         $ git merge -s subtree -Xpath="git-gui git-gui/master"

Read again what did you wrote. ;-)

The current form is

git merge -s subtree git-gui/master, so at most it could be

        $ git merge -s subtree -Xpath="git-gui" git-gui/master

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

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

[Sverre Rabbelier]

On Sun, Jul 20, 2008 at 10:33 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Sun, Jul 20, 2008 at 10:03:24PM +0200, Sverre Rabbelier <alturin@gmail.com> wrote:
>> Whatever happened to quotes?
>>
>>         $ git merge -s subtree -Xpath="git-gui git-gui/master"
>
> Read again what did you wrote. ;-)
>
> The current form is
>
> git merge -s subtree git-gui/master, so at most it could be
>
>        $ git merge -s subtree -Xpath="git-gui" git-gui/master

Meh, what I ofcourse mean was:
         $ git merge -s subtree -X"path=git-gui" git-gui/master

But that looks rather awkward, which is probably why I typed it the
way I did? Maybe something like....
         $ git merge -s subtree -X(--path=git-gui --foo=bar) git-gui/master

-- 
Cheers,

Sverre Rabbelier

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

[Jakub Narebski]

"Sverre Rabbelier" <alturin@gmail.com> writes:

> On Sun, Jul 20, 2008 at 10:33 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
>> On Sun, Jul 20, 2008 at 10:03:24PM +0200, Sverre Rabbelier <alturin@gmail.com> wrote:
>>> Whatever happened to quotes?
>>>
>>>         $ git merge -s subtree -Xpath="git-gui git-gui/master"
>>
>> Read again what did you wrote. ;-)
>>
>> The current form is
>>
>> git merge -s subtree git-gui/master, so at most it could be
>>
>>        $ git merge -s subtree -Xpath="git-gui" git-gui/master
> 
> Meh, what I of course mean was:
>          $ git merge -s subtree -X"path=git-gui" git-gui/master
> 
> But that looks rather awkward, which is probably why I typed it the
> way I did? Maybe something like....
>          $ git merge -s subtree -X(--path=git-gui --foo=bar) git-gui/master

Or perhaps (following -Wx family of GCC options)

           $ git merge -s subtree -X--path=git-gui,--foo=bar git-gui/master

-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Junio C Hamano]

"Sverre Rabbelier" <alturin@gmail.com> writes:

> Whatever happened to quotes?
>
>         $ git merge -s subtree -Xpath="git-gui git-gui/master"

Nothing special needs to happen.  That would naturally be passed to the
underlying strategy as the equivalent of:

	$ git merge-subtree --path="git-gui git-gui/master"

but now "git-merge" is in C, it does not have to quote nor unquote
explicitly itself.  Unquoting will be done by the shell when you call
"git-merge", and quoting is unneeded when you give each argument as a
separate string in **argv to call execv().

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

[Johannes Schindelin]

Hi,

On Sun, 20 Jul 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> I personally think -sstrategy=string1,string2,... is simply a bad taste.
> >> 
> >> Why force yourself to parse things by having the users to concatenate
> >> something that the user could give us separated?  If you care about the
> >> order and association between strategy and their options, you can always
> >> do:
> >> 
> >> 	-s strategy1 -X option-1-for-strategy-1 -X option-2-for-strategy-1 \
> >> 	-s strategy2 -X option-1-for-strategy-2 ...
> >
> > You mean something like
> >
> > 	$ git merge -s subtree -X --path -X git-gui/ git-gui/master
> >
> > Wow. :-)
> 
> I would envision it to be more like:
> 
> 	$ git merge -s subtree -Xpath=git-gui git-gui/master
> 
> which git-merge internally would turn into:
> 
> 	$ git-merge-subtree --path=git-gui HEAD -- OURS THEIRS
> 
> That way both the external command line (that the end users do care about)
> and the internal one (that the strategy programmer would care about) look
> a lot more sensible than your command line, don't they?

I still find it a lot easier to explain

	$ git -s subtree=git-gui git-gui/master

to a new user than your command line, especially since

	$ git -X path=git-gui -s subtree git-gui/master

would be a not so obvious mistake, _and_ especially since the 
implementation of your option parsing would be rather ugly.

But the subject has been discussed to death, and you seem to still prefer 
the -X way, so I give up.

You win,
Dscho "who can adapt even to a syntax he does not like"

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

[Petr Baudis]

On Fri, Jul 18, 2008 at 06:20:10PM +0900, Nanako Shiraishi wrote:
> I do not know if "I do not understand what they did well enough" is the only reason people would want to use that feature. Isn't it better to let people decide that for themselves?

It is dangerous to introduce new options just because we think someone,
sometimes might find it useful, especially if they potentially encourage
a bad workflow. Adding options and commands is expensive since it
complicates the UI further, thus we should add further only when we have
good reason for it.

> > That also was the reason I did not add any documentation to it.

I was actually looking for something like this based on some question on
#git (about git pull -s theirs possibility), and did stumble upon these
patches, but quickly gave up on them since it wasn't immediately clear
for me from the patch description exactly how the workflow looks like
(it doesn't really seem to work like the opposite of -s ours nor is it a
separate strategy... huh) and the options were completely undocumented.

-- 
				Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce

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

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> On Fri, Jul 18, 2008 at 06:20:10PM +0900, Nanako Shiraishi wrote:
>> I do not know if "I do not understand what they did well enough" is the only reason people would want to use that feature. Isn't it better to let people decide that for themselves?
>
> It is dangerous to introduce new options just because we think someone,
> sometimes might find it useful, especially if they potentially encourage
> a bad workflow. Adding options and commands is expensive since it
> complicates the UI further, thus we should add further only when we have
> good reason for it.
>
>> > That also was the reason I did not add any documentation to it.
>
> I was actually looking for something like this based on some question on
> #git (about git pull -s theirs possibility), and did stumble upon these
> patches, but quickly gave up on them since it wasn't immediately clear
> for me from the patch description exactly how the workflow looks like
> (it doesn't really seem to work like the opposite of -s ours nor is it a
> separate strategy... huh) and the options were completely undocumented.

Heh, now you have some readings to do ;-)

I tried not to sound too negative when describing -Xours and -Xtheirs
there, but actually I think "-s theirs" is even worse.  It is how you
would discard what you did (perhaps because the other side has much better
solution than your hack), but that can be much more easily and cleanly
done with:

	$ git reset --hard origin

Some poeple might say "But with 'merge -s theirs', I can keep what I did,
too".  That reset is simply discarding what I did.

That logic also is flawed.  You can instead:

	$ git branch i-was-stupid
        $ git reset --hard origin

if you really want to keep record of your failure.

One big problem "-s theirs" has, compared to the above "reset to origin,
discarding or setting aside the failed history" is that your 'master'
history that your further development is based on will keep your failed
crap in it forever if you did "-s theirs".  Hopefully you will become a
better programmer over time, and you may eventually have something worth
sharing with the world near the tip of your master branch.  When that
happens, however, you _cannot_ offer your master branch to be pulled by
the upstream, as the wider world will not be interested in your earlier
mistakes at all.

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

[Yaroslav Halchenko]

Dear Everyone,

> I tried not to sound too negative when describing -Xours and -Xtheirs
> there, but actually I think "-s theirs" is even worse.  It is how you
> would discard what you did (perhaps because the other side has much better
> solution than your hack)

or perhaps this is very well intended, e.g. if you are tracking other project's
development and just need to carry a limited portion of the source tree.

Sorry for reincarnating this old thread, but  since I have filed Debian
wishlist bug against GIT for '-s theirs':

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581680

and this thread is linked to it as the ultimate source 'why not (yet)', I want
to describe a usecase when/why I wanted to have -s theirs:

For debian packaging, we often need to clean up the upstream source tree so it
does not contain non-free material (binary blobs, components under non-free
licenses, etc).  If I want to setup all packaging within GIT, I would follow
natively following setup:

git checkout -b dfsg 0.1
git rm non-free-1 non-free-2 ...
git commit -m "DFSG-compliant 0.1"
git tag -a -m 0.1.dfsg

and base my packaging off dfsg branch (in a separate branch, e.g. debian).

Upon release 0.2 of upstream work, in the simplest case, I can do now

git checkout dfsg
git merge 0.2

and there things could get hairy -- if files were modified upstream, I get
conflicts, so I would need to git rm files again, and only then commit the
merge:

git rm 

Moreover, 0.2 might not follow 0.1 -- upstream might release off
"release-branches", then I simply *must not* do "git merge" with recursive 
strategy.

Moreover, if some material finally became free, I would need to re-add it
somehow into dfsg branch from 0.2 branch.


*All* those complications could easily be avoided if I only had '-s theirs'.
Then I simply

git checkout dfsg
git merge --no-commit -s theirs 0.2
# after all I do not, and must not have my modifications
git rm -rf non-free-1 ... # probably would be scripted
git commit

With -s theirs now I would be able manage all tricky cases above without hassle
in a unified way.

Would it be possible to have GIT people reconsider addition of '-s theirs'?

Thank you in advance for your time!

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

[Junio C Hamano]

Yaroslav Halchenko <debian@onerussian.com> writes:

> git checkout dfsg
> git merge --no-commit -s theirs 0.2
> # after all I do not, and must not have my modifications
> git rm -rf non-free-1 ... # probably would be scripted
> git commit

The other day I was talking with Shawn Pearce and said that "-s theirs"
would make sense only if used with --no-commit.

But for such a use case, "git read-tree -m -u 0.2" would work just as
well, and discussion ended there ;-)

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

[Yaroslav Halchenko]

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


On Mon, 13 Dec 2010, Junio C Hamano wrote:
> would make sense only if used with --no-commit.

> But for such a use case, "git read-tree -m -u 0.2" would work just as
> well, and discussion ended there ;-)

hm -- read-tree sounded like yet another unknown to me feature of GIT I
was trying desperately to discover ;)  unfortunately it doesn't produce a merge
for me :-/ -- just a simple commit with the state taken from the other tree:

$> git read-tree -m -u origin/master                 
cached/staged changes: 179 changes  

$> git commit -m 'blunt merge for -s theirs: -m -u origin/master '
[maint/0.5 b246251] blunt merge for -s theirs: -m -u origin/master
 175 files changed, 9589 insertions(+), 4914 deletions(-)
 create mode 100644 doc/pics/ex_curvefitting_bold.svg
 create mode 100644 doc/pics/ex_curvefitting_searchlight.svg
 ...
$> git show HEAD^2                                                
fatal: ambiguous argument 'HEAD^2': unknown revision or path not in the working tree.

I am using git (Debian amd64): 1:1.7.2.3-2.1 (so it is 1.7.2.3)

-- 
Yaroslav O. Halchenko
Postdoctoral Fellow,   Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

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

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

[Junio C Hamano]

Yaroslav Halchenko <debian@onerussian.com> writes:

> On Mon, 13 Dec 2010, Junio C Hamano wrote:
>> would make sense only if used with --no-commit.
>
>> But for such a use case, "git read-tree -m -u 0.2" would work just as
>> well, and discussion ended there ;-)
>
> hm -- read-tree sounded like yet another unknown to me feature of GIT I
> was trying desperately to discover ;)  unfortunately it doesn't produce a merge
> for me

Didn't I already say it makes sense only with --no-commit?  IOW to shape
the tree.

And in your use case I do not think you would even want to have a merge.
Even if you run "git rm" to remove non-free stuff from the merge result,
if you merged the history of 0.2 that contains non-free stuff you are not
allowed to distribute (forbidden either by upstream or self-imposed dfsg,
the reason does not matter), people who gets the merge commit can follow
its second parent to grab the non-free stuff, no?

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

[Yaroslav Halchenko]

On Mon, 13 Dec 2010, Junio C Hamano wrote:
> > hm -- read-tree sounded like yet another unknown to me feature of GIT I
> > was trying desperately to discover ;)  unfortunately it doesn't produce a merge
> > for me

> Didn't I already say it makes sense only with --no-commit?  IOW to shape
> the tree.

rright -- in my case --no-commit so I could remove the content before
committing.

> And in your use case I do not think you would even want to have a merge.
> Even if you run "git rm" to remove non-free stuff from the merge result,
> if you merged the history of 0.2 that contains non-free stuff you are not
> allowed to distribute (forbidden either by upstream or self-imposed dfsg,
> the reason does not matter), people who gets the merge commit can follow
> its second parent to grab the non-free stuff, no?

I see your point better now -- so it is yet another dimension of
"the feature".

as for non-free -- I probably should have been more precise --
non-DFSG (debian free software guidelines)-free ;) i.e.:

*  free compiled,rendered materials, often binary blobs, without
   sources (e.g. .dll's, pdfs etc)

*  material under free but not DFSG-free licenses, etc

* if upstream repository already provides that 'non-free' material it
  would not be much of my misdemeanor to keep them as well buried in the
  repository history.  What I care is to have a cleaned branch from
  which I could git archive, and also which I could inspect in regards to
  changes between releases without visually filtering all changes in
  non-sources (e.g. those binary blobs) or irrelevant content.

  if ever legal situation causes upstream to rewrite history to remove
  them -- I will have to do that as well anyways :-/

Having an actual merge would be useful for making the explicit "bridge"
from upstream branch, thus '--no-commit -s theirs' with consecutive
cleaning before commit looks the way to go IMHO.  But I see now
that I could possibly use read-tree at times if a real necessity comes
to prune non-distributable content, and then obviously I do not want to
drag upstream's illegal stuff along.

-- 
Yaroslav O. Halchenko
Postdoctoral Fellow,   Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

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

[Johannes Sixt]

Am 12/13/2010 22:46, schrieb Yaroslav Halchenko:
> On Mon, 13 Dec 2010, Junio C Hamano wrote:
>> But for such a use case, "git read-tree -m -u 0.2" would work just as
>> well, and discussion ended there ;-)
> 
> hm -- read-tree sounded like yet another unknown to me feature of GIT I
> was trying desperately to discover ;)  unfortunately it doesn't produce a merge
> for me :-/ -- just a simple commit with the state taken from the other tree:

How about:

  git merge --no-commit -s ours 0.2
  git read-tree -m -u 0.2
  git commit -m "Reset to 0.2"

-- Hannes

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

[Yaroslav Halchenko]

On Tue, 14 Dec 2010, Johannes Sixt wrote:
> > hm -- read-tree sounded like yet another unknown to me feature of GIT I
> > was trying desperately to discover ;)  unfortunately it doesn't produce a merge
> > for me :-/ -- just a simple commit with the state taken from the other tree:
> How about:
>   git merge --no-commit -s ours 0.2
>   git read-tree -m -u 0.2
>   git commit -m "Reset to 0.2"

Thank you Johannes for chewing it up to ease the digestion by my
brainless stomach -- works just fine ;)

I guess this could be the alias for my needs:

    mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m -u "$1"' -

but since it might be a generic pattern for the use case(s) I have
stated I still see no objective reason why simple '-s theirs' should not
be there.

-- 
=------------------------------------------------------------------=
Keep in touch                                     www.onerussian.com
Yaroslav Halchenko                 www.ohloh.net/accounts/yarikoptic

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

[Nanako Shiraishi]

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

> I tried not to sound too negative when describing -Xours and -Xtheirs
> there, but actually I think "-s theirs" is even worse.  It is how you
> would discard what you did (perhaps because the other side has much better
> solution than your hack), but that can be much more easily and cleanly
> done with:
>
> 	$ git reset --hard origin
>
> Some poeple might say "But with 'merge -s theirs', I can keep what I did,
> too".  That reset is simply discarding what I did.
>
> That logic also is flawed.  You can instead:
>
> 	$ git branch i-was-stupid
>       $ git reset --hard origin
>
> if you really want to keep record of your failure.
>
> One big problem "-s theirs" has, compared to the above "reset to origin,
> discarding or setting aside the failed history" is that your 'master'
> history that your further development is based on will keep your failed
> crap in it forever if you did "-s theirs".  Hopefully you will become a
> better programmer over time, and you may eventually have something worth
> sharing with the world near the tip of your master branch.  When that
> happens, however, you _cannot_ offer your master branch to be pulled by
> the upstream, as the wider world will not be interested in your earlier
> mistakes at all.

Thanks for sharing your insight.  Perhaps the above can become a separate pargraph to explains why there is no "theirs" merge strategy somewhere in the manual?

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

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

[Johannes Schindelin]

Hi,

On Fri, 18 Jul 2008, Nanako Shiraishi wrote:

> Quoting Junio C Hamano <gitster@pobox.com>:
> 
> > * xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
> >  + Teach git-merge -X<option> again.
> >  + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
> >  + builtin-merge.c: use parse_options_step() "incremental parsing"
> >    machinery
> >  + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next
> >
> > This needs to be merged to master iff/when merge-theirs gets merged, 
> > but I do not think this series is widely supported, so both are on 
> > hold.
> 
> Why do you say it is not widely supported?  I may be wrong but I think 
> you developed these patches after somebody from the mailing list asked 
> for this feature.

Asking for a feature, and then not doing a single thing to defend why it 
makes sense, of a single person, who does not even speak up now, does not 
count for "wide support".

Ciao,
Dscho

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

[Nanako Shiraishi]

Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:

> On Fri, 18 Jul 2008, Nanako Shiraishi wrote:
>
>> Quoting Junio C Hamano <gitster@pobox.com>:
>> > This needs to be merged to master iff/when merge-theirs gets merged, 
>> > but I do not think this series is widely supported, so both are on 
>> > hold.
>> 
>> Why do you say it is not widely supported?  I may be wrong but I think 
>> you developed these patches after somebody from the mailing list asked 
>> for this feature.
>
> Asking for a feature, and then not doing a single thing to defend why it 
> makes sense, of a single person, who does not even speak up now, does not 
> count for "wide support".

For the record, I was not the one who asked for such a feature.

It seems that the conclusion of the discussion is that "theirs" promotes a bad workflow, and I am happy with that.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

What's cooking in git.git (topics)

[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 topics list the commits in reverse chronological order.  The topics
meant to be merged to the maintenance series have "maint-" in their names.

Due to increased activity level from people including GSoC students, I
expect 'next' to stay somewhat more active than previous rounds during the
1.6.0-rc cycle.  The request for people who usually follow 'next' is the
same as usual, though.  After -rc1 is tagged, please run 'master' for your
daily git use instead, in order to make sure 'master' does what it claims
to do without regression.

Tentative schedule, my wishful thinking:

 - 1.6.0-rc0 (Jul 20)
 - 1.6.0-rc1 (Jul 23)
 - 1.6.0-rc2 (Jul 30)
 - 1.6.0-rc3 (Aug  6)
 - 1.6.0     (Aug 10)

No real activity on 'next', as I was busy tending bugfixes and pushing out
v1.5.6.4 today.

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

* ns/am-abort (Wed Jul 16 19:39:10 2008 +0900) 1 commit
 + git am --abort

This one is for Ted; builds on top of the recent "am and rebase leaves
ORIG_HEAD just like reset, merge and pull does" rather nicely.

* jc/rerere-auto-more (Wed Jul 16 20:25:18 2008 -0700) 1 commit
 + rerere.autoupdate: change the message when autoupdate is in effect

This one is for Ingo.

This changes the message rerere issues after reusing previous conflict
resolution from "Resolved" to "Staged" when autoupdate option is in
effect.

It is envisioned that in practice, some auto resolutions are trickier and
iffier than others, and we would want to add a feature to mark individual
resolutions as "this is ok to autoupdate" or "do not autoupdate the result
using this resolution even when rerere.autoupdate is in effect" in the
future.  When that happens, these messages will make the distinction
clearer.

* ap/trackinfo (Wed Jul 16 15:19:27 2008 -0400) 1 commit
 + Reword "your branch has diverged..." lines to reduce line length

----------------------------------------------------------------
[Stalled/Needs more work]

* rs/imap (Wed Jul 9 22:29:02 2008 +0100) 5 commits
 - Documentation: Improve documentation for git-imap-send(1)
 - imap-send.c: more style fixes
 - imap-send.c: style fixes
 - git-imap-send: Support SSL
 - git-imap-send: Allow the program to be run from subdirectories of
   a git tree

I said: "Some people seem to prefer having this feature available also
with gnutls.  If such a patch materializes soon, that would be good, but
otherwise I'll merge this as-is to 'next'.  Such an enhancement can be
done in-tree on top of this series."  Anybody?

* gi/cherry-cache (Sat Jul 12 20:14:51 2008 -0700) 1 commit
 . cherry: cache patch-ids to avoid repeating work

The discussion suggested that the value of having the cache itself is
iffy, but I should pick up the updated one and look at it.

* lw/gitweb (Fri Jul 11 03:11:48 2008 +0200) 3 commits
 . gitweb: use new Git::Repo API, and add optional caching
 . Add new Git::Repo API
 . gitweb: add test suite with Test::WWW::Mechanize::CGI

* sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
 . Migrate git-am to use git-sequencer
 . Add git-sequencer test suite (t3350)
 . Add git-sequencer prototype documentation
 . Add git-sequencer shell prototype

I haven't looked at the updated series yet.  I should, but nobody else
seems to be looking at these patches, which is somewhat depressing but
understandable.  Summer is slower ;-)

* pb/submodule (Wed Jul 16 21:11:40 2008 +0200) 7 commits
 . t7403: Submodule git mv, git rm testsuite
 . git rm: Support for removing submodules
 . git mv: Support moving submodules
 . submodule.*: Introduce simple C interface for submodule lookup by
   path
 . git submodule add: Fix naming clash handling
 . t7400: Add short "git submodule add" testsuite
 . git-mv: Remove dead code branch

Long overdue usability improvement series for submodule.  Very much
welcomed.  It would be nice to have some submodule improvements in 1.6.0,
but it would take us a few more rounds to hit 'next' with this, and it
will not be in 'master' when 1.6.0 ships.

* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
 - [BROKEN wrt shallow clones] Ignore graft during object transfer

Cloning or fetching from a repository from grafts did not send objects
that are hidden by grafts, but the commits in the resulting repository do
need these to pass fsck.  This fixes object transfer to ignore grafts.

Another fix is needed to git-prune so that it ignores grafts but treats
commits that are mentioned in grafts as reachable.

* 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 is for peeling the line from the blamed version to see what's behind
it, which may or may not help applications like gitweb.

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

* xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
 + Teach git-merge -X<option> again.
 + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
 + builtin-merge.c: use parse_options_step() "incremental parsing"
   machinery
 + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next

* jc/merge-theirs (Fri Jul 18 02:43:00 2008 -0700) 6 commits
 - Document that merge strategies can now take their own options
 + Make "subtree" part more orthogonal to the rest of merge-
   recursive.
 + Teach git-pull to pass -X<option> to git-merge
 + Teach git-merge to pass -X<option> to the backend strategy module
 + git-merge-recursive-{ours,theirs}
 + git-merge-file --ours, --theirs

It appears nobody wants "theirs" nor "ours", so I'll soon apply a
wholesale revert for these series to 'next', and then these will be
dropped when we rewind 'next' after 1.6.0 final.

Please make sure next time somebody asks "ours/theirs" merge on the list
and #git s/he is quickly told that it was unanimously rejected so that
people do not have to waste time rehashing the topic ever again.

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

* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
 + merge: remove deprecated summary and diffstat options and config
   variables

This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet.  Perhaps
in 1.7.0.

* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
 + Revert "Make clients ask for "git program" over ssh and local
   transport"
 + Make clients ask for "git program" over ssh and local transport

This is the "botched" one.  Will be resurrected during 1.7.0 or 1.8.0
timeframe.

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

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

[Petr Baudis]

On Sat, Jul 19, 2008 at 06:58:55PM -0700, Junio C Hamano wrote:
> * pb/submodule (Wed Jul 16 21:11:40 2008 +0200) 7 commits
>  . t7403: Submodule git mv, git rm testsuite
>  . git rm: Support for removing submodules
>  . git mv: Support moving submodules
>  . submodule.*: Introduce simple C interface for submodule lookup by
>    path
>  . git submodule add: Fix naming clash handling
>  . t7400: Add short "git submodule add" testsuite
>  . git-mv: Remove dead code branch
> 
> Long overdue usability improvement series for submodule.  Very much
> welcomed.  It would be nice to have some submodule improvements in 1.6.0,
> but it would take us a few more rounds to hit 'next' with this, and it
> will not be in 'master' when 1.6.0 ships.

Do you think this would create serious problems?

One thing this patch series depends on now is changing the git mv
semantics in a rather non-trivial way, which is something we might want
to do in a major release instead of within the 1.6 series.

				Petr "Pasky" Baudis

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

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> Do you think this would create serious problems?
>
> One thing this patch series depends on now is changing the git mv
> semantics in a rather non-trivial way, which is something we might want
> to do in a major release instead of within the 1.6 series.

The change to git-mv perhaps is necessary to happen between a major
release boundary.  I do not know if the current round of patch to do so
will become ready in time for 1.6.0.  The rename-ce-at patch I looked at
did not look like it was.

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

[Brandon Casey]

Junio C Hamano wrote:

> * jc/reflog-expire (Sat Jun 28 22:24:49 2008 -0700) 2 commits
>  - Make default expiration period of reflog used for stash infinite
>  - Per-ref reflog expiry configuration

Thanks.

-brandon