* What's cooking in git.git (topics) @ 2008-03-09 10:46 Junio C Hamano 2008-03-12 7:50 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-03-09 10:46 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-03-09 10:46 What's cooking in git.git (topics) Junio C Hamano @ 2008-03-12 7:50 ` Junio C Hamano 2008-03-12 12:18 ` Johannes Schindelin 2008-03-14 9:00 ` Junio C Hamano 0 siblings, 2 replies; 371+ messages in thread From: Junio C Hamano @ 2008-03-12 7:50 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-03-12 7:50 ` Junio C Hamano @ 2008-03-12 12:18 ` Johannes Schindelin 2008-03-14 9:00 ` Junio C Hamano 1 sibling, 0 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-03-12 12:18 UTC (permalink / raw) To: Junio C Hamano; +Cc: git Hi, On Wed, 12 Mar 2008, Junio C Hamano wrote: > * nd/worktree (Sun Mar 2 17:35:43 2008 +0700) 10 commits > - Additional tests to capture worktree special cases > - Documentation: update api-builtin and api-setup > - Make setup_git_directory() auto-setup worktree if found > - builtin-archive: mark unused prefix "unused_prefix" > - Completely move out worktree setup from > setup_git_directory_gently() > - http-push: Avoid calling setup_git_directory() twice > - Make setup_work_tree() return new prefix > - Make get_git_dir() and 'git rev-parse --git-dir' absolute path > - Make sure setup_git_directory is called before accessing > repository > - "git read-tree -m" and the like require worktree > > Every time we touch work-tree stuff we seem to unstabilize; this round > seems more solid but I am still treading cautiously. Not sure if we > want this for 1.5.5. I am sure we do not want this for 1.5.5. It is too complicated a patch series to be obviously correct, and as I said earlier, a few design goals are not to my liking, such as trying to separate git_dir from work_tree logic with a sledgehammer. Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-03-12 7:50 ` Junio C Hamano 2008-03-12 12:18 ` Johannes Schindelin @ 2008-03-14 9:00 ` Junio C Hamano 2008-03-23 10:08 ` Junio C Hamano 1 sibling, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-03-14 9:00 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-03-14 9:00 ` Junio C Hamano @ 2008-03-23 10:08 ` Junio C Hamano 2008-03-23 12:00 ` Samuel Tardieu ` (3 more replies) 0 siblings, 4 replies; 371+ messages in thread From: Junio C Hamano @ 2008-03-23 10:08 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-03-23 10:08 ` Junio C Hamano @ 2008-03-23 12:00 ` Samuel Tardieu 2008-03-23 17:15 ` Junio C Hamano 2008-03-23 12:39 ` Steffen Prohaska ` (2 subsequent siblings) 3 siblings, 1 reply; 371+ messages in thread From: Samuel Tardieu @ 2008-03-23 12:00 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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/ ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-03-23 12:00 ` Samuel Tardieu @ 2008-03-23 17:15 ` Junio C Hamano 2008-03-23 22:34 ` Samuel Tardieu 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-03-23 17:15 UTC (permalink / raw) To: Samuel Tardieu; +Cc: git 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)? ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-03-23 17:15 ` Junio C Hamano @ 2008-03-23 22:34 ` Samuel Tardieu 0 siblings, 0 replies; 371+ messages in thread From: Samuel Tardieu @ 2008-03-23 22:34 UTC (permalink / raw) To: Junio C Hamano; +Cc: git >>>>> "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/ ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-03-23 10:08 ` Junio C Hamano 2008-03-23 12:00 ` Samuel Tardieu @ 2008-03-23 12:39 ` Steffen Prohaska 2008-03-23 17:37 ` Junio C Hamano 2008-03-23 21:06 ` Govind Salinas 2008-03-28 1:45 ` Junio C Hamano 3 siblings, 1 reply; 371+ messages in thread From: Steffen Prohaska @ 2008-03-23 12:39 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Sun, 23 Mar 2008, Junio C Hamano wrote: > * lt/case-insensitive (Sat Mar 22 14:22:44 2008 -0700) 9 commits > - Make git-add behave more sensibly in a case-insensitive > environment > - When adding files to the index, add support for case-independent > matches > - Make unpack-tree update removed files before any updated files > - Make branch merging aware of underlying case-insensitive > filsystems > - Add 'core.ignorecase' option > - Make hash_name_lookup able to do case-independent lookups > - Make "index_name_exists()" return the cache_entry it found > - Move name hashing functions into a file of its own > - Make unpack_trees_options bit flags actual bitfields > > The beginning of ASCII-only case insensitive filesystem support. It is > not complete yet, though. E.g. if you enable core.ignorecase in t0050, > the merge test fails. The merge test passes for me (on hfs+). The "git mv" test still fails; Linus made clear that "git mv" is not yet fixed. Steffen ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-03-23 12:39 ` Steffen Prohaska @ 2008-03-23 17:37 ` Junio C Hamano 0 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-03-23 17:37 UTC (permalink / raw) To: Steffen Prohaska; +Cc: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-03-23 10:08 ` Junio C Hamano 2008-03-23 12:00 ` Samuel Tardieu 2008-03-23 12:39 ` Steffen Prohaska @ 2008-03-23 21:06 ` Govind Salinas 2008-03-24 3:01 ` Junio C Hamano 2008-03-28 1:45 ` Junio C Hamano 3 siblings, 1 reply; 371+ messages in thread From: Govind Salinas @ 2008-03-23 21:06 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Sun, Mar 23, 2008 at 5:08 AM, Junio C Hamano <gitster@pobox.com> wrote: > > * gs/pretty-hexval (Fri Mar 21 10:05:06 2008 -0500) 1 commit > + pretty.c: add %x00 format specifier. > > Adds a generic "insert any byte value" to --pretty=format:<> specifier. > I also sent out the following patch that could be put in instead of or in addition to this one. The both solve my problem in different ways. Thanks, Govind. --- From: Govind Salinas <blix@sophiasuchtig.com> Date: Sun, 23 Mar 2008 16:02:11 -0500 Subject: [PATCH] log-tree.c: Make log_tree_diff_flush() honor line_termination. Signed-off-by: Govind Salinas <blix@sophiasuchtig.com> --- log-tree.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/log-tree.c b/log-tree.c index 608f697..5f55683 100644 --- a/log-tree.c +++ b/log-tree.c @@ -338,7 +338,7 @@ int log_tree_diff_flush(struct rev_info *opt) int pch = DIFF_FORMAT_DIFFSTAT | DIFF_FORMAT_PATCH; if ((pch & opt->diffopt.output_format) == pch) printf("---"); - putchar('\n'); + putchar(opt->diffopt.line_termination); } } diff_flush(&opt->diffopt); -- 1.5.4.4.550.g77e21.dirty ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-03-23 21:06 ` Govind Salinas @ 2008-03-24 3:01 ` Junio C Hamano 0 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-03-24 3:01 UTC (permalink / raw) To: Govind Salinas; +Cc: git "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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-03-23 10:08 ` Junio C Hamano ` (2 preceding siblings ...) 2008-03-23 21:06 ` Govind Salinas @ 2008-03-28 1:45 ` Junio C Hamano 2008-03-31 8:40 ` Junio C Hamano 3 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-03-28 1:45 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-03-28 1:45 ` Junio C Hamano @ 2008-03-31 8:40 ` Junio C Hamano 2008-04-04 18:24 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-03-31 8:40 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-03-31 8:40 ` Junio C Hamano @ 2008-04-04 18:24 ` Junio C Hamano 2008-04-04 20:21 ` Kristian Høgsberg 2008-04-09 9:43 ` Junio C Hamano 0 siblings, 2 replies; 371+ messages in thread From: Junio C Hamano @ 2008-04-04 18:24 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-04 18:24 ` Junio C Hamano @ 2008-04-04 20:21 ` Kristian Høgsberg 2008-04-04 20:52 ` Junio C Hamano 2008-04-09 9:43 ` Junio C Hamano 1 sibling, 1 reply; 371+ messages in thread From: Kristian Høgsberg @ 2008-04-04 20:21 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Fri, 2008-04-04 at 11:24 -0700, Junio C Hamano wrote: > Here are the topics that have been cooking. Commits prefixed > with '-' are only in 'pu' while commits prefixed with '+' are > in 'next'. > > The topics list the commits in reverse chronological order. > > With a handful topics graduated to "master", we hopefully will have > the > final 1.5.5 soon. What happened to builtin-clone? I know I just threw it over the fence, but Daniel picked it up and got it a lot closer to working? Did it fall through the cracks or is it just 1.5.6 material? Kristian ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-04 20:21 ` Kristian Høgsberg @ 2008-04-04 20:52 ` Junio C Hamano 2008-04-05 0:26 ` Johannes Schindelin 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-04-04 20:52 UTC (permalink / raw) To: Kristian Høgsberg; +Cc: git Kristian Høgsberg <krh@redhat.com> writes: > On Fri, 2008-04-04 at 11:24 -0700, Junio C Hamano wrote: >> Here are the topics that have been cooking. Commits prefixed >> with '-' are only in 'pu' while commits prefixed with '+' are >> in 'next'. >> >> The topics list the commits in reverse chronological order. >> >> With a handful topics graduated to "master", we hopefully will have the >> final 1.5.5 soon. > > What happened to builtin-clone? Nothing. > ... I know I just threw it over the fence, > but Daniel picked it up and got it a lot closer to working? Did it fall > through the cracks or is it just 1.5.6 material? If I recall correctly, "a lot closer to working" happened way after 1.5.5 merge window closed, so it definitely is not 1.5.5 material. Judging from the fact that we recently had to deal with the fallouts of C rewrites that happened during the 1.5.4 timeframe, I would have to say that any C rewrite of a substantial and important program needs to be cooked at least for one (or preferably two cycles, especially we are trying to have shorter cycles) in 'next'. So at this point, I optimistically say that it has a good chance of being deeply in 'next' and all the active git people would hopefully be using it, by the time 1.5.6 (or perhaps that is named 1.6.0, depending on what else we will do) ships, but I cannot say much more than that. It very much depends on how hard the code has been scrutinized already at this point; I haven't personally looked at it in any serious depth yet. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-04 20:52 ` Junio C Hamano @ 2008-04-05 0:26 ` Johannes Schindelin 2008-04-05 5:51 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Johannes Schindelin @ 2008-04-05 0:26 UTC (permalink / raw) To: Junio C Hamano; +Cc: Kristian Høgsberg, git [-- Attachment #1: Type: TEXT/PLAIN, Size: 1314 bytes --] Hi, On Fri, 4 Apr 2008, Junio C Hamano wrote: > Kristian Høgsberg <krh@redhat.com> writes: > > > ... I know I just threw it over the fence, but Daniel picked it up and > > got it a lot closer to working? Did it fall through the cracks or is > > it just 1.5.6 material? > > If I recall correctly, "a lot closer to working" happened way after > 1.5.5 merge window closed, so it definitely is not 1.5.5 material. > > Judging from the fact that we recently had to deal with the fallouts of > C rewrites that happened during the 1.5.4 timeframe, I would have to say > that any C rewrite of a substantial and important program needs to be > cooked at least for one (or preferably two cycles, especially we are > trying to have shorter cycles) in 'next'. That would mean that you'd have to merge it into 'next'. And rather sooner than later, since everything else would lead to a dragging out of the timeline. As it happens, until you called out the 'please test master' phase, I was running with builtin clone, and did not find it lacking. Although I have to admit that I have some cleanups, and I haven't merged with Daniel in a long time. And I do not do anything particularly fancy, such as shallow clone or shared clone. Ciao, Dscho "who hopes that the please-test-master phase is over soon" ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-05 0:26 ` Johannes Schindelin @ 2008-04-05 5:51 ` Junio C Hamano 0 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-04-05 5:51 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Kristian Høgsberg, git Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > On Fri, 4 Apr 2008, Junio C Hamano wrote: > >> Judging from the fact that we recently had to deal with the fallouts of >> C rewrites that happened during the 1.5.4 timeframe, I would have to say >> that any C rewrite of a substantial and important program needs to be >> cooked at least for one (or preferably two cycles, especially we are >> trying to have shorter cycles) in 'next'. > > That would mean that you'd have to merge it into 'next'. And rather > sooner than later, since everything else would lead to a dragging out of > the timeline. Yes, which means somebody needs to present a mergeable history rather sooner than later, and that somebody does not have to be me ;-) ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-04-04 18:24 ` Junio C Hamano 2008-04-04 20:21 ` Kristian Høgsberg @ 2008-04-09 9:43 ` Junio C Hamano 2008-04-14 7:00 ` Junio C Hamano 1 sibling, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-04-09 9:43 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-04-09 9:43 ` Junio C Hamano @ 2008-04-14 7:00 ` Junio C Hamano 2008-04-15 19:23 ` Jeff King 2008-04-19 8:19 ` Junio C Hamano 0 siblings, 2 replies; 371+ messages in thread From: Junio C Hamano @ 2008-04-14 7:00 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-14 7:00 ` Junio C Hamano @ 2008-04-15 19:23 ` Jeff King 2008-04-19 8:19 ` Junio C Hamano 1 sibling, 0 replies; 371+ messages in thread From: Jeff King @ 2008-04-15 19:23 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-04-14 7:00 ` Junio C Hamano 2008-04-15 19:23 ` Jeff King @ 2008-04-19 8:19 ` Junio C Hamano 2008-04-19 14:23 ` Johannes Schindelin ` (3 more replies) 1 sibling, 4 replies; 371+ messages in thread From: Junio C Hamano @ 2008-04-19 8:19 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-19 8:19 ` Junio C Hamano @ 2008-04-19 14:23 ` Johannes Schindelin 2008-04-19 16:34 ` Lars Hjemli ` (2 subsequent siblings) 3 siblings, 0 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-04-19 14:23 UTC (permalink / raw) To: Junio C Hamano; +Cc: git Hi, On Sat, 19 Apr 2008, Junio C Hamano wrote: > ---------------------------------------------------------------- > [On Hold] > > * js/decorate (Mon Apr 7 14:41:12 2008 +0100) 2 commits > - pretty=format: Add %d to show decoration > - decorate: use "const struct object" > > This has stalled, after a petered-out discussion. I am not personally interested, but I thought that it was easy enough to do. So let's just scrap it, the mailing list has it should anybody need it in the future. Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-19 8:19 ` Junio C Hamano 2008-04-19 14:23 ` Johannes Schindelin @ 2008-04-19 16:34 ` Lars Hjemli 2008-04-20 4:08 ` Junio C Hamano 2008-04-21 16:10 ` Brandon Casey 2008-04-22 10:03 ` Junio C Hamano 3 siblings, 1 reply; 371+ messages in thread From: Lars Hjemli @ 2008-04-19 16:34 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-19 16:34 ` Lars Hjemli @ 2008-04-20 4:08 ` Junio C Hamano 0 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-04-20 4:08 UTC (permalink / raw) To: Lars Hjemli; +Cc: git "Lars Hjemli" <hjemli@gmail.com> writes: > On Sat, Apr 19, 2008 at 10:19 AM, Junio C Hamano <gitster@pobox.com> wrote: >> * lh/branch-merged (Fri Apr 18 18:30:15 2008 +0200) 3 commits >> - Add tests for `branch --[no-]merged` >> - git-branch.txt: compare --contains, --merged and --no-merged >> - git-branch: add support for --merged and --no-merged > > I notice that you moved the test script into t3201 while still adding > t3202, which probably wasn't your intent. > > Would you like me to resend the patches with your fixups to tests and > docs (and maybe even squash them into a single patch)? Thanks, but it's easy enough for me to amend the tip of lh/branch-merged to drop t3202 and that should be sufficient. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-19 8:19 ` Junio C Hamano 2008-04-19 14:23 ` Johannes Schindelin 2008-04-19 16:34 ` Lars Hjemli @ 2008-04-21 16:10 ` Brandon Casey 2008-04-22 10:03 ` Junio C Hamano 3 siblings, 0 replies; 371+ messages in thread From: Brandon Casey @ 2008-04-21 16:10 UTC (permalink / raw) To: Junio C Hamano; +Cc: git Junio C Hamano wrote: > * bc/filter-branch (Wed Mar 26 10:47:09 2008 -0500) 1 commit > - filter-branch.sh: support nearly proper tag name filtering > > Instead of discarding signed tags, this demotes them to simply annotated, > which is technically not that different from signed tags. I just want to point out that this patch is not exclusively about signed tags. The patch is about retaining annotated tags rather than demoting them to light-weight tag references as is done currently for _all_ annotated tags, signed and unsigned. When rewriting signed tags, the signature is stripped so that we don't write a tag with a bogus signature. -brandon ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-04-19 8:19 ` Junio C Hamano ` (2 preceding siblings ...) 2008-04-21 16:10 ` Brandon Casey @ 2008-04-22 10:03 ` Junio C Hamano 2008-04-22 13:59 ` Ping Yin ` (2 more replies) 3 siblings, 3 replies; 371+ messages in thread From: Junio C Hamano @ 2008-04-22 10:03 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-22 10:03 ` Junio C Hamano @ 2008-04-22 13:59 ` Ping Yin 2008-04-22 14:55 ` Josef Weidendorfer 2008-04-22 20:51 ` Michele Ballabio 2008-04-27 6:04 ` Junio C Hamano 2 siblings, 1 reply; 371+ messages in thread From: Ping Yin @ 2008-04-22 13:59 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Tue, Apr 22, 2008 at 6:03 PM, Junio C Hamano <gitster@pobox.com> wrote: > Here are the topics that have been cooking. Commits prefixed > with '-' are only in 'pu' while commits prefixed with '+' are > in 'next'. > > > * py/submodule-2 (Wed Apr 16 22:19:31 2008 +0800) 1 commit > - git-submodule: Extract functions module_info and module_url > > > I only managed to queue the first one so far. > > It does not help motivating me reviewing the series that the overall tone > of it is to ignore .git/config more and make .gitmodules take more active > role, either. I have already said number of times why that is not a good > idea and why it is against the overall submodule design. I summarize junio's points that says $GIT_DIR/config is authoritative. 1. .gitmodules shouldn't be authoritative and should be just a hint to fill $GIT_DIR/config because a) url may be rewritten with different protocol, such as from "http://" to "git://" b) url may be total different between .gitmodules and $GIT_DIR/config 2. When going back to an old HEAD of super project and do "git submodule update", the url recorded in .gitmodules may be stale or not existent anymore, so we should refer to $GIT_DIR/config for the right url. 3. We can record what contents we've seen in the .gitmodules, so that we can give users a chance to adjust what is in $GIT_DIR/config when we notice the entry in .gitmodules has changed. Any others? However, i argue the fall back strategy (say fall back to .gitmodules when we can't find an entries in $GIT_DIR/config) doesn't break the authority and isn't in contrast with the cases above. It just attachs more importance to .gitmodules and can make the world better in most cases. For 1.a, i think we can keep these entries in .gitmodules, and use "url.<thisurl>.insteadof = <otherurl>" to override the urls. For 1.b, i think this is a rare case. And we can override these urls in $GIT_DIR/config. However, in many cases, we havn't to do that. For 2, i think it is also a rare case. And before going back, we can override the urls in $GIT_DIR/config. For 3, i havn't found a good way to do that. And it doesn't conflict with the fall back strategy (say, wh So, my conclusion * 1.b, 2 and 3 are all rare cases, and these cases don't conflict with the fall back strategy * 1.a is a usual case, and fallback + 'url insteadOf" will make things better * The most common case is that most (even all) entries in .gitmodules are the same as entires in $GIT_DIR/config. So with fallback, we don't have to copy entries from .gitmodules to $GIT_DIR/config. * And, in a central environment, i think it's common that the super project and sub project use the same protocol. So if we use relative urls in .gitmodules, when changing the url protocol the super project, the urls in .gitmodules needn't change and can be dynamically expanded with the url of the super project (Of course, after applying the 2nd patch of this series) -- Ping Yin ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-22 13:59 ` Ping Yin @ 2008-04-22 14:55 ` Josef Weidendorfer 2008-04-22 17:13 ` Ping Yin 0 siblings, 1 reply; 371+ messages in thread From: Josef Weidendorfer @ 2008-04-22 14:55 UTC (permalink / raw) To: Ping Yin; +Cc: Junio C Hamano, git On Tuesday 22 April 2008, Ping Yin wrote: > On Tue, Apr 22, 2008 at 6:03 PM, Junio C Hamano <gitster@pobox.com> wrote: > > It does not help motivating me reviewing the series that the overall tone > > of it is to ignore .git/config more and make .gitmodules take more active > > role, either. I have already said number of times why that is not a good > > idea and why it is against the overall submodule design. > > I summarize junio's points that says $GIT_DIR/config is authoritative. > > [...] > > Any others? A reason you did not mention is security: You never want your .git/config to be changed behind your back, which effectivly is the case when using the versioned .gitmodules information (similar problem as with a .gitconfig in-tree). Another one: From a design point of view, submodule URLs are project meta information unrelated to source history. So, actually, I think it was wrong to put submodule URLs (even hints only) into the versioned .gitmodules files (*). The main reason for .gitmodules is to store submodule information which has to be in sync with commits, such as a submodule name related to some path where the submodule happens to be checked out in a given commit, and also related to some config entry holding the URL to allow for fetch/pull. The idea is that submodules have an identity in the supermodule (in contrast to files in git), such that related configuration keeps valid when moving submodules around. This needs simultanous adjusting the path attribute in .gitmodules when a submodule is moved. Josef (*) IMHO, it would be far better if such project meta/policy information could be in its own history (e.g. branch "gitconfig" to allow for easy propagation at clone/fetch time). However, any such configuration should need explicit interaction by the user to take over project config into the local git config (e.g. via a "git config merge gitconfig:config" after inspecting via "git show gitconfig:config"). ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-22 14:55 ` Josef Weidendorfer @ 2008-04-22 17:13 ` Ping Yin 2008-04-22 17:28 ` Johannes Schindelin 2008-04-22 18:07 ` Josef Weidendorfer 0 siblings, 2 replies; 371+ messages in thread From: Ping Yin @ 2008-04-22 17:13 UTC (permalink / raw) To: Josef Weidendorfer; +Cc: Junio C Hamano, git On Tue, Apr 22, 2008 at 10:55 PM, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote: > On Tuesday 22 April 2008, Ping Yin wrote: > > On Tue, Apr 22, 2008 at 6:03 PM, Junio C Hamano <gitster@pobox.com> wrote: > > > > It does not help motivating me reviewing the series that the overall tone > > > of it is to ignore .git/config more and make .gitmodules take more active > > > role, either. I have already said number of times why that is not a good > > > idea and why it is against the overall submodule design. > > > > I summarize junio's points that says $GIT_DIR/config is authoritative. > > > > [...] > > > > Any others? > > A reason you did not mention is security: > You never want your .git/config to be changed behind your back, which > effectivly is the case when using the versioned .gitmodules information > (similar problem as with a .gitconfig in-tree). As discussed in another thread about in-tree .gitconfig, security issues only arise on limited configuration entries. However, there are no entries in .gitmodules falling into any of these entries. > > Another one: > From a design point of view, submodule URLs are project meta information > unrelated to source history. So, actually, I think it was wrong to put > submodule URLs (even hints only) into the versioned .gitmodules files (*). But now it actually acts as hints and we don't find a better way. I just propose that the hints become the good default. > > The main reason for .gitmodules is to store submodule information which > has to be in sync with commits, such as a submodule name related to some > path where the submodule happens to be checked out in a given commit, and > also related to some config entry holding the URL to allow for fetch/pull. > The idea is that submodules have an identity in the supermodule (in contrast > to files in git), such that related configuration keeps valid when moving > submodules around. This needs simultanous adjusting the path attribute in > .gitmodules when a submodule is moved. If we go back to a old HEAD or switch to another branch with changed path for a submodule, what should 'git submodule update' do? I think entries in .gitmodules should take precedence. So url in $GIT_DIR/config is authoritative, and path in .gitmodules is authoritative. -- Ping Yin ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-22 17:13 ` Ping Yin @ 2008-04-22 17:28 ` Johannes Schindelin 2008-04-23 1:27 ` Ping Yin 2008-04-22 18:07 ` Josef Weidendorfer 1 sibling, 1 reply; 371+ messages in thread From: Johannes Schindelin @ 2008-04-22 17:28 UTC (permalink / raw) To: Ping Yin; +Cc: Josef Weidendorfer, Junio C Hamano, git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-22 17:28 ` Johannes Schindelin @ 2008-04-23 1:27 ` Ping Yin 2008-04-23 2:03 ` Ping Yin 0 siblings, 1 reply; 371+ messages in thread From: Ping Yin @ 2008-04-23 1:27 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Josef Weidendorfer, Junio C Hamano, git On Wed, Apr 23, 2008 at 1:28 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > Hi, > > > On Wed, 23 Apr 2008, Ping Yin wrote: > > > If we go back to a old HEAD or switch to another branch with changed > > path for a submodule, what should 'git submodule update' do? I think > > entries in .gitmodules should take precedence. > > Literally the most common reason for a _different_ .gitmodules in an older > revision is that the repository was moved to another machine. > > In this case, your suggestion is actively wrong. > Another common reason is the adjustment of repository directory in the central environment so i said *path*, not *url*. I agree what Josef said in the the following reply: "It makes no sense to have submodule path configuration in .git/config, as it has to be in sync with the current commit". So it should be bettter to store path info only in .gitmodules instead of $GIT_DIR/config -- Ping Yin ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-23 1:27 ` Ping Yin @ 2008-04-23 2:03 ` Ping Yin 0 siblings, 0 replies; 371+ messages in thread From: Ping Yin @ 2008-04-23 2:03 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Josef Weidendorfer, Junio C Hamano, git On Wed, Apr 23, 2008 at 9:27 AM, Ping Yin <pkufranky@gmail.com> wrote: > > On Wed, Apr 23, 2008 at 1:28 AM, Johannes Schindelin > <Johannes.Schindelin@gmx.de> wrote: > > Hi, > > > > > > On Wed, 23 Apr 2008, Ping Yin wrote: > > > > > If we go back to a old HEAD or switch to another branch with changed > > > path for a submodule, what should 'git submodule update' do? I think > > > entries in .gitmodules should take precedence. > > > > Literally the most common reason for a _different_ .gitmodules in an older > > revision is that the repository was moved to another machine. > > > > In this case, your suggestion is actively wrong. > > > Another common reason is the adjustment of repository directory in the > central environment I'm wrong, this is the case that *url* changes. > so i said *path*, not *url*. I agree what Josef said in the the > following reply: "It makes no sense to have submodule path > configuration in .git/config, as it has to be in sync with the current > commit". So it should be bettter to store path info only in > .gitmodules instead of $GIT_DIR/config > The case that *path* changes is the submodule is moved to a new path in some commit. But it is a very rare case. -- Ping Yin ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-22 17:13 ` Ping Yin 2008-04-22 17:28 ` Johannes Schindelin @ 2008-04-22 18:07 ` Josef Weidendorfer 2008-04-23 1:59 ` Ping Yin 1 sibling, 1 reply; 371+ messages in thread From: Josef Weidendorfer @ 2008-04-22 18:07 UTC (permalink / raw) To: Ping Yin; +Cc: Junio C Hamano, git On Tuesday 22 April 2008, Ping Yin wrote: > > A reason you did not mention is security: > > You never want your .git/config to be changed behind your back, which > > effectivly is the case when using the versioned .gitmodules information > > (similar problem as with a .gitconfig in-tree). > > As discussed in another thread about in-tree .gitconfig, security > issues only arise on limited configuration entries. However, there are > no entries in .gitmodules falling into any of these entries. Hmm... At least, it can be very annoying when git fetches data from repositories you did not expect, only because submodule URLs change via this fallback mechanism. Perhaps it is a little far reached, but suppose a project changes its URL, and the old one becomes occupied by a malicious person. The problem is that the URL with the now malicious repository is bound in the history of the project. For sure, you do not want to fetch from that old repository by accident, after you did a checkout of an old commit. And there would be no way to protect other people from this malicious repository other than rewriting the whole history. > > Another one: > > From a design point of view, submodule URLs are project meta information > > unrelated to source history. So, actually, I think it was wrong to put > > submodule URLs (even hints only) into the versioned .gitmodules files (*). > > But now it actually acts as hints and we don't find a better way. I > just propose that the hints become the good default. For me this sounds like: Now that we have made this bad decision, it does not matter to make it even worse. What was the motivation for this fallback mechanism? In any way, it is preferable to always use the correct URL for submodules. Thus, when the URL ever changes in the projects livetime (covered by git history), you want to have the correct URL in your .git/config (not to accidently use the wrong URL when checking out an old commit). But then, the fallback mechanism does not trigger anyway. > > The main reason for .gitmodules is to store submodule information which > > has to be in sync with commits, such as a submodule name related to some > > path where the submodule happens to be checked out in a given commit, and > > also related to some config entry holding the URL to allow for fetch/pull. > > The idea is that submodules have an identity in the supermodule (in contrast > > to files in git), such that related configuration keeps valid when moving > > submodules around. This needs simultanous adjusting the path attribute in > > .gitmodules when a submodule is moved. > > If we go back to a old HEAD or switch to another branch with changed > path for a submodule, what should 'git submodule update' do? > I think entries in .gitmodules should take precedence. Of course. It makes no sense to have submodule path configuration in .git/config, as it has to be in sync with the current commit. That has nothing to do with precedence. The same is true for .gitattributes, for example. > So url in $GIT_DIR/config is authoritative, and path in .gitmodules is > authoritative. No. These are totally different types of configurations. Josef ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-22 18:07 ` Josef Weidendorfer @ 2008-04-23 1:59 ` Ping Yin 2008-04-23 7:47 ` Fedor Sergeev 0 siblings, 1 reply; 371+ messages in thread From: Ping Yin @ 2008-04-23 1:59 UTC (permalink / raw) To: Josef Weidendorfer; +Cc: Junio C Hamano, git On Wed, Apr 23, 2008 at 2:07 AM, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote: > On Tuesday 22 April 2008, Ping Yin wrote: > > > > A reason you did not mention is security: > > > You never want your .git/config to be changed behind your back, which > > > effectivly is the case when using the versioned .gitmodules information > > > (similar problem as with a .gitconfig in-tree). > > > > As discussed in another thread about in-tree .gitconfig, security > > issues only arise on limited configuration entries. However, there are > > no entries in .gitmodules falling into any of these entries. > > Hmm... At least, it can be very annoying when git fetches data from repositories > you did not expect, only because submodule URLs change via this > fallback mechanism. Perhaps it is a little far reached, but suppose a project > changes its URL, and the old one becomes occupied by a malicious person. > The problem is that the URL with the now malicious repository is bound in the > history of the project. It is always bound now without the fallback patch :) > For sure, you do not want to fetch from that old repository > by accident, after you did a checkout of an old commit. And there would be no > way to protect other people from this malicious repository other than rewriting > the whole history. I wonder how the *malicious* repository can hurt us since only the commit recorded in commit of the super project will be checked out. > > > > > Another one: > > > From a design point of view, submodule URLs are project meta information > > > unrelated to source history. So, actually, I think it was wrong to put > > > submodule URLs (even hints only) into the versioned .gitmodules files (*). > > > > But now it actually acts as hints and we don't find a better way. I > > just propose that the hints become the good default. > > For me this sounds like: Now that we have made this bad decision, it does > not matter to make it even worse. I should be like: Now that we have made a bad decision (if it is), we have to improve it to make life better before we can find a better solution. > > What was the motivation for this fallback mechanism? > > In any way, it is preferable to always use the correct URL for submodules. > Thus, when the URL ever changes in the projects livetime (covered by > git history), you want to have the correct URL in your .git/config > (not to accidently use the wrong URL when checking out an old commit). > But then, the fallback mechanism does not trigger anyway. I havn't found yet how an incorrect URL can hurt us. The worst case i can imagine is the failure of "git submodule update". Two of the most common cases which can result in an incorrect/stale url is * the repository has been moved to another machine * the directory structure of upstream repositories has changed However, there are also cases that the old version of url in .gitmodules is correct. Think about the case that the reposotory maintainer has decided to replace current submodule with a totoally different one. In this case, when back to the old HEAD, the url in .gitmodules is correct while url in $GIT_DIR/config is incorrect. So, when error happens, we can't judge which url is correct. So just let the user make the decision by refering the change history of .gitmodules or asking the repository maintainer. -- Ping Yin ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-23 1:59 ` Ping Yin @ 2008-04-23 7:47 ` Fedor Sergeev 2008-04-23 8:32 ` Ping Yin 2008-04-23 8:47 ` Robin Rosenberg 0 siblings, 2 replies; 371+ messages in thread From: Fedor Sergeev @ 2008-04-23 7:47 UTC (permalink / raw) To: Ping Yin; +Cc: Josef Weidendorfer, Junio C Hamano, git On Wed, 23 Apr 2008, Ping Yin wrote: > On Wed, Apr 23, 2008 at 2:07 AM, Josef Weidendorfer >> Hmm... At least, it can be very annoying when git fetches data from repositories >> you did not expect, only because submodule URLs change via this >> fallback mechanism. Perhaps it is a little far reached, but suppose a project >> changes its URL, and the old one becomes occupied by a malicious person. >> The problem is that the URL with the now malicious repository is bound in the >> history of the project. > > It is always bound now without the fallback patch :) > >> For sure, you do not want to fetch from that old repository >> by accident, after you did a checkout of an old commit. And there would be no >> way to protect other people from this malicious repository other than rewriting >> the whole history. > > I wonder how the *malicious* repository can hurt us since only the > commit recorded in commit of the super project will be checked out. If one manages to hack on repository one can modify it enormous amount of ways, including spoofing on SHA (providing wrong contents for it - does git verify that when getting a pack?), utilizing bugs in git etc... I doubt somebody would spend that much of an effort but you know, you can not be paranoid *enough* :) regards, Fedor. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-23 7:47 ` Fedor Sergeev @ 2008-04-23 8:32 ` Ping Yin 2008-04-23 8:47 ` Robin Rosenberg 1 sibling, 0 replies; 371+ messages in thread From: Ping Yin @ 2008-04-23 8:32 UTC (permalink / raw) To: Fedor Sergeev; +Cc: Josef Weidendorfer, Junio C Hamano, git On Wed, Apr 23, 2008 at 3:47 PM, Fedor Sergeev <Fedor.Sergeev@sun.com> wrote: > On Wed, 23 Apr 2008, Ping Yin wrote: > > > > > On Wed, Apr 23, 2008 at 2:07 AM, Josef Weidendorfer > > > > > > > Hmm... At least, it can be very annoying when git fetches data from > repositories > > > you did not expect, only because submodule URLs change via this > > > fallback mechanism. Perhaps it is a little far reached, but suppose a > project > > > changes its URL, and the old one becomes occupied by a malicious > person. > > > The problem is that the URL with the now malicious repository is bound > in the > > > history of the project. > > > > > > > It is always bound now without the fallback patch :) > > > > > > > For sure, you do not want to fetch from that old repository > > > by accident, after you did a checkout of an old commit. And there would > be no > > > way to protect other people from this malicious repository other than > rewriting > > > the whole history. > > > > > > > I wonder how the *malicious* repository can hurt us since only the > > commit recorded in commit of the super project will be checked out. > > > > If one manages to hack on repository one can modify it enormous amount of > ways, including spoofing on SHA (providing wrong contents for it - does git > verify that when getting a pack?), utilizing bugs in git etc... Doable? I dunno. -- Ping Yin ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-23 7:47 ` Fedor Sergeev 2008-04-23 8:32 ` Ping Yin @ 2008-04-23 8:47 ` Robin Rosenberg 2008-04-23 9:16 ` Fedor Sergeev 1 sibling, 1 reply; 371+ messages in thread From: Robin Rosenberg @ 2008-04-23 8:47 UTC (permalink / raw) To: Fedor Sergeev; +Cc: Ping Yin, Josef Weidendorfer, Junio C Hamano, git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-23 8:47 ` Robin Rosenberg @ 2008-04-23 9:16 ` Fedor Sergeev 0 siblings, 0 replies; 371+ messages in thread From: Fedor Sergeev @ 2008-04-23 9:16 UTC (permalink / raw) To: Robin Rosenberg; +Cc: Ping Yin, Josef Weidendorfer, Junio C Hamano, git On Wed, 23 Apr 2008, Robin Rosenberg wrote: > onsdagen den 23 april 2008 09.47.57 skrev Fedor Sergeev: >> If one manages to hack on repository one can modify it enormous amount of >> ways, including spoofing on SHA (providing wrong contents for it - does >> git verify that when getting a pack?), utilizing bugs in git etc... > > The pack transfer protocol does not transfer the SHA of objects, only the > contents is transferred. The SHA-1 is (has to be since it is not sent) > reconstructed on the receiving end. Thats nice. Then I agree its difficult to spoil superproject out of submodule other than it just does not checkout. regards, Fedor. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-22 10:03 ` Junio C Hamano 2008-04-22 13:59 ` Ping Yin @ 2008-04-22 20:51 ` Michele Ballabio 2008-04-23 0:22 ` Junio C Hamano 2008-04-27 6:04 ` Junio C Hamano 2 siblings, 1 reply; 371+ messages in thread From: Michele Ballabio @ 2008-04-22 20:51 UTC (permalink / raw) To: git; +Cc: Junio C Hamano 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? ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-22 20:51 ` Michele Ballabio @ 2008-04-23 0:22 ` Junio C Hamano 2008-04-23 7:36 ` Michele Ballabio 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-04-23 0:22 UTC (permalink / raw) To: Michele Ballabio; +Cc: git Michele Ballabio <barra_cuda@katamail.com> writes: > On Tuesday 22 April 2008, Junio C Hamano wrote: >> * mv/defer-gc (Wed Apr 2 21:35:11 2008 +0200) 3 commits >> + contrib/hooks: add an example pre-auto-gc hook >> + Documentation/hooks: add pre-auto-gc hook >> + git-gc --auto: add pre-auto-gc hook >> >> A new hook to stop "git gc --auto" from running. > > About "git gc --auto", there was a patch sometime ago: > > [PATCH] commit: resurrect "gc --auto" at the end > > http://marc.info/?l=git&m=120716427130606&w=2 > > Was it dropped? In the thread, addition of an extra hook to "gc --auto" wasdiscussed. It was judged conditionally Ok as long as nobody assumes "gc --auto" is ultra-cheap. We used to have a "gc --auto" at the end of git-commit which violated that condition, but we do not have that anymore. The patch resurrects the behaviour that makes the extra hook possibly unacceptable again, dosn't it? ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-23 0:22 ` Junio C Hamano @ 2008-04-23 7:36 ` Michele Ballabio 0 siblings, 0 replies; 371+ messages in thread From: Michele Ballabio @ 2008-04-23 7:36 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Wednesday 23 April 2008, Junio C Hamano wrote: > In the thread, addition of an extra hook to "gc --auto" wasdiscussed. It > was judged conditionally Ok as long as nobody assumes "gc --auto" is > ultra-cheap. We used to have a "gc --auto" at the end of git-commit which > violated that condition, but we do not have that anymore. > > The patch resurrects the behaviour that makes the extra hook possibly > unacceptable again, dosn't it? Yes. I thought there was an unwanted change in behavior in git-commit. Sorry for the noise. ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-04-22 10:03 ` Junio C Hamano 2008-04-22 13:59 ` Ping Yin 2008-04-22 20:51 ` Michele Ballabio @ 2008-04-27 6:04 ` Junio C Hamano 2008-04-27 6:44 ` Ping Yin 2008-05-06 6:38 ` Junio C Hamano 2 siblings, 2 replies; 371+ messages in thread From: Junio C Hamano @ 2008-04-27 6:04 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-04-27 6:04 ` Junio C Hamano @ 2008-04-27 6:44 ` Ping Yin 2008-05-06 6:38 ` Junio C Hamano 1 sibling, 0 replies; 371+ messages in thread From: Ping Yin @ 2008-04-27 6:44 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Sun, Apr 27, 2008 at 2:04 PM, Junio C Hamano <gitster@pobox.com> wrote: > > * py/submodule-2 (Wed Apr 16 22:19:31 2008 +0800) 1 commit > - git-submodule: Extract functions module_info and module_url > > Not going well. > Hmm, i wonder how this series can go well. Or this series is totoally bad and should be discarded. Ping Yin ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-04-27 6:04 ` Junio C Hamano 2008-04-27 6:44 ` Ping Yin @ 2008-05-06 6:38 ` Junio C Hamano 2008-05-12 22:03 ` Junio C Hamano 2008-05-14 22:30 ` Junio C Hamano 1 sibling, 2 replies; 371+ messages in thread From: Junio C Hamano @ 2008-05-06 6:38 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-05-06 6:38 ` Junio C Hamano @ 2008-05-12 22:03 ` Junio C Hamano 2008-05-13 0:02 ` Junio C Hamano 2008-05-14 22:30 ` Junio C Hamano 1 sibling, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-05-12 22:03 UTC (permalink / raw) To: Adam Roben; +Cc: git, Eric Wong Junio C Hamano <gitster@pobox.com> writes: > [Dropped] > > * ap/svn (Tue Apr 15 21:04:18 2008 -0400) 3 commits > . git-svn: add documentation for --add-author-from option. > . git-svn: Add --add-author-from option. > . git-svn: add documentation for --use-log-author option. > > Eric requested a new set of tests for this series which never came. I am > still holding onto the tip of the topic in case we can resurrect it, but > it is not merged to 'pu'. I usually try hard not to do this kind of thing as it would encourage a misconception that I'll tie any and all loose ends (which I obviously do not have infinite amount of time and energy that is necessary), but I've decided to add a skeleton for necessary tests to get the ball rolling. Here is a sample output from the test sequence (the log message from the last one): commit 0bc699cbd72810f85a0200c7197022b50e8298ed Author: A U Thor <author@example.com> Date: Mon May 12 21:28:26 2008 +0000 fourth From: A U Thor <author@example.com> git-svn-id: file:///git.git/t/trash directory/svnrepo@4 23bf1e2a-19bf-478a-b023-e66a9e40421e I am not sure if adding the "From: " line as a trailer, with two blank line after it before the git-svn-id line, is the intended format for the final log message. Maybe it is meant to go before the commit log message with a blank line after it. Maybe it is meant to be a trailer, one blank line before and after it and then git-svn-id line (in whcih case we have one blank after it too many). I genuinely do not know what is intended. If this is the intended output, please say so. Otherwise please fix it as needed, and add tests for the final format specification as well, so that later changes will not break it. Thanks. -- >8 -- From: Junio C Hamano <gitster@pobox.com> Date: Mon, 12 May 2008 14:53:40 -0700 Subject: [PATCH] git-svn: add test for --add-author-from and --use-log-author Signed-off-by: Junio C Hamano <gitster@pobox.com> --- t/t9122-git-svn-author.sh | 73 +++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 73 insertions(+), 0 deletions(-) create mode 100755 t/t9122-git-svn-author.sh diff --git a/t/t9122-git-svn-author.sh b/t/t9122-git-svn-author.sh new file mode 100755 index 0000000..d9a784b --- /dev/null +++ b/t/t9122-git-svn-author.sh @@ -0,0 +1,73 @@ +#!/bin/sh + +test_description='git svn authorship' +. ./lib-git-svn.sh + +test_expect_success 'setup svn repository' ' + svn checkout "$svnrepo" work.svn && + ( + cd work.svn && + echo >file + svn add file + svn commit -m "first commit" file + ) + +' + +test_expect_success 'interact with it via git-svn' ' + + mkdir work.git && + ( + cd work.git && + git svn init "$svnrepo" + git svn fetch && + + echo modification >file && + test_tick && + git commit -a -m second && + + test_tick && + git svn dcommit && + + echo "further modification" >file && + test_tick && + git commit -a -m third && + + test_tick && + git svn --add-author-from dcommit && + + echo "yet further modification" >file && + test_tick && + git commit -a -m fourth && + + test_tick && + git svn --add-author-from --use-log-author dcommit && + + git log && + + git show -s HEAD^^ >../actual.2 && + git show -s HEAD^ >../actual.3 && + git show -s HEAD >../actual.4 + + ) && + + # Make sure that --add-author-from without --use-log-author + # did not affect the authorship information + myself=$(grep "^Author: " actual.2) && + unaffected=$(grep "^Author: " actual.3) && + test "z$myself" = "z$unaffected" && + + # Make sure lack of --add-author-from did not add cruft + ! grep "^ From: A U Thor " actual.2 && + + # Make sure --add-author-from added cruft + grep "^ From: A U Thor " actual.3 && + grep "^ From: A U Thor " actual.4 && + + # Make sure --add-author-from with --use-log-author affected + # the authorship information + grep "^Author: A U Thor " actual.4 + +' + +test_done -- 1.5.5.1.328.g8abfd ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-05-12 22:03 ` Junio C Hamano @ 2008-05-13 0:02 ` Junio C Hamano 0 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-05-13 0:02 UTC (permalink / raw) To: Adam Roben; +Cc: git, Eric Wong Adam, I am very sorry, but the message was misdirected. I'm resending it now to ask for comments from Avery. ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-05-06 6:38 ` Junio C Hamano 2008-05-12 22:03 ` Junio C Hamano @ 2008-05-14 22:30 ` Junio C Hamano 2008-05-14 22:55 ` Daniel Barkalow ` (2 more replies) 1 sibling, 3 replies; 371+ messages in thread From: Junio C Hamano @ 2008-05-14 22:30 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-05-14 22:30 ` Junio C Hamano @ 2008-05-14 22:55 ` Daniel Barkalow 2008-05-15 4:30 ` Junio C Hamano 2008-05-15 5:51 ` Steffen Prohaska 2008-05-22 1:18 ` Junio C Hamano 2 siblings, 1 reply; 371+ messages in thread From: Daniel Barkalow @ 2008-05-14 22:55 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Wed, 14 May 2008, Junio C Hamano wrote: > * db/clone-in-c (Sun Apr 27 13:39:30 2008 -0400) 8 commits > + Build in clone > + Provide API access to init_db() > + Add a function to set a non-default work tree > + Allow for having for_each_ref() list extra refs > + Have a constant extern refspec for "--tags" > + Add a library function to add an alternate to the alternates file > + Add a lockfile function to append to a file > + Mark the list of refs to fetch as const > > For 1.5.6; please give it a good beating. Last time, you said you were going to review this again; did you review it and find nothing to comment on, decide to just make sure it gets a beating, or are you still planning to review it more? (Just wondering so I can try to arrange to have time to respond to comments if there's going to be a bunch) ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-05-14 22:55 ` Daniel Barkalow @ 2008-05-15 4:30 ` Junio C Hamano 0 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-05-15 4:30 UTC (permalink / raw) To: Daniel Barkalow; +Cc: git Daniel Barkalow <barkalow@iabervon.org> writes: > Last time, you said you were going to review this again; did you review it > and find nothing to comment on, decide to just make sure it gets a > beating, or are you still planning to review it more? (Just wondering so I > can try to arrange to have time to respond to comments if there's going to > be a bunch) I did not have any further nitpicks on either design nor code in particular. But keep in mind that I won't be the single source of review comments ;-). . ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-05-14 22:30 ` Junio C Hamano 2008-05-14 22:55 ` Daniel Barkalow @ 2008-05-15 5:51 ` Steffen Prohaska 2008-05-22 1:18 ` Junio C Hamano 2 siblings, 0 replies; 371+ messages in thread From: Steffen Prohaska @ 2008-05-15 5:51 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Wed, 14 May 2008, Junio C Hamano wrote: > > For 1.5.6. > > * sp/ignorecase (Sun May 11 18:16:42 2008 +0200) 4 commits > - t0050: Add test for case insensitive add > - t0050: Set core.ignorecase case to activate case insensitivity > - t0050: Test autodetect core.ignorecase > - git-init: autodetect core.ignorecase > > This unfortunately seems to break on natively case sensitive filesystems. >From 92ec8c8a12cdc45a69f6612af340a8ce50976ab1 Mon Sep 17 00:00:00 2001 From: Steffen Prohaska <prohaska@zib.de> Date: Thu, 15 May 2008 07:19:54 +0200 Subject: [PATCH] t0050: Fix merge test on case sensitive file systems On a case sensitive filesystem, "git reset --hard" might refuse to overwrite a file whose name differs only by case, even if core.ignorecase is set. It is not clear which circumstances cause this behavior. This commit simply works around the problem by removing the case changing file before running "git reset --hard". Signed-off-by: Steffen Prohaska <prohaska@zib.de> --- t/t0050-filesystem.sh | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh index 0e33c4b..c5360e2 100755 --- a/t/t0050-filesystem.sh +++ b/t/t0050-filesystem.sh @@ -72,6 +72,8 @@ $test_case 'rename (case change)' ' $test_case 'merge (case change)' ' + rm -f CamelCase && + rm -f camelcase && git reset --hard initial && git merge topic -- 1.5.5.1.349.g99d0 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-05-14 22:30 ` Junio C Hamano 2008-05-14 22:55 ` Daniel Barkalow 2008-05-15 5:51 ` Steffen Prohaska @ 2008-05-22 1:18 ` Junio C Hamano 2008-05-22 11:35 ` Johannes Schindelin 2008-05-26 1:22 ` Junio C Hamano 2 siblings, 2 replies; 371+ messages in thread From: Junio C Hamano @ 2008-05-22 1:18 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-05-22 1:18 ` Junio C Hamano @ 2008-05-22 11:35 ` Johannes Schindelin 2008-05-22 18:17 ` Junio C Hamano 2008-05-25 21:29 ` Stephan Beyer 2008-05-26 1:22 ` Junio C Hamano 1 sibling, 2 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-05-22 11:35 UTC (permalink / raw) To: Junio C Hamano; +Cc: git Hi, On Wed, 21 May 2008, Junio C Hamano wrote: > * js/config-cb (Wed May 14 18:46:53 2008 +0100) 1 commit > - Provide git_config with a callback-data parameter > > This needs to wait until most of the other things graduate for 1.5.6; > luckily, unlike the other "path-list" changes, misconversions is much > easier to catch for this change and I am not worried about it. Just let me know when to resubmit, and against what branch(es). > * js/mailinfo (Fri May 16 14:03:30 2008 +0100) 1 commit > - <<PARK - BASE64 and QP still broken>> mailsplit and mailinfo: > gracefully handle NUL characters > > When "am" processes a patch that modifies a line with NUL, we used to > chomp the patch line there, resulting in rejects. This patch fixes the > issue partially, only when the message is not encoded in BASE64 nor > Quoted-Printable. Like I said, I would be happy if Tommy took care of that patch. > * js/ignore-submodule (Wed May 14 18:03:59 2008 +0100) 3 commits > + Ignore dirty submodule states during rebase and stash > + Teach update-index about --ignore-submodules > + diff options: Introduce --ignore-submodules I haven't heard back from you about renaming that option. I think I suggested --non-gitlinks or something equally discouraging for porcelain users. > * as/graph (Mon May 5 00:57:03 2008 -0700) 4 commits > + graph API: eliminate unnecessary indentation > + log and rev-list: add --graph option > + Add history graph API > + revision API: split parent rewriting and parent printing options > > Draw "tig 'g'" graph without tig ;-) I am a big fan of this feature. > * db/clone-in-c (Tue May 20 14:15:14 2008 -0400) 11 commits > + clone: fall back to copying if hardlinking fails > + builtin-clone.c: Need to closedir() in copy_or_link_directory() > + builtin-clone: fix initial checkout > + Build in clone > + Provide API access to init_db() > + Add a function to set a non-default work tree > + Allow for having for_each_ref() list extra refs > + Have a constant extern refspec for "--tags" > + Add a library function to add an alternate to the alternates file > + Add a lockfile function to append to a file > + Mark the list of refs to fetch as const Fingers crossed. > * js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits > + Use perl instead of tac > + Fix t3404 assumption that `wc -l` does not use whitespace. > + rebase -i: Use : in expr command instead of match. > + rebase -i: update the implementation of 'mark' command > + Add option --preserve-tags > + Teach rebase interactive the tag command > + Add option --first-parent > + Do rebase with preserve merges with advanced TODO list > + Select all lines with fake-editor > + Unify the length of $SHORT* and the commits in the TODO list > + Teach rebase interactive the merge command > + Move redo merge code in a function > + Teach rebase interactive the reset command > + Teach rebase interactive the mark command > + Move cleanup code into it's own function > + Don't append default merge message to -m message > + fake-editor: output TODO list if unchanged > > This may complement the proposed "sequencer" GSoC project. Dscho seems > to have quite a strong objection to the 'mark' syntax and mechanism > being unnecessarily complex. Let's wait and see if a less complex but > equally expressive alternative materializes... Yeah, I know. My backlog is growing and growing. Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-05-22 11:35 ` Johannes Schindelin @ 2008-05-22 18:17 ` Junio C Hamano 2008-05-22 22:02 ` Daniel Barkalow 2008-05-25 21:29 ` Stephan Beyer 1 sibling, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-05-22 18:17 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> * js/config-cb (Wed May 14 18:46:53 2008 +0100) 1 commit >> - Provide git_config with a callback-data parameter >> >> This needs to wait until most of the other things graduate for 1.5.6; >> luckily, unlike the other "path-list" changes, misconversions is much >> easier to catch for this change and I am not worried about it. > > Just let me know when to resubmit, and against what branch(es). It is probably easier for me to munge the original submission from you when I decide to tag -rc0, adjusting any potential new callers (I do not think of any offhand in diff between master and next). We will need a quiescent time for this kind of change, and that way we will get such a quiescent window by definition. >> * js/mailinfo (Fri May 16 14:03:30 2008 +0100) 1 commit >> - <<PARK - BASE64 and QP still broken>> mailsplit and mailinfo: >> gracefully handle NUL characters >> >> When "am" processes a patch that modifies a line with NUL, we used to >> chomp the patch line there, resulting in rejects. This patch fixes the >> issue partially, only when the message is not encoded in BASE64 nor >> Quoted-Printable. > Like I said, I would be happy if Tommy took care of that patch. I dunno. Is it likely to happen? I'd take a look at it myself when I have a chance. >> * js/ignore-submodule (Wed May 14 18:03:59 2008 +0100) 3 commits >> + Ignore dirty submodule states during rebase and stash >> + Teach update-index about --ignore-submodules >> + diff options: Introduce --ignore-submodules > > I haven't heard back from you about renaming that option. I think I > suggested --non-gitlinks or something equally discouraging for > porcelain users. The name is fine. I had more trouble with what it does, rather, what it doesn't --- it does not ignore typechange that involve a gitlink if I recall correctly. >> * db/clone-in-c (Tue May 20 14:15:14 2008 -0400) 11 commits >> + clone: fall back to copying if hardlinking fails >> + builtin-clone.c: Need to closedir() in copy_or_link_directory() >> + builtin-clone: fix initial checkout >> + Build in clone >> + Provide API access to init_db() >> + Add a function to set a non-default work tree >> + Allow for having for_each_ref() list extra refs >> + Have a constant extern refspec for "--tags" >> + Add a library function to add an alternate to the alternates file >> + Add a lockfile function to append to a file >> + Mark the list of refs to fetch as const > > Fingers crossed. Rather, uncross them and type a few more tests ;-)? ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-05-22 18:17 ` Junio C Hamano @ 2008-05-22 22:02 ` Daniel Barkalow 0 siblings, 0 replies; 371+ messages in thread From: Daniel Barkalow @ 2008-05-22 22:02 UTC (permalink / raw) To: Junio C Hamano; +Cc: Johannes Schindelin, git On Thu, 22 May 2008, Junio C Hamano wrote: > >> * db/clone-in-c (Tue May 20 14:15:14 2008 -0400) 11 commits > >> + clone: fall back to copying if hardlinking fails > >> + builtin-clone.c: Need to closedir() in copy_or_link_directory() > >> + builtin-clone: fix initial checkout > >> + Build in clone > >> + Provide API access to init_db() > >> + Add a function to set a non-default work tree > >> + Allow for having for_each_ref() list extra refs > >> + Have a constant extern refspec for "--tags" > >> + Add a library function to add an alternate to the alternates file > >> + Add a lockfile function to append to a file > >> + Mark the list of refs to fetch as const > > > > Fingers crossed. > > Rather, uncross them and type a few more tests ;-)? There are a few tests from Johan that didn't get in, which I'd had in my tree but didn't send because I don't have a good process in place for sending patches I'm not the author of. I'm pretty sure they pass, but I haven't checked recently. I'll send them in a moment. -Daniel *This .sig left intentionally blank* ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-05-22 11:35 ` Johannes Schindelin 2008-05-22 18:17 ` Junio C Hamano @ 2008-05-25 21:29 ` Stephan Beyer 1 sibling, 0 replies; 371+ messages in thread From: Stephan Beyer @ 2008-05-25 21:29 UTC (permalink / raw) To: git [-- Attachment #1: Type: text/plain, Size: 515 bytes --] Hi, > > * js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits esp. > > + Teach rebase interactive the merge command > > + Teach rebase interactive the reset command > > + Teach rebase interactive the mark command [...] > > Yeah, I know. My backlog is growing and growing. I think, this week we get the git-sequencer "spec" ready to be sent to the list. Then there's a new thread to discuss ;-) Regards, Stephan -- Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-05-22 1:18 ` Junio C Hamano 2008-05-22 11:35 ` Johannes Schindelin @ 2008-05-26 1:22 ` Junio C Hamano 2008-05-27 5:36 ` [PATCH] git-diff: allow --no-index semantics a bit more Junio C Hamano 2008-05-30 20:44 ` What's cooking in git.git (topics) Junio C Hamano 1 sibling, 2 replies; 371+ messages in thread From: Junio C Hamano @ 2008-05-26 1:22 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* [PATCH] git-diff: allow --no-index semantics a bit more 2008-05-26 1:22 ` Junio C Hamano @ 2008-05-27 5:36 ` Junio C Hamano 2008-05-30 20:44 ` What's cooking in git.git (topics) Junio C Hamano 1 sibling, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-05-27 5:36 UTC (permalink / raw) To: git; +Cc: Johannes Schindelin 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 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-05-26 1:22 ` Junio C Hamano 2008-05-27 5:36 ` [PATCH] git-diff: allow --no-index semantics a bit more Junio C Hamano @ 2008-05-30 20:44 ` Junio C Hamano 2008-05-30 21:10 ` Jon Loeliger ` (2 more replies) 1 sibling, 3 replies; 371+ messages in thread From: Junio C Hamano @ 2008-05-30 20:44 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-05-30 20:44 ` What's cooking in git.git (topics) Junio C Hamano @ 2008-05-30 21:10 ` Jon Loeliger 2008-05-31 1:25 ` Stephan Beyer 2008-05-30 22:00 ` Steven Grimm 2008-06-02 7:58 ` Junio C Hamano 2 siblings, 1 reply; 371+ messages in thread From: Jon Loeliger @ 2008-05-30 21:10 UTC (permalink / raw) To: Junio C Hamano; +Cc: git Junio C Hamano wrote: > Here are the topics that have been cooking. Commits prefixed > with '-' are only in 'pu' while commits prefixed with '+' are > in 'next'. > > > * js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits > + Use perl instead of tac > + Fix t3404 assumption that `wc -l` does not use whitespace. > + rebase -i: Use : in expr command instead of match. > + rebase -i: update the implementation of 'mark' command > + Add option --preserve-tags > + Teach rebase interactive the tag command > + Add option --first-parent > + Do rebase with preserve merges with advanced TODO list > + Select all lines with fake-editor > + Unify the length of $SHORT* and the commits in the TODO list > + Teach rebase interactive the merge command > + Move redo merge code in a function > + Teach rebase interactive the reset command > + Teach rebase interactive the mark command > + Move cleanup code into it's own function > + Don't append default merge message to -m message > + fake-editor: output TODO list if unchanged > > This may complement the proposed "sequencer" GSoC project. Dscho seems to > have quite a strong objection to the 'mark' syntax and mechanism being > unnecessarily complex. Let's wait and see if a less complex but equally > expressive alternative materializes... Well, there are the two not-quite facetious suggestions I made off list to Junio. Granted, he though they would be overkill (too), but I guess I could make them here for the general record in any case. One suggestion was to make a procedural model out of the commit graph and allow something like this: b :- pick(B) x :- merge(pick(A), b) y :- merge(pick(C), b) z :- merge(x, y) My second and semi-equivallent suggestion was to allow a lisp-like notation: (merge (merge (pick A) (pick B) (merge (pick B) (pick C) As Junio observed, even that could be beyond what most casual git rebase -i users are willing to do to a sequencer edit stream before getting down to business. Ah well. :-) jdl ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-05-30 21:10 ` Jon Loeliger @ 2008-05-31 1:25 ` Stephan Beyer 0 siblings, 0 replies; 371+ messages in thread From: Stephan Beyer @ 2008-05-31 1:25 UTC (permalink / raw) To: git; +Cc: Jon Loeliger Hi, > One suggestion was to make a procedural model out of > the commit graph and allow something like this: > > b :- pick(B) > x :- merge(pick(A), b) > y :- merge(pick(C), b) > z :- merge(x, y) Nice idea. But imho too hard for casual users. Someone who has to learn a new language won't use the tool. > My second and semi-equivallent suggestion was to > allow a lisp-like notation: > > (merge (merge (pick A) > (pick B) > (merge (pick B) > (pick C) You forgot some right parenthesis here ;-) ...which shows, that it is also not easy enough for users. Or is it intentional? :) Stephan -- Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-05-30 20:44 ` What's cooking in git.git (topics) Junio C Hamano 2008-05-30 21:10 ` Jon Loeliger @ 2008-05-30 22:00 ` Steven Grimm 2008-06-02 7:58 ` Junio C Hamano 2 siblings, 0 replies; 371+ messages in thread From: Steven Grimm @ 2008-05-30 22:00 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On May 30, 2008, at 1:44 PM, Junio C Hamano wrote: > [Stalled] > > * dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits > - Eliminate an unnecessary chdir("..") > - Add support for GIT_CEILING_DIRECTORIES > - Fold test-absolute-path into test-path-utils > - Implement normalize_absolute_path The most recent version of this patch seemed to come and go without any commentary one way or the other. What are people's objections to it as it stands now? -Steve ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-05-30 20:44 ` What's cooking in git.git (topics) Junio C Hamano 2008-05-30 21:10 ` Jon Loeliger 2008-05-30 22:00 ` Steven Grimm @ 2008-06-02 7:58 ` Junio C Hamano 2008-06-02 8:10 ` Jakub Narebski ` (3 more replies) 2 siblings, 4 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-02 7:58 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-02 7:58 ` Junio C Hamano @ 2008-06-02 8:10 ` Jakub Narebski 2008-06-02 11:56 ` Sebastian Bober ` (2 subsequent siblings) 3 siblings, 0 replies; 371+ messages in thread From: Jakub Narebski @ 2008-06-02 8:10 UTC (permalink / raw) To: Junio C Hamano; +Cc: git Junio C Hamano <gitster@pobox.com> writes: > I've looked at the Git.pm testsuite that uses Test::More briefly but > hadn't really reviewed it. Is Test::More commonly used, considered solid > and widely available? It is part of perl-5.8.6-24 RPM package in Fedora Core 4. It is mentioned in http://www.perlfoundation.org/perl5/index.cgi?testing > ---------------------------------------------------------------- > [Graduated to "master"] > > * lr/init-bare (Wed May 28 19:53:57 2008 +0100) 1 commit > + git-init: accept --bare option > > This makes both "git --bare init" and "git init --bare" work, which would > reduce confusion. Nice. -- Jakub Narebski Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-02 7:58 ` Junio C Hamano 2008-06-02 8:10 ` Jakub Narebski @ 2008-06-02 11:56 ` Sebastian Bober 2008-06-02 15:17 ` Johannes Schindelin 2008-06-13 10:16 ` Junio C Hamano 3 siblings, 0 replies; 371+ messages in thread From: Sebastian Bober @ 2008-06-02 11:56 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-02 7:58 ` Junio C Hamano 2008-06-02 8:10 ` Jakub Narebski 2008-06-02 11:56 ` Sebastian Bober @ 2008-06-02 15:17 ` Johannes Schindelin 2008-06-02 15:43 ` Shawn O. Pearce 2008-06-13 10:16 ` Junio C Hamano 3 siblings, 1 reply; 371+ messages in thread From: Johannes Schindelin @ 2008-06-02 15:17 UTC (permalink / raw) To: Junio C Hamano; +Cc: git Hi, On Mon, 2 Jun 2008, Junio C Hamano wrote: > * sp/remote (Sun Jun 1 00:28:04 2008 -0400) 3 commits > + Make "git-remote rm" delete refs acccording to fetch specs > + Make "git-remote prune" delete refs according to fetch specs > + Remove unused remote_prefix member in builtin-remote > > "git-remote" had an unwarranted assumption that everybody uses > refs/remotes/$it namespace to track remote repository called $it. This > series is a reasonable fix to it. AFAIR this limitation was already in the scripted version, and I tried to wrap my head around lifting it. However, I did not end up with the brillian analysis of Shawn, and was almost sending a reply contradicting his logic. However, I agree with Shawn that it is the same issue as contradicting fetches, so if it leads to problems, it is a pilot error. _However_, I still try to come up with some attic for deleted refs. It is not just a matter of moving the logs to a different namespace because of D/F conflicts. Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-02 15:17 ` Johannes Schindelin @ 2008-06-02 15:43 ` Shawn O. Pearce 2008-06-02 16:14 ` Johannes Schindelin 0 siblings, 1 reply; 371+ messages in thread From: Shawn O. Pearce @ 2008-06-02 15:43 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-02 15:43 ` Shawn O. Pearce @ 2008-06-02 16:14 ` Johannes Schindelin 2008-06-02 18:13 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Johannes Schindelin @ 2008-06-02 16:14 UTC (permalink / raw) To: Shawn O. Pearce; +Cc: Junio C Hamano, git Hi, On Mon, 2 Jun 2008, Shawn O. Pearce wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > _However_, I still try to come up with some attic for deleted refs. > > It is not just a matter of moving the logs to a different namespace > > because of D/F conflicts. > > Record the delete at the end of the reflog so we have a date/time record > and the last SHA-1 value, just in case it doesn't match up with the most > recent reflog entry (e.g. user ran some legacy tool that just redirect > git-commit-tree output to the branch itself). That's obvious. > Take the SHA-1 hash of the reflog now that the final entry is written. > Rename the file to .git/attic/$sha1 and call it a day. I thought about > compressing the file too, but its not worth saving the disk space here > and it would make tools that inspect the attic expensive to run. > > The attic can be easily cleaned out by looking at the timestamp of the > last record of each file. Attic log files older than X days can be > removed. This is better than reading the modification time of the file > as we don't have to worry about some copy tool not saving the > modification time if the user moves/copies the repository. I actually would prefer to have the logs in the .git/logs/ directory, so that I can easily reuse all existing reflog handling. After sending the mail, I actually got an idea: .git/logs/attic/<timestamp>/<refname> I think this should work without problems. In that case, git-gc also handles the garbage collection. > The hard stuff is: > > - Should the commits listed in attic reflogs be considered reachable > when we pack, prune or fsck? Commits in a reflog are, even if they > aren't reachable from a transport perspective. Yes, they should. That is the whole purpose of keeping the reflogs: I want to be able to resurrect the branch, if I deleted it by accident. > - What command gets the extra options to see what branches are in the > attic and when they got there? I'd like to have them listed with the other reflogs. > - What command gets the extra option to recover a branch from the attic? None. It is the user's responsibility to use the information wisely. git branch resurrected attic/<bla>/refs/heads/accidentally-deleted@{1} > - When we recover a branch from the attic is it sufficient to recover it > to the name it had at time of deletion? Should we allow you to > recover it to a different name? See above. I think resurrecting under the same name would not necessarily be the most frequent operation on deleted refs. > - Is it sufficient to make you recover the branch from the attic before > you can access the rest of its reflog with porcelain? > > - What do we do if we recover a branch with stale reflog entries > and the attic is deemed to not be reachable (see above). I'll just go with my idea, implement it, and post it here for discussion. Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-02 16:14 ` Johannes Schindelin @ 2008-06-02 18:13 ` Junio C Hamano 2008-06-02 19:17 ` Johannes Schindelin 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-06-02 18:13 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Shawn O. Pearce, git Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > After sending the mail, I actually got an idea: > > .git/logs/attic/<timestamp>/<refname> > > I think this should work without problems. In that case, git-gc also > handles the garbage collection. I do not like that particular color of the bikeshed, but I'd agree that it certainly is the easiest route from both the implementation and the design point of view. All of the "hard stuff" Shawn mentions goes away, and you are left with only one new "hard stuff", which is much easier to solve: - Should there be a way to really remove the archived reflog? And my answer is "yes, a new subcommand to 'git-reflog' to list and another subcommand to remove one". As to default behaviour, probably we would by default archive any local branches, and _not_ archive other things like remote trackers and tags. A new configuration variable reflog.archive = {none,heads,all} would be honored and absense of it defaults to reflog.archive = heads. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-02 18:13 ` Junio C Hamano @ 2008-06-02 19:17 ` Johannes Schindelin 2008-06-02 19:25 ` Johannes Schindelin 0 siblings, 1 reply; 371+ messages in thread From: Johannes Schindelin @ 2008-06-02 19:17 UTC (permalink / raw) To: Junio C Hamano; +Cc: Shawn O. Pearce, git Hi, On Mon, 2 Jun 2008, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > After sending the mail, I actually got an idea: > > > > .git/logs/attic/<timestamp>/<refname> > > > > I think this should work without problems. In that case, git-gc also > > handles the garbage collection. > > I do not like that particular color of the bikeshed, but I'd agree that > it certainly is the easiest route from both the implementation and the > design point of view. Okay, how about "deleted-%d.%m.%Y-%H:%M:%S" instead of "attic/%s"? > All of the "hard stuff" Shawn mentions goes away, and you are left with > only one new "hard stuff", which is much easier to solve: > > - Should there be a way to really remove the archived reflog? > > And my answer is "yes, a new subcommand to 'git-reflog' to list and > another subcommand to remove one". You mean a subcommand to list just the refs that exist in the deleted-* namespace? As to remove one, how about: git reflog --expire=now --expire-unreachable=now \ deleted-<date>/<refname> Hmm? > As to default behaviour, probably we would by default archive any local > branches, and _not_ archive other things like remote trackers and tags. Unfortunately, this is exactly what I need: remote trackers and tags. Since I have to delete branches from repo.or.cz as long as the pruning of forked projects' objects does not work correctly. > A new configuration variable reflog.archive = {none,heads,all} would be > honored and absense of it defaults to reflog.archive = heads. Sure, that makes sense. I'd just "git config --global reflog.archive all". Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-02 19:17 ` Johannes Schindelin @ 2008-06-02 19:25 ` Johannes Schindelin 0 siblings, 0 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-06-02 19:25 UTC (permalink / raw) To: Junio C Hamano; +Cc: Shawn O. Pearce, git Hi, On Mon, 2 Jun 2008, Johannes Schindelin wrote: > On Mon, 2 Jun 2008, Junio C Hamano wrote: > > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > > > After sending the mail, I actually got an idea: > > > > > > .git/logs/attic/<timestamp>/<refname> Just tried that, and for obvious reasons it fails the testsuite: Git is just too darned fast. Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-06-02 7:58 ` Junio C Hamano ` (2 preceding siblings ...) 2008-06-02 15:17 ` Johannes Schindelin @ 2008-06-13 10:16 ` Junio C Hamano 2008-06-18 7:31 ` Junio C Hamano 3 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-06-13 10:16 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-06-13 10:16 ` Junio C Hamano @ 2008-06-18 7:31 ` Junio C Hamano 2008-06-19 8:58 ` Johan Herland 2008-06-21 9:44 ` Junio C Hamano 0 siblings, 2 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-18 7:31 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-18 7:31 ` Junio C Hamano @ 2008-06-19 8:58 ` Johan Herland 2008-06-21 9:44 ` Junio C Hamano 1 sibling, 0 replies; 371+ messages in thread From: Johan Herland @ 2008-06-19 8:58 UTC (permalink / raw) To: git; +Cc: Junio C Hamano On Wednesday 18 June 2008, Junio C Hamano wrote: > [New Topics] > > * jh/clone-packed-refs (Sun Jun 15 16:06:16 2008 +0200) 4 commits > - Teach "git clone" to pack refs > - Prepare testsuite for a "git clone" that packs refs > - Move pack_refs() and friends into libgit > - Incorporate fetched packs in future object traversal > > Would be helpful cloning from a repository with insanely large number of > refs. The first 3 patches (i.e. the bottom 3 in the above list) might be considered general cleanup patches, and are independent of each other (i.e. you might want to include them on their own merit, independently of patch #4). The final patch doesn't make any difference for "regular" repos (e.g. git.git with ~200 refs) on Linux (see below). But once the number of refs increase, the difference becomes obvious. Here are some numbers to give some more context: All tests done on 64-bit quad-core Linux, cloning locally (hard-linked): ~200 refs (git.git): current next: 0.2s w/above patches: 0.2s ~1000 refs (test repo): current next: 0.16s w/above patches: 0.05s ~11000 refs (test repo): current next: 1.3s w/above patches: 0.3s ~26000 refs (actual repo at $dayjob): current next: 3.2s w/above patches: 0.8s Regards, ...Johan -- Johan Herland, <johan@herland.net> www.herland.net ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-06-18 7:31 ` Junio C Hamano 2008-06-19 8:58 ` Johan Herland @ 2008-06-21 9:44 ` Junio C Hamano 2008-06-21 12:14 ` Miklos Vajna 2008-06-23 7:15 ` Junio C Hamano 1 sibling, 2 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-21 9:44 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-21 9:44 ` Junio C Hamano @ 2008-06-21 12:14 ` Miklos Vajna 2008-06-24 7:59 ` Junio C Hamano 2008-06-23 7:15 ` Junio C Hamano 1 sibling, 1 reply; 371+ messages in thread From: Miklos Vajna @ 2008-06-21 12:14 UTC (permalink / raw) To: Junio C Hamano; +Cc: git [-- Attachment #1: Type: text/plain, Size: 812 bytes --] On Sat, Jun 21, 2008 at 02:44:50AM -0700, Junio C Hamano <gitster@pobox.com> wrote: > * nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit > + Move all dashed-form commands to libexecdir > > Scheduled for 1.6.0. > > * jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits > - Prepare execv_git_cmd() for removal of builtins from the > filesystem > - git-shell: accept "git foo" form > > We do not plan to remove git-foo form completely from the filesystem at > this point, but git-shell may need to be updated. I may be wrong, but given that git-upload-pack/receive-pack is now not in PATH, I think it will be problematic to do a pull/push in case the server runs next, the client is 1.5.6 and the user has git-shell as shell, for example. Or have I missed something? Thanks [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-21 12:14 ` Miklos Vajna @ 2008-06-24 7:59 ` Junio C Hamano 2008-06-24 8:12 ` Pieter de Bie 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-06-24 7:59 UTC (permalink / raw) To: Miklos Vajna; +Cc: git Miklos Vajna <vmiklos@frugalware.org> writes: > On Sat, Jun 21, 2008 at 02:44:50AM -0700, Junio C Hamano <gitster@pobox.com> wrote: >> * nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit >> + Move all dashed-form commands to libexecdir >> >> Scheduled for 1.6.0. >> >> * jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits >> - Prepare execv_git_cmd() for removal of builtins from the >> filesystem >> - git-shell: accept "git foo" form >> >> We do not plan to remove git-foo form completely from the filesystem at >> this point, but git-shell may need to be updated. > > I may be wrong, but given that git-upload-pack/receive-pack is now not > in PATH, I think it will be problematic to do a pull/push in case the > server runs next, the client is 1.5.6 and the user has git-shell as > shell, for example. The idea of the "shell: accept 'git foo' form" patch is that as long as the server end consistently use the same version (i.e. git-shell is from 'next' and it knows where the rest of git is installed), things should work fine. I've merged them to 'next' and pushed it out so that you can try it. I do not use git-shell in production setting (I do have one user account whose login shell is git-shell from 'next' I use purely for testing), and I do not know how much use it has seen in the real world. My cursory sanity-check ("cvs -d :ext:thatuser@myhost:/path/ co --help", and "git ls-remote ssh://thatuser@myhost/path/") seems to be Ok with $(bindir) that has only git, gitk and nothing else. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-24 7:59 ` Junio C Hamano @ 2008-06-24 8:12 ` Pieter de Bie 2008-06-24 8:16 ` Pieter de Bie 2008-06-24 16:02 ` Miklos Vajna 0 siblings, 2 replies; 371+ messages in thread From: Pieter de Bie @ 2008-06-24 8:12 UTC (permalink / raw) To: Junio C Hamano; +Cc: Miklos Vajna, git On 24 jun 2008, at 09:59, Junio C Hamano wrote: > The idea of the "shell: accept 'git foo' form" patch is that as long > as > the server end consistently use the same version (i.e. git-shell is > from > 'next' and it knows where the rest of git is installed), things should > work fine. I've merged them to 'next' and pushed it out so that you > can > try it. Any clone / push operation fails if you use current next: Vienna:bin pieter$ git --version git version 1.5.6.129.g274ea Vienna:bin pieter$ git clone localhost:project/bonnenteller Initialize bonnenteller/.git Initialized empty Git repository in /opt/git/bin/bonnenteller/.git/ Password: bash: git-upload-pack: command not found fatal: The remote end hung up unexpectedly I think that is what Miklos meant. Also, I think the client sends the command to execute on the remote side. At least for v1.5.5 clients and before, that is "git-upload-pack". As this is not in PATH, that command will fail on any server that runs v1.5.6 and has the libexec dir. - Pieter ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-24 8:12 ` Pieter de Bie @ 2008-06-24 8:16 ` Pieter de Bie 2008-06-24 16:02 ` Miklos Vajna 1 sibling, 0 replies; 371+ messages in thread From: Pieter de Bie @ 2008-06-24 8:16 UTC (permalink / raw) To: Junio C Hamano; +Cc: Miklos Vajna, Git Mailinglist On 24 jun 2008, at 10:12, Pieter de Bie wrote: > I think that is what Miklos meant. Also, I think the client sends > the command to execute on the remote side. At least for v1.5.5 > clients and before, that is "git-upload-pack". As this is not in > PATH, that command will fail on any server that runs v1.5.6 and has > the libexec dir. That is supposed to be "v1.5.6" and "v1.6.0" respectively. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-24 8:12 ` Pieter de Bie 2008-06-24 8:16 ` Pieter de Bie @ 2008-06-24 16:02 ` Miklos Vajna 2008-06-24 16:25 ` Johannes Schindelin 1 sibling, 1 reply; 371+ messages in thread From: Miklos Vajna @ 2008-06-24 16:02 UTC (permalink / raw) To: Pieter de Bie; +Cc: Junio C Hamano, git [-- Attachment #1: Type: text/plain, Size: 507 bytes --] On Tue, Jun 24, 2008 at 10:12:28AM +0200, Pieter de Bie <pdebie@ai.rug.nl> wrote: > Vienna:bin pieter$ git --version > git version 1.5.6.129.g274ea > Vienna:bin pieter$ git clone localhost:project/bonnenteller > Initialize bonnenteller/.git > Initialized empty Git repository in /opt/git/bin/bonnenteller/.git/ > Password: > bash: git-upload-pack: command not found > fatal: The remote end hung up unexpectedly > > I think that is what Miklos meant. Exactly. Thanks for the good description. [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-24 16:02 ` Miklos Vajna @ 2008-06-24 16:25 ` Johannes Schindelin 2008-06-24 18:54 ` Miklos Vajna 0 siblings, 1 reply; 371+ messages in thread From: Johannes Schindelin @ 2008-06-24 16:25 UTC (permalink / raw) To: Miklos Vajna; +Cc: Pieter de Bie, Junio C Hamano, git Hi, On Tue, 24 Jun 2008, Miklos Vajna wrote: > On Tue, Jun 24, 2008 at 10:12:28AM +0200, Pieter de Bie <pdebie@ai.rug.nl> wrote: > > Vienna:bin pieter$ git --version > > git version 1.5.6.129.g274ea > > Vienna:bin pieter$ git clone localhost:project/bonnenteller > > Initialize bonnenteller/.git > > Initialized empty Git repository in /opt/git/bin/bonnenteller/.git/ > > Password: > > bash: git-upload-pack: command not found > > fatal: The remote end hung up unexpectedly > > > > I think that is what Miklos meant. > > Exactly. Thanks for the good description. AFAICT these are fixed with ed99a225(Merge branch 'jc/dashless' into next). Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-24 16:25 ` Johannes Schindelin @ 2008-06-24 18:54 ` Miklos Vajna 2008-06-24 19:08 ` Johannes Schindelin 0 siblings, 1 reply; 371+ messages in thread From: Miklos Vajna @ 2008-06-24 18:54 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Pieter de Bie, Junio C Hamano, git [-- Attachment #1: Type: text/plain, Size: 1038 bytes --] On Tue, Jun 24, 2008 at 05:25:57PM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > > Vienna:bin pieter$ git --version > > > git version 1.5.6.129.g274ea > > > Vienna:bin pieter$ git clone localhost:project/bonnenteller > > > Initialize bonnenteller/.git > > > Initialized empty Git repository in /opt/git/bin/bonnenteller/.git/ > > > Password: > > > bash: git-upload-pack: command not found > > > fatal: The remote end hung up unexpectedly > > > > > > I think that is what Miklos meant. > > > > Exactly. Thanks for the good description. > > AFAICT these are fixed with ed99a225(Merge branch 'jc/dashless' into > next). Using fc48199 ("Merge branch 'master' into next", which includes ed99a225) on the server, v1.5.6 on the client, I get: $ git clone server:/home/vmiklos/git/test next Initialize next/.git Initialized empty Git repository in /home/vmiklos/scm/git/next/.git/ vmiklos@server's password: bash: git-upload-pack: command not found fatal: The remote end hung up unexpectedly [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-24 18:54 ` Miklos Vajna @ 2008-06-24 19:08 ` Johannes Schindelin 2008-06-24 19:31 ` Jakub Narebski 2008-06-24 20:44 ` Junio C Hamano 0 siblings, 2 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-06-24 19:08 UTC (permalink / raw) To: Miklos Vajna; +Cc: Pieter de Bie, Junio C Hamano, git Hi, On Tue, 24 Jun 2008, Miklos Vajna wrote: > On Tue, Jun 24, 2008 at 05:25:57PM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > > > Vienna:bin pieter$ git --version > > > > git version 1.5.6.129.g274ea > > > > Vienna:bin pieter$ git clone localhost:project/bonnenteller > > > > Initialize bonnenteller/.git > > > > Initialized empty Git repository in /opt/git/bin/bonnenteller/.git/ > > > > Password: > > > > bash: git-upload-pack: command not found > > > > fatal: The remote end hung up unexpectedly > > > > > > > > I think that is what Miklos meant. > > > > > > Exactly. Thanks for the good description. > > > > AFAICT these are fixed with ed99a225(Merge branch 'jc/dashless' into > > next). > > Using fc48199 ("Merge branch 'master' into next", which includes > ed99a225) on the server, v1.5.6 on the client, I get: > > $ git clone server:/home/vmiklos/git/test next > Initialize next/.git > Initialized empty Git repository in /home/vmiklos/scm/git/next/.git/ > vmiklos@server's password: > bash: git-upload-pack: command not found > fatal: The remote end hung up unexpectedly Hmm. Probably the client needs to be newer, too. This is going to be painful. Junio? Sorry for the noise, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-24 19:08 ` Johannes Schindelin @ 2008-06-24 19:31 ` Jakub Narebski 2008-06-24 19:34 ` Johannes Schindelin 2008-06-24 20:44 ` Junio C Hamano 1 sibling, 1 reply; 371+ messages in thread From: Jakub Narebski @ 2008-06-24 19:31 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Miklos Vajna, Pieter de Bie, Junio C Hamano, git Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > On Tue, 24 Jun 2008, Miklos Vajna wrote: > > > > Using fc48199 ("Merge branch 'master' into next", which includes > > ed99a225) on the server, v1.5.6 on the client, I get: > > > > $ git clone server:/home/vmiklos/git/test next > > Initialize next/.git > > Initialized empty Git repository in /home/vmiklos/scm/git/next/.git/ > > vmiklos@server's password: > > bash: git-upload-pack: command not found > > fatal: The remote end hung up unexpectedly > > Hmm. Probably the client needs to be newer, too. This is going to be > painful. Junio? It looks like git-upload-pack and git-receive-pack would have to be left in $PATH, at least till old clients die of old age ;-) git-shell hackery won't solve problem, because not everybody is using git-shell. -- Jakub Narebski Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-24 19:31 ` Jakub Narebski @ 2008-06-24 19:34 ` Johannes Schindelin 2008-06-24 20:06 ` Jakub Narebski 2008-06-26 15:41 ` Jakub Narebski 0 siblings, 2 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-06-24 19:34 UTC (permalink / raw) To: Jakub Narebski; +Cc: Miklos Vajna, Pieter de Bie, Junio C Hamano, git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-24 19:34 ` Johannes Schindelin @ 2008-06-24 20:06 ` Jakub Narebski 2008-06-26 15:41 ` Jakub Narebski 1 sibling, 0 replies; 371+ messages in thread From: Jakub Narebski @ 2008-06-24 20:06 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Miklos Vajna, Pieter de Bie, Junio C Hamano, git Hello! Johannes Schindelin wrote: > On Tue, 24 Jun 2008, Jakub Narebski wrote: > > > git-shell hackery won't solve problem, because not everybody is using > > git-shell. > > The problem is not git-shell vs git potty. > > The problem is that not everybody magically updates their clients to ask > for dash-less form. What I meant here by "git-shell hackery" was for git-shell to automagically redirect request for "git-receive-pack" to "git receive-pack" (or "$GIT_EXEC_PATH/git-receive-pack"). But, as I said, it isn't complete solution. Leaving git-*-pack in $PATH for the time being (what I said) is. -- Jakub Narebski Poland ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-24 19:34 ` Johannes Schindelin 2008-06-24 20:06 ` Jakub Narebski @ 2008-06-26 15:41 ` Jakub Narebski 1 sibling, 0 replies; 371+ messages in thread From: Jakub Narebski @ 2008-06-26 15:41 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Miklos Vajna, Pieter de Bie, Junio C Hamano, git On Tue, 24 Jun 2008, Johannes Schindelin wrote: > Hi, > > On Tue, 24 Jun 2008, Jakub Narebski wrote: > > > git-shell hackery won't solve problem, because not everybody is using > > git-shell. > > The problem is not git-shell vs git potty. > > The problem is that not everybody magically updates their clients to ask > for dash-less form. With git-shell even if client uses dashed form it can find git commands ("hackery" is too strong a word for having git-shell search $GIT_EXEC_PATH). But if one uses only SSH, server must have dashed form in a $PATH -- Jakub Narebski Poland ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-24 19:08 ` Johannes Schindelin 2008-06-24 19:31 ` Jakub Narebski @ 2008-06-24 20:44 ` Junio C Hamano 2008-06-24 22:10 ` Miklos Vajna 1 sibling, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-06-24 20:44 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Miklos Vajna, Pieter de Bie, git Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> Using fc48199 ("Merge branch 'master' into next", which includes >> ed99a225) on the server, v1.5.6 on the client, I get: >> >> $ git clone server:/home/vmiklos/git/test next >> Initialize next/.git >> Initialized empty Git repository in /home/vmiklos/scm/git/next/.git/ >> vmiklos@server's password: >> bash: git-upload-pack: command not found >> fatal: The remote end hung up unexpectedly > > Hmm. Probably the client needs to be newer, too. This is going to be > painful. Junio? Even with maint client accessing an account with next git-shell as its login shell, I do not get the above failure. Is git-shell installed and configured correctly at all in Miklos's setup? Why does the other side say "bash: git-upload-pack" when login shell is git-shell and not bash? ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-24 20:44 ` Junio C Hamano @ 2008-06-24 22:10 ` Miklos Vajna 2008-06-24 23:16 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Miklos Vajna @ 2008-06-24 22:10 UTC (permalink / raw) To: Junio C Hamano; +Cc: Johannes Schindelin, Pieter de Bie, git [-- Attachment #1: Type: text/plain, Size: 823 bytes --] On Tue, Jun 24, 2008 at 01:44:34PM -0700, Junio C Hamano <gitster@pobox.com> wrote: > >> bash: git-upload-pack: command not found > >> fatal: The remote end hung up unexpectedly > > > > Hmm. Probably the client needs to be newer, too. This is going to be > > painful. Junio? > > Even with maint client accessing an account with next git-shell as its > login shell, I do not get the above failure. > > Is git-shell installed and configured correctly at all in Miklos's setup? > Why does the other side say "bash: git-upload-pack" when login shell is > git-shell and not bash? Sorry for the confusion, this is not about git-shell at all. I have bash as the shell on the server, obviously. So, in case the server runs next, the client runs master, and I try to clone via ssh, I get the above error. [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-24 22:10 ` Miklos Vajna @ 2008-06-24 23:16 ` Junio C Hamano 2008-06-24 23:32 ` Miklos Vajna 2008-06-25 0:11 ` Jakub Narebski 0 siblings, 2 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-24 23:16 UTC (permalink / raw) To: Miklos Vajna; +Cc: Johannes Schindelin, Pieter de Bie, git Miklos Vajna <vmiklos@frugalware.org> writes: > On Tue, Jun 24, 2008 at 01:44:34PM -0700, Junio C Hamano <gitster@pobox.com> wrote: >> >> bash: git-upload-pack: command not found >> >> fatal: The remote end hung up unexpectedly >> > >> > Hmm. Probably the client needs to be newer, too. This is going to be >> > painful. Junio? >> >> Even with maint client accessing an account with next git-shell as its >> login shell, I do not get the above failure. >> >> Is git-shell installed and configured correctly at all in Miklos's setup? >> Why does the other side say "bash: git-upload-pack" when login shell is >> git-shell and not bash? > > Sorry for the confusion, this is not about git-shell at all. I have > bash as the shell on the server, obviously. > > So, in case the server runs next, the client runs master, and I try to > clone via ssh, I get the above error. Ah, there is not much we can do in that case then. git-upload-pack is what the client asks you to run, and if you do not have it in the path, you can (1) either make sure it is on the path, (2) have the client be more explicit when asking for git-upload-pack (--upload-pack=$where), or (3) leave the minimum git-* binaries that can remotely be launched directly in the usual $PATH. It most likely makes sense to do (3) anyway. upload-pack, receive-pack, anything else? ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-24 23:16 ` Junio C Hamano @ 2008-06-24 23:32 ` Miklos Vajna 2008-06-25 2:57 ` Junio C Hamano 2008-06-25 3:08 ` しらいしななこ 2008-06-25 0:11 ` Jakub Narebski 1 sibling, 2 replies; 371+ messages in thread From: Miklos Vajna @ 2008-06-24 23:32 UTC (permalink / raw) To: Junio C Hamano; +Cc: Johannes Schindelin, Pieter de Bie, git [-- Attachment #1: Type: text/plain, Size: 197 bytes --] On Tue, Jun 24, 2008 at 04:16:36PM -0700, Junio C Hamano <gitster@pobox.com> wrote: > It most likely makes sense to do (3) anyway. upload-pack, receive-pack, > anything else? I think that's all. [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-24 23:32 ` Miklos Vajna @ 2008-06-25 2:57 ` Junio C Hamano 2008-06-25 3:08 ` しらいしななこ 1 sibling, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-25 2:57 UTC (permalink / raw) To: Miklos Vajna; +Cc: pclouds, Johannes Schindelin, Pieter de Bie, git 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 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-24 23:32 ` Miklos Vajna 2008-06-25 2:57 ` Junio C Hamano @ 2008-06-25 3:08 ` しらいしななこ 2008-06-25 3:22 ` [PATCH] Keep some git-* programs in $(bindir) Junio C Hamano 2008-06-25 3:26 ` What's cooking in git.git (topics) Shawn O. Pearce 1 sibling, 2 replies; 371+ messages in thread From: しらいしななこ @ 2008-06-25 3:08 UTC (permalink / raw) To: Junio C Hamano Cc: Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git Quoting Junio C Hamano <gitster@pobox.com>: > Miklos Vajna <vmiklos@frugalware.org> writes: > >> On Tue, Jun 24, 2008 at 04:16:36PM -0700, Junio C Hamano <gitster@pobox.com> wrote: >>> It most likely makes sense to do (3) anyway. upload-pack, receive-pack, >>> anything else? >> >> I think that's all. > > Then that would be this patch on top of nd/dashless topic. > > Makefile | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/Makefile b/Makefile > index 929136b..babf16b 100644 > --- a/Makefile > +++ b/Makefile > @@ -1268,7 +1268,7 @@ install: all > $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)' > $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)' > $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)' > - $(INSTALL) git$X '$(DESTDIR_SQ)$(bindir_SQ)' > + $(INSTALL) git$X git-upload-pack$X git-receive-pack$X '$(DESTDIR_SQ)$(bindir_SQ)' > $(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install > $(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install > ifndef NO_TCLTK Doesn't "git archive --remote=<repo>" also execute git program on a remote machine? -- Nanako Shiraishi http://ivory.ap.teacup.com/nanako3/ ^ permalink raw reply [flat|nested] 371+ messages in thread
* [PATCH] Keep some git-* programs in $(bindir) 2008-06-25 3:08 ` しらいしななこ @ 2008-06-25 3:22 ` Junio C Hamano 2008-06-25 3:26 ` [PATCH] Ask for "git program" when asking for "git-program" over SSH connection Junio C Hamano ` (2 more replies) 2008-06-25 3:26 ` What's cooking in git.git (topics) Shawn O. Pearce 1 sibling, 3 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-25 3:22 UTC (permalink / raw) To: しらいしななこ Cc: Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git 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 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH] Ask for "git program" when asking for "git-program" over SSH connection 2008-06-25 3:22 ` [PATCH] Keep some git-* programs in $(bindir) Junio C Hamano @ 2008-06-25 3:26 ` Junio C Hamano 2008-06-25 3:45 ` Shawn O. Pearce 2008-06-25 4:17 ` [PATCH] Keep some git-* programs in $(bindir) Shawn O. Pearce 2008-06-25 4:19 ` Daniel Barkalow 2 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-06-25 3:26 UTC (permalink / raw) To: しらいしななこ Cc: Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git 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 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection 2008-06-25 3:26 ` [PATCH] Ask for "git program" when asking for "git-program" over SSH connection Junio C Hamano @ 2008-06-25 3:45 ` Shawn O. Pearce 2008-06-25 4:32 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Shawn O. Pearce @ 2008-06-25 3:45 UTC (permalink / raw) To: Junio C Hamano Cc: しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git Junio C Hamano <gitster@pobox.com> wrote: > The daemon expects to see the dashed form and we cannot change older > servers. But when invoking programs on the remote end over SSH, the > command line the client side build is under client's control. ... > diff --git a/connect.c b/connect.c > index e92af29..fd1da26 100644 > --- a/connect.c > +++ b/connect.c > @@ -589,6 +589,10 @@ struct child_process *git_connect(int fd[2], const char *url_orig, > conn = xcalloc(1, sizeof(*conn)); > > strbuf_init(&cmd, MAX_CMD_LEN); > + if (protocol != PROTO_GIT && !strncmp(prog, "git-", 4)) { > + strbuf_addstr(&cmd, "git "); > + prog += 4; > + } Nack on that implementation. I think this is a problem for systems based on say gitosis, or some pattern like it. Day-job doesn't use gitosis, but has switched to a Perl based forced ssh tool that smells a lot like gitosis. Gitosis is popular. github probably uses something similar. But nobody knows (or probably cares) since they don't release their source. gitosis is likely looking for "$git-upload-pack '(.*)'$" to be in the $SSH_ORIGINAL_COMMAND environment variable, if you send "git upload-pack 'path.git'" I think its going to reject. What's really bad about your patch is you cannot work around it as a user by setting --upload-pack on the command line, or in the config, because down at the very deepest level you are switching the "git-" to "git " and ignoring what the user has supplied you. Sorry, but I think this change needs to go higher up, to the default values that --upload-pack and remote.$name.uploadpack override, so the user can at least work around it when we break her ability to use github, gitosis, or anything like it. -- Shawn. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection 2008-06-25 3:45 ` Shawn O. Pearce @ 2008-06-25 4:32 ` Junio C Hamano 2008-06-25 4:44 ` Shawn O. Pearce 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-06-25 4:32 UTC (permalink / raw) To: Shawn O. Pearce Cc: しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git "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? ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection 2008-06-25 4:32 ` Junio C Hamano @ 2008-06-25 4:44 ` Shawn O. Pearce 2008-06-25 5:09 ` Junio C Hamano 2008-06-25 5:30 ` Junio C Hamano 0 siblings, 2 replies; 371+ messages in thread From: Shawn O. Pearce @ 2008-06-25 4:44 UTC (permalink / raw) To: Junio C Hamano Cc: しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git Junio C Hamano <gitster@pobox.com> wrote: > "Shawn O. Pearce" <spearce@spearce.org> writes: > > > Sorry, but I think this change needs to go higher up, to the default > > values that --upload-pack and remote.$name.uploadpack override, > > so the user can at least work around it when we break her ability > > to use github, gitosis, or anything like it. > > Well, the thing is, "higher up" would not have enough clue to see if it > needs to give dashed form (for git-daemon) or space form (for ssh), so > that suggestion won't help much. Actually I'd go the other direction. Allow the higher up level to supply "git upload-pack" and convert it to git- for the git:// protocol. Possible patch below. > I do not care too much about closed source service, but gitosis should be > able to update the pattern to allow "git[ -]upload-pack" reasonably > easily. Pasky also has to update: $ git ls-remote --upload-pack='git upload-pack' repo.or.cz:/srv/git/egit.git fatal: unrecognized command 'git upload-pack '/srv/git/egit.git'' fatal: The remote end hung up unexpectedly ;-) > Any other suggestions that is workable? diff --git a/builtin-clone.c b/builtin-clone.c index 5c5acb4..98d0f0f 100644 --- a/builtin-clone.c +++ b/builtin-clone.c @@ -37,7 +37,7 @@ static int option_quiet, option_no_checkout, option_bare; static int option_local, option_no_hardlinks, option_shared; static char *option_template, *option_reference, *option_depth; static char *option_origin = NULL; -static char *option_upload_pack = "git-upload-pack"; +static char *option_upload_pack = "git upload-pack"; static struct option builtin_clone_options[] = { OPT__QUIET(&option_quiet), @@ -58,7 +58,7 @@ static struct option builtin_clone_options[] = { OPT_STRING('o', "origin", &option_origin, "branch", "use <branch> instead or 'origin' to track upstream"), OPT_STRING('u', "upload-pack", &option_upload_pack, "path", - "path to git-upload-pack on the remote"), + "path to git upload-pack on the remote"), OPT_STRING(0, "depth", &option_depth, "depth", "create a shallow clone of that depth"), diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c index f4dbcf0..b0efd01 100644 --- a/builtin-fetch-pack.c +++ b/builtin-fetch-pack.c @@ -14,7 +14,7 @@ static int transfer_unpack_limit = -1; static int fetch_unpack_limit = -1; static int unpack_limit = 100; static struct fetch_pack_args args = { - /* .uploadpack = */ "git-upload-pack", + /* .uploadpack = */ "git upload-pack", }; static const char fetch_pack_usage[] = diff --git a/connect.c b/connect.c index e92af29..dbabd93 100644 --- a/connect.c +++ b/connect.c @@ -576,8 +576,8 @@ struct child_process *git_connect(int fd[2], const char *url_orig, * from extended components with a NUL byte. */ packet_write(fd[1], - "%s %s%chost=%s%c", - prog, path, 0, + "git-%s %s%chost=%s%c", + prog + 4, path, 0, target_host, 0); free(target_host); free(url); diff --git a/git-parse-remote.sh b/git-parse-remote.sh index 695a409..0f82a93 100755 --- a/git-parse-remote.sh +++ b/git-parse-remote.sh @@ -255,10 +255,10 @@ get_uploadpack () { case "$data_source" in config) uplp=$(git config --get "remote.$1.uploadpack") - echo ${uplp:-git-upload-pack} + echo ${uplp:-git upload-pack} ;; *) - echo "git-upload-pack" + echo "git upload-pack" ;; esac } diff --git a/transport.c b/transport.c index 3ff8519..351b7f5 100644 --- a/transport.c +++ b/transport.c @@ -762,10 +762,10 @@ struct transport *transport_get(struct remote *remote, const char *url) data->thin = 1; data->conn = NULL; - data->uploadpack = "git-upload-pack"; + data->uploadpack = "git upload-pack"; if (remote && remote->uploadpack) data->uploadpack = remote->uploadpack; - data->receivepack = "git-receive-pack"; + data->receivepack = "git receive-pack"; if (remote && remote->receivepack) data->receivepack = remote->receivepack; } -- Shawn. ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection 2008-06-25 4:44 ` Shawn O. Pearce @ 2008-06-25 5:09 ` Junio C Hamano 2008-06-25 5:13 ` Junio C Hamano 2008-06-25 5:30 ` Junio C Hamano 1 sibling, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-06-25 5:09 UTC (permalink / raw) To: Shawn O. Pearce Cc: しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git "Shawn O. Pearce" <spearce@spearce.org> writes: >> Any other suggestions that is workable? > > diff --git a/builtin-clone.c b/builtin-clone.c > index 5c5acb4..98d0f0f 100644 > --- a/builtin-clone.c > +++ b/builtin-clone.c > @@ -37,7 +37,7 @@ static int option_quiet, option_no_checkout, option_bare; << a patch to conditionally change "git-program" default to "git program" snipped >> How would that help client that talk with git-daemon, unlike what I sent earlier? ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection 2008-06-25 5:09 ` Junio C Hamano @ 2008-06-25 5:13 ` Junio C Hamano 2008-06-25 5:27 ` Junio C Hamano 2008-06-25 5:34 ` Shawn O. Pearce 0 siblings, 2 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-25 5:13 UTC (permalink / raw) To: Shawn O. Pearce Cc: しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git Junio C Hamano <gitster@pobox.com> writes: > "Shawn O. Pearce" <spearce@spearce.org> writes: > >>> Any other suggestions that is workable? >> >> diff --git a/builtin-clone.c b/builtin-clone.c >> index 5c5acb4..98d0f0f 100644 >> --- a/builtin-clone.c >> +++ b/builtin-clone.c >> @@ -37,7 +37,7 @@ static int option_quiet, option_no_checkout, option_bare; > > << a patch to conditionally change "git-program" default to "git program" > snipped >> Typofix: s/cond/uncond/; > How would that help client that talk with git-daemon, unlike what I sent > earlier? If we force --upload-pack workaround to _everybody_ we are already lost. Also I think the previous one still lets you work it around by giving a full path, like "/usr/local/bin/git-upload-pack", because "/usr" does not match "git-" ;-) ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection 2008-06-25 5:13 ` Junio C Hamano @ 2008-06-25 5:27 ` Junio C Hamano 2008-06-25 5:38 ` Shawn O. Pearce 2008-06-25 13:06 ` [PATCH] Ask for "git program" when asking for "git-program" over SSH connection Theodore Tso 2008-06-25 5:34 ` Shawn O. Pearce 1 sibling, 2 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-25 5:27 UTC (permalink / raw) To: Shawn O. Pearce Cc: しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git Junio C Hamano <gitster@pobox.com> writes: > If we force --upload-pack workaround to _everybody_ we are already lost. > > Also I think the previous one still lets you work it around by giving a > full path, like "/usr/local/bin/git-upload-pack", because "/usr" does not > match "git-" ;-) Ok, let's map this out seriously. * 1.6.0 will install the server-side programs in $(bindir) so that people coming over ssh will find them on the $PATH * In 1.6.0 (and 1.5.6.1), we will change "git daemon" to accept both "git-program" and "git program" forms. When the spaced form is used, it will behave as if the dashed form is requested. This is a prerequisite for client side change to start asking for "git program". * In the near future, there will no client-side change. "git-program" will be asked for. * 6 months after 1.6.0 ships, hopefully all the deployed server side will be running that version or newer. Client side will start asking for "git program" by default, but we can still override with --upload-pack and friends. * 12 months after client side changes, everybody will be running that version or newer. We stop installing the server side programs in $(bindir) but people coming over ssh will be asking for "git program" and "git" will be on the $PATH so there is no issue. The above 6 and 12 are yanked out of thin air and I am of course open to tweaking them, but I think the above order of events would be workable. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection 2008-06-25 5:27 ` Junio C Hamano @ 2008-06-25 5:38 ` Shawn O. Pearce 2008-06-25 22:47 ` [PATCH] daemon: accept "git program" as well Junio C Hamano 2008-06-25 13:06 ` [PATCH] Ask for "git program" when asking for "git-program" over SSH connection Theodore Tso 1 sibling, 1 reply; 371+ messages in thread From: Shawn O. Pearce @ 2008-06-25 5:38 UTC (permalink / raw) To: Junio C Hamano Cc: しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git Junio C Hamano <gitster@pobox.com> wrote: > Junio C Hamano <gitster@pobox.com> writes: > > > If we force --upload-pack workaround to _everybody_ we are already lost. > > > > Also I think the previous one still lets you work it around by giving a > > full path, like "/usr/local/bin/git-upload-pack", because "/usr" does not > > match "git-" ;-) > > Ok, let's map this out seriously. This plan makes a lot of sense to me. I'm behind it. For whatever that means. At least I'll shutup and stop making noise about this issue if you take this approach. :-) > * 1.6.0 will install the server-side programs in $(bindir) so that > people coming over ssh will find them on the $PATH > > * In 1.6.0 (and 1.5.6.1), we will change "git daemon" to accept both > "git-program" and "git program" forms. When the spaced form is used, it > will behave as if the dashed form is requested. This is a prerequisite > for client side change to start asking for "git program". > > * In the near future, there will no client-side change. "git-program" > will be asked for. > > * 6 months after 1.6.0 ships, hopefully all the deployed server side will > be running that version or newer. Client side will start asking for > "git program" by default, but we can still override with --upload-pack > and friends. > > * 12 months after client side changes, everybody will be running that > version or newer. We stop installing the server side programs in > $(bindir) but people coming over ssh will be asking for "git program" > and "git" will be on the $PATH so there is no issue. > > The above 6 and 12 are yanked out of thin air and I am of course open to > tweaking them, but I think the above order of events would be workable. Yea, 6 and 12 seem like a good idea. Its a couple of releases and gives people time to migrate their server installations. -- Shawn. ^ permalink raw reply [flat|nested] 371+ messages in thread
* [PATCH] daemon: accept "git program" as well 2008-06-25 5:38 ` Shawn O. Pearce @ 2008-06-25 22:47 ` Junio C Hamano 2008-06-25 22:55 ` [PATCH] Make clients ask for "git program" over ssh and local transport Junio C Hamano 2008-06-25 23:02 ` [PATCH] daemon: accept "git program" as well Shawn O. Pearce 0 siblings, 2 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-25 22:47 UTC (permalink / raw) To: Shawn O. Pearce Cc: しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git 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] == ' ') { /* ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH] Make clients ask for "git program" over ssh and local transport 2008-06-25 22:47 ` [PATCH] daemon: accept "git program" as well Junio C Hamano @ 2008-06-25 22:55 ` Junio C Hamano 2008-06-25 22:58 ` [PATCH] Ask for "git program" even against git-daemon Junio C Hamano 2008-06-25 23:13 ` [PATCH] Make clients ask for "git program" over ssh and local transport Shawn O. Pearce 2008-06-25 23:02 ` [PATCH] daemon: accept "git program" as well Shawn O. Pearce 1 sibling, 2 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-25 22:55 UTC (permalink / raw) To: Shawn O. Pearce Cc: しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git 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 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH] Ask for "git program" even against git-daemon 2008-06-25 22:55 ` [PATCH] Make clients ask for "git program" over ssh and local transport Junio C Hamano @ 2008-06-25 22:58 ` Junio C Hamano 2008-06-25 23:27 ` Shawn O. Pearce 2008-06-25 23:13 ` [PATCH] Make clients ask for "git program" over ssh and local transport Shawn O. Pearce 1 sibling, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-06-25 22:58 UTC (permalink / raw) To: Shawn O. Pearce Cc: しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git 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 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH] Ask for "git program" even against git-daemon 2008-06-25 22:58 ` [PATCH] Ask for "git program" even against git-daemon Junio C Hamano @ 2008-06-25 23:27 ` Shawn O. Pearce 2008-06-25 23:36 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Shawn O. Pearce @ 2008-06-25 23:27 UTC (permalink / raw) To: Junio C Hamano Cc: しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git Junio C Hamano <gitster@pobox.com> wrote: > This drops backward compatibility support to ask for "git-program" > form when talking to git-daemon. Now all git native requests use > "git program" form over ssh, local and git transports. > > This needs to be held back until everybody runs git-daemon from 1.5.6.1 or > 1.6.0 or newer. > > Signed-off-by: Junio C Hamano <gitster@pobox.com> > --- > * According to the roadmap we exchanged earlier, this should happen in a > major release (that increments the second dewey-decimal digit from the > left) that ships at least 6 months after 1.5.6.1 and 1.6.0 (which will > have the "git daemon preparation" patch included) are released. Agreed about holding back. But I wonder if this patch is even worth it at some later point in time. Are we also going to change git-daemon to stop accepting "git-" form? Is it a worthwhile change? -- Shawn. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Ask for "git program" even against git-daemon 2008-06-25 23:27 ` Shawn O. Pearce @ 2008-06-25 23:36 ` Junio C Hamano 2008-06-25 23:57 ` Shawn O. Pearce 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-06-25 23:36 UTC (permalink / raw) To: Shawn O. Pearce Cc: しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git "Shawn O. Pearce" <spearce@spearce.org> writes: > Junio C Hamano <gitster@pobox.com> wrote: > ... >> * According to the roadmap we exchanged earlier, this should happen in a >> major release (that increments the second dewey-decimal digit from the >> left) that ships at least 6 months after 1.5.6.1 and 1.6.0 (which will >> have the "git daemon preparation" patch included) are released. > > Agreed about holding back. > > But I wonder if this patch is even worth it at some later point > in time. Are we also going to change git-daemon to stop accepting > "git-" form? Is it a worthwhile change? This was merely responding to... From: "Shawn O. Pearce" <spearce@spearce.org> Subject: Re: [PATCH] Keep some git-* programs in $(bindir) Date: Wed, 25 Jun 2008 00:37:41 -0400 Message-ID: <20080625043741.GD11793@spearce.org> Daniel Barkalow <barkalow@iabervon.org> wrote: > ... > Should they use "git upload-pack" or should they look for their helper > programs in a libexec dir? I don't think that either of these programs is > useful to run independantly, but I don't know if finding a program that > doesn't go in $PATH on a remote machine is going to be any fun. IMHO they should in the future use "git upload-pack". I do not mind not doing this at all. Remember, I am the one with more inertia than anybody else here (holding back backward incompatible innovations is what maintainers do). Oh, that inertia does not have much to do with actual body weight, if anybody is wondering ;-) ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Ask for "git program" even against git-daemon 2008-06-25 23:36 ` Junio C Hamano @ 2008-06-25 23:57 ` Shawn O. Pearce 2008-06-26 0:07 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Shawn O. Pearce @ 2008-06-25 23:57 UTC (permalink / raw) To: Junio C Hamano Cc: しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git Junio C Hamano <gitster@pobox.com> wrote: > "Shawn O. Pearce" <spearce@spearce.org> writes: > > > > But I wonder if this patch is even worth it at some later point > > in time. Are we also going to change git-daemon to stop accepting > > "git-" form? Is it a worthwhile change? > > This was merely responding to... > > From: "Shawn O. Pearce" <spearce@spearce.org> > Subject: Re: [PATCH] Keep some git-* programs in $(bindir) > Date: Wed, 25 Jun 2008 00:37:41 -0400 > Message-ID: <20080625043741.GD11793@spearce.org> > > Daniel Barkalow <barkalow@iabervon.org> wrote: > > ... > > Should they use "git upload-pack" [...] > > IMHO they should in the future use "git upload-pack". Sorry I wasn't clear. I was talking about the SSH transport only. For git:// we could just always send git-upload-pack, like your transitional patch does. Then we stay compatible with even very old git:// servers. -- Shawn. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Ask for "git program" even against git-daemon 2008-06-25 23:57 ` Shawn O. Pearce @ 2008-06-26 0:07 ` Junio C Hamano 0 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-26 0:07 UTC (permalink / raw) To: Shawn O. Pearce Cc: しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git "Shawn O. Pearce" <spearce@spearce.org> writes: > Junio C Hamano <gitster@pobox.com> wrote: >> "Shawn O. Pearce" <spearce@spearce.org> writes: >> > >> > But I wonder if this patch is even worth it at some later point >> > in time. Are we also going to change git-daemon to stop accepting >> > "git-" form? Is it a worthwhile change? >> >> This was merely responding to... >> >> From: "Shawn O. Pearce" <spearce@spearce.org> >> Subject: Re: [PATCH] Keep some git-* programs in $(bindir) >> Date: Wed, 25 Jun 2008 00:37:41 -0400 >> Message-ID: <20080625043741.GD11793@spearce.org> >> >> Daniel Barkalow <barkalow@iabervon.org> wrote: >> > ... >> > Should they use "git upload-pack" [...] >> >> IMHO they should in the future use "git upload-pack". > > Sorry I wasn't clear. I was talking about the SSH transport only. > For git:// we could just always send git-upload-pack, like your > transitional patch does. Then we stay compatible with even very > old git:// servers. Ok, if that is the plan, then we wouldn't even need to futureproof git-daemon at all. Not having to change anything is good ;-). ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Make clients ask for "git program" over ssh and local transport 2008-06-25 22:55 ` [PATCH] Make clients ask for "git program" over ssh and local transport Junio C Hamano 2008-06-25 22:58 ` [PATCH] Ask for "git program" even against git-daemon Junio C Hamano @ 2008-06-25 23:13 ` Shawn O. Pearce 1 sibling, 0 replies; 371+ messages in thread From: Shawn O. Pearce @ 2008-06-25 23:13 UTC (permalink / raw) To: Junio C Hamano Cc: しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git Junio C Hamano <gitster@pobox.com> wrote: > This will allow server side programs such as upload-pack to be installed > outside $PATH. Connections to git-daemon still ask for "git-program" to > retain backward compatibility for daemons before 1.5.6.1 and 1.6.0. > > Signed-off-by: Junio C Hamano <gitster@pobox.com> > --- > * This is essentially your patch. This can be in 1.6.0 clients and it > should also be in 1.5.6.1 as people might keep ancient clients to talk > to new servers that won't have anything but "git" on $PATH. Ack. Thanks for cleaning up the code in connect.c to not segfault or send garbage. I think you want to squash this in as well: diff --git a/builtin-send-pack.c b/builtin-send-pack.c index d76260c..f693a6d 100644 --- a/builtin-send-pack.c +++ b/builtin-send-pack.c @@ -12,7 +12,7 @@ static const char send_pack_usage[] = " --all and explicit <ref> specification are mutually exclusive."; static struct send_pack_args args = { - /* .receivepack = */ "git-receive-pack", + /* .receivepack = */ "git receive-pack", }; /* -- Shawn. ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH] daemon: accept "git program" as well 2008-06-25 22:47 ` [PATCH] daemon: accept "git program" as well Junio C Hamano 2008-06-25 22:55 ` [PATCH] Make clients ask for "git program" over ssh and local transport Junio C Hamano @ 2008-06-25 23:02 ` Shawn O. Pearce 2008-06-25 23:26 ` Junio C Hamano 1 sibling, 1 reply; 371+ messages in thread From: Shawn O. Pearce @ 2008-06-25 23:02 UTC (permalink / raw) To: Junio C Hamano Cc: しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git Junio C Hamano <gitster@pobox.com> wrote: > This is a step to futureproof git-daemon to accept clients that > ask for "git upload-pack" and friends, instead of using the more > traditional dash-form "git-upload-pack". By allowing both, it > makes the client side easier to handle, as it makes "git" the only > thing necessary to be on $PATH when invoking the remote command > directly via ssh. > > Signed-off-by: Junio C Hamano <gitster@pobox.com> Obviously correct. Ack. Thanks Junio. > So this obviously needs to be queued to 'maint' to be included in 1.5.6.1 > and 1.6.0. > > daemon.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/daemon.c b/daemon.c > index 63cd12c..621c567 100644 > --- a/daemon.c > +++ b/daemon.c > @@ -586,7 +586,7 @@ static int execute(struct sockaddr *addr) > for (i = 0; i < ARRAY_SIZE(daemon_service); i++) { > struct daemon_service *s = &(daemon_service[i]); > int namelen = strlen(s->name); > - if (!prefixcmp(line, "git-") && > + if ((!prefixcmp(line, "git-") || !prefixcmp(line, "git ")) && > !strncmp(s->name, line + 4, namelen) && > line[namelen + 4] == ' ') { > /* -- Shawn. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] daemon: accept "git program" as well 2008-06-25 23:02 ` [PATCH] daemon: accept "git program" as well Shawn O. Pearce @ 2008-06-25 23:26 ` Junio C Hamano 2008-06-26 8:20 ` Tommi Virtanen 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-06-25 23:26 UTC (permalink / raw) To: Shawn O. Pearce Cc: tv, しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git "Shawn O. Pearce" <spearce@spearce.org> writes: > Junio C Hamano <gitster@pobox.com> wrote: >> This is a step to futureproof git-daemon to accept clients that >> ask for "git upload-pack" and friends, instead of using the more >> traditional dash-form "git-upload-pack". By allowing both, it >> makes the client side easier to handle, as it makes "git" the only >> thing necessary to be on $PATH when invoking the remote command >> directly via ssh. >> >> Signed-off-by: Junio C Hamano <gitster@pobox.com> > > Obviously correct. Ack. Thanks Junio. By the way I looked at gitosis (Tommi CC'ed). http://repo.or.cz/w/gitosis.git?a=blob;f=gitosis/serve.py;h=c0b7135bf45305ee1079b0dcab3b4ed1ce988aab;hb=38561aa6a51a2ef6cc04aa119481df62d213ffa4 In gitosis/serve.py, there are COMMANDS_READONLY and COMMANDS_WRITE array that holds 'git-upload-pack' and 'git-receive-pack' commands, and they are compared with user commands after doing: verb, args = command.split(None, 1) (and "verb" is looked up in the set of valid commands). It should not be too involved to notice verb is 'git' and then re-split the args part to see if they are upload-pack/receive-pack, which would be the equivalent change to this patch. It needs to be done before the clients are updated. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] daemon: accept "git program" as well 2008-06-25 23:26 ` Junio C Hamano @ 2008-06-26 8:20 ` Tommi Virtanen 2008-06-26 23:38 ` Olivier Marin 0 siblings, 1 reply; 371+ messages in thread From: Tommi Virtanen @ 2008-06-26 8:20 UTC (permalink / raw) To: Junio C Hamano Cc: Shawn O. Pearce, しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git On Wed, Jun 25, 2008 at 04:26:46PM -0700, Junio C Hamano wrote: > By the way I looked at gitosis (Tommi CC'ed). > > http://repo.or.cz/w/gitosis.git?a=blob;f=gitosis/serve.py;h=c0b7135bf45305ee1079b0dcab3b4ed1ce988aab;hb=38561aa6a51a2ef6cc04aa119481df62d213ffa4 > > In gitosis/serve.py, there are COMMANDS_READONLY and COMMANDS_WRITE array > that holds 'git-upload-pack' and 'git-receive-pack' commands, and they are > compared with user commands after doing: Yeah, that's pretty much a trivial change, doing it now to future-proof gitosis. -- :(){ :|:&};: ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] daemon: accept "git program" as well 2008-06-26 8:20 ` Tommi Virtanen @ 2008-06-26 23:38 ` Olivier Marin 2008-06-26 23:42 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Olivier Marin @ 2008-06-26 23:38 UTC (permalink / raw) To: Tommi Virtanen Cc: Git Mailing List, Junio C Hamano, しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, Shawn O. Pearce Hi, Tommi Virtanen a écrit : > On Wed, Jun 25, 2008 at 04:26:46PM -0700, Junio C Hamano wrote: >> >> In gitosis/serve.py, there are COMMANDS_READONLY and COMMANDS_WRITE array >> that holds 'git-upload-pack' and 'git-receive-pack' commands, and they are >> compared with user commands after doing: > > Yeah, that's pretty much a trivial change, doing it now to future-proof > gitosis. > This just happened to me with a dashless client, so I tried your patch but it does not work. The problem comes from git-shell that do not support dashless argument, yet (IOW: git shell -c 'git upload-pack ...' give an error). The following patch on top of yours fix the problem. The s/git-shell/git shell/ part is not really necessary, but why not? diff --git a/gitosis/serve.py b/gitosis/serve.py index 9a91fcb..5aac355 100644 --- a/gitosis/serve.py +++ b/gitosis/serve.py @@ -21,12 +21,10 @@ ALLOW_RE = re.compile("^'/*(?P<path>[a-zA-Z0-9][a-zA-Z0-9@._-]*(/[a-zA-Z0-9][a-z COMMANDS_READONLY = [ 'git-upload-pack', - 'git upload-pack', ] COMMANDS_WRITE = [ 'git-receive-pack', - 'git receive-pack', ] class ServingError(Exception): @@ -75,7 +73,7 @@ def serve( # all known "git foo" commands take one argument; improve # if/when needed raise UnknownCommandError() - verb = '%s %s' % (verb, subverb) + verb = '%s-%s' % (verb, subverb) if (verb not in COMMANDS_WRITE and verb not in COMMANDS_READONLY): @@ -201,6 +199,6 @@ class Main(app.App): sys.exit(1) main_log.debug('Serving %s', newcmd) - os.execvp('git-shell', ['git-shell', '-c', newcmd]) - main_log.error('Cannot execute git-shell.') + os.execvp('git', ['git', 'shell', '-c', newcmd]) + main_log.error('Cannot execute git.') sys.exit(1) Olivier. ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH] daemon: accept "git program" as well 2008-06-26 23:38 ` Olivier Marin @ 2008-06-26 23:42 ` Junio C Hamano 0 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-26 23:42 UTC (permalink / raw) To: Olivier Marin Cc: Tommi Virtanen, Git Mailing List, しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, Shawn O. Pearce Olivier Marin <dkr+ml.git@free.fr> writes: > Hi, > > Tommi Virtanen a écrit : >> On Wed, Jun 25, 2008 at 04:26:46PM -0700, Junio C Hamano wrote: >>> >>> In gitosis/serve.py, there are COMMANDS_READONLY and COMMANDS_WRITE array >>> that holds 'git-upload-pack' and 'git-receive-pack' commands, and they are >>> compared with user commands after doing: >> >> Yeah, that's pretty much a trivial change, doing it now to future-proof >> gitosis. >> > > This just happened to me with a dashless client, so I tried your patch but it > does not work. The problem comes from git-shell that do not support dashless > argument, yet (IOW: git shell -c 'git upload-pack ...' give an error). > > The following patch on top of yours fix the problem. The s/git-shell/git shell/ > part is not really necessary, but why not? > > diff --git a/gitosis/serve.py b/gitosis/serve.py > index 9a91fcb..5aac355 100644 > --- a/gitosis/serve.py > +++ b/gitosis/serve.py > @@ -21,12 +21,10 @@ ALLOW_RE = re.compile("^'/*(?P<path>[a-zA-Z0-9][a-zA-Z0-9@._-]*(/[a-zA-Z0-9][a-z > > COMMANDS_READONLY = [ > 'git-upload-pack', > - 'git upload-pack', > ] > > COMMANDS_WRITE = [ > 'git-receive-pack', > - 'git receive-pack', > ] > > class ServingError(Exception): > @@ -75,7 +73,7 @@ def serve( > # all known "git foo" commands take one argument; improve > # if/when needed > raise UnknownCommandError() > - verb = '%s %s' % (verb, subverb) > + verb = '%s-%s' % (verb, subverb) > > if (verb not in COMMANDS_WRITE > and verb not in COMMANDS_READONLY): > @@ -201,6 +199,6 @@ class Main(app.App): > sys.exit(1) > > main_log.debug('Serving %s', newcmd) > - os.execvp('git-shell', ['git-shell', '-c', newcmd]) > - main_log.error('Cannot execute git-shell.') > + os.execvp('git', ['git', 'shell', '-c', newcmd]) > + main_log.error('Cannot execute git.') > sys.exit(1) Hmm, Tommi, if you are doing command sanitizing yourself, is there a reason to still invoke the command via git-shell? ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection 2008-06-25 5:27 ` Junio C Hamano 2008-06-25 5:38 ` Shawn O. Pearce @ 2008-06-25 13:06 ` Theodore Tso 2008-06-25 17:42 ` Junio C Hamano 1 sibling, 1 reply; 371+ messages in thread From: Theodore Tso @ 2008-06-25 13:06 UTC (permalink / raw) To: Junio C Hamano Cc: Shawn O. Pearce, しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git On Tue, Jun 24, 2008 at 10:27:07PM -0700, Junio C Hamano wrote: > Ok, let's map this out seriously. > > * 1.6.0 will install the server-side programs in $(bindir) so that > people coming over ssh will find them on the $PATH > > * In 1.6.0 (and 1.5.6.1), we will change "git daemon" to accept both > "git-program" and "git program" forms. When the spaced form is used, it > will behave as if the dashed form is requested. This is a prerequisite > for client side change to start asking for "git program". > > * In the near future, there will no client-side change. "git-program" > will be asked for. > > * 6 months after 1.6.0 ships, hopefully all the deployed server side will > be running that version or newer. Client side will start asking for > "git program" by default, but we can still override with --upload-pack > and friends. > > * 12 months after client side changes, everybody will be running that > version or newer. We stop installing the server side programs in > $(bindir) but people coming over ssh will be asking for "git program" > and "git" will be on the $PATH so there is no issue. > > The above 6 and 12 are yanked out of thin air and I am of course open to > tweaking them, but I think the above order of events would be workable. Is that really 6 and 12 months, or "6/12 months or at the next major release boundary, whichever is later". i.e., would make some of these changes as part of a minor dot release, such as having the client side change what it starts asking for in 1.6.3 or some such? Presumably the earliest that change would happen is 1.7, and the earliest to make the server side installation changes is 1.8, right? Or did you really mean a hard 6/12 months, regardless of release cycle issues? - Ted ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection 2008-06-25 13:06 ` [PATCH] Ask for "git program" when asking for "git-program" over SSH connection Theodore Tso @ 2008-06-25 17:42 ` Junio C Hamano 0 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-25 17:42 UTC (permalink / raw) To: Theodore Tso Cc: Shawn O. Pearce, しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git Theodore Tso <tytso@mit.edu> writes: > On Tue, Jun 24, 2008 at 10:27:07PM -0700, Junio C Hamano wrote: > ... >> The above 6 and 12 are yanked out of thin air and I am of course open to >> tweaking them, but I think the above order of events would be workable. > > Is that really 6 and 12 months, or "6/12 months or at the next major > release boundary, whichever is later". Sigh... I thought you by now knew me better than that... Yes, I didn't say it explicitly because I thought it was too obvious, which was a mistake. These except for the ones that are preparation (such as "prepare daemon so that future clients can ask with non-dash forms") need to happen at release boundaries, but these 6/12 months figures set the minimums. E.g. even if we had 6 week release cycles and 1.7.0 were to be done 6 weeks after 1.6.0, that is still too early for the client side to switch asking for "git program". ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection 2008-06-25 5:13 ` Junio C Hamano 2008-06-25 5:27 ` Junio C Hamano @ 2008-06-25 5:34 ` Shawn O. Pearce 2008-06-25 5:53 ` Junio C Hamano 1 sibling, 1 reply; 371+ messages in thread From: Shawn O. Pearce @ 2008-06-25 5:34 UTC (permalink / raw) To: Junio C Hamano Cc: しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git Junio C Hamano <gitster@pobox.com> wrote: > Junio C Hamano <gitster@pobox.com> writes: > > "Shawn O. Pearce" <spearce@spearce.org> writes: > > > >>> Any other suggestions that is workable? > >> > >> diff --git a/builtin-clone.c b/builtin-clone.c > >> index 5c5acb4..98d0f0f 100644 > >> --- a/builtin-clone.c > >> +++ b/builtin-clone.c > >> @@ -37,7 +37,7 @@ static int option_quiet, option_no_checkout, option_bare; > > > > << a patch to conditionally change "git-program" default to "git program" > > snipped >> Shouldn't "git upload-pack" work on the server side as far back as 0.99.9k? That's back really old. And my patch fixed "git " to be "git-" when talking to git-daemon, thus keeping clients compatible with all current git:// servers. For SSH servers that can't handle "git upload-pack" the user can change it to --upload-pack=git-upload-pack and get back to the old behavior, until the server operator can upgrade. Your patch doesn't offer that work around on the client side. > Typofix: s/cond/uncond/; > > > How would that help client that talk with git-daemon, unlike what I sent > > earlier? Check my change in git_connect again: diff --git a/connect.c b/connect.c index e92af29..dbabd93 100644 --- a/connect.c +++ b/connect.c @@ -576,8 +576,8 @@ struct child_process *git_connect(int fd[2], const char *url_orig, * from extended components with a NUL byte. */ packet_write(fd[1], - "%s %s%chost=%s%c", - prog, path, 0, + "git-%s %s%chost=%s%c", + prog + 4, path, 0, target_host, 0); free(target_host); free(url); Its buggy if the user tried to do "git ls-remote --upload-pack=crp git://" but if this is the direction we want to go we can obviously work out a better method of forcing "git " to be "git-" when talking to git-daemon. > If we force --upload-pack workaround to _everybody_ we are already lost. > > Also I think the previous one still lets you work it around by giving a > full path, like "/usr/local/bin/git-upload-pack", because "/usr" does not > match "git-" ;-) Please tell me, where is git-upload-pack on repo.or.cz? $ ssh repo.or.cz which git-upload-pack fatal: unrecognized command 'which git-upload-pack' I doubt I can pass it '/usr/local/bin/git-upload-pack' and get it to work too. So I don't think this is a good work around. Obviously pasky will fix repo.or.cz to accept both at some point in the near future, likely before 1.6.0 releases, because he's cool like that. Not everyone is. Please don't make 1.6.0 unavailable to end-users because their server operator can't currently accept "git upload-pack" without giving them a workaround to force "git-upload-pack" over SSH. -- Shawn. ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection 2008-06-25 5:34 ` Shawn O. Pearce @ 2008-06-25 5:53 ` Junio C Hamano 0 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-25 5:53 UTC (permalink / raw) To: Shawn O. Pearce Cc: しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git "Shawn O. Pearce" <spearce@spearce.org> writes: > Junio C Hamano <gitster@pobox.com> wrote: >> Junio C Hamano <gitster@pobox.com> writes: >> > "Shawn O. Pearce" <spearce@spearce.org> writes: >> > >> >>> Any other suggestions that is workable? >> >> >> >> diff --git a/builtin-clone.c b/builtin-clone.c >> >> index 5c5acb4..98d0f0f 100644 >> >> --- a/builtin-clone.c >> >> +++ b/builtin-clone.c >> >> @@ -37,7 +37,7 @@ static int option_quiet, option_no_checkout, option_bare; >> > >> > << a patch to conditionally change "git-program" default to "git program" >> > snipped >> > > Shouldn't "git upload-pack" work on the server side as far back as > 0.99.9k? Yeah, I missed the patch to connect.c that was buried among other changes. Sorry. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection 2008-06-25 4:44 ` Shawn O. Pearce 2008-06-25 5:09 ` Junio C Hamano @ 2008-06-25 5:30 ` Junio C Hamano 1 sibling, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-25 5:30 UTC (permalink / raw) To: Shawn O. Pearce Cc: しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git "Shawn O. Pearce" <spearce@spearce.org> writes: > Pasky also has to update: > > $ git ls-remote --upload-pack='git upload-pack' repo.or.cz:/srv/git/egit.git > fatal: unrecognized command 'git upload-pack '/srv/git/egit.git'' > fatal: The remote end hung up unexpectedly Of course. I am assuming that he runs git-shell for user account, and that's what the change in 'next' is about. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Keep some git-* programs in $(bindir) 2008-06-25 3:22 ` [PATCH] Keep some git-* programs in $(bindir) Junio C Hamano 2008-06-25 3:26 ` [PATCH] Ask for "git program" when asking for "git-program" over SSH connection Junio C Hamano @ 2008-06-25 4:17 ` Shawn O. Pearce 2008-06-25 4:19 ` Daniel Barkalow 2 siblings, 0 replies; 371+ messages in thread From: Shawn O. Pearce @ 2008-06-25 4:17 UTC (permalink / raw) To: Junio C Hamano Cc: しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git Junio C Hamano <gitster@pobox.com> wrote: > * しらいしななこ <nanako3@lavabit.com> writes: > > Doesn't "git archive --remote=<repo>" also execute git program on a remote machine? > > diff --git a/Makefile b/Makefile > index 929136b..742e7d3 100644 > --- a/Makefile > +++ b/Makefile > @@ -1268,7 +1268,7 @@ install: all > $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)' > $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)' > $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)' > - $(INSTALL) git$X '$(DESTDIR_SQ)$(bindir_SQ)' > + $(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-archive$X '$(DESTDIR_SQ)$(bindir_SQ)' I think you mean git-upload-archive, given what daemon.c says. Or line 34 of builtin-archive.c, which calls git-upload-archive by way of git_connect(). -- Shawn. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Keep some git-* programs in $(bindir) 2008-06-25 3:22 ` [PATCH] Keep some git-* programs in $(bindir) Junio C Hamano 2008-06-25 3:26 ` [PATCH] Ask for "git program" when asking for "git-program" over SSH connection Junio C Hamano 2008-06-25 4:17 ` [PATCH] Keep some git-* programs in $(bindir) Shawn O. Pearce @ 2008-06-25 4:19 ` Daniel Barkalow 2008-06-25 4:37 ` Shawn O. Pearce 2 siblings, 1 reply; 371+ messages in thread From: Daniel Barkalow @ 2008-06-25 4:19 UTC (permalink / raw) To: Junio C Hamano Cc: しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git On Tue, 24 Jun 2008, Junio C Hamano wrote: > Otherwise remote executions directly over ssh won't find them as they used > to. --upload-pack and --receive-pack options _could_ be used on the > client side, but things should keep working out-of-box for older clients. > > Later versions of clients (fetch-pack and send-pack) probably could start > asking for these programs with dashless form, but that is a different > topic. Should they use "git upload-pack" or should they look for their helper programs in a libexec dir? I don't think that either of these programs is useful to run independantly, but I don't know if finding a program that doesn't go in $PATH on a remote machine is going to be any fun. -Daniel *This .sig lefti ntentionally blank* ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Keep some git-* programs in $(bindir) 2008-06-25 4:19 ` Daniel Barkalow @ 2008-06-25 4:37 ` Shawn O. Pearce 0 siblings, 0 replies; 371+ messages in thread From: Shawn O. Pearce @ 2008-06-25 4:37 UTC (permalink / raw) To: Daniel Barkalow Cc: Junio C Hamano, しらいしななこ, Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git Daniel Barkalow <barkalow@iabervon.org> wrote: > On Tue, 24 Jun 2008, Junio C Hamano wrote: > > > Otherwise remote executions directly over ssh won't find them as they used > > to. --upload-pack and --receive-pack options _could_ be used on the > > client side, but things should keep working out-of-box for older clients. > > > > Later versions of clients (fetch-pack and send-pack) probably could start > > asking for these programs with dashless form, but that is a different > > topic. > > Should they use "git upload-pack" or should they look for their helper > programs in a libexec dir? I don't think that either of these programs is > useful to run independantly, but I don't know if finding a program that > doesn't go in $PATH on a remote machine is going to be any fun. IMHO they should in the future use "git upload-pack". But this may not work with all servers, especially those that use $SSH_ORIGINAL_COMMAND to dispatch to the correct command, or abort if the user tries to request something dangerous. Gitosis comes to mind. I'm not sure we can get away with doing this in 1.6.0 as it is effectively a network protocol breakage. We have thus far never caused a newer client to fail talking to an older server. I'm not sure we should start doing that in 1.6.0. My vote is we keep the dashed form of these 3 commands in the $PATH during 1.6 and remove them in 1.7, but when we do it we must ensure there is a way to still request dashed form found through $PATH when passing --upload-pack as an argument. -- Shawn. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-25 3:08 ` しらいしななこ 2008-06-25 3:22 ` [PATCH] Keep some git-* programs in $(bindir) Junio C Hamano @ 2008-06-25 3:26 ` Shawn O. Pearce 1 sibling, 0 replies; 371+ messages in thread From: Shawn O. Pearce @ 2008-06-25 3:26 UTC (permalink / raw) To: しらいしななこ, Junio C Hamano Cc: Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git <nanako3@lavabit.com> wrote: > Quoting Junio C Hamano <gitster@pobox.com>: > > Miklos Vajna <vmiklos@frugalware.org> writes: > >> On Tue, Jun 24, 2008 at 04:16:36PM -0700, Junio C Hamano <gitster@pobox.com> wrote: > >>> It most likely makes sense to do (3) anyway. upload-pack, receive-pack, > >>> anything else? > >> > >> I think that's all. > > > > Then that would be this patch on top of nd/dashless topic. > > > > Makefile | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/Makefile b/Makefile > > index 929136b..babf16b 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -1268,7 +1268,7 @@ install: all > > $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)' > > $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)' > > $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)' > > - $(INSTALL) git$X '$(DESTDIR_SQ)$(bindir_SQ)' > > + $(INSTALL) git$X git-upload-pack$X git-receive-pack$X '$(DESTDIR_SQ)$(bindir_SQ)' > > $(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install > > $(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install > > ifndef NO_TCLTK > > Doesn't "git archive --remote=<repo>" also execute git program on a remote machine? Yes, it runs git-upload-archive on the remote side. The three primary services for the remote side are documented in daemon.c: 403 static struct daemon_service daemon_service[] = { 404 { "upload-archive", "uploadarch", upload_archive, 0, 1 }, 405 { "upload-pack", "uploadpack", upload_pack, 1, 1 }, 406 { "receive-pack", "receivepack", receive_pack, 0, 1 }, 407 }; (with git- prefixes). IMHO all three need to be in $PATH, along with git and gitk, through at least a major revision release cycle to give clients a chance to upgrade to something that uses "git foo" rather than "git-foo" when talking to the remote. -- Shawn. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-24 23:16 ` Junio C Hamano 2008-06-24 23:32 ` Miklos Vajna @ 2008-06-25 0:11 ` Jakub Narebski 2008-06-25 3:32 ` Shawn O. Pearce 2008-06-25 7:29 ` Miklos Vajna 1 sibling, 2 replies; 371+ messages in thread From: Jakub Narebski @ 2008-06-25 0:11 UTC (permalink / raw) To: Junio C Hamano; +Cc: Miklos Vajna, Johannes Schindelin, Pieter de Bie, git Junio C Hamano <gitster@pobox.com> writes: > Ah, there is not much we can do in that case then. git-upload-pack is > what the client asks you to run, and if you do not have it in the path, > you can (1) either make sure it is on the path, (2) have the client be > more explicit when asking for git-upload-pack (--upload-pack=$where), or > (3) leave the minimum git-* binaries that can remotely be launched > directly in the usual $PATH. > > It most likely makes sense to do (3) anyway. upload-pack, receive-pack, > anything else? What does "git ls-remote server:/home/vmiklos/git/test" invoke on server? -- Jakub Narebski Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-25 0:11 ` Jakub Narebski @ 2008-06-25 3:32 ` Shawn O. Pearce 2008-06-25 7:29 ` Miklos Vajna 1 sibling, 0 replies; 371+ messages in thread From: Shawn O. Pearce @ 2008-06-25 3:32 UTC (permalink / raw) To: Jakub Narebski Cc: Junio C Hamano, Miklos Vajna, Johannes Schindelin, Pieter de Bie, git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-25 0:11 ` Jakub Narebski 2008-06-25 3:32 ` Shawn O. Pearce @ 2008-06-25 7:29 ` Miklos Vajna 1 sibling, 0 replies; 371+ messages in thread From: Miklos Vajna @ 2008-06-25 7:29 UTC (permalink / raw) To: Jakub Narebski; +Cc: Junio C Hamano, Johannes Schindelin, Pieter de Bie, git [-- Attachment #1: Type: text/plain, Size: 297 bytes --] On Tue, Jun 24, 2008 at 05:11:44PM -0700, Jakub Narebski <jnareb@gmail.com> wrote: > What does "git ls-remote server:/home/vmiklos/git/test" invoke on server? $ git ls-remote server:/home/vmiklos/git/test bash: git-upload-pack: command not found fatal: The remote end hung up unexpectedly [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-06-21 9:44 ` Junio C Hamano 2008-06-21 12:14 ` Miklos Vajna @ 2008-06-23 7:15 ` Junio C Hamano 2008-06-23 12:15 ` Miklos Vajna 2008-06-25 9:31 ` Junio C Hamano 1 sibling, 2 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-23 7:15 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-23 7:15 ` Junio C Hamano @ 2008-06-23 12:15 ` Miklos Vajna 2008-06-25 9:31 ` Junio C Hamano 1 sibling, 0 replies; 371+ messages in thread From: Miklos Vajna @ 2008-06-23 12:15 UTC (permalink / raw) To: Junio C Hamano; +Cc: git [-- Attachment #1: Type: text/plain, Size: 1242 bytes --] On Mon, Jun 23, 2008 at 12:15:35AM -0700, Junio C Hamano <gitster@pobox.com> wrote: > * mv/merge-in-c (Sat Jun 21 19:15:35 2008 +0200) 14 commits > - Add new test case to ensure git-merge reduces octopus parents when > possible > - Add new test case to ensure git-merge filters for independent > parents > - Build in merge > - Introduce reduce_heads() > - Introduce get_merge_bases_many() > - Add new test to ensure git-merge handles more than 25 refs. > - Introduce get_octopus_merge_bases() in commit.c > - git-fmt-merge-msg: make it usable from other builtins > - Move read_cache_unmerged() to read-cache.c > - parseopt: add a new PARSE_OPT_ARGV0_IS_AN_OPTION option > - Add new test to ensure git-merge handles pull.twohead and > pull.octopus > - Move parse-options's skip_prefix() to git-compat-util.h > - Move commit_list_count() to commit.c > - Move split_cmdline() to alias.c "Add new test case to ensure git-merge reduces octopus parents when possible" does exactly the same as "Add new test case to ensure git-merge filters for independent parents", so I think you should drop the later. Only the name of the test and the commit message differs, and I think we want to avoid redundancy in the testsuite. ;-) [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-06-23 7:15 ` Junio C Hamano 2008-06-23 12:15 ` Miklos Vajna @ 2008-06-25 9:31 ` Junio C Hamano 2008-06-29 8:50 ` [PATCH] Make default expiration period of reflog used for stash infinite Junio C Hamano ` (2 more replies) 1 sibling, 3 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-25 9:31 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* [PATCH] Make default expiration period of reflog used for stash infinite 2008-06-25 9:31 ` Junio C Hamano @ 2008-06-29 8:50 ` Junio C Hamano 2008-06-30 23:45 ` Olivier Marin 2008-06-29 8:50 ` [PATCH] Teach git-merge to pass -X<option> to the backend strategy module Junio C Hamano 2008-06-29 8:55 ` What's cooking in git.git (topics) Junio C Hamano 2 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-06-29 8:50 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH] Make default expiration period of reflog used for stash infinite 2008-06-29 8:50 ` [PATCH] Make default expiration period of reflog used for stash infinite Junio C Hamano @ 2008-06-30 23:45 ` Olivier Marin 2008-07-01 7:28 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Olivier Marin @ 2008-06-30 23:45 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Make default expiration period of reflog used for stash infinite 2008-06-30 23:45 ` Olivier Marin @ 2008-07-01 7:28 ` Junio C Hamano 2008-07-02 10:59 ` [PATCH] Disconnect stash from its base commit Nanako Shiraishi 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-01 7:28 UTC (permalink / raw) To: Olivier Marin; +Cc: git Olivier Marin <dkr+ml.git@free.fr> writes: > Junio C Hamano a écrit : >> This makes the default expiration period for the reflog that implements >> stash infinite. > > I did not read the whole thread so maybe I missed something but I though you > wanted to apply Nanako's patch before? > > The patch: http://article.gmane.org/gmane.comp.version-control.git/85055 Thanks for reminding, but I am of two minds about the change. (1) The change would untie the base tree of the stash from the history behind it and allow previously rewound tips of branches that these stashes were built on top of. Without the patch, these otherwise unreachable commits will never be reclaimed. (2) Today, you can say "git log stash" (note the lack of "-g" option) to view the history behind the stash through two artificial commits that stash creates. This will become impossible with the patch. Probably I am worrying too much; I do not personally think the second point matters in the real life. If "git log stash" _were_ any useful, it means the history behind the stash entries are not useless at all, but in that case the user would be using regular branches to store them anyway. ^ permalink raw reply [flat|nested] 371+ messages in thread
* [PATCH] Disconnect stash from its base commit 2008-07-01 7:28 ` Junio C Hamano @ 2008-07-02 10:59 ` Nanako Shiraishi 2008-07-02 13:51 ` Johannes Schindelin 0 siblings, 1 reply; 371+ messages in thread From: Nanako Shiraishi @ 2008-07-02 10:59 UTC (permalink / raw) To: Junio C Hamano; +Cc: Git Mailing List, Olivier Marin 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/ ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH] Disconnect stash from its base commit 2008-07-02 10:59 ` [PATCH] Disconnect stash from its base commit Nanako Shiraishi @ 2008-07-02 13:51 ` Johannes Schindelin 2008-07-02 19:01 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Johannes Schindelin @ 2008-07-02 13:51 UTC (permalink / raw) To: Nanako Shiraishi; +Cc: Junio C Hamano, Git Mailing List, Olivier Marin Hi, On Wed, 2 Jul 2008, Nanako Shiraishi wrote: > A stash records the state of the files in the working tree as a merge > between the HEAD and another commit that records the state of the index, > that in turn is a child commit of the HEAD commit. In order to later > apply (or pop) the stash, however, only the tree objects of these three > commits are necessary. > > This patch changes the structure of a stash to use a parentless new > commit that has the same tree as the HEAD commit, in place of the HEAD > commit. This way, a stash does not keep the history that leads to the > HEAD commit reachable, even if the stash is kept forever. May I register my suspicion that this is the wrong direction to go? I actually find it quite nice that I can easily see in gitk where I spawned off a certain stash, indeed, how the recent stash history (manually specified with "stash@{0} stash@{1} stash@{2}" [*1*]), relates to the current branch's history. Ciao, Dscho P.S.: I vaguely remember that I once wrote a patch to turn "stash@{0..2}" into exactly the same, but I do not remember why I did not follow up on it. Was it refuted, or unwanted? ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Disconnect stash from its base commit 2008-07-02 13:51 ` Johannes Schindelin @ 2008-07-02 19:01 ` Junio C Hamano 2008-07-02 19:54 ` Abhijit Menon-Sen 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-02 19:01 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Nanako Shiraishi, Git Mailing List, Olivier Marin Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> This patch changes the structure of a stash to use a parentless new >> commit that has the same tree as the HEAD commit, in place of the HEAD >> commit. This way, a stash does not keep the history that leads to the >> HEAD commit reachable, even if the stash is kept forever. > > May I register my suspicion that this is the wrong direction to go? > > I actually find it quite nice that I can easily see in gitk where I > spawned off a certain stash, indeed, how the recent stash history > (manually specified with "stash@{0} stash@{1} stash@{2}" [*1*]), relates > to the current branch's history. A stash may primarily be for applying the change to random place, but where it was created is not a useless information. The very original use case that was in the discussion "git stash" (actually its original form "git save") was first posted was "I am in the middle of something, and get interrupted. Stash the changes away to switch branches to deal with the emergency for a while so that I can later come back to where I was, and I want both saving away and coming back easy operations". A stash _can_ be applied to any random other state, but "coming back" is very much part of what it should have supported, and not recording the base commit means we would lose that capability. Side note. In addition to the current "stash apply" and "stash pop", "stash branch $stash newbranchname" that does git checkout -b newbranchanme $stash^ (i.e. create a new branch starting from the state you were in) might be a good ingredient to support a more git-like workflow to resume. If your original branch gained extra commits, was rewound, or was rebased during the emergency/distraction, you may not have anywhere to apply/pop the stash without conflicts when you want to "come back" with normal git checkout somebranch && git stash pop But that imaginary "stash branch" command would always give you the exact state you were in and creates a clean fork to finish what you were doing, and continue. So the base commit is an integral part of what a stash is, and I agree with you that an unexpiring stash that pins the whole history beind it is a feature. It is not unncessary cruft that accumulates that we need to worry about. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Disconnect stash from its base commit 2008-07-02 19:01 ` Junio C Hamano @ 2008-07-02 19:54 ` Abhijit Menon-Sen 2008-07-02 21:04 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Abhijit Menon-Sen @ 2008-07-02 19:54 UTC (permalink / raw) To: Junio C Hamano; +Cc: Nanako Shiraishi, git 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 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH] Disconnect stash from its base commit 2008-07-02 19:54 ` Abhijit Menon-Sen @ 2008-07-02 21:04 ` Junio C Hamano 2008-07-03 2:23 ` [PATCH] Implement "git stash branch <newbranch> <stash>" Abhijit Menon-Sen 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-02 21:04 UTC (permalink / raw) To: Abhijit Menon-Sen; +Cc: Nanako Shiraishi, git Abhijit Menon-Sen <ams@toroid.org> writes: > At 2008-07-02 12:01:35 -0700, gitster@pobox.com wrote: >> >> But that imaginary "stash branch" command would always give you >> the exact state you were in and creates a clean fork to finish >> what you were doing, and continue. > > Nice idea. Something as simple as the appended diff? > > I reversed the stash/branch arguments so that one need specify only the > branch name. Playing with it a little, it feels very useful. I'd further suggest to delete the stash automatically when you create a new branch out of it. ^ permalink raw reply [flat|nested] 371+ messages in thread
* [PATCH] Implement "git stash branch <newbranch> <stash>" 2008-07-02 21:04 ` Junio C Hamano @ 2008-07-03 2:23 ` Abhijit Menon-Sen 2008-07-03 4:12 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Abhijit Menon-Sen @ 2008-07-03 2:23 UTC (permalink / raw) To: Junio C Hamano; +Cc: Nanako Shiraishi, git 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 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH] Implement "git stash branch <newbranch> <stash>" 2008-07-03 2:23 ` [PATCH] Implement "git stash branch <newbranch> <stash>" Abhijit Menon-Sen @ 2008-07-03 4:12 ` Junio C Hamano 2008-07-03 6:16 ` Abhijit Menon-Sen 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-03 4:12 UTC (permalink / raw) To: Abhijit Menon-Sen; +Cc: Nanako Shiraishi, git Abhijit Menon-Sen <ams@toroid.org> writes: > +branch <branchname> [<stash>]:: > + > + Creates and checks out a new branch named `<branchname>` starting from > + the commit at which the `<stash>` was originally created, applies the > + changes recorded in `<stash>` to the new working tree, and drops the > + `<stash>` if that completes successfully. When no `<stash>` is given, > + applies the latest one. > ++ > +This is useful if the branch on which you ran `git stash save` has > +changed enough that `git stash apply` fails due to conflicts. Since > +the stash is applied on top of the commit that was HEAD at the time > +`git stash` was run, it restores the originally stashed state with > +no conflicts. Perhaps we would want to replay the stash always with --index for this application. By definition this will be conflict-free both in the index and in the working tree. I've also toyed with an idea to make <branchname> optional, and detach the HEAD if <branchname> is not given. It would be a useful mode of operation but one problem is that it is _not_ an operation that should be called "branch" anymore. ^ permalink raw reply [flat|nested] 371+ messages in thread
* [PATCH] Implement "git stash branch <newbranch> <stash>" 2008-07-03 4:12 ` Junio C Hamano @ 2008-07-03 6:16 ` Abhijit Menon-Sen 2008-07-06 11:23 ` [PATCH v3] " Abhijit Menon-Sen 0 siblings, 1 reply; 371+ messages in thread From: Abhijit Menon-Sen @ 2008-07-03 6:16 UTC (permalink / raw) To: Junio C Hamano; +Cc: Nanako Shiraishi, git 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 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH v3] Implement "git stash branch <newbranch> <stash>" 2008-07-03 6:16 ` Abhijit Menon-Sen @ 2008-07-06 11:23 ` Abhijit Menon-Sen 2008-07-06 12:54 ` Johannes Schindelin 0 siblings, 1 reply; 371+ messages in thread From: Abhijit Menon-Sen @ 2008-07-06 11:23 UTC (permalink / raw) To: Junio C Hamano; +Cc: Nanako Shiraishi, git 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 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH v3] Implement "git stash branch <newbranch> <stash>" 2008-07-06 11:23 ` [PATCH v3] " Abhijit Menon-Sen @ 2008-07-06 12:54 ` Johannes Schindelin 2008-07-06 14:45 ` [PATCH] Add a test for "git stash branch" Abhijit Menon-Sen 0 siblings, 1 reply; 371+ messages in thread From: Johannes Schindelin @ 2008-07-06 12:54 UTC (permalink / raw) To: Abhijit Menon-Sen; +Cc: Junio C Hamano, Nanako Shiraishi, git Hi, On Sun, 6 Jul 2008, Abhijit Menon-Sen wrote: > Restores the stashed state on a new branch rooted at the commit on which > the stash was originally created, so that conflicts caused by subsequent > changes on the original branch can be dealt with. > > (Thanks to Junio for this nice idea.) > > Signed-off-by: Abhijit Menon-Sen <ams@toroid.org> > --- > Reposting as requested with a new test included. AFAICS the previous version is in 'next' already: 656b50345239293929ad8c639c5f1941c6b867ad Hth, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* [PATCH] Add a test for "git stash branch" 2008-07-06 12:54 ` Johannes Schindelin @ 2008-07-06 14:45 ` Abhijit Menon-Sen 2008-07-06 19:53 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Abhijit Menon-Sen @ 2008-07-06 14:45 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, Nanako Shiraishi, git 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 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH] Add a test for "git stash branch" 2008-07-06 14:45 ` [PATCH] Add a test for "git stash branch" Abhijit Menon-Sen @ 2008-07-06 19:53 ` Junio C Hamano 2008-07-06 21:20 ` [PATCH v2] " Abhijit Menon-Sen 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-06 19:53 UTC (permalink / raw) To: Abhijit Menon-Sen; +Cc: Johannes Schindelin, Nanako Shiraishi, git Abhijit Menon-Sen <ams@toroid.org> writes: > At 2008-07-06 14:54:44 +0200, Johannes.Schindelin@gmx.de wrote: >> >> AFAICS the previous version is in 'next' already: >> 656b50345239293929ad8c639c5f1941c6b867ad > > Oh, I see, thanks. I misunderstood the request. Here's a separate patch > to just add the test. Oh, there is no misunderstanding. You couldn't have possibly known if the main body of the patch will go to 'next' or just be dropped when I said "you might also want to have tests" to you. > +test_expect_success 'stash apply' ' > + echo foo > file && > + git commit file -m first > + echo bar > file && > + git stash && > + echo baz > file && > + git commit file -m second && > + git stash branch stashbranch && > + git commit file -m alternate\ second && > + git diff master..stashbranch > output && > + test_cmp output expect && > + test 0 = $(git stash list | wc -l) > +' The title is probably not 'stash apply' but 'stash branch'. Don't you want to also validate that: - "stash branch" command switched to the new branch "stashbranch"? - before making "alternate second", the index and the working tree have expected contents? and - the final shape of the history looks correctly forked (i.e. "stashbranch" branches at the commit before "-m second" commit was made)? > test_done > -- > 1.5.6 ^ permalink raw reply [flat|nested] 371+ messages in thread
* [PATCH v2] Add a test for "git stash branch" 2008-07-06 19:53 ` Junio C Hamano @ 2008-07-06 21:20 ` Abhijit Menon-Sen 0 siblings, 0 replies; 371+ messages in thread From: Abhijit Menon-Sen @ 2008-07-06 21:20 UTC (permalink / raw) To: Junio C Hamano; +Cc: Johannes Schindelin, Nanako Shiraishi, git 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 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH] Teach git-merge to pass -X<option> to the backend strategy module 2008-06-25 9:31 ` Junio C Hamano 2008-06-29 8:50 ` [PATCH] Make default expiration period of reflog used for stash infinite Junio C Hamano @ 2008-06-29 8:50 ` Junio C Hamano 2008-06-29 10:32 ` Jakub Narebski 2008-06-29 8:55 ` What's cooking in git.git (topics) Junio C Hamano 2 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-06-29 8:50 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH] Teach git-merge to pass -X<option> to the backend strategy module 2008-06-29 8:50 ` [PATCH] Teach git-merge to pass -X<option> to the backend strategy module Junio C Hamano @ 2008-06-29 10:32 ` Jakub Narebski 2008-06-29 19:09 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Jakub Narebski @ 2008-06-29 10:32 UTC (permalink / raw) To: git Junio C Hamano wrote: > diff --git a/git-merge.sh b/git-merge.sh > index 39b5cd9..d475852 100755 > --- a/git-merge.sh > +++ b/git-merge.sh > @@ -17,6 +17,7 @@ commit perform a commit if the merge succeeds (default) > ff allow fast forward (default) > s,strategy= merge strategy to use > m,message= message to be used for the merge commit (if any) > +X= pass merge strategy specific options > " You have updated usage for git-merge, but didn't update manpages (Documentation). -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Teach git-merge to pass -X<option> to the backend strategy module 2008-06-29 10:32 ` Jakub Narebski @ 2008-06-29 19:09 ` Junio C Hamano 0 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-29 19:09 UTC (permalink / raw) To: Jakub Narebski; +Cc: git Jakub Narebski <jnareb@gmail.com> writes: > Junio C Hamano wrote: > >> diff --git a/git-merge.sh b/git-merge.sh >> index 39b5cd9..d475852 100755 >> --- a/git-merge.sh >> +++ b/git-merge.sh >> @@ -17,6 +17,7 @@ commit perform a commit if the merge succeeds (default) >> ff allow fast forward (default) >> s,strategy= merge strategy to use >> m,message= message to be used for the merge commit (if any) >> +X= pass merge strategy specific options >> " > > You have updated usage for git-merge, but didn't update manpages > (Documentation). Patches welcome ;-) ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-25 9:31 ` Junio C Hamano 2008-06-29 8:50 ` [PATCH] Make default expiration period of reflog used for stash infinite Junio C Hamano 2008-06-29 8:50 ` [PATCH] Teach git-merge to pass -X<option> to the backend strategy module Junio C Hamano @ 2008-06-29 8:55 ` Junio C Hamano 2008-06-29 18:35 ` Linus Torvalds ` (3 more replies) 2 siblings, 4 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-29 8:55 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-29 8:55 ` What's cooking in git.git (topics) Junio C Hamano @ 2008-06-29 18:35 ` Linus Torvalds 2008-06-29 19:08 ` Junio C Hamano 2008-06-29 20:11 ` Junio C Hamano 2008-06-30 3:30 ` Jeff King ` (2 subsequent siblings) 3 siblings, 2 replies; 371+ messages in thread From: Linus Torvalds @ 2008-06-29 18:35 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-29 18:35 ` Linus Torvalds @ 2008-06-29 19:08 ` Junio C Hamano 2008-06-29 20:11 ` Junio C Hamano 1 sibling, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-29 19:08 UTC (permalink / raw) To: Linus Torvalds; +Cc: git Linus Torvalds <torvalds@linux-foundation.org> writes: > Maybe just say > > * Do not install all git subcommands as 'git-xyzzy' files in the user > path. This avoids unnecessary hardlinks (or copies on systems that do > not support links), and enforces the 'git xyzzy' syntax. > > Subcommands that aren't builtins now get installed in > /usr/libexec/git-core/ or somesuch. Thanks. > (I haven't looked at the series, but I _assume_ it also avoids installing > the builtin subcommands entirely when not necessary, ie "git-cat-file" > really _is_ gone, but it's not because the "cat-file" command itself is > gone). It is actually a fairly long road ahead. In 1.6.0, most of them will be moved to /usr/libexec/git-core/, so that really old scripts end users may have can be more easily kept working by simply saying: PATH=$(git --exec-path):$PATH early, without doing "s/git-/git /g". Current git clients run git-upload-pack and friends in "git-xyzzy" form when accessing remote repositories directly over ssh, so in 1.6.0 we will have to leave these server side programs in $(bindir) as well. git-shell and gitosis is being updated to accept "git upload-pack" form as well, and after older versions of these programs die out, we can update the clients to ask for remote side programs without dash. None of the server side programs is built-in, so we could start the hardlink removal independent from this transition (iow, "Only subcommands that aren't builtin will be installed in libexec, builtins are not on the disk anywhere" could happen now), but I'd prefer to keep changes in each steps small to minimize impacts to the end users' environments. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-29 18:35 ` Linus Torvalds 2008-06-29 19:08 ` Junio C Hamano @ 2008-06-29 20:11 ` Junio C Hamano 2008-06-29 20:15 ` Pieter de Bie 1 sibling, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-06-29 20:11 UTC (permalink / raw) To: Linus Torvalds; +Cc: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-29 20:11 ` Junio C Hamano @ 2008-06-29 20:15 ` Pieter de Bie 2008-06-29 21:57 ` Johannes Schindelin 2008-06-29 22:00 ` Steffen Prohaska 0 siblings, 2 replies; 371+ messages in thread From: Pieter de Bie @ 2008-06-29 20:15 UTC (permalink / raw) To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailinglist On 29 jun 2008, at 22:11, Junio C Hamano wrote: > use of them from your scripts after adding > output from "git --exec-path" to the $PATH will still be supported > in > 1.6.0, but users are again strongly encouraged to adjust their > scripts to use "git xyzzy" form, as we will stop installing > "git-xyzzy" hardlinks for built-in commands in later releases. I think msysgit doesn't (didn't?) install the hardlinks to conserve space, as Windows doesn't support hard links. Perhaps we should mention that as well? - Pieter ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-29 20:15 ` Pieter de Bie @ 2008-06-29 21:57 ` Johannes Schindelin 2008-06-29 22:00 ` Steffen Prohaska 1 sibling, 0 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-06-29 21:57 UTC (permalink / raw) To: Pieter de Bie; +Cc: Junio C Hamano, Linus Torvalds, Git Mailinglist Hi, On Sun, 29 Jun 2008, Pieter de Bie wrote: > On 29 jun 2008, at 22:11, Junio C Hamano wrote: > > > use of them from your scripts after adding output from "git > > --exec-path" to the $PATH will still be supported in 1.6.0, but users > > are again strongly encouraged to adjust their scripts to use "git > > xyzzy" form, as we will stop installing "git-xyzzy" hardlinks for > > built-in commands in later releases. > > I think msysgit doesn't (didn't?) install the hardlinks to conserve > space, as Windows doesn't support hard links. Please do not spread FUD. Where available, we install hardlinks. And even if we did not, given that we do not yet actively support MinGW, I think your suggestion is a bit early, to say the least. Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-29 20:15 ` Pieter de Bie 2008-06-29 21:57 ` Johannes Schindelin @ 2008-06-29 22:00 ` Steffen Prohaska 1 sibling, 0 replies; 371+ messages in thread From: Steffen Prohaska @ 2008-06-29 22:00 UTC (permalink / raw) To: Pieter de Bie; +Cc: Junio C Hamano, Linus Torvalds, Git Mailinglist On Jun 29, 2008, at 10:15 PM, Pieter de Bie wrote: > > On 29 jun 2008, at 22:11, Junio C Hamano wrote: > >> use of them from your scripts after adding >> output from "git --exec-path" to the $PATH will still be supported >> in >> 1.6.0, but users are again strongly encouraged to adjust their >> scripts to use "git xyzzy" form, as we will stop installing >> "git-xyzzy" hardlinks for built-in commands in later releases. > > I think msysgit doesn't (didn't?) install the hardlinks to conserve > space, > as Windows doesn't support hard links. Perhaps we should mention that > as well? Windows does support hardlinks and msysgit uses them. Steffen ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-29 8:55 ` What's cooking in git.git (topics) Junio C Hamano 2008-06-29 18:35 ` Linus Torvalds @ 2008-06-30 3:30 ` Jeff King 2008-06-30 5:31 ` Junio C Hamano 2008-06-30 9:08 ` Junio C Hamano 2008-06-30 14:59 ` Brandon Casey 3 siblings, 1 reply; 371+ messages in thread From: Jeff King @ 2008-06-30 3:30 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Sun, Jun 29, 2008 at 01:55:13AM -0700, Junio C Hamano wrote: > * jk/maint-fetch-ref-hier (Thu Jun 26 23:59:50 2008 -0400) 1 commit > + fetch: report local storage errors in status table > > When the remote used to have "foo" branch but now has "foo/bar", fetch > refuses to delete the existing remote tracking branch "foo" to create a > new remote tracking branch "foo/bar", but the error message was > confusing. Where do we want to take this? The conversation went something like: me: here's a patch where we hint about "remote prune" you: why not just fix the refs, it's no worse than a rewind me: we kill reflogs, so it is different than a rewind you: oh, right So I'm not sure if that was "Oh, right, it's not a good idea to remove the conflicting ref" or "Oh, right, but it's probably still fine." -Peff ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-30 3:30 ` Jeff King @ 2008-06-30 5:31 ` Junio C Hamano 2008-06-30 5:33 ` Jeff King 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-06-30 5:31 UTC (permalink / raw) To: Jeff King; +Cc: git Jeff King <peff@peff.net> writes: > On Sun, Jun 29, 2008 at 01:55:13AM -0700, Junio C Hamano wrote: > >> * jk/maint-fetch-ref-hier (Thu Jun 26 23:59:50 2008 -0400) 1 commit >> + fetch: report local storage errors in status table >> >> When the remote used to have "foo" branch but now has "foo/bar", fetch >> refuses to delete the existing remote tracking branch "foo" to create a >> new remote tracking branch "foo/bar", but the error message was >> confusing. > > Where do we want to take this? The conversation went something like: > > me: here's a patch where we hint about "remote prune" > you: why not just fix the refs, it's no worse than a rewind > me: we kill reflogs, so it is different than a rewind > you: oh, right > > So I'm not sure if that was "Oh, right, it's not a good idea to remove > the conflicting ref" or "Oh, right, but it's probably still fine." It is "Oh right, it is Ok. Let's cook it in 'next', have it in 'master' and then backmerge to 'maint'". ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-30 5:31 ` Junio C Hamano @ 2008-06-30 5:33 ` Jeff King 2008-06-30 5:38 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Jeff King @ 2008-06-30 5:33 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Sun, Jun 29, 2008 at 10:31:00PM -0700, Junio C Hamano wrote: > > Where do we want to take this? The conversation went something like: > > > > me: here's a patch where we hint about "remote prune" > > you: why not just fix the refs, it's no worse than a rewind > > me: we kill reflogs, so it is different than a rewind > > you: oh, right > > > > So I'm not sure if that was "Oh, right, it's not a good idea to remove > > the conflicting ref" or "Oh, right, but it's probably still fine." > > It is "Oh right, it is Ok. Let's cook it in 'next', have it in 'master' > and then backmerge to 'maint'". Sorry if I'm being slow, but what is "it" here? The "warning" patch I sent, or a to-be-posted patch that deletes the conflicting ref? -Peff ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-30 5:33 ` Jeff King @ 2008-06-30 5:38 ` Junio C Hamano 0 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-30 5:38 UTC (permalink / raw) To: Jeff King; +Cc: git Jeff King <peff@peff.net> writes: > On Sun, Jun 29, 2008 at 10:31:00PM -0700, Junio C Hamano wrote: > >> > Where do we want to take this? The conversation went something like: >> > >> > me: here's a patch where we hint about "remote prune" >> > you: why not just fix the refs, it's no worse than a rewind >> > me: we kill reflogs, so it is different than a rewind >> > you: oh, right >> > >> > So I'm not sure if that was "Oh, right, it's not a good idea to remove >> > the conflicting ref" or "Oh, right, but it's probably still fine." >> >> It is "Oh right, it is Ok. Let's cook it in 'next', have it in 'master' >> and then backmerge to 'maint'". > > Sorry if I'm being slow, but what is "it" here? The "warning" patch I > sent, or a to-be-posted patch that deletes the conflicting ref? Sorry, my fingers outpaced my brain and gave you gibberish. Oh right, we should hint about "remote prune" and stop there, at least for now, as it is not nice to just delete the refs and lose their reflogs without user's consent. ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-06-29 8:55 ` What's cooking in git.git (topics) Junio C Hamano 2008-06-29 18:35 ` Linus Torvalds 2008-06-30 3:30 ` Jeff King @ 2008-06-30 9:08 ` Junio C Hamano 2008-06-30 11:19 ` How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics)) Steffen Prohaska ` (3 more replies) 2008-06-30 14:59 ` Brandon Casey 3 siblings, 4 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-30 9:08 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics)) 2008-06-30 9:08 ` Junio C Hamano @ 2008-06-30 11:19 ` Steffen Prohaska 2008-06-30 18:47 ` [msysGit] " Johannes Sixt 2008-06-30 14:09 ` What's cooking in git.git (topics) Kristian Høgsberg ` (2 subsequent siblings) 3 siblings, 1 reply; 371+ messages in thread From: Steffen Prohaska @ 2008-06-30 11:19 UTC (permalink / raw) To: msysGit, Junio C Hamano, Johannes Sixt; +Cc: Git Mailing List 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(-) ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [msysGit] How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics)) 2008-06-30 11:19 ` How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics)) Steffen Prohaska @ 2008-06-30 18:47 ` Johannes Sixt 2008-07-01 0:03 ` Clifford Caoile 2008-07-02 8:31 ` Steffen Prohaska 0 siblings, 2 replies; 371+ messages in thread From: Johannes Sixt @ 2008-06-30 18:47 UTC (permalink / raw) To: prohaska; +Cc: msysGit, Junio C Hamano, Git Mailing List On Montag, 30. Juni 2008, Steffen Prohaska wrote: > On Jun 30, 2008, at 11:08 AM, Junio C Hamano wrote: > > * MinGW will be in. > > If this is done, we should be able to create the msysgit release > directly > from Junio's master. Hannes changes alone, however, are not sufficient, > because some commits have been parked in 4msysgit. Now that MinGW is > on Junio's next and Junio's next is also on 4msysgit's next, it it easy > to see how much is left to do by running: > > git diff --stat junio/next..4msysgit/next > > junio is a remote pointing to git://git.kernel.org/pub/scm/git/git.git. > 4msysgit is a remote pointing to git://repo.or.cz/git/mingw/ > 4msysgit.git. > I attached the output below. > > How should we proceed to get rid of the differences? > > Should we prepare and send patches directly to the official git list > now? > Should we wait until the first MinGW branch is on master? > Should we prepare a whole patch series? Maybe Hannes would maintain > this > patch series. Until 1.6.0 is released, a number of _required_ patches will have to be included. There are two sorts of them: * Patches that touch generic code, like replacing c == '/' by is_dir_sep(c). * Patches that are purly Windows specific. The former I intend to submit to the mailing list directly and as soon as possible (but if I can intervene on newly submitted patches early so that a fixup is not even necessary, then even better). The latter I intend to collect in a branch and submit as a batch. Let's see how this works out. Then there are the extra patches in 4msysgit. From my POV, they are not _required_ because I can appearently work with git on Windows without them. I think some of them are not necessary. Can we go through them again? And then there are the patches to the t/ directory. I do not target them for 1.6.0, but I do want to prepare another series with them. -- Hannes ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics)) 2008-06-30 18:47 ` [msysGit] " Johannes Sixt @ 2008-07-01 0:03 ` Clifford Caoile 2008-07-02 8:31 ` Steffen Prohaska 1 sibling, 0 replies; 371+ messages in thread From: Clifford Caoile @ 2008-07-01 0:03 UTC (permalink / raw) To: johannes.sixt; +Cc: prohaska, msysGit, Junio C Hamano, Git Mailing List Hi: On Tue, Jul 1, 2008 at 3:47 AM, Johannes Sixt <johannes.sixt@telecom.at> wrote: > > On Montag, 30. Juni 2008, Steffen Prohaska wrote: >> On Jun 30, 2008, at 11:08 AM, Junio C Hamano wrote: >> > * MinGW will be in. >> >> How should we proceed to get rid of the differences? > ... > Then there are the extra patches in 4msysgit. From my POV, they are not > _required_ because I can appearently work with git on Windows without them. I > think some of them are not necessary. Can we go through them again? As one of the extra patches in 4msysgit, there is the cca/git.el branch [1] which I contributed [2] previously for Emacs git.el users on Windows. However I have not gotten any feedback whatsoever, so perhaps parking it in 4msysgit is not appropriate. I plan to separately to host these patch(es). Please ignore it or remove it at your convenience. References: [1] http://repo.or.cz/w/git/mingw/4msysgit.git?a=shortlog;h=refs/heads/cca/git.el [2] http://thread.gmane.org/gmane.comp.version-control.msysgit/2140 Best regards, Clifford Caoile ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics)) 2008-06-30 18:47 ` [msysGit] " Johannes Sixt 2008-07-01 0:03 ` Clifford Caoile @ 2008-07-02 8:31 ` Steffen Prohaska 2008-07-02 8:32 ` [PATCH 01/12] Fake reencoding success under NO_ICONV instead of returning NULL Steffen Prohaska 1 sibling, 1 reply; 371+ messages in thread From: Steffen Prohaska @ 2008-07-02 8:31 UTC (permalink / raw) To: Johannes Sixt; +Cc: msysGit, Junio C Hamano, Git Mailing List On Jun 30, 2008, at 8:47 PM, Johannes Sixt wrote: > Then there are the extra patches in 4msysgit. From my POV, they are > not > _required_ because I can appearently work with git on Windows > without them. I > think some of them are not necessary. Can we go through them again? I'll send a patch series in reply to this mail that contains the following patches: [PATCH 01/12] Fake reencoding success under NO_ICONV instead of returning NULL. [PATCH 02/12] Do not complain about "no common commits" in an empty repo [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds. [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) [PATCH 07/12] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it. [PATCH 09/12] We need to check for msys as well as Windows in add-- interactive. [PATCH 10/12] Add ANSI control code emulation for the Windows console [PATCH 11/12] verify_path(): do not allow absolute paths [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next This series would bring *.{c,h,sh,perl} on Junio's next to 4msysgit/ next, except for some minor differences (whitespace, comments, a workaround in git-parse-remote.sh). Steffen ^ permalink raw reply [flat|nested] 371+ messages in thread
* [PATCH 01/12] Fake reencoding success under NO_ICONV instead of returning NULL. 2008-07-02 8:31 ` Steffen Prohaska @ 2008-07-02 8:32 ` Steffen Prohaska 2008-07-02 8:32 ` [PATCH 02/12] Do not complain about "no common commits" in an empty repo Steffen Prohaska 2008-07-02 18:43 ` [PATCH 01/12] Fake reencoding success under NO_ICONV instead of returning NULL Johannes Sixt 0 siblings, 2 replies; 371+ messages in thread From: Steffen Prohaska @ 2008-07-02 8:32 UTC (permalink / raw) To: Johannes Sixt Cc: git, msysgit, Junio C Hamano, Johannes Sixt, Steffen Prohaska From: Johannes Sixt <johannes.sixt@telecom.at> git-am when invoked from git-rebase seems to rely on successful conversion. Signed-off-by: Steffen Prohaska <prohaska@zib.de> --- utf8.c | 7 +++++++ utf8.h | 4 ---- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/utf8.c b/utf8.c index dc37353..b07d43e 100644 --- a/utf8.c +++ b/utf8.c @@ -388,4 +388,11 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e iconv_close(conv); return out; } +#else +char *reencode_string(const char *in, const char *out_encoding, const char *in_encoding) +{ + if (!in_encoding) + return NULL; + return xstrdup(in); +} #endif diff --git a/utf8.h b/utf8.h index 98cce1b..f22ef31 100644 --- a/utf8.h +++ b/utf8.h @@ -10,10 +10,6 @@ int is_encoding_utf8(const char *name); int print_wrapped_text(const char *text, int indent, int indent2, int len); -#ifndef NO_ICONV char *reencode_string(const char *in, const char *out_encoding, const char *in_encoding); -#else -#define reencode_string(a,b,c) NULL -#endif #endif -- 1.5.6.1.255.g32571 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH 02/12] Do not complain about "no common commits" in an empty repo 2008-07-02 8:32 ` [PATCH 01/12] Fake reencoding success under NO_ICONV instead of returning NULL Steffen Prohaska @ 2008-07-02 8:32 ` Steffen Prohaska 2008-07-02 8:32 ` [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures Steffen Prohaska 2008-07-02 8:58 ` [PATCH 02/12] Do not complain about "no common commits" in an empty repo Junio C Hamano 2008-07-02 18:43 ` [PATCH 01/12] Fake reencoding success under NO_ICONV instead of returning NULL Johannes Sixt 1 sibling, 2 replies; 371+ messages in thread From: Steffen Prohaska @ 2008-07-02 8:32 UTC (permalink / raw) To: Johannes Sixt Cc: git, msysgit, Junio C Hamano, Johannes Schindelin, Steffen Prohaska From: Johannes Schindelin <johannes.schindelin@gmx.de> If the repo is empty, we know that already, thank you very much. So shut fetch-pack up about that case. Fixes issue 3, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Steffen Prohaska <prohaska@zib.de> --- builtin-fetch-pack.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c index f4dbcf0..2175c6d 100644 --- a/builtin-fetch-pack.c +++ b/builtin-fetch-pack.c @@ -309,7 +309,8 @@ done: } flushes--; } - return retval; + /* it is no error to fetch into a completely empty repo */ + return count ? retval : 0; } static struct commit_list *complete; -- 1.5.6.1.255.g32571 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures 2008-07-02 8:32 ` [PATCH 02/12] Do not complain about "no common commits" in an empty repo Steffen Prohaska @ 2008-07-02 8:32 ` Steffen Prohaska 2008-07-02 8:32 ` [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds Steffen Prohaska 2008-07-02 18:46 ` [msysGit] [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures Johannes Sixt 2008-07-02 8:58 ` [PATCH 02/12] Do not complain about "no common commits" in an empty repo Junio C Hamano 1 sibling, 2 replies; 371+ messages in thread From: Steffen Prohaska @ 2008-07-02 8:32 UTC (permalink / raw) To: Johannes Sixt Cc: git, msysgit, Junio C Hamano, Johannes Schindelin, Steffen Prohaska From: Johannes Schindelin <johannes.schindelin@gmx.de> On Windows, gpg outputs CR/LF signatures. But since the tag messages are already stripped of the CR by stripspace(), it is arguably nicer to do the same for the tag signature. Actually, this patch does not look for CR/LF, but strips all CRs from the signature. [ spr: ported code to use strbuf ] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Steffen Prohaska <prohaska@zib.de> --- builtin-tag.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/builtin-tag.c b/builtin-tag.c index e675206..77977ba 100644 --- a/builtin-tag.c +++ b/builtin-tag.c @@ -241,6 +241,20 @@ static int do_sign(struct strbuf *buffer) if (finish_command(&gpg) || !len || len < 0) return error("gpg failed to sign the tag"); +#ifdef __MINGW32__ + /* strip CR from the line endings */ + { + int i, j; + for (i = j = 0; i < buffer->len; i++) + if (buffer->buf[i] != '\r') { + if (i != j) + buffer->buf[j] = buffer->buf[i]; + j++; + } + strbuf_setlen(buffer, j); + } +#endif + return 0; } -- 1.5.6.1.255.g32571 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds. 2008-07-02 8:32 ` [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures Steffen Prohaska @ 2008-07-02 8:32 ` Steffen Prohaska 2008-07-02 8:32 ` [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser Steffen Prohaska 2008-07-02 9:22 ` [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds Junio C Hamano 2008-07-02 18:46 ` [msysGit] [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures Johannes Sixt 1 sibling, 2 replies; 371+ messages in thread From: Steffen Prohaska @ 2008-07-02 8:32 UTC (permalink / raw) To: Johannes Sixt Cc: git, msysgit, Junio C Hamano, Marius Storm-Olsen, Steffen Prohaska From: Marius Storm-Olsen <mstormo_git@storm-olsen.com> SIGPIPE isn't supported in MinGW. Signed-off-by: Marius Storm-Olsen <mstormo_git@storm-olsen.com> Signed-off-by: Steffen Prohaska <prohaska@zib.de> --- builtin-verify-tag.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/builtin-verify-tag.c b/builtin-verify-tag.c index 92eaa89..540e3b9 100644 --- a/builtin-verify-tag.c +++ b/builtin-verify-tag.c @@ -100,9 +100,11 @@ int cmd_verify_tag(int argc, const char **argv, const char *prefix) i++; } +#ifndef __MINGW32__ /* sometimes the program was terminated because this signal * was received in the process of writing the gpg input: */ signal(SIGPIPE, SIG_IGN); +#endif while (i < argc) if (verify_tag(argv[i++], verbose)) had_error = 1; -- 1.5.6.1.255.g32571 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser 2008-07-02 8:32 ` [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds Steffen Prohaska @ 2008-07-02 8:32 ` Steffen Prohaska 2008-07-02 8:32 ` [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) Steffen Prohaska ` (2 more replies) 2008-07-02 9:22 ` [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds Junio C Hamano 1 sibling, 3 replies; 371+ messages in thread From: Steffen Prohaska @ 2008-07-02 8:32 UTC (permalink / raw) To: Johannes Sixt; +Cc: git, msysgit, Junio C Hamano, Steffen Prohaska The implementation directly calls the Win32 API to launch the browser. Note that the specific directory layout of msysgit is required. Signed-off-by: Steffen Prohaska <prohaska@zib.de> --- cache.h | 2 ++ help.c | 28 ++++++++++++++++++++++++++++ path.c | 13 +++++++++++++ 3 files changed, 43 insertions(+), 0 deletions(-) diff --git a/cache.h b/cache.h index 0d8edda..958d257 100644 --- a/cache.h +++ b/cache.h @@ -529,6 +529,8 @@ const char *make_nonrelative_path(const char *path); const char *make_relative_path(const char *abs, const char *base); int normalize_absolute_path(char *buf, const char *path); int longest_ancestor_length(const char *path, const char *prefix_list); +/* Convert slashes to backslashes on Windows. */ +char *make_native_separator(char *path); /* Read and unpack a sha1 file into memory, write memory to a sha1 file */ extern int sha1_object_info(const unsigned char *, unsigned long *); diff --git a/help.c b/help.c index ca9632b..811f8db 100644 --- a/help.c +++ b/help.c @@ -9,6 +9,7 @@ #include "common-cmds.h" #include "parse-options.h" #include "run-command.h" +#include "dir.h" static struct man_viewer_list { struct man_viewer_list *next; @@ -28,7 +29,11 @@ enum help_format { }; static int show_all = 0; +#ifdef __MINGW32__ +static enum help_format help_format = HELP_FORMAT_WEB; +#else static enum help_format help_format = HELP_FORMAT_MAN; +#endif static struct option builtin_help_options[] = { OPT_BOOLEAN('a', "all", &show_all, "print all available commands"), OPT_SET_INT('m', "man", &help_format, "show man page", HELP_FORMAT_MAN), @@ -644,12 +649,35 @@ static void get_html_page_path(struct strbuf *page_path, const char *page) static void show_html_page(const char *git_cmd) { +#ifdef __MINGW32__ + const char* exec_path = git_exec_path(); + char *htmlpath = make_native_separator( + mkpath("%s/../doc/git/html/%s.html" + , exec_path + , git_cmd) + ); + if (!file_exists(htmlpath)) { + htmlpath = make_native_separator( + mkpath("%s/../doc/git/html/git-%s.html" + , exec_path + , git_cmd) + ); + if (!file_exists(htmlpath)) { + fprintf(stderr, "Can't find HTML help for '%s'.\n" + , git_cmd); + exit(1); + } + } + printf("Launching default browser to display HTML help ...\n"); + ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0); +#else const char *page = cmd_to_page(git_cmd); struct strbuf page_path; /* it leaks but we exec bellow */ get_html_page_path(&page_path, page); execl_git_cmd("web--browse", "-c", "help.browser", page_path.buf, NULL); +#endif } void help_unknown_cmd(const char *cmd) diff --git a/path.c b/path.c index 5983255..2a4a76a 100644 --- a/path.c +++ b/path.c @@ -439,3 +439,16 @@ int longest_ancestor_length(const char *path, const char *prefix_list) return max_len; } + +char *make_native_separator(char* path) { +#ifdef __MINGW32__ + char* c; + for (c = path; *c; c++) { + if (*c == '/') + *c = '\\'; + } + return path; +#else + return path; +#endif +} -- 1.5.6.1.255.g32571 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) 2008-07-02 8:32 ` [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser Steffen Prohaska @ 2008-07-02 8:32 ` Steffen Prohaska 2008-07-02 8:32 ` [PATCH 07/12] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable Steffen Prohaska 2008-07-02 19:04 ` [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) Johannes Sixt 2008-07-02 9:11 ` [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser Junio C Hamano 2008-07-02 18:57 ` Johannes Sixt 2 siblings, 2 replies; 371+ messages in thread From: Steffen Prohaska @ 2008-07-02 8:32 UTC (permalink / raw) To: Johannes Sixt Cc: git, msysgit, Junio C Hamano, Edward Z. Yang, Steffen Prohaska From: Edward Z. Yang <edwardzyang@thewritingpot.com> PuTTY requires -P while OpenSSH requires -p; if plink is detected as GIT_SSH, use the alternate flag. Signed-off-by: Edward Z. Yang <edwardzyang@thewritingpot.com> Signed-off-by: Steffen Prohaska <prohaska@zib.de> --- connect.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/connect.c b/connect.c index 574f42f..0d007f3 100644 --- a/connect.c +++ b/connect.c @@ -599,11 +599,13 @@ struct child_process *git_connect(int fd[2], const char *url_orig, conn->argv = arg = xcalloc(6, sizeof(*arg)); if (protocol == PROTO_SSH) { const char *ssh = getenv("GIT_SSH"); + int putty = ssh && strstr(ssh, "plink"); if (!ssh) ssh = "ssh"; *arg++ = ssh; if (port) { - *arg++ = "-p"; + /* P is for PuTTY, p is for OpenSSH */ + *arg++ = putty ? "-P" : "-p"; *arg++ = port; } *arg++ = host; -- 1.5.6.1.255.g32571 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH 07/12] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable 2008-07-02 8:32 ` [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) Steffen Prohaska @ 2008-07-02 8:32 ` Steffen Prohaska 2008-07-02 8:32 ` [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it Steffen Prohaska 2008-07-02 9:16 ` [PATCH 07/12] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable Junio C Hamano 2008-07-02 19:04 ` [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) Johannes Sixt 1 sibling, 2 replies; 371+ messages in thread From: Steffen Prohaska @ 2008-07-02 8:32 UTC (permalink / raw) To: Johannes Sixt Cc: git, msysgit, Junio C Hamano, Dmitry Kakurin, Steffen Prohaska From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com> Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com> Signed-off-by: Steffen Prohaska <prohaska@zib.de> --- convert.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/convert.c b/convert.c index 1c66844..f24ac25 100644 --- a/convert.c +++ b/convert.c @@ -61,6 +61,10 @@ static void gather_stats(const char *buf, unsigned long size, struct text_stat * else stats->printable++; } + + // If file ends with EOF then don't count this EOF as non-printable + if ( size >= 1 && buf[size-1] == '\032' ) + stats->nonprintable--; } /* -- 1.5.6.1.255.g32571 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it. 2008-07-02 8:32 ` [PATCH 07/12] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable Steffen Prohaska @ 2008-07-02 8:32 ` Steffen Prohaska 2008-07-02 8:32 ` [PATCH 09/12] We need to check for msys as well as Windows in add--interactive Steffen Prohaska 2008-07-02 9:20 ` [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it Junio C Hamano 2008-07-02 9:16 ` [PATCH 07/12] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable Junio C Hamano 1 sibling, 2 replies; 371+ messages in thread From: Steffen Prohaska @ 2008-07-02 8:32 UTC (permalink / raw) To: Johannes Sixt Cc: git, msysgit, Junio C Hamano, Johannes Schindelin, Steffen Prohaska From: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Steffen Prohaska <prohaska@zib.de> --- fast-import.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/fast-import.c b/fast-import.c index e72b286..271b93c 100644 --- a/fast-import.c +++ b/fast-import.c @@ -391,7 +391,9 @@ static void write_crash_report(const char *err) fprintf(rpt, "fast-import crash report:\n"); fprintf(rpt, " fast-import process: %d\n", getpid()); +#ifndef __MINGW32__ fprintf(rpt, " parent process : %d\n", getppid()); +#endif fprintf(rpt, " at %s\n", show_date(time(NULL), 0, DATE_LOCAL)); fputc('\n', rpt); -- 1.5.6.1.255.g32571 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH 09/12] We need to check for msys as well as Windows in add--interactive. 2008-07-02 8:32 ` [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it Steffen Prohaska @ 2008-07-02 8:32 ` Steffen Prohaska 2008-07-02 8:32 ` [PATCH 10/12] Add ANSI control code emulation for the Windows console Steffen Prohaska 2008-07-02 9:20 ` [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it Junio C Hamano 1 sibling, 1 reply; 371+ messages in thread From: Steffen Prohaska @ 2008-07-02 8:32 UTC (permalink / raw) To: Johannes Sixt; +Cc: git, msysgit, Junio C Hamano, Mike Pape, Steffen Prohaska From: Mike Pape <dotzenlabs@gmail.com> Signed-off-by: Mike Pape <dotzenlabs@gmail.com> Signed-off-by: Steffen Prohaska <prohaska@zib.de> --- git-add--interactive.perl | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/git-add--interactive.perl b/git-add--interactive.perl index 903953e..78a64e6 100755 --- a/git-add--interactive.perl +++ b/git-add--interactive.perl @@ -42,7 +42,7 @@ sub colored { my $patch_mode; sub run_cmd_pipe { - if ($^O eq 'MSWin32') { + if ($^O eq 'MSWin32' || $^O eq 'msys') { my @invalid = grep {m/[":*]/} @_; die "$^O does not support: @invalid\n" if @invalid; my @args = map { m/ /o ? "\"$_\"": $_ } @_; -- 1.5.6.1.255.g32571 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH 10/12] Add ANSI control code emulation for the Windows console 2008-07-02 8:32 ` [PATCH 09/12] We need to check for msys as well as Windows in add--interactive Steffen Prohaska @ 2008-07-02 8:32 ` Steffen Prohaska 2008-07-02 8:32 ` [PATCH 11/12] verify_path(): do not allow absolute paths Steffen Prohaska ` (2 more replies) 0 siblings, 3 replies; 371+ messages in thread From: Steffen Prohaska @ 2008-07-02 8:32 UTC (permalink / raw) To: Johannes Sixt; +Cc: git, msysgit, Junio C Hamano, Peter, Steffen Prohaska From: Peter <git@peter.is-a-geek.org> This adds only the minimum necessary to keep git pull/merge's diffstat from wrapping. Notably absent is support for the K (erase) operation, and support for POSIX write. Cygwin does not need the WIN_ANSI define, since it has its own (more complete) ANSI emulation. Signed-off-by: Peter Harris <git@peter.is-a-geek.org> Signed-off-by: Steffen Prohaska <prohaska@zib.de> --- Makefile | 6 + compat/winansi.c | 309 +++++++++++++++++++++++++++++++++++++++++++++++++++++ git-compat-util.h | 7 ++ 3 files changed, 322 insertions(+), 0 deletions(-) create mode 100644 compat/winansi.c diff --git a/Makefile b/Makefile index 5914e1a..a7f2dcb 100644 --- a/Makefile +++ b/Makefile @@ -737,6 +737,7 @@ ifneq (,$(findstring MINGW,$(uname_S))) NO_SVN_TESTS = YesPlease NO_PERL_MAKEMAKER = YesPlease NO_POSIX_ONLY_PROGRAMS = YesPlease + WIN_ANSI = YesPlease COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -DNOGDI -Icompat COMPAT_CFLAGS += -DSNPRINTF_SIZE_CORR=1 COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\" @@ -981,6 +982,11 @@ ifdef NO_EXTERNAL_GREP BASIC_CFLAGS += -DNO_EXTERNAL_GREP endif +ifdef WIN_ANSI + COMPAT_CFLAGS += -DWIN_ANSI + COMPAT_OBJS += compat/winansi.o +endif + ifeq ($(TCLTK_PATH),) NO_TCLTK=NoThanks endif diff --git a/compat/winansi.c b/compat/winansi.c new file mode 100644 index 0000000..86c3fd2 --- /dev/null +++ b/compat/winansi.c @@ -0,0 +1,309 @@ +#include <windows.h> +#include "../git-compat-util.h" + +/* + Functions to be wrapped: +*/ +#undef printf +#undef fputs + +/* + ANSI codes to implement: m, K +*/ + +static HANDLE console; +static WORD plain_attr; +static WORD attr; +static int negative; + +static void init(void) +{ + CONSOLE_SCREEN_BUFFER_INFO sbi; + + static int initialized = 0; + if (initialized) + return; + + console = GetStdHandle(STD_OUTPUT_HANDLE); + if (console == INVALID_HANDLE_VALUE) + console = NULL; + + if (!console) + return; + + GetConsoleScreenBufferInfo(console, &sbi); + attr = plain_attr = sbi.wAttributes; + negative = 0; + + initialized = 1; +} + + +#define FOREGROUND_ALL (FOREGROUND_RED | FOREGROUND_GREEN | FOREGROUND_BLUE) +#define BACKGROUND_ALL (BACKGROUND_RED | BACKGROUND_GREEN | BACKGROUND_BLUE) + +static void set_console_attr(void) +{ + WORD attributes = attr; + if (negative) { + attributes &= ~FOREGROUND_ALL; + attributes &= ~BACKGROUND_ALL; + + /* This could probably use a bitmask instead of a series of ifs */ + if (attr & FOREGROUND_RED) + attributes |= BACKGROUND_RED; + if (attr & FOREGROUND_GREEN) + attributes |= BACKGROUND_GREEN; + if (attr & FOREGROUND_BLUE) + attributes |= BACKGROUND_BLUE; + + if (attr & BACKGROUND_RED) + attributes |= FOREGROUND_RED; + if (attr & BACKGROUND_GREEN) + attributes |= FOREGROUND_GREEN; + if (attr & BACKGROUND_BLUE) + attributes |= FOREGROUND_BLUE; + } + SetConsoleTextAttribute(console, attributes); +} + +static const char *set_attr(const char *str) +{ + const char *func; + size_t len = strspn(str, "0123456789;"); + func = str + len; + + switch (*func) { + case 'm': + do { + long val = strtol(str, (char **)&str, 10); + switch (val) { + case 0: /* reset */ + attr = plain_attr; + negative = 0; + break; + case 1: /* bold */ + attr |= FOREGROUND_INTENSITY; + break; + case 2: /* faint */ + case 22: /* normal */ + attr &= ~FOREGROUND_INTENSITY; + break; + case 3: /* italic */ + /* Unsupported */ + break; + case 4: /* underline */ + case 21: /* double underline */ + /* Wikipedia says this flag does nothing */ + /* Furthermore, mingw doesn't define this flag + attr |= COMMON_LVB_UNDERSCORE; */ + break; + case 24: /* no underline */ + /* attr &= ~COMMON_LVB_UNDERSCORE; */ + break; + case 5: /* slow blink */ + case 6: /* fast blink */ + /* We don't have blink, but we do have background intensity */ + attr |= BACKGROUND_INTENSITY; + break; + case 25: /* no blink */ + attr &= ~BACKGROUND_INTENSITY; + break; + case 7: /* negative */ + negative = 1; + break; + case 27: /* positive */ + negative = 0; + break; + case 8: /* conceal */ + case 28: /* reveal */ + /* Unsupported */ + break; + case 30: /* Black */ + attr &= ~FOREGROUND_ALL; + break; + case 31: /* Red */ + attr &= ~FOREGROUND_ALL; + attr |= FOREGROUND_RED; + break; + case 32: /* Green */ + attr &= ~FOREGROUND_ALL; + attr |= FOREGROUND_GREEN; + break; + case 33: /* Yellow */ + attr &= ~FOREGROUND_ALL; + attr |= FOREGROUND_RED | FOREGROUND_GREEN; + break; + case 34: /* Blue */ + attr &= ~FOREGROUND_ALL; + attr |= FOREGROUND_BLUE; + break; + case 35: /* Magenta */ + attr &= ~FOREGROUND_ALL; + attr |= FOREGROUND_RED | FOREGROUND_BLUE; + break; + case 36: /* Cyan */ + attr &= ~FOREGROUND_ALL; + attr |= FOREGROUND_GREEN | FOREGROUND_BLUE; + break; + case 37: /* White */ + attr |= FOREGROUND_RED | FOREGROUND_GREEN | FOREGROUND_BLUE; + break; + case 38: /* Unknown */ + break; + case 39: /* reset */ + attr &= ~FOREGROUND_ALL; + attr |= (plain_attr & FOREGROUND_ALL); + break; + case 40: /* Black */ + attr &= ~BACKGROUND_ALL; + break; + case 41: /* Red */ + attr &= ~BACKGROUND_ALL; + attr |= BACKGROUND_RED; + break; + case 42: /* Green */ + attr &= ~BACKGROUND_ALL; + attr |= BACKGROUND_GREEN; + break; + case 43: /* Yellow */ + attr &= ~BACKGROUND_ALL; + attr |= BACKGROUND_RED | BACKGROUND_GREEN; + break; + case 44: /* Blue */ + attr &= ~BACKGROUND_ALL; + attr |= BACKGROUND_BLUE; + break; + case 45: /* Magenta */ + attr &= ~BACKGROUND_ALL; + attr |= BACKGROUND_RED | BACKGROUND_BLUE; + break; + case 46: /* Cyan */ + attr &= ~BACKGROUND_ALL; + attr |= BACKGROUND_GREEN | BACKGROUND_BLUE; + break; + case 47: /* White */ + attr |= BACKGROUND_RED | BACKGROUND_GREEN | BACKGROUND_BLUE; + break; + case 48: /* Unknown */ + break; + case 49: /* reset */ + attr &= ~BACKGROUND_ALL; + attr |= (plain_attr & BACKGROUND_ALL); + break; + default: + /* Unsupported code */ + break; + } + str++; + } while (*(str-1) == ';'); + + set_console_attr(); + break; + case 'K': + /* TODO */ + break; + default: + /* Unsupported code */ + break; + } + + return func + 1; +} + +static int ansi_emulate(const char *str, FILE *stream) +{ + int rv = 0; + const char *pos = str; + + while (*pos) { + pos = strstr(str, "\033["); + if (pos) { + size_t len = pos - str; + + if (len) { + size_t output_len = fwrite(str, 1, len, stream); + rv += output_len; + if (output_len < len) + return rv; + } + + str = pos + 2; + rv += 2; + + fflush(stream); + + pos = set_attr(str); + rv += pos - str; + str = pos; + } else { + rv += strlen(str); + fputs(str, stream); + return rv; + } + } + return rv; +} + +int git_fputs(const char *str, FILE *stream) +{ + int rv; + + init(); + + if (!console) + return fputs(str, stream); + + if (!isatty(fileno(stream))) + return fputs(str, stream); + + rv = ansi_emulate(str, stream); + + if (rv >= 0) + return 0; + else + return EOF; +} + +int git_printf(const char *format, ...) +{ + va_list list; + + char small_buf[256]; + char *buf = small_buf; + int len, rv; + + init(); + + if (!console) + goto abort; + + if (!isatty(fileno(stdout))) + goto abort; + + va_start(list, format); + len = vsnprintf(small_buf, sizeof(small_buf), format, list); + va_end(list); + + if (len > sizeof(small_buf) - 1) { + buf = malloc(len + 1); + if (!buf) + goto abort; + + va_start(list, format); + len = vsnprintf(buf, len + 1, format, list); + va_end(list); + } + + rv = ansi_emulate(buf, stdout); + + if (buf != small_buf) + free(buf); + return rv; + +abort: + va_start(list, format); + rv = vprintf(format, list); + va_end(list); + return rv; +} diff --git a/git-compat-util.h b/git-compat-util.h index 545df59..fc5168e 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -357,4 +357,11 @@ void git_qsort(void *base, size_t nmemb, size_t size, # define FORCE_DIR_SET_GID 0 #endif +#ifdef WIN_ANSI +extern int git_fputs(const char *str, FILE *stream); +extern int git_printf(const char *format, ...) __attribute__((format (printf, 1, 2))); +#define fputs git_fputs +#define printf(...) git_printf(__VA_ARGS__) +#endif + #endif -- 1.5.6.1.255.g32571 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH 11/12] verify_path(): do not allow absolute paths 2008-07-02 8:32 ` [PATCH 10/12] Add ANSI control code emulation for the Windows console Steffen Prohaska @ 2008-07-02 8:32 ` Steffen Prohaska 2008-07-02 8:32 ` [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next Steffen Prohaska 2008-07-02 9:21 ` [PATCH 11/12] verify_path(): do not allow absolute paths Junio C Hamano 2008-07-02 19:17 ` [msysGit] [PATCH 10/12] Add ANSI control code emulation for the Windows console Johannes Sixt 2008-07-07 18:41 ` Johannes Sixt 2 siblings, 2 replies; 371+ messages in thread From: Steffen Prohaska @ 2008-07-02 8:32 UTC (permalink / raw) To: Johannes Sixt Cc: git, msysgit, Junio C Hamano, Johannes Schindelin, Steffen Prohaska From: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Steffen Prohaska <prohaska@zib.de> --- read-cache.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/read-cache.c b/read-cache.c index f83de8c..cb130ef 100644 --- a/read-cache.c +++ b/read-cache.c @@ -650,6 +650,11 @@ int verify_path(const char *path) { char c; +#ifdef __MINGW32__ + if (is_absolute_path(path)) + return error("Cannot handle absolute path: %s", path); +#endif + goto inside; for (;;) { if (!c) -- 1.5.6.1.255.g32571 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next 2008-07-02 8:32 ` [PATCH 11/12] verify_path(): do not allow absolute paths Steffen Prohaska @ 2008-07-02 8:32 ` Steffen Prohaska 2008-07-02 16:17 ` [msysGit] " Johannes Schindelin 2008-07-02 9:21 ` [PATCH 11/12] verify_path(): do not allow absolute paths Junio C Hamano 1 sibling, 1 reply; 371+ messages in thread From: Steffen Prohaska @ 2008-07-02 8:32 UTC (permalink / raw) To: Johannes Sixt Cc: git, msysgit, Junio C Hamano, Johannes Sixt, Dmitry Kakurin, Steffen Prohaska From: Johannes Sixt <johannes.sixt@telecom.at> Hannes, You introduced "minoffset" in 861429a7c37c7. Here is your original message: ''' An earlier patch has implemented getcwd() so that it converts the drive letter into the POSIX-like path that is used internally by MinGW (C:\foo => /c/foo), but this style does not work outside the MinGW shell. It is better to just convert the backslashes to forward slashes and handle the drive letter explicitly. ''' Dmitry replaced setenv() with set_git_dir in 855f254b2b5b08. Here is his original message: ''' git clone was failing with 'invalid object name HEAD' if ran from cmd.exe directly environment.c caches results of many getenv calls. Under MinGW setenv(X) invalidates all previous values returned by getenv(X) so cached values become dangling pointers. Replaced all setenv(GIT_DIR, ...) with set_git_dir Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com> ''' Signed-off-by: Steffen Prohaska <prohaska@zib.de> --- setup.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/setup.c b/setup.c index 6cf9094..1fd30c4 100644 --- a/setup.c +++ b/setup.c @@ -381,6 +381,7 @@ const char *setup_git_directory_gently(int *nongit_ok) const char *gitdirenv; const char *gitfile_dir; int len, offset, ceil_offset; + int minoffset = 0; /* * Let's assume that we are in a git repository. @@ -431,6 +432,8 @@ const char *setup_git_directory_gently(int *nongit_ok) if (!getcwd(cwd, sizeof(cwd)-1)) die("Unable to read current working directory"); + if (has_dos_drive_prefix(cwd)) + minoffset = 2; ceil_offset = longest_ancestor_length(cwd, env_ceiling_dirs); if (ceil_offset < 0 && has_dos_drive_prefix(cwd)) @@ -461,11 +464,11 @@ const char *setup_git_directory_gently(int *nongit_ok) inside_git_dir = 1; if (!work_tree_env) inside_work_tree = 0; - setenv(GIT_DIR_ENVIRONMENT, ".", 1); + set_git_dir("."); check_repository_format_gently(nongit_ok); return NULL; } - while (--offset > ceil_offset && cwd[offset] != '/'); + while (offset > minoffset && --offset > ceil_offset && cwd[offset] != '/'); if (offset <= ceil_offset) { if (nongit_ok) { if (chdir(cwd)) -- 1.5.6.1.255.g32571 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [msysGit] [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next 2008-07-02 8:32 ` [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next Steffen Prohaska @ 2008-07-02 16:17 ` Johannes Schindelin 2008-07-02 17:08 ` Steffen Prohaska 0 siblings, 1 reply; 371+ messages in thread From: Johannes Schindelin @ 2008-07-02 16:17 UTC (permalink / raw) To: Steffen Prohaska Cc: Johannes Sixt, git, msysgit, Junio C Hamano, Dmitry Kakurin Hi, On Wed, 2 Jul 2008, Steffen Prohaska wrote: > > From: Johannes Sixt <johannes.sixt@telecom.at> > > Hannes, > You introduced "minoffset" in 861429a7c37c7. AFAICT it was redone differently in 'next', because 'next' has this ceiling dir thingie, which allows a different (much smaller) patch. It might be more sensible to base your patch series on 'next'... Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next 2008-07-02 16:17 ` [msysGit] " Johannes Schindelin @ 2008-07-02 17:08 ` Steffen Prohaska 2008-07-02 19:32 ` [msysGit] " Johannes Sixt 0 siblings, 1 reply; 371+ messages in thread From: Steffen Prohaska @ 2008-07-02 17:08 UTC (permalink / raw) To: Johannes Schindelin, Johannes Sixt Cc: Git Mailing List, msysGit, Junio C Hamano, Dmitry Kakurin On Jul 2, 2008, at 6:17 PM, Johannes Schindelin wrote: > On Wed, 2 Jul 2008, Steffen Prohaska wrote: > >> >> From: Johannes Sixt <johannes.sixt@telecom.at> >> >> Hannes, >> You introduced "minoffset" in 861429a7c37c7. > > AFAICT it was redone differently in 'next', because 'next' has this > ceiling dir thingie, which allows a different (much smaller) patch. > > It might be more sensible to base your patch series on 'next'... Hmm.. it is based on next. But obviously I needed to merge mingw's master to 4msysgit's master and resolve conflicts. Maybe I made the wrong decisions then. Hannes, If you believe that your setup.c is good, then I'll copy your version to 4msysgit's master. Steffen ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [msysGit] Re: [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next 2008-07-02 17:08 ` Steffen Prohaska @ 2008-07-02 19:32 ` Johannes Sixt 2008-07-03 6:06 ` Steffen Prohaska 0 siblings, 1 reply; 371+ messages in thread From: Johannes Sixt @ 2008-07-02 19:32 UTC (permalink / raw) To: prohaska Cc: msysGit, Johannes Schindelin, Git Mailing List, Junio C Hamano, Dmitry Kakurin On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote: > On Jul 2, 2008, at 6:17 PM, Johannes Schindelin wrote: > > On Wed, 2 Jul 2008, Steffen Prohaska wrote: > >> From: Johannes Sixt <johannes.sixt@telecom.at> > >> > >> Hannes, > >> You introduced "minoffset" in 861429a7c37c7. > > > > AFAICT it was redone differently in 'next', because 'next' has this > > ceiling dir thingie, which allows a different (much smaller) patch. > > > > It might be more sensible to base your patch series on 'next'... > > Hmm.. it is based on next. But obviously I needed to merge > mingw's master to 4msysgit's master and resolve conflicts. > Maybe I made the wrong decisions then. > > Hannes, > If you believe that your setup.c is good, then I'll copy your version > to 4msysgit's master. The setup.c in mingw.git (and soon Junio's master) and Junio's next are _different_, but both are correct. If you reverse-apply the patch you presented here, then you get the version from Junio's next, which is a good state. [ Of course, the result will work only as long as you do not set GIT_CEILING_DIRECTORIES, because we haven't taken care of the helper functions that this feature uses, longest_ancestor_length() and normalize_path(). ] We have debated about set_git_dir(".") in the past. mingw.git doesn't have it, and it works (for me). I don't know what it is needed for. -- Hannes ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next 2008-07-02 19:32 ` [msysGit] " Johannes Sixt @ 2008-07-03 6:06 ` Steffen Prohaska 2008-07-03 6:13 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Steffen Prohaska @ 2008-07-03 6:06 UTC (permalink / raw) To: Johannes Sixt Cc: msysGit, Johannes Schindelin, Git Mailing List, Junio C Hamano, Dmitry Kakurin On Jul 2, 2008, at 9:32 PM, Johannes Sixt wrote: > On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote: >> On Jul 2, 2008, at 6:17 PM, Johannes Schindelin wrote: >>> On Wed, 2 Jul 2008, Steffen Prohaska wrote: >>>> From: Johannes Sixt <johannes.sixt@telecom.at> >>>> >>>> Hannes, >>>> You introduced "minoffset" in 861429a7c37c7. >>> >>> AFAICT it was redone differently in 'next', because 'next' has this >>> ceiling dir thingie, which allows a different (much smaller) patch. >>> >>> It might be more sensible to base your patch series on 'next'... >> >> Hmm.. it is based on next. But obviously I needed to merge >> mingw's master to 4msysgit's master and resolve conflicts. >> Maybe I made the wrong decisions then. >> >> Hannes, >> If you believe that your setup.c is good, then I'll copy your version >> to 4msysgit's master. > > The setup.c in mingw.git (and soon Junio's master) and Junio's next > are > _different_, but both are correct. If you reverse-apply the patch you > presented here, then you get the version from Junio's next, which is > a good > state. Ok, I'll wait until Junio's master has the changes and will remove the changes to 4msysgit then. Steffen ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next 2008-07-03 6:06 ` Steffen Prohaska @ 2008-07-03 6:13 ` Junio C Hamano 0 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-03 6:13 UTC (permalink / raw) To: prohaska Cc: Johannes Sixt, msysGit, Johannes Schindelin, Git Mailing List, Dmitry Kakurin Steffen Prohaska <prohaska@zib.de> writes: > On Jul 2, 2008, at 9:32 PM, Johannes Sixt wrote: > >> The setup.c in mingw.git (and soon Junio's master) and Junio's next >> are >> _different_, but both are correct. If you reverse-apply the patch you >> presented here, then you get the version from Junio's next, which is >> a good >> state. > > Ok, I'll wait until Junio's master has the changes and will remove > the changes to 4msysgit then. There will be a slight difference between the setup.c in soon-to-be master and j6t/mingw (14086b0), due to recent optimization already on 'master' from Linus, 044bbbc (Make git_dir a path relative to work_tree in setup_work_tree(), 2008-06-19). diff --git a/setup.c b/setup.c index 8bb7b10..cc3fb38 100644 --- a/setup.c +++ b/setup.c @@ -308,9 +308,10 @@ void setup_work_tree(void) work_tree = get_git_work_tree(); git_dir = get_git_dir(); if (!is_absolute_path(git_dir)) - set_git_dir(make_absolute_path(git_dir)); + git_dir = make_absolute_path(git_dir); if (!work_tree || chdir(work_tree)) die("This operation must be run in a work tree"); + set_git_dir(make_relative_path(git_dir, work_tree)); initialized = 1; } ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH 11/12] verify_path(): do not allow absolute paths 2008-07-02 8:32 ` [PATCH 11/12] verify_path(): do not allow absolute paths Steffen Prohaska 2008-07-02 8:32 ` [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next Steffen Prohaska @ 2008-07-02 9:21 ` Junio C Hamano 2008-07-02 14:24 ` Steffen Prohaska 2008-07-02 16:15 ` Johannes Schindelin 1 sibling, 2 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-02 9:21 UTC (permalink / raw) To: prohaska; +Cc: Johannes Sixt, git, msysgit, Johannes Schindelin 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? ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 11/12] verify_path(): do not allow absolute paths 2008-07-02 9:21 ` [PATCH 11/12] verify_path(): do not allow absolute paths Junio C Hamano @ 2008-07-02 14:24 ` Steffen Prohaska 2008-07-02 16:15 ` Johannes Schindelin 1 sibling, 0 replies; 371+ messages in thread From: Steffen Prohaska @ 2008-07-02 14:24 UTC (permalink / raw) To: Johannes Sixt Cc: Git Mailing List, msysGit, Junio C Hamano, Johannes Schindelin On Jul 2, 2008, at 11:21 AM, Junio C Hamano wrote: > Steffen Prohaska <prohaska@zib.de> writes: > >> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> >> Signed-off-by: Steffen Prohaska <prohaska@zib.de> > > No commit log message? Justification? Hannes, Do we still need this change in verify_path(). I am not sure. Maybe it should be reverted in 4msysgit? Steffen ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 11/12] verify_path(): do not allow absolute paths 2008-07-02 9:21 ` [PATCH 11/12] verify_path(): do not allow absolute paths Junio C Hamano 2008-07-02 14:24 ` Steffen Prohaska @ 2008-07-02 16:15 ` Johannes Schindelin 2008-07-02 17:20 ` Steffen Prohaska 1 sibling, 1 reply; 371+ messages in thread From: Johannes Schindelin @ 2008-07-02 16:15 UTC (permalink / raw) To: Junio C Hamano; +Cc: prohaska, Johannes Sixt, git, msysgit Hi, On Wed, 2 Jul 2008, Junio C Hamano wrote: > Steffen Prohaska <prohaska@zib.de> writes: > > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> > > Signed-off-by: Steffen Prohaska <prohaska@zib.de> > > No commit log message? Justification? Justification: adding absolute paths was not caught properly on Windows, and this was the easiest patch. However, IIRC, in the meantime we are nice to the user, and allow absolute paths (which we turn into a relative path, or error out if it is not under the current working directory). Steffen, can you revert the patch and verify that my memory does not fail me? Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 11/12] verify_path(): do not allow absolute paths 2008-07-02 16:15 ` Johannes Schindelin @ 2008-07-02 17:20 ` Steffen Prohaska 2008-07-02 17:31 ` Johannes Schindelin 0 siblings, 1 reply; 371+ messages in thread From: Steffen Prohaska @ 2008-07-02 17:20 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, Johannes Sixt, git, msysgit On Jul 2, 2008, at 6:15 PM, Johannes Schindelin wrote: > Hi, > > On Wed, 2 Jul 2008, Junio C Hamano wrote: > >> Steffen Prohaska <prohaska@zib.de> writes: >> >>> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> >>> Signed-off-by: Steffen Prohaska <prohaska@zib.de> >> >> No commit log message? Justification? > > Justification: adding absolute paths was not caught properly on > Windows, > and this was the easiest patch. > > However, IIRC, in the meantime we are nice to the user, and allow > absolute > paths (which we turn into a relative path, or error out if it is not > under > the current working directory). > > Steffen, can you revert the patch and verify that my memory does not > fail > me? Is git add /c/msysgit/git/read-cache.c an appropriate test? It fails with error: 'c:/msysgit/git/read-cache.c' is outside repository no matter if the commit is reverted or not. Steffen ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 11/12] verify_path(): do not allow absolute paths 2008-07-02 17:20 ` Steffen Prohaska @ 2008-07-02 17:31 ` Johannes Schindelin 0 siblings, 0 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-07-02 17:31 UTC (permalink / raw) To: Steffen Prohaska; +Cc: Junio C Hamano, Johannes Sixt, git, msysgit Hi, On Wed, 2 Jul 2008, Steffen Prohaska wrote: > On Jul 2, 2008, at 6:15 PM, Johannes Schindelin wrote: > > >On Wed, 2 Jul 2008, Junio C Hamano wrote: > > > > >Steffen Prohaska <prohaska@zib.de> writes: > > > > > > >Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> > > > >Signed-off-by: Steffen Prohaska <prohaska@zib.de> > > > > > >No commit log message? Justification? > > > >Justification: adding absolute paths was not caught properly on > >Windows, and this was the easiest patch. > > > >However, IIRC, in the meantime we are nice to the user, and allow > >absolute paths (which we turn into a relative path, or error out if it > >is not under the current working directory). > > > >Steffen, can you revert the patch and verify that my memory does not > >fail me? > > Is > > git add /c/msysgit/git/read-cache.c > > an appropriate test? > > It fails with > > error: 'c:/msysgit/git/read-cache.c' is outside repository > > no matter if the commit is reverted or not. Yes, that is enough. It proves that the patch 11/12 is unnecessary and should be removed from 4msysgit.git. Thanks, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [msysGit] [PATCH 10/12] Add ANSI control code emulation for the Windows console 2008-07-02 8:32 ` [PATCH 10/12] Add ANSI control code emulation for the Windows console Steffen Prohaska 2008-07-02 8:32 ` [PATCH 11/12] verify_path(): do not allow absolute paths Steffen Prohaska @ 2008-07-02 19:17 ` Johannes Sixt 2008-07-02 19:32 ` Peter Harris 2008-07-07 18:41 ` Johannes Sixt 2 siblings, 1 reply; 371+ messages in thread From: Johannes Sixt @ 2008-07-02 19:17 UTC (permalink / raw) To: prohaska; +Cc: msysGit, git, Junio C Hamano, Peter 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [msysGit] [PATCH 10/12] Add ANSI control code emulation for the Windows console 2008-07-02 19:17 ` [msysGit] [PATCH 10/12] Add ANSI control code emulation for the Windows console Johannes Sixt @ 2008-07-02 19:32 ` Peter Harris 0 siblings, 0 replies; 371+ messages in thread From: Peter Harris @ 2008-07-02 19:32 UTC (permalink / raw) To: Johannes Sixt; +Cc: prohaska, msysGit, git, Junio C Hamano On Wed, Jul 2, 2008 at 3:17 PM, Johannes Sixt wrote: > On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote: >> This adds only the minimum necessary to keep git pull/merge's diffstat from >> wrapping. Notably absent is support for the K (erase) operation, and >> support for POSIX write. > > If I understand the patch correctly, it won't affect output that goes to the > pager; only text that goes directly to the console would be colored. Yes, that is correct. Note that an MSYS bash/rxvt is effectively considered a pager by this patch, since it fails the isatty() test. This is actually a good thing: MSYS has better ANSI support anyway. Peter Harris ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [msysGit] [PATCH 10/12] Add ANSI control code emulation for the Windows console 2008-07-02 8:32 ` [PATCH 10/12] Add ANSI control code emulation for the Windows console Steffen Prohaska 2008-07-02 8:32 ` [PATCH 11/12] verify_path(): do not allow absolute paths Steffen Prohaska 2008-07-02 19:17 ` [msysGit] [PATCH 10/12] Add ANSI control code emulation for the Windows console Johannes Sixt @ 2008-07-07 18:41 ` Johannes Sixt 2 siblings, 0 replies; 371+ messages in thread From: Johannes Sixt @ 2008-07-07 18:41 UTC (permalink / raw) To: prohaska, Peter; +Cc: msysGit, git, Junio C Hamano On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote: > This adds only the minimum necessary to keep git pull/merge's diffstat from > wrapping. Notably absent is support for the K (erase) operation, and > support for POSIX write. I've tested this patch, and it is no longer ready for prime-time in its current form. It doesn't do what it advertises (colorize diffstat of merge) because the diff machinery since some time now uses fprintf, not printf, so the replacements are not called and escape characters are left in the console window. > +#ifdef WIN_ANSI > +extern int git_fputs(const char *str, FILE *stream); > +extern int git_printf(const char *format, ...) __attribute__((format > (printf, 1, 2))); +#define fputs git_fputs > +#define printf(...) git_printf(__VA_ARGS__) > +#endif > + > #endif Put this (without #ifdef WIN_ANSI) in mingw.h and don't change the Makefile. -- Hannes ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it. 2008-07-02 8:32 ` [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it Steffen Prohaska 2008-07-02 8:32 ` [PATCH 09/12] We need to check for msys as well as Windows in add--interactive Steffen Prohaska @ 2008-07-02 9:20 ` Junio C Hamano 2008-07-02 14:22 ` Steffen Prohaska 2008-07-02 16:52 ` Johannes Schindelin 1 sibling, 2 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-02 9:20 UTC (permalink / raw) To: prohaska; +Cc: Johannes Sixt, git, msysgit, Johannes Schindelin 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it. 2008-07-02 9:20 ` [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it Junio C Hamano @ 2008-07-02 14:22 ` Steffen Prohaska 2008-07-02 16:52 ` Johannes Schindelin 1 sibling, 0 replies; 371+ messages in thread From: Steffen Prohaska @ 2008-07-02 14:22 UTC (permalink / raw) To: Junio C Hamano; +Cc: Johannes Sixt, git, msysgit, Johannes Schindelin On Jul 2, 2008, at 11:20 AM, Junio C Hamano wrote: > Steffen Prohaska <prohaska@zib.de> writes: > >> diff --git a/fast-import.c b/fast-import.c >> index e72b286..271b93c 100644 >> --- a/fast-import.c >> +++ b/fast-import.c >> @@ -391,7 +391,9 @@ static void write_crash_report(const char *err) >> >> fprintf(rpt, "fast-import crash report:\n"); >> fprintf(rpt, " fast-import process: %d\n", getpid()); >> +#ifndef __MINGW32__ >> fprintf(rpt, " parent process : %d\n", getppid()); >> +#endif >> fprintf(rpt, " at %s\n", show_date(time(NULL), 0, DATE_LOCAL)); >> fputc('\n', rpt); >> >> -- >> 1.5.6.1.255.g32571 > > It does not matter too much for this part that writes crash report, > but > keeping the file format the same across platforms will make it > easier for > tools to read output, so as a general principle, I think this is a > suboptimal solution to the issue. How about throwing something like > this > in MinGW specific header files? > > #define getppid() 0 Hannes added something similar to the compat layer, so this commit is no longer needed. I'll remove it from the series and revert it in 4msysgit. Steffen ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it. 2008-07-02 9:20 ` [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it Junio C Hamano 2008-07-02 14:22 ` Steffen Prohaska @ 2008-07-02 16:52 ` Johannes Schindelin 1 sibling, 0 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-07-02 16:52 UTC (permalink / raw) To: Junio C Hamano; +Cc: prohaska, Johannes Sixt, git, msysgit Hi, On Wed, 2 Jul 2008, Junio C Hamano wrote: > Steffen Prohaska <prohaska@zib.de> writes: > > > diff --git a/fast-import.c b/fast-import.c > > index e72b286..271b93c 100644 > > --- a/fast-import.c > > +++ b/fast-import.c > > @@ -391,7 +391,9 @@ static void write_crash_report(const char *err) > > > > fprintf(rpt, "fast-import crash report:\n"); > > fprintf(rpt, " fast-import process: %d\n", getpid()); > > +#ifndef __MINGW32__ > > fprintf(rpt, " parent process : %d\n", getppid()); > > +#endif > > fprintf(rpt, " at %s\n", show_date(time(NULL), 0, DATE_LOCAL)); > > fputc('\n', rpt); > > > > -- > > 1.5.6.1.255.g32571 > > It does not matter too much for this part that writes crash report, but > keeping the file format the same across platforms will make it easier for > tools to read output, so as a general principle, I think this is a > suboptimal solution to the issue. How about throwing something like this > in MinGW specific header files? > > #define getppid() 0 Of course, we could also implement it, using NtQueryInformationProcess() as suggested by Google. Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 07/12] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable 2008-07-02 8:32 ` [PATCH 07/12] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable Steffen Prohaska 2008-07-02 8:32 ` [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it Steffen Prohaska @ 2008-07-02 9:16 ` Junio C Hamano 2008-07-11 16:48 ` [PATCH] " Steffen Prohaska 1 sibling, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-02 9:16 UTC (permalink / raw) To: prohaska; +Cc: Johannes Sixt, git, msysgit, Dmitry Kakurin Steffen Prohaska <prohaska@zib.de> writes: > From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com> > > Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com> > Signed-off-by: Steffen Prohaska <prohaska@zib.de> > --- > convert.c | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/convert.c b/convert.c > index 1c66844..f24ac25 100644 > --- a/convert.c > +++ b/convert.c > @@ -61,6 +61,10 @@ static void gather_stats(const char *buf, unsigned long size, struct text_stat * > else > stats->printable++; > } > + > + // If file ends with EOF then don't count this EOF as non-printable > + if ( size >= 1 && buf[size-1] == '\032' ) > + stats->nonprintable--; Style. I debated for 5 seconds with myself if this should be inside #ifdef, but doing this everywhere would give us reproducibility --- otherwise the resulting project won't be cross platform, so I think the intention of this change is good. ^ permalink raw reply [flat|nested] 371+ messages in thread
* [PATCH] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable 2008-07-02 9:16 ` [PATCH 07/12] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable Junio C Hamano @ 2008-07-11 16:48 ` Steffen Prohaska 2008-07-11 18:42 ` Johannes Schindelin 0 siblings, 1 reply; 371+ messages in thread From: Steffen Prohaska @ 2008-07-11 16:48 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, Dmitry Kakurin, Steffen Prohaska From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com> Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com> Signed-off-by: Steffen Prohaska <prohaska@zib.de> --- convert.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/convert.c b/convert.c index 352b69d..78efed8 100644 --- a/convert.c +++ b/convert.c @@ -61,6 +61,10 @@ static void gather_stats(const char *buf, unsigned long size, struct text_stat * else stats->printable++; } + + /* If file ends with EOF then don't count this EOF as non-printable. */ + if (size >= 1 && buf[size-1] == '\032') + stats->nonprintable--; } /* -- 1.5.6.1.282.gd8a0d ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable 2008-07-11 16:48 ` [PATCH] " Steffen Prohaska @ 2008-07-11 18:42 ` Johannes Schindelin 2008-07-11 20:32 ` Steffen Prohaska 0 siblings, 1 reply; 371+ messages in thread From: Johannes Schindelin @ 2008-07-11 18:42 UTC (permalink / raw) To: Steffen Prohaska; +Cc: Junio C Hamano, git, Dmitry Kakurin Hi, On Fri, 11 Jul 2008, Steffen Prohaska wrote: > From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com> > > Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com> > Signed-off-by: Steffen Prohaska <prohaska@zib.de> > --- > convert.c | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/convert.c b/convert.c > index 352b69d..78efed8 100644 > --- a/convert.c > +++ b/convert.c > @@ -61,6 +61,10 @@ static void gather_stats(const char *buf, unsigned long size, struct text_stat * > else > stats->printable++; > } > + > + /* If file ends with EOF then don't count this EOF as non-printable. */ > + if (size >= 1 && buf[size-1] == '\032') > + stats->nonprintable--; This is one of the things that are very specific to Windows and should not affect other people. Ciao, Dscho P.S.: this is one of the examples why I would like to discuss things that are Windows-only on the msysGit list, until we have a consensus there. We have a few Git experts there, you and Hannes in particular, which cover that side, but also some Windows experts such as Peter and Marius, and we should not need to have that discussion on a list where people are not expected to care about Windows _at all_. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable 2008-07-11 18:42 ` Johannes Schindelin @ 2008-07-11 20:32 ` Steffen Prohaska 2008-07-11 20:40 ` Johannes Schindelin 0 siblings, 1 reply; 371+ messages in thread From: Steffen Prohaska @ 2008-07-11 20:32 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, git, Dmitry Kakurin On Jul 11, 2008, at 8:42 PM, Johannes Schindelin wrote: > On Fri, 11 Jul 2008, Steffen Prohaska wrote: > >> From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com> >> >> Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com> >> Signed-off-by: Steffen Prohaska <prohaska@zib.de> >> --- >> convert.c | 4 ++++ >> 1 files changed, 4 insertions(+), 0 deletions(-) >> >> diff --git a/convert.c b/convert.c >> index 352b69d..78efed8 100644 >> --- a/convert.c >> +++ b/convert.c >> @@ -61,6 +61,10 @@ static void gather_stats(const char *buf, >> unsigned long size, struct text_stat * >> else >> stats->printable++; >> } >> + >> + /* If file ends with EOF then don't count this EOF as non- >> printable. */ >> + if (size >= 1 && buf[size-1] == '\032') >> + stats->nonprintable--; > > This is one of the things that are very specific to Windows and > should not > affect other people. Does this mean you are opposed to this change? Junio thinks that "the intention of this change is good" [1]. Hence, I cleaned up the style and re-send the patch. [1] http://article.gmane.org/gmane.comp.version-control.git/87122 Steffen ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable 2008-07-11 20:32 ` Steffen Prohaska @ 2008-07-11 20:40 ` Johannes Schindelin 0 siblings, 0 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-07-11 20:40 UTC (permalink / raw) To: Steffen Prohaska; +Cc: Junio C Hamano, git, Dmitry Kakurin Hi, On Fri, 11 Jul 2008, Steffen Prohaska wrote: > On Jul 11, 2008, at 8:42 PM, Johannes Schindelin wrote: > > >On Fri, 11 Jul 2008, Steffen Prohaska wrote: > > > > >From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com> > > > > > >Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com> > > >Signed-off-by: Steffen Prohaska <prohaska@zib.de> > > >--- > > >convert.c | 4 ++++ > > >1 files changed, 4 insertions(+), 0 deletions(-) > > > > > >diff --git a/convert.c b/convert.c > > >index 352b69d..78efed8 100644 > > >--- a/convert.c > > >+++ b/convert.c > > >@@ -61,6 +61,10 @@ static void gather_stats(const char *buf, unsigned long > > >size, struct text_stat * > > > else > > > stats->printable++; > > > } > > >+ > > >+ /* If file ends with EOF then don't count this EOF as non-printable. > > >*/ > > >+ if (size >= 1 && buf[size-1] == '\032') > > >+ stats->nonprintable--; > > > >This is one of the things that are very specific to Windows and should not > >affect other people. > > Does this mean you are opposed to this change? Hrm. Thinking about it again, this _could_ help Unix people who collaborate with DOS people. OTOH it will just hide the fact that text files were committed that contain silly characters. On the third hand, this code path affects only people who set autocrlf. Well, I guess they asked for it, kind of. Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) 2008-07-02 8:32 ` [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) Steffen Prohaska 2008-07-02 8:32 ` [PATCH 07/12] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable Steffen Prohaska @ 2008-07-02 19:04 ` Johannes Sixt 2008-07-03 11:10 ` Johannes Schindelin 2008-07-04 9:18 ` Junio C Hamano 1 sibling, 2 replies; 371+ messages in thread From: Johannes Sixt @ 2008-07-02 19:04 UTC (permalink / raw) To: prohaska; +Cc: msysGit, git, Junio C Hamano, Edward Z. Yang On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote: > From: Edward Z. Yang <edwardzyang@thewritingpot.com> > > PuTTY requires -P while OpenSSH requires -p; if plink is detected > as GIT_SSH, use the alternate flag. > > Signed-off-by: Edward Z. Yang <edwardzyang@thewritingpot.com> > Signed-off-by: Steffen Prohaska <prohaska@zib.de> > --- > connect.c | 4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/connect.c b/connect.c > index 574f42f..0d007f3 100644 > --- a/connect.c > +++ b/connect.c > @@ -599,11 +599,13 @@ struct child_process *git_connect(int fd[2], const > char *url_orig, conn->argv = arg = xcalloc(6, sizeof(*arg)); > if (protocol == PROTO_SSH) { > const char *ssh = getenv("GIT_SSH"); > + int putty = ssh && strstr(ssh, "plink"); > if (!ssh) ssh = "ssh"; > > *arg++ = ssh; > if (port) { > - *arg++ = "-p"; > + /* P is for PuTTY, p is for OpenSSH */ > + *arg++ = putty ? "-P" : "-p"; > *arg++ = port; > } > *arg++ = host; What about installing a wrapper script, plinkssh, that does this: #!/bin/bash if test "$1" = -p; then port="-P $2" shift; shift fi exec plink $port "$@" and require plink users to set GIT_SSH=plinkssh? -- Hannes ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) 2008-07-02 19:04 ` [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) Johannes Sixt @ 2008-07-03 11:10 ` Johannes Schindelin 2008-07-04 8:50 ` Steffen Prohaska 2008-07-04 9:18 ` Junio C Hamano 1 sibling, 1 reply; 371+ messages in thread From: Johannes Schindelin @ 2008-07-03 11:10 UTC (permalink / raw) To: Johannes Sixt; +Cc: prohaska, msysGit, git, Junio C Hamano, Edward Z. Yang Hi, On Wed, 2 Jul 2008, Johannes Sixt wrote: > On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote: > > From: Edward Z. Yang <edwardzyang@thewritingpot.com> > > > > PuTTY requires -P while OpenSSH requires -p; if plink is detected > > as GIT_SSH, use the alternate flag. > > > > Signed-off-by: Edward Z. Yang <edwardzyang@thewritingpot.com> > > Signed-off-by: Steffen Prohaska <prohaska@zib.de> > > --- > > connect.c | 4 +++- > > 1 files changed, 3 insertions(+), 1 deletions(-) > > > > diff --git a/connect.c b/connect.c > > index 574f42f..0d007f3 100644 > > --- a/connect.c > > +++ b/connect.c > > @@ -599,11 +599,13 @@ struct child_process *git_connect(int fd[2], const > > char *url_orig, conn->argv = arg = xcalloc(6, sizeof(*arg)); > > if (protocol == PROTO_SSH) { > > const char *ssh = getenv("GIT_SSH"); > > + int putty = ssh && strstr(ssh, "plink"); > > if (!ssh) ssh = "ssh"; > > > > *arg++ = ssh; > > if (port) { > > - *arg++ = "-p"; > > + /* P is for PuTTY, p is for OpenSSH */ > > + *arg++ = putty ? "-P" : "-p"; > > *arg++ = port; > > } > > *arg++ = host; > > What about installing a wrapper script, plinkssh, that does this: > > #!/bin/bash > > if test "$1" = -p; then > port="-P $2" > shift; shift > fi > > exec plink $port "$@" > > and require plink users to set GIT_SSH=plinkssh? I like that better than this special-casing of plink. Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) 2008-07-03 11:10 ` Johannes Schindelin @ 2008-07-04 8:50 ` Steffen Prohaska 0 siblings, 0 replies; 371+ messages in thread From: Steffen Prohaska @ 2008-07-04 8:50 UTC (permalink / raw) To: Johannes Schindelin Cc: Johannes Sixt, msysGit, git, Junio C Hamano, Edward Z. Yang On Jul 3, 2008, at 1:10 PM, Johannes Schindelin wrote: > On Wed, 2 Jul 2008, Johannes Sixt wrote: > >> On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote: >>> From: Edward Z. Yang <edwardzyang@thewritingpot.com> >>> >>> PuTTY requires -P while OpenSSH requires -p; if plink is detected >>> as GIT_SSH, use the alternate flag. >>> >>> Signed-off-by: Edward Z. Yang <edwardzyang@thewritingpot.com> >>> Signed-off-by: Steffen Prohaska <prohaska@zib.de> >>> --- >>> connect.c | 4 +++- >>> 1 files changed, 3 insertions(+), 1 deletions(-) >>> >>> diff --git a/connect.c b/connect.c >>> index 574f42f..0d007f3 100644 >>> --- a/connect.c >>> +++ b/connect.c >>> @@ -599,11 +599,13 @@ struct child_process *git_connect(int fd[2], >>> const >>> char *url_orig, conn->argv = arg = xcalloc(6, sizeof(*arg)); >>> if (protocol == PROTO_SSH) { >>> const char *ssh = getenv("GIT_SSH"); >>> + int putty = ssh && strstr(ssh, "plink"); >>> if (!ssh) ssh = "ssh"; >>> >>> *arg++ = ssh; >>> if (port) { >>> - *arg++ = "-p"; >>> + /* P is for PuTTY, p is for OpenSSH */ >>> + *arg++ = putty ? "-P" : "-p"; >>> *arg++ = port; >>> } >>> *arg++ = host; >> >> What about installing a wrapper script, plinkssh, that does this: >> >> #!/bin/bash >> >> if test "$1" = -p; then >> port="-P $2" >> shift; shift >> fi >> >> exec plink $port "$@" >> >> and require plink users to set GIT_SSH=plinkssh? > > I like that better than this special-casing of plink. I'd prefer to change connect.c. plinkssh would introduce another dependency on the shell, while our overall goal is to avoid shell as much as possible on Windows, no? Edward's solution also looks more obvious to me than the plinkssh wrapper script. Steffen ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) 2008-07-02 19:04 ` [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) Johannes Sixt 2008-07-03 11:10 ` Johannes Schindelin @ 2008-07-04 9:18 ` Junio C Hamano 2008-07-04 9:29 ` Steffen Prohaska 1 sibling, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-04 9:18 UTC (permalink / raw) To: johannes.sixt; +Cc: prohaska, msysGit, git, Edward Z. Yang 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) 2008-07-04 9:18 ` Junio C Hamano @ 2008-07-04 9:29 ` Steffen Prohaska 2008-07-04 16:09 ` Clifford Caoile 0 siblings, 1 reply; 371+ messages in thread From: Steffen Prohaska @ 2008-07-04 9:29 UTC (permalink / raw) To: Junio C Hamano; +Cc: johannes.sixt, msysGit, git, Edward Z. Yang On Jul 4, 2008, at 11:18 AM, Junio C Hamano wrote: > Johannes Sixt <johannes.sixt@telecom.at> writes: > >> What about installing a wrapper script, plinkssh, that does this: >> >> #!/bin/bash >> >> if test "$1" = -p; then >> port="-P $2" >> shift; shift >> fi >> >> exec plink $port "$@" >> >> and require plink users to set GIT_SSH=plinkssh? > > That's quite a nice solution with absolute minimum impact. It has minimum impact on the source code of git. The same is not true, however, for the git user and the installer on Windows: - The proposed plinkssh requires that plink is in the PATH. This is not necessarily the case on Windows. If plink is not in the PATH, then the user needs to modify plinkssh. - The msysgit installer supports setting GIT_SSH to the full path of plink. It automatically detects this path based on Putty's entries in the Windows registry. If we choose the plinkssh solution the installer has to be modified. Setting '-P' in connect.c would have some impact on the git source, but would avoid changes elsewhere. Steffen ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) 2008-07-04 9:29 ` Steffen Prohaska @ 2008-07-04 16:09 ` Clifford Caoile 2008-07-04 20:11 ` [msysGit] " Edward Z. Yang 0 siblings, 1 reply; 371+ messages in thread From: Clifford Caoile @ 2008-07-04 16:09 UTC (permalink / raw) To: prohaska; +Cc: Junio C Hamano, johannes.sixt, msysGit, git, Edward Z. Yang Hi: On Fri, Jul 4, 2008 at 6:29 PM, Steffen Prohaska <prohaska@zib.de> wrote: > > On Jul 4, 2008, at 11:18 AM, Junio C Hamano wrote: > >> Johannes Sixt <johannes.sixt@telecom.at> writes: >> >>> What about installing a wrapper script, plinkssh, that does this: >> >> That's quite a nice solution with absolute minimum impact. > > It has minimum impact on the source code of git. The same is not > true, however, for the git user and the installer on Windows: > > - The proposed plinkssh requires that plink is in the PATH. This is > not necessarily the case on Windows. If plink is not in the PATH, > then the user needs to modify plinkssh. > > - The msysgit installer supports setting GIT_SSH to the full path > of plink. It automatically detects this path based on Putty's > entries in the Windows registry. If we choose the plinkssh > solution the installer has to be modified. How about we create one more global environment variable MSYSGIT_REAL_PLINK which points to the Windows plink during installation? Then we set the GIT_SSH to the plinkssh, and the proposed plinkssh can point to MSYSGIT_REAL_PLINK? + # fall back to plink if MSYSGIT_REAL_PLINK is not defined + # and hope plink is in the path + plink=${MSYSGIT_REAL_PLINK:-plink} - exec plink $port "$@" + exec ${plink} $port "$@" Perhaps I have traded one problem for another, because the msysgit user still has to be aware of MSYSGIT_REAL_PLINK (at least she doesn't have to set it up). And of course, the installer has to be modified to accommodate plinkssh and my proposal. Best regards, Clifford Caoile ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [msysGit] Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) 2008-07-04 16:09 ` Clifford Caoile @ 2008-07-04 20:11 ` Edward Z. Yang 0 siblings, 0 replies; 371+ messages in thread From: Edward Z. Yang @ 2008-07-04 20:11 UTC (permalink / raw) To: piyo; +Cc: prohaska, Junio C Hamano, johannes.sixt, msysGit, git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser 2008-07-02 8:32 ` [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser Steffen Prohaska 2008-07-02 8:32 ` [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) Steffen Prohaska @ 2008-07-02 9:11 ` Junio C Hamano 2008-07-02 18:57 ` Johannes Sixt 2 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-02 9:11 UTC (permalink / raw) To: prohaska; +Cc: Johannes Sixt, git, msysgit Steffen Prohaska <prohaska@zib.de> writes: > +/* Convert slashes to backslashes on Windows. */ > +char *make_native_separator(char *path); Makes one onder why it is not inside #ifdef, but presumably it is no-op on other platforms (which is fine, better than fine)? > static int show_all = 0; > +#ifdef __MINGW32__ > +static enum help_format help_format = HELP_FORMAT_WEB; > +#else > static enum help_format help_format = HELP_FORMAT_MAN; > +#endif That's Ugly isn't it? Can't you do this with Makefile macro without #ifdef please? > @@ -644,12 +649,35 @@ static void get_html_page_path(struct strbuf *page_path, const char *page) > > static void show_html_page(const char *git_cmd) > { > +#ifdef __MINGW32__ > + const char* exec_path = git_exec_path(); > + char *htmlpath = make_native_separator( > + mkpath("%s/../doc/git/html/%s.html" > + , exec_path > + , git_cmd) > + ); > + if (!file_exists(htmlpath)) { > + htmlpath = make_native_separator( > + mkpath("%s/../doc/git/html/git-%s.html" > + , exec_path > + , git_cmd) > + ); > + if (!file_exists(htmlpath)) { > + fprintf(stderr, "Can't find HTML help for '%s'.\n" > + , git_cmd); > + exit(1); > + } > + } > + printf("Launching default browser to display HTML help ...\n"); > + ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0); > +#else > const char *page = cmd_to_page(git_cmd); > struct strbuf page_path; /* it leaks but we exec bellow */ > > get_html_page_path(&page_path, page); > > execl_git_cmd("web--browse", "-c", "help.browser", page_path.buf, NULL); > +#endif > } Hmm. The above almost makes me barf and suggest making them two totally separate functions (i.e. introduce a new "show_html_page_on_windows()" function and do not bother us Unix folks ;-). But I suspect your code is not beyond salvaging. Why is the htmlpath computed by hand in this function, instead of having the port specific implementation hidden inside get_html_page_path() function? About the execution part, isn't it the matter of using "open" (whatever that is) as one of the supported backend for web--browse to unify these two independent case arms? ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser 2008-07-02 8:32 ` [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser Steffen Prohaska 2008-07-02 8:32 ` [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) Steffen Prohaska 2008-07-02 9:11 ` [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser Junio C Hamano @ 2008-07-02 18:57 ` Johannes Sixt 2008-07-04 9:06 ` Steffen Prohaska 2 siblings, 1 reply; 371+ messages in thread From: Johannes Sixt @ 2008-07-02 18:57 UTC (permalink / raw) To: prohaska; +Cc: msysGit, git, Junio C Hamano On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote: > The implementation directly calls the Win32 API to launch the browser. > Note that the specific directory layout of msysgit is required. > +#ifdef __MINGW32__ > + const char* exec_path = git_exec_path(); > + char *htmlpath = make_native_separator( > + mkpath("%s/../doc/git/html/%s.html" > + , exec_path > + , git_cmd) > + ); > + if (!file_exists(htmlpath)) { > + htmlpath = make_native_separator( > + mkpath("%s/../doc/git/html/git-%s.html" > + , exec_path > + , git_cmd) > + ); > + if (!file_exists(htmlpath)) { > + fprintf(stderr, "Can't find HTML help for '%s'.\n" > + , git_cmd); > + exit(1); > + } > + } > + printf("Launching default browser to display HTML help ...\n"); > + ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0); > +#else Can't we move this part into git-web--browse.sh? It should be a matter of calling start $htmlpath (and msys-1.0.dll would convert slashes to backslashes for us). -- Hannes ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser 2008-07-02 18:57 ` Johannes Sixt @ 2008-07-04 9:06 ` Steffen Prohaska 2008-07-04 9:09 ` [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path() Steffen Prohaska 0 siblings, 1 reply; 371+ messages in thread From: Steffen Prohaska @ 2008-07-04 9:06 UTC (permalink / raw) To: Johannes Sixt, Junio C Hamano; +Cc: Git Mailing List On Jul 2, 2008, at 8:57 PM, Johannes Sixt wrote: > On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote: >> The implementation directly calls the Win32 API to launch the >> browser. >> Note that the specific directory layout of msysgit is required. > >> +#ifdef __MINGW32__ >> + const char* exec_path = git_exec_path(); >> + char *htmlpath = make_native_separator( >> + mkpath("%s/../doc/git/html/%s.html" >> + , exec_path >> + , git_cmd) >> + ); >> + if (!file_exists(htmlpath)) { >> + htmlpath = make_native_separator( >> + mkpath("%s/../doc/git/html/git-%s.html" >> + , exec_path >> + , git_cmd) >> + ); >> + if (!file_exists(htmlpath)) { >> + fprintf(stderr, "Can't find HTML help for '%s'.\n" >> + , git_cmd); >> + exit(1); >> + } >> + } >> + printf("Launching default browser to display HTML help ...\n"); >> + ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0); >> +#else > > Can't we move this part into git-web--browse.sh? It should be a > matter of > calling > > start $htmlpath > > (and msys-1.0.dll would convert slashes to backslashes for us). I try to avoid the shell as much as possible on Windows. How about the two following patches: [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path() [PATCH 2/2] help (Windows): Display HTML in default browser using Win32 API I'll send them as replies to this mail. Steffen ^ permalink raw reply [flat|nested] 371+ messages in thread
* [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path() 2008-07-04 9:06 ` Steffen Prohaska @ 2008-07-04 9:09 ` Steffen Prohaska 2008-07-04 9:09 ` [PATCH 2/2] help (Windows): Display HTML in default browser using Win32 API Steffen Prohaska 2008-07-04 9:26 ` [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path() Junio C Hamano 0 siblings, 2 replies; 371+ messages in thread From: Steffen Prohaska @ 2008-07-04 9:09 UTC (permalink / raw) To: Junio C Hamano, Johannes Sixt; +Cc: git, Steffen Prohaska If htmldir (in the Makefile) is a relative path, this path will be interpreted relative to git_exec_path. This can be used to create an installation that can be moved to a different directory without re-compiling. The Windows installer (msysgit) is an example for such a setup. Note that the Makefile maps htmldir to the define GIT_HTML_PATH. Signed-off-by: Steffen Prohaska <prohaska@zib.de> --- help.c | 14 +++++++++++--- 1 files changed, 11 insertions(+), 3 deletions(-) diff --git a/help.c b/help.c index ca9632b..5586e1d 100644 --- a/help.c +++ b/help.c @@ -634,12 +634,20 @@ static void get_html_page_path(struct strbuf *page_path, const char *page) { struct stat st; + const char* html_path = GIT_HTML_PATH; + if (!is_absolute_path(html_path)) { + struct strbuf d = STRBUF_INIT; + strbuf_addf(&d, "%s/%s", git_exec_path(), html_path); + html_path = strbuf_detach(&d, NULL); + } + /* Check that we have a git documentation directory. */ - if (stat(GIT_HTML_PATH "/git.html", &st) || !S_ISREG(st.st_mode)) - die("'%s': not a documentation directory.", GIT_HTML_PATH); + if (stat(mkpath("%s/git.html", html_path), &st) + || !S_ISREG(st.st_mode)) + die("'%s': not a documentation directory.", html_path); strbuf_init(page_path, 0); - strbuf_addf(page_path, GIT_HTML_PATH "/%s.html", page); + strbuf_addf(page_path, "%s/%s.html", html_path, page); } static void show_html_page(const char *git_cmd) -- 1.5.6.1.282.gd8a0d ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH 2/2] help (Windows): Display HTML in default browser using Win32 API 2008-07-04 9:09 ` [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path() Steffen Prohaska @ 2008-07-04 9:09 ` Steffen Prohaska 2008-07-04 9:26 ` [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path() Junio C Hamano 1 sibling, 0 replies; 371+ messages in thread From: Steffen Prohaska @ 2008-07-04 9:09 UTC (permalink / raw) To: Junio C Hamano, Johannes Sixt; +Cc: git, Steffen Prohaska The Win32 API is now called directly to launch the system's default browser for displaying HTML help pages instead of launching a shell to execute git-web--browser. Avoiding the MSYS' bash when possible is good because it avoids potential path translation issues. In this case it is not too hard to avoid launching a shell, so let's avoid it. This commit also adds make_native_separator() to convert slashes to backslashes on Windows. Signed-off-by: Steffen Prohaska <prohaska@zib.de> --- cache.h | 2 ++ help.c | 18 ++++++++++++++++++ path.c | 18 ++++++++++++++++++ 3 files changed, 38 insertions(+), 0 deletions(-) diff --git a/cache.h b/cache.h index 35a9132..747581f 100644 --- a/cache.h +++ b/cache.h @@ -527,6 +527,8 @@ static inline int is_absolute_path(const char *path) const char *make_absolute_path(const char *path); const char *make_nonrelative_path(const char *path); const char *make_relative_path(const char *abs, const char *base); +/* Convert slashes to backslashes on Windows. no-op on other platforms. */ +const char *make_native_separator(const char *path); /* Read and unpack a sha1 file into memory, write memory to a sha1 file */ extern int sha1_object_info(const unsigned char *, unsigned long *); diff --git a/help.c b/help.c index 5586e1d..8fcd644 100644 --- a/help.c +++ b/help.c @@ -9,6 +9,7 @@ #include "common-cmds.h" #include "parse-options.h" #include "run-command.h" +#include "dir.h" static struct man_viewer_list { struct man_viewer_list *next; @@ -650,6 +651,19 @@ static void get_html_page_path(struct strbuf *page_path, const char *page) strbuf_addf(page_path, "%s/%s.html", html_path, page); } +#ifdef __MINGW32__ +static void open_html_win(const char *unixpath) +{ + const char *htmlpath = make_native_separator(mkpath("%s",unixpath)); + if (!file_exists(htmlpath)) { + fprintf(stderr, "HTML file '%s' does not exist.\n", htmlpath); + exit(1); + } + printf("Launching default browser to display HTML help ...\n"); + ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0); +} +#endif + static void show_html_page(const char *git_cmd) { const char *page = cmd_to_page(git_cmd); @@ -657,7 +671,11 @@ static void show_html_page(const char *git_cmd) get_html_page_path(&page_path, page); +#ifdef __MINGW32__ + open_html_win(page_path.buf); +#else execl_git_cmd("web--browse", "-c", "help.browser", page_path.buf, NULL); +#endif } void help_unknown_cmd(const char *cmd) diff --git a/path.c b/path.c index 496123c..9f2bd91 100644 --- a/path.c +++ b/path.c @@ -343,3 +343,21 @@ const char *make_relative_path(const char *abs, const char *base) strcpy(buf, abs + baselen); return buf; } + +const char *make_native_separator(const char* path) { +#ifdef __MINGW32__ + static char buf[PATH_MAX + 1]; + char* c; + + if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX) + die ("Too long path: %.*s", 60, path); + + for (c = buf; *c; c++) { + if (*c == '/') + *c = '\\'; + } + return buf; +#else + return path; +#endif +} -- 1.5.6.1.282.gd8a0d ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path() 2008-07-04 9:09 ` [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path() Steffen Prohaska 2008-07-04 9:09 ` [PATCH 2/2] help (Windows): Display HTML in default browser using Win32 API Steffen Prohaska @ 2008-07-04 9:26 ` Junio C Hamano 2008-07-04 12:35 ` Johannes Schindelin 1 sibling, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-04 9:26 UTC (permalink / raw) To: Steffen Prohaska; +Cc: Johannes Sixt, git Steffen Prohaska <prohaska@zib.de> writes: > If htmldir (in the Makefile) is a relative path, this path will be > interpreted relative to git_exec_path. This can be used to create an > installation that can be moved to a different directory without > re-compiling. The Windows installer (msysgit) is an example for such > a setup. > ... > + const char* html_path = GIT_HTML_PATH; Style. Asterisk sticks to the variable, not type. > + if (!is_absolute_path(html_path)) { > + struct strbuf d = STRBUF_INIT; > + strbuf_addf(&d, "%s/%s", git_exec_path(), html_path); > + html_path = strbuf_detach(&d, NULL); > + } I've seen similar "if $this (which is usually an absolute) is relative, it is taken as relative to git_exec_path" solution employed elsewhere in the MinGW series, and I think it makes sense, even though initially I thought it was somewhat hacky. Could you check if there are copy-and-pasted duplicated code you can factor out before continuing this direction? I suspect templates and etc/gitconfig are specified in similar fashion, and it would probably be easier to maintain if you define once: char *system_path(const char *specified) { if (is_absolute_path(specified)) return specified; ... strbuf dance ... return strbuf_detach(...); } and use it like this: const char *html_path = system_path(GIT_HTML_PATH); ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path() 2008-07-04 9:26 ` [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path() Junio C Hamano @ 2008-07-04 12:35 ` Johannes Schindelin 2008-07-11 7:27 ` Steffen Prohaska 0 siblings, 1 reply; 371+ messages in thread From: Johannes Schindelin @ 2008-07-04 12:35 UTC (permalink / raw) To: Junio C Hamano; +Cc: Steffen Prohaska, Johannes Sixt, git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path() 2008-07-04 12:35 ` Johannes Schindelin @ 2008-07-11 7:27 ` Steffen Prohaska 2008-07-11 7:28 ` [PATCH 1/3] Move code interpreting path relative to exec-dir to new function system_path() Steffen Prohaska 2008-07-11 9:02 ` [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path() Johannes Sixt 0 siblings, 2 replies; 371+ messages in thread From: Steffen Prohaska @ 2008-07-11 7:27 UTC (permalink / raw) To: Junio C Hamano, Johannes Sixt; +Cc: Git Mailing List, Johannes Schindelin On Jul 4, 2008, at 2:35 PM, Johannes Schindelin wrote: > On Fri, 4 Jul 2008, Junio C Hamano wrote: > >> Could you check if there are copy-and-pasted duplicated code you can >> factor out before continuing this direction? > > Note also that Hannes tried very hard to get rid of those ugly "#ifdef > __MINGW32__"s by declaring/overriding functions in git-compat-util.h. > > I think that is such a good practice that we should not stop here. I'll send three patches that address Junio's and Dscho's comments: [PATCH 1/3] Move code interpreting path relative to exec-dir to new function system_path() [PATCH 2/3] help.c: Add support for htmldir relative to git_exec_path() [PATCH 3/3] help (Windows): Display HTML in default browser using Windows' shell API Hannes, the patches I'll send probably conflict with your planned work on GIT_EXEC_PATH that has been discussed on the msysgit list. I think you could built on my series and modify system_path(). Steffen ^ permalink raw reply [flat|nested] 371+ messages in thread
* [PATCH 1/3] Move code interpreting path relative to exec-dir to new function system_path() 2008-07-11 7:27 ` Steffen Prohaska @ 2008-07-11 7:28 ` Steffen Prohaska 2008-07-11 7:28 ` [PATCH 2/3] help.c: Add support for htmldir relative to git_exec_path() Steffen Prohaska 2008-07-11 9:02 ` [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path() Johannes Sixt 1 sibling, 1 reply; 371+ messages in thread From: Steffen Prohaska @ 2008-07-11 7:28 UTC (permalink / raw) To: Junio C Hamano, Johannes Sixt; +Cc: git, Johannes Schindelin, Steffen Prohaska Expanding system paths relative to git_exec_path can be used for creating an installation that can be moved to a different directory without re-compiling. We use this approach for template_dir and the system wide gitconfig. The Windows installer (msysgit) is an example for such a setup. This commit moves common code to a new function system_path(). System paths that are to be interpreted relative to git_exec_path are passed to system_path() and the return value is used instead of the original path. system_path() prefixes a relative path with git_exec_path and leaves absolute paths unmodified. For example, we now write template_dir = system_path(DEFAULT_GIT_TEMPLATE_DIR); Signed-off-by: Steffen Prohaska <prohaska@zib.de> --- builtin-init-db.c | 14 ++------------ cache.h | 1 + config.c | 11 ++--------- path.c | 11 +++++++++++ 4 files changed, 16 insertions(+), 21 deletions(-) diff --git a/builtin-init-db.c b/builtin-init-db.c index e23b843..5ba213a 100644 --- a/builtin-init-db.c +++ b/builtin-init-db.c @@ -115,18 +115,8 @@ static void copy_templates(const char *template_dir) if (!template_dir) template_dir = getenv(TEMPLATE_DIR_ENVIRONMENT); - if (!template_dir) { - /* - * if the hard-coded template is relative, it is - * interpreted relative to the exec_dir - */ - template_dir = DEFAULT_GIT_TEMPLATE_DIR; - if (!is_absolute_path(template_dir)) { - struct strbuf d = STRBUF_INIT; - strbuf_addf(&d, "%s/%s", git_exec_path(), template_dir); - template_dir = strbuf_detach(&d, NULL); - } - } + if (!template_dir) + template_dir = system_path(DEFAULT_GIT_TEMPLATE_DIR); strcpy(template_path, template_dir); template_len = strlen(template_path); if (template_path[template_len-1] != '/') { diff --git a/cache.h b/cache.h index 0d8edda..dafa265 100644 --- a/cache.h +++ b/cache.h @@ -529,6 +529,7 @@ const char *make_nonrelative_path(const char *path); const char *make_relative_path(const char *abs, const char *base); int normalize_absolute_path(char *buf, const char *path); int longest_ancestor_length(const char *path, const char *prefix_list); +extern const char *system_path(const char *path); /* Read and unpack a sha1 file into memory, write memory to a sha1 file */ extern int sha1_object_info(const unsigned char *, unsigned long *); diff --git a/config.c b/config.c index 2862cc4..1e066c7 100644 --- a/config.c +++ b/config.c @@ -581,15 +581,8 @@ int git_config_from_file(config_fn_t fn, const char *filename, void *data) const char *git_etc_gitconfig(void) { static const char *system_wide; - if (!system_wide) { - system_wide = ETC_GITCONFIG; - if (!is_absolute_path(system_wide)) { - /* interpret path relative to exec-dir */ - struct strbuf d = STRBUF_INIT; - strbuf_addf(&d, "%s/%s", git_exec_path(), system_wide); - system_wide = strbuf_detach(&d, NULL); - } - } + if (!system_wide) + system_wide = system_path(ETC_GITCONFIG); return system_wide; } diff --git a/path.c b/path.c index 5983255..141496e 100644 --- a/path.c +++ b/path.c @@ -11,6 +11,7 @@ * which is what it's designed for. */ #include "cache.h" +#include "exec_cmd.h" static char bad_path[] = "/bad-path/"; @@ -439,3 +440,13 @@ int longest_ancestor_length(const char *path, const char *prefix_list) return max_len; } + +const char *system_path(const char *path) +{ + if (!is_absolute_path(path)) { + struct strbuf d = STRBUF_INIT; + strbuf_addf(&d, "%s/%s", git_exec_path(), path); + path = strbuf_detach(&d, NULL); + } + return path; +} -- 1.5.6.1.282.gd8a0d ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH 2/3] help.c: Add support for htmldir relative to git_exec_path() 2008-07-11 7:28 ` [PATCH 1/3] Move code interpreting path relative to exec-dir to new function system_path() Steffen Prohaska @ 2008-07-11 7:28 ` Steffen Prohaska 2008-07-11 7:28 ` [PATCH 3/3] help (Windows): Display HTML in default browser using Windows' shell API Steffen Prohaska 0 siblings, 1 reply; 371+ messages in thread From: Steffen Prohaska @ 2008-07-11 7:28 UTC (permalink / raw) To: Junio C Hamano, Johannes Sixt; +Cc: git, Johannes Schindelin, Steffen Prohaska If htmldir (in the Makefile) is a relative path, this path will now be interpreted relative to git_exec_path. This can be used to create an installation that can be moved to a different directory without re-compiling. The Windows installer (msysgit) is an example for such a setup. Note that the Makefile maps htmldir to the define GIT_HTML_PATH. Signed-off-by: Steffen Prohaska <prohaska@zib.de> --- help.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/help.c b/help.c index ca9632b..0f055bf 100644 --- a/help.c +++ b/help.c @@ -633,13 +633,15 @@ static void show_info_page(const char *git_cmd) static void get_html_page_path(struct strbuf *page_path, const char *page) { struct stat st; + const char *html_path = system_path(GIT_HTML_PATH); /* Check that we have a git documentation directory. */ - if (stat(GIT_HTML_PATH "/git.html", &st) || !S_ISREG(st.st_mode)) - die("'%s': not a documentation directory.", GIT_HTML_PATH); + if (stat(mkpath("%s/git.html", html_path), &st) + || !S_ISREG(st.st_mode)) + die("'%s': not a documentation directory.", html_path); strbuf_init(page_path, 0); - strbuf_addf(page_path, GIT_HTML_PATH "/%s.html", page); + strbuf_addf(page_path, "%s/%s.html", html_path, page); } static void show_html_page(const char *git_cmd) -- 1.5.6.1.282.gd8a0d ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH 3/3] help (Windows): Display HTML in default browser using Windows' shell API 2008-07-11 7:28 ` [PATCH 2/3] help.c: Add support for htmldir relative to git_exec_path() Steffen Prohaska @ 2008-07-11 7:28 ` Steffen Prohaska 2008-07-11 7:35 ` Steffen Prohaska 0 siblings, 1 reply; 371+ messages in thread From: Steffen Prohaska @ 2008-07-11 7:28 UTC (permalink / raw) To: Junio C Hamano, Johannes Sixt; +Cc: git, Johannes Schindelin, Steffen Prohaska The system's default browser for displaying HTML help pages is now used directly on Windows, instead of launching git-web--browser, which requires a Unix shell. Avoiding MSYS' bash when possible is good because it avoids potential path translation issues. In this case it is not too hard to avoid launching a shell, so let's avoid it. The Windows-specific code is implemented in compat/mingw.c to avoid platform-specific code in the main code base. On Windows, open_html is provided as a define. If open_html is not defined, git-web--browse is used. This approach avoids platform-specific ifdefs by using per-function ifdefs. The "ifndef open_html" together with the introductory comment should sufficiently warn developers, so that they hopefully will not break this mechanism. Signed-off-by: Steffen Prohaska <prohaska@zib.de> --- compat/mingw.c | 21 +++++++++++++++++++++ compat/mingw.h | 3 +++ help.c | 14 +++++++++++++- 3 files changed, 37 insertions(+), 1 deletions(-) diff --git a/compat/mingw.c b/compat/mingw.c index 3a05fe7..f7ef545 100644 --- a/compat/mingw.c +++ b/compat/mingw.c @@ -1017,3 +1017,24 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler) timer_fn = handler; return old; } + +static const char *make_backslash_path(const char* path) { + static char buf[PATH_MAX + 1]; + char* c; + + if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX) + die ("Too long path: %.*s", 60, path); + + for (c = buf; *c; c++) { + if (*c == '/') + *c = '\\'; + } + return buf; +} + +void mingw_open_html(const char *unixpath) +{ + const char *htmlpath = make_backslash_path(unixpath); + printf("Launching default browser to display HTML ...\n"); + ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0); +} diff --git a/compat/mingw.h b/compat/mingw.h index 6bc049a..136361e 100644 --- a/compat/mingw.h +++ b/compat/mingw.h @@ -193,6 +193,9 @@ static inline unsigned int git_ntohl(unsigned int x) sig_handler_t mingw_signal(int sig, sig_handler_t handler); #define signal mingw_signal +void mingw_open_html(const char *path); +#define open_html mingw_open_html + /* * git specific compatibility */ diff --git a/help.c b/help.c index 0f055bf..18116f3 100644 --- a/help.c +++ b/help.c @@ -644,6 +644,18 @@ static void get_html_page_path(struct strbuf *page_path, const char *page) strbuf_addf(page_path, "%s/%s.html", html_path, page); } +/* + * If open_html is not defined in a platform-specific way (see for + * example compat/mingw.h), we use the script web--browse to display + * HTML. + */ +#ifndef open_html +void open_html(const char* path) +{ + execl_git_cmd("web--browse", "-c", "help.browser", path, NULL); +} +#endif + static void show_html_page(const char *git_cmd) { const char *page = cmd_to_page(git_cmd); @@ -651,7 +663,7 @@ static void show_html_page(const char *git_cmd) get_html_page_path(&page_path, page); - execl_git_cmd("web--browse", "-c", "help.browser", page_path.buf, NULL); + open_html(page_path.buf); } void help_unknown_cmd(const char *cmd) -- 1.5.6.1.282.gd8a0d ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH 3/3] help (Windows): Display HTML in default browser using Windows' shell API 2008-07-11 7:28 ` [PATCH 3/3] help (Windows): Display HTML in default browser using Windows' shell API Steffen Prohaska @ 2008-07-11 7:35 ` Steffen Prohaska 2008-07-11 7:37 ` [PATCH 3/3 FIXED] " Steffen Prohaska 0 siblings, 1 reply; 371+ messages in thread From: Steffen Prohaska @ 2008-07-11 7:35 UTC (permalink / raw) To: Junio C Hamano; +Cc: Johannes Sixt, Git Mailing List, Johannes Schindelin 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API 2008-07-11 7:35 ` Steffen Prohaska @ 2008-07-11 7:37 ` Steffen Prohaska 2008-07-12 3:26 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Steffen Prohaska @ 2008-07-11 7:37 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, Johannes Schindelin, Johannes Sixt, Steffen Prohaska The system's default browser for displaying HTML help pages is now used directly on Windows, instead of launching git-web--browser, which requires a Unix shell. Avoiding MSYS' bash when possible is good because it avoids potential path translation issues. In this case it is not too hard to avoid launching a shell, so let's avoid it. The Windows-specific code is implemented in compat/mingw.c to avoid platform-specific code in the main code base. On Windows, open_html is provided as a define. If open_html is not defined, git-web--browse is used. This approach avoids platform-specific ifdefs by using per-function ifdefs. The "ifndef open_html" together with the introductory comment should sufficiently warn developers, so that they hopefully will not break this mechanism. Signed-off-by: Steffen Prohaska <prohaska@zib.de> --- compat/mingw.c | 21 +++++++++++++++++++++ compat/mingw.h | 3 +++ help.c | 14 +++++++++++++- 3 files changed, 37 insertions(+), 1 deletions(-) diff --git a/compat/mingw.c b/compat/mingw.c index 3a05fe7..0ca73f7 100644 --- a/compat/mingw.c +++ b/compat/mingw.c @@ -1017,3 +1017,24 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler) timer_fn = handler; return old; } + +static const char *make_backslash_path(const char *path) { + static char buf[PATH_MAX + 1]; + char *c; + + if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX) + die ("Too long path: %.*s", 60, path); + + for (c = buf; *c; c++) { + if (*c == '/') + *c = '\\'; + } + return buf; +} + +void mingw_open_html(const char *unixpath) +{ + const char *htmlpath = make_backslash_path(unixpath); + printf("Launching default browser to display HTML ...\n"); + ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0); +} diff --git a/compat/mingw.h b/compat/mingw.h index 6bc049a..136361e 100644 --- a/compat/mingw.h +++ b/compat/mingw.h @@ -193,6 +193,9 @@ static inline unsigned int git_ntohl(unsigned int x) sig_handler_t mingw_signal(int sig, sig_handler_t handler); #define signal mingw_signal +void mingw_open_html(const char *path); +#define open_html mingw_open_html + /* * git specific compatibility */ diff --git a/help.c b/help.c index 0f055bf..52d39b8 100644 --- a/help.c +++ b/help.c @@ -644,6 +644,18 @@ static void get_html_page_path(struct strbuf *page_path, const char *page) strbuf_addf(page_path, "%s/%s.html", html_path, page); } +/* + * If open_html is not defined in a platform-specific way (see for + * example compat/mingw.h), we use the script web--browse to display + * HTML. + */ +#ifndef open_html +void open_html(const char *path) +{ + execl_git_cmd("web--browse", "-c", "help.browser", path, NULL); +} +#endif + static void show_html_page(const char *git_cmd) { const char *page = cmd_to_page(git_cmd); @@ -651,7 +663,7 @@ static void show_html_page(const char *git_cmd) get_html_page_path(&page_path, page); - execl_git_cmd("web--browse", "-c", "help.browser", page_path.buf, NULL); + open_html(page_path.buf); } void help_unknown_cmd(const char *cmd) -- 1.5.6.1.282.gd8a0d ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API 2008-07-11 7:37 ` [PATCH 3/3 FIXED] " Steffen Prohaska @ 2008-07-12 3:26 ` Junio C Hamano 2008-07-12 6:45 ` Steffen Prohaska 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-12 3:26 UTC (permalink / raw) To: Steffen Prohaska; +Cc: git, Johannes Schindelin, Johannes Sixt 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? ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API 2008-07-12 3:26 ` Junio C Hamano @ 2008-07-12 6:45 ` Steffen Prohaska 2008-07-12 7:07 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Steffen Prohaska @ 2008-07-12 6:45 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, Johannes Schindelin, Johannes Sixt On Jul 12, 2008, at 5:26 AM, Junio C Hamano wrote: > Steffen Prohaska <prohaska@zib.de> writes: > >> diff --git a/compat/mingw.c b/compat/mingw.c >> index 3a05fe7..0ca73f7 100644 >> --- a/compat/mingw.c >> +++ b/compat/mingw.c >> @@ -1017,3 +1017,24 @@ sig_handler_t mingw_signal(int sig, >> sig_handler_t handler) >> ... >> +void mingw_open_html(const char *unixpath) >> +{ >> + const char *htmlpath = make_backslash_path(unixpath); >> + printf("Launching default browser to display HTML ...\n"); >> + ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0); >> +} > > Do you mean to have that printf() or is it a leftover debugging > statement? I mean to have it. It takes some time until a fresh browser starts up if no browser has been running before. Impatient people (like me) could start believing that nothing would happen. But this certainly depends on your machine. I run Windows inside a virtual machine on a Laptop, which is probably rather slow compared to a desktop machine running Windows natively. Steffen ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API 2008-07-12 6:45 ` Steffen Prohaska @ 2008-07-12 7:07 ` Junio C Hamano 2008-07-12 20:41 ` Johannes Sixt 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-12 7:07 UTC (permalink / raw) To: Steffen Prohaska; +Cc: git, Johannes Schindelin, Johannes Sixt 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API 2008-07-12 7:07 ` Junio C Hamano @ 2008-07-12 20:41 ` Johannes Sixt 2008-07-13 8:58 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Johannes Sixt @ 2008-07-12 20:41 UTC (permalink / raw) To: Junio C Hamano; +Cc: Steffen Prohaska, git, Johannes Schindelin Zitat von Junio C Hamano <gitster@pobox.com>: > Steffen Prohaska <prohaska@zib.de> writes: > > >> Do you mean to have that printf() or is it a leftover debugging > >> statement? > > > > I mean to have it. > > Ok, I was just checking. Unless other Windows users complain, will apply > as-is. As you might guess, I am completely neutral on this one. I'm working on followups to this series, and it turns out to be more convenient to have system_path() in exec_cmd.c instead of path.c. It'll make sense if I resend the series with an updated version of 1/3 (instead of a patch that merely moves the function around). -- Hannes ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 3/3 FIXED] help (Windows): Display HTML in default browser using Windows' shell API 2008-07-12 20:41 ` Johannes Sixt @ 2008-07-13 8:58 ` Junio C Hamano 2008-07-13 20:31 ` [PATCH] Move code interpreting path relative to exec-dir to new function system_path() Johannes Sixt 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-13 8:58 UTC (permalink / raw) To: Johannes Sixt; +Cc: Steffen Prohaska, git, Johannes Schindelin Johannes Sixt <johannes.sixt@telecom.at> writes: > Zitat von Junio C Hamano <gitster@pobox.com>: > >> Steffen Prohaska <prohaska@zib.de> writes: >> >> >> Do you mean to have that printf() or is it a leftover debugging >> >> statement? >> > >> > I mean to have it. >> >> Ok, I was just checking. Unless other Windows users complain, will apply >> as-is. As you might guess, I am completely neutral on this one. > > I'm working on followups to this series, and it turns out to be more > convenient to have system_path() in exec_cmd.c instead of path.c. > It'll make sense if I resend the series with an updated version of 1/3 > (instead of a patch that merely moves the function around). Ok, will drop these three patches and wait for replacement from yours to appear, and then we will see which ones to apply. ^ permalink raw reply [flat|nested] 371+ messages in thread
* [PATCH] Move code interpreting path relative to exec-dir to new function system_path() 2008-07-13 8:58 ` Junio C Hamano @ 2008-07-13 20:31 ` Johannes Sixt 2008-07-13 20:31 ` [PATCH] help.c: Add support for htmldir relative to git_exec_path() Johannes Sixt 0 siblings, 1 reply; 371+ messages in thread From: Johannes Sixt @ 2008-07-13 20:31 UTC (permalink / raw) To: Junio C Hamano; +Cc: Steffen Prohaska, git, Johannes Schindelin, Johannes Sixt From: Steffen Prohaska <prohaska@zib.de> Expanding system paths relative to git_exec_path can be used for creating an installation that can be moved to a different directory without re-compiling. We use this approach for template_dir and the system wide gitconfig. The Windows installer (msysgit) is an example for such a setup. This commit moves common code to a new function system_path(). System paths that are to be interpreted relative to git_exec_path are passed to system_path() and the return value is used instead of the original path. system_path() prefixes a relative path with git_exec_path and leaves absolute paths unmodified. For example, we now write template_dir = system_path(DEFAULT_GIT_TEMPLATE_DIR); [j6t: moved from path.c to exec_cmd.c] Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> --- builtin-init-db.c | 14 ++------------ config.c | 11 ++--------- exec_cmd.c | 10 ++++++++++ exec_cmd.h | 2 +- 4 files changed, 15 insertions(+), 22 deletions(-) diff --git a/builtin-init-db.c b/builtin-init-db.c index e23b843..5ba213a 100644 --- a/builtin-init-db.c +++ b/builtin-init-db.c @@ -115,18 +115,8 @@ static void copy_templates(const char *template_dir) if (!template_dir) template_dir = getenv(TEMPLATE_DIR_ENVIRONMENT); - if (!template_dir) { - /* - * if the hard-coded template is relative, it is - * interpreted relative to the exec_dir - */ - template_dir = DEFAULT_GIT_TEMPLATE_DIR; - if (!is_absolute_path(template_dir)) { - struct strbuf d = STRBUF_INIT; - strbuf_addf(&d, "%s/%s", git_exec_path(), template_dir); - template_dir = strbuf_detach(&d, NULL); - } - } + if (!template_dir) + template_dir = system_path(DEFAULT_GIT_TEMPLATE_DIR); strcpy(template_path, template_dir); template_len = strlen(template_path); if (template_path[template_len-1] != '/') { diff --git a/config.c b/config.c index 2862cc4..1e066c7 100644 --- a/config.c +++ b/config.c @@ -581,15 +581,8 @@ int git_config_from_file(config_fn_t fn, const char *filename, void *data) const char *git_etc_gitconfig(void) { static const char *system_wide; - if (!system_wide) { - system_wide = ETC_GITCONFIG; - if (!is_absolute_path(system_wide)) { - /* interpret path relative to exec-dir */ - struct strbuf d = STRBUF_INIT; - strbuf_addf(&d, "%s/%s", git_exec_path(), system_wide); - system_wide = strbuf_detach(&d, NULL); - } - } + if (!system_wide) + system_wide = system_path(ETC_GITCONFIG); return system_wide; } diff --git a/exec_cmd.c b/exec_cmd.c index da04efe..8899e31 100644 --- a/exec_cmd.c +++ b/exec_cmd.c @@ -40,6 +40,16 @@ static const char *builtin_exec_path(void) #endif } +const char *system_path(const char *path) +{ + if (!is_absolute_path(path)) { + struct strbuf d = STRBUF_INIT; + strbuf_addf(&d, "%s/%s", git_exec_path(), path); + path = strbuf_detach(&d, NULL); + } + return path; +} + void git_set_argv_exec_path(const char *exec_path) { argv_exec_path = exec_path; diff --git a/exec_cmd.h b/exec_cmd.h index a892355..7eb94e5 100644 --- a/exec_cmd.h +++ b/exec_cmd.h @@ -6,6 +6,6 @@ extern const char* git_exec_path(void); extern void setup_path(const char *); extern int execv_git_cmd(const char **argv); /* NULL terminated */ extern int execl_git_cmd(const char *cmd, ...); - +extern const char *system_path(const char *path); #endif /* GIT_EXEC_CMD_H */ -- 1.5.6.2.300.ga3a9 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH] help.c: Add support for htmldir relative to git_exec_path() 2008-07-13 20:31 ` [PATCH] Move code interpreting path relative to exec-dir to new function system_path() Johannes Sixt @ 2008-07-13 20:31 ` Johannes Sixt 2008-07-13 20:31 ` [PATCH] help (Windows): Display HTML in default browser using Windows' shell API Johannes Sixt 0 siblings, 1 reply; 371+ messages in thread From: Johannes Sixt @ 2008-07-13 20:31 UTC (permalink / raw) To: Junio C Hamano; +Cc: Steffen Prohaska, git, Johannes Schindelin, Johannes Sixt From: Steffen Prohaska <prohaska@zib.de> If htmldir (in the Makefile) is a relative path, this path will now be interpreted relative to git_exec_path. This can be used to create an installation that can be moved to a different directory without re-compiling. The Windows installer (msysgit) is an example for such a setup. Note that the Makefile maps htmldir to the define GIT_HTML_PATH. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> --- help.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/help.c b/help.c index ca9632b..0f055bf 100644 --- a/help.c +++ b/help.c @@ -633,13 +633,15 @@ static void show_info_page(const char *git_cmd) static void get_html_page_path(struct strbuf *page_path, const char *page) { struct stat st; + const char *html_path = system_path(GIT_HTML_PATH); /* Check that we have a git documentation directory. */ - if (stat(GIT_HTML_PATH "/git.html", &st) || !S_ISREG(st.st_mode)) - die("'%s': not a documentation directory.", GIT_HTML_PATH); + if (stat(mkpath("%s/git.html", html_path), &st) + || !S_ISREG(st.st_mode)) + die("'%s': not a documentation directory.", html_path); strbuf_init(page_path, 0); - strbuf_addf(page_path, GIT_HTML_PATH "/%s.html", page); + strbuf_addf(page_path, "%s/%s.html", html_path, page); } static void show_html_page(const char *git_cmd) -- 1.5.6.2.300.ga3a9 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH] help (Windows): Display HTML in default browser using Windows' shell API 2008-07-13 20:31 ` [PATCH] help.c: Add support for htmldir relative to git_exec_path() Johannes Sixt @ 2008-07-13 20:31 ` Johannes Sixt 2008-07-13 20:31 ` [PATCH] Fix relative built-in paths to be relative to the command invocation Johannes Sixt 0 siblings, 1 reply; 371+ messages in thread From: Johannes Sixt @ 2008-07-13 20:31 UTC (permalink / raw) To: Junio C Hamano; +Cc: Steffen Prohaska, git, Johannes Schindelin, Johannes Sixt From: Steffen Prohaska <prohaska@zib.de> The system's default browser for displaying HTML help pages is now used directly on Windows, instead of launching git-web--browser, which requires a Unix shell. Avoiding MSYS' bash when possible is good because it avoids potential path translation issues. In this case it is not too hard to avoid launching a shell, so let's avoid it. The Windows-specific code is implemented in compat/mingw.c to avoid platform-specific code in the main code base. On Windows, open_html is provided as a define. If open_html is not defined, git-web--browse is used. This approach avoids platform-specific ifdefs by using per-function ifdefs. The "ifndef open_html" together with the introductory comment should sufficiently warn developers, so that they hopefully will not break this mechanism. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> --- compat/mingw.c | 21 +++++++++++++++++++++ compat/mingw.h | 3 +++ help.c | 14 +++++++++++++- 3 files changed, 37 insertions(+), 1 deletions(-) diff --git a/compat/mingw.c b/compat/mingw.c index 3a05fe7..0ca73f7 100644 --- a/compat/mingw.c +++ b/compat/mingw.c @@ -1017,3 +1017,24 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler) timer_fn = handler; return old; } + +static const char *make_backslash_path(const char *path) { + static char buf[PATH_MAX + 1]; + char *c; + + if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX) + die ("Too long path: %.*s", 60, path); + + for (c = buf; *c; c++) { + if (*c == '/') + *c = '\\'; + } + return buf; +} + +void mingw_open_html(const char *unixpath) +{ + const char *htmlpath = make_backslash_path(unixpath); + printf("Launching default browser to display HTML ...\n"); + ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0); +} diff --git a/compat/mingw.h b/compat/mingw.h index 6bc049a..5a3bcee 100644 --- a/compat/mingw.h +++ b/compat/mingw.h @@ -202,6 +202,9 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler); #define PATH_SEP ';' #define PRIuMAX "I64u" +void mingw_open_html(const char *path); +#define open_html mingw_open_html + /* * helpers */ diff --git a/help.c b/help.c index 0f055bf..52d39b8 100644 --- a/help.c +++ b/help.c @@ -644,6 +644,18 @@ static void get_html_page_path(struct strbuf *page_path, const char *page) strbuf_addf(page_path, "%s/%s.html", html_path, page); } +/* + * If open_html is not defined in a platform-specific way (see for + * example compat/mingw.h), we use the script web--browse to display + * HTML. + */ +#ifndef open_html +void open_html(const char *path) +{ + execl_git_cmd("web--browse", "-c", "help.browser", path, NULL); +} +#endif + static void show_html_page(const char *git_cmd) { const char *page = cmd_to_page(git_cmd); @@ -651,7 +663,7 @@ static void show_html_page(const char *git_cmd) get_html_page_path(&page_path, page); - execl_git_cmd("web--browse", "-c", "help.browser", page_path.buf, NULL); + open_html(page_path.buf); } void help_unknown_cmd(const char *cmd) -- 1.5.6.2.300.ga3a9 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH] Fix relative built-in paths to be relative to the command invocation 2008-07-13 20:31 ` [PATCH] help (Windows): Display HTML in default browser using Windows' shell API Johannes Sixt @ 2008-07-13 20:31 ` Johannes Sixt 2008-07-13 20:31 ` [PATCH] Allow the built-in exec path to be relative to the command invocation path Johannes Sixt 2008-07-13 20:43 ` [PATCH] Fix relative built-in paths to be relative to the command invocation Johannes Schindelin 0 siblings, 2 replies; 371+ messages in thread From: Johannes Sixt @ 2008-07-13 20:31 UTC (permalink / raw) To: Junio C Hamano; +Cc: Steffen Prohaska, git, Johannes Schindelin, Johannes Sixt $(gitexecdir) (as defined in the Makefile) has gained another path component, but the relative paths in the MINGW section of the Makefile, which are interpreted relative to it, do not account for it. Instead of adding another ../ in front of the path, we change the code that constructs the absolute paths to do it relative to the command's directory, which is essentially $(bindir). We do it this way because we will also allow a relative $(gitexecdir) later. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> --- Makefile | 2 +- exec_cmd.c | 14 ++++++++++---- exec_cmd.h | 3 ++- git.c | 5 ++--- receive-pack.c | 2 +- shell.c | 4 ++-- upload-pack.c | 2 +- 7 files changed, 19 insertions(+), 13 deletions(-) diff --git a/Makefile b/Makefile index 4796565..2bdb9bf 100644 --- a/Makefile +++ b/Makefile @@ -1301,7 +1301,7 @@ remove-dashes: ### Installation rules ifeq ($(firstword $(subst /, ,$(template_dir))),..) -template_instdir = $(gitexecdir)/$(template_dir) +template_instdir = $(shell cd '$(bindir_SQ)/$(template_dir_SQ)' && pwd) else template_instdir = $(template_dir) endif diff --git a/exec_cmd.c b/exec_cmd.c index 8899e31..45f92eb 100644 --- a/exec_cmd.c +++ b/exec_cmd.c @@ -5,6 +5,7 @@ extern char **environ; static const char *argv_exec_path; +static const char *argv0_path; static const char *builtin_exec_path(void) { @@ -42,14 +43,19 @@ static const char *builtin_exec_path(void) const char *system_path(const char *path) { - if (!is_absolute_path(path)) { + if (!is_absolute_path(path) && argv0_path) { struct strbuf d = STRBUF_INIT; - strbuf_addf(&d, "%s/%s", git_exec_path(), path); + strbuf_addf(&d, "%s/%s", argv0_path, path); path = strbuf_detach(&d, NULL); } return path; } +void git_set_argv0_path(const char *path) +{ + argv0_path = path; +} + void git_set_argv_exec_path(const char *exec_path) { argv_exec_path = exec_path; @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char *path) } } -void setup_path(const char *cmd_path) +void setup_path(void) { const char *old_path = getenv("PATH"); struct strbuf new_path; @@ -94,7 +100,7 @@ void setup_path(const char *cmd_path) add_path(&new_path, argv_exec_path); add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT)); add_path(&new_path, builtin_exec_path()); - add_path(&new_path, cmd_path); + add_path(&new_path, argv0_path); if (old_path) strbuf_addstr(&new_path, old_path); diff --git a/exec_cmd.h b/exec_cmd.h index 7eb94e5..0c46cd5 100644 --- a/exec_cmd.h +++ b/exec_cmd.h @@ -2,8 +2,9 @@ #define GIT_EXEC_CMD_H extern void git_set_argv_exec_path(const char *exec_path); +extern void git_set_argv0_path(const char *path); extern const char* git_exec_path(void); -extern void setup_path(const char *); +extern void setup_path(void); extern int execv_git_cmd(const char **argv); /* NULL terminated */ extern int execl_git_cmd(const char *cmd, ...); extern const char *system_path(const char *path); diff --git a/git.c b/git.c index 7075533..b90c358 100644 --- a/git.c +++ b/git.c @@ -470,7 +470,6 @@ int main(int argc, const char **argv) { const char *cmd = argv[0] && *argv[0] ? argv[0] : "git-help"; char *slash = (char *)cmd + strlen(cmd); - const char *cmd_path = NULL; int done_alias = 0; /* @@ -483,7 +482,7 @@ int main(int argc, const char **argv) while (cmd <= slash && !is_dir_sep(*slash)); if (cmd <= slash) { *slash++ = 0; - cmd_path = cmd; + git_set_argv0_path(cmd); cmd = slash; } @@ -527,7 +526,7 @@ int main(int argc, const char **argv) * environment, and the $(gitexecdir) from the Makefile at build * time. */ - setup_path(cmd_path); + setup_path(); while (1) { /* See if it's an internal command */ diff --git a/receive-pack.c b/receive-pack.c index fa653b4..d44c19e 100644 --- a/receive-pack.c +++ b/receive-pack.c @@ -482,7 +482,7 @@ int main(int argc, char **argv) if (!dir) usage(receive_pack_usage); - setup_path(NULL); + setup_path(); if (!enter_repo(dir, 0)) die("'%s': unable to chdir or not a git archive", dir); diff --git a/shell.c b/shell.c index 91ca7de..6a48de0 100644 --- a/shell.c +++ b/shell.c @@ -15,7 +15,7 @@ static int do_generic_cmd(const char *me, char *arg) { const char *my_argv[4]; - setup_path(NULL); + setup_path(); if (!arg || !(arg = sq_dequote(arg))) die("bad argument"); if (prefixcmp(me, "git-")) @@ -37,7 +37,7 @@ static int do_cvs_cmd(const char *me, char *arg) if (!arg || strcmp(arg, "server")) die("git-cvsserver only handles server: %s", arg); - setup_path(NULL); + setup_path(); return execv_git_cmd(cvsserver_argv); } diff --git a/upload-pack.c b/upload-pack.c index 9f82941..c911e70 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -638,7 +638,7 @@ int main(int argc, char **argv) if (i != argc-1) usage(upload_pack_usage); - setup_path(NULL); + setup_path(); dir = argv[i]; -- 1.5.6.2.300.ga3a9 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH] Allow the built-in exec path to be relative to the command invocation path 2008-07-13 20:31 ` [PATCH] Fix relative built-in paths to be relative to the command invocation Johannes Sixt @ 2008-07-13 20:31 ` Johannes Sixt 2008-07-13 20:31 ` [PATCH] Allow add_path() to add non-existent directories to the path Johannes Sixt 2008-07-13 20:45 ` [PATCH] Allow the built-in exec path to be relative to the command invocation path Johannes Schindelin 2008-07-13 20:43 ` [PATCH] Fix relative built-in paths to be relative to the command invocation Johannes Schindelin 1 sibling, 2 replies; 371+ messages in thread From: Johannes Sixt @ 2008-07-13 20:31 UTC (permalink / raw) To: Junio C Hamano; +Cc: Steffen Prohaska, git, Johannes Schindelin, Johannes Sixt If GIT_EXEC_PATH (the macro that is defined in the Makefile) is relative, it is interpreted relative to the command's invocation path, which usually is $(bindir). The Makefile rules were written with the assumption that $(gitexecdir) is an absolute path. We introduce a separate variable that names the (absolute) installation directory. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> --- Makefile | 23 +++++++++++++++-------- exec_cmd.c | 38 ++------------------------------------ 2 files changed, 17 insertions(+), 44 deletions(-) diff --git a/Makefile b/Makefile index 2bdb9bf..3593e6f 100644 --- a/Makefile +++ b/Makefile @@ -1307,10 +1307,17 @@ template_instdir = $(template_dir) endif export template_instdir +ifeq ($(firstword $(subst /, ,$(gitexecdir))),..) +gitexec_instdir = $(shell cd '$(bindir_SQ)/$(gitexecdir_SQ)' && pwd) +else +gitexec_instdir = $(gitexecdir) +endif +gitexec_instdir_SQ = $(subst ','\'',$(gitexec_instdir)) + install: all $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)' - $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)' - $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)' + $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' + $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' $(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X '$(DESTDIR_SQ)$(bindir_SQ)' $(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install $(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install @@ -1318,18 +1325,18 @@ ifndef NO_TCLTK $(MAKE) -C gitk-git install $(MAKE) -C git-gui install endif - if test 'z$(bindir_SQ)' != 'z$(gitexecdir_SQ)'; \ + if test 'z$(bindir_SQ)' != 'z$(gitexec_instdir_SQ)'; \ then \ ln -f '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \ - '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' || \ + '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/git$X' || \ cp '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \ - '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \ + '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/git$X'; \ fi - $(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;) + $(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p' ;) ifneq (,$X) - $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';) + $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p';) endif - ./check_bindir 'z$(bindir_SQ)' 'z$(gitexecdir_SQ)' '$(DESTDIR_SQ)$(bindir_SQ)/git-shell$X' + ./check_bindir 'z$(bindir_SQ)' 'z$(gitexec_instdir_SQ)' '$(DESTDIR_SQ)$(bindir_SQ)/git-shell$X' install-doc: $(MAKE) -C Documentation install diff --git a/exec_cmd.c b/exec_cmd.c index 45f92eb..c236034 100644 --- a/exec_cmd.c +++ b/exec_cmd.c @@ -7,40 +7,6 @@ extern char **environ; static const char *argv_exec_path; static const char *argv0_path; -static const char *builtin_exec_path(void) -{ -#ifndef __MINGW32__ - return GIT_EXEC_PATH; -#else - int len; - char *p, *q, *sl; - static char *ep; - if (ep) - return ep; - - len = strlen(_pgmptr); - if (len < 2) - return ep = "."; - - p = ep = xmalloc(len+1); - q = _pgmptr; - sl = NULL; - /* copy program name, turn '\\' into '/', skip last part */ - while ((*p = *q)) { - if (*q == '\\' || *q == '/') { - *p = '/'; - sl = p; - } - p++, q++; - } - if (sl) - *sl = '\0'; - else - ep[0] = '.', ep[1] = '\0'; - return ep; -#endif -} - const char *system_path(const char *path) { if (!is_absolute_path(path) && argv0_path) { @@ -75,7 +41,7 @@ const char *git_exec_path(void) return env; } - return builtin_exec_path(); + return system_path(GIT_EXEC_PATH); } static void add_path(struct strbuf *out, const char *path) @@ -99,7 +65,7 @@ void setup_path(void) add_path(&new_path, argv_exec_path); add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT)); - add_path(&new_path, builtin_exec_path()); + add_path(&new_path, system_path(GIT_EXEC_PATH)); add_path(&new_path, argv0_path); if (old_path) -- 1.5.6.2.300.ga3a9 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH] Allow add_path() to add non-existent directories to the path 2008-07-13 20:31 ` [PATCH] Allow the built-in exec path to be relative to the command invocation path Johannes Sixt @ 2008-07-13 20:31 ` Johannes Sixt 2008-07-14 7:13 ` Johannes Sixt 2008-07-13 20:45 ` [PATCH] Allow the built-in exec path to be relative to the command invocation path Johannes Schindelin 1 sibling, 1 reply; 371+ messages in thread From: Johannes Sixt @ 2008-07-13 20:31 UTC (permalink / raw) To: Junio C Hamano; +Cc: Steffen Prohaska, git, Johannes Schindelin, Johannes Sixt This function had used make_absolute_path(); but this function dies if the directory that contains the entry whose relative path was supplied in the argument does not exist. This is a problem if the argument is, for example, "../libexec/git-core", and that "../libexec" does not exist. Since the resolution of symbolic links is not required for elements in PATH, we can fall back to using make_nonrelative_path(), which simply prepends $PWD to the path. We have to move make_nonrelative_path() alongside make_absolute_path() in abspath.c so that git-shell can be linked. See 5b8e6f85f. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> --- abspath.c | 36 ++++++++++++++++++++++++++++++++++++ exec_cmd.c | 2 +- path.c | 36 ------------------------------------ 3 files changed, 37 insertions(+), 37 deletions(-) diff --git a/abspath.c b/abspath.c index 4f95a95..99ee1af 100644 --- a/abspath.c +++ b/abspath.c @@ -66,3 +66,39 @@ const char *make_absolute_path(const char *path) return buf; } + +static const char *get_pwd_cwd(void) +{ + static char cwd[PATH_MAX + 1]; + char *pwd; + struct stat cwd_stat, pwd_stat; + if (getcwd(cwd, PATH_MAX) == NULL) + return NULL; + pwd = getenv("PWD"); + if (pwd && strcmp(pwd, cwd)) { + stat(cwd, &cwd_stat); + if (!stat(pwd, &pwd_stat) && + pwd_stat.st_dev == cwd_stat.st_dev && + pwd_stat.st_ino == cwd_stat.st_ino) { + strlcpy(cwd, pwd, PATH_MAX); + } + } + return cwd; +} + +const char *make_nonrelative_path(const char *path) +{ + static char buf[PATH_MAX + 1]; + + if (is_absolute_path(path)) { + if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX) + die ("Too long path: %.*s", 60, path); + } else { + const char *cwd = get_pwd_cwd(); + if (!cwd) + die("Cannot determine the current working directory"); + if (snprintf(buf, PATH_MAX, "%s/%s", cwd, path) >= PATH_MAX) + die ("Too long path: %.*s", 60, path); + } + return buf; +} diff --git a/exec_cmd.c b/exec_cmd.c index c236034..0ed768d 100644 --- a/exec_cmd.c +++ b/exec_cmd.c @@ -50,7 +50,7 @@ static void add_path(struct strbuf *out, const char *path) if (is_absolute_path(path)) strbuf_addstr(out, path); else - strbuf_addstr(out, make_absolute_path(path)); + strbuf_addstr(out, make_nonrelative_path(path)); strbuf_addch(out, PATH_SEP); } diff --git a/path.c b/path.c index 5983255..16c1d01 100644 --- a/path.c +++ b/path.c @@ -291,42 +291,6 @@ int adjust_shared_perm(const char *path) return 0; } -static const char *get_pwd_cwd(void) -{ - static char cwd[PATH_MAX + 1]; - char *pwd; - struct stat cwd_stat, pwd_stat; - if (getcwd(cwd, PATH_MAX) == NULL) - return NULL; - pwd = getenv("PWD"); - if (pwd && strcmp(pwd, cwd)) { - stat(cwd, &cwd_stat); - if (!stat(pwd, &pwd_stat) && - pwd_stat.st_dev == cwd_stat.st_dev && - pwd_stat.st_ino == cwd_stat.st_ino) { - strlcpy(cwd, pwd, PATH_MAX); - } - } - return cwd; -} - -const char *make_nonrelative_path(const char *path) -{ - static char buf[PATH_MAX + 1]; - - if (is_absolute_path(path)) { - if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX) - die ("Too long path: %.*s", 60, path); - } else { - const char *cwd = get_pwd_cwd(); - if (!cwd) - die("Cannot determine the current working directory"); - if (snprintf(buf, PATH_MAX, "%s/%s", cwd, path) >= PATH_MAX) - die ("Too long path: %.*s", 60, path); - } - return buf; -} - const char *make_relative_path(const char *abs, const char *base) { static char buf[PATH_MAX + 1]; -- 1.5.6.2.300.ga3a9 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH] Allow add_path() to add non-existent directories to the path 2008-07-13 20:31 ` [PATCH] Allow add_path() to add non-existent directories to the path Johannes Sixt @ 2008-07-14 7:13 ` Johannes Sixt 0 siblings, 0 replies; 371+ messages in thread From: Johannes Sixt @ 2008-07-14 7:13 UTC (permalink / raw) To: Steffen Prohaska; +Cc: Junio C Hamano, git, Johannes Schindelin, msysGit Johannes Sixt schrieb: > +static const char *get_pwd_cwd(void) > +{ > + static char cwd[PATH_MAX + 1]; > + char *pwd; > + struct stat cwd_stat, pwd_stat; > + if (getcwd(cwd, PATH_MAX) == NULL) > + return NULL; > + pwd = getenv("PWD"); > + if (pwd && strcmp(pwd, cwd)) { > + stat(cwd, &cwd_stat); > + if (!stat(pwd, &pwd_stat) && > + pwd_stat.st_dev == cwd_stat.st_dev && > + pwd_stat.st_ino == cwd_stat.st_ino) { > + strlcpy(cwd, pwd, PATH_MAX); git-bash users on Windows, please test this patch. The problem is that with our custom stat implementation st_dev and st_ino are not reliable. It works in my setup because $PWD is not set and this branch is never entered, but with bash it makes a difference. -- Hannes ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Allow the built-in exec path to be relative to the command invocation path 2008-07-13 20:31 ` [PATCH] Allow the built-in exec path to be relative to the command invocation path Johannes Sixt 2008-07-13 20:31 ` [PATCH] Allow add_path() to add non-existent directories to the path Johannes Sixt @ 2008-07-13 20:45 ` Johannes Schindelin 1 sibling, 0 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-07-13 20:45 UTC (permalink / raw) To: Johannes Sixt; +Cc: Junio C Hamano, Steffen Prohaska, git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Fix relative built-in paths to be relative to the command invocation 2008-07-13 20:31 ` [PATCH] Fix relative built-in paths to be relative to the command invocation Johannes Sixt 2008-07-13 20:31 ` [PATCH] Allow the built-in exec path to be relative to the command invocation path Johannes Sixt @ 2008-07-13 20:43 ` Johannes Schindelin 2008-07-14 6:55 ` Johannes Sixt 2008-07-14 8:47 ` Johannes Sixt 1 sibling, 2 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-07-13 20:43 UTC (permalink / raw) To: Johannes Sixt; +Cc: Junio C Hamano, Steffen Prohaska, git Hi, On Sun, 13 Jul 2008, Johannes Sixt wrote: > diff --git a/Makefile b/Makefile > index 4796565..2bdb9bf 100644 > --- a/Makefile > +++ b/Makefile > @@ -1301,7 +1301,7 @@ remove-dashes: > ### Installation rules > > ifeq ($(firstword $(subst /, ,$(template_dir))),..) > -template_instdir = $(gitexecdir)/$(template_dir) > +template_instdir = $(shell cd '$(bindir_SQ)/$(template_dir_SQ)' && pwd) What is this for? Did the original line stop working? > diff --git a/exec_cmd.c b/exec_cmd.c > index 8899e31..45f92eb 100644 > --- a/exec_cmd.c > +++ b/exec_cmd.c > @@ -5,6 +5,7 @@ > > extern char **environ; > static const char *argv_exec_path; > +static const char *argv0_path; > > static const char *builtin_exec_path(void) > { > @@ -42,14 +43,19 @@ static const char *builtin_exec_path(void) > > const char *system_path(const char *path) > { > - if (!is_absolute_path(path)) { > + if (!is_absolute_path(path) && argv0_path) { > struct strbuf d = STRBUF_INIT; > - strbuf_addf(&d, "%s/%s", git_exec_path(), path); > + strbuf_addf(&d, "%s/%s", argv0_path, path); > path = strbuf_detach(&d, NULL); > } > return path; > } > > +void git_set_argv0_path(const char *path) > +{ > + argv0_path = path; > +} > + > void git_set_argv_exec_path(const char *exec_path) > { > argv_exec_path = exec_path; > @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char *path) > } > } > > -void setup_path(const char *cmd_path) > +void setup_path(void) It seems to me that this patch would not do anything different, but with less code change, if setup_path() would set argv0_path, and not a new function was introduced. Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Fix relative built-in paths to be relative to the command invocation 2008-07-13 20:43 ` [PATCH] Fix relative built-in paths to be relative to the command invocation Johannes Schindelin @ 2008-07-14 6:55 ` Johannes Sixt 2008-07-14 12:20 ` Johannes Schindelin 2008-07-14 8:47 ` Johannes Sixt 1 sibling, 1 reply; 371+ messages in thread From: Johannes Sixt @ 2008-07-14 6:55 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, Steffen Prohaska, git Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>: > Hi, > > On Sun, 13 Jul 2008, Johannes Sixt wrote: > > > diff --git a/Makefile b/Makefile > > index 4796565..2bdb9bf 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -1301,7 +1301,7 @@ remove-dashes: > > ### Installation rules > > > > ifeq ($(firstword $(subst /, ,$(template_dir))),..) > > -template_instdir = $(gitexecdir)/$(template_dir) > > +template_instdir = $(shell cd '$(bindir_SQ)/$(template_dir_SQ)' && pwd) > > What is this for? Did the original line stop working? I could just have changed $(gitexecdir) to $(bindir), but in the make-execpath-relative patch we will need the normalized gitexec_instdir because its value is compared to $(bindir). So the extra $(shell...) in _this_ patch is only that the final result looks consistent. > > diff --git a/exec_cmd.c b/exec_cmd.c > > index 8899e31..45f92eb 100644 > > --- a/exec_cmd.c > > +++ b/exec_cmd.c > > @@ -5,6 +5,7 @@ > > > > extern char **environ; > > static const char *argv_exec_path; > > +static const char *argv0_path; > > > > static const char *builtin_exec_path(void) > > { > > @@ -42,14 +43,19 @@ static const char *builtin_exec_path(void) > > > > const char *system_path(const char *path) > > { > > - if (!is_absolute_path(path)) { > > + if (!is_absolute_path(path) && argv0_path) { > > struct strbuf d = STRBUF_INIT; > > - strbuf_addf(&d, "%s/%s", git_exec_path(), path); > > + strbuf_addf(&d, "%s/%s", argv0_path, path); > > path = strbuf_detach(&d, NULL); > > } > > return path; > > } > > > > +void git_set_argv0_path(const char *path) > > +{ > > + argv0_path = path; > > +} > > + > > void git_set_argv_exec_path(const char *exec_path) > > { > > argv_exec_path = exec_path; > > @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char > *path) > > } > > } > > > > -void setup_path(const char *cmd_path) > > +void setup_path(void) > > It seems to me that this patch would not do anything different, but with > less code change, if setup_path() would set argv0_path, and not a new > function was introduced. This is just to play a safe game. I had it that way, but I decided to have the call to the new git_set_argv0_path() early in git.c because the call to setup_path() in git.c is very late, and it could happen that we call system_path() (which needs argv0_path) before that. Although I didn't audit the code whether this really happens. -- Hannes ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Fix relative built-in paths to be relative to the command invocation 2008-07-14 6:55 ` Johannes Sixt @ 2008-07-14 12:20 ` Johannes Schindelin 2008-07-14 18:54 ` Johannes Sixt 0 siblings, 1 reply; 371+ messages in thread From: Johannes Schindelin @ 2008-07-14 12:20 UTC (permalink / raw) To: Johannes Sixt; +Cc: Junio C Hamano, Steffen Prohaska, git Hi, On Mon, 14 Jul 2008, Johannes Sixt wrote: > Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>: > > > On Sun, 13 Jul 2008, Johannes Sixt wrote: > > > > > @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char > > > *path) > > > } > > > } > > > > > > -void setup_path(const char *cmd_path) > > > +void setup_path(void) > > > > It seems to me that this patch would not do anything different, but > > with less code change, if setup_path() would set argv0_path, and not a > > new function was introduced. > > This is just to play a safe game. I had it that way, but I decided to have > the call to the new git_set_argv0_path() early in git.c because the call > to setup_path() in git.c is very late, and it could happen that we call > system_path() (which needs argv0_path) before that. Although I didn't audit > the code whether this really happens. Well, okay... I would have rather seen it not change (since there was no bug to fix), or as a separate patch, but it's Junio's call. Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Fix relative built-in paths to be relative to the command invocation 2008-07-14 12:20 ` Johannes Schindelin @ 2008-07-14 18:54 ` Johannes Sixt 2008-07-14 19:03 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Johannes Sixt @ 2008-07-14 18:54 UTC (permalink / raw) To: Johannes Schindelin, Junio C Hamano; +Cc: git, Steffen Prohaska On Montag, 14. Juli 2008, Johannes Schindelin wrote: > Hi, > > On Mon, 14 Jul 2008, Johannes Sixt wrote: > > Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>: > > > On Sun, 13 Jul 2008, Johannes Sixt wrote: > > > > @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char > > > > *path) > > > > } > > > > } > > > > > > > > -void setup_path(const char *cmd_path) > > > > +void setup_path(void) > > > > > > It seems to me that this patch would not do anything different, but > > > with less code change, if setup_path() would set argv0_path, and not a > > > new function was introduced. > > > > This is just to play a safe game. I had it that way, but I decided to > > have the call to the new git_set_argv0_path() early in git.c because the > > call to setup_path() in git.c is very late, and it could happen that we > > call system_path() (which needs argv0_path) before that. Although I > > didn't audit the code whether this really happens. > > Well, okay... I would have rather seen it not change (since there was no > bug to fix), or as a separate patch, but it's Junio's call. I investigated this, and, yes, there indeed are calls to system_path() before setup_path(), for example: commit_pager_choice setup_pager git_config git_etc_gitconfig system_path(ETC_GITCONFIG) Junio, do you want git_set_argv0_path() in a separate patch? -- Hannes ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Fix relative built-in paths to be relative to the command invocation 2008-07-14 18:54 ` Johannes Sixt @ 2008-07-14 19:03 ` Junio C Hamano 0 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-14 19:03 UTC (permalink / raw) To: Johannes Sixt; +Cc: Johannes Schindelin, git, Steffen Prohaska Johannes Sixt <johannes.sixt@telecom.at> writes: > On Montag, 14. Juli 2008, Johannes Schindelin wrote: >> Hi, >> >> On Mon, 14 Jul 2008, Johannes Sixt wrote: >> > Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>: >> > > On Sun, 13 Jul 2008, Johannes Sixt wrote: >> > > > @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char >> > > > *path) >> > > > } >> > > > } >> > > > >> > > > -void setup_path(const char *cmd_path) >> > > > +void setup_path(void) >> > > >> > > It seems to me that this patch would not do anything different, but >> > > with less code change, if setup_path() would set argv0_path, and not a >> > > new function was introduced. >> > >> > This is just to play a safe game. I had it that way, but I decided to >> > have the call to the new git_set_argv0_path() early in git.c because the >> > call to setup_path() in git.c is very late, and it could happen that we >> > call system_path() (which needs argv0_path) before that. Although I >> > didn't audit the code whether this really happens. >> >> Well, okay... I would have rather seen it not change (since there was no >> bug to fix), or as a separate patch, but it's Junio's call. > > I investigated this, and, yes, there indeed are calls to system_path() before > setup_path(), for example: > > commit_pager_choice > setup_pager > git_config > git_etc_gitconfig > system_path(ETC_GITCONFIG) > > Junio, do you want git_set_argv0_path() in a separate patch? I think that would be easier to explain in the commit log what is going on, if it is a separate patch. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] Fix relative built-in paths to be relative to the command invocation 2008-07-13 20:43 ` [PATCH] Fix relative built-in paths to be relative to the command invocation Johannes Schindelin 2008-07-14 6:55 ` Johannes Sixt @ 2008-07-14 8:47 ` Johannes Sixt 2008-07-14 21:41 ` [PATCH 0/5] replacement for the part of js/more-win that is in pu Johannes Sixt 1 sibling, 1 reply; 371+ messages in thread From: Johannes Sixt @ 2008-07-14 8:47 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, Steffen Prohaska, git Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>: > Hi, > > On Sun, 13 Jul 2008, Johannes Sixt wrote: > > > diff --git a/Makefile b/Makefile > > index 4796565..2bdb9bf 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -1301,7 +1301,7 @@ remove-dashes: > > ### Installation rules > > > > ifeq ($(firstword $(subst /, ,$(template_dir))),..) > > -template_instdir = $(gitexecdir)/$(template_dir) > > +template_instdir = $(shell cd '$(bindir_SQ)/$(template_dir_SQ)' && pwd) > > What is this for? Did the original line stop working? Hmpf! This new line doesn't work in the intended way if the installation destination does not exist. I'll have to find a better solution... -- Hannes ^ permalink raw reply [flat|nested] 371+ messages in thread
* [PATCH 0/5] replacement for the part of js/more-win that is in pu 2008-07-14 8:47 ` Johannes Sixt @ 2008-07-14 21:41 ` Johannes Sixt 2008-07-14 21:41 ` [PATCH 1/5] Makefile: Normalize $(bindir) and $(gitexecdir) before comparing Johannes Sixt 2008-07-15 7:59 ` [PATCH 0/5] replacement for the part of js/more-win that is in pu Johannes Sixt 0 siblings, 2 replies; 371+ messages in thread From: Johannes Sixt @ 2008-07-14 21:41 UTC (permalink / raw) To: Junio C Hamano; +Cc: Steffen Prohaska, git, Johannes Sixt The interdiff to js/more-win is below. It is mostly the changes of 1/5. Johannes Sixt (5): Makefile: Normalize $(bindir) and $(gitexecdir) before comparing Record the command invocation path early Fix relative built-in paths to be relative to the command invocation Allow the built-in exec path to be relative to the command invocation path Allow add_path() to add non-existent directories to the path Makefile | 33 +++++++++++++++++----------- abspath.c | 36 ++++++++++++++++++++++++++++++ exec_cmd.c | 54 +++++++++++---------------------------------- exec_cmd.h | 3 +- git.c | 5 +-- path.c | 36 ------------------------------ receive-pack.c | 2 +- shell.c | 4 +- upload-pack.c | 2 +- 9 files changed, 77 insertions(+), 98 deletions(-) diff --git a/Makefile b/Makefile index 3593e6f..4df6423 100644 --- a/Makefile +++ b/Makefile @@ -1301,14 +1301,14 @@ remove-dashes: ### Installation rules ifeq ($(firstword $(subst /, ,$(template_dir))),..) -template_instdir = $(shell cd '$(bindir_SQ)/$(template_dir_SQ)' && pwd) +template_instdir = $(bindir)/$(template_dir) else template_instdir = $(template_dir) endif export template_instdir ifeq ($(firstword $(subst /, ,$(gitexecdir))),..) -gitexec_instdir = $(shell cd '$(bindir_SQ)/$(gitexecdir_SQ)' && pwd) +gitexec_instdir = $(bindir)/$(gitexecdir) else gitexec_instdir = $(gitexecdir) endif @@ -1325,18 +1325,18 @@ ifndef NO_TCLTK $(MAKE) -C gitk-git install $(MAKE) -C git-gui install endif - if test 'z$(bindir_SQ)' != 'z$(gitexec_instdir_SQ)'; \ - then \ - ln -f '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \ - '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/git$X' || \ - cp '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \ - '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/git$X'; \ - fi - $(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p' ;) ifneq (,$X) $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p';) endif - ./check_bindir 'z$(bindir_SQ)' 'z$(gitexec_instdir_SQ)' '$(DESTDIR_SQ)$(bindir_SQ)/git-shell$X' + bindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \ + execdir=$$(cd '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' && pwd) && \ + if test "z$$bindir" != "z$$execdir"; \ + then \ + ln -f "$$bindir/git$X" "$$execdir/git$X" || \ + cp "$$bindir/git$X" "$$execdir/git$X"; \ + fi && \ + { $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \ + ./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-shell$X" install-doc: $(MAKE) -C Documentation install ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH 1/5] Makefile: Normalize $(bindir) and $(gitexecdir) before comparing 2008-07-14 21:41 ` [PATCH 0/5] replacement for the part of js/more-win that is in pu Johannes Sixt @ 2008-07-14 21:41 ` Johannes Sixt 2008-07-14 21:41 ` [PATCH 2/5] Record the command invocation path early Johannes Sixt 2008-07-15 7:59 ` [PATCH 0/5] replacement for the part of js/more-win that is in pu Johannes Sixt 1 sibling, 1 reply; 371+ messages in thread From: Johannes Sixt @ 2008-07-14 21:41 UTC (permalink / raw) To: Junio C Hamano; +Cc: Steffen Prohaska, git, Johannes Sixt The install target needs to check whether the user has opted to make $(gitexecdir) equal to $(bindir). It did so by a straight string comparison. Since we are going to allow a relative $(gitexecdir), we have to normalize paths before comparison, which we do with $(cd there && pwd). The normalized paths are stored in shell variables. These we can now reuse in the subsequent install statements, which conveniently shortens the lines a bit. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> --- Makefile | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/Makefile b/Makefile index 4796565..4de9271 100644 --- a/Makefile +++ b/Makefile @@ -1318,18 +1318,18 @@ ifndef NO_TCLTK $(MAKE) -C gitk-git install $(MAKE) -C git-gui install endif - if test 'z$(bindir_SQ)' != 'z$(gitexecdir_SQ)'; \ - then \ - ln -f '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \ - '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' || \ - cp '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \ - '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \ - fi - $(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;) ifneq (,$X) $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';) endif - ./check_bindir 'z$(bindir_SQ)' 'z$(gitexecdir_SQ)' '$(DESTDIR_SQ)$(bindir_SQ)/git-shell$X' + bindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \ + execdir=$$(cd '$(DESTDIR_SQ)$(gitexecdir_SQ)' && pwd) && \ + if test "z$$bindir" != "z$$execdir"; \ + then \ + ln -f "$$bindir/git$X" "$$execdir/git$X" || \ + cp "$$bindir/git$X" "$$execdir/git$X"; \ + fi && \ + { $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \ + ./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-shell$X" install-doc: $(MAKE) -C Documentation install -- 1.5.6.3.323.g1e58 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH 2/5] Record the command invocation path early 2008-07-14 21:41 ` [PATCH 1/5] Makefile: Normalize $(bindir) and $(gitexecdir) before comparing Johannes Sixt @ 2008-07-14 21:41 ` Johannes Sixt 2008-07-14 21:41 ` [PATCH 3/5] Fix relative built-in paths to be relative to the command invocation Johannes Sixt 0 siblings, 1 reply; 371+ messages in thread From: Johannes Sixt @ 2008-07-14 21:41 UTC (permalink / raw) To: Junio C Hamano; +Cc: Steffen Prohaska, git, Johannes Sixt We will need the command invocation path in system_path(). This path was passed to setup_path(), but system_path() can be called earlier, for example via: main commit_pager_choice setup_pager git_config git_etc_gitconfig system_path Therefore, we introduce git_set_argv0_path() and call it as soon as possible. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> --- exec_cmd.c | 10 ++++++++-- exec_cmd.h | 3 ++- git.c | 5 ++--- receive-pack.c | 2 +- shell.c | 4 ++-- upload-pack.c | 2 +- 6 files changed, 16 insertions(+), 10 deletions(-) diff --git a/exec_cmd.c b/exec_cmd.c index 8899e31..dedb01d 100644 --- a/exec_cmd.c +++ b/exec_cmd.c @@ -5,6 +5,7 @@ extern char **environ; static const char *argv_exec_path; +static const char *argv0_path; static const char *builtin_exec_path(void) { @@ -50,6 +51,11 @@ const char *system_path(const char *path) return path; } +void git_set_argv0_path(const char *path) +{ + argv0_path = path; +} + void git_set_argv_exec_path(const char *exec_path) { argv_exec_path = exec_path; @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char *path) } } -void setup_path(const char *cmd_path) +void setup_path(void) { const char *old_path = getenv("PATH"); struct strbuf new_path; @@ -94,7 +100,7 @@ void setup_path(const char *cmd_path) add_path(&new_path, argv_exec_path); add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT)); add_path(&new_path, builtin_exec_path()); - add_path(&new_path, cmd_path); + add_path(&new_path, argv0_path); if (old_path) strbuf_addstr(&new_path, old_path); diff --git a/exec_cmd.h b/exec_cmd.h index 7eb94e5..0c46cd5 100644 --- a/exec_cmd.h +++ b/exec_cmd.h @@ -2,8 +2,9 @@ #define GIT_EXEC_CMD_H extern void git_set_argv_exec_path(const char *exec_path); +extern void git_set_argv0_path(const char *path); extern const char* git_exec_path(void); -extern void setup_path(const char *); +extern void setup_path(void); extern int execv_git_cmd(const char **argv); /* NULL terminated */ extern int execl_git_cmd(const char *cmd, ...); extern const char *system_path(const char *path); diff --git a/git.c b/git.c index 7075533..b90c358 100644 --- a/git.c +++ b/git.c @@ -470,7 +470,6 @@ int main(int argc, const char **argv) { const char *cmd = argv[0] && *argv[0] ? argv[0] : "git-help"; char *slash = (char *)cmd + strlen(cmd); - const char *cmd_path = NULL; int done_alias = 0; /* @@ -483,7 +482,7 @@ int main(int argc, const char **argv) while (cmd <= slash && !is_dir_sep(*slash)); if (cmd <= slash) { *slash++ = 0; - cmd_path = cmd; + git_set_argv0_path(cmd); cmd = slash; } @@ -527,7 +526,7 @@ int main(int argc, const char **argv) * environment, and the $(gitexecdir) from the Makefile at build * time. */ - setup_path(cmd_path); + setup_path(); while (1) { /* See if it's an internal command */ diff --git a/receive-pack.c b/receive-pack.c index fa653b4..d44c19e 100644 --- a/receive-pack.c +++ b/receive-pack.c @@ -482,7 +482,7 @@ int main(int argc, char **argv) if (!dir) usage(receive_pack_usage); - setup_path(NULL); + setup_path(); if (!enter_repo(dir, 0)) die("'%s': unable to chdir or not a git archive", dir); diff --git a/shell.c b/shell.c index 91ca7de..6a48de0 100644 --- a/shell.c +++ b/shell.c @@ -15,7 +15,7 @@ static int do_generic_cmd(const char *me, char *arg) { const char *my_argv[4]; - setup_path(NULL); + setup_path(); if (!arg || !(arg = sq_dequote(arg))) die("bad argument"); if (prefixcmp(me, "git-")) @@ -37,7 +37,7 @@ static int do_cvs_cmd(const char *me, char *arg) if (!arg || strcmp(arg, "server")) die("git-cvsserver only handles server: %s", arg); - setup_path(NULL); + setup_path(); return execv_git_cmd(cvsserver_argv); } diff --git a/upload-pack.c b/upload-pack.c index 9f82941..c911e70 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -638,7 +638,7 @@ int main(int argc, char **argv) if (i != argc-1) usage(upload_pack_usage); - setup_path(NULL); + setup_path(); dir = argv[i]; -- 1.5.6.3.323.g1e58 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH 3/5] Fix relative built-in paths to be relative to the command invocation 2008-07-14 21:41 ` [PATCH 2/5] Record the command invocation path early Johannes Sixt @ 2008-07-14 21:41 ` Johannes Sixt 2008-07-14 21:41 ` [PATCH 4/5] Allow the built-in exec path to be relative to the command invocation path Johannes Sixt 0 siblings, 1 reply; 371+ messages in thread From: Johannes Sixt @ 2008-07-14 21:41 UTC (permalink / raw) To: Junio C Hamano; +Cc: Steffen Prohaska, git, Johannes Sixt $(gitexecdir) (as defined in the Makefile) has gained another path component, but the relative paths in the MINGW section of the Makefile, which are interpreted relative to it, do not account for it. Instead of adding another ../ in front of the path, we change the code that constructs the absolute paths to do it relative to the command's directory, which is essentially $(bindir). We do it this way because we will also allow a relative $(gitexecdir) later. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> --- Makefile | 2 +- exec_cmd.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 4de9271..b9ea0ea 100644 --- a/Makefile +++ b/Makefile @@ -1301,7 +1301,7 @@ remove-dashes: ### Installation rules ifeq ($(firstword $(subst /, ,$(template_dir))),..) -template_instdir = $(gitexecdir)/$(template_dir) +template_instdir = $(bindir)/$(template_dir) else template_instdir = $(template_dir) endif diff --git a/exec_cmd.c b/exec_cmd.c index dedb01d..45f92eb 100644 --- a/exec_cmd.c +++ b/exec_cmd.c @@ -43,9 +43,9 @@ static const char *builtin_exec_path(void) const char *system_path(const char *path) { - if (!is_absolute_path(path)) { + if (!is_absolute_path(path) && argv0_path) { struct strbuf d = STRBUF_INIT; - strbuf_addf(&d, "%s/%s", git_exec_path(), path); + strbuf_addf(&d, "%s/%s", argv0_path, path); path = strbuf_detach(&d, NULL); } return path; -- 1.5.6.3.323.g1e58 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH 4/5] Allow the built-in exec path to be relative to the command invocation path 2008-07-14 21:41 ` [PATCH 3/5] Fix relative built-in paths to be relative to the command invocation Johannes Sixt @ 2008-07-14 21:41 ` Johannes Sixt 2008-07-14 21:41 ` [PATCH 5/5] Allow add_path() to add non-existent directories to the path Johannes Sixt 0 siblings, 1 reply; 371+ messages in thread From: Johannes Sixt @ 2008-07-14 21:41 UTC (permalink / raw) To: Junio C Hamano; +Cc: Steffen Prohaska, git, Johannes Sixt If GIT_EXEC_PATH (the macro that is defined in the Makefile) is relative, it is interpreted relative to the command's invocation path, which usually is $(bindir). The Makefile rules were written with the assumption that $(gitexecdir) is an absolute path. We introduce a separate variable that names the (absolute) installation directory. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> --- Makefile | 15 +++++++++++---- exec_cmd.c | 38 ++------------------------------------ 2 files changed, 13 insertions(+), 40 deletions(-) diff --git a/Makefile b/Makefile index b9ea0ea..4df6423 100644 --- a/Makefile +++ b/Makefile @@ -1307,10 +1307,17 @@ template_instdir = $(template_dir) endif export template_instdir +ifeq ($(firstword $(subst /, ,$(gitexecdir))),..) +gitexec_instdir = $(bindir)/$(gitexecdir) +else +gitexec_instdir = $(gitexecdir) +endif +gitexec_instdir_SQ = $(subst ','\'',$(gitexec_instdir)) + install: all $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)' - $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)' - $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)' + $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' + $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' $(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X '$(DESTDIR_SQ)$(bindir_SQ)' $(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install $(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install @@ -1319,10 +1326,10 @@ ifndef NO_TCLTK $(MAKE) -C git-gui install endif ifneq (,$X) - $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';) + $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p';) endif bindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \ - execdir=$$(cd '$(DESTDIR_SQ)$(gitexecdir_SQ)' && pwd) && \ + execdir=$$(cd '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' && pwd) && \ if test "z$$bindir" != "z$$execdir"; \ then \ ln -f "$$bindir/git$X" "$$execdir/git$X" || \ diff --git a/exec_cmd.c b/exec_cmd.c index 45f92eb..c236034 100644 --- a/exec_cmd.c +++ b/exec_cmd.c @@ -7,40 +7,6 @@ extern char **environ; static const char *argv_exec_path; static const char *argv0_path; -static const char *builtin_exec_path(void) -{ -#ifndef __MINGW32__ - return GIT_EXEC_PATH; -#else - int len; - char *p, *q, *sl; - static char *ep; - if (ep) - return ep; - - len = strlen(_pgmptr); - if (len < 2) - return ep = "."; - - p = ep = xmalloc(len+1); - q = _pgmptr; - sl = NULL; - /* copy program name, turn '\\' into '/', skip last part */ - while ((*p = *q)) { - if (*q == '\\' || *q == '/') { - *p = '/'; - sl = p; - } - p++, q++; - } - if (sl) - *sl = '\0'; - else - ep[0] = '.', ep[1] = '\0'; - return ep; -#endif -} - const char *system_path(const char *path) { if (!is_absolute_path(path) && argv0_path) { @@ -75,7 +41,7 @@ const char *git_exec_path(void) return env; } - return builtin_exec_path(); + return system_path(GIT_EXEC_PATH); } static void add_path(struct strbuf *out, const char *path) @@ -99,7 +65,7 @@ void setup_path(void) add_path(&new_path, argv_exec_path); add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT)); - add_path(&new_path, builtin_exec_path()); + add_path(&new_path, system_path(GIT_EXEC_PATH)); add_path(&new_path, argv0_path); if (old_path) -- 1.5.6.3.323.g1e58 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH 5/5] Allow add_path() to add non-existent directories to the path 2008-07-14 21:41 ` [PATCH 4/5] Allow the built-in exec path to be relative to the command invocation path Johannes Sixt @ 2008-07-14 21:41 ` Johannes Sixt 0 siblings, 0 replies; 371+ messages in thread From: Johannes Sixt @ 2008-07-14 21:41 UTC (permalink / raw) To: Junio C Hamano; +Cc: Steffen Prohaska, git, Johannes Sixt This function had used make_absolute_path(); but this function dies if the directory that contains the entry whose relative path was supplied in the argument does not exist. This is a problem if the argument is, for example, "../libexec/git-core", and that "../libexec" does not exist. Since the resolution of symbolic links is not required for elements in PATH, we can fall back to using make_nonrelative_path(), which simply prepends $PWD to the path. We have to move make_nonrelative_path() alongside make_absolute_path() in abspath.c so that git-shell can be linked. See 5b8e6f85f. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> --- abspath.c | 36 ++++++++++++++++++++++++++++++++++++ exec_cmd.c | 2 +- path.c | 36 ------------------------------------ 3 files changed, 37 insertions(+), 37 deletions(-) diff --git a/abspath.c b/abspath.c index 4f95a95..0d56124 100644 --- a/abspath.c +++ b/abspath.c @@ -66,3 +66,39 @@ const char *make_absolute_path(const char *path) return buf; } + +static const char *get_pwd_cwd(void) +{ + static char cwd[PATH_MAX + 1]; + char *pwd; + struct stat cwd_stat, pwd_stat; + if (getcwd(cwd, PATH_MAX) == NULL) + return NULL; + pwd = getenv("PWD"); + if (pwd && strcmp(pwd, cwd)) { + stat(cwd, &cwd_stat); + if (!stat(pwd, &pwd_stat) && + pwd_stat.st_dev == cwd_stat.st_dev && + pwd_stat.st_ino == cwd_stat.st_ino) { + strlcpy(cwd, pwd, PATH_MAX); + } + } + return cwd; +} + +const char *make_nonrelative_path(const char *path) +{ + static char buf[PATH_MAX + 1]; + + if (is_absolute_path(path)) { + if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX) + die("Too long path: %.*s", 60, path); + } else { + const char *cwd = get_pwd_cwd(); + if (!cwd) + die("Cannot determine the current working directory"); + if (snprintf(buf, PATH_MAX, "%s/%s", cwd, path) >= PATH_MAX) + die("Too long path: %.*s", 60, path); + } + return buf; +} diff --git a/exec_cmd.c b/exec_cmd.c index c236034..0ed768d 100644 --- a/exec_cmd.c +++ b/exec_cmd.c @@ -50,7 +50,7 @@ static void add_path(struct strbuf *out, const char *path) if (is_absolute_path(path)) strbuf_addstr(out, path); else - strbuf_addstr(out, make_absolute_path(path)); + strbuf_addstr(out, make_nonrelative_path(path)); strbuf_addch(out, PATH_SEP); } diff --git a/path.c b/path.c index 504eae0..9df447b 100644 --- a/path.c +++ b/path.c @@ -291,42 +291,6 @@ int adjust_shared_perm(const char *path) return 0; } -static const char *get_pwd_cwd(void) -{ - static char cwd[PATH_MAX + 1]; - char *pwd; - struct stat cwd_stat, pwd_stat; - if (getcwd(cwd, PATH_MAX) == NULL) - return NULL; - pwd = getenv("PWD"); - if (pwd && strcmp(pwd, cwd)) { - stat(cwd, &cwd_stat); - if (!stat(pwd, &pwd_stat) && - pwd_stat.st_dev == cwd_stat.st_dev && - pwd_stat.st_ino == cwd_stat.st_ino) { - strlcpy(cwd, pwd, PATH_MAX); - } - } - return cwd; -} - -const char *make_nonrelative_path(const char *path) -{ - static char buf[PATH_MAX + 1]; - - if (is_absolute_path(path)) { - if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX) - die ("Too long path: %.*s", 60, path); - } else { - const char *cwd = get_pwd_cwd(); - if (!cwd) - die("Cannot determine the current working directory"); - if (snprintf(buf, PATH_MAX, "%s/%s", cwd, path) >= PATH_MAX) - die ("Too long path: %.*s", 60, path); - } - return buf; -} - const char *make_relative_path(const char *abs, const char *base) { static char buf[PATH_MAX + 1]; -- 1.5.6.3.323.g1e58 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH 0/5] replacement for the part of js/more-win that is in pu 2008-07-14 21:41 ` [PATCH 0/5] replacement for the part of js/more-win that is in pu Johannes Sixt 2008-07-14 21:41 ` [PATCH 1/5] Makefile: Normalize $(bindir) and $(gitexecdir) before comparing Johannes Sixt @ 2008-07-15 7:59 ` Johannes Sixt 1 sibling, 0 replies; 371+ messages in thread From: Johannes Sixt @ 2008-07-15 7:59 UTC (permalink / raw) To: Junio C Hamano; +Cc: Steffen Prohaska, git Johannes Sixt schrieb: > The interdiff to js/more-win is below. It is mostly the changes > of 1/5. > > Johannes Sixt (5): > Makefile: Normalize $(bindir) and $(gitexecdir) before comparing > Record the command invocation path early > Fix relative built-in paths to be relative to the command > invocation > Allow the built-in exec path to be relative to the command > invocation path > Allow add_path() to add non-existent directories to the path I retract this series and also the earlier version (the part that is in pu). If I had done due diligence, I could have found out earlier that it does not solve the problem it tried to solve. Appologies for the noise. :-( The series tries to derive the exec-path from argv[0] (if the built-in path is relative). But if a command is invoked from CMD on Windows, argv[0] doesn't have a path, there is only the program name, "git.exe". In the past, we relied on the global variable _pgmptr (only Windows's C runtime has this), which does contain the full path, and if we set gitexecdir = $(bindir) in the Makefile, then we get a working git.exe, but we put back all commands into $PATH. -- Hannes ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path() 2008-07-11 7:27 ` Steffen Prohaska 2008-07-11 7:28 ` [PATCH 1/3] Move code interpreting path relative to exec-dir to new function system_path() Steffen Prohaska @ 2008-07-11 9:02 ` Johannes Sixt 1 sibling, 0 replies; 371+ messages in thread From: Johannes Sixt @ 2008-07-11 9:02 UTC (permalink / raw) To: Steffen Prohaska; +Cc: Junio C Hamano, Git Mailing List, Johannes Schindelin Zitat von Steffen Prohaska <prohaska@zib.de>: > > On Jul 4, 2008, at 2:35 PM, Johannes Schindelin wrote: > > > On Fri, 4 Jul 2008, Junio C Hamano wrote: > > > >> Could you check if there are copy-and-pasted duplicated code you can > >> factor out before continuing this direction? > > > > Note also that Hannes tried very hard to get rid of those ugly "#ifdef > > __MINGW32__"s by declaring/overriding functions in git-compat-util.h. > > > > I think that is such a good practice that we should not stop here. > > I'll send three patches that address Junio's and Dscho's comments: > > [PATCH 1/3] Move code interpreting path relative to exec-dir to new > function system_path() > [PATCH 2/3] help.c: Add support for htmldir relative to > git_exec_path() > [PATCH 3/3] help (Windows): Display HTML in default browser using > Windows' shell API > > > Hannes, > the patches I'll send probably conflict with your planned work on > GIT_EXEC_PATH that has been discussed on the msysgit list. I think > you could built on my series and modify system_path(). Thanks. I haven't done a lot in that direction, yet, so your patches will be helpful. But according to the conclusion of our recent discussion http://thread.gmane.org/gmane.comp.version-control.msysgit/2633/focus=2669 I shall modify system_path() to construct paths relative to the git executable, which is essentially Makefile's $(bindir), not git_exec_path(). -- Hannes ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds. 2008-07-02 8:32 ` [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds Steffen Prohaska 2008-07-02 8:32 ` [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser Steffen Prohaska @ 2008-07-02 9:22 ` Junio C Hamano 2008-07-02 10:03 ` Marius Storm-Olsen 1 sibling, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-02 9:22 UTC (permalink / raw) To: prohaska; +Cc: Johannes Sixt, git, msysgit, Marius Storm-Olsen Steffen Prohaska <prohaska@zib.de> writes: > From: Marius Storm-Olsen <mstormo_git@storm-olsen.com> > > SIGPIPE isn't supported in MinGW. Shouldn't #ifdef be on SIGPIPE not on __MINGW32__? > @@ -100,9 +100,11 @@ int cmd_verify_tag(int argc, const char **argv, const char *prefix) > i++; > } > > +#ifndef __MINGW32__ > /* sometimes the program was terminated because this signal > * was received in the process of writing the gpg input: */ > signal(SIGPIPE, SIG_IGN); > +#endif ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds. 2008-07-02 9:22 ` [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds Junio C Hamano @ 2008-07-02 10:03 ` Marius Storm-Olsen 2008-07-02 14:29 ` Steffen Prohaska 0 siblings, 1 reply; 371+ messages in thread From: Marius Storm-Olsen @ 2008-07-02 10:03 UTC (permalink / raw) To: Junio C Hamano; +Cc: prohaska, Johannes Sixt, git, msysgit, Marius Storm-Olsen [-- Attachment #1: Type: text/plain, Size: 401 bytes --] Junio C Hamano said the following on 02.07.2008 11:22: > Steffen Prohaska <prohaska@zib.de> writes: > >> From: Marius Storm-Olsen <mstormo_git@storm-olsen.com> >> >> SIGPIPE isn't supported in MinGW. > > Shouldn't #ifdef be on SIGPIPE not on __MINGW32__? That's certainly a good suggestion. :-) -- .marius [@] storm-olsen [.com] 'if you know what you're doing, it's not research' [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 187 bytes --] ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds. 2008-07-02 10:03 ` Marius Storm-Olsen @ 2008-07-02 14:29 ` Steffen Prohaska 0 siblings, 0 replies; 371+ messages in thread From: Steffen Prohaska @ 2008-07-02 14:29 UTC (permalink / raw) To: Marius Storm-Olsen, Junio C Hamano Cc: Johannes Sixt, Git Mailing List, msysGit, Marius Storm-Olsen On Jul 2, 2008, at 12:03 PM, Marius Storm-Olsen wrote: > Junio C Hamano said the following on 02.07.2008 11:22: >> Steffen Prohaska <prohaska@zib.de> writes: >>> From: Marius Storm-Olsen <mstormo_git@storm-olsen.com> >>> >>> SIGPIPE isn't supported in MinGW. >> Shouldn't #ifdef be on SIGPIPE not on __MINGW32__? > > That's certainly a good suggestion. :-) I reverted this in 4msysgit and will remove the patch from the series. Steffen ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [msysGit] [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures 2008-07-02 8:32 ` [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures Steffen Prohaska 2008-07-02 8:32 ` [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds Steffen Prohaska @ 2008-07-02 18:46 ` Johannes Sixt 2008-07-03 11:08 ` Johannes Schindelin 2008-07-11 16:55 ` [PATCH] " Steffen Prohaska 1 sibling, 2 replies; 371+ messages in thread From: Johannes Sixt @ 2008-07-02 18:46 UTC (permalink / raw) To: prohaska; +Cc: msysGit, git, Junio C Hamano, Johannes Schindelin On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote: > From: Johannes Schindelin <johannes.schindelin@gmx.de> > > On Windows, gpg outputs CR/LF signatures. But since the tag > messages are already stripped of the CR by stripspace(), it is > arguably nicer to do the same for the tag signature. Actually, > this patch does not look for CR/LF, but strips all CRs > from the signature. > > [ spr: ported code to use strbuf ] > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> > Signed-off-by: Steffen Prohaska <prohaska@zib.de> > --- > builtin-tag.c | 14 ++++++++++++++ > 1 files changed, 14 insertions(+), 0 deletions(-) > > diff --git a/builtin-tag.c b/builtin-tag.c > index e675206..77977ba 100644 > --- a/builtin-tag.c > +++ b/builtin-tag.c > @@ -241,6 +241,20 @@ static int do_sign(struct strbuf *buffer) > if (finish_command(&gpg) || !len || len < 0) > return error("gpg failed to sign the tag"); > > +#ifdef __MINGW32__ > + /* strip CR from the line endings */ > + { > + int i, j; > + for (i = j = 0; i < buffer->len; i++) > + if (buffer->buf[i] != '\r') { > + if (i != j) > + buffer->buf[j] = buffer->buf[i]; > + j++; > + } > + strbuf_setlen(buffer, j); > + } > +#endif > + > return 0; > } Do we need the #ifdef __MINGW32__? Can't we just strip CRs unconditionally? It shouldn't hurt on Unix anyway. -- Hannes ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures 2008-07-02 18:46 ` [msysGit] [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures Johannes Sixt @ 2008-07-03 11:08 ` Johannes Schindelin 2008-07-11 16:55 ` [PATCH] " Steffen Prohaska 1 sibling, 0 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-07-03 11:08 UTC (permalink / raw) To: Johannes Sixt; +Cc: prohaska, msysGit, git, Junio C Hamano Hi, On Wed, 2 Jul 2008, Johannes Sixt wrote: > On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote: > > From: Johannes Schindelin <johannes.schindelin@gmx.de> > > > > On Windows, gpg outputs CR/LF signatures. But since the tag > > messages are already stripped of the CR by stripspace(), it is > > arguably nicer to do the same for the tag signature. Actually, > > this patch does not look for CR/LF, but strips all CRs > > from the signature. > > > > [ spr: ported code to use strbuf ] > > > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> > > Signed-off-by: Steffen Prohaska <prohaska@zib.de> > > --- > > builtin-tag.c | 14 ++++++++++++++ > > 1 files changed, 14 insertions(+), 0 deletions(-) > > > > diff --git a/builtin-tag.c b/builtin-tag.c > > index e675206..77977ba 100644 > > --- a/builtin-tag.c > > +++ b/builtin-tag.c > > @@ -241,6 +241,20 @@ static int do_sign(struct strbuf *buffer) > > if (finish_command(&gpg) || !len || len < 0) > > return error("gpg failed to sign the tag"); > > > > +#ifdef __MINGW32__ > > + /* strip CR from the line endings */ > > + { > > + int i, j; > > + for (i = j = 0; i < buffer->len; i++) > > + if (buffer->buf[i] != '\r') { > > + if (i != j) > > + buffer->buf[j] = buffer->buf[i]; > > + j++; > > + } > > + strbuf_setlen(buffer, j); > > + } > > +#endif > > + > > return 0; > > } > > Do we need the #ifdef __MINGW32__? Can't we just strip CRs unconditionally? It > shouldn't hurt on Unix anyway. I agree, and I would even like to refactor this into its own function. Probably even move it to strbuf.[ch]. Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* [PATCH] Convert CR/LF to LF in tag signatures 2008-07-02 18:46 ` [msysGit] [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures Johannes Sixt 2008-07-03 11:08 ` Johannes Schindelin @ 2008-07-11 16:55 ` Steffen Prohaska 1 sibling, 0 replies; 371+ messages in thread From: Steffen Prohaska @ 2008-07-11 16:55 UTC (permalink / raw) To: git, Johannes Sixt Cc: Junio C Hamano, Johannes Schindelin, Johannes Schindelin, Steffen Prohaska From: Johannes Schindelin <johannes.schindelin@gmx.de> On Windows, gpg outputs CR/LF signatures. But since the tag messages are already stripped of the CR by stripspace(), it is arguably nicer to do the same for the tag signature. Actually, this patch does not look for CR/LF, but strips all CRs from the signature. It does so not only on Windows but on all platforms to keep the code simpler. [ spr: ported code to use strbuf ] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Steffen Prohaska <prohaska@zib.de> --- builtin-tag.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/builtin-tag.c b/builtin-tag.c index 3c97c69..a70922b 100644 --- a/builtin-tag.c +++ b/builtin-tag.c @@ -202,6 +202,7 @@ static int do_sign(struct strbuf *buffer) const char *args[4]; char *bracket; int len; + int i, j; if (!*signingkey) { if (strlcpy(signingkey, git_committer_info(IDENT_ERROR_ON_NO_NAME), @@ -241,6 +242,15 @@ static int do_sign(struct strbuf *buffer) if (finish_command(&gpg) || !len || len < 0) return error("gpg failed to sign the tag"); + /* Strip CR from the line endings, in case we are on Windows. */ + for (i = j = 0; i < buffer->len; i++) + if (buffer->buf[i] != '\r') { + if (i != j) + buffer->buf[j] = buffer->buf[i]; + j++; + } + strbuf_setlen(buffer, j); + return 0; } -- 1.5.6.1.282.gd8a0d ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH 02/12] Do not complain about "no common commits" in an empty repo 2008-07-02 8:32 ` [PATCH 02/12] Do not complain about "no common commits" in an empty repo Steffen Prohaska 2008-07-02 8:32 ` [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures Steffen Prohaska @ 2008-07-02 8:58 ` Junio C Hamano 2008-07-02 14:04 ` Steffen Prohaska 1 sibling, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-02 8:58 UTC (permalink / raw) To: prohaska; +Cc: Johannes Sixt, git, msysgit, Johannes Schindelin 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 02/12] Do not complain about "no common commits" in an empty repo 2008-07-02 8:58 ` [PATCH 02/12] Do not complain about "no common commits" in an empty repo Junio C Hamano @ 2008-07-02 14:04 ` Steffen Prohaska 2008-07-02 17:07 ` Johannes Schindelin 0 siblings, 1 reply; 371+ messages in thread From: Steffen Prohaska @ 2008-07-02 14:04 UTC (permalink / raw) To: Junio C Hamano, Johannes Schindelin Cc: Johannes Sixt, Git Mailing List, msysGit On Jul 2, 2008, at 10:58 AM, Junio C Hamano wrote: > Steffen Prohaska <prohaska@zib.de> writes: > >> From: Johannes Schindelin <johannes.schindelin@gmx.de> >> >> If the repo is empty, we know that already, thank you very much. >> So shut fetch-pack up about that case. > > Two complaints. You are right, although I didn't intend to "hide" the patch. I just went through the differences between the mainline and 4msysgit and collected a patch series with all changes I found. I sent this series to the list, so that the remaining differences do not get lost unrecognized. I didn't mean to bother you with incomplete patches. Maybe I should have made my intention clearer by prefixing the subject lines with WIP (or something similar). Apologies. > * What does this have to do with Windows port? Please don't hide a > general interface change in a larger and mostly unrelated topic. I remember that users of msysgit's net installer complaint about this warning. The warning appeared as part of the output of a sequence of automatically executed commands. Without context, the users did not understand what the warning means. > * Do you think people can tell without reading the code in larger > context > outside the patch and this commit log text if you are talking > about the > case you fetch _into_ an empty repository, or if you are > attempting to > fetch _from_ an empty repository, or what? Please try to be a bit > easier for _readers_. Being more redundant and verbose is better > than > being too concise. > > About the first point, "no common commits" is just a friendly > reminder and > not even an error. When you see it, you will learn to expect > looooooooong > download session. > > I personally happen to agree with the logic of this patch, though > --- if > you are fetching into an empty repository, you would already expect > that > the download is as big as the other end anyway, so you would not > need to > be further reminded about that. > > But that is just one-man's opinion. Maybe somebody knows a reason > why I > am (and the logic I am agreeing with is) wrong. Maybe not. So make > the > "remainder of Windows port" series 11 commits, and send this as a > general > interface fix via the normal channel to be discussed, please. Dscho, will you send it? You are the original author. Steffen ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 02/12] Do not complain about "no common commits" in an empty repo 2008-07-02 14:04 ` Steffen Prohaska @ 2008-07-02 17:07 ` Johannes Schindelin 0 siblings, 0 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-07-02 17:07 UTC (permalink / raw) To: Steffen Prohaska; +Cc: Junio C Hamano, Johannes Sixt, Git Mailing List, msysGit Hi, On Wed, 2 Jul 2008, Steffen Prohaska wrote: > Dscho, will you send it? You are the original author. Done, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 01/12] Fake reencoding success under NO_ICONV instead of returning NULL. 2008-07-02 8:32 ` [PATCH 01/12] Fake reencoding success under NO_ICONV instead of returning NULL Steffen Prohaska 2008-07-02 8:32 ` [PATCH 02/12] Do not complain about "no common commits" in an empty repo Steffen Prohaska @ 2008-07-02 18:43 ` Johannes Sixt 1 sibling, 0 replies; 371+ messages in thread From: Johannes Sixt @ 2008-07-02 18:43 UTC (permalink / raw) To: prohaska; +Cc: msysGit, git, Junio C Hamano On Mittwoch, 2. Juli 2008, Steffen Prohaska wrote: > From: Johannes Sixt <johannes.sixt@telecom.at> > > git-am when invoked from git-rebase seems to rely on successful conversion. > diff --git a/utf8.h b/utf8.h > index 98cce1b..f22ef31 100644 > --- a/utf8.h > +++ b/utf8.h > @@ -10,10 +10,6 @@ int is_encoding_utf8(const char *name); > > int print_wrapped_text(const char *text, int indent, int indent2, int > len); > > -#ifndef NO_ICONV > char *reencode_string(const char *in, const char *out_encoding, const char > *in_encoding); -#else > -#define reencode_string(a,b,c) NULL > -#endif > > #endif I don't think that this is still needed. It dates back to the origins of mingw.git, at which time I did not have a working libiconv. -- Hannes ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-30 9:08 ` Junio C Hamano 2008-06-30 11:19 ` How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics)) Steffen Prohaska @ 2008-06-30 14:09 ` Kristian Høgsberg 2008-06-30 15:58 ` Jakub Narebski 2008-06-30 22:15 ` Junio C Hamano 2008-07-01 10:11 ` Jeff King 2008-07-02 4:41 ` What's cooking in git.git (topics) Junio C Hamano 3 siblings, 2 replies; 371+ messages in thread From: Kristian Høgsberg @ 2008-06-30 14:09 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Mon, 2008-06-30 at 02:08 -0700, Junio C Hamano wrote: > Here are the topics that have been cooking. Commits prefixed > with '-' are only in 'pu' while commits prefixed with '+' are > in 'next'. > > The topics list the commits in reverse chronological order. The topics > meant to be applied to the maintenance series have "maint-" in their > names. > > It already is beginning to become clear what 1.6.0 will look like. What's > already in 'next' all are well intentioned (I do not guarantee they are > already bug-free --- that is what cooking them in 'next' is for) and are > good set of feature enhancements. Bigger changes will be: > > * MinGW will be in. > > * With the default Makefile settings, most of the programs will be > installed outside your $PATH, except for "git", "gitk", "git-gui" and > some server side programs that need to be accessible for technical > reasons. Invoking a git subcommand as "git-xyzzy" from the command > line has been deprecated since early 2006 (and officially announced in > 1.5.4 release notes); use of them from your scripts after adding > output from "git --exec-path" to the $PATH will still be supported in > 1.6.0, but users are again strongly encouraged to adjust their > scripts to use "git xyzzy" form, as we will stop installing > "git-xyzzy" hardlinks for built-in commands in later releases. > > * git-merge will be rewritten in C. > > * default pack and idx versions will be updated as scheduled for some > time ago. A small detail I've suggested scheduling for 1.6 before is removing (or rather, stop creating) the empty .git/branches directory. How does that sound? cheers, Kristian ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-30 14:09 ` What's cooking in git.git (topics) Kristian Høgsberg @ 2008-06-30 15:58 ` Jakub Narebski 2008-06-30 22:15 ` Junio C Hamano 2008-06-30 22:15 ` Junio C Hamano 1 sibling, 1 reply; 371+ messages in thread From: Jakub Narebski @ 2008-06-30 15:58 UTC (permalink / raw) To: Kristian Høgsberg; +Cc: Junio C Hamano, git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-30 15:58 ` Jakub Narebski @ 2008-06-30 22:15 ` Junio C Hamano 0 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-30 22:15 UTC (permalink / raw) To: Jakub Narebski; +Cc: Kristian Høgsberg, git Jakub Narebski <jnareb@gmail.com> writes: > Kristian Høgsberg <krh@redhat.com> writes: > >> >> A small detail I've suggested scheduling for 1.6 before is removing (or >> rather, stop creating) the empty .git/branches directory. How does that >> sound? > > Perhaps also stop creating .git/description (remove > 'templates/this--description' file), now that it is mentioned in > gitweb/README and/or gitweb/INSTALL? > > (Do you want a patch?) Not yet. I would first like to see a justification that makes sense. I do not see much connection between your mentioning the file in README and the file's removal. You currently say "By default it is set to ..." and you would have to change it to "By default it does not exist so you have to create one". Does it have much difference? Either way the user needs to open the file with the editor and edit it, and the current file at least says "Please edit me". I am not sure if removal is an improvement. The sample templates/hooks--update.sample seems to check if the contents of the description file makes sense, without even checking if it exists. That also needs to be updated. Actually, the sample hook should be updated independent of this issue. I'd suggest to simply remove the check from the sample hook. Setting description and installing the hook is part of the initial public repository deployment task, and once the description is set, the hook does not have to check it over and over again. Allowing arrival of new commits while the description is not set won't hurt anything (somebody would notice and tell "please set a better description" to the repository owner, and doing so at that point will fix things without anybody having to redo any old pushes), and forbidding push from the hook for lack of description does not make any sense. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-30 14:09 ` What's cooking in git.git (topics) Kristian Høgsberg 2008-06-30 15:58 ` Jakub Narebski @ 2008-06-30 22:15 ` Junio C Hamano 2008-06-30 22:51 ` Andrew Morton ` (3 more replies) 1 sibling, 4 replies; 371+ messages in thread From: Junio C Hamano @ 2008-06-30 22:15 UTC (permalink / raw) To: Kristian Høgsberg; +Cc: git, akpm, Stephen Rothwell, pasky Kristian Høgsberg <krh@redhat.com> writes: > On Mon, 2008-06-30 at 02:08 -0700, Junio C Hamano wrote: > ... >> It already is beginning to become clear what 1.6.0 will look like. What's >> already in 'next' all are well intentioned (I do not guarantee they are >> already bug-free --- that is what cooking them in 'next' is for) and are >> good set of feature enhancements. Bigger changes will be: > ... > A small detail I've suggested scheduling for 1.6 before is removing (or > rather, stop creating) the empty .git/branches directory. How does that > sound? What's the benefit of the removal that outweighs the downside? I can imagine two contradicting voices from new end users. (1) With current git, I ran "git init" and I have an empty .git/branches/, but my remote information created with "git clone" and "git remote add" all go to .git/config these days. Why do I have to have this empty directory that I do not use? (2) It is documented that "git fetch" can use files in .git/branches/ as the source specification, but when I ran "git init", it does not create the directory with Kristian's git. I need to do an extra "mkdir .git/branches/" myself. Why? You are obviously coming from the former camp, but do you have a good answer to people from the other camp? I do not recall if Cogito required to have .git/branches created by us or it can create it on demand if we don't. If the latter, that would be great, otherwise remaining users would be in the latter camp as well, and we may have to make sure Cogito is really dead already (or wait for it to die), or Cogito gets updated for its remaining users to tolerate the initial lack of the directory (and wait for that version percolates down to the users). Some people rely on (or at least "like") the convenience of being able to create a single-liner file in .git/branches/ to easily add, and remove such a file to easily remove where they integrate from. This is especially so when they have dozens of source repositories to fetch from. I do not think we want to remove support for .git/branches as a way to specify fetch sources (this is why I am CC'ing Andrew who I know uses branches, and Stephen who is also a heavy integrator even though I do not know if he is in branches camp or uses more modern style), but they now have to do an extra "mkdir .git/branches" after "git init" to continue their workflow if we adopt the change you are proposing here. It is not a big deal, but it still is a backward incompatible change. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-30 22:15 ` Junio C Hamano @ 2008-06-30 22:51 ` Andrew Morton 2008-06-30 23:09 ` Johannes Schindelin 2008-06-30 22:53 ` Petr Baudis ` (2 subsequent siblings) 3 siblings, 1 reply; 371+ messages in thread From: Andrew Morton @ 2008-06-30 22:51 UTC (permalink / raw) To: Junio C Hamano; +Cc: krh, git, sfr, pasky On Mon, 30 Jun 2008 15:15:52 -0700 Junio C Hamano <gitster@pobox.com> wrote: > Some people rely on (or at least "like") the convenience of being able to > create a single-liner file in .git/branches/ to easily add, and remove > such a file to easily remove where they integrate from. This is > especially so when they have dozens of source repositories to fetch from. > I do not think we want to remove support for .git/branches as a way to > specify fetch sources (this is why I am CC'ing Andrew who I know uses > branches, and Stephen who is also a heavy integrator even though I do not > know if he is in branches camp or uses more modern style), but they now > have to do an extra "mkdir .git/branches" after "git init" to continue > their workflow if we adopt the change you are proposing here. It is not a > big deal, but it still is a backward incompatible change. I do find the more compact format of .git/branches/git-foo to be convenient. For example, my scripts go looking in there for the URL and add that to the patch changelog so that people can reconstruct -mm's git-foo.patch from the relevant git tree. That being said, - It wouldn't bother me to have to type `mkdir .git/branches' after `git init'! - It's bad to have the same info in two places, and to have to support two different ways of doing the same thing for ever. So I could understand a wish to remove .git/branches/ support completely. I'll cope :) For me the biggest part of migrating would be working out what on earth the format of the new files is. Maybe it's documented somewhere undiscoverable, dunno. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-30 22:51 ` Andrew Morton @ 2008-06-30 23:09 ` Johannes Schindelin 0 siblings, 0 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-06-30 23:09 UTC (permalink / raw) To: Andrew Morton; +Cc: Junio C Hamano, krh, git, sfr, pasky 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-30 22:15 ` Junio C Hamano 2008-06-30 22:51 ` Andrew Morton @ 2008-06-30 22:53 ` Petr Baudis 2008-07-01 0:57 ` Stephen Rothwell 2008-07-01 15:44 ` Kristian Høgsberg 3 siblings, 0 replies; 371+ messages in thread From: Petr Baudis @ 2008-06-30 22:53 UTC (permalink / raw) To: Junio C Hamano; +Cc: Kristian H??gsberg, git, akpm, Stephen Rothwell On Mon, Jun 30, 2008 at 03:15:52PM -0700, Junio C Hamano wrote: > I do not recall if Cogito required to have .git/branches created by us or > it can create it on demand if we don't. If the latter, that would be > great, otherwise remaining users would be in the latter camp as well, and > we may have to make sure Cogito is really dead already (or wait for it to > die), or Cogito gets updated for its remaining users to tolerate the > initial lack of the directory (and wait for that version percolates down > to the users). Cogito is getting somewhat broken by removing of the git- plumbing from $PATH anyway (you have to hack around it; and I'm not saying it's bad thing). But it is actually quite resilient against this kind of stuff (as it was constructed to be able to run on very rudimental repositories dating early to the dawn of time). All versions supporting .git/branches [*] will autocreate the .git/branches directory if missing. [*] .git/branches was actually called .git/remotes even earlier; yay, how rich our history is. ;-) > Some people rely on (or at least "like") the convenience of being able to > create a single-liner file in .git/branches/ to easily add, and remove > such a file to easily remove where they integrate from. This is > especially so when they have dozens of source repositories to fetch from. > I do not think we want to remove support for .git/branches as a way to > specify fetch sources (this is why I am CC'ing Andrew who I know uses > branches, and Stephen who is also a heavy integrator even though I do not > know if he is in branches camp or uses more modern style), but they now > have to do an extra "mkdir .git/branches" after "git init" to continue > their workflow if we adopt the change you are proposing here. It is not a > big deal, but it still is a backward incompatible change. Now, I think it would be nice to keep backward compatibility here. I'm still _regularly_ running into people who still use Cogito (and it's not because they know me :-)) and are only now doing the switch, or only planning to yet. (On the other hand, using Git on repositories created by old Git versions or Cogito can be quite a confusing experience for non-expert users - things related to remote repositories behave differently to what the documentation describes, obviously. Maybe it _would_ be reasonable option to do something radical when hitting old repository, like "(Re-)clone me for non-confusing user experience, pretty please, or git-config force_old_repo 1 if you know what are you doing.") -- Petr "Pasky" Baudis The last good thing written in C++ was the Pachelbel Canon. -- J. Olson ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-30 22:15 ` Junio C Hamano 2008-06-30 22:51 ` Andrew Morton 2008-06-30 22:53 ` Petr Baudis @ 2008-07-01 0:57 ` Stephen Rothwell 2008-07-01 15:44 ` Kristian Høgsberg 3 siblings, 0 replies; 371+ messages in thread From: Stephen Rothwell @ 2008-07-01 0:57 UTC (permalink / raw) To: Junio C Hamano; +Cc: Kristian Høgsberg, git, akpm, pasky [-- Attachment #1: Type: text/plain, Size: 483 bytes --] On Mon, 30 Jun 2008 15:15:52 -0700 Junio C Hamano <gitster@pobox.com> wrote: > > branches, and Stephen who is also a heavy integrator even though I do not > know if he is in branches camp or uses more modern style), but they now I use "git remote add" for each new repository and haven't had anything in the branches directory of any of my trees for a long time ... -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-30 22:15 ` Junio C Hamano ` (2 preceding siblings ...) 2008-07-01 0:57 ` Stephen Rothwell @ 2008-07-01 15:44 ` Kristian Høgsberg 3 siblings, 0 replies; 371+ messages in thread From: Kristian Høgsberg @ 2008-07-01 15:44 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, akpm, Stephen Rothwell, pasky On Mon, 2008-06-30 at 15:15 -0700, Junio C Hamano wrote: > Kristian Høgsberg <krh@redhat.com> writes: > > > On Mon, 2008-06-30 at 02:08 -0700, Junio C Hamano wrote: > > ... > >> It already is beginning to become clear what 1.6.0 will look like. What's > >> already in 'next' all are well intentioned (I do not guarantee they are > >> already bug-free --- that is what cooking them in 'next' is for) and are > >> good set of feature enhancements. Bigger changes will be: > > ... > > A small detail I've suggested scheduling for 1.6 before is removing (or > > rather, stop creating) the empty .git/branches directory. How does that > > sound? > > What's the benefit of the removal that outweighs the downside? I can > imagine two contradicting voices from new end users. > > (1) With current git, I ran "git init" and I have an empty > .git/branches/, but my remote information created with "git clone" > and "git remote add" all go to .git/config these days. Why do I have > to have this empty directory that I do not use? Yeah, that's one reason, my main problem with .git/branches is that for a user that wants to learn about git and peeks into .git it's pretty confusing. "I wonder where and how git stores the information about branches... oh look, .git/branches, that must it... hmm, wait no..." Git is still getting a lot of bad-mouthing for being hard to learn and inconsitent. I think it makes sense to push git towards consistency and simplicity (where is doesn't affect the flexibility) and this seemed like a tiny step towards that. As Dscho mentioned we have two other ways of accomplishing what .git/branches did, so maybe it makes sense to retire this one? > (2) It is documented that "git fetch" can use files in .git/branches/ as > the source specification, but when I ran "git init", it does not > create the directory with Kristian's git. I need to do an extra > "mkdir .git/branches/" myself. Why? We could just change the documentation to ask the user to create the .git/branches directory if they want to use that feature. > You are obviously coming from the former camp, but do you have a good > answer to people from the other camp? > > I do not recall if Cogito required to have .git/branches created by us or > it can create it on demand if we don't. If the latter, that would be > great, otherwise remaining users would be in the latter camp as well, and > we may have to make sure Cogito is really dead already (or wait for it to > die), or Cogito gets updated for its remaining users to tolerate the > initial lack of the directory (and wait for that version percolates down > to the users). > > Some people rely on (or at least "like") the convenience of being able to > create a single-liner file in .git/branches/ to easily add, and remove > such a file to easily remove where they integrate from. This is > especially so when they have dozens of source repositories to fetch from. > I do not think we want to remove support for .git/branches as a way to > specify fetch sources (this is why I am CC'ing Andrew who I know uses > branches, and Stephen who is also a heavy integrator even though I do not > know if he is in branches camp or uses more modern style), but they now > have to do an extra "mkdir .git/branches" after "git init" to continue > their workflow if we adopt the change you are proposing here. It is not a > big deal, but it still is a backward incompatible change. Yeah... I have to confess, that when I suggested removing it, I was under the impression that git didn't use .git/branches, but only created it to be nice to cogito. I just read the code in remote.c that deals with .git/branches and understand that it's still used by git. From the feedback from Stephen, Andrew and Pasky, it looks like we can drop the .git/branches from the template for 1.6 and maybe in the future, we could drop the .git/branches support entirely. Dunno. cheers, Kristian ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-30 9:08 ` Junio C Hamano 2008-06-30 11:19 ` How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics)) Steffen Prohaska 2008-06-30 14:09 ` What's cooking in git.git (topics) Kristian Høgsberg @ 2008-07-01 10:11 ` Jeff King 2008-07-01 11:44 ` [PATCH] git-add--interactive: manual hunk editing mode Thomas Rast 2008-07-02 4:41 ` What's cooking in git.git (topics) Junio C Hamano 3 siblings, 1 reply; 371+ messages in thread From: Jeff King @ 2008-07-01 10:11 UTC (permalink / raw) To: Thomas Rast; +Cc: Junio C Hamano, Johannes Schindelin, git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* [PATCH] git-add--interactive: manual hunk editing mode 2008-07-01 10:11 ` Jeff King @ 2008-07-01 11:44 ` Thomas Rast 2008-07-01 16:48 ` Johannes Schindelin ` (2 more replies) 0 siblings, 3 replies; 371+ messages in thread From: Thomas Rast @ 2008-07-01 11:44 UTC (permalink / raw) To: git; +Cc: Jeff King, Junio C Hamano, Thomas Rast Adds a new option 'e' to the 'add -p' command loop that lets you edit the current hunk in your favourite editor. If the resulting patch applies cleanly, the edited hunk will immediately be marked for staging. If it does not apply cleanly, you will be given an opportunity to edit again. If all lines of the hunk are removed, then the edit is aborted and the hunk is left unchanged. Applying the changed hunk(s) relies on Johannes Schindelin's new --recount option for git-apply. Note that the "real patch" test intentionally uses (echo e; echo n; echo d) | git add -p even though the 'n' and 'd' are superfluous at first sight. They serve to get out of the interaction loop if git add -p wrongly concludes the patch does not apply. Many thanks to Jeff King <peff@peff.net> for lots of help and suggestions. Signed-off-by: Thomas Rast <trast@student.ethz.ch> --- Jeff King wrote: > Now that this is in next, maybe it is a good time to repost the > add--interactive patch (it should be independent of Dscho's 2/2 "add -e" > patch). It is independent, so I suppose you're right. (Dscho mentioned in passing he might repost "add -e" himself.) - Thomas Documentation/git-add.txt | 1 + git-add--interactive.perl | 124 +++++++++++++++++++++++++++++++++++++++++++- t/t3701-add-interactive.sh | 67 ++++++++++++++++++++++++ 3 files changed, 191 insertions(+), 1 deletions(-) diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index c6de028..1d8d209 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -246,6 +246,7 @@ patch:: k - leave this hunk undecided, see previous undecided hunk K - leave this hunk undecided, see previous hunk s - split the current hunk into smaller hunks + e - manually edit the current hunk ? - print help + After deciding the fate for all hunks, if there is any hunk diff --git a/git-add--interactive.perl b/git-add--interactive.perl index 903953e..6bb117a 100755 --- a/git-add--interactive.perl +++ b/git-add--interactive.perl @@ -2,6 +2,7 @@ use strict; use Git; +use File::Temp; my $repo = Git->repository(); @@ -18,6 +19,18 @@ my ($fraginfo_color) = $diff_use_color ? ( $repo->get_color('color.diff.frag', 'cyan'), ) : (); +my ($diff_plain_color) = + $diff_use_color ? ( + $repo->get_color('color.diff.plain', ''), + ) : (); +my ($diff_old_color) = + $diff_use_color ? ( + $repo->get_color('color.diff.old', 'red'), + ) : (); +my ($diff_new_color) = + $diff_use_color ? ( + $repo->get_color('color.diff.new', 'green'), + ) : (); my $normal_color = $repo->get_color("", "reset"); @@ -770,6 +783,104 @@ sub coalesce_overlapping_hunks { return @out; } +sub color_diff { + return map { + colored((/^@/ ? $fraginfo_color : + /^\+/ ? $diff_new_color : + /^-/ ? $diff_old_color : + $diff_plain_color), + $_); + } @_; +} + +sub edit_hunk_manually { + my ($oldtext) = @_; + + my $t = File::Temp->new( + TEMPLATE => $repo->repo_path . "/git-hunk-edit.XXXXXX", + SUFFIX => '.diff' + ); + print $t "# Manual hunk edit mode -- see bottom for a quick guide\n"; + print $t @$oldtext; + print $t <<EOF; +# --- +# To remove '-' lines, make them ' ' lines (context). +# To remove '+' lines, delete them. +# Lines starting with # will be removed. +# +# If the patch applies cleanly, the edited hunk will immediately be +# marked for staging. If it does not apply cleanly, you will be given +# an opportunity to edit again. If all lines of the hunk are removed, +# then the edit is aborted and the hunk is left unchanged. +EOF + close $t; + + my $editor = $ENV{GIT_EDITOR} || $repo->config("core.editor") + || $ENV{VISUAL} || $ENV{EDITOR} || "vi"; + system('sh', '-c', $editor.' "$@"', $editor, $t); + + open my $fh, '<', $t + or die "failed to open hunk edit file for reading: " . $!; + my @newtext = grep { !/^#/ } <$fh>; + close $fh; + + # Abort if nothing remains + if (!grep { /\S/ } @newtext) { + return undef; + } + + # Reinsert the first hunk header if the user accidentally deleted it + if ($newtext[0] !~ /^@/) { + unshift @newtext, $oldtext->[0]; + } + return \@newtext; +} + +sub diff_applies { + my $fh; + open $fh, '| git apply --recount --cached --check'; + for my $h (@_) { + print $fh @{$h->{TEXT}}; + } + return close $fh; +} + +sub prompt_yesno { + my ($prompt) = @_; + while (1) { + print colored $prompt_color, $prompt; + my $line = <STDIN>; + return 0 if $line =~ /^n/i; + return 1 if $line =~ /^y/i; + } +} + +sub edit_hunk_loop { + my ($head, $hunk, $ix) = @_; + my $text = $hunk->[$ix]->{TEXT}; + + while (1) { + $text = edit_hunk_manually($text); + if (!defined $text) { + return undef; + } + my $newhunk = { TEXT => $text, USE => 1 }; + if (diff_applies($head, + @{$hunk}[0..$ix-1], + $newhunk, + @{$hunk}[$ix+1..$#{$hunk}])) { + $newhunk->{DISPLAY} = [color_diff(@{$text})]; + return $newhunk; + } + else { + prompt_yesno( + 'Your edited hunk does not apply. Edit again ' + . '(saying "no" discards!) [y/n]? ' + ) or return undef; + } + } +} + sub help_patch_cmd { print colored $help_color, <<\EOF ; y - stage this hunk @@ -781,6 +892,7 @@ J - leave this hunk undecided, see next hunk k - leave this hunk undecided, see previous undecided hunk K - leave this hunk undecided, see previous hunk s - split the current hunk into smaller hunks +e - manually edit the current hunk ? - print help EOF } @@ -846,6 +958,7 @@ sub patch_update_file { $num = scalar @hunk; $ix = 0; + my $need_recount = 0; while (1) { my ($prev, $next, $other, $undecided, $i); @@ -885,6 +998,7 @@ sub patch_update_file { if (hunk_splittable($hunk[$ix]{TEXT})) { $other .= '/s'; } + $other .= '/e'; for (@{$hunk[$ix]{DISPLAY}}) { print; } @@ -949,6 +1063,13 @@ sub patch_update_file { $num = scalar @hunk; next; } + elsif ($line =~ /^e/) { + my $newhunk = edit_hunk_loop($head, \@hunk, $ix); + if (defined $newhunk) { + splice @hunk, $ix, 1, $newhunk; + $need_recount = 1; + } + } else { help_patch_cmd($other); next; @@ -1002,7 +1123,8 @@ sub patch_update_file { if (@result) { my $fh; - open $fh, '| git apply --cached'; + open $fh, '| git apply --cached' + . ($need_recount ? ' --recount' : ''); for (@{$head->{TEXT}}, @result) { print $fh $_; } diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh index fae64ea..e95663d 100755 --- a/t/t3701-add-interactive.sh +++ b/t/t3701-add-interactive.sh @@ -66,6 +66,73 @@ test_expect_success 'revert works (commit)' ' grep "unchanged *+3/-0 file" output ' +cat >expected <<EOF +EOF +cat >fake_editor.sh <<EOF +EOF +chmod a+x fake_editor.sh +test_set_editor "$(pwd)/fake_editor.sh" +test_expect_success 'dummy edit works' ' + (echo e; echo a) | git add -p && + git diff > diff && + test_cmp expected diff +' + +cat >patch <<EOF +@@ -1,1 +1,4 @@ + this ++patch +-doesn't + apply +EOF +echo "#!$SHELL_PATH" >fake_editor.sh +cat >>fake_editor.sh <<\EOF +mv -f "$1" oldpatch && +mv -f patch "$1" +EOF +chmod a+x fake_editor.sh +test_set_editor "$(pwd)/fake_editor.sh" +test_expect_success 'bad edit rejected' ' + git reset && + (echo e; echo n; echo d) | git add -p >output && + grep "hunk does not apply" output +' + +cat >patch <<EOF +this patch +is garbage +EOF +test_expect_success 'garbage edit rejected' ' + git reset && + (echo e; echo n; echo d) | git add -p >output && + grep "hunk does not apply" output +' + +cat >patch <<EOF +@@ -1,0 +1,0 @@ + baseline ++content ++newcontent ++lines +EOF +cat >expected <<EOF +diff --git a/file b/file +index b5dd6c9..f910ae9 100644 +--- a/file ++++ b/file +@@ -1,4 +1,4 @@ + baseline + content +-newcontent ++more + lines +EOF +test_expect_success 'real edit works' ' + (echo e; echo n; echo d) | git add -p && + git diff >output && + test_cmp expected output +' + if test "$(git config --bool core.filemode)" = false then say 'skipping filemode tests (filesystem does not properly support modes)' -- 1.5.4.5 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH] git-add--interactive: manual hunk editing mode 2008-07-01 11:44 ` [PATCH] git-add--interactive: manual hunk editing mode Thomas Rast @ 2008-07-01 16:48 ` Johannes Schindelin 2008-07-01 23:54 ` Junio C Hamano 2008-07-02 5:39 ` Junio C Hamano 2 siblings, 0 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-07-01 16:48 UTC (permalink / raw) To: Thomas Rast; +Cc: git, Jeff King, Junio C Hamano Hi, On Tue, 1 Jul 2008, Thomas Rast wrote: > (Dscho mentioned in passing he might repost "add -e" himself.) He will not :-) Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] git-add--interactive: manual hunk editing mode 2008-07-01 11:44 ` [PATCH] git-add--interactive: manual hunk editing mode Thomas Rast 2008-07-01 16:48 ` Johannes Schindelin @ 2008-07-01 23:54 ` Junio C Hamano 2008-07-02 5:39 ` Junio C Hamano 2 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-01 23:54 UTC (permalink / raw) To: Thomas Rast; +Cc: git, Jeff King Thomas Rast <trast@student.ethz.ch> writes: > Jeff King wrote: >> Now that this is in next, maybe it is a good time to repost the >> add--interactive patch (it should be independent of Dscho's 2/2 "add -e" >> patch). > > It is independent, so I suppose you're right. (Dscho mentioned in > passing he might repost "add -e" himself.) Thanks, both. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] git-add--interactive: manual hunk editing mode 2008-07-01 11:44 ` [PATCH] git-add--interactive: manual hunk editing mode Thomas Rast 2008-07-01 16:48 ` Johannes Schindelin 2008-07-01 23:54 ` Junio C Hamano @ 2008-07-02 5:39 ` Junio C Hamano 2008-07-02 7:00 ` Thomas Rast ` (2 more replies) 2 siblings, 3 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-02 5:39 UTC (permalink / raw) To: Thomas Rast; +Cc: git, Jeff King Thomas Rast <trast@student.ethz.ch> writes: > diff --git a/git-add--interactive.perl b/git-add--interactive.perl > index 903953e..6bb117a 100755 > --- a/git-add--interactive.perl > +++ b/git-add--interactive.perl > @@ -2,6 +2,7 @@ > > use strict; > use Git; > +use File::Temp; People with minimum Perl installation should still be able to use "add -i" as long as they do not use 'e' subcommand, shouldn't they? Shouldn't we do something like: my $can_use_temp = eval { require File::Temp; 1; }; and disable 'e' subcommand unless $can_use_temp? > +sub edit_hunk_manually { > + my ($oldtext) = @_; > + > + my $t = File::Temp->new( > + TEMPLATE => $repo->repo_path . "/git-hunk-edit.XXXXXX", > + SUFFIX => '.diff' > + ); > + print $t "# Manual hunk edit mode -- see bottom for a quick guide\n"; > + print $t @$oldtext; > + print $t <<EOF; > +# --- > +# To remove '-' lines, make them ' ' lines (context). > +# To remove '+' lines, delete them. > +# Lines starting with # will be removed. Don't you want to say "Do not touch lines that begin with ' '"? > + # Reinsert the first hunk header if the user accidentally deleted it > + if ($newtext[0] !~ /^@/) { > + unshift @newtext, $oldtext->[0]; > + } Hmm, perhaps not even giving the "@@ ... @@" lines to the editor would be a more robust solution? > +sub diff_applies { > + my $fh; > + open $fh, '| git apply --recount --cached --check'; > + for my $h (@_) { > + print $fh @{$h->{TEXT}}; > + } > + return close $fh; Have to wonder where the potential error message would go, and if it would confuse the end users... > @@ -1002,7 +1123,8 @@ sub patch_update_file { > if (@result) { > my $fh; > > - open $fh, '| git apply --cached'; > + open $fh, '| git apply --cached' > + . ($need_recount ? ' --recount' : ''); > for (@{$head->{TEXT}}, @result) { > print $fh $_; > } I recall that the original "add--interactive" carefully counted numbers in hunks it reassembles (as it can let you split and then you can choose to use both parts, which requires it to merge overlapping hunks back), but if you are going to use --recount anyway, perhaps we can discard that logic? It may make the patch application less robust, though. I dunno. An alternative, and probably more robust, approach would be to recount what we have in @{$mode->{TEXT}}, after letting the user edit some of them, so that "add--interactive" still knows what it is doing after applying your patch without having to rely on "apply --recount". ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] git-add--interactive: manual hunk editing mode 2008-07-02 5:39 ` Junio C Hamano @ 2008-07-02 7:00 ` Thomas Rast 2008-07-02 8:38 ` Junio C Hamano 2008-07-02 8:02 ` Jeff King 2008-07-02 21:58 ` [PATCH 0/3] git-add--interactive: use --recount, editing Thomas Rast 2 siblings, 1 reply; 371+ messages in thread From: Thomas Rast @ 2008-07-02 7:00 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, Jeff King [-- Attachment #1: Type: text/plain, Size: 2904 bytes --] Junio C Hamano wrote: > > People with minimum Perl installation should still be able to use "add -i" > as long as they do not use 'e' subcommand, shouldn't they? Shouldn't we > do something like: [...] > and disable 'e' subcommand unless $can_use_temp? I can just call the temporary editing file something constant, like the commit message already is. I don't care much about that point, and honestly assumed File::Temp came with every Perl (it's in perl-base here). > > +# To remove '-' lines, make them ' ' lines (context). > > +# To remove '+' lines, delete them. > > +# Lines starting with # will be removed. > > Don't you want to say "Do not touch lines that begin with ' '"? Why? You can make them '-' instead if you really want to :-) > > + # Reinsert the first hunk header if the user accidentally deleted it > > Hmm, perhaps not even giving the "@@ ... @@" lines to the editor would be > a more robust solution? I originally left it there because Emacs automatically recounts the header, and it also reminds the user of the function the hunk applies to. > > + open $fh, '| git apply --recount --cached --check'; > > Have to wonder where the potential error message would go, and if it would > confuse the end users... To the terminal. If we eat that error message, the user gets absolutely no indication as to _what_ might be wrong with the edited patch, so I kind of deliberately left it there. Then again the message from git-apply is not exactly transparent either. > I recall that the original "add--interactive" carefully counted numbers in > hunks it reassembles (as it can let you split and then you can choose to > use both parts, which requires it to merge overlapping hunks back), but if > you are going to use --recount anyway, perhaps we can discard that logic? We briefly talked about that[1], but Jeff thought it should be a separate patch, and I agree. Can't sneakily rip out two dozen lines of otherwise unrelated code in my feature patch, can I? > It may make the patch application less robust, though. I dunno. I've become convinced it can't, apart from making it less likely to trip over bugs in the script itself of course. > An alternative, and probably more robust, approach would be to recount > what we have in @{$mode->{TEXT}}, after letting the user edit some of > them, so that "add--interactive" still knows what it is doing after > applying your patch without having to rely on "apply --recount". You lost me here. Why recount the mode part? If you mean the _hunk_ headers, that's what the first three versions of this patch did, at the expense of a lot of code complication (and now that git-apply implements --recount, actually _duplication_). - Thomas [1] http://article.gmane.org/gmane.comp.version-control.git/84698 -- Thomas Rast trast@student.ethz.ch [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] git-add--interactive: manual hunk editing mode 2008-07-02 7:00 ` Thomas Rast @ 2008-07-02 8:38 ` Junio C Hamano 0 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-02 8:38 UTC (permalink / raw) To: Thomas Rast; +Cc: git, Jeff King Thomas Rast <trast@student.ethz.ch> writes: > Junio C Hamano wrote: > ... >> > +# To remove '-' lines, make them ' ' lines (context). >> > +# To remove '+' lines, delete them. >> > +# Lines starting with # will be removed. >> >> Don't you want to say "Do not touch lines that begin with ' '"? > > Why? You can make them '-' instead if you really want to :-) If you change '-' to ' ', or remove '+', then you are temporarily reverting the change you have made since HEAD to your working tree copy. If you do not change anything, you are taking something that was in your working tree copy. Both are simpler and easier to explain operations. Once you allow changing ' ' to '-' or insert '+' at random places, however, you are letting the user commit lines that is neither from HEAD nor from the working tree. If the goal of "e" action in "add -i" is to support that operation (I am not saying that it is a bad thing to support), you have to deal with an issue that your patch so far did not have to deal with, and it would require a much larger change to the way how "add -i" is structured. When you give the user a hunk like this to edit: @@ -4,9 +4,6 @@ GIT v1.6.0 Release Notes User visible changes -------------------- -[[Note that none of these are not merged to 'master' as of this writing -but they will be before 1.6.0 happens]] - With the default Makefile settings, most of the programs are now installed outside your $PATH, except for "git", "gitk", "git-gui" and some server side programs that need to be accessible for technical the user may want to change the line before the line that has "User visible changes", or the lines toward the end of the hunk. The user may want to edit the line that ends with "for technical" for rewording the sentence, but the rest of the sentence is outside the context, and these lines somehow needs to be summoned to the editing session for completing the updated sentence. In order to support that, you need to be able to extend the context on demand in either direction, beyond the original "git diff" output you captured in $hunk[$i]{TEXT} (sorry, I misspelled this as $mode->{TEXT} in the previous message). Once you start to do that, you would need to worry about the case where the hunk extended to include later lines overlaps with the hunk after the one we are currently looking at, and run coalesce_overlapping_hunks to concatenate them into a larger single hunk. But to be able to do that, you would need to keep track of the number of lines in a hunk yourself anyway, which would mean that you cannot rely on --recount anymore. The extension recently made to "git apply" becomes redundant and unused code. In short, declaring that you are supporting the use to change ' ' to '-' means you are opening a whole can of worms, and I asked the question because I did not know if you are really prepared to deal with it. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] git-add--interactive: manual hunk editing mode 2008-07-02 5:39 ` Junio C Hamano 2008-07-02 7:00 ` Thomas Rast @ 2008-07-02 8:02 ` Jeff King 2008-07-02 8:08 ` Junio C Hamano 2008-07-02 21:58 ` [PATCH 0/3] git-add--interactive: use --recount, editing Thomas Rast 2 siblings, 1 reply; 371+ messages in thread From: Jeff King @ 2008-07-02 8:02 UTC (permalink / raw) To: Junio C Hamano; +Cc: Thomas Rast, git On Tue, Jul 01, 2008 at 10:39:58PM -0700, Junio C Hamano wrote: > > +use File::Temp; > > People with minimum Perl installation should still be able to use "add -i" > as long as they do not use 'e' subcommand, shouldn't they? Shouldn't we > do something like: > > my $can_use_temp = eval { > require File::Temp; > 1; > }; > > and disable 'e' subcommand unless $can_use_temp? According to Module::CoreList, File::Temp has shipped as part of core perl since 5.006001. "add -i" doesn't work with perl < 5.6 already due to things like 3-argument open. So if the problem is "old perl", I don't think it is an issue. Are there modern perl installations in the wild that don't have File::Temp? -Peff ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] git-add--interactive: manual hunk editing mode 2008-07-02 8:02 ` Jeff King @ 2008-07-02 8:08 ` Junio C Hamano 2008-07-02 8:32 ` Jeff King 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-02 8:08 UTC (permalink / raw) To: Jeff King; +Cc: Thomas Rast, git Jeff King <peff@peff.net> writes: > According to Module::CoreList, File::Temp has shipped as part of core > perl since 5.006001. "add -i" doesn't work with perl < 5.6 already due to > things like 3-argument open. > > So if the problem is "old perl", I don't think it is an issue. Are there > modern perl installations in the wild that don't have File::Temp? The thing is, I think I heard quite similar explanation why Test::More is safe to use when the patch to add t/t9700 was submit. Then what happened? ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] git-add--interactive: manual hunk editing mode 2008-07-02 8:08 ` Junio C Hamano @ 2008-07-02 8:32 ` Jeff King 2008-07-02 13:13 ` Johannes Schindelin 0 siblings, 1 reply; 371+ messages in thread From: Jeff King @ 2008-07-02 8:32 UTC (permalink / raw) To: Junio C Hamano; +Cc: Thomas Rast, git On Wed, Jul 02, 2008 at 01:08:09AM -0700, Junio C Hamano wrote: > > So if the problem is "old perl", I don't think it is an issue. Are there > > modern perl installations in the wild that don't have File::Temp? > > The thing is, I think I heard quite similar explanation why Test::More is > safe to use when the patch to add t/t9700 was submit. Then what happened? ISTR the Test::More problem was reported by Linus, who is a Fedora user? I tried searching for any reasonable information on which of the core perl modules are installed by default on Fedora systems, but didn't come up with anything useful. I really have no clue as to what is out there, and I suspect we must either play it totally safe, or push the limits and wait for people to complain about breakage. -Peff ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] git-add--interactive: manual hunk editing mode 2008-07-02 8:32 ` Jeff King @ 2008-07-02 13:13 ` Johannes Schindelin 2008-07-02 18:27 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Johannes Schindelin @ 2008-07-02 13:13 UTC (permalink / raw) To: Jeff King; +Cc: Junio C Hamano, Thomas Rast, git Hi, On Wed, 2 Jul 2008, Jeff King wrote: > On Wed, Jul 02, 2008 at 01:08:09AM -0700, Junio C Hamano wrote: > > > > So if the problem is "old perl", I don't think it is an issue. Are > > > there modern perl installations in the wild that don't have > > > File::Temp? > > > > The thing is, I think I heard quite similar explanation why Test::More > > is safe to use when the patch to add t/t9700 was submit. Then what > > happened? > > ISTR the Test::More problem was reported by Linus, who is a Fedora user? > I tried searching for any reasonable information on which of the core > perl modules are installed by default on Fedora systems, but didn't come > up with anything useful. > > I really have no clue as to what is out there, and I suspect we must > either play it totally safe, or push the limits and wait for people to > complain about breakage. I wonder why bother trying to import things when you do not need them to begin with! I mean, it is _obvious_ that in this case, we want .git/ to be writable _anyway_, so why not stick with a fixed name in that? Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH] git-add--interactive: manual hunk editing mode 2008-07-02 13:13 ` Johannes Schindelin @ 2008-07-02 18:27 ` Junio C Hamano 0 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-02 18:27 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Jeff King, Thomas Rast, git 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? ^ permalink raw reply [flat|nested] 371+ messages in thread
* [PATCH 0/3] git-add--interactive: use --recount, editing 2008-07-02 5:39 ` Junio C Hamano 2008-07-02 7:00 ` Thomas Rast 2008-07-02 8:02 ` Jeff King @ 2008-07-02 21:58 ` Thomas Rast 2008-07-02 21:59 ` [PATCH 1/3] git-add--interactive: replace hunk recounting with apply --recount Thomas Rast 2 siblings, 1 reply; 371+ messages in thread From: Thomas Rast @ 2008-07-02 21:58 UTC (permalink / raw) To: git; +Cc: Junio C Hamano, Jeff King Junio C Hamano wrote: > > I recall that the original "add--interactive" carefully counted numbers in > hunks it reassembles (as it can let you split and then you can choose to > use both parts, which requires it to merge overlapping hunks back), but if > you are going to use --recount anyway, perhaps we can discard that logic? > It may make the patch application less robust, though. I dunno. This series takes it a bit further. I played around with 'apply', and it seems there is no reason to even merge the hunks. (It would be great if someone who knows builtin-apply.c could confirm this.) So we can get rid of all recounting except for the correct splitting boundaries. These are the first two patches. Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > I wonder why bother trying to import things when you do not need them to > > begin with! I mean, it is _obvious_ that in this case, we want .git/ to > > be writable _anyway_, so why not stick with a fixed name in that? > > Good suggestion -- I love that simplicity. Thomas? Well, changed that back. Apart from that, no real changes to 3/3, but the $needs_recount code has become unnecessary because 1/3 already forces --recount. - Thomas Documentation/git-add.txt | 1 + git-add--interactive.perl | 203 ++++++++++++++++++++++--------------------- t/t3701-add-interactive.sh | 67 +++++++++++++++ 3 files changed, 172 insertions(+), 99 deletions(-) ^ permalink raw reply [flat|nested] 371+ messages in thread
* [PATCH 1/3] git-add--interactive: replace hunk recounting with apply --recount 2008-07-02 21:58 ` [PATCH 0/3] git-add--interactive: use --recount, editing Thomas Rast @ 2008-07-02 21:59 ` Thomas Rast 2008-07-02 21:59 ` [PATCH 2/3] git-add--interactive: remove hunk coalescing Thomas Rast 0 siblings, 1 reply; 371+ messages in thread From: Thomas Rast @ 2008-07-02 21:59 UTC (permalink / raw) To: git; +Cc: Junio C Hamano, Jeff King 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 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH 2/3] git-add--interactive: remove hunk coalescing 2008-07-02 21:59 ` [PATCH 1/3] git-add--interactive: replace hunk recounting with apply --recount Thomas Rast @ 2008-07-02 21:59 ` Thomas Rast 2008-07-02 22:00 ` [PATCH 3/3] git-add--interactive: manual hunk editing mode Thomas Rast 2008-07-02 22:26 ` [PATCH 2/3] git-add--interactive: remove hunk coalescing Junio C Hamano 0 siblings, 2 replies; 371+ messages in thread From: Thomas Rast @ 2008-07-02 21:59 UTC (permalink / raw) To: git; +Cc: Junio C Hamano, Jeff King 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 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* [PATCH 3/3] git-add--interactive: manual hunk editing mode 2008-07-02 21:59 ` [PATCH 2/3] git-add--interactive: remove hunk coalescing Thomas Rast @ 2008-07-02 22:00 ` Thomas Rast 2008-07-02 22:26 ` [PATCH 2/3] git-add--interactive: remove hunk coalescing Junio C Hamano 1 sibling, 0 replies; 371+ messages in thread From: Thomas Rast @ 2008-07-02 22:00 UTC (permalink / raw) To: git; +Cc: Junio C Hamano, Jeff King 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 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: [PATCH 2/3] git-add--interactive: remove hunk coalescing 2008-07-02 21:59 ` [PATCH 2/3] git-add--interactive: remove hunk coalescing Thomas Rast 2008-07-02 22:00 ` [PATCH 3/3] git-add--interactive: manual hunk editing mode Thomas Rast @ 2008-07-02 22:26 ` Junio C Hamano 2008-07-02 22:35 ` Junio C Hamano 1 sibling, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-02 22:26 UTC (permalink / raw) To: Thomas Rast; +Cc: git, Jeff King Thomas Rast <trast@student.ethz.ch> writes: > Current git-apply has no trouble at all applying chunks that have > overlapping context, as produced by the splitting feature. So we can > drop the manual coalescing. > > Signed-off-by: Thomas Rast <trast@student.ethz.ch> > --- > git-add--interactive.perl | 89 --------------------------------------------- > 1 files changed, 0 insertions(+), 89 deletions(-) > > diff --git a/git-add--interactive.perl b/git-add--interactive.perl > index e1964a5..a4234d3 100755 > --- a/git-add--interactive.perl > +++ b/git-add--interactive.perl > @@ -682,93 +682,6 @@ sub split_hunk { > return @split; > } > > -sub find_last_o_ctx { > ... > -} > - > -sub merge_hunk { > ... > -} > - > -sub coalesce_overlapping_hunks { > ... > -} > > sub help_patch_cmd { > print colored $help_color, <<\EOF ; > @@ -962,8 +875,6 @@ sub patch_update_file { > } > } > > - @hunk = coalesce_overlapping_hunks(@hunk); > - > my $n_lofs = 0; > my @result = (); > if ($mode->{USE}) { > -- > 1.5.6.1.276.gde9a I think [1/3] makes sense as we trust --recount anyway (and more importantly if the user did not muck with the patch --recount would be a no-op), but I am not sure about this one. I suspect this change reduces the precision and safety of the patch application, especially when the user does not edit hunks. When you "[s]plit" a hunk like this: @@ -n,7 +m,6 @@ con text -deleted preimage +replaced postimage more line of context -deleted another context into two, we prepare these two hunks internally: @@ -n,5 +m,5 @@ con text -deleted preimage +replaced postimage more line of context @@ -l,4 +k,3 @@ -- l=n+5, k=m+5 more line of context -deleted another context So that applying only one piece without applying the other would still have correct context to locate where to apply. However, if the user says "I want to apply both after all", we would need to remove the overlap when merge them back. If you don't, you would be feeding a nonsense patch to "git apply" that goes back in context. Blindly concatenating the above two and feeding them to "git apply" *may* happen to work by accident, not by design. This very much feels like a hack of "This works most of the time for me, your mileage may vary" kind, which we would want to avoid when we can. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 2/3] git-add--interactive: remove hunk coalescing 2008-07-02 22:26 ` [PATCH 2/3] git-add--interactive: remove hunk coalescing Junio C Hamano @ 2008-07-02 22:35 ` Junio C Hamano 2008-07-03 19:24 ` Thomas Rast 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-02 22:35 UTC (permalink / raw) To: Thomas Rast; +Cc: git, Jeff King 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 2/3] git-add--interactive: remove hunk coalescing 2008-07-02 22:35 ` Junio C Hamano @ 2008-07-03 19:24 ` Thomas Rast 2008-07-03 21:46 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Thomas Rast @ 2008-07-03 19:24 UTC (permalink / raw) To: Junio C Hamano; +Cc: git [-- Attachment #1: Type: text/plain, Size: 797 bytes --] Junio C Hamano wrote: > > > Blindly concatenating the above two and feeding them to "git apply" *may* > > happen to work by accident, not by design. This very much feels like a > > hack of "This works most of the time for me, your mileage may vary" kind, > > which we would want to avoid when we can. > > Well, I changed my mind. Let's run with this and see what happens. In support of this being a feature of git-apply, notice that it even handles the situation correctly where the context of a hunk has been influenced by previous hunks, as in @@ -1,2 +1,3 @@ foo +quux bar @@ -1,3 +1,4 @@ foo quux +abc bar With Don Zickus' recent patch, it also handles patches that go over the same file twice. - Thomas -- Thomas Rast trast@student.ethz.ch [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 2/3] git-add--interactive: remove hunk coalescing 2008-07-03 19:24 ` Thomas Rast @ 2008-07-03 21:46 ` Junio C Hamano 0 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-03 21:46 UTC (permalink / raw) To: Thomas Rast; +Cc: git Thomas Rast <trast@student.ethz.ch> writes: > Junio C Hamano wrote: >> >> > Blindly concatenating the above two and feeding them to "git apply" *may* >> > happen to work by accident, not by design. This very much feels like a >> > hack of "This works most of the time for me, your mileage may vary" kind, >> > which we would want to avoid when we can. >> >> Well, I changed my mind. Let's run with this and see what happens. > > In support of this being a feature of git-apply, notice that it even > handles the situation correctly where the context of a hunk has been > influenced by previous hunks, as in... That's what meant by my earlier "application is hunk-by-hunk in nature" and we are in agreement. The fact it works that way is not quite by design and close to being "by accident", but I do not foresee anybody changing it in the near future, so... ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-06-30 9:08 ` Junio C Hamano ` (2 preceding siblings ...) 2008-07-01 10:11 ` Jeff King @ 2008-07-02 4:41 ` Junio C Hamano 2008-07-06 10:04 ` Junio C Hamano 3 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-02 4:41 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-07-02 4:41 ` What's cooking in git.git (topics) Junio C Hamano @ 2008-07-06 10:04 ` Junio C Hamano 2008-07-06 11:10 ` Johannes Schindelin 2008-07-08 2:46 ` Junio C Hamano 0 siblings, 2 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-06 10:04 UTC (permalink / raw) To: git 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". ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-06 10:04 ` Junio C Hamano @ 2008-07-06 11:10 ` Johannes Schindelin 2008-07-07 1:36 ` Junio C Hamano 2008-07-08 2:46 ` Junio C Hamano 1 sibling, 1 reply; 371+ messages in thread From: Johannes Schindelin @ 2008-07-06 11:10 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-06 11:10 ` Johannes Schindelin @ 2008-07-07 1:36 ` Junio C Hamano 0 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-07 1:36 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > On Sun, 6 Jul 2008, Junio C Hamano wrote: > >> * js/apply-root (Wed Jul 2 15:28:22 2008 -0700) 2 commits >> + apply --root: thinkofix. >> + Teach "git apply" to prepend a prefix with "--root=<root>" > > If we want to call this "--directory=<root>" instead, we should do it > before that commit hits master. Yeah, perhaps like this? -- >8 -- git-apply --directory: make --root more similar to GNU diff Applying a patch in the directory that is different from what the patch records is done with --directory option in GNU diff. The --root option we introduced previously does the same, and we can call it the same way to give users more familiar feel. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- Documentation/git-apply.txt | 8 ++++++-- builtin-apply.c | 4 ++-- t/t4128-apply-root.sh | 8 ++++---- 3 files changed, 12 insertions(+), 8 deletions(-) diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt index 63fce53..3cd3179 100644 --- a/Documentation/git-apply.txt +++ b/Documentation/git-apply.txt @@ -14,7 +14,7 @@ SYNOPSIS [--allow-binary-replacement | --binary] [--reject] [-z] [-pNUM] [-CNUM] [--inaccurate-eof] [--cached] [--whitespace=<nowarn|warn|fix|error|error-all>] - [--exclude=PATH] [--root=<root>] [--verbose] [<patch>...] + [--exclude=PATH] [--directory=<root>] [--verbose] [<patch>...] DESCRIPTION ----------- @@ -177,9 +177,13 @@ behavior: current patch being applied will be printed. This option will cause additional information to be reported. ---root=<root>:: +--directory=<root>:: Prepend <root> to all filenames. If a "-p" argument was passed, too, it is applied before prepending the new root. ++ +For example, a patch that talks about updating `a/git-gui.sh` to `b/git-gui.sh` +can be applied to the file in the working tree `modules/git-gui/git-gui.sh` by +running `git apply --directory=modules/git-gui`. Configuration ------------- diff --git a/builtin-apply.c b/builtin-apply.c index 6c3db60..c242bbd 100644 --- a/builtin-apply.c +++ b/builtin-apply.c @@ -3130,8 +3130,8 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix) inaccurate_eof = 1; continue; } - if (!prefixcmp(arg, "--root=")) { - arg += strlen("--root="); + if (!prefixcmp(arg, "--directory=")) { + arg += strlen("--directory="); root_len = strlen(arg); if (root_len && arg[root_len - 1] != '/') { char *new_root; diff --git a/t/t4128-apply-root.sh b/t/t4128-apply-root.sh index b650245..2dd0c75 100755 --- a/t/t4128-apply-root.sh +++ b/t/t4128-apply-root.sh @@ -23,18 +23,18 @@ diff a/bla/blub/dir/file b/bla/blub/dir/file +Bello EOF -test_expect_success 'apply --root -p (1)' ' +test_expect_success 'apply --directory -p (1)' ' - git apply --root=some/sub -p3 --index patch && + git apply --directory=some/sub -p3 --index patch && test Bello = $(git show :some/sub/dir/file) && test Bello = $(cat some/sub/dir/file) ' -test_expect_success 'apply --root -p (2) ' ' +test_expect_success 'apply --directory -p (2) ' ' git reset --hard initial && - git apply --root=some/sub/ -p3 --index patch && + git apply --directory=some/sub/ -p3 --index patch && test Bello = $(git show :some/sub/dir/file) && test Bello = $(cat some/sub/dir/file) ^ permalink raw reply related [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-07-06 10:04 ` Junio C Hamano 2008-07-06 11:10 ` Johannes Schindelin @ 2008-07-08 2:46 ` Junio C Hamano 2008-07-10 2:32 ` Junio C Hamano 1 sibling, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-08 2:46 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-07-08 2:46 ` Junio C Hamano @ 2008-07-10 2:32 ` Junio C Hamano 2008-07-14 5:11 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-10 2:32 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-07-10 2:32 ` Junio C Hamano @ 2008-07-14 5:11 ` Junio C Hamano 2008-07-14 6:45 ` Junio C Hamano ` (5 more replies) 0 siblings, 6 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-14 5:11 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-14 5:11 ` Junio C Hamano @ 2008-07-14 6:45 ` Junio C Hamano 2008-07-14 7:50 ` Closing the merge window for 1.6.0 Junio C Hamano ` (4 subsequent siblings) 5 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-14 6:45 UTC (permalink / raw) To: Lea Wiemann; +Cc: git Junio C Hamano <gitster@pobox.com> writes: > * lw/gitweb (Fri Jul 11 03:11:48 2008 +0200) 3 commits > - gitweb: use new Git::Repo API, and add optional caching > - Add new Git::Repo API > - gitweb: add test suite with Test::WWW::Mechanize::CGI > > This does not pass t9710, at least for me X-<. This is getting a bit boring and tiresome. Obviously I haven't checked what _else_ is missing because I did not install Carp::Always myself to my system. t/t9710-perl-git-repo.sh | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t9710-perl-git-repo.sh b/t/t9710-perl-git-repo.sh index ca67b87..2da3cd8 100755 --- a/t/t9710-perl-git-repo.sh +++ b/t/t9710-perl-git-repo.sh @@ -6,8 +6,8 @@ test_description='perl interface (Git/*.pm)' . ./test-lib.sh -perl -MTest::More -e 0 2>/dev/null || { - say_color skip "Perl Test::More unavailable, skipping test" +perl -MTest::More -MTest::Exception -MCarp::Always -e 0 2>/dev/null || { + say_color skip "Perl Test::{More,Exception}, Carp::Always unavailable, skipping test" test_done } ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Closing the merge window for 1.6.0 2008-07-14 5:11 ` Junio C Hamano 2008-07-14 6:45 ` Junio C Hamano @ 2008-07-14 7:50 ` Junio C Hamano 2008-07-14 8:07 ` Johannes Sixt ` (2 more replies) 2008-07-14 11:53 ` What's cooking in git.git (topics) Johannes Schindelin ` (3 subsequent siblings) 5 siblings, 3 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-14 7:50 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-14 7:50 ` Closing the merge window for 1.6.0 Junio C Hamano @ 2008-07-14 8:07 ` Johannes Sixt 2008-07-14 8:50 ` Jakub Narebski 2008-07-14 8:55 ` Petr Baudis 2 siblings, 0 replies; 371+ messages in thread From: Johannes Sixt @ 2008-07-14 8:07 UTC (permalink / raw) To: Shawn O. Pearce; +Cc: Junio C Hamano, git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-14 7:50 ` Closing the merge window for 1.6.0 Junio C Hamano 2008-07-14 8:07 ` Johannes Sixt @ 2008-07-14 8:50 ` Jakub Narebski 2008-07-14 8:55 ` Petr Baudis 2 siblings, 0 replies; 371+ messages in thread From: Jakub Narebski @ 2008-07-14 8:50 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-14 7:50 ` Closing the merge window for 1.6.0 Junio C Hamano 2008-07-14 8:07 ` Johannes Sixt 2008-07-14 8:50 ` Jakub Narebski @ 2008-07-14 8:55 ` Petr Baudis 2008-07-14 11:57 ` Johannes Schindelin 2008-07-14 19:16 ` Junio C Hamano 2 siblings, 2 replies; 371+ messages in thread From: Petr Baudis @ 2008-07-14 8:55 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-14 8:55 ` Petr Baudis @ 2008-07-14 11:57 ` Johannes Schindelin 2008-07-14 12:41 ` Gerrit Pape 2008-07-14 12:43 ` Petr Baudis 2008-07-14 19:16 ` Junio C Hamano 1 sibling, 2 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-07-14 11:57 UTC (permalink / raw) To: Petr Baudis; +Cc: Junio C Hamano, git Hi, On Mon, 14 Jul 2008, Petr Baudis wrote: > I'm saying this because I believe the best conservative upper bound for > backwards compatibility is Git version in Debian stable. It gets > probably the most stale from all the widely used software distributions > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which > fails miserably on the new packs. Can't we just hit Debian's Git maintainer with a clue bat or a bus, whichever is easier, and force them to upgrade _in_ Etch? It's not like we haven't had _several_ stable releases in-between. Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-14 11:57 ` Johannes Schindelin @ 2008-07-14 12:41 ` Gerrit Pape 2008-07-14 12:56 ` Johannes Schindelin 2008-07-14 17:54 ` Nicolas Pitre 2008-07-14 12:43 ` Petr Baudis 1 sibling, 2 replies; 371+ messages in thread From: Gerrit Pape @ 2008-07-14 12:41 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Petr Baudis, Junio C Hamano, git On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote: > On Mon, 14 Jul 2008, Petr Baudis wrote: > > I'm saying this because I believe the best conservative upper bound for > > backwards compatibility is Git version in Debian stable. It gets > > probably the most stale from all the widely used software distributions > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which > > fails miserably on the new packs. > > Can't we just hit Debian's Git maintainer with a clue bat or a bus, Please don't. It wouldn't help, rather the opposite I think, espacially the bus. We don't introduce new upstream versions into a Debian stable release, there's a great effort done for each stable release to reach high quality integration of all the software packages available in Debian. Once that status is reached, only security fixes and criticial usability fixes are added. The freeze of the packages for the next stable release is planned a few days from now, so it looks like Debian 'lenny' will include git 1.5.6.x. Regards, Gerrit. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-14 12:41 ` Gerrit Pape @ 2008-07-14 12:56 ` Johannes Schindelin 2008-07-14 17:54 ` Nicolas Pitre 1 sibling, 0 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-07-14 12:56 UTC (permalink / raw) To: Gerrit Pape; +Cc: Petr Baudis, Junio C Hamano, git Hi, On Mon, 14 Jul 2008, Gerrit Pape wrote: > On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote: > > On Mon, 14 Jul 2008, Petr Baudis wrote: > > > I'm saying this because I believe the best conservative upper bound for > > > backwards compatibility is Git version in Debian stable. It gets > > > probably the most stale from all the widely used software distributions > > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which > > > fails miserably on the new packs. > > > > Can't we just hit Debian's Git maintainer with a clue bat or a bus, > > Please don't. It wouldn't help, rather the opposite I think, espacially > the bus. Heh. It was a feeble attempt at humor production ;-) > We don't introduce new upstream versions into a Debian stable release, > there's a great effort done for each stable release to reach high > quality integration of all the software packages available in Debian. > Once that status is reached, only security fixes and criticial usability > fixes are added. If that is the case, we might need to think about fixing that segmentation fault to 1.4.4.5... Which would be a minor pain in the donkey, I guess. > The freeze of the packages for the next stable release is planned a few > days from now, so it looks like Debian 'lenny' will include git 1.5.6.x. >From my memories of IRC, it seems that quite a few people do not even consider upgrading. Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-14 12:41 ` Gerrit Pape 2008-07-14 12:56 ` Johannes Schindelin @ 2008-07-14 17:54 ` Nicolas Pitre 2008-07-14 19:00 ` Junio C Hamano 2008-07-15 2:51 ` Shawn O. Pearce 1 sibling, 2 replies; 371+ messages in thread From: Nicolas Pitre @ 2008-07-14 17:54 UTC (permalink / raw) To: Gerrit Pape; +Cc: Johannes Schindelin, Petr Baudis, Junio C Hamano, git On Mon, 14 Jul 2008, Gerrit Pape wrote: > On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote: > > On Mon, 14 Jul 2008, Petr Baudis wrote: > > > I'm saying this because I believe the best conservative upper bound for > > > backwards compatibility is Git version in Debian stable. It gets > > > probably the most stale from all the widely used software distributions > > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which > > > fails miserably on the new packs. > > > > Can't we just hit Debian's Git maintainer with a clue bat or a bus, > > Please don't. It wouldn't help, rather the opposite I think, espacially > the bus. We don't introduce new upstream versions into a Debian stable > release, there's a great effort done for each stable release to reach > high quality integration of all the software packages available in > Debian. Once that status is reached, only security fixes and criticial > usability fixes are added. Please consider it as a critical usability problem. Maybe we can release 1.4.5 with the ability to read index v2? That wouldn't be hard to backport the reading part of it. Nicolas ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-14 17:54 ` Nicolas Pitre @ 2008-07-14 19:00 ` Junio C Hamano 2008-07-14 19:19 ` Teemu Likonen 2008-07-15 9:20 ` Petr Baudis 2008-07-15 2:51 ` Shawn O. Pearce 1 sibling, 2 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-14 19:00 UTC (permalink / raw) To: Nicolas Pitre; +Cc: Gerrit Pape, Johannes Schindelin, Petr Baudis, git Nicolas Pitre <nico@cam.org> writes: > On Mon, 14 Jul 2008, Gerrit Pape wrote: > >> On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote: >> > On Mon, 14 Jul 2008, Petr Baudis wrote: >> > > I'm saying this because I believe the best conservative upper bound for >> > > backwards compatibility is Git version in Debian stable. It gets >> > > probably the most stale from all the widely used software distributions >> > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which >> > > fails miserably on the new packs. >> > >> > Can't we just hit Debian's Git maintainer with a clue bat or a bus, >> >> Please don't. It wouldn't help, rather the opposite I think, espacially >> the bus. We don't introduce new upstream versions into a Debian stable >> release, there's a great effort done for each stable release to reach >> high quality integration of all the software packages available in >> Debian. Once that status is reached, only security fixes and criticial >> usability fixes are added. > > Please consider it as a critical usability problem. > > Maybe we can release 1.4.5 with the ability to read index v2? That > wouldn't be hard to backport the reading part of it. I am of two minds here. On one hand, I am sympathetic to distros that want to give long time support for ancient versions to keep working in an ever-changing new world. It is a wonderful thing that there are distros that aim for ultra conservative stability, and I applaud them. But as the upstream, we have our own deprecation schedule. We should of course plan carefully not to harm existing users of our releases, but frankly speaking, 18 months since 1.4.4.4 was tagged (early January 2007) is an eternity in git timescale. Maybe we will slow down someday, and this 18-month is not a set-in-stone rule in any way, but at this point even without the packfile format issues, I personally think anything before 1.5.0 is irrelevant --- maybe they are interesting as historical curiosities, but not more than that. We could: $ git checkout -b maint-1.4 v1.4.4.4 $ git merge maint $ git tag v1.4.4.5 and push the result out. While I would imagine that the end-user experience after such a maintenance release would be very positive, that is not something distros who really want to stay with a stale version for a good reason would want to swallow ;-). If we _were_ to keep v1.4.4.X series alive, serious backporting efforts will be necessary. For example, recent 'git-shell' futureproofing was made not just to 1.5.6.X series but was backported to 1.5.4.X and 1.5.5.X, and we would probably need to give it to 1.4.4.X as well. What other things are there that are missing in 1.4.4.X? It would take nontrivial engineering resource to even list them, let alone assessing how much effort is required for such backporting and actually doing it. The remotes/ layout, use of "git-add" for new contents (instead of only new files), reflogs, detached HEAD, --pretty=format:%<blah>, bundles, mergetool,... all the things that a modern git workflow revolves around and are described in the user manuals the users find on the net are not found in 1.4.4.X series. If a user of such a conservative distro needs to work with a repository prepared on another platform with newer git, perhaps crossmounted, should we backport "git branch -r" so that the user can confortably work with remote tracking branches? Should we backport reflogs? If a distro chooses to support its users whom they force to pin at 1.4.4.X series, it's primarily _their_ choice. I do not mind helping them in such a backport, but the request has to come from the distro first with a specific list of items that need to be supported. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-14 19:00 ` Junio C Hamano @ 2008-07-14 19:19 ` Teemu Likonen 2008-07-15 3:14 ` Martin Langhoff 2008-07-15 9:20 ` Petr Baudis 1 sibling, 1 reply; 371+ messages in thread From: Teemu Likonen @ 2008-07-14 19:19 UTC (permalink / raw) To: Junio C Hamano Cc: Nicolas Pitre, Gerrit Pape, Johannes Schindelin, Petr Baudis, git Junio C Hamano wrote (2008-07-14 12:00 -0700): > Nicolas Pitre <nico@cam.org> writes: > > > On Mon, 14 Jul 2008, Gerrit Pape wrote: > >> > On Mon, 14 Jul 2008, Petr Baudis wrote: > >> > > I'm saying this because I believe the best conservative upper > >> > > bound for backwards compatibility is Git version in Debian > >> > > stable. It gets > > Please consider it as a critical usability problem. > > > > Maybe we can release 1.4.5 with the ability to read index v2? That > > wouldn't be hard to backport the reading part of it. > I am of two minds here. > > On one hand, I am sympathetic to distros that want to give long time > support for ancient versions to keep working in an ever-changing new > world. It is a wonderful thing that there are distros that aim for > ultra conservative stability, and I applaud them. > > But as the upstream, we have our own deprecation schedule. As Debian stable (4.0 "Etch") and its git 1.4.4.4 was mentioned I'd like to point out that git 1.5.6 is available for Etch users from kind-of-semi-official <www.backports.org>. So I guess Debian stable users aren't left completely behind. Git's web page already advertises backports.org version for Etch. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-14 19:19 ` Teemu Likonen @ 2008-07-15 3:14 ` Martin Langhoff 0 siblings, 0 replies; 371+ messages in thread From: Martin Langhoff @ 2008-07-15 3:14 UTC (permalink / raw) To: Teemu Likonen Cc: Junio C Hamano, Nicolas Pitre, Gerrit Pape, Johannes Schindelin, Petr Baudis, git On Tue, Jul 15, 2008 at 7:19 AM, Teemu Likonen <tlikonen@iki.fi> wrote: >> But as the upstream, we have our own deprecation schedule. > > As Debian stable (4.0 "Etch") and its git 1.4.4.4 was mentioned I'd like > to point out that git 1.5.6 is available for Etch users from > kind-of-semi-official <www.backports.org>. So I guess Debian stable > users aren't left completely behind. Git's web page already advertises > backports.org version for Etch. I concur. Users of git on Etch are using backports AFAIK. We still have the case of the "casual" user, who does not know much about git, but installs it to clone & review a project's code. There, if v1.4.4 complains with a useful message, the casual user will swear a bit and grab a backport. If it dies a horrible uninformative death, then we will get bogus bug reports, flamage, the works. cheers, m -- martin.langhoff@gmail.com martin@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-14 19:00 ` Junio C Hamano 2008-07-14 19:19 ` Teemu Likonen @ 2008-07-15 9:20 ` Petr Baudis 2008-07-15 15:06 ` Dmitry Potapov 1 sibling, 1 reply; 371+ messages in thread From: Petr Baudis @ 2008-07-15 9:20 UTC (permalink / raw) To: Junio C Hamano; +Cc: Nicolas Pitre, Gerrit Pape, Johannes Schindelin, git On Mon, Jul 14, 2008 at 12:00:54PM -0700, Junio C Hamano wrote: > But as the upstream, we have our own deprecation schedule. We should of > course plan carefully not to harm existing users of our releases, but > frankly speaking, 18 months since 1.4.4.4 was tagged (early January 2007) > is an eternity in git timescale. Maybe we will slow down someday, and > this 18-month is not a set-in-stone rule in any way, but at this point > even without the packfile format issues, I personally think anything > before 1.5.0 is irrelevant --- maybe they are interesting as historical > curiosities, but not more than that. Really, I think this is should be put into certain perspective: (i) This change is special since it affects client-server compatibility in bare repositories. AFAIK, none of the others you mention does this. (ii) The CRC checking is perhaps quite an improvement, but I don't think it is critical-to-have-just-now. (iii) Most importantly, this is not about waiting another few years for Debian to catch up, since the next stable release should really be upcoming rather soon: http://debian-community.org/LennyReleaseSchedule/ (iv) These problems do not concern people who are currently _actively_ _working_ with Git; these people hopefully do not use 1.4 willingly and already use Git from backports.org. This is about user experience for casual users who are quite possibly interested only in read-only tracking of upstream using Git - these people will likely use default Debian Git version and that is okay, because frankly, for them, the 1.5 improvements do not really matter much. This is also large class of prospective future real Git users and we might not want to ruin Git's reputation in their eyes. -- Petr "Pasky" Baudis GNU, n. An animal of South Africa, which in its domesticated state resembles a horse, a buffalo and a stag. In its wild condition it is something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-15 9:20 ` Petr Baudis @ 2008-07-15 15:06 ` Dmitry Potapov 2008-07-15 15:27 ` Johannes Schindelin 0 siblings, 1 reply; 371+ messages in thread From: Dmitry Potapov @ 2008-07-15 15:06 UTC (permalink / raw) To: Petr Baudis Cc: Junio C Hamano, Nicolas Pitre, Gerrit Pape, Johannes Schindelin, git On Tue, Jul 15, 2008 at 11:20:23AM +0200, Petr Baudis wrote: > > (iii) Most importantly, this is not about waiting another few > years for Debian to catch up, since the next stable release > should really be upcoming rather soon: > > http://debian-community.org/LennyReleaseSchedule/ Even if Lenny will be released right on the scheduler (which I seriously doubt), Etch will be around for another year. In fact, the last release of oldstable (sarge) happened on April 12 this year. Thus delaying of indexversion=2 does not help much here. Anyone who is more or less seriously about using Git grabs it from backports. The downside of delaying is that any incompatible changes are much less welcome by users during minor releases than major ones. People tend to read release notes during major releases more carefully and think whether they prefer new features or backward compatibility. This choice will not be the same for anyone, but changing default settings on the major release is much more appropriate than during minor ones. > > (iv) These problems do not concern people who are currently > _actively_ _working_ with Git; these people hopefully do not > use 1.4 willingly and already use Git from backports.org. > This is about user experience for casual users who are quite > possibly interested only in read-only tracking of upstream > using Git - these people will likely use default Debian Git > version and that is okay, because frankly, for them, the > 1.5 improvements do not really matter much. This is also > large class of prospective future real Git users and we might > not want to ruin Git's reputation in their eyes. I disagree. It is not Git does not support the old format, but it switches on the new one as default on the next major release, which is a sensible thing to do. Those repos that think that access for Git 1.4 users is important for them can set indexformat=1. As to prospective future real Git users, anyone who is trying to use Git 1.4 is going to hit by many usability issues that were resolved in 1.5; and there is no community support for Git 1.4 either -- you can ask about any problem with Git 1.4 on this list, and the only answer you'll get is that you should upgrade your Git. So, there is no way for newcommers to start using Git 1.4 and be satisfied with it. Finally, 18 months since 1.4.4 may not appear as a long time ago for other projects that are being developed for many years, but for Git, which was only 21 months when Git 1.4.4 was released, 18 months is really very *long* time ago. Dmitry ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-15 15:06 ` Dmitry Potapov @ 2008-07-15 15:27 ` Johannes Schindelin 2008-07-15 15:51 ` Avery Pennarun ` (3 more replies) 0 siblings, 4 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-07-15 15:27 UTC (permalink / raw) To: Dmitry Potapov Cc: Petr Baudis, Junio C Hamano, Nicolas Pitre, Gerrit Pape, git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-15 15:27 ` Johannes Schindelin @ 2008-07-15 15:51 ` Avery Pennarun 2008-07-15 16:26 ` Nicolas Pitre ` (2 subsequent siblings) 3 siblings, 0 replies; 371+ messages in thread From: Avery Pennarun @ 2008-07-15 15:51 UTC (permalink / raw) To: Johannes Schindelin Cc: Dmitry Potapov, Petr Baudis, Junio C Hamano, Nicolas Pitre, Gerrit Pape, git On 7/15/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > On Tue, 15 Jul 2008, Dmitry Potapov wrote: > > Those repos that think that access for Git 1.4 users is important for > > them can set indexformat=1. > > Unfortunately, you place quite a high maintenance burden on the repository > maintainers here. > > From the time balance sheet, it does not look good at all: a few minutes > for Junio to change and commit, up to a few hours (because they missed it > in the release notes) for probably more than hundred repository > maintainers that are not subscribed to the Git mailing list. To take this in a slightly different direction, what exactly is the benefit of the new feature? Apparently my git doesn't have it enabled by default, and git works fine for me. Am I missing out on something that I should feel inferior about if my non-debian-etch running friends(*) found out about it? :) Have fun, Avery (*) Actually I compile my own git from source anyway. I never want to live without "git rebase -i" and "git add -p" ever again. Life is too short! :) ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-15 15:27 ` Johannes Schindelin 2008-07-15 15:51 ` Avery Pennarun @ 2008-07-15 16:26 ` Nicolas Pitre 2008-07-15 16:46 ` Sverre Rabbelier 2008-07-15 17:28 ` Petr Baudis 2008-07-15 17:04 ` Dmitry Potapov 2008-07-15 18:51 ` Junio C Hamano 3 siblings, 2 replies; 371+ messages in thread From: Nicolas Pitre @ 2008-07-15 16:26 UTC (permalink / raw) To: Johannes Schindelin Cc: Dmitry Potapov, Petr Baudis, Junio C Hamano, Gerrit Pape, git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-15 16:26 ` Nicolas Pitre @ 2008-07-15 16:46 ` Sverre Rabbelier 2008-07-15 17:28 ` Petr Baudis 1 sibling, 0 replies; 371+ messages in thread From: Sverre Rabbelier @ 2008-07-15 16:46 UTC (permalink / raw) To: Nicolas Pitre Cc: Johannes Schindelin, Dmitry Potapov, Petr Baudis, Junio C Hamano, Gerrit Pape, git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-15 16:26 ` Nicolas Pitre 2008-07-15 16:46 ` Sverre Rabbelier @ 2008-07-15 17:28 ` Petr Baudis 1 sibling, 0 replies; 371+ messages in thread From: Petr Baudis @ 2008-07-15 17:28 UTC (permalink / raw) To: Nicolas Pitre Cc: Johannes Schindelin, Dmitry Potapov, Junio C Hamano, Gerrit Pape, git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-15 15:27 ` Johannes Schindelin 2008-07-15 15:51 ` Avery Pennarun 2008-07-15 16:26 ` Nicolas Pitre @ 2008-07-15 17:04 ` Dmitry Potapov 2008-07-15 18:51 ` Junio C Hamano 3 siblings, 0 replies; 371+ messages in thread From: Dmitry Potapov @ 2008-07-15 17:04 UTC (permalink / raw) To: Johannes Schindelin Cc: Petr Baudis, Junio C Hamano, Nicolas Pitre, Gerrit Pape, git On Tue, Jul 15, 2008 at 04:27:02PM +0100, Johannes Schindelin wrote: > > >From the time balance sheet, it does not look good at all: a few minutes > for Junio to change and commit, up to a few hours (because they missed it > in the release notes) for probably more than hundred repository > maintainers that are not subscribed to the Git mailing list. If you just grab sources and never read release notes, there is nothing that can help you. If Git 1.6.0 is not the right moment to do these changes then Git 1.6.1 is neither, regardless whether Debian will release Lenny by that time or not. People do not upgrade their distro in the day of release. Some upgraded to Etch not so long ago. So, should we wait for another year till 1.7.0? > > And I absolutely agree with Pasky that this does _nothing_ in the vague > direction of wielding a reputation of being easy to use. I don't think Git 1.4 is easy to use. If you want Git that is easy to use install Git 1.5.x. And, it is *much* easier to install Git from backports then to deal with usability issues of Git 1.4 and the lack of community support. So, I don't see how this change may hurt. > > Sure, we can make it easy on ourselves. And it is just as easy to make it > hard on others. If you're okay with that, I am not. It has *nothing* to do with making easy on ourselves and hard on others. The question here is what is the appropriate time to change these default settings, and I believe that *major* releases are the appropriate time while minor ones are not. Dmitry ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-15 15:27 ` Johannes Schindelin ` (2 preceding siblings ...) 2008-07-15 17:04 ` Dmitry Potapov @ 2008-07-15 18:51 ` Junio C Hamano 2008-07-15 22:10 ` Johannes Schindelin 3 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-15 18:51 UTC (permalink / raw) To: Johannes Schindelin Cc: Dmitry Potapov, Petr Baudis, Nicolas Pitre, Gerrit Pape, git Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > On Tue, 15 Jul 2008, Dmitry Potapov wrote: > >> Those repos that think that access for Git 1.4 users is important for >> them can set indexformat=1. > > Unfortunately, you place quite a high maintenance burden on the repository > maintainers here. > > From the time balance sheet, it does not look good at all: a few minutes > for Junio to change and commit, up to a few hours (because they missed it > in the release notes) for probably more than hundred repository > maintainers that are not subscribed to the Git mailing list. > > And I absolutely agree with Pasky that this does _nothing_ in the vague > direction of wielding a reputation of being easy to use. > > Sure, we can make it easy on ourselves. And it is just as easy to make it > hard on others. If you're okay with that, I am not. I was not planning to comment on this issue further as the ball is in Debian's court, but I think you are misguided. We are not making anything hard on others. Sticking to 1.4.4.4 codebase is forced by Debian (for its policy) and choice made by its users (for not knowing or using backports). 1.5.0 and later are vastly better and we encourage users to update on every occassion we get. I do not know the extent of the backporting effort necessary, the size of potentially impacted population if Debian keeps shipping unpatched 1.4.4.4, nor how much Debian cares about supporting their 1.4.4.4 users i.e. if they are willing and able to carry distro-only forward compatibility patches, and knowing all of these is necessary before we declare this is worth handling _ourselves_. That is why I did not want to take a definitive stance on this issue before hearing from the Debian maintainer about them -- I said "Debian has to ask with list of items", didn't I? What troubles me the most is that you seem to be forgetting that we are using git to manage our codebase. Even if this turns out to be something we would want to handle ourselves, it does not have to come from me. If you care that much, you could backport whatever change is appropriate to keep 1.4.4.X codebase alive and arrange it to be published as 1.4.4.5. In any case, it will _definitely_ *NOT* a few minutes of me nor anybody. Release engineering takes quite a lot of time. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-15 18:51 ` Junio C Hamano @ 2008-07-15 22:10 ` Johannes Schindelin 2008-07-15 22:33 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Johannes Schindelin @ 2008-07-15 22:10 UTC (permalink / raw) To: Junio C Hamano Cc: Dmitry Potapov, Petr Baudis, Nicolas Pitre, Gerrit Pape, git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-15 22:10 ` Johannes Schindelin @ 2008-07-15 22:33 ` Junio C Hamano 2008-07-15 22:45 ` Johannes Schindelin 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-15 22:33 UTC (permalink / raw) To: Johannes Schindelin Cc: Dmitry Potapov, Petr Baudis, Nicolas Pitre, Gerrit Pape, git Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > On Tue, 15 Jul 2008, Junio C Hamano wrote: > >> What troubles me the most is that you seem to be forgetting that we are >> using git to manage our codebase. > > I don't. I have vivid memories of updating an ancient git repository of > Git itself, which had some almost forgotten changes in it. That was in > the bad old days, when the version number did not even have a "1" in it. > > It could not even fetch the current git.git. > > I do _not_ want that to happen to anybody else, _even if_ we leave 1.4.4.4 > Behind as if it was an American Child. My reference to "git" was about "forking is easy". We seem to have to agree that talking is even cheaper, though ;-) > Having said that, I do not have the resources to test and fix everything > that may arise from Debian being seemingly unable to update to Git 1.5. Heh, what happent to your earlier "a few minutes for Junio to change and commit"? ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-15 22:33 ` Junio C Hamano @ 2008-07-15 22:45 ` Johannes Schindelin 0 siblings, 0 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-07-15 22:45 UTC (permalink / raw) To: Junio C Hamano Cc: Dmitry Potapov, Petr Baudis, Nicolas Pitre, Gerrit Pape, git Hi, On Tue, 15 Jul 2008, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > Having said that, I do not have the resources to test and fix > > everything that may arise from Debian being seemingly unable to update > > to Git 1.5. > > Heh, what happent to your earlier "a few minutes for Junio to change and > commit"? That was meant for the integration of the patch that makes the backwards-incompatible patch. Not for the necessary forward-compatible changes. Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-14 17:54 ` Nicolas Pitre 2008-07-14 19:00 ` Junio C Hamano @ 2008-07-15 2:51 ` Shawn O. Pearce 2008-07-15 3:30 ` Nicolas Pitre 1 sibling, 1 reply; 371+ messages in thread From: Shawn O. Pearce @ 2008-07-15 2:51 UTC (permalink / raw) To: Nicolas Pitre Cc: Gerrit Pape, Johannes Schindelin, Petr Baudis, Junio C Hamano, git Nicolas Pitre <nico@cam.org> wrote: > On Mon, 14 Jul 2008, Gerrit Pape wrote: > > > On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote: > > > On Mon, 14 Jul 2008, Petr Baudis wrote: > > > > I'm saying this because I believe the best conservative upper bound for > > > > backwards compatibility is Git version in Debian stable. It gets > > > > probably the most stale from all the widely used software distributions > > > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which > > > > fails miserably on the new packs. > > Maybe we can release 1.4.5 with the ability to read index v2? That > wouldn't be hard to backport the reading part of it. If we consider that supporting 1.4.4.4 clients is still a priority, due to the widespread distribution of that version in a popular version of Debian, we shouldn't be rushing the index v2 or OFS_DELTA functionality on by default in 1.6.0. Instead we would wait until Debian stable (and most other widely popular distributions) are on a modern enough version of Git to understand this format. Really. As much as I'd love to see the switch to v2 made by default I don't think we can/should do it unless the majority of the user base will be able to grok it. And Debian etch sounds like it won't. -- Shawn. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-15 2:51 ` Shawn O. Pearce @ 2008-07-15 3:30 ` Nicolas Pitre 0 siblings, 0 replies; 371+ messages in thread From: Nicolas Pitre @ 2008-07-15 3:30 UTC (permalink / raw) To: Shawn O. Pearce Cc: Gerrit Pape, Johannes Schindelin, Petr Baudis, Junio C Hamano, git On Tue, 15 Jul 2008, Shawn O. Pearce wrote: > Nicolas Pitre <nico@cam.org> wrote: > > On Mon, 14 Jul 2008, Gerrit Pape wrote: > > > > > On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote: > > > > On Mon, 14 Jul 2008, Petr Baudis wrote: > > > > > I'm saying this because I believe the best conservative upper bound for > > > > > backwards compatibility is Git version in Debian stable. It gets > > > > > probably the most stale from all the widely used software distributions > > > > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which > > > > > fails miserably on the new packs. > > > > Maybe we can release 1.4.5 with the ability to read index v2? That > > wouldn't be hard to backport the reading part of it. > > If we consider that supporting 1.4.4.4 clients is still a priority, > due to the widespread distribution of that version in a popular > version of Debian, we shouldn't be rushing the index v2 or OFS_DELTA > functionality on by default in 1.6.0. OFS_DELTA is supported by 1.4.4.4 so that's a non issue. > Instead we would wait until Debian stable (and most other widely > popular distributions) are on a modern enough version of Git to > understand this format. I don't think we should have git development be dictated by some discutable policy from one distribution. IMHO git prior 1.5.0 is so horrible as general usability goes, and so different from what everybody is discussing on the net, that no one sane should still be using it. Even ourselves (i.e. the git community) are not supporting git 1.4.4 anymore so this hardly can be a priority. As far as I know, there is no other widely popular distribution other than Debian using git prior 1.5.0 in their latest release. If Debian people want to support git 1.4.4 although we called thatversion obsolete _long_ ago then that's their problem. We should not be bound by that external policy to which we never agreed with. Now I proposed a compromise which consists of making 1.4.4.4+1 able to cope with index v2. That should fall into Debian's "major usability fix" category. I think that is a far better compromize than delaying index v2 even further. > Really. As much as I'd love to see the switch to v2 made by default > I don't think we can/should do it unless the majority of the user > base will be able to grok it. And Debian etch sounds like it won't. I truly hope the majority of the user is _not_ using 1.4.4.4. Otherwise I may only have pity for them. Nicolas ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-14 11:57 ` Johannes Schindelin 2008-07-14 12:41 ` Gerrit Pape @ 2008-07-14 12:43 ` Petr Baudis 2008-07-20 2:23 ` Nick Andrew 1 sibling, 1 reply; 371+ messages in thread From: Petr Baudis @ 2008-07-14 12:43 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, git Hi, On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote: > On Mon, 14 Jul 2008, Petr Baudis wrote: > > > I'm saying this because I believe the best conservative upper bound for > > backwards compatibility is Git version in Debian stable. It gets > > probably the most stale from all the widely used software distributions > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which > > fails miserably on the new packs. > > Can't we just hit Debian's Git maintainer with a clue bat or a bus, > whichever is easier, and force them to upgrade _in_ Etch? It's not like > we haven't had _several_ stable releases in-between. the whole point of having a stable distribution is that random version upgrades don't happen under your hands; sure, 1.4.4.4 can have plenty of bugs, but it's buggy in a well-defined way, which is better than upgrade to newer stable version, which may be less buggy, but in a different way; also, by upgrading to newer version you might find various subtle compatibility issues, etc. Upgrading to newer version, *especially* if it's over then 1.4 - 1.5 boundary, is not something you could seriously expect Debian to do. At least I actually _hope_ so, as a sysadmin of a network of 40 etch workstations. -- Petr "Pasky" Baudis GNU, n. An animal of South Africa, which in its domesticated state resembles a horse, a buffalo and a stag. In its wild condition it is something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-14 12:43 ` Petr Baudis @ 2008-07-20 2:23 ` Nick Andrew 0 siblings, 0 replies; 371+ messages in thread From: Nick Andrew @ 2008-07-20 2:23 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-14 8:55 ` Petr Baudis 2008-07-14 11:57 ` Johannes Schindelin @ 2008-07-14 19:16 ` Junio C Hamano 2008-07-15 9:09 ` Petr Baudis 1 sibling, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-14 19:16 UTC (permalink / raw) To: Petr Baudis; +Cc: git Petr Baudis <pasky@suse.cz> writes: > Getting alternates list for http://repo.or.cz/r/repo.git/ > Getting pack list for http://repo.or.cz/r/repo.git/ > Getting index for pack 5111285cac0f895cd9367c9939ced68e2c43dcc0 > error: non-monotonic index > /usr/bin/git-fetch: line 297: 30402 Segmentation fault git-http-fetch -v -a "$head" "$remote/" Yeah, I think git-repack, git-gc, git-pack-objects and git-index-pack on the server side need a knob to tell it to stay conservative because the repository may be served over dumb protocols to avoid this problem. That knob could even be called [repack] usedeltabaseoffset = false [pack] indexversion = 1 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: Closing the merge window for 1.6.0 2008-07-14 19:16 ` Junio C Hamano @ 2008-07-15 9:09 ` Petr Baudis 0 siblings, 0 replies; 371+ messages in thread From: Petr Baudis @ 2008-07-15 9:09 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Mon, Jul 14, 2008 at 12:16:26PM -0700, Junio C Hamano wrote: > Yeah, I think git-repack, git-gc, git-pack-objects and git-index-pack on > the server side need a knob to tell it to stay conservative because the > repository may be served over dumb protocols to avoid this problem. > > That knob could even be called > > [repack] > usedeltabaseoffset = false > [pack] > indexversion = 1 Can you please mention this in release notes? Until now, I actually thought you're speaking about a hypothetical improvement, not a knob we actually have. :-) (BTW, turning off the usedeltabaseoffset is not critical at least Debian-wise, and I think that really is the oldest Git in widespread use.) Now, there is of course still the issue of default behaviour, but at least my concern is somewhat eased now. :-) -- Petr "Pasky" Baudis GNU, n. An animal of South Africa, which in its domesticated state resembles a horse, a buffalo and a stag. In its wild condition it is something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-14 5:11 ` Junio C Hamano 2008-07-14 6:45 ` Junio C Hamano 2008-07-14 7:50 ` Closing the merge window for 1.6.0 Junio C Hamano @ 2008-07-14 11:53 ` Johannes Schindelin 2008-07-14 23:12 ` Lea Wiemann ` (2 subsequent siblings) 5 siblings, 0 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-07-14 11:53 UTC (permalink / raw) To: Junio C Hamano; +Cc: git Hi, On Sun, 13 Jul 2008, Junio C Hamano wrote: > * js/more-win (Sun Jul 13 22:31:23 2008 +0200) 6 commits > - Allow add_path() to add non-existent directories to the path > - Allow the built-in exec path to be relative to the command > invocation path > - Fix relative built-in paths to be relative to the command > invocation > + help (Windows): Display HTML in default browser using Windows' > shell API > + help.c: Add support for htmldir relative to git_exec_path() > + Move code interpreting path relative to exec-dir to new function > system_path() > > The earlier parts are obvious; Dscho seemed to have some comments on the > later ones that are in 'pu'. Just one, and it seems that the next patch patched that ;-) Not really a showstopper. > * mv/merge-in-c (Sun Jul 13 08:13:55 2008 +0000) 19 commits > + reduce_heads(): thinkofix Hmm. My earlier response to Sverre was based on an old "next", it seems. Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-14 5:11 ` Junio C Hamano ` (2 preceding siblings ...) 2008-07-14 11:53 ` What's cooking in git.git (topics) Johannes Schindelin @ 2008-07-14 23:12 ` Lea Wiemann 2008-07-14 23:20 ` Lea Wiemann 2008-07-15 3:38 ` Geoffrey Irving 2008-07-16 3:33 ` Junio C Hamano 5 siblings, 1 reply; 371+ messages in thread From: Lea Wiemann @ 2008-07-14 23:12 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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). ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-14 23:12 ` Lea Wiemann @ 2008-07-14 23:20 ` Lea Wiemann 2008-07-15 0:03 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Lea Wiemann @ 2008-07-14 23:20 UTC (permalink / raw) To: Lea Wiemann; +Cc: Junio C Hamano, git 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? ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-14 23:20 ` Lea Wiemann @ 2008-07-15 0:03 ` Junio C Hamano 0 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-15 0:03 UTC (permalink / raw) To: Lea Wiemann; +Cc: git Lea Wiemann <lewiemann@gmail.com> writes: > Lea Wiemann wrote: >> It'll be fixed in the next version I post > > By the way Junio, how do you prefer to get reposts of patch sequences? > Should I repost the whole sequence under a new common parent message, or > can I simply post v2 of each patch in the sequence as a followup to its > respective v1? I do not have major preference either way, but for a long series, I'd prefer a resend to be independent from the previous series, i.e. [PATCH 0/3] .[PATCH 1/3] ..[PATCH 2/3] ...[PATCH 3/3] [PATCH 0/4 v2] .[PATCH 1/4 v2] ..[PATCH 2/4 v2] ...[PATCH 3/4 v2] ....[PATCH 4/4 v2] I can live with the first one from the new series being a follow-up to the first one from the old series, i.e.: [PATCH 0/3] .[PATCH 1/3] ..[PATCH 2/3] ...[PATCH 3/3] .[PATCH 0/4 v2] ..[PATCH 1/4 v2] ...[PATCH 2/4 v2] ....[PATCH 3/4 v2] .....[PATCH 4/4 v2] but _not_ with this, i.e. N/M being followup to old N/M: [PATCH 0/3] .[PATCH 0/4 v2] .[PATCH 1/3] ..[PATCH 1/4 v2] ..[PATCH 2/3] ...[PATCH 2/4 v2] ...[PATCH 3/3] ....[PATCH 3/4 v2] .....[PATCH 4/4 v2] ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-14 5:11 ` Junio C Hamano ` (3 preceding siblings ...) 2008-07-14 23:12 ` Lea Wiemann @ 2008-07-15 3:38 ` Geoffrey Irving 2008-07-15 9:22 ` Johannes Schindelin 2008-07-16 3:33 ` Junio C Hamano 5 siblings, 1 reply; 371+ messages in thread From: Geoffrey Irving @ 2008-07-15 3:38 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, Johannes Schindelin On Sun, Jul 13, 2008 at 10:11 PM, Junio C Hamano <gitster@pobox.com> wrote: > Here are the topics that have been cooking. Commits prefixed > with '-' are only in 'pu' while commits prefixed with '+' are > in 'next'. > > <snip> > > * gi/cherry-cache (Sat Jul 12 20:14:51 2008 -0700) 1 commit > - cherry: cache patch-ids to avoid repeating work > > This does not seem to pass tests even on its own. The problem (beyond the basic problem of me not having tried running the tests) is that the current caching code isn't taking into account the changing values of diff_options. t6007 computes a patch-id for a commit with one value of options.paths, and then tries to compute a _different_ patch-id for the same commit using a different value of options.paths. Here are a few different ways of fixing this: 1. Modify commit_patch_id in patch-ids.c to compute a sha1 of the diff_options structure and xor it with the commit sha1 to get a truly unique hash of the input. This means the optimization can be safely applied for all patch-id computations regardless of the diff_options. I can add a diff_options_sha1 function in diff.[ch] to compute the checksum. 2. Restrict commit_patch_id in patch-ids.c to apply the optimization only if options.nr_paths is zero, and perhaps a few other conditions. This is rather fragile, since it would mean that the cache would break if someone decided to change the default diff options. 3. Add a flag in struct patch_ids defaulting to false which turns the caching on or off, and manually set the flag to true in cmd_cherry. I'd lean towards (1), but wanted to check before writing the code to make sure that it's reasonable to treat diff_options as stable enough that computing a sha1 hash of it makes sense. According to "git help patch-id", it is only "reasonable stable", which is sufficient as long as we're confident that whenever the diff format changes, the diff_options_sha1 function will be updated to reflect that change. As an aside: is it correct that as long as the change is in pu, I should be submitting complete (nonincremental) patches whenever I fix bugs? Thanks, Geoffrey ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-15 3:38 ` Geoffrey Irving @ 2008-07-15 9:22 ` Johannes Schindelin 2008-07-15 16:48 ` Geoffrey Irving 0 siblings, 1 reply; 371+ messages in thread From: Johannes Schindelin @ 2008-07-15 9:22 UTC (permalink / raw) To: Geoffrey Irving; +Cc: Junio C Hamano, git Hi, On Mon, 14 Jul 2008, Geoffrey Irving wrote: > The problem (beyond the basic problem of me not having tried running the > tests) is that the current caching code isn't taking into account the > changing values of diff_options. t6007 computes a patch-id for a commit > with one value of options.paths, and then tries to compute a _different_ > patch-id for the same commit using a different value of options.paths. > > Here are a few different ways of fixing this: > > 1. Modify commit_patch_id in patch-ids.c to compute a sha1 of the > diff_options structure and xor it with the commit sha1 to get a truly > unique hash of the input. This means the optimization can be safely > applied for all patch-id computations regardless of the diff_options. > I can add a diff_options_sha1 function in diff.[ch] to compute the > checksum. > > 2. Restrict commit_patch_id in patch-ids.c to apply the optimization > only if options.nr_paths is zero, and perhaps a few other conditions. > This is rather fragile, since it would mean that the cache would > break if someone decided to change the default diff options. Funnily, (2) contradicts (1). The patch id is _different_ when you have nr_paths > 0. At least in the general case. So what you propose in (1) will not work, unless you also hash the path names (in the correct order, otherwise you'll end up with two hashes). OTOH I would be really surprised if you needed --cherry-pick with paths and/or diff options more than once for the same commits. So the caching does not make sense to begin with (especially since we do not have a proper way of gc'ing it, right?). So I'd suggest saving diff_opts before the command line parsing, and disable the cache when it is different _and/or_ (||) nr_paths. Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-15 9:22 ` Johannes Schindelin @ 2008-07-15 16:48 ` Geoffrey Irving 0 siblings, 0 replies; 371+ messages in thread From: Geoffrey Irving @ 2008-07-15 16:48 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, git On Tue, Jul 15, 2008 at 2:22 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > Hi, > > On Mon, 14 Jul 2008, Geoffrey Irving wrote: > >> The problem (beyond the basic problem of me not having tried running the >> tests) is that the current caching code isn't taking into account the >> changing values of diff_options. t6007 computes a patch-id for a commit >> with one value of options.paths, and then tries to compute a _different_ >> patch-id for the same commit using a different value of options.paths. >> >> Here are a few different ways of fixing this: >> >> 1. Modify commit_patch_id in patch-ids.c to compute a sha1 of the >> diff_options structure and xor it with the commit sha1 to get a truly >> unique hash of the input. This means the optimization can be safely >> applied for all patch-id computations regardless of the diff_options. >> I can add a diff_options_sha1 function in diff.[ch] to compute the >> checksum. >> >> 2. Restrict commit_patch_id in patch-ids.c to apply the optimization >> only if options.nr_paths is zero, and perhaps a few other conditions. >> This is rather fragile, since it would mean that the cache would >> break if someone decided to change the default diff options. > > Funnily, (2) contradicts (1). The patch id is _different_ when you have > nr_paths > 0. At least in the general case. > > So what you propose in (1) will not work, unless you also hash the path > names (in the correct order, otherwise you'll end up with two hashes). The sha1 would include paths, of course, since it's part of diff_options. > OTOH I would be really surprised if you needed --cherry-pick with paths > and/or diff options more than once for the same commits. So the caching > does not make sense to begin with (especially since we do not have a > proper way of gc'ing it, right?). > > So I'd suggest saving diff_opts before the command line parsing, and > disable the cache when it is different _and/or_ (||) nr_paths. I'll attach the patch to the other thread. Geoffrey ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-07-14 5:11 ` Junio C Hamano ` (4 preceding siblings ...) 2008-07-15 3:38 ` Geoffrey Irving @ 2008-07-16 3:33 ` Junio C Hamano 2008-07-17 8:08 ` Junio C Hamano 5 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-16 3:33 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-07-16 3:33 ` Junio C Hamano @ 2008-07-17 8:08 ` Junio C Hamano 2008-07-17 13:09 ` Stephan Beyer ` (2 more replies) 0 siblings, 3 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-17 8:08 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-17 8:08 ` Junio C Hamano @ 2008-07-17 13:09 ` Stephan Beyer 2008-07-18 8:50 ` Nanako Shiraishi 2008-07-20 1:58 ` Junio C Hamano 2 siblings, 0 replies; 371+ messages in thread From: Stephan Beyer @ 2008-07-17 13:09 UTC (permalink / raw) To: Junio C Hamano; +Cc: git Hi, Junio C Hamano wrote: > * sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits > . Migrate git-am to use git-sequencer > . Add git-sequencer test suite (t3350) > . Add git-sequencer prototype documentation > . Add git-sequencer shell prototype > > I haven't looked at the updated series yet. I should, but nobody else > seems to be looking at these patches, which is somewhat depressing but > understandable. Summer is slower ;-) imho there is no need to hurry, but if I can help, just tell me how. Regards. -- Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-17 8:08 ` Junio C Hamano 2008-07-17 13:09 ` Stephan Beyer @ 2008-07-18 8:50 ` Nanako Shiraishi 2008-07-18 9:08 ` Junio C Hamano ` (3 more replies) 2008-07-20 1:58 ` Junio C Hamano 2 siblings, 4 replies; 371+ messages in thread From: Nanako Shiraishi @ 2008-07-18 8:50 UTC (permalink / raw) To: Junio C Hamano; +Cc: git Quoting Junio C Hamano <gitster@pobox.com>: > * xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits > + Teach git-merge -X<option> again. > + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next > + builtin-merge.c: use parse_options_step() "incremental parsing" > machinery > + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next > > This needs to be merged to master iff/when merge-theirs gets merged, > but I do not think this series is widely supported, so both are on hold. Why do you say it is not widely supported? I may be wrong but I think you developed these patches after somebody from the mailing list asked for this feature. You may find out people are enthusiastic about this only after you merge it to your master branch. -- Nanako Shiraishi http://ivory.ap.teacup.com/nanako3/ ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-18 8:50 ` Nanako Shiraishi @ 2008-07-18 9:08 ` Junio C Hamano 2008-07-18 9:20 ` Nanako Shiraishi ` (2 subsequent siblings) 3 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-18 9:08 UTC (permalink / raw) To: Nanako Shiraishi; +Cc: git Nanako Shiraishi <nanako3@lavabit.com> writes: > Quoting Junio C Hamano <gitster@pobox.com>: > >> * xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits >> + Teach git-merge -X<option> again. >> + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next >> + builtin-merge.c: use parse_options_step() "incremental parsing" >> machinery >> + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next >> >> This needs to be merged to master iff/when merge-theirs gets merged, >> but I do not think this series is widely supported, so both are on hold. > > Why do you say it is not widely supported? I may be wrong but I think > you developed these patches after somebody from the mailing list asked > for this feature. Well, for one thing, I do not believe in their cause. As I wrote in the log messages for these commits (actually not these above which is a series for merge fixup, but the other topic), I do not think it is a sensible thing to say "let's take as much automerge results as possible to salvage our changes where they do not overlap with what the upstream did, but I would give up our changes to places that the upstream also touched, because I do not understand what they did well enough to be able to resolve the merge conflicts correctly", and "merge -Xtheirs" is exactly that. That also was the reason I did not add any documentation to it. But I do like the change to the infrastructure to allow passing strategy-specific options through git-merge and git-pull. Perhaps I should write something up, if only to salvage that -X<option> part, even though I am very much inclined to discard -Xtheirs (and -Xours) part. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-18 8:50 ` Nanako Shiraishi 2008-07-18 9:08 ` Junio C Hamano @ 2008-07-18 9:20 ` Nanako Shiraishi 2008-07-18 9:43 ` Junio C Hamano 2008-07-18 9:44 ` Petr Baudis 2008-07-18 11:56 ` Johannes Schindelin 2008-07-20 10:20 ` Nanako Shiraishi 3 siblings, 2 replies; 371+ messages in thread From: Nanako Shiraishi @ 2008-07-18 9:20 UTC (permalink / raw) To: Junio C Hamano; +Cc: git Quoting Junio C Hamano <gitster@pobox.com>: > Well, for one thing, I do not believe in their cause. As I wrote in the > log messages for these commits (actually not these above which is a series > for merge fixup, but the other topic), I do not think it is a sensible > thing to say "let's take as much automerge results as possible to salvage > our changes where they do not overlap with what the upstream did, but I > would give up our changes to places that the upstream also touched, > because I do not understand what they did well enough to be able to > resolve the merge conflicts correctly", and "merge -Xtheirs" is exactly > that. I do not know if "I do not understand what they did well enough" is the only reason people would want to use that feature. Isn't it better to let people decide that for themselves? > That also was the reason I did not add any documentation to it. But I do > like the change to the infrastructure to allow passing strategy-specific > options through git-merge and git-pull. Perhaps I should write something > up, if only to salvage that -X<option> part, even though I am very much > inclined to discard -Xtheirs (and -Xours) part. I think such a documentation will help people to decide if 'theirs' option makes sense for their workflow. -- Nanako Shiraishi http://ivory.ap.teacup.com/nanako3/ ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-18 9:20 ` Nanako Shiraishi @ 2008-07-18 9:43 ` Junio C Hamano 2008-07-18 11:55 ` Johannes Schindelin 2008-07-18 9:44 ` Petr Baudis 1 sibling, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-18 9:43 UTC (permalink / raw) To: Nanako Shiraishi; +Cc: git Nanako Shiraishi <nanako3@lavabit.com> writes: > Quoting Junio C Hamano <gitster@pobox.com>: > >> ... I do not think it is a sensible >> thing to say "let's take as much automerge results as possible to salvage >> our changes where they do not overlap with what the upstream did, but I >> would give up our changes to places that the upstream also touched, >> because I do not understand what they did well enough to be able to >> resolve the merge conflicts correctly", and "merge -Xtheirs" is exactly >> that. > > I do not know if "I do not understand what they did well enough" is the > only reason people would want to use that feature. Isn't it better to > let people decide that for themselves? We have been saying that we will give long enough rope to people, but at the same time I believe there are things that the world is better without, and a feature that would only encourage a bad workflow is one of them. The way I try to tell such a (mis)feature from a feature that can be useful to people other than myself is to ask people why they would want such a feature and what their response to possible downsides of such a feature. Don't get me wrong. Choice is good, and it is also good that some people may choose differently from me. After all, we are different people with different workflows. But they should be able to explain the reason why they choose something clearly, at least well enough to convince themselves to choose it. If they can't come up with a rational explanation, it becomes an irrational "because I want to" (and "because I can, now that you have already coded it"). That leads to feeping creaturism and a bad feature that the world is better without. I haven't heard an explanation other than the one I said above, and I do not think that explanation is rational. Side note. Even though I invented rerere and it turned out to be a great ti[mp]esaver, I do want to validate the reused resolution makes sense in the new context every time rerere does its job. Recently Ingo wanted the auto resolution to be staged automatically, and rerere.autoupdate was born. I was initially very much against it, but his description of the workflow where it would be useful was convincing enough. This "convincing" does not have to be "Yeah, it's useful to me as well; thanks for explaining it to me". Even though my workflow might never be helped with such a feature, I can see that the different workflow he presented would be useful to people other than myself, and I could agree that the new feature would help such a workflow. This was a good example of "choosing something I initially thought would be detrimental with a good reason, and with a good explanation making me realize that my initial thought was too narrow". > I think such a documentation will help people to decide if 'theirs' > option makes sense for their workflow. So here it is. -- >8 -- [PATCH] Document that merge strategies can now take their own options Also document the recently added -Xtheirs, -Xours and -Xsubtree[=path] options to the merge-recursive strategy. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- Documentation/merge-options.txt | 4 ++++ Documentation/merge-strategies.txt | 26 ++++++++++++++++++++++++++ 2 files changed, 30 insertions(+), 0 deletions(-) diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt index ffbc6e9..96aec48 100644 --- a/Documentation/merge-options.txt +++ b/Documentation/merge-options.txt @@ -58,3 +58,7 @@ If there is no `-s` option, a built-in list of strategies is used instead (`git-merge-recursive` when merging a single head, `git-merge-octopus` otherwise). + +-X<option>:: + Pass merge strategy specific option through to the merge + strategy. diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt index 1276f85..39ff0a8 100644 --- a/Documentation/merge-strategies.txt +++ b/Documentation/merge-strategies.txt @@ -1,6 +1,11 @@ MERGE STRATEGIES ---------------- +The merge mechanism ('git-merge' and 'git-pull' commands) allows the +backend 'merge strategies' to be chosen with `-s` option. Some strategies +can also take their own options, which can be passed by giving `-X<option>` +arguments to 'git-merge' and/or 'git-pull'. + resolve:: This can only resolve two heads (i.e. the current branch and another branch you pulled from) using 3-way merge @@ -20,6 +25,27 @@ recursive:: Additionally this can detect and handle merges involving renames. This is the default merge strategy when pulling or merging one branch. ++ +The 'recursive' strategy can take the following options: + +ours;; + This option forces conflicting hunks to be auto-resolved cleanly by + favoring 'our' version. Changes from the other tree that do not + conflict with our side are reflected to the merge result. ++ +This should not be confused with the 'ours' merge strategy, which does not +even look at what the other tree contains at all. IOW, it discards everything +the other tree did, declaring 'our' history contains all that happened in it. + +theirs;; + This is opposite of 'ours'. + +subtree[=path];; + This option is a more advanced form of 'subtree' strategy, where + the strategy makes a guess on how two trees must be shifted to + match with each other when merging. Instead, the specified path + is prefixed (or stripped from the beginning) to make the shape of + two trees to match. octopus:: This resolves more than two-head case, but refuses to do -- 1.5.6.3.573.gd2d2 ^ permalink raw reply related [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-18 9:43 ` Junio C Hamano @ 2008-07-18 11:55 ` Johannes Schindelin 2008-07-19 5:32 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Johannes Schindelin @ 2008-07-18 11:55 UTC (permalink / raw) To: Junio C Hamano; +Cc: Nanako Shiraishi, git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-18 11:55 ` Johannes Schindelin @ 2008-07-19 5:32 ` Junio C Hamano 2008-07-19 11:19 ` Johannes Schindelin 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-19 5:32 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Nanako Shiraishi, git Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > On Fri, 18 Jul 2008, Junio C Hamano wrote: > >> +The 'recursive' strategy can take the following options: >> + >> +ours;; > > You still have not addressed the issue that you can specify multiple > strategies,... Even though multiple -s parameters are supported, I know you have been here long enough in git scene to remember how it came about. I've seen some third-party documents that talk about our ability to "try multiple strategies and pick the best one" as one of the unique features, but anybody who was there knows that it was just a failed experiment that we did not bother removing. The thing is, trying multiple strategies was a cute idea and it was quite straightforward to implement. But picking the best one is the much more important part, and judging whose result is the best shouldn't be done with just a naïve "how many conflicting paths remain there?" metric (c.f. $gmane/87297 which talks about "stupid" but the argument is exactly the same --- smaller number of conflicts may not necessarily be the easiest to resolve nor the right resolution). I would be surprised if anybody uses multiple -s options in their daily workflow, even though I would not be surprised if people tried to use it just as an experiment and for its entertainment value once or maybe twice. After all, I invented the multiple strategy support for amusement, not from any practical real world needs ;-) So I do not consider that a convincing argument at all. > ... or even a single _wrong_ one. So: > > $ git merge -s stupid -Xours > > would not fail at all, but definitely not do the right thing either (it > disobeys a direct command of the user). It does fail gracefully, though. $ git merge -s resolve -Xours next Trying really trivial in-index merge... error: Untracked working tree file '.gitattributes' would be overwritten by merge. Nope. fatal: Not a valid object name --ours Merge with strategy resolve failed. I consider this falls into "You say it hurts? Don't do that, then" category. The error message will naturally improve, once we teach the merge strategy backends that they can be given --<option> in front of the usual <base>... -- <ents>... parameters, and there is no risk of ambiguity because no object names begin with a dash. Having said all that, I do not have any reason to push for -Xours/theirs myself. I've made myself very clear from the beginning that what these options do is a bad idea, just as "-s theirs" is a bad idea. These encourage a broken workflow and I do not see a clear upside, however narrow, and you and Pasky seem to agree with me (heh, isn't it a rare occasion that all three of us agree on something these days? ;-) I won't shed tears to see them go. However, I do think it is wrong to deny that it will eventually be necessary for us to be able to pass strategy specific options via the git-merge frontend driver to the strategy backend. The primary reason why I wrote "subtree" strategy to _guess_ how to shift trees was because there was no way to pass "how the end user wants to shift them" to the strategy backend over "pull -- merge -- merge-subtree" callchain. Coming up with the algorithm was fun, but that was secondary. If we allow users to say -Xsubtree=<path>, it would be a true improvement to a tool that is used in real life. Unlike "multiple -s strategy" support that I think nobody ever uses in practice (on which part of your objection is based), "-s subtree" has been useful in real life, and you can verify that claim easily by counting how many times I've used that in git.git history yourself. Even though I do not care deeply about the syntax (and if you do not like the "-X" as the external option introducer, you are welcome to pick a different notation and send in a patch), it would help for example the vanilla "recursive" strategy to allow the user, when dealing with really tricky merge, to influence the rename threshold score it uses by passing it as a strategy-specific option. As a conclusion of this discussion, I'll discard xx/merge-in-c-into-next branch from "next", at the beginning of post-1.6.0 cycle. We might in the future need to resurrect only the -X<option> part to allow us to pass strategy specific options (that are not "ours/theirs"), but there is no immediate need for it, other than -Xsubtree=<path>. If somebody wants to step up and give the custom rename threshold to the recursive strategy, keeping that code to do -X<option> might help that too, though. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-19 5:32 ` Junio C Hamano @ 2008-07-19 11:19 ` Johannes Schindelin 2008-07-19 16:55 ` Junio C Hamano 2008-07-20 13:04 ` Miklos Vajna 0 siblings, 2 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-07-19 11:19 UTC (permalink / raw) To: Junio C Hamano; +Cc: Nanako Shiraishi, git Hi, On Fri, 18 Jul 2008, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > On Fri, 18 Jul 2008, Junio C Hamano wrote: > > > >> +The 'recursive' strategy can take the following options: > >> + > >> +ours;; > > > > You still have not addressed the issue that you can specify multiple > > strategies,... > > Even though multiple -s parameters are supported, I know you have been > here long enough in git scene to remember how it came about. I've seen > some third-party documents that talk about our ability to "try multiple > strategies and pick the best one" as one of the unique features, but > anybody who was there knows that it was just a failed experiment that we > did not bother removing. I think that we made it hard for that experiment to succeed, by disallowing custom merge strategies. See http://git.or.cz/gitwiki/SoC2007Ideas#head-cfde15f16950c2579a89cc109762e911546e6fe3 for an idea that would make complete sense as a _fallback_ strategy. Fallback, because it is definitely too slow to be the default. Yes, I agree, if all strategies fail, it is dubitable that we find a metric that will always find the "best" one. But if one fails and the next one does not, it is obvious what is correct. So I still feel that "-s subtree=<blabla>,recursive=theirs" would be a viable way to go. And more intuitive than "-X". I'll just ask Miklos what he thinks of the idea, and to write the patch if he likes it, once he's back from the saddle. :-) Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-19 11:19 ` Johannes Schindelin @ 2008-07-19 16:55 ` Junio C Hamano 2008-07-19 23:16 ` Johannes Schindelin 2008-07-20 13:04 ` Miklos Vajna 1 sibling, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-19 16:55 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Nanako Shiraishi, git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-19 16:55 ` Junio C Hamano @ 2008-07-19 23:16 ` Johannes Schindelin 0 siblings, 0 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-07-19 23:16 UTC (permalink / raw) To: Junio C Hamano; +Cc: Nanako Shiraishi, git Hi, On Sat, 19 Jul 2008, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > Yes, I agree, if all strategies fail, it is dubitable that we find a > > metric that will always find the "best" one. But if one fails and the > > next one does not, it is obvious what is correct. > > Not at all. Imagine the case where one of them is either ours or > theirs. But then it is not the _default_ at all! It is what the _user_ _asked_ for. So this is what the user gets. With Git, the user is not ignored (like GNOME does, to "help" the user). With Git, the user _gets_ what she asked for, even if the question does not make sense. Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-19 11:19 ` Johannes Schindelin 2008-07-19 16:55 ` Junio C Hamano @ 2008-07-20 13:04 ` Miklos Vajna 2008-07-20 13:16 ` Johannes Schindelin 2008-07-20 18:27 ` Junio C Hamano 1 sibling, 2 replies; 371+ messages in thread From: Miklos Vajna @ 2008-07-20 13:04 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, Nanako Shiraishi, git [-- Attachment #1: Type: text/plain, Size: 1462 bytes --] On Sat, Jul 19, 2008 at 01:19:46PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > So I still feel that "-s subtree=<blabla>,recursive=theirs" would be a > viable way to go. And more intuitive than "-X". > > I'll just ask Miklos what he thinks of the idea, and to write the patch if > he likes it, once he's back from the saddle. :-) I think there are three steps here. First, currently you can specify multiple strategies in the config (pull.twohead, pull.octopus) using a space separated list. If we want to change it to a coma-separated list, should we care about backwards compatibility? There are tests for this, but it's undocumented (and my patch to document it was rejected, saying we should not encourage people to use it). Second, we could allow custom strategies, as we started to discuss here: http://thread.gmane.org/gmane.comp.version-control.git/86584/focus=87684 Third, it would be nice to allow passing extra parameter(s) to the backends, but I do not know what concept is the best here. The strategy1=foo,stategy2=bar limits the input to a single string. Is that enough? Given that recursive=theirs was considered harmful, we don't have too much examples; for subtree the only parameter I could think of is the path, so a string there is enough. However, further strategies, like blame, could take more parameters, like git blame -C<num> -M<othernum>. Or do I just overcomplicate it? ;-) [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-20 13:04 ` Miklos Vajna @ 2008-07-20 13:16 ` Johannes Schindelin 2008-07-20 18:27 ` Junio C Hamano 1 sibling, 0 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-07-20 13:16 UTC (permalink / raw) To: Miklos Vajna; +Cc: Junio C Hamano, Nanako Shiraishi, git Hi, On Sun, 20 Jul 2008, Miklos Vajna wrote: > First, currently you can specify multiple strategies in the config > (pull.twohead, pull.octopus) using a space separated list. Oh, I did not mean to change that. I just misremembered. > Second, we could allow custom strategies, as we started to discuss here: > > http://thread.gmane.org/gmane.comp.version-control.git/86584/focus=87684 In my opinion, this would make it easier for interested parties to start implementing that blame-based merge strategy I mentioned. > Third, it would be nice to allow passing extra parameter(s) to the > backends, but I do not know what concept is the best here. The > strategy1=foo,stategy2=bar limits the input to a single string. Is that > enough? Given that recursive=theirs was considered harmful, we don't > have too much examples; for subtree the only parameter I could think of > is the path, so a string there is enough. > > However, further strategies, like blame, could take more parameters, > like git blame -C<num> -M<othernum>. Or do I just overcomplicate it? ;-) The common solution is like with gcc's -Wl option, which translates commata into spaces, like so: "-Wl,--machine,i386" is added as "--machine i386" to the linker command line. Our own cvsimport implements the same principle: $ git cvsimport -p -b,HEAD will only update the main branch. Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-20 13:04 ` Miklos Vajna 2008-07-20 13:16 ` Johannes Schindelin @ 2008-07-20 18:27 ` Junio C Hamano 2008-07-20 19:07 ` Johannes Schindelin 1 sibling, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-20 18:27 UTC (permalink / raw) To: Miklos Vajna; +Cc: Johannes Schindelin, Nanako Shiraishi, git 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 ... ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-20 18:27 ` Junio C Hamano @ 2008-07-20 19:07 ` Johannes Schindelin 2008-07-20 19:58 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Johannes Schindelin @ 2008-07-20 19:07 UTC (permalink / raw) To: Junio C Hamano; +Cc: Miklos Vajna, Nanako Shiraishi, git Hi, On Sun, 20 Jul 2008, Junio C Hamano wrote: > Miklos Vajna <vmiklos@frugalware.org> writes: > > > Third, it would be nice to allow passing extra parameter(s) to the > > backends, but I do not know what concept is the best here. The > > strategy1=foo,stategy2=bar limits the input to a single string. Is that > > enough? Given that recursive=theirs was considered harmful, we don't > > have too much examples;... > > I personally think -sstrategy=string1,string2,... is simply a bad taste. > > Why force yourself to parse things by having the users to concatenate > something that the user could give us separated? If you care about the > order and association between strategy and their options, you can always > do: > > -s strategy1 -X option-1-for-strategy-1 -X option-2-for-strategy-1 \ > -s strategy2 -X option-1-for-strategy-2 ... You mean something like $ git merge -s subtree -X --path -X git-gui/ git-gui/master Wow. :-) Speechless, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-20 19:07 ` Johannes Schindelin @ 2008-07-20 19:58 ` Junio C Hamano 2008-07-20 20:03 ` Sverre Rabbelier 2008-07-20 22:24 ` Johannes Schindelin 0 siblings, 2 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-20 19:58 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Miklos Vajna, Nanako Shiraishi, git 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? ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-20 19:58 ` Junio C Hamano @ 2008-07-20 20:03 ` Sverre Rabbelier 2008-07-20 20:33 ` Miklos Vajna 2008-07-20 20:33 ` Junio C Hamano 2008-07-20 22:24 ` Johannes Schindelin 1 sibling, 2 replies; 371+ messages in thread From: Sverre Rabbelier @ 2008-07-20 20:03 UTC (permalink / raw) To: Junio C Hamano; +Cc: Johannes Schindelin, Miklos Vajna, Nanako Shiraishi, git On Sun, Jul 20, 2008 at 9:58 PM, Junio C Hamano <gitster@pobox.com> wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> You mean something like >> >> $ git merge -s subtree -X --path -X git-gui/ git-gui/master >> >> Wow. :-) > > I would envision it to be more like: > > $ git merge -s subtree -Xpath=git-gui git-gui/master Whatever happened to quotes? $ git merge -s subtree -Xpath="git-gui git-gui/master" -- Cheers, Sverre Rabbelier ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-20 20:03 ` Sverre Rabbelier @ 2008-07-20 20:33 ` Miklos Vajna 2008-07-20 22:58 ` Sverre Rabbelier 2008-07-20 20:33 ` Junio C Hamano 1 sibling, 1 reply; 371+ messages in thread From: Miklos Vajna @ 2008-07-20 20:33 UTC (permalink / raw) To: sverre; +Cc: Junio C Hamano, Johannes Schindelin, Nanako Shiraishi, git [-- Attachment #1: Type: text/plain, Size: 769 bytes --] On Sun, Jul 20, 2008 at 10:03:24PM +0200, Sverre Rabbelier <alturin@gmail.com> wrote: > On Sun, Jul 20, 2008 at 9:58 PM, Junio C Hamano <gitster@pobox.com> wrote: > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > >> You mean something like > >> > >> $ git merge -s subtree -X --path -X git-gui/ git-gui/master > >> > >> Wow. :-) > > > > I would envision it to be more like: > > > > $ git merge -s subtree -Xpath=git-gui git-gui/master > > Whatever happened to quotes? > > $ git merge -s subtree -Xpath="git-gui git-gui/master" Read again what did you wrote. ;-) The current form is git merge -s subtree git-gui/master, so at most it could be $ git merge -s subtree -Xpath="git-gui" git-gui/master [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-20 20:33 ` Miklos Vajna @ 2008-07-20 22:58 ` Sverre Rabbelier 2008-07-21 8:47 ` Jakub Narebski 0 siblings, 1 reply; 371+ messages in thread From: Sverre Rabbelier @ 2008-07-20 22:58 UTC (permalink / raw) To: Miklos Vajna; +Cc: Junio C Hamano, Johannes Schindelin, Nanako Shiraishi, git On Sun, Jul 20, 2008 at 10:33 PM, Miklos Vajna <vmiklos@frugalware.org> wrote: > On Sun, Jul 20, 2008 at 10:03:24PM +0200, Sverre Rabbelier <alturin@gmail.com> wrote: >> Whatever happened to quotes? >> >> $ git merge -s subtree -Xpath="git-gui git-gui/master" > > Read again what did you wrote. ;-) > > The current form is > > git merge -s subtree git-gui/master, so at most it could be > > $ git merge -s subtree -Xpath="git-gui" git-gui/master Meh, what I ofcourse mean was: $ git merge -s subtree -X"path=git-gui" git-gui/master But that looks rather awkward, which is probably why I typed it the way I did? Maybe something like.... $ git merge -s subtree -X(--path=git-gui --foo=bar) git-gui/master -- Cheers, Sverre Rabbelier ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-20 22:58 ` Sverre Rabbelier @ 2008-07-21 8:47 ` Jakub Narebski 0 siblings, 0 replies; 371+ messages in thread From: Jakub Narebski @ 2008-07-21 8:47 UTC (permalink / raw) To: Sverre Rabbelier Cc: Miklos Vajna, Junio C Hamano, Johannes Schindelin, Nanako Shiraishi, git "Sverre Rabbelier" <alturin@gmail.com> writes: > On Sun, Jul 20, 2008 at 10:33 PM, Miklos Vajna <vmiklos@frugalware.org> wrote: >> On Sun, Jul 20, 2008 at 10:03:24PM +0200, Sverre Rabbelier <alturin@gmail.com> wrote: >>> Whatever happened to quotes? >>> >>> $ git merge -s subtree -Xpath="git-gui git-gui/master" >> >> Read again what did you wrote. ;-) >> >> The current form is >> >> git merge -s subtree git-gui/master, so at most it could be >> >> $ git merge -s subtree -Xpath="git-gui" git-gui/master > > Meh, what I of course mean was: > $ git merge -s subtree -X"path=git-gui" git-gui/master > > But that looks rather awkward, which is probably why I typed it the > way I did? Maybe something like.... > $ git merge -s subtree -X(--path=git-gui --foo=bar) git-gui/master Or perhaps (following -Wx family of GCC options) $ git merge -s subtree -X--path=git-gui,--foo=bar git-gui/master -- Jakub Narebski Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-20 20:03 ` Sverre Rabbelier 2008-07-20 20:33 ` Miklos Vajna @ 2008-07-20 20:33 ` Junio C Hamano 1 sibling, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-20 20:33 UTC (permalink / raw) To: sverre Cc: Junio C Hamano, Johannes Schindelin, Miklos Vajna, Nanako Shiraishi, git "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(). ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-20 19:58 ` Junio C Hamano 2008-07-20 20:03 ` Sverre Rabbelier @ 2008-07-20 22:24 ` Johannes Schindelin 1 sibling, 0 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-07-20 22:24 UTC (permalink / raw) To: Junio C Hamano; +Cc: Miklos Vajna, Nanako Shiraishi, git Hi, On Sun, 20 Jul 2008, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > >> I personally think -sstrategy=string1,string2,... is simply a bad taste. > >> > >> Why force yourself to parse things by having the users to concatenate > >> something that the user could give us separated? If you care about the > >> order and association between strategy and their options, you can always > >> do: > >> > >> -s strategy1 -X option-1-for-strategy-1 -X option-2-for-strategy-1 \ > >> -s strategy2 -X option-1-for-strategy-2 ... > > > > You mean something like > > > > $ git merge -s subtree -X --path -X git-gui/ git-gui/master > > > > Wow. :-) > > I would envision it to be more like: > > $ git merge -s subtree -Xpath=git-gui git-gui/master > > which git-merge internally would turn into: > > $ git-merge-subtree --path=git-gui HEAD -- OURS THEIRS > > That way both the external command line (that the end users do care about) > and the internal one (that the strategy programmer would care about) look > a lot more sensible than your command line, don't they? I still find it a lot easier to explain $ git -s subtree=git-gui git-gui/master to a new user than your command line, especially since $ git -X path=git-gui -s subtree git-gui/master would be a not so obvious mistake, _and_ especially since the implementation of your option parsing would be rather ugly. But the subject has been discussed to death, and you seem to still prefer the -X way, so I give up. You win, Dscho "who can adapt even to a syntax he does not like" ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-18 9:20 ` Nanako Shiraishi 2008-07-18 9:43 ` Junio C Hamano @ 2008-07-18 9:44 ` Petr Baudis 2008-07-18 9:58 ` Junio C Hamano 2008-07-19 5:13 ` Nanako Shiraishi 1 sibling, 2 replies; 371+ messages in thread From: Petr Baudis @ 2008-07-18 9:44 UTC (permalink / raw) To: Nanako Shiraishi; +Cc: Junio C Hamano, git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-18 9:44 ` Petr Baudis @ 2008-07-18 9:58 ` Junio C Hamano 2010-12-13 19:09 ` Yaroslav Halchenko 2008-07-19 5:13 ` Nanako Shiraishi 1 sibling, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-18 9:58 UTC (permalink / raw) To: Petr Baudis; +Cc: Nanako Shiraishi, git Petr Baudis <pasky@suse.cz> writes: > On Fri, Jul 18, 2008 at 06:20:10PM +0900, Nanako Shiraishi wrote: >> I do not know if "I do not understand what they did well enough" is the only reason people would want to use that feature. Isn't it better to let people decide that for themselves? > > It is dangerous to introduce new options just because we think someone, > sometimes might find it useful, especially if they potentially encourage > a bad workflow. Adding options and commands is expensive since it > complicates the UI further, thus we should add further only when we have > good reason for it. > >> > That also was the reason I did not add any documentation to it. > > I was actually looking for something like this based on some question on > #git (about git pull -s theirs possibility), and did stumble upon these > patches, but quickly gave up on them since it wasn't immediately clear > for me from the patch description exactly how the workflow looks like > (it doesn't really seem to work like the opposite of -s ours nor is it a > separate strategy... huh) and the options were completely undocumented. Heh, now you have some readings to do ;-) I tried not to sound too negative when describing -Xours and -Xtheirs there, but actually I think "-s theirs" is even worse. It is how you would discard what you did (perhaps because the other side has much better solution than your hack), but that can be much more easily and cleanly done with: $ git reset --hard origin Some poeple might say "But with 'merge -s theirs', I can keep what I did, too". That reset is simply discarding what I did. That logic also is flawed. You can instead: $ git branch i-was-stupid $ git reset --hard origin if you really want to keep record of your failure. One big problem "-s theirs" has, compared to the above "reset to origin, discarding or setting aside the failed history" is that your 'master' history that your further development is based on will keep your failed crap in it forever if you did "-s theirs". Hopefully you will become a better programmer over time, and you may eventually have something worth sharing with the world near the tip of your master branch. When that happens, however, you _cannot_ offer your master branch to be pulled by the upstream, as the wider world will not be interested in your earlier mistakes at all. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-18 9:58 ` Junio C Hamano @ 2010-12-13 19:09 ` Yaroslav Halchenko 2010-12-13 20:46 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Yaroslav Halchenko @ 2010-12-13 19:09 UTC (permalink / raw) To: git 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! ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2010-12-13 19:09 ` Yaroslav Halchenko @ 2010-12-13 20:46 ` Junio C Hamano 2010-12-13 21:46 ` Yaroslav Halchenko 0 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2010-12-13 20:46 UTC (permalink / raw) To: Yaroslav Halchenko; +Cc: git Yaroslav Halchenko <debian@onerussian.com> writes: > git checkout dfsg > git merge --no-commit -s theirs 0.2 > # after all I do not, and must not have my modifications > git rm -rf non-free-1 ... # probably would be scripted > git commit The other day I was talking with Shawn Pearce and said that "-s theirs" would make sense only if used with --no-commit. But for such a use case, "git read-tree -m -u 0.2" would work just as well, and discussion ended there ;-) ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2010-12-13 20:46 ` Junio C Hamano @ 2010-12-13 21:46 ` Yaroslav Halchenko 2010-12-13 22:15 ` Junio C Hamano 2010-12-14 7:23 ` Johannes Sixt 0 siblings, 2 replies; 371+ messages in thread From: Yaroslav Halchenko @ 2010-12-13 21:46 UTC (permalink / raw) To: Junio C Hamano; +Cc: git [-- Attachment #1: Type: text/plain, Size: 1375 bytes --] On Mon, 13 Dec 2010, Junio C Hamano wrote: > would make sense only if used with --no-commit. > But for such a use case, "git read-tree -m -u 0.2" would work just as > well, and discussion ended there ;-) hm -- read-tree sounded like yet another unknown to me feature of GIT I was trying desperately to discover ;) unfortunately it doesn't produce a merge for me :-/ -- just a simple commit with the state taken from the other tree: $> git read-tree -m -u origin/master cached/staged changes: 179 changes $> git commit -m 'blunt merge for -s theirs: -m -u origin/master ' [maint/0.5 b246251] blunt merge for -s theirs: -m -u origin/master 175 files changed, 9589 insertions(+), 4914 deletions(-) create mode 100644 doc/pics/ex_curvefitting_bold.svg create mode 100644 doc/pics/ex_curvefitting_searchlight.svg ... $> git show HEAD^2 fatal: ambiguous argument 'HEAD^2': unknown revision or path not in the working tree. I am using git (Debian amd64): 1:1.7.2.3-2.1 (so it is 1.7.2.3) -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2010-12-13 21:46 ` Yaroslav Halchenko @ 2010-12-13 22:15 ` Junio C Hamano 2010-12-13 22:36 ` Yaroslav Halchenko 2010-12-14 7:23 ` Johannes Sixt 1 sibling, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2010-12-13 22:15 UTC (permalink / raw) To: Yaroslav Halchenko; +Cc: git Yaroslav Halchenko <debian@onerussian.com> writes: > On Mon, 13 Dec 2010, Junio C Hamano wrote: >> would make sense only if used with --no-commit. > >> But for such a use case, "git read-tree -m -u 0.2" would work just as >> well, and discussion ended there ;-) > > hm -- read-tree sounded like yet another unknown to me feature of GIT I > was trying desperately to discover ;) unfortunately it doesn't produce a merge > for me Didn't I already say it makes sense only with --no-commit? IOW to shape the tree. And in your use case I do not think you would even want to have a merge. Even if you run "git rm" to remove non-free stuff from the merge result, if you merged the history of 0.2 that contains non-free stuff you are not allowed to distribute (forbidden either by upstream or self-imposed dfsg, the reason does not matter), people who gets the merge commit can follow its second parent to grab the non-free stuff, no? ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2010-12-13 22:15 ` Junio C Hamano @ 2010-12-13 22:36 ` Yaroslav Halchenko 0 siblings, 0 replies; 371+ messages in thread From: Yaroslav Halchenko @ 2010-12-13 22:36 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Mon, 13 Dec 2010, Junio C Hamano wrote: > > hm -- read-tree sounded like yet another unknown to me feature of GIT I > > was trying desperately to discover ;) unfortunately it doesn't produce a merge > > for me > Didn't I already say it makes sense only with --no-commit? IOW to shape > the tree. rright -- in my case --no-commit so I could remove the content before committing. > And in your use case I do not think you would even want to have a merge. > Even if you run "git rm" to remove non-free stuff from the merge result, > if you merged the history of 0.2 that contains non-free stuff you are not > allowed to distribute (forbidden either by upstream or self-imposed dfsg, > the reason does not matter), people who gets the merge commit can follow > its second parent to grab the non-free stuff, no? I see your point better now -- so it is yet another dimension of "the feature". as for non-free -- I probably should have been more precise -- non-DFSG (debian free software guidelines)-free ;) i.e.: * free compiled,rendered materials, often binary blobs, without sources (e.g. .dll's, pdfs etc) * material under free but not DFSG-free licenses, etc * if upstream repository already provides that 'non-free' material it would not be much of my misdemeanor to keep them as well buried in the repository history. What I care is to have a cleaned branch from which I could git archive, and also which I could inspect in regards to changes between releases without visually filtering all changes in non-sources (e.g. those binary blobs) or irrelevant content. if ever legal situation causes upstream to rewrite history to remove them -- I will have to do that as well anyways :-/ Having an actual merge would be useful for making the explicit "bridge" from upstream branch, thus '--no-commit -s theirs' with consecutive cleaning before commit looks the way to go IMHO. But I see now that I could possibly use read-tree at times if a real necessity comes to prune non-distributable content, and then obviously I do not want to drag upstream's illegal stuff along. -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2010-12-13 21:46 ` Yaroslav Halchenko 2010-12-13 22:15 ` Junio C Hamano @ 2010-12-14 7:23 ` Johannes Sixt 2010-12-14 14:21 ` Yaroslav Halchenko 1 sibling, 1 reply; 371+ messages in thread From: Johannes Sixt @ 2010-12-14 7:23 UTC (permalink / raw) To: Yaroslav Halchenko; +Cc: Junio C Hamano, git Am 12/13/2010 22:46, schrieb Yaroslav Halchenko: > On Mon, 13 Dec 2010, Junio C Hamano wrote: >> But for such a use case, "git read-tree -m -u 0.2" would work just as >> well, and discussion ended there ;-) > > hm -- read-tree sounded like yet another unknown to me feature of GIT I > was trying desperately to discover ;) unfortunately it doesn't produce a merge > for me :-/ -- just a simple commit with the state taken from the other tree: How about: git merge --no-commit -s ours 0.2 git read-tree -m -u 0.2 git commit -m "Reset to 0.2" -- Hannes ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2010-12-14 7:23 ` Johannes Sixt @ 2010-12-14 14:21 ` Yaroslav Halchenko 0 siblings, 0 replies; 371+ messages in thread From: Yaroslav Halchenko @ 2010-12-14 14:21 UTC (permalink / raw) To: Johannes Sixt; +Cc: Junio C Hamano, git On Tue, 14 Dec 2010, Johannes Sixt wrote: > > hm -- read-tree sounded like yet another unknown to me feature of GIT I > > was trying desperately to discover ;) unfortunately it doesn't produce a merge > > for me :-/ -- just a simple commit with the state taken from the other tree: > How about: > git merge --no-commit -s ours 0.2 > git read-tree -m -u 0.2 > git commit -m "Reset to 0.2" Thank you Johannes for chewing it up to ease the digestion by my brainless stomach -- works just fine ;) I guess this could be the alias for my needs: mtheirs = !sh -c 'git merge -s ours --no-commit $1 && git read-tree -m -u "$1"' - but since it might be a generic pattern for the use case(s) I have stated I still see no objective reason why simple '-s theirs' should not be there. -- =------------------------------------------------------------------= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-18 9:44 ` Petr Baudis 2008-07-18 9:58 ` Junio C Hamano @ 2008-07-19 5:13 ` Nanako Shiraishi 1 sibling, 0 replies; 371+ messages in thread From: Nanako Shiraishi @ 2008-07-19 5:13 UTC (permalink / raw) To: Junio C Hamano; +Cc: Petr Baudis, git Quoting Junio C Hamano <gitster@pobox.com>: > I tried not to sound too negative when describing -Xours and -Xtheirs > there, but actually I think "-s theirs" is even worse. It is how you > would discard what you did (perhaps because the other side has much better > solution than your hack), but that can be much more easily and cleanly > done with: > > $ git reset --hard origin > > Some poeple might say "But with 'merge -s theirs', I can keep what I did, > too". That reset is simply discarding what I did. > > That logic also is flawed. You can instead: > > $ git branch i-was-stupid > $ git reset --hard origin > > if you really want to keep record of your failure. > > One big problem "-s theirs" has, compared to the above "reset to origin, > discarding or setting aside the failed history" is that your 'master' > history that your further development is based on will keep your failed > crap in it forever if you did "-s theirs". Hopefully you will become a > better programmer over time, and you may eventually have something worth > sharing with the world near the tip of your master branch. When that > happens, however, you _cannot_ offer your master branch to be pulled by > the upstream, as the wider world will not be interested in your earlier > mistakes at all. Thanks for sharing your insight. Perhaps the above can become a separate pargraph to explains why there is no "theirs" merge strategy somewhere in the manual? -- Nanako Shiraishi http://ivory.ap.teacup.com/nanako3/ ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-18 8:50 ` Nanako Shiraishi 2008-07-18 9:08 ` Junio C Hamano 2008-07-18 9:20 ` Nanako Shiraishi @ 2008-07-18 11:56 ` Johannes Schindelin 2008-07-20 10:20 ` Nanako Shiraishi 3 siblings, 0 replies; 371+ messages in thread From: Johannes Schindelin @ 2008-07-18 11:56 UTC (permalink / raw) To: Nanako Shiraishi; +Cc: Junio C Hamano, git Hi, On Fri, 18 Jul 2008, Nanako Shiraishi wrote: > Quoting Junio C Hamano <gitster@pobox.com>: > > > * xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits > > + Teach git-merge -X<option> again. > > + Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next > > + builtin-merge.c: use parse_options_step() "incremental parsing" > > machinery > > + Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next > > > > This needs to be merged to master iff/when merge-theirs gets merged, > > but I do not think this series is widely supported, so both are on > > hold. > > Why do you say it is not widely supported? I may be wrong but I think > you developed these patches after somebody from the mailing list asked > for this feature. Asking for a feature, and then not doing a single thing to defend why it makes sense, of a single person, who does not even speak up now, does not count for "wide support". Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-18 8:50 ` Nanako Shiraishi ` (2 preceding siblings ...) 2008-07-18 11:56 ` Johannes Schindelin @ 2008-07-20 10:20 ` Nanako Shiraishi 3 siblings, 0 replies; 371+ messages in thread From: Nanako Shiraishi @ 2008-07-20 10:20 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, git Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>: > On Fri, 18 Jul 2008, Nanako Shiraishi wrote: > >> Quoting Junio C Hamano <gitster@pobox.com>: >> > This needs to be merged to master iff/when merge-theirs gets merged, >> > but I do not think this series is widely supported, so both are on >> > hold. >> >> Why do you say it is not widely supported? I may be wrong but I think >> you developed these patches after somebody from the mailing list asked >> for this feature. > > Asking for a feature, and then not doing a single thing to defend why it > makes sense, of a single person, who does not even speak up now, does not > count for "wide support". For the record, I was not the one who asked for such a feature. It seems that the conclusion of the discussion is that "theirs" promotes a bad workflow, and I am happy with that. -- Nanako Shiraishi http://ivory.ap.teacup.com/nanako3/ ^ permalink raw reply [flat|nested] 371+ messages in thread
* What's cooking in git.git (topics) 2008-07-17 8:08 ` Junio C Hamano 2008-07-17 13:09 ` Stephan Beyer 2008-07-18 8:50 ` Nanako Shiraishi @ 2008-07-20 1:58 ` Junio C Hamano 2008-07-20 22:40 ` Petr Baudis 2 siblings, 1 reply; 371+ messages in thread From: Junio C Hamano @ 2008-07-20 1:58 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-20 1:58 ` Junio C Hamano @ 2008-07-20 22:40 ` Petr Baudis 2008-07-20 23:04 ` Junio C Hamano 0 siblings, 1 reply; 371+ messages in thread From: Petr Baudis @ 2008-07-20 22:40 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Sat, Jul 19, 2008 at 06:58:55PM -0700, Junio C Hamano wrote: > * pb/submodule (Wed Jul 16 21:11:40 2008 +0200) 7 commits > . t7403: Submodule git mv, git rm testsuite > . git rm: Support for removing submodules > . git mv: Support moving submodules > . submodule.*: Introduce simple C interface for submodule lookup by > path > . git submodule add: Fix naming clash handling > . t7400: Add short "git submodule add" testsuite > . git-mv: Remove dead code branch > > Long overdue usability improvement series for submodule. Very much > welcomed. It would be nice to have some submodule improvements in 1.6.0, > but it would take us a few more rounds to hit 'next' with this, and it > will not be in 'master' when 1.6.0 ships. Do you think this would create serious problems? One thing this patch series depends on now is changing the git mv semantics in a rather non-trivial way, which is something we might want to do in a major release instead of within the 1.6 series. Petr "Pasky" Baudis ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-07-20 22:40 ` Petr Baudis @ 2008-07-20 23:04 ` Junio C Hamano 0 siblings, 0 replies; 371+ messages in thread From: Junio C Hamano @ 2008-07-20 23:04 UTC (permalink / raw) To: Petr Baudis; +Cc: git Petr Baudis <pasky@suse.cz> writes: > Do you think this would create serious problems? > > One thing this patch series depends on now is changing the git mv > semantics in a rather non-trivial way, which is something we might want > to do in a major release instead of within the 1.6 series. The change to git-mv perhaps is necessary to happen between a major release boundary. I do not know if the current round of patch to do so will become ready in time for 1.6.0. The rename-ce-at patch I looked at did not look like it was. ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: What's cooking in git.git (topics) 2008-06-29 8:55 ` What's cooking in git.git (topics) Junio C Hamano ` (2 preceding siblings ...) 2008-06-30 9:08 ` Junio C Hamano @ 2008-06-30 14:59 ` Brandon Casey 3 siblings, 0 replies; 371+ messages in thread From: Brandon Casey @ 2008-06-30 14:59 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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 ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) @ 2008-07-03 3:07 Edward Z. Yang 2008-07-03 12:29 ` Johannes Schindelin 0 siblings, 1 reply; 371+ messages in thread From: Edward Z. Yang @ 2008-07-03 3:07 UTC (permalink / raw) To: git; +Cc: gitster, msysGit, junio Johannes Sixt wrote: > What about installing a wrapper script, plinkssh, that does this: > [snip] Well, the patch is shorter :-) Joking aside, it's a good question. I guess I prefer the patch because: 1. It's been tested, it works. I haven't tried the script yet, so I don't know if it works. 2. Git historically doesn't use bash, so the script would have to be rewritten in Perl or plain sh or tcl or something. 3. It's less brittle than the wrapper script if we decide to have Git pass more params to OpenSSH. 4. It's "more native". I don't know if these are compelling enough reasons, though. (cc'ed everyone else, whoops) ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) 2008-07-03 3:07 [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) Edward Z. Yang @ 2008-07-03 12:29 ` Johannes Schindelin 2008-07-04 20:05 ` Edward Z. Yang 0 siblings, 1 reply; 371+ messages in thread From: Johannes Schindelin @ 2008-07-03 12:29 UTC (permalink / raw) To: Edward Z. Yang; +Cc: git, gitster, msysGit, junio Hi, On Wed, 2 Jul 2008, Edward Z. Yang wrote: > Johannes Sixt wrote: > > What about installing a wrapper script, plinkssh, that does this: > > [snip] > > Well, the patch is shorter :-) But you have to do it for every SSH backend that you might want to support. And you have to recompile. > 1. It's been tested, it works. I haven't tried the script yet, so I > don't know if it works. Sorry, that argument does not fly. "My patch is better, because I did not test your patch." > 2. Git historically doesn't use bash, so the script would have to be > rewritten in Perl or plain sh or tcl or something. That is so totally untrue. We have Perl scripts and Shell scripts (for which we need the bash), and then we have the two GUIs which use Tcl/Tk. Actually, we only have so few Perl scripts left that it might be possible to ship a version of Git on Windows without Perl. The only script that needs to be converted to a builtin is add -i. The rest of the scripts are shell. So this argument is totally bogus. > 3. It's less brittle than the wrapper script if we decide to have Git > pass more params to OpenSSH. Granted, should we decide one day to use more elaborate features of OpenSSH, then we would have to change the script, too. But most likely, Plink support would be broken by that update _anyway_, since it does not grok the OpenSSH options directly. And guess what is easier to fix, a script that rewrites the arguments from OpenSSH syntax to Plink syntax, or a C program with over 78,000 code lines that has to be recompiled? > 4. It's "more native". Would it not be even more native if we just linked in libssl? Would you write the patch? Further, would you like to convert and maintain all people's wrapper scripts to C code inside Git? BTW what is the reason why Hannes' mail does not appear to be the mail you replied to in GMane, but the patch Steffen sent? Ciao, Dscho ^ permalink raw reply [flat|nested] 371+ messages in thread
* Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) 2008-07-03 12:29 ` Johannes Schindelin @ 2008-07-04 20:05 ` Edward Z. Yang 0 siblings, 0 replies; 371+ messages in thread From: Edward Z. Yang @ 2008-07-04 20:05 UTC (permalink / raw) To: Johannes Schindelin; +Cc: msysGit, git, gitster, junio > Sorry, that argument does not fly. "My patch is better, because I did not > test your patch." Just tested, the patch works. > That is so totally untrue. We have Perl scripts and Shell scripts (for > which we need the bash), and then we have the two GUIs which use Tcl/Tk. I came up with that conclusion by grepping the Git source code for the word bash; no results. Granted, it's still a null point because the proposed script doesn't use any bash-specific features. > Further, would you like to convert and maintain all people's wrapper > scripts to C code inside Git? I was under the impression that wrapper scripts were for fleshing out new APIs and implementing non-performance critical functionality, without all the overhead of writing in C. There is little to no overhead from this patch. Anyway, Johannes still makes some pretty compelling points for the wrapper script, so you can count me +1 for the wrapper. > BTW what is the reason why Hannes' mail does not appear to be the mail > you replied to in GMane, but the patch Steffen sent? I actually did a "Reply" and so he was the only one who got the email at first. Then I resent it to the list, as well as the other CC'ed people. (Thus my comment at the bottom) ^ permalink raw reply [flat|nested] 371+ messages in thread
end of thread, other threads:[~2010-12-14 14:22 UTC | newest] Thread overview: 371+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-03-09 10:46 What's cooking in git.git (topics) Junio C Hamano 2008-03-12 7:50 ` Junio C Hamano 2008-03-12 12:18 ` Johannes Schindelin 2008-03-14 9:00 ` Junio C Hamano 2008-03-23 10:08 ` Junio C Hamano 2008-03-23 12:00 ` Samuel Tardieu 2008-03-23 17:15 ` Junio C Hamano 2008-03-23 22:34 ` Samuel Tardieu 2008-03-23 12:39 ` Steffen Prohaska 2008-03-23 17:37 ` Junio C Hamano 2008-03-23 21:06 ` Govind Salinas 2008-03-24 3:01 ` Junio C Hamano 2008-03-28 1:45 ` Junio C Hamano 2008-03-31 8:40 ` Junio C Hamano 2008-04-04 18:24 ` Junio C Hamano 2008-04-04 20:21 ` Kristian Høgsberg 2008-04-04 20:52 ` Junio C Hamano 2008-04-05 0:26 ` Johannes Schindelin 2008-04-05 5:51 ` Junio C Hamano 2008-04-09 9:43 ` Junio C Hamano 2008-04-14 7:00 ` Junio C Hamano 2008-04-15 19:23 ` Jeff King 2008-04-19 8:19 ` Junio C Hamano 2008-04-19 14:23 ` Johannes Schindelin 2008-04-19 16:34 ` Lars Hjemli 2008-04-20 4:08 ` Junio C Hamano 2008-04-21 16:10 ` Brandon Casey 2008-04-22 10:03 ` Junio C Hamano 2008-04-22 13:59 ` Ping Yin 2008-04-22 14:55 ` Josef Weidendorfer 2008-04-22 17:13 ` Ping Yin 2008-04-22 17:28 ` Johannes Schindelin 2008-04-23 1:27 ` Ping Yin 2008-04-23 2:03 ` Ping Yin 2008-04-22 18:07 ` Josef Weidendorfer 2008-04-23 1:59 ` Ping Yin 2008-04-23 7:47 ` Fedor Sergeev 2008-04-23 8:32 ` Ping Yin 2008-04-23 8:47 ` Robin Rosenberg 2008-04-23 9:16 ` Fedor Sergeev 2008-04-22 20:51 ` Michele Ballabio 2008-04-23 0:22 ` Junio C Hamano 2008-04-23 7:36 ` Michele Ballabio 2008-04-27 6:04 ` Junio C Hamano 2008-04-27 6:44 ` Ping Yin 2008-05-06 6:38 ` Junio C Hamano 2008-05-12 22:03 ` Junio C Hamano 2008-05-13 0:02 ` Junio C Hamano 2008-05-14 22:30 ` Junio C Hamano 2008-05-14 22:55 ` Daniel Barkalow 2008-05-15 4:30 ` Junio C Hamano 2008-05-15 5:51 ` Steffen Prohaska 2008-05-22 1:18 ` Junio C Hamano 2008-05-22 11:35 ` Johannes Schindelin 2008-05-22 18:17 ` Junio C Hamano 2008-05-22 22:02 ` Daniel Barkalow 2008-05-25 21:29 ` Stephan Beyer 2008-05-26 1:22 ` Junio C Hamano 2008-05-27 5:36 ` [PATCH] git-diff: allow --no-index semantics a bit more Junio C Hamano 2008-05-30 20:44 ` What's cooking in git.git (topics) Junio C Hamano 2008-05-30 21:10 ` Jon Loeliger 2008-05-31 1:25 ` Stephan Beyer 2008-05-30 22:00 ` Steven Grimm 2008-06-02 7:58 ` Junio C Hamano 2008-06-02 8:10 ` Jakub Narebski 2008-06-02 11:56 ` Sebastian Bober 2008-06-02 15:17 ` Johannes Schindelin 2008-06-02 15:43 ` Shawn O. Pearce 2008-06-02 16:14 ` Johannes Schindelin 2008-06-02 18:13 ` Junio C Hamano 2008-06-02 19:17 ` Johannes Schindelin 2008-06-02 19:25 ` Johannes Schindelin 2008-06-13 10:16 ` Junio C Hamano 2008-06-18 7:31 ` Junio C Hamano 2008-06-19 8:58 ` Johan Herland 2008-06-21 9:44 ` Junio C Hamano 2008-06-21 12:14 ` Miklos Vajna 2008-06-24 7:59 ` Junio C Hamano 2008-06-24 8:12 ` Pieter de Bie 2008-06-24 8:16 ` Pieter de Bie 2008-06-24 16:02 ` Miklos Vajna 2008-06-24 16:25 ` Johannes Schindelin 2008-06-24 18:54 ` Miklos Vajna 2008-06-24 19:08 ` Johannes Schindelin 2008-06-24 19:31 ` Jakub Narebski 2008-06-24 19:34 ` Johannes Schindelin 2008-06-24 20:06 ` Jakub Narebski 2008-06-26 15:41 ` Jakub Narebski 2008-06-24 20:44 ` Junio C Hamano 2008-06-24 22:10 ` Miklos Vajna 2008-06-24 23:16 ` Junio C Hamano 2008-06-24 23:32 ` Miklos Vajna 2008-06-25 2:57 ` Junio C Hamano 2008-06-25 3:08 ` しらいしななこ 2008-06-25 3:22 ` [PATCH] Keep some git-* programs in $(bindir) Junio C Hamano 2008-06-25 3:26 ` [PATCH] Ask for "git program" when asking for "git-program" over SSH connection Junio C Hamano 2008-06-25 3:45 ` Shawn O. Pearce 2008-06-25 4:32 ` Junio C Hamano 2008-06-25 4:44 ` Shawn O. Pearce 2008-06-25 5:09 ` Junio C Hamano 2008-06-25 5:13 ` Junio C Hamano 2008-06-25 5:27 ` Junio C Hamano 2008-06-25 5:38 ` Shawn O. Pearce 2008-06-25 22:47 ` [PATCH] daemon: accept "git program" as well Junio C Hamano 2008-06-25 22:55 ` [PATCH] Make clients ask for "git program" over ssh and local transport Junio C Hamano 2008-06-25 22:58 ` [PATCH] Ask for "git program" even against git-daemon Junio C Hamano 2008-06-25 23:27 ` Shawn O. Pearce 2008-06-25 23:36 ` Junio C Hamano 2008-06-25 23:57 ` Shawn O. Pearce 2008-06-26 0:07 ` Junio C Hamano 2008-06-25 23:13 ` [PATCH] Make clients ask for "git program" over ssh and local transport Shawn O. Pearce 2008-06-25 23:02 ` [PATCH] daemon: accept "git program" as well Shawn O. Pearce 2008-06-25 23:26 ` Junio C Hamano 2008-06-26 8:20 ` Tommi Virtanen 2008-06-26 23:38 ` Olivier Marin 2008-06-26 23:42 ` Junio C Hamano 2008-06-25 13:06 ` [PATCH] Ask for "git program" when asking for "git-program" over SSH connection Theodore Tso 2008-06-25 17:42 ` Junio C Hamano 2008-06-25 5:34 ` Shawn O. Pearce 2008-06-25 5:53 ` Junio C Hamano 2008-06-25 5:30 ` Junio C Hamano 2008-06-25 4:17 ` [PATCH] Keep some git-* programs in $(bindir) Shawn O. Pearce 2008-06-25 4:19 ` Daniel Barkalow 2008-06-25 4:37 ` Shawn O. Pearce 2008-06-25 3:26 ` What's cooking in git.git (topics) Shawn O. Pearce 2008-06-25 0:11 ` Jakub Narebski 2008-06-25 3:32 ` Shawn O. Pearce 2008-06-25 7:29 ` Miklos Vajna 2008-06-23 7:15 ` Junio C Hamano 2008-06-23 12:15 ` Miklos Vajna 2008-06-25 9:31 ` Junio C Hamano 2008-06-29 8:50 ` [PATCH] Make default expiration period of reflog used for stash infinite Junio C Hamano 2008-06-30 23:45 ` Olivier Marin 2008-07-01 7:28 ` Junio C Hamano 2008-07-02 10:59 ` [PATCH] Disconnect stash from its base commit Nanako Shiraishi 2008-07-02 13:51 ` Johannes Schindelin 2008-07-02 19:01 ` Junio C Hamano 2008-07-02 19:54 ` Abhijit Menon-Sen 2008-07-02 21:04 ` Junio C Hamano 2008-07-03 2:23 ` [PATCH] Implement "git stash branch <newbranch> <stash>" Abhijit Menon-Sen 2008-07-03 4:12 ` Junio C Hamano 2008-07-03 6:16 ` Abhijit Menon-Sen 2008-07-06 11:23 ` [PATCH v3] " Abhijit Menon-Sen 2008-07-06 12:54 ` Johannes Schindelin 2008-07-06 14:45 ` [PATCH] Add a test for "git stash branch" Abhijit Menon-Sen 2008-07-06 19:53 ` Junio C Hamano 2008-07-06 21:20 ` [PATCH v2] " Abhijit Menon-Sen 2008-06-29 8:50 ` [PATCH] Teach git-merge to pass -X<option> to the backend strategy module Junio C Hamano 2008-06-29 10:32 ` Jakub Narebski 2008-06-29 19:09 ` Junio C Hamano 2008-06-29 8:55 ` What's cooking in git.git (topics) Junio C Hamano 2008-06-29 18:35 ` Linus Torvalds 2008-06-29 19:08 ` Junio C Hamano 2008-06-29 20:11 ` Junio C Hamano 2008-06-29 20:15 ` Pieter de Bie 2008-06-29 21:57 ` Johannes Schindelin 2008-06-29 22:00 ` Steffen Prohaska 2008-06-30 3:30 ` Jeff King 2008-06-30 5:31 ` Junio C Hamano 2008-06-30 5:33 ` Jeff King 2008-06-30 5:38 ` Junio C Hamano 2008-06-30 9:08 ` Junio C Hamano 2008-06-30 11:19 ` How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics)) Steffen Prohaska 2008-06-30 18:47 ` [msysGit] " Johannes Sixt 2008-07-01 0:03 ` Clifford Caoile 2008-07-02 8:31 ` Steffen Prohaska 2008-07-02 8:32 ` [PATCH 01/12] Fake reencoding success under NO_ICONV instead of returning NULL Steffen Prohaska 2008-07-02 8:32 ` [PATCH 02/12] Do not complain about "no common commits" in an empty repo Steffen Prohaska 2008-07-02 8:32 ` [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures Steffen Prohaska 2008-07-02 8:32 ` [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds Steffen Prohaska 2008-07-02 8:32 ` [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser Steffen Prohaska 2008-07-02 8:32 ` [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) Steffen Prohaska 2008-07-02 8:32 ` [PATCH 07/12] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable Steffen Prohaska 2008-07-02 8:32 ` [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it Steffen Prohaska 2008-07-02 8:32 ` [PATCH 09/12] We need to check for msys as well as Windows in add--interactive Steffen Prohaska 2008-07-02 8:32 ` [PATCH 10/12] Add ANSI control code emulation for the Windows console Steffen Prohaska 2008-07-02 8:32 ` [PATCH 11/12] verify_path(): do not allow absolute paths Steffen Prohaska 2008-07-02 8:32 ` [PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next Steffen Prohaska 2008-07-02 16:17 ` [msysGit] " Johannes Schindelin 2008-07-02 17:08 ` Steffen Prohaska 2008-07-02 19:32 ` [msysGit] " Johannes Sixt 2008-07-03 6:06 ` Steffen Prohaska 2008-07-03 6:13 ` Junio C Hamano 2008-07-02 9:21 ` [PATCH 11/12] verify_path(): do not allow absolute paths Junio C Hamano 2008-07-02 14:24 ` Steffen Prohaska 2008-07-02 16:15 ` Johannes Schindelin 2008-07-02 17:20 ` Steffen Prohaska 2008-07-02 17:31 ` Johannes Schindelin 2008-07-02 19:17 ` [msysGit] [PATCH 10/12] Add ANSI control code emulation for the Windows console Johannes Sixt 2008-07-02 19:32 ` Peter Harris 2008-07-07 18:41 ` Johannes Sixt 2008-07-02 9:20 ` [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it Junio C Hamano 2008-07-02 14:22 ` Steffen Prohaska 2008-07-02 16:52 ` Johannes Schindelin 2008-07-02 9:16 ` [PATCH 07/12] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable Junio C Hamano 2008-07-11 16:48 ` [PATCH] " Steffen Prohaska 2008-07-11 18:42 ` Johannes Schindelin 2008-07-11 20:32 ` Steffen Prohaska 2008-07-11 20:40 ` Johannes Schindelin 2008-07-02 19:04 ` [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) Johannes Sixt 2008-07-03 11:10 ` Johannes Schindelin 2008-07-04 8:50 ` Steffen Prohaska 2008-07-04 9:18 ` Junio C Hamano 2008-07-04 9:29 ` Steffen Prohaska 2008-07-04 16:09 ` Clifford Caoile 2008-07-04 20:11 ` [msysGit] " Edward Z. Yang 2008-07-02 9:11 ` [PATCH 05/12] Windows(msysgit): Per default, display help as HTML in default browser Junio C Hamano 2008-07-02 18:57 ` Johannes Sixt 2008-07-04 9:06 ` Steffen Prohaska 2008-07-04 9:09 ` [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path() Steffen Prohaska 2008-07-04 9:09 ` [PATCH 2/2] help (Windows): Display HTML in default browser using Win32 API Steffen Prohaska 2008-07-04 9:26 ` [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path() Junio C Hamano 2008-07-04 12:35 ` Johannes Schindelin 2008-07-11 7:27 ` Steffen Prohaska 2008-07-11 7:28 ` [PATCH 1/3] Move code interpreting path relative to exec-dir to new function system_path() Steffen Prohaska 2008-07-11 7:28 ` [PATCH 2/3] help.c: Add support for htmldir relative to git_exec_path() Steffen Prohaska 2008-07-11 7:28 ` [PATCH 3/3] help (Windows): Display HTML in default browser using Windows' shell API Steffen Prohaska 2008-07-11 7:35 ` Steffen Prohaska 2008-07-11 7:37 ` [PATCH 3/3 FIXED] " Steffen Prohaska 2008-07-12 3:26 ` Junio C Hamano 2008-07-12 6:45 ` Steffen Prohaska 2008-07-12 7:07 ` Junio C Hamano 2008-07-12 20:41 ` Johannes Sixt 2008-07-13 8:58 ` Junio C Hamano 2008-07-13 20:31 ` [PATCH] Move code interpreting path relative to exec-dir to new function system_path() Johannes Sixt 2008-07-13 20:31 ` [PATCH] help.c: Add support for htmldir relative to git_exec_path() Johannes Sixt 2008-07-13 20:31 ` [PATCH] help (Windows): Display HTML in default browser using Windows' shell API Johannes Sixt 2008-07-13 20:31 ` [PATCH] Fix relative built-in paths to be relative to the command invocation Johannes Sixt 2008-07-13 20:31 ` [PATCH] Allow the built-in exec path to be relative to the command invocation path Johannes Sixt 2008-07-13 20:31 ` [PATCH] Allow add_path() to add non-existent directories to the path Johannes Sixt 2008-07-14 7:13 ` Johannes Sixt 2008-07-13 20:45 ` [PATCH] Allow the built-in exec path to be relative to the command invocation path Johannes Schindelin 2008-07-13 20:43 ` [PATCH] Fix relative built-in paths to be relative to the command invocation Johannes Schindelin 2008-07-14 6:55 ` Johannes Sixt 2008-07-14 12:20 ` Johannes Schindelin 2008-07-14 18:54 ` Johannes Sixt 2008-07-14 19:03 ` Junio C Hamano 2008-07-14 8:47 ` Johannes Sixt 2008-07-14 21:41 ` [PATCH 0/5] replacement for the part of js/more-win that is in pu Johannes Sixt 2008-07-14 21:41 ` [PATCH 1/5] Makefile: Normalize $(bindir) and $(gitexecdir) before comparing Johannes Sixt 2008-07-14 21:41 ` [PATCH 2/5] Record the command invocation path early Johannes Sixt 2008-07-14 21:41 ` [PATCH 3/5] Fix relative built-in paths to be relative to the command invocation Johannes Sixt 2008-07-14 21:41 ` [PATCH 4/5] Allow the built-in exec path to be relative to the command invocation path Johannes Sixt 2008-07-14 21:41 ` [PATCH 5/5] Allow add_path() to add non-existent directories to the path Johannes Sixt 2008-07-15 7:59 ` [PATCH 0/5] replacement for the part of js/more-win that is in pu Johannes Sixt 2008-07-11 9:02 ` [PATCH 1/2] help.c: Add support for htmldir relative to git_exec_path() Johannes Sixt 2008-07-02 9:22 ` [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds Junio C Hamano 2008-07-02 10:03 ` Marius Storm-Olsen 2008-07-02 14:29 ` Steffen Prohaska 2008-07-02 18:46 ` [msysGit] [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures Johannes Sixt 2008-07-03 11:08 ` Johannes Schindelin 2008-07-11 16:55 ` [PATCH] " Steffen Prohaska 2008-07-02 8:58 ` [PATCH 02/12] Do not complain about "no common commits" in an empty repo Junio C Hamano 2008-07-02 14:04 ` Steffen Prohaska 2008-07-02 17:07 ` Johannes Schindelin 2008-07-02 18:43 ` [PATCH 01/12] Fake reencoding success under NO_ICONV instead of returning NULL Johannes Sixt 2008-06-30 14:09 ` What's cooking in git.git (topics) Kristian Høgsberg 2008-06-30 15:58 ` Jakub Narebski 2008-06-30 22:15 ` Junio C Hamano 2008-06-30 22:15 ` Junio C Hamano 2008-06-30 22:51 ` Andrew Morton 2008-06-30 23:09 ` Johannes Schindelin 2008-06-30 22:53 ` Petr Baudis 2008-07-01 0:57 ` Stephen Rothwell 2008-07-01 15:44 ` Kristian Høgsberg 2008-07-01 10:11 ` Jeff King 2008-07-01 11:44 ` [PATCH] git-add--interactive: manual hunk editing mode Thomas Rast 2008-07-01 16:48 ` Johannes Schindelin 2008-07-01 23:54 ` Junio C Hamano 2008-07-02 5:39 ` Junio C Hamano 2008-07-02 7:00 ` Thomas Rast 2008-07-02 8:38 ` Junio C Hamano 2008-07-02 8:02 ` Jeff King 2008-07-02 8:08 ` Junio C Hamano 2008-07-02 8:32 ` Jeff King 2008-07-02 13:13 ` Johannes Schindelin 2008-07-02 18:27 ` Junio C Hamano 2008-07-02 21:58 ` [PATCH 0/3] git-add--interactive: use --recount, editing Thomas Rast 2008-07-02 21:59 ` [PATCH 1/3] git-add--interactive: replace hunk recounting with apply --recount Thomas Rast 2008-07-02 21:59 ` [PATCH 2/3] git-add--interactive: remove hunk coalescing Thomas Rast 2008-07-02 22:00 ` [PATCH 3/3] git-add--interactive: manual hunk editing mode Thomas Rast 2008-07-02 22:26 ` [PATCH 2/3] git-add--interactive: remove hunk coalescing Junio C Hamano 2008-07-02 22:35 ` Junio C Hamano 2008-07-03 19:24 ` Thomas Rast 2008-07-03 21:46 ` Junio C Hamano 2008-07-02 4:41 ` What's cooking in git.git (topics) Junio C Hamano 2008-07-06 10:04 ` Junio C Hamano 2008-07-06 11:10 ` Johannes Schindelin 2008-07-07 1:36 ` Junio C Hamano 2008-07-08 2:46 ` Junio C Hamano 2008-07-10 2:32 ` Junio C Hamano 2008-07-14 5:11 ` Junio C Hamano 2008-07-14 6:45 ` Junio C Hamano 2008-07-14 7:50 ` Closing the merge window for 1.6.0 Junio C Hamano 2008-07-14 8:07 ` Johannes Sixt 2008-07-14 8:50 ` Jakub Narebski 2008-07-14 8:55 ` Petr Baudis 2008-07-14 11:57 ` Johannes Schindelin 2008-07-14 12:41 ` Gerrit Pape 2008-07-14 12:56 ` Johannes Schindelin 2008-07-14 17:54 ` Nicolas Pitre 2008-07-14 19:00 ` Junio C Hamano 2008-07-14 19:19 ` Teemu Likonen 2008-07-15 3:14 ` Martin Langhoff 2008-07-15 9:20 ` Petr Baudis 2008-07-15 15:06 ` Dmitry Potapov 2008-07-15 15:27 ` Johannes Schindelin 2008-07-15 15:51 ` Avery Pennarun 2008-07-15 16:26 ` Nicolas Pitre 2008-07-15 16:46 ` Sverre Rabbelier 2008-07-15 17:28 ` Petr Baudis 2008-07-15 17:04 ` Dmitry Potapov 2008-07-15 18:51 ` Junio C Hamano 2008-07-15 22:10 ` Johannes Schindelin 2008-07-15 22:33 ` Junio C Hamano 2008-07-15 22:45 ` Johannes Schindelin 2008-07-15 2:51 ` Shawn O. Pearce 2008-07-15 3:30 ` Nicolas Pitre 2008-07-14 12:43 ` Petr Baudis 2008-07-20 2:23 ` Nick Andrew 2008-07-14 19:16 ` Junio C Hamano 2008-07-15 9:09 ` Petr Baudis 2008-07-14 11:53 ` What's cooking in git.git (topics) Johannes Schindelin 2008-07-14 23:12 ` Lea Wiemann 2008-07-14 23:20 ` Lea Wiemann 2008-07-15 0:03 ` Junio C Hamano 2008-07-15 3:38 ` Geoffrey Irving 2008-07-15 9:22 ` Johannes Schindelin 2008-07-15 16:48 ` Geoffrey Irving 2008-07-16 3:33 ` Junio C Hamano 2008-07-17 8:08 ` Junio C Hamano 2008-07-17 13:09 ` Stephan Beyer 2008-07-18 8:50 ` Nanako Shiraishi 2008-07-18 9:08 ` Junio C Hamano 2008-07-18 9:20 ` Nanako Shiraishi 2008-07-18 9:43 ` Junio C Hamano 2008-07-18 11:55 ` Johannes Schindelin 2008-07-19 5:32 ` Junio C Hamano 2008-07-19 11:19 ` Johannes Schindelin 2008-07-19 16:55 ` Junio C Hamano 2008-07-19 23:16 ` Johannes Schindelin 2008-07-20 13:04 ` Miklos Vajna 2008-07-20 13:16 ` Johannes Schindelin 2008-07-20 18:27 ` Junio C Hamano 2008-07-20 19:07 ` Johannes Schindelin 2008-07-20 19:58 ` Junio C Hamano 2008-07-20 20:03 ` Sverre Rabbelier 2008-07-20 20:33 ` Miklos Vajna 2008-07-20 22:58 ` Sverre Rabbelier 2008-07-21 8:47 ` Jakub Narebski 2008-07-20 20:33 ` Junio C Hamano 2008-07-20 22:24 ` Johannes Schindelin 2008-07-18 9:44 ` Petr Baudis 2008-07-18 9:58 ` Junio C Hamano 2010-12-13 19:09 ` Yaroslav Halchenko 2010-12-13 20:46 ` Junio C Hamano 2010-12-13 21:46 ` Yaroslav Halchenko 2010-12-13 22:15 ` Junio C Hamano 2010-12-13 22:36 ` Yaroslav Halchenko 2010-12-14 7:23 ` Johannes Sixt 2010-12-14 14:21 ` Yaroslav Halchenko 2008-07-19 5:13 ` Nanako Shiraishi 2008-07-18 11:56 ` Johannes Schindelin 2008-07-20 10:20 ` Nanako Shiraishi 2008-07-20 1:58 ` Junio C Hamano 2008-07-20 22:40 ` Petr Baudis 2008-07-20 23:04 ` Junio C Hamano 2008-06-30 14:59 ` Brandon Casey 2008-07-03 3:07 [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh) Edward Z. Yang 2008-07-03 12:29 ` Johannes Schindelin 2008-07-04 20:05 ` Edward Z. Yang
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).