threads / discuss / 12603

What's cooking in git.git (topics)

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

## tl;dr

368 messages between Mar 9, 2008 and Dec 14, 2010.

replies: 367people: 50as markdown or json

Junio C Hamano· Mar 9, 2008, 10:46 UTC · lore

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.

Junio C Hamano· Mar 12, 2008, 07:50 UTC · re: Junio C Hamano · lore

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.
Johannes Schindelin· Mar 12, 2008, 12:18 UTC · re: Junio C Hamano · lore

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

Hi,
On Wed, 12 Mar 2008, Junio C Hamano wrote:
Show 17 quoted lines
> * 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

Junio C Hamano· Mar 14, 2008, 09:00 UTC · re: Junio C Hamano · lore

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.
Junio C Hamano· Mar 23, 2008, 10:08 UTC · re: Junio C Hamano · lore

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.
Samuel Tardieu· Mar 23, 2008, 12:00 UTC · re: Junio C Hamano · lore

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

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/
Junio C Hamano· Mar 23, 2008, 17:15 UTC · re: Samuel Tardieu · lore

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

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

Samuel Tardieu· Mar 23, 2008, 22:34 UTC · re: Junio C Hamano · lore

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

>>>>> "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/
Steffen Prohaska· Mar 23, 2008, 12:39 UTC · re: Junio C Hamano · lore

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

On Sun, 23 Mar 2008, Junio C Hamano wrote:
Show 17 quoted lines
> * 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
Junio C Hamano· Mar 23, 2008, 17:37 UTC · re: Steffen Prohaska · lore

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

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.

Govind Salinas· Mar 23, 2008, 21:06 UTC · re: Junio C Hamano · lore

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

On Sun, Mar 23, 2008 at 5:08 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 6 quoted lines
>
>  * 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
Junio C Hamano· Mar 24, 2008, 03:01 UTC · re: Govind Salinas · lore

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

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

Junio C Hamano· Mar 28, 2008, 01:45 UTC · re: Junio C Hamano · lore

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.
Junio C Hamano· Mar 31, 2008, 08:40 UTC · re: Junio C Hamano · lore

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.
Junio C Hamano· Apr 4, 2008, 18:24 UTC · re: Junio C Hamano · lore

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.
Kristian Høgsberg· Apr 4, 2008, 20:21 UTC · re: Junio C Hamano · lore

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

On Fri, 2008-04-04 at 11:24 -0700, Junio C Hamano wrote:
Show 9 quoted lines
> 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
Junio C Hamano· Apr 4, 2008, 20:52 UTC · re: Kristian Høgsberg · lore

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

Kristian Høgsberg <krh@redhat.com> writes:
Show 11 quoted lines
> 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.

Johannes Schindelin· Apr 5, 2008, 00:26 UTC · re: Junio C Hamano · lore

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

Hi,
On Fri, 4 Apr 2008, Junio C Hamano wrote:
Show 14 quoted lines
> 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"

Junio C Hamano· Apr 5, 2008, 05:51 UTC · re: Johannes Schindelin · lore

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 11 quoted lines
> 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 ;-)

Junio C Hamano· Apr 9, 2008, 09:43 UTC · re: Junio C Hamano · lore

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.
Junio C Hamano· Apr 14, 2008, 07:00 UTC · re: Junio C Hamano · lore

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.
Jeff King· Apr 15, 2008, 19:23 UTC · re: Junio C Hamano · lore

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

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
Junio C Hamano· Apr 19, 2008, 08:19 UTC · re: Junio C Hamano · lore

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.
Johannes Schindelin· Apr 19, 2008, 14:23 UTC · re: Junio C Hamano · lore

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

Hi,
On Sat, 19 Apr 2008, Junio C Hamano wrote:
Show 8 quoted lines
> ----------------------------------------------------------------
> [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

Lars Hjemli· Apr 19, 2008, 16:34 UTC · re: Junio C Hamano · lore

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

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

Junio C Hamano· Apr 20, 2008, 04:08 UTC · re: Lars Hjemli · lore

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

"Lars Hjemli" <hjemli@gmail.com> writes:
Show 11 quoted lines
> 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.

Brandon Casey· Apr 21, 2008, 16:10 UTC · re: Junio C Hamano · lore

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

Junio C Hamano wrote:
Show 5 quoted lines
> * 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
Junio C Hamano· Apr 22, 2008, 10:03 UTC · re: Junio C Hamano · lore

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.
Ping Yin· Apr 22, 2008, 13:59 UTC · re: Junio C Hamano · lore

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

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'.
>
Show 11 quoted lines
>
> * 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
Josef Weidendorfer· Apr 22, 2008, 14:55 UTC · re: Ping Yin · lore

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

On Tuesday 22 April 2008, Ping Yin wrote:
Show 11 quoted lines
> 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").

Ping Yin· Apr 22, 2008, 17:13 UTC · re: Josef Weidendorfer · lore

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

On Tue, Apr 22, 2008 at 10:55 PM, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:

Show 18 quoted lines
> 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.

Show 5 quoted lines
>
>  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.

Show 9 quoted lines
>
>  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
Johannes Schindelin· Apr 22, 2008, 17:28 UTC · re: Ping Yin · lore

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

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

Ping Yin· Apr 23, 2008, 01:27 UTC · re: Johannes Schindelin · lore

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

On Wed, Apr 23, 2008 at 1:28 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 14 quoted lines
> 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
Ping Yin· Apr 23, 2008, 02:03 UTC · re: Ping Yin · lore

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

On Wed, Apr 23, 2008 at 9:27 AM, Ping Yin <pkufranky@gmail.com> wrote:
Show 19 quoted lines
>
> 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.
Show 6 quoted lines
>  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
Josef Weidendorfer· Apr 22, 2008, 18:07 UTC · re: Ping Yin · lore

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

On Tuesday 22 April 2008, Ping Yin wrote:
Show 8 quoted lines
> >  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.

Show 7 quoted lines
> >  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.

Show 12 quoted lines
> >  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
Ping Yin· Apr 23, 2008, 01:59 UTC · re: Josef Weidendorfer · lore

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

On Wed, Apr 23, 2008 at 2:07 AM, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:

Show 17 quoted lines
> 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.

Show 12 quoted lines
>
>
>  > >  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.

Show 8 quoted lines
>
>  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
Fedor Sergeev· Apr 23, 2008, 07:47 UTC · re: Ping Yin · lore

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

On Wed, 23 Apr 2008, Ping Yin wrote:
Show 17 quoted lines
> 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.
Ping Yin· Apr 23, 2008, 08:32 UTC · re: Fedor Sergeev · lore

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

On Wed, Apr 23, 2008 at 3:47 PM, Fedor Sergeev <Fedor.Sergeev@sun.com> wrote:
Show 36 quoted lines
> 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
Robin Rosenberg· Apr 23, 2008, 08:47 UTC · re: Fedor Sergeev · lore

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

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
Fedor Sergeev· Apr 23, 2008, 09:16 UTC · re: Robin Rosenberg · lore

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

On Wed, 23 Apr 2008, Robin Rosenberg wrote:
Show 8 quoted lines
> 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.
Michele Ballabio· Apr 22, 2008, 20:51 UTC · re: Junio C Hamano · lore

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

On Tuesday 22 April 2008, Junio C Hamano wrote:
Show 6 quoted lines
> * 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?
Junio C Hamano· Apr 23, 2008, 00:22 UTC · re: Michele Ballabio · lore

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

Michele Ballabio <barra_cuda@katamail.com> writes:
Show 15 quoted lines
> 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?

Michele Ballabio· Apr 23, 2008, 07:36 UTC · re: Junio C Hamano · lore

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

On Wednesday 23 April 2008, Junio C Hamano wrote:
Show 7 quoted lines
> 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.

Junio C Hamano· Apr 27, 2008, 06:04 UTC · re: Junio C Hamano · lore

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.
Ping Yin· Apr 27, 2008, 06:44 UTC · re: Junio C Hamano · lore

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

On Sun, Apr 27, 2008 at 2:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 6 quoted lines
>
>  * 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
Junio C Hamano· May 6, 2008, 06:38 UTC · re: Junio C Hamano · lore

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.
Junio C Hamano· May 12, 2008, 22:03 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:
Show 10 quoted lines
> [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
Junio C Hamano· May 14, 2008, 22:30 UTC · re: Junio C Hamano · lore

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.
Daniel Barkalow· May 14, 2008, 22:55 UTC · re: Junio C Hamano · lore

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

On Wed, 14 May 2008, Junio C Hamano wrote:
Show 11 quoted lines
> * 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)

Junio C Hamano· May 15, 2008, 04:30 UTC · re: Daniel Barkalow · lore

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

Daniel Barkalow <barkalow@iabervon.org> writes:
Show 5 quoted lines
> 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 ;-). .

Steffen Prohaska· May 15, 2008, 05:51 UTC · re: Junio C Hamano · lore

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

On Wed, 14 May 2008, Junio C Hamano wrote:
Show 10 quoted lines
> 
> 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
Junio C Hamano· May 22, 2008, 01:18 UTC · re: Junio C Hamano · lore

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.

Johannes Schindelin· May 22, 2008, 11:35 UTC · re: Junio C Hamano · lore

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

Hi,
On Wed, 21 May 2008, Junio C Hamano wrote:
Show 6 quoted lines
> * 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).
Show 8 quoted lines
> * 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.

Show 7 quoted lines
> * 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.
Show 12 quoted lines
> * 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.
Show 23 quoted lines
> * 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

Junio C Hamano· May 22, 2008, 18:17 UTC · re: Johannes Schindelin · lore

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 8 quoted lines
>> * 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.

Show 8 quoted lines
>> * 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.

Show 8 quoted lines
>> * 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.

Show 14 quoted lines
>> * 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 ;-)?
Daniel Barkalow· May 22, 2008, 22:02 UTC · re: Junio C Hamano · lore

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

On Thu, 22 May 2008, Junio C Hamano wrote:
Show 16 quoted lines
> >> * 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*
Stephan Beyer· May 25, 2008, 21:29 UTC · re: Johannes Schindelin · lore

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

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
Junio C Hamano· May 26, 2008, 01:22 UTC · re: Junio C Hamano · lore

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.

Junio C Hamano· May 27, 2008, 05:36 UTC · re: Junio C Hamano · lore

[PATCH] git-diff: allow --no-index semantics a bit more

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
Junio C Hamano· May 30, 2008, 20:44 UTC · re: Junio C Hamano · lore

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.
Jon Loeliger· May 30, 2008, 21:10 UTC · re: Junio C Hamano · lore

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

Junio C Hamano wrote:
Show 28 quoted lines
> 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
Stephan Beyer· May 31, 2008, 01:25 UTC · re: Jon Loeliger · lore

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

Hi,
Show 7 quoted lines
> 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.

Show 7 quoted lines
> 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
Steven Grimm· May 30, 2008, 22:00 UTC · re: Junio C Hamano · lore

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

On May 30, 2008, at 1:44 PM, Junio C Hamano wrote:
Show 7 quoted lines
> [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
Junio C Hamano· Jun 2, 2008, 07:58 UTC · re: Junio C Hamano · lore

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.
Jakub Narebski· Jun 2, 2008, 08:10 UTC · re: Junio C Hamano · lore

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

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
 
Show 8 quoted lines
> ----------------------------------------------------------------
> [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
Sebastian Bober· Jun 2, 2008, 11:56 UTC · re: Junio C Hamano · lore

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

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
Johannes Schindelin· Jun 2, 2008, 15:17 UTC · re: Junio C Hamano · lore

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

Hi,
On Mon, 2 Jun 2008, Junio C Hamano wrote:
Show 8 quoted lines
> * 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

Shawn O. Pearce· Jun 2, 2008, 15:43 UTC · re: Johannes Schindelin · lore

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

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.
Johannes Schindelin· Jun 2, 2008, 16:14 UTC · re: Shawn O. Pearce · lore

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

Hi,
On Mon, 2 Jun 2008, Shawn O. Pearce wrote:
Show 9 quoted lines
> 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.
Show 10 quoted lines
> 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.

Show 5 quoted lines
> 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.

Show 5 quoted lines
> - 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

Junio C Hamano· Jun 2, 2008, 18:13 UTC · re: Johannes Schindelin · lore

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 6 quoted lines
> 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.

Johannes Schindelin· Jun 2, 2008, 19:17 UTC · re: Junio C Hamano · lore

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

Hi,
On Mon, 2 Jun 2008, Junio C Hamano wrote:
Show 12 quoted lines
> 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"?
Show 7 quoted lines
> 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

Johannes Schindelin· Jun 2, 2008, 19:25 UTC · re: Johannes Schindelin · lore

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

Hi,
On Mon, 2 Jun 2008, Johannes Schindelin wrote:
Show 7 quoted lines
> 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

Junio C Hamano· Jun 13, 2008, 10:16 UTC · re: Junio C Hamano · lore

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.
Junio C Hamano· Jun 18, 2008, 07:31 UTC · re: Junio C Hamano · lore

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.
Johan Herland· Jun 19, 2008, 08:58 UTC · re: Junio C Hamano · lore

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

On Wednesday 18 June 2008, Junio C Hamano wrote:
Show 10 quoted lines
> [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
Junio C Hamano· Jun 21, 2008, 09:44 UTC · re: Junio C Hamano · lore

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.
Miklos Vajna· Jun 21, 2008, 12:14 UTC · re: Junio C Hamano · lore

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

On Sat, Jun 21, 2008 at 02:44:50AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
Show 12 quoted lines
> * 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
Junio C Hamano· Jun 24, 2008, 07:59 UTC · re: Miklos Vajna · lore

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

Miklos Vajna <vmiklos@frugalware.org> writes:
Show 18 quoted lines
> 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.

Pieter de Bie· Jun 24, 2008, 08:12 UTC · re: Junio C Hamano · lore

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

On 24 jun 2008, at 09:59, Junio C Hamano wrote:
Show 8 quoted lines
> 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
Pieter de Bie· Jun 24, 2008, 08:16 UTC · re: Pieter de Bie · lore

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

On 24 jun 2008, at 10:12, Pieter de Bie wrote:
Show 5 quoted lines
> 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.
Miklos Vajna· Jun 24, 2008, 16:02 UTC · re: Pieter de Bie · lore

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

On Tue, Jun 24, 2008 at 10:12:28AM +0200, Pieter de Bie <pdebie@ai.rug.nl> wrote:
Show 10 quoted lines
> 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.
Johannes Schindelin· Jun 24, 2008, 16:25 UTC · re: Miklos Vajna · lore

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

Hi,
On Tue, 24 Jun 2008, Miklos Vajna wrote:
Show 13 quoted lines
> 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

Miklos Vajna· Jun 24, 2008, 18:54 UTC · re: Johannes Schindelin · lore

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

On Tue, Jun 24, 2008 at 05:25:57PM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 15 quoted lines
> > > 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

Johannes Schindelin· Jun 24, 2008, 19:08 UTC · re: Miklos Vajna · lore

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

Hi,
On Tue, 24 Jun 2008, Miklos Vajna wrote:
Show 26 quoted lines
> 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

Jakub Narebski· Jun 24, 2008, 19:31 UTC · re: Johannes Schindelin · lore

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 14 quoted lines
> 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
Johannes Schindelin· Jun 24, 2008, 19:34 UTC · re: Jakub Narebski · lore

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

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

Jakub Narebski· Jun 24, 2008, 20:06 UTC · re: Johannes Schindelin · lore

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

Hello!
Johannes Schindelin wrote:
Show 9 quoted lines
> 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
Jakub Narebski· Jun 26, 2008, 15:41 UTC · re: Johannes Schindelin · lore

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

On Tue, 24 Jun 2008, Johannes Schindelin wrote:
Show 11 quoted lines
> 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
Junio C Hamano· Jun 24, 2008, 20:44 UTC · re: Johannes Schindelin · lore

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 12 quoted lines
>> 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?

Miklos Vajna· Jun 24, 2008, 22:10 UTC · re: Junio C Hamano · lore

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

On Tue, Jun 24, 2008 at 01:44:34PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
Show 12 quoted lines
> >> 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.

Junio C Hamano· Jun 24, 2008, 23:16 UTC · re: Miklos Vajna · lore

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

Miklos Vajna <vmiklos@frugalware.org> writes:
Show 19 quoted lines
> 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?

Miklos Vajna· Jun 24, 2008, 23:32 UTC · re: Junio C Hamano · lore

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

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.
Junio C Hamano· Jun 25, 2008, 02:57 UTC · re: Miklos Vajna · lore

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

Miklos Vajna <vmiklos@frugalware.org> writes:
Show 5 quoted lines
> 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
しらいしななこ· Jun 25, 2008, 03:08 UTC · re: Junio C Hamano · lore

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

Quoting Junio C Hamano <gitster@pobox.com>:
Show 26 quoted lines
> 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/
Junio C Hamano· Jun 25, 2008, 03:22 UTC · re: しらいしななこ · lore

[PATCH] Keep some git-* programs in $(bindir)

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
Junio C Hamano· Jun 25, 2008, 03:26 UTC · re: Junio C Hamano · lore

[PATCH] Ask for "git program" when asking for "git-program" over SSH connection

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
Shawn O. Pearce· Jun 25, 2008, 03:45 UTC · re: Junio C Hamano · lore

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

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.
...
Show 12 quoted lines
> 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.
Junio C Hamano· Jun 25, 2008, 04:32 UTC · re: Shawn O. Pearce · lore

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

"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?
Shawn O. Pearce· Jun 25, 2008, 04:44 UTC · re: Junio C Hamano · lore

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

Junio C Hamano <gitster@pobox.com> wrote:
Show 10 quoted lines
> "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.
Junio C Hamano· Jun 25, 2008, 05:09 UTC · re: Shawn O. Pearce · lore

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 7 quoted lines
>> 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?

Junio C Hamano· Jun 25, 2008, 05:13 UTC · re: Junio C Hamano · lore

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

Junio C Hamano <gitster@pobox.com> writes:
Show 12 quoted lines
> "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-" ;-)

Junio C Hamano· Jun 25, 2008, 05:27 UTC · re: Junio C Hamano · lore

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

Junio C Hamano <gitster@pobox.com> writes:
Show 5 quoted lines
> 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.

Shawn O. Pearce· Jun 25, 2008, 05:38 UTC · re: Junio C Hamano · lore

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

Junio C Hamano <gitster@pobox.com> wrote:
Show 9 quoted lines
> 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. :-)

 
Show 23 quoted lines
> * 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.
Junio C Hamano· Jun 25, 2008, 22:47 UTC · re: Shawn O. Pearce · lore

[PATCH] daemon: accept "git program" as well

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] == ' ') {
 			/*
Junio C Hamano· Jun 25, 2008, 22:55 UTC · re: Junio C Hamano · lore

[PATCH] Make clients ask for "git program" over ssh and local transport

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
Junio C Hamano· Jun 25, 2008, 22:58 UTC · re: Junio C Hamano · lore

[PATCH] Ask for "git program" even against git-daemon

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
Shawn O. Pearce· Jun 25, 2008, 23:27 UTC · re: Junio C Hamano · lore

Re: [PATCH] Ask for "git program" even against git-daemon

Junio C Hamano <gitster@pobox.com> wrote:
Show 13 quoted lines
> 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.
Junio C Hamano· Jun 25, 2008, 23:36 UTC · re: Shawn O. Pearce · lore

Re: [PATCH] Ask for "git program" even against git-daemon

"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 12 quoted lines
> 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 ;-)

Shawn O. Pearce· Jun 25, 2008, 23:57 UTC · re: Junio C Hamano · lore

Re: [PATCH] Ask for "git program" even against git-daemon

Junio C Hamano <gitster@pobox.com> wrote:
Show 18 quoted lines
> "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.
Junio C Hamano· Jun 26, 2008, 00:07 UTC · re: Shawn O. Pearce · lore

Re: [PATCH] Ask for "git program" even against git-daemon

"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 24 quoted lines
> 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 ;-).
Shawn O. Pearce· Jun 25, 2008, 23:13 UTC · re: Junio C Hamano · lore

Re: [PATCH] Make clients ask for "git program" over ssh and local transport

Junio C Hamano <gitster@pobox.com> wrote:
Show 9 quoted lines
> 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.
Shawn O. Pearce· Jun 25, 2008, 23:02 UTC · re: Junio C Hamano · lore

Re: [PATCH] daemon: accept "git program" as well

Junio C Hamano <gitster@pobox.com> wrote:
Show 8 quoted lines
> 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.
Show 19 quoted lines
>  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.
Junio C Hamano· Jun 25, 2008, 23:26 UTC · re: Shawn O. Pearce · lore

Re: [PATCH] daemon: accept "git program" as well

"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 11 quoted lines
> 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.

Tommi Virtanen· Jun 26, 2008, 08:20 UTC · re: Junio C Hamano · lore

Re: [PATCH] daemon: accept "git program" as well

On Wed, Jun 25, 2008 at 04:26:46PM -0700, Junio C Hamano wrote:
Show 7 quoted lines
> 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.

-- 
:(){ :|:&};:
Olivier Marin· Jun 26, 2008, 23:38 UTC · re: Tommi Virtanen · lore

Re: [PATCH] daemon: accept "git program" as well

Hi,
Tommi Virtanen a écrit :
Show 9 quoted lines
> 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.
Junio C Hamano· Jun 26, 2008, 23:42 UTC · re: Olivier Marin · lore

Re: [PATCH] daemon: accept "git program" as well

Olivier Marin <dkr+ml.git@free.fr> writes:
Show 55 quoted lines
> 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?

Theodore Tso· Jun 25, 2008, 13:06 UTC · re: Junio C Hamano · lore

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

On Tue, Jun 24, 2008 at 10:27:07PM -0700, Junio C Hamano wrote:
Show 25 quoted lines
> 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
Junio C Hamano· Jun 25, 2008, 17:42 UTC · re: Theodore Tso · lore

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

Theodore Tso <tytso@mit.edu> writes:
Show 7 quoted lines
> 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".

Shawn O. Pearce· Jun 25, 2008, 05:34 UTC · re: Junio C Hamano · lore

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

Junio C Hamano <gitster@pobox.com> wrote:
Show 13 quoted lines
> 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.
Junio C Hamano· Jun 25, 2008, 05:53 UTC · re: Shawn O. Pearce · lore

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 17 quoted lines
> 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.

Junio C Hamano· Jun 25, 2008, 05:30 UTC · re: Shawn O. Pearce · lore

Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection

"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 5 quoted lines
> 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.

Shawn O. Pearce· Jun 25, 2008, 04:17 UTC · re: Junio C Hamano · lore

Re: [PATCH] Keep some git-* programs in $(bindir)

Junio C Hamano <gitster@pobox.com> wrote:
Show 13 quoted lines
>  * しらいしななこ <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.
Daniel Barkalow· Jun 25, 2008, 04:19 UTC · re: Junio C Hamano · lore

Re: [PATCH] Keep some git-* programs in $(bindir)

On Tue, 24 Jun 2008, Junio C Hamano wrote:
Show 7 quoted lines
> 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*
Shawn O. Pearce· Jun 25, 2008, 04:37 UTC · re: Daniel Barkalow · lore

Re: [PATCH] Keep some git-* programs in $(bindir)

Daniel Barkalow <barkalow@iabervon.org> wrote:
Show 14 quoted lines
> 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.
Shawn O. Pearce· Jun 25, 2008, 03:26 UTC · re: しらいしななこ · lore

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

 <nanako3@lavabit.com> wrote:
Show 28 quoted lines
> 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.
Jakub Narebski· Jun 25, 2008, 00:11 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:
Show 9 quoted lines
> 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
Shawn O. Pearce· Jun 25, 2008, 03:32 UTC · re: Jakub Narebski · lore

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

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.
Miklos Vajna· Jun 25, 2008, 07:29 UTC · re: Jakub Narebski · lore

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

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

Junio C Hamano· Jun 23, 2008, 07:15 UTC · re: Junio C Hamano · lore

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
Miklos Vajna· Jun 23, 2008, 12:15 UTC · re: Junio C Hamano · lore

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

On Mon, Jun 23, 2008 at 12:15:35AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
Show 18 quoted lines
> * 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. ;-)

Junio C Hamano· Jun 25, 2008, 09:31 UTC · re: Junio C Hamano · lore

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
Junio C Hamano· Jun 29, 2008, 08:50 UTC · re: Junio C Hamano · lore

[PATCH] Make default expiration period of reflog used for stash infinite

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
Olivier Marin· Jun 30, 2008, 23:45 UTC · re: Junio C Hamano · lore

Re: [PATCH] Make default expiration period of reflog used for stash infinite

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.
Junio C Hamano· Jul 1, 2008, 07:28 UTC · re: Olivier Marin · lore

Re: [PATCH] Make default expiration period of reflog used for stash infinite

Olivier Marin <dkr+ml.git@free.fr> writes:
Show 8 quoted lines
> 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.

Nanako Shiraishi· Jul 2, 2008, 10:59 UTC · re: Junio C Hamano · lore

[PATCH] Disconnect stash from its base commit

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/
Johannes Schindelin· Jul 2, 2008, 13:51 UTC · re: Nanako Shiraishi · lore

Re: [PATCH] Disconnect stash from its base commit

Hi,
On Wed, 2 Jul 2008, Nanako Shiraishi wrote:
Show 10 quoted lines
> 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?

Junio C Hamano· Jul 2, 2008, 19:01 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Disconnect stash from its base commit

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 11 quoted lines
>> 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.

Abhijit Menon-Sen· Jul 2, 2008, 19:54 UTC · re: Junio C Hamano · lore

Re: [PATCH] Disconnect stash from its base commit

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
Junio C Hamano· Jul 2, 2008, 21:04 UTC · re: Abhijit Menon-Sen · lore

Re: [PATCH] Disconnect stash from its base commit

Abhijit Menon-Sen <ams@toroid.org> writes:
Show 10 quoted lines
> 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.

Abhijit Menon-Sen· Jul 3, 2008, 02:23 UTC · re: Junio C Hamano · lore

[PATCH] Implement "git stash branch <newbranch> <stash>"

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
Junio C Hamano· Jul 3, 2008, 04:12 UTC · re: Abhijit Menon-Sen · lore

Re: [PATCH] Implement "git stash branch <newbranch> <stash>"

Abhijit Menon-Sen <ams@toroid.org> writes:
Show 13 quoted lines
> +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.

Abhijit Menon-Sen· Jul 3, 2008, 06:16 UTC · re: Junio C Hamano · lore

[PATCH] Implement "git stash branch <newbranch> <stash>"

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
Abhijit Menon-Sen· Jul 6, 2008, 11:23 UTC · re: Abhijit Menon-Sen · lore

[PATCH v3] Implement "git stash branch <newbranch> <stash>"

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
Johannes Schindelin· Jul 6, 2008, 12:54 UTC · re: Abhijit Menon-Sen · lore

Re: [PATCH v3] Implement "git stash branch <newbranch> <stash>"

Hi,
On Sun, 6 Jul 2008, Abhijit Menon-Sen wrote:
Show 9 quoted lines
> 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

Abhijit Menon-Sen· Jul 6, 2008, 14:45 UTC · re: Johannes Schindelin · lore

[PATCH] Add a test for "git stash branch"

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
Junio C Hamano· Jul 6, 2008, 19:53 UTC · re: Abhijit Menon-Sen · lore

Re: [PATCH] Add a test for "git stash branch"

Abhijit Menon-Sen <ams@toroid.org> writes:
Show 7 quoted lines
> 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.

Show 13 quoted lines
> +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
Abhijit Menon-Sen· Jul 6, 2008, 21:20 UTC · re: Junio C Hamano · lore

[PATCH v2] Add a test for "git stash branch"

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
Junio C Hamano· Jun 29, 2008, 08:50 UTC · re: Junio C Hamano · lore

[PATCH] Teach git-merge to pass -X<option> to the backend strategy module

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
Jakub Narebski· Jun 29, 2008, 10:32 UTC · re: Junio C Hamano · lore

Re: [PATCH] Teach git-merge to pass -X<option> to the backend strategy module

Junio C Hamano wrote:
Show 10 quoted lines
> 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
Junio C Hamano· Jun 29, 2008, 19:09 UTC · re: Jakub Narebski · lore

Re: [PATCH] Teach git-merge to pass -X<option> to the backend strategy module

Jakub Narebski <jnareb@gmail.com> writes:
Show 15 quoted lines
> 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 ;-)
Junio C Hamano· Jun 29, 2008, 08:55 UTC · re: Junio C Hamano · lore

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

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
Linus Torvalds· Jun 29, 2008, 18:35 UTC · re: Junio C Hamano · lore

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

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
Junio C Hamano· Jun 29, 2008, 19:08 UTC · re: Linus Torvalds · lore

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

Linus Torvalds <torvalds@linux-foundation.org> writes:
Show 8 quoted lines
> 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.

Junio C Hamano· Jun 29, 2008, 20:11 UTC · re: Linus Torvalds · lore

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

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.
Pieter de Bie· Jun 29, 2008, 20:15 UTC · re: Junio C Hamano · lore

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

On 29 jun 2008, at 22:11, Junio C Hamano wrote:
Show 6 quoted lines
> 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
Johannes Schindelin· Jun 29, 2008, 21:57 UTC · re: Pieter de Bie · lore

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

Hi,
On Sun, 29 Jun 2008, Pieter de Bie wrote:
Show 10 quoted lines
> 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

Steffen Prohaska· Jun 29, 2008, 22:00 UTC · re: Pieter de Bie · lore

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

On Jun 29, 2008, at 10:15 PM, Pieter de Bie wrote:
Show 14 quoted lines
>
> 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
Jeff King· Jun 30, 2008, 03:30 UTC · re: Junio C Hamano · lore

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

On Sun, Jun 29, 2008 at 01:55:13AM -0700, Junio C Hamano wrote:
Show 7 quoted lines
> * 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
Junio C Hamano· Jun 30, 2008, 05:31 UTC · re: Jeff King · lore

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

Jeff King <peff@peff.net> writes:
Show 19 quoted lines
> 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'".

Jeff King· Jun 30, 2008, 05:33 UTC · re: Junio C Hamano · lore

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

On Sun, Jun 29, 2008 at 10:31:00PM -0700, Junio C Hamano wrote:
Show 12 quoted lines
> > 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
Junio C Hamano· Jun 30, 2008, 05:38 UTC · re: Jeff King · lore

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

Jeff King <peff@peff.net> writes:
Show 17 quoted lines
> 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.
Junio C Hamano· Jun 30, 2008, 09:08 UTC · re: Junio C Hamano · lore

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
Steffen Prohaska· Jun 30, 2008, 11:19 UTC · re: Junio C Hamano · lore

How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics))

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(-)
Johannes Sixt· Jun 30, 2008, 18:47 UTC · re: Steffen Prohaska · lore

Re: [msysGit] How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics))

On Montag, 30. Juni 2008, Steffen Prohaska wrote:
Show 25 quoted lines
> 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
Clifford Caoile· Jul 1, 2008, 00:03 UTC · re: Johannes Sixt · lore

Re: How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics))

Hi:
On Tue, Jul 1, 2008 at 3:47 AM, Johannes Sixt <johannes.sixt@telecom.at> wrote:
Show 10 quoted lines
>
> 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

Steffen Prohaska· Jul 2, 2008, 08:31 UTC · re: Johannes Sixt · lore

Re: How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics))

On Jun 30, 2008, at 8:47 PM, Johannes Sixt wrote:
Show 5 quoted lines
> 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
Steffen Prohaska· Jul 2, 2008, 08:32 UTC · re: Steffen Prohaska · lore

[PATCH 01/12] Fake reencoding success under NO_ICONV instead of returning NULL.

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
Steffen Prohaska· Jul 2, 2008, 08:32 UTC · re: Steffen Prohaska · lore

[PATCH 02/12] Do not complain about "no common commits" in an empty repo

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
Steffen Prohaska· Jul 2, 2008, 08:32 UTC · re: Steffen Prohaska · lore

[PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures

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
Steffen Prohaska· Jul 2, 2008, 08:32 UTC · re: Steffen Prohaska · lore

[PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds.

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
Steffen Prohaska· Jul 2, 2008, 08:32 UTC · re: Steffen Prohaska · lore

[PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser

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
Steffen Prohaska· Jul 2, 2008, 08:32 UTC · re: Steffen Prohaska · lore

[PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

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
Steffen Prohaska· Jul 2, 2008, 08:32 UTC · re: Steffen Prohaska · lore

[PATCH 07/12] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable

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
Steffen Prohaska· Jul 2, 2008, 08:32 UTC · re: Steffen Prohaska · lore

[PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it.

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
Steffen Prohaska· Jul 2, 2008, 08:32 UTC · re: Steffen Prohaska · lore

[PATCH 09/12] We need to check for msys as well as Windows in add--interactive.

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
Steffen Prohaska· Jul 2, 2008, 08:32 UTC · re: Steffen Prohaska · lore

[PATCH 10/12] Add ANSI control code emulation for the Windows console

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
Steffen Prohaska· Jul 2, 2008, 08:32 UTC · re: Steffen Prohaska · lore

[PATCH 11/12] verify_path(): do not allow absolute paths

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
Steffen Prohaska· Jul 2, 2008, 08:32 UTC · re: Steffen Prohaska · lore

[PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next

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
Johannes Schindelin· Jul 2, 2008, 16:17 UTC · re: Steffen Prohaska · lore

Re: [msysGit] [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next

Hi,
On Wed, 2 Jul 2008, Steffen Prohaska wrote:
Show 5 quoted lines
> 
> 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

Steffen Prohaska· Jul 2, 2008, 17:08 UTC · re: Johannes Schindelin · lore

Re: [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next

On Jul 2, 2008, at 6:17 PM, Johannes Schindelin wrote:
Show 12 quoted lines
> 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
Johannes Sixt· Jul 2, 2008, 19:32 UTC · re: Steffen Prohaska · lore

Re: [msysGit] Re: [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next

On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
Show 19 quoted lines
> 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
Steffen Prohaska· Jul 3, 2008, 06:06 UTC · re: Johannes Sixt · lore

Re: [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next

On Jul 2, 2008, at 9:32 PM, Johannes Sixt wrote:
Show 27 quoted lines
> 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
Junio C Hamano· Jul 3, 2008, 06:13 UTC · re: Steffen Prohaska · lore

Re: [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next

Steffen Prohaska <prohaska@zib.de> writes:
Show 11 quoted lines
> 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;
 }
 
Junio C Hamano· Jul 2, 2008, 09:21 UTC · re: Steffen Prohaska · lore

Re: [PATCH 11/12] verify_path(): do not allow absolute paths

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?
Steffen Prohaska· Jul 2, 2008, 14:24 UTC · re: Junio C Hamano · lore

Re: [PATCH 11/12] verify_path(): do not allow absolute paths

On Jul 2, 2008, at 11:21 AM, Junio C Hamano wrote:
Show 6 quoted lines
> 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
Johannes Schindelin· Jul 2, 2008, 16:15 UTC · re: Junio C Hamano · lore

Re: [PATCH 11/12] verify_path(): do not allow absolute paths

Hi,
On Wed, 2 Jul 2008, Junio C Hamano wrote:
Show 6 quoted lines
> 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

Steffen Prohaska· Jul 2, 2008, 17:20 UTC · re: Johannes Schindelin · lore

Re: [PATCH 11/12] verify_path(): do not allow absolute paths

On Jul 2, 2008, at 6:15 PM, Johannes Schindelin wrote:
Show 24 quoted lines
> 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
Johannes Schindelin· Jul 2, 2008, 17:31 UTC · re: Steffen Prohaska · lore

Re: [PATCH 11/12] verify_path(): do not allow absolute paths

Hi,
On Wed, 2 Jul 2008, Steffen Prohaska wrote:
Show 32 quoted lines
> 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

Johannes Sixt· Jul 2, 2008, 19:17 UTC · re: Steffen Prohaska · lore

Re: [msysGit] [PATCH 10/12] Add ANSI control code emulation for the Windows console

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
Peter Harris· Jul 2, 2008, 19:32 UTC · re: Johannes Sixt · lore

Re: [msysGit] [PATCH 10/12] Add ANSI control code emulation for the Windows console

On Wed, Jul 2, 2008 at 3:17 PM, Johannes Sixt wrote:
Show 7 quoted lines
> 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
Johannes Sixt· Jul 7, 2008, 18:41 UTC · re: Steffen Prohaska · lore

Re: [msysGit] [PATCH 10/12] Add ANSI control code emulation for the Windows console

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.

Show 8 quoted lines
> +#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
Junio C Hamano· Jul 2, 2008, 09:20 UTC · re: Steffen Prohaska · lore

Re: [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it.

Steffen Prohaska <prohaska@zib.de> writes:
Show 16 quoted lines
> 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
Steffen Prohaska· Jul 2, 2008, 14:22 UTC · re: Junio C Hamano · lore

Re: [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it.

On Jul 2, 2008, at 11:20 AM, Junio C Hamano wrote:
Show 29 quoted lines
> 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
Johannes Schindelin· Jul 2, 2008, 16:52 UTC · re: Junio C Hamano · lore

Re: [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it.

Hi,
On Wed, 2 Jul 2008, Junio C Hamano wrote:
Show 26 quoted lines
> 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

		
Junio C Hamano· Jul 2, 2008, 09:16 UTC · re: Steffen Prohaska · lore

Re: [PATCH 07/12] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable

Steffen Prohaska <prohaska@zib.de> writes:
Show 20 quoted lines
> 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.

Steffen Prohaska· Jul 11, 2008, 16:48 UTC · re: Junio C Hamano · lore

[PATCH] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable

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
Johannes Schindelin· Jul 11, 2008, 18:42 UTC · re: Steffen Prohaska · lore

Re: [PATCH] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable

Hi,
On Fri, 11 Jul 2008, Steffen Prohaska wrote:
Show 20 quoted lines
> 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_.

Steffen Prohaska· Jul 11, 2008, 20:32 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable

On Jul 11, 2008, at 8:42 PM, Johannes Schindelin wrote:
Show 28 quoted lines
> 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
Johannes Schindelin· Jul 11, 2008, 20:40 UTC · re: Steffen Prohaska · lore

Re: [PATCH] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable

Hi,
On Fri, 11 Jul 2008, Steffen Prohaska wrote:
Show 31 quoted lines
> 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

Johannes Sixt· Jul 2, 2008, 19:04 UTC · re: Steffen Prohaska · lore

Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
Show 30 quoted lines
> 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
Johannes Schindelin· Jul 3, 2008, 11:10 UTC · re: Johannes Sixt · lore

Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

Hi,
On Wed, 2 Jul 2008, Johannes Sixt wrote:
Show 44 quoted lines
> 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

Steffen Prohaska· Jul 4, 2008, 08:50 UTC · re: Johannes Schindelin · lore

Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

On Jul 3, 2008, at 1:10 PM, Johannes Schindelin wrote:
Show 49 quoted lines
> 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
Junio C Hamano· Jul 4, 2008, 09:18 UTC · re: Johannes Sixt · lore

Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

Johannes Sixt <johannes.sixt@telecom.at> writes:
Show 12 quoted lines
> 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.
Steffen Prohaska· Jul 4, 2008, 09:29 UTC · re: Junio C Hamano · lore

Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

On Jul 4, 2008, at 11:18 AM, Junio C Hamano wrote:
Show 16 quoted lines
> 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
Clifford Caoile· Jul 4, 2008, 16:09 UTC · re: Steffen Prohaska · lore

Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

Hi:
On Fri, Jul 4, 2008 at 6:29 PM, Steffen Prohaska <prohaska@zib.de> wrote:
Show 20 quoted lines
>
> 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

Edward Z. Yang· Jul 4, 2008, 20:11 UTC · re: Clifford Caoile · lore

Re: [msysGit] Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)

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.

Junio C Hamano· Jul 2, 2008, 09:11 UTC · re: Steffen Prohaska · lore

Re: [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser

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

Show 6 quoted lines
>  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?

Show 34 quoted lines
> @@ -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?

Johannes Sixt· Jul 2, 2008, 18:57 UTC · re: Steffen Prohaska · lore

Re: [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser

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.
Show 22 quoted lines
> +#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
Steffen Prohaska· Jul 4, 2008, 09:06 UTC · re: Johannes Sixt · lore

Re: [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser

On Jul 2, 2008, at 8:57 PM, Johannes Sixt wrote:
Show 35 quoted lines
> 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
	
Steffen Prohaska· Jul 4, 2008, 09:09 UTC · re: Steffen Prohaska · lore

[PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path()

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
Steffen Prohaska· Jul 4, 2008, 09:09 UTC · re: Steffen Prohaska · lore

[PATCH 2/2] help (Windows): Display HTML in default browser using Win32 API

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
Junio C Hamano· Jul 4, 2008, 09:26 UTC · re: Steffen Prohaska · lore

Re: [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path()

Steffen Prohaska <prohaska@zib.de> writes:
Show 7 quoted lines
> 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.
Show 5 quoted lines
> +	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);
Johannes Schindelin· Jul 4, 2008, 12:35 UTC · re: Junio C Hamano · lore

Re: [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path()

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

Steffen Prohaska· Jul 11, 2008, 07:27 UTC · re: Johannes Schindelin · lore

Re: [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path()

On Jul 4, 2008, at 2:35 PM, Johannes Schindelin wrote:
Show 9 quoted lines
> 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
Steffen Prohaska· Jul 11, 2008, 07:28 UTC · re: Steffen Prohaska · lore

[PATCH 1/3] Move code interpreting path relative to exec-dir to new function system_path()

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
Steffen Prohaska· Jul 11, 2008, 07:28 UTC · re: Steffen Prohaska · lore

[PATCH 2/3] help.c: Add support for htmldir relative to git_exec_path()

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
Steffen Prohaska· Jul 11, 2008, 07:28 UTC · re: Steffen Prohaska · lore

[PATCH 3/3] help (Windows): Display HTML in default browser using Windows' shell API

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
Steffen Prohaska· Jul 11, 2008, 07:35 UTC · re: Steffen Prohaska · lore

Re: [PATCH 3/3] help (Windows): Display HTML in default browser using Windows' shell API

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
Steffen Prohaska· Jul 11, 2008, 07:37 UTC · re: Steffen Prohaska · lore

[PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API

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
Junio C Hamano· Jul 12, 2008, 03:26 UTC · re: Steffen Prohaska · lore

Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API

Steffen Prohaska <prohaska@zib.de> writes:
Show 12 quoted lines
> 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?
Steffen Prohaska· Jul 12, 2008, 06:45 UTC · re: Junio C Hamano · lore

Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API

On Jul 12, 2008, at 5:26 AM, Junio C Hamano wrote:
Show 18 quoted lines
> 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
Junio C Hamano· Jul 12, 2008, 07:07 UTC · re: Steffen Prohaska · lore

Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API

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.

Johannes Sixt· Jul 12, 2008, 20:41 UTC · re: Junio C Hamano · lore

Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API

Zitat von Junio C Hamano <gitster@pobox.com>:
Show 9 quoted lines
> 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
Junio C Hamano· Jul 13, 2008, 08:58 UTC · re: Johannes Sixt · lore

Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API

Johannes Sixt <johannes.sixt@telecom.at> writes:
Show 16 quoted lines
> 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.

Johannes Sixt· Jul 13, 2008, 20:31 UTC · re: Junio C Hamano · lore

[PATCH] Move code interpreting path relative to exec-dir to new function system_path()

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
Johannes Sixt· Jul 13, 2008, 20:31 UTC · re: Johannes Sixt · lore

[PATCH] help.c: Add support for htmldir relative to git_exec_path()

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
Johannes Sixt· Jul 13, 2008, 20:31 UTC · re: Johannes Sixt · lore

[PATCH] help (Windows): Display HTML in default browser using Windows' shell API

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
Johannes Sixt· Jul 13, 2008, 20:31 UTC · re: Johannes Sixt · lore

[PATCH] Fix relative built-in paths to be relative to the command invocation

$(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
Johannes Sixt· Jul 13, 2008, 20:31 UTC · re: Johannes Sixt · lore

[PATCH] Allow the built-in exec path to be relative to the command invocation path

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
Johannes Sixt· Jul 13, 2008, 20:31 UTC · re: Johannes Sixt · lore

[PATCH] Allow add_path() to add non-existent directories to the path

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
Johannes Sixt· Jul 14, 2008, 07:13 UTC · re: Johannes Sixt · lore

Re: [PATCH] Allow add_path() to add non-existent directories to the path

Johannes Sixt schrieb:
Show 14 quoted lines
> +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
Johannes Schindelin· Jul 13, 2008, 20:45 UTC · re: Johannes Sixt · lore

Re: [PATCH] Allow the built-in exec path to be relative to the command invocation path

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

Johannes Schindelin· Jul 13, 2008, 20:43 UTC · re: Johannes Sixt · lore

Re: [PATCH] Fix relative built-in paths to be relative to the command invocation

Hi,
On Sun, 13 Jul 2008, Johannes Sixt wrote:
Show 10 quoted lines
> 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?
Show 40 quoted lines
> 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

Johannes Sixt· Jul 14, 2008, 06:55 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Fix relative built-in paths to be relative to the command invocation

Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>:
Show 16 quoted lines
> 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.

Show 45 quoted lines
> > 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
Johannes Schindelin· Jul 14, 2008, 12:20 UTC · re: Johannes Sixt · lore

Re: [PATCH] Fix relative built-in paths to be relative to the command invocation

Hi,
On Mon, 14 Jul 2008, Johannes Sixt wrote:
Show 21 quoted lines
> 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

Johannes Sixt· Jul 14, 2008, 18:54 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Fix relative built-in paths to be relative to the command invocation

On Montag, 14. Juli 2008, Johannes Schindelin wrote:
Show 25 quoted lines
> 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
Junio C Hamano· Jul 14, 2008, 19:03 UTC · re: Johannes Sixt · lore

Re: [PATCH] Fix relative built-in paths to be relative to the command invocation

Johannes Sixt <johannes.sixt@telecom.at> writes:
Show 37 quoted lines
> 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.

Johannes Sixt· Jul 14, 2008, 08:47 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Fix relative built-in paths to be relative to the command invocation

Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>:
Show 16 quoted lines
> 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
Johannes Sixt· Jul 14, 2008, 21:41 UTC · re: Johannes Sixt · lore

[PATCH 0/5] replacement for the part of js/more-win that is in pu

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
Johannes Sixt· Jul 14, 2008, 21:41 UTC · re: Johannes Sixt · lore

[PATCH 1/5] Makefile: Normalize $(bindir) and $(gitexecdir) before comparing

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
Johannes Sixt· Jul 14, 2008, 21:41 UTC · re: Johannes Sixt · lore

[PATCH 2/5] Record the command invocation path early

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
Johannes Sixt· Jul 14, 2008, 21:41 UTC · re: Johannes Sixt · lore

[PATCH 3/5] Fix relative built-in paths to be relative to the command invocation

$(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
Johannes Sixt· Jul 14, 2008, 21:41 UTC · re: Johannes Sixt · lore

[PATCH 4/5] Allow the built-in exec path to be relative to the command invocation path

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
Johannes Sixt· Jul 14, 2008, 21:41 UTC · re: Johannes Sixt · lore

[PATCH 5/5] Allow add_path() to add non-existent directories to the path

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
Johannes Sixt· Jul 15, 2008, 07:59 UTC · re: Johannes Sixt · lore

Re: [PATCH 0/5] replacement for the part of js/more-win that is in pu

Johannes Sixt schrieb:
Show 11 quoted lines
> 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
Johannes Sixt· Jul 11, 2008, 09:02 UTC · re: Steffen Prohaska · lore

Re: [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path()

Zitat von Steffen Prohaska <prohaska@zib.de>:
Show 27 quoted lines
>
> 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
Junio C Hamano· Jul 2, 2008, 09:22 UTC · re: Steffen Prohaska · lore

Re: [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds.

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__?
Show 9 quoted lines
> @@ -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	
Marius Storm-Olsen· Jul 2, 2008, 10:03 UTC · re: Junio C Hamano · lore

Re: [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds.

Junio C Hamano said the following on 02.07.2008 11:22:
Show 7 quoted lines
> 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'
Steffen Prohaska· Jul 2, 2008, 14:29 UTC · re: Marius Storm-Olsen · lore

Re: [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds.

On Jul 2, 2008, at 12:03 PM, Marius Storm-Olsen wrote:
Show 8 quoted lines
> 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
Johannes Sixt· Jul 2, 2008, 18:46 UTC · re: Steffen Prohaska · lore

Re: [msysGit] [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures

On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote:
Show 40 quoted lines
> 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
Johannes Schindelin· Jul 3, 2008, 11:08 UTC · re: Johannes Sixt · lore

Re: [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures

Hi,
On Wed, 2 Jul 2008, Johannes Sixt wrote:
Show 44 quoted lines
> 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

Steffen Prohaska· Jul 11, 2008, 16:55 UTC · re: Johannes Sixt · lore

[PATCH] Convert CR/LF to LF in tag signatures

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
Junio C Hamano· Jul 2, 2008, 08:58 UTC · re: Steffen Prohaska · lore

Re: [PATCH 02/12] Do not complain about "no common commits" in an empty repo

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.

Steffen Prohaska· Jul 2, 2008, 14:04 UTC · re: Junio C Hamano · lore

Re: [PATCH 02/12] Do not complain about "no common commits" in an empty repo

On Jul 2, 2008, at 10:58 AM, Junio C Hamano wrote:
Show 8 quoted lines
> 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.

Show 32 quoted lines
> * 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
Johannes Sixt· Jul 2, 2008, 18:43 UTC · re: Steffen Prohaska · lore

Re: [PATCH 01/12] Fake reencoding success under NO_ICONV instead of returning NULL.

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.
Show 16 quoted lines
> 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
Kristian Høgsberg· Jun 30, 2008, 14:09 UTC · re: Junio C Hamano · lore

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

On Mon, 2008-06-30 at 02:08 -0700, Junio C Hamano wrote:
Show 30 quoted lines
> 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

Jakub Narebski· Jun 30, 2008, 15:58 UTC · re: Kristian Høgsberg · lore

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

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
Junio C Hamano· Jun 30, 2008, 22:15 UTC · re: Jakub Narebski · lore

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

Jakub Narebski <jnareb@gmail.com> writes:
Show 12 quoted lines
> 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.

Junio C Hamano· Jun 30, 2008, 22:15 UTC · re: Kristian Høgsberg · lore

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

Kristian Høgsberg <krh@redhat.com> writes:
Show 10 quoted lines
> 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.

Andrew Morton· Jun 30, 2008, 22:51 UTC · re: Junio C Hamano · lore

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

On Mon, 30 Jun 2008 15:15:52 -0700 Junio C Hamano <gitster@pobox.com> wrote:

Show 11 quoted lines
> 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.
Johannes Schindelin· Jun 30, 2008, 23:09 UTC · re: Andrew Morton · lore

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

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

Petr Baudis· Jun 30, 2008, 22:53 UTC · re: Junio C Hamano · lore

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

On Mon, Jun 30, 2008 at 03:15:52PM -0700, Junio C Hamano wrote:
Show 7 quoted lines
> 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. ;-)

Show 11 quoted lines
> 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
Stephen Rothwell· Jul 1, 2008, 00:57 UTC · re: Junio C Hamano · lore

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

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/
Kristian Høgsberg· Jul 1, 2008, 15:44 UTC · re: Junio C Hamano · lore

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

On Mon, 2008-06-30 at 15:15 -0700, Junio C Hamano wrote:
Show 20 quoted lines
> 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.

Show 22 quoted lines
> 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

Jeff King· Jul 1, 2008, 10:11 UTC · re: Junio C Hamano · lore

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

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
Thomas Rast· Jul 1, 2008, 11:44 UTC · re: Jeff King · lore

[PATCH] git-add--interactive: manual hunk editing mode

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
Junio C Hamano· Jul 1, 2008, 23:54 UTC · re: Thomas Rast · lore

Re: [PATCH] git-add--interactive: manual hunk editing mode

Thomas Rast <trast@student.ethz.ch> writes:
Show 7 quoted lines
> 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.
Junio C Hamano· Jul 2, 2008, 05:39 UTC · re: Thomas Rast · lore

Re: [PATCH] git-add--interactive: manual hunk editing mode

Thomas Rast <trast@student.ethz.ch> writes:
Show 9 quoted lines
> 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?
Show 14 quoted lines
> +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?

Show 7 quoted lines
> +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...

Show 10 quoted lines
> @@ -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".

Thomas Rast· Jul 2, 2008, 07:00 UTC · re: Junio C Hamano · lore

Re: [PATCH] git-add--interactive: manual hunk editing mode

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

Show 5 quoted lines
> > +# 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
Junio C Hamano· Jul 2, 2008, 08:38 UTC · re: Thomas Rast · lore

Re: [PATCH] git-add--interactive: manual hunk editing mode

Thomas Rast <trast@student.ethz.ch> writes:
Show 9 quoted lines
> 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.

Jeff King· Jul 2, 2008, 08:02 UTC · re: Junio C Hamano · lore

Re: [PATCH] git-add--interactive: manual hunk editing mode

On Tue, Jul 01, 2008 at 10:39:58PM -0700, Junio C Hamano wrote:
Show 12 quoted lines
> > +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
Junio C Hamano· Jul 2, 2008, 08:08 UTC · re: Jeff King · lore

Re: [PATCH] git-add--interactive: manual hunk editing mode

Jeff King <peff@peff.net> writes:
Show 6 quoted lines
> 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?

Jeff King· Jul 2, 2008, 08:32 UTC · re: Junio C Hamano · lore

Re: [PATCH] git-add--interactive: manual hunk editing mode

On Wed, Jul 02, 2008 at 01:08:09AM -0700, Junio C Hamano wrote:
Show 5 quoted lines
> > 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
Johannes Schindelin· Jul 2, 2008, 13:13 UTC · re: Jeff King · lore

Re: [PATCH] git-add--interactive: manual hunk editing mode

Hi,
On Wed, 2 Jul 2008, Jeff King wrote:
Show 18 quoted lines
> 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

Junio C Hamano· Jul 2, 2008, 18:27 UTC · re: Johannes Schindelin · lore

Re: [PATCH] git-add--interactive: manual hunk editing mode

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?
Thomas Rast· Jul 2, 2008, 21:58 UTC · re: Junio C Hamano · lore

[PATCH 0/3] git-add--interactive: use --recount, editing

Junio C Hamano wrote:
Show 6 quoted lines
> 
> 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:
Show 7 quoted lines
> 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(-)
Thomas Rast· Jul 2, 2008, 21:59 UTC · re: Thomas Rast · lore

[PATCH 1/3] git-add--interactive: replace hunk recounting with apply --recount

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
Thomas Rast· Jul 2, 2008, 21:59 UTC · re: Thomas Rast · lore

[PATCH 2/3] git-add--interactive: remove hunk coalescing

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
Thomas Rast· Jul 2, 2008, 22:00 UTC · re: Thomas Rast · lore

[PATCH 3/3] git-add--interactive: manual hunk editing mode

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
Junio C Hamano· Jul 2, 2008, 22:26 UTC · re: Thomas Rast · lore

Re: [PATCH 2/3] git-add--interactive: remove hunk coalescing

Thomas Rast <trast@student.ethz.ch> writes:
Show 42 quoted lines
> 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.

Junio C Hamano· Jul 2, 2008, 22:35 UTC · re: Junio C Hamano · lore

Re: [PATCH 2/3] git-add--interactive: remove hunk coalescing

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.

Thomas Rast· Jul 3, 2008, 19:24 UTC · re: Junio C Hamano · lore

Re: [PATCH 2/3] git-add--interactive: remove hunk coalescing

Junio C Hamano wrote:
Show 7 quoted lines
> 
> > 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
Junio C Hamano· Jul 3, 2008, 21:46 UTC · re: Thomas Rast · lore

Re: [PATCH 2/3] git-add--interactive: remove hunk coalescing

Thomas Rast <trast@student.ethz.ch> writes:
Show 12 quoted lines
> 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...

Junio C Hamano· Jul 2, 2008, 04:41 UTC · re: Junio C Hamano · lore

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
Junio C Hamano· Jul 6, 2008, 10:04 UTC · re: Junio C Hamano · lore

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".
Johannes Schindelin· Jul 6, 2008, 11:10 UTC · re: Junio C Hamano · lore

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

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

Junio C Hamano· Jul 7, 2008, 01:36 UTC · re: Johannes Schindelin · lore

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 8 quoted lines
> 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)
 
Junio C Hamano· Jul 8, 2008, 02:46 UTC · re: Junio C Hamano · lore

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.

Junio C Hamano· Jul 10, 2008, 02:32 UTC · re: Junio C Hamano · lore

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.

Junio C Hamano· Jul 14, 2008, 05:11 UTC · re: Junio C Hamano · lore

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.

Junio C Hamano· Jul 14, 2008, 06:45 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:
Show 6 quoted lines
> * 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
 }
 
Junio C Hamano· Jul 14, 2008, 07:50 UTC · re: Junio C Hamano · lore

Closing the merge window for 1.6.0

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

Johannes Sixt· Jul 14, 2008, 08:07 UTC · re: Junio C Hamano · lore

Re: Closing the merge window for 1.6.0

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
Jakub Narebski· Jul 14, 2008, 08:50 UTC · re: Junio C Hamano · lore

Re: Closing the merge window for 1.6.0

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
Petr Baudis· Jul 14, 2008, 08:55 UTC · re: Junio C Hamano · lore

Re: Closing the merge window for 1.6.0

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
Johannes Schindelin· Jul 14, 2008, 11:57 UTC · re: Petr Baudis · lore

Re: Closing the merge window for 1.6.0

Hi,
On Mon, 14 Jul 2008, Petr Baudis wrote:
Show 5 quoted lines
> 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

Gerrit Pape· Jul 14, 2008, 12:41 UTC · re: Johannes Schindelin · lore

Re: Closing the merge window for 1.6.0

On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
Show 8 quoted lines
> 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.
Johannes Schindelin· Jul 14, 2008, 12:56 UTC · re: Gerrit Pape · lore

Re: Closing the merge window for 1.6.0

Hi,
On Mon, 14 Jul 2008, Gerrit Pape wrote:
Show 12 quoted lines
> 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 ;-)
Show 5 quoted lines
> 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

Nicolas Pitre· Jul 14, 2008, 17:54 UTC · re: Gerrit Pape · lore

Re: Closing the merge window for 1.6.0

On Mon, 14 Jul 2008, Gerrit Pape wrote:
Show 16 quoted lines
> 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
Junio C Hamano· Jul 14, 2008, 19:00 UTC · re: Nicolas Pitre · lore

Re: Closing the merge window for 1.6.0

Nicolas Pitre <nico@cam.org> writes:
Show 23 quoted lines
> 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.

Teemu Likonen· Jul 14, 2008, 19:19 UTC · re: Junio C Hamano · lore

Re: Closing the merge window for 1.6.0

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.
Show 8 quoted lines
> 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.

Martin Langhoff· Jul 15, 2008, 03:14 UTC · re: Teemu Likonen · lore

Re: Closing the merge window for 1.6.0

On Tue, Jul 15, 2008 at 7:19 AM, Teemu Likonen <tlikonen@iki.fi> wrote:
Show 7 quoted lines
>> 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
Petr Baudis· Jul 15, 2008, 09:20 UTC · re: Junio C Hamano · lore

Re: Closing the merge window for 1.6.0

On Mon, Jul 14, 2008 at 12:00:54PM -0700, Junio C Hamano wrote:
Show 8 quoted lines
> 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
Dmitry Potapov· Jul 15, 2008, 15:06 UTC · re: Petr Baudis · lore

Re: Closing the merge window for 1.6.0

On Tue, Jul 15, 2008 at 11:20:23AM +0200, Petr Baudis wrote:
Show 6 quoted lines
> 
> 	(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.

Show 11 quoted lines
> 
> 	(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
Johannes Schindelin· Jul 15, 2008, 15:27 UTC · re: Dmitry Potapov · lore

Re: Closing the merge window for 1.6.0

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

Avery Pennarun· Jul 15, 2008, 15:51 UTC · re: Johannes Schindelin · lore

Re: Closing the merge window for 1.6.0

On 7/15/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 11 quoted lines
>  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! :)

Nicolas Pitre· Jul 15, 2008, 16:26 UTC · re: Johannes Schindelin · lore

Re: Closing the merge window for 1.6.0

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
Sverre Rabbelier· Jul 15, 2008, 16:46 UTC · re: Nicolas Pitre · lore

Re: Closing the merge window for 1.6.0

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
Petr Baudis· Jul 15, 2008, 17:28 UTC · re: Nicolas Pitre · lore

Re: Closing the merge window for 1.6.0

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
Dmitry Potapov· Jul 15, 2008, 17:04 UTC · re: Johannes Schindelin · lore

Re: Closing the merge window for 1.6.0

On Tue, Jul 15, 2008 at 04:27:02PM +0100, Johannes Schindelin wrote:
Show 5 quoted lines
> 
> >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
Junio C Hamano· Jul 15, 2008, 18:51 UTC · re: Johannes Schindelin · lore

Re: Closing the merge window for 1.6.0

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 18 quoted lines
> 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.

Johannes Schindelin· Jul 15, 2008, 22:10 UTC · re: Junio C Hamano · lore

Re: Closing the merge window for 1.6.0

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

Junio C Hamano· Jul 15, 2008, 22:33 UTC · re: Johannes Schindelin · lore

Re: Closing the merge window for 1.6.0

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 13 quoted lines
> 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"?

Johannes Schindelin· Jul 15, 2008, 22:45 UTC · re: Junio C Hamano · lore

Re: Closing the merge window for 1.6.0

Hi,
On Tue, 15 Jul 2008, Junio C Hamano wrote:
Show 8 quoted lines
> 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

Shawn O. Pearce· Jul 15, 2008, 02:51 UTC · re: Nicolas Pitre · lore

Re: Closing the merge window for 1.6.0

Nicolas Pitre <nico@cam.org> wrote:
Show 12 quoted lines
> 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.
Nicolas Pitre· Jul 15, 2008, 03:30 UTC · re: Shawn O. Pearce · lore

Re: Closing the merge window for 1.6.0

On Tue, 15 Jul 2008, Shawn O. Pearce wrote:
Show 18 quoted lines
> 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
Petr Baudis· Jul 14, 2008, 12:43 UTC · re: Johannes Schindelin · lore

Re: Closing the merge window for 1.6.0

  Hi,
On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
Show 11 quoted lines
> 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
Nick Andrew· Jul 20, 2008, 02:23 UTC · re: Petr Baudis · lore

Re: Closing the merge window for 1.6.0

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.
Junio C Hamano· Jul 14, 2008, 19:16 UTC · re: Petr Baudis · lore

Re: Closing the merge window for 1.6.0

Petr Baudis <pasky@suse.cz> writes:
Show 5 quoted lines
> 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
Petr Baudis· Jul 15, 2008, 09:09 UTC · re: Junio C Hamano · lore

Re: Closing the merge window for 1.6.0

On Mon, Jul 14, 2008 at 12:16:26PM -0700, Junio C Hamano wrote:
Show 10 quoted lines
> 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
Johannes Schindelin· Jul 14, 2008, 11:53 UTC · re: Junio C Hamano · lore

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

Hi,
On Sun, 13 Jul 2008, Junio C Hamano wrote:
Show 14 quoted lines
> * 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

Lea Wiemann· Jul 14, 2008, 23:12 UTC · re: Junio C Hamano · lore

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

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

Lea Wiemann· Jul 14, 2008, 23:20 UTC · re: Lea Wiemann · lore

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

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?

Junio C Hamano· Jul 15, 2008, 00:03 UTC · re: Lea Wiemann · lore

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

Lea Wiemann <lewiemann@gmail.com> writes:
Show 7 quoted lines
> 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]
Geoffrey Irving· Jul 15, 2008, 03:38 UTC · re: Junio C Hamano · lore

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

On Sun, Jul 13, 2008 at 10:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 10 quoted lines
> 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

Johannes Schindelin· Jul 15, 2008, 09:22 UTC · re: Geoffrey Irving · lore

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

Hi,
On Mon, 14 Jul 2008, Geoffrey Irving wrote:
Show 19 quoted lines
> 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

Geoffrey Irving· Jul 15, 2008, 16:48 UTC · re: Johannes Schindelin · lore

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

On Tue, Jul 15, 2008 at 2:22 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 29 quoted lines
> 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.
Show 7 quoted lines
> 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
Junio C Hamano· Jul 16, 2008, 03:33 UTC · re: Junio C Hamano · lore

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.

Junio C Hamano· Jul 17, 2008, 08:08 UTC · re: Junio C Hamano · lore

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.

Stephan Beyer· Jul 17, 2008, 13:09 UTC · re: Junio C Hamano · lore

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

Hi,
Junio C Hamano wrote:
Show 9 quoted lines
> * 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
Nanako Shiraishi· Jul 18, 2008, 08:50 UTC · re: Junio C Hamano · lore

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

Quoting Junio C Hamano <gitster@pobox.com>:
Show 9 quoted lines
> * 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/
Junio C Hamano· Jul 18, 2008, 09:08 UTC · re: Nanako Shiraishi · lore

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

Nanako Shiraishi <nanako3@lavabit.com> writes:
Show 15 quoted lines
> 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.

Nanako Shiraishi· Jul 18, 2008, 09:20 UTC · re: Junio C Hamano · lore

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

Quoting Junio C Hamano <gitster@pobox.com>:
Show 9 quoted lines
> 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?
Show 5 quoted lines
> 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/
Junio C Hamano· Jul 18, 2008, 09:43 UTC · re: Nanako Shiraishi · lore

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

Nanako Shiraishi <nanako3@lavabit.com> writes:
Show 13 quoted lines
> 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
Johannes Schindelin· Jul 18, 2008, 11:55 UTC · re: Junio C Hamano · lore

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

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

Junio C Hamano· Jul 19, 2008, 05:32 UTC · re: Johannes Schindelin · lore

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 8 quoted lines
> 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.
Show 6 quoted lines
> ... 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.

Johannes Schindelin· Jul 19, 2008, 11:19 UTC · re: Junio C Hamano · lore

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

Hi,
On Fri, 18 Jul 2008, Junio C Hamano wrote:
Show 17 quoted lines
> 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

Junio C Hamano· Jul 19, 2008, 16:55 UTC · re: Johannes Schindelin · lore

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

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.
Johannes Schindelin· Jul 19, 2008, 23:16 UTC · re: Junio C Hamano · lore

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

Hi,
On Sat, 19 Jul 2008, Junio C Hamano wrote:
Show 8 quoted lines
> 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

Miklos Vajna· Jul 20, 2008, 13:04 UTC · re: Johannes Schindelin · lore

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

On Sat, Jul 19, 2008 at 01:19:46PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 5 quoted lines
> 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? ;-)

Johannes Schindelin· Jul 20, 2008, 13:16 UTC · re: Miklos Vajna · lore

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

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.

Show 9 quoted lines
> 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

Junio C Hamano· Jul 20, 2008, 18:27 UTC · re: Miklos Vajna · lore

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

Miklos Vajna <vmiklos@frugalware.org> writes:
Show 5 quoted lines
> 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 ...
Johannes Schindelin· Jul 20, 2008, 19:07 UTC · re: Junio C Hamano · lore

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

Hi,
On Sun, 20 Jul 2008, Junio C Hamano wrote:
Show 17 quoted lines
> 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

Junio C Hamano· Jul 20, 2008, 19:58 UTC · re: Johannes Schindelin · lore

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 15 quoted lines
>> 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?

Sverre Rabbelier· Jul 20, 2008, 20:03 UTC · re: Junio C Hamano · lore

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

On Sun, Jul 20, 2008 at 9:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 10 quoted lines
> 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
Miklos Vajna· Jul 20, 2008, 20:33 UTC · re: Sverre Rabbelier · lore

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

On Sun, Jul 20, 2008 at 10:03:24PM +0200, Sverre Rabbelier <alturin@gmail.com> wrote:
Show 15 quoted lines
> 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
Sverre Rabbelier· Jul 20, 2008, 22:58 UTC · re: Miklos Vajna · lore

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

On Sun, Jul 20, 2008 at 10:33 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
Show 12 quoted lines
> 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
Jakub Narebski· Jul 21, 2008, 08:47 UTC · re: Sverre Rabbelier · lore

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

"Sverre Rabbelier" <alturin@gmail.com> writes:
Show 20 quoted lines
> 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
Junio C Hamano· Jul 20, 2008, 20:33 UTC · re: Sverre Rabbelier · lore

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

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

Johannes Schindelin· Jul 20, 2008, 22:24 UTC · re: Junio C Hamano · lore

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

Hi,
On Sun, 20 Jul 2008, Junio C Hamano wrote:
Show 29 quoted lines
> 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"

Petr Baudis· Jul 18, 2008, 09:44 UTC · re: Nanako Shiraishi · lore

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

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
Junio C Hamano· Jul 18, 2008, 09:58 UTC · re: Petr Baudis · lore

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

Petr Baudis <pasky@suse.cz> writes:
Show 17 quoted lines
> 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.

Nanako Shiraishi· Jul 19, 2008, 05:13 UTC · re: Junio C Hamano · lore

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

Quoting Junio C Hamano <gitster@pobox.com>:
Show 27 quoted lines
> 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/
Yaroslav Halchenko· Dec 13, 2010, 19:09 UTC · re: Junio C Hamano · lore

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

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!
Junio C Hamano· Dec 13, 2010, 20:46 UTC · re: Yaroslav Halchenko · lore

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

Yaroslav Halchenko <debian@onerussian.com> writes:
Show 5 quoted lines
> 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 ;-)

Yaroslav Halchenko· Dec 13, 2010, 21:46 UTC · re: Junio C Hamano · lore

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

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        
Junio C Hamano· Dec 13, 2010, 22:15 UTC · re: Yaroslav Halchenko · lore

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

Yaroslav Halchenko <debian@onerussian.com> writes:
Show 9 quoted lines
> 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?

Yaroslav Halchenko· Dec 13, 2010, 22:36 UTC · re: Junio C Hamano · lore

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

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.

Show 6 quoted lines
> 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        
Johannes Sixt· Dec 14, 2010, 07:23 UTC · re: Yaroslav Halchenko · lore

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

Am 12/13/2010 22:46, schrieb Yaroslav Halchenko:
Show 7 quoted lines
> 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
Yaroslav Halchenko· Dec 14, 2010, 14:21 UTC · re: Johannes Sixt · lore

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

On Tue, 14 Dec 2010, Johannes Sixt wrote:
Show 7 quoted lines
> > 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
Johannes Schindelin· Jul 18, 2008, 11:56 UTC · re: Nanako Shiraishi · lore

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

Hi,
On Fri, 18 Jul 2008, Nanako Shiraishi wrote:
Show 16 quoted lines
> 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

Nanako Shiraishi· Jul 20, 2008, 10:20 UTC · re: Johannes Schindelin · lore

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

Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
Show 14 quoted lines
> 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/
Junio C Hamano· Jul 20, 2008, 01:58 UTC · re: Junio C Hamano · lore

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.

Petr Baudis· Jul 20, 2008, 22:40 UTC · re: Junio C Hamano · lore

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

On Sat, Jul 19, 2008 at 06:58:55PM -0700, Junio C Hamano wrote:
Show 14 quoted lines
> * 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
Junio C Hamano· Jul 20, 2008, 23:04 UTC · re: Petr Baudis · lore

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

Petr Baudis <pasky@suse.cz> writes:
Show 5 quoted lines
> 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.

Brandon Casey· Jun 30, 2008, 14:59 UTC · re: Junio C Hamano · lore

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

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

← back to recent threads