* What's cooking in git.git (Dec 2010, #01; Sat, 4) @ 2010-12-05 6:30 Junio C Hamano 2010-12-05 7:39 ` Jeff King ` (5 more replies) 0 siblings, 6 replies; 27+ messages in thread From: Junio C Hamano @ 2010-12-05 6: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 ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. -------------------------------------------------- [New Topics] * aa/status-hilite-branch (2010-11-18) 1 commit - status: show branchname with a configurable color I am indifferent/uninterested; I don't see anything wrong with it, but I do not find coloring the field particularly useful myself. * ef/help-cmd-prefix (2010-11-26) 2 commits - (jc) review comments - help: always suggest common-cmds if prefix of cmd Reroll, or squash? * jn/fast-import-blob-access (2010-12-03) 5 commits - t9300: remove unnecessary use of /dev/stdin - fast-import: Allow cat-blob requests at arbitrary points in stream - fast-import: let importers retrieve blobs - fast-import: clarify documentation of "feature" command - fast-import: stricter parsing of integer options Will merge to 'next' soon. * jn/gitweb-per-request-config (2010-11-28) 2 commits - gitweb: document $per_request_config better - gitweb: selectable configurations that change with each request Will merge to 'next' soon. * kb/diff-C-M-synonym (2010-11-29) 1 commit - diff: add --detect-copies-harder as a synonym for --find-copies-harder Will merge to 'next' soon. * mg/cvsimport (2010-11-28) 3 commits - cvsimport.txt: document the mapping between config and options - cvsimport: fix the parsing of uppercase config options - cvsimport: partial whitespace cleanup I was being lazy and said "Ok" to "cvsimport.capital-r" but luckily other people injected sanity to the discussion. Weatherbaloon patch sent, but not queued here. * mz/maint-rebase-stat-config (2010-11-09) 1 commit - rebase: only show stat if configured to true Will merge to 'next' soon. * mz/pull-rebase-rebased (2010-11-13) 1 commit - Use reflog in 'pull --rebase . foo' Will merge to 'next' soon. * nd/maint-hide-checkout-index-from-error (2010-11-28) 1 commit - entry.c: remove "checkout-index" from error messages Will merge to 'next' soon. * tf/commit-list-prefix (2010-11-26) 1 commit - commit: Add commit_list prefix in two function names. * gb/web--browse (2010-12-03) 4 commits - web--browse: better support for chromium - web--browse: support opera, seamonkey and elinks - web--browse: split valid_tool list - web--browse: coding style Will merge to 'next' soon. The remainder of the series, which is mostly Debian specific addition, can wait (or just left for the distro). * ja/maint-pull-rebase-doc (2010-12-03) 1 commit - git-pull.txt: Mention branch.autosetuprebase Will merge to 'next'. * js/configurable-tab (2010-11-30) 2 commits - Make the tab width used for whitespace checks configurable - Merge branch 'js/maint-apply-tab-in-indent-fix' into HEAD (this branch uses js/maint-apply-tab-in-indent-fix.) Will merge to 'next'. * js/maint-apply-tab-in-indent-fix (2010-11-30) 1 commit - apply --whitespace=fix: fix tab-in-indent (this branch is used by js/configurable-tab.) Will merge to 'next'. * pd/bash-4-completion (2010-12-01) 2 commits - Use the new functions to get the current cword. - Introduce functions from bash-completion project. There is a "here is a better way to do this" from Jonathan, still in flight. -------------------------------------------------- [Graduated to "master"] * ak/apply-non-git-epoch (2010-09-29) 2 commits (merged to 'next' on 2010-11-17 at a00579c) + apply: handle patches with funny filename and colon in timezone + apply: Recognize epoch timestamps with : in the timezone * cb/leading-path-removal (2010-11-15) 6 commits (merged to 'next' on 2010-11-17 at ec7d709) + use persistent memory for rejected paths (merged to 'next' on 2010-11-05 at 55ea322) + do not overwrite files in leading path + lstat_cache: optionally return match_len + add function check_ok_to_remove() + t7607: add leading-path tests + t7607: use test-lib functions and check MERGE_HEAD * cm/diff-check-at-eol (2010-10-10) 1 commit (merged to 'next' on 2010-11-17 at ad7005a) + diff --check: correct line numbers of new blank lines at EOF * en/merge-recursive (2010-11-08) 40 commits (merged to 'next' on 2010-11-17 at 1b6f865) + t6022: Use -eq not = to test output of wc -l (merged to 'next' on 2010-11-05 at 16902eb) + merge-recursive:make_room_for_directories - work around dumb compilers + merge-recursive: Remove redundant path clearing for D/F conflicts + merge-recursive: Make room for directories in D/F conflicts + handle_delete_modify(): Check whether D/F conflicts are still present + merge_content(): Check whether D/F conflicts are still present + conflict_rename_rename_1to2(): Fix checks for presence of D/F conflicts + conflict_rename_delete(): Check whether D/F conflicts are still present + merge-recursive: Delay modify/delete conflicts if D/F conflict present + merge-recursive: Delay content merging for renames + merge-recursive: Delay handling of rename/delete conflicts + merge-recursive: Move handling of double rename of one file to other file + merge-recursive: Move handling of double rename of one file to two + merge-recursive: Avoid doubly merging rename/add conflict contents + merge-recursive: Update merge_content() call signature + merge-recursive: Update conflict_rename_rename_1to2() call signature + merge-recursive: Structure process_df_entry() to handle more cases + merge-recursive: Have process_entry() skip D/F or rename entries + merge-recursive: New function to assist resolving renames in-core only + merge-recursive: New data structures for deferring of D/F conflicts + merge-recursive: Move process_entry's content merging into a function + merge-recursive: Move delete/modify handling into dedicated function + merge-recursive: Move rename/delete handling into dedicated function + merge-recursive: Nuke rename/directory conflict detection + merge-recursive: Rename conflict_rename_rename*() for clarity + merge-recursive: Small code clarification -- variable name and comments + t6036: Add testcase for undetected conflict + t6036: Add a second testcase similar to the first but with content changes + t6036: Test index and worktree state, not just that merge fails + t6020: Add a testcase for modify/delete + directory/file conflict + t6020: Modernize style a bit + t6022: Add tests for rename/rename combined with D/F conflicts + t6022: Add paired rename+D/F conflict: (two/file, one/file) -> (one, two) + t6022: Add tests with both rename source & dest involved in D/F conflicts + t6022: Add tests for reversing order of merges when D/F conflicts present + t6022: Add test combinations of {content conflict?, D/F conflict remains?} + t6032: Add a test checking for excessive output from merge + merge-recursive: Restructure showing how to chain more process_* functions + t3030: Add a testcase for resolvable rename/add conflict with symlinks + Merge branch 'en/rename-d-f' into en/merge-recursive (this branch uses en/rename-d-f.) * en/rename-d-f (2010-09-08) 2 commits + merge-recursive: D/F conflicts where was_a_dir/file -> was_a_dir + t3509: Add rename + D/F conflict testcase that recursive strategy fails (this branch is used by en/merge-recursive.) * fc/apply-p2-get-header-name (2010-10-21) 2 commits (merged to 'next' on 2010-11-17 at 05a8e94) + test: git-apply -p2 rename/chmod only + Fix git-apply with -p greater than 1 * jc/abbrev-guard (2010-10-28) 1 commit (merged to 'next' on 2010-11-24 at f26c943) + core.abbrevguard: Ensure short object names stay unique a bit longer * jc/emfile (2010-10-28) 2 commits (merged to 'next' on 2010-11-17 at dac1bc6) + A loose object is not corrupt if it cannot be read due to EMFILE + read_sha1_file(): report correct name of packfile with a corrupt object (this branch is used by sp/emfile.) * jj/icase-directory (2010-10-03) 8 commits (merged to 'next' on 2010-11-24 at 0da9385) + Support case folding in git fast-import when core.ignorecase=true + Support case folding for git add when core.ignorecase=true + Add case insensitivity support when using git ls-files + Add case insensitivity support for directories when using git status + Case insensitivity support for .gitignore via core.ignorecase + Add string comparison functions that respect the ignore_case variable. + Makefile & configure: add a NO_FNMATCH_CASEFOLD flag + Makefile & configure: add a NO_FNMATCH flag * jl/add-p-reverse-message (2010-10-27) 1 commit (merged to 'next' on 2010-11-17 at db2ce14) + Correct help blurb in checkout -p and friends * jl/clone-recurse-sm-synonym (2010-11-04) 1 commit (merged to 'next' on 2010-11-17 at 8c326c2) + clone: Add the --recurse-submodules option as alias for --recursive * jn/cherry-pick-refresh-index (2010-10-31) 1 commit (merged to 'next' on 2010-11-17 at 75e9103) + cherry-pick/revert: transparently refresh index * jn/fast-import-fix (2010-10-20) 4 commits (merged to 'next' on 2010-11-17 at ef3b791) + fast-import: do not clear notes in do_change_note_fanout() + t9300 (fast-import): another test for the "replace root" feature + fast-import: tighten M 040000 syntax + fast-import: filemodify after M 040000 <tree> "" crashes * jn/ignore-doc (2010-11-10) 2 commits (merged to 'next' on 2010-11-24 at c0a9730) + Documentation: point to related commands from gitignore + Documentation: split gitignore page into sections * jn/thinner-wrapper (2010-11-06) 7 commits (merged to 'next' on 2010-11-24 at 3f2227d) + Remove pack file handling dependency from wrapper.o + pack-objects: mark file-local variable static + wrapper: give zlib wrappers their own translation unit + strbuf: move strbuf_branchname to sha1_name.c + path helpers: move git_mkstemp* to wrapper.c + wrapper: move odb_* to environment.c + wrapper: move xmmap() to sha1_file.c * js/configuable-tab (2010-11-29) 1 commit - Make the tab width used for whitespace checks configurable * kb/blame-author-email (2010-10-15) 1 commit (merged to 'next' on 2010-11-17 at 6fd6a2f) + blame: Add option to show author email instead of name * kb/maint-status-cquote (2010-11-08) 1 commit (merged to 'next' on 2010-11-24 at e15b73d) + status: Quote paths with spaces in short format * md/interix (2010-10-27) 2 commits (merged to 'next' on 2010-11-17 at 2a8b562) + Interix: add configure checks + add support for the SUA layer (interix; windows) * np/diff-in-corrupt-repository (2010-10-22) 1 commit (merged to 'next' on 2010-11-17 at b57a6cb) + diff: don't presume empty file when corresponding object is missing * np/pack-broken-boundary (2010-10-22) 1 commit (merged to 'next' on 2010-11-17 at 69a9f46) + make pack-objects a bit more resilient to repo corruption * pn/commit-autosquash (2010-11-02) 6 commits (merged to 'next' on 2010-11-24 at acc9c78) + add tests of commit --squash + commit: --squash option for use with rebase --autosquash + add tests of commit --fixup + commit: --fixup option for use with rebase --autosquash + pretty.c: teach format_commit_message() to reencode the output + commit: helper methods to reduce redundant blocks of code * rr/needs-clean-work-tree (2010-10-19) 1 commit (merged to 'next' on 2010-11-17 at b8aee21) + Porcelain scripts: Rewrite cryptic "needs update" error message * sn/diff-doc (2010-11-04) 3 commits (merged to 'next' on 2010-11-24 at 77190a5) + docs: clarify git diff modes of operation + diff,difftool: Don't use the {0,2} notation in usage strings + CodingGuidelines: Add a section on writing documentation * sp/emfile (2010-11-01) 2 commits (merged to 'next' on 2010-11-24 at f46d2ce) + Work around EMFILE when there are too many pack files + Use git_open_noatime when accessing pack data * tc/smart-http-post-redirect (2010-09-25) 1 commit (merged to 'next' on 2010-11-17 at 6478f7f) + smart-http: Don't change POST to GET when following redirect -------------------------------------------------- [Stalled] * nd/index-doc (2010-09-06) 1 commit - doc: technical details about the index file format Half-written but it is a good start. I may need to give some help in describing more recent index extensions. * cb/ignored-paths-are-precious (2010-08-21) 1 commit - checkout/merge: optionally fail operation when ignored files need to be overwritten This needs tests; also we know of longstanding bugs in related area that needs to be addressed---they do not have to be part of this series but their reproduction recipe would belong to the test script for this topic. It would hurt users to make the new feature on by default, especially the ones with subdirectories that come and go. * jk/tag-contains (2010-07-05) 4 commits - Why is "git tag --contains" so slow? - default core.clockskew variable to one day - limit "contains" traversals based on commit timestamp - tag: speed up --contains calculation The idea of the bottom one is probably Ok, except that the use of object flags needs to be rethought, or at least the helper needs to be moved to builtin/tag.c to make it clear that it should not be used outside the current usage context. * tr/config-doc (2010-10-24) 2 commits . Documentation: complete config list from other manpages . Documentation: Move variables from config.txt to separate file This unfortunately heavily conflicts with patches in flight... -------------------------------------------------- [Cooking] * ef/win32-dirent (2010-11-23) 6 commits - win32: use our own dirent.h - msvc: opendir: handle paths ending with a slash - win32: dirent: handle errors - msvc: opendir: do not start the search - msvc: opendir: allocate enough memory - msvc: opendir: fix malloc-failure Will merge to 'next' soon. * jk/asciidoc-update (2010-11-19) 1 commit - docs: default to more modern toolset Will merge to 'next' soon. * jk/maint-reflog-bottom (2010-11-21) 1 commit - reflogs: clear flags properly in corner case Will merge to 'next' soon. * jn/fast-import-ondemand-checkpoint (2010-11-22) 1 commit - fast-import: treat SIGUSR1 as a request to access objects early * jn/maint-fast-import-object-reuse (2010-11-23) 1 commit - fast-import: insert new object entries at start of hash bucket Will merge to 'next' soon. * jn/maint-svn-fe (2010-10-10) 1 commit - t9010 (svn-fe): Eliminate dependency on svn perl bindings Will merge to 'next' soon. * jn/svn-fe (2010-11-19) 17 commits - vcs-svn: Implement Prop-delta handling - vcs-svn: Sharpen parsing of property lines - vcs-svn: Split off function for handling of individual properties - vcs-svn: Make source easier to read on small screens - vcs-svn: More dump format sanity checks - vcs-svn: Reject path nodes without Node-action - vcs-svn: Delay read of per-path properties - vcs-svn: Combine repo_replace and repo_modify functions - vcs-svn: Replace = Delete + Add - vcs-svn: handle_node: Handle deletion case early - vcs-svn: Use mark to indicate nodes with included text - vcs-svn: Unclutter handle_node by introducing have_props var - vcs-svn: Eliminate node_ctx.mark global - vcs-svn: Eliminate node_ctx.srcRev global - vcs-svn: Check for errors from open() - vcs-svn: Allow simple v3 dumps (no deltas yet) - vcs-svn: Error out for v3 dumps Some RFC patches, to give them early and wider exposure. * mz/rebase-abort-reflog-fix (2010-11-21) 1 commit - rebase --abort: do not update branch ref * mz/rebase-i-verify (2010-11-22) 1 commit - rebase: support --verify Will merge to 'next' soon. * nd/maint-relative (2010-11-20) 1 commit - get_cwd_relative(): do not misinterpret root path Will merge to 'next' soon. * tc/format-patch-p (2010-11-23) 1 commit - format-patch: page output with --stdout I am indifferent/uninterested; I don't see anything wrong with it, though. * tc/http-urls-ends-with-slash (2010-11-25) 9 commits - http-fetch: rework url handling - http-push: add trailing slash at arg-parse time, instead of later on - http-push: check path length before using it - http-push: Normalise directory names when pushing to some WebDAV servers - http-backend: use end_url_with_slash() - url: add str wrapper for end_url_with_slash() - shift end_url_with_slash() from http.[ch] to url.[ch] - t5550-http-fetch: add test for http-fetch - t5550-http-fetch: add missing '&&' Will merge to 'next' soon. * gb/gitweb-remote-heads (2010-11-11) 11 commits (merged to 'next' on 2010-11-24 at 6fb4a6f) + git instaweb: enable remote_heads + gitweb: group remote heads by remote + gitweb: provide a routine to display (sub)sections + gitweb: refactor repository URL printing + gitweb: remotes view for a single remote + gitweb: allow action specialization in page header + gitweb: nagivation menu for tags, heads and remotes + gitweb: separate heads and remotes lists + gitweb: git_get_heads_list accepts an optional list of refs + gitweb: introduce remote_heads feature + gitweb: use fullname as hash_base in heads link * gc/http-with-non-ascii-username-url (2010-11-14) 2 commits (merged to 'next' on 2010-11-24 at 08f317f) + Fix username and password extraction from HTTP URLs + t5550: test HTTP authentication and userinfo decoding * jk/maint-decorate-01-bool (2010-11-17) 1 commit (merged to 'next' on 2010-11-24 at 347f73b) + log.decorate: accept 0/1 bool values (this branch is used by jk/pager-per-command.) * jk/pager-per-command (2010-11-17) 1 commit (merged to 'next' on 2010-11-24 at 9ebcffc) + allow command-specific pagers in pager.<cmd> (this branch uses jk/maint-decorate-01-bool.) * jn/getenv-poison (2010-11-12) 1 commit . add GETENV_POISON option to simulate unfriendly getenv() (this branch uses ks/maint-getenv-fix.) * jn/gitweb-time-hires-comes-with-5.8 (2010-11-09) 1 commit (merged to 'next' on 2010-11-24 at 6b91b41) + gitweb: Time::HiRes is in core for Perl 5.8 * ks/maint-getenv-fix (2010-11-11) 1 commit (merged to 'next' on 2010-11-24 at fa89826) + setup: make sure git_dir path is in a permanent buffer, getenv(3) case (this branch is used by jn/getenv-poison.) * nd/extended-sha1-relpath (2010-11-28) 2 commits - get_sha1: support relative path ":path" syntax - Make prefix_path() return char* without const (this branch uses jn/parse-options-extra.) As jn/parse-options-extra seems to be still rerolled, this needs to stay outside 'next' waiting for it. * nd/maint-fix-add-typo-detection (2010-11-27) 6 commits - Revert "excluded_1(): support exclude files in index" - unpack-trees: fix sparse checkout's "unable to match directories" - unpack-trees: move all skip-worktree checks back to unpack_trees() - dir.c: add free_excludes() - cache.h: realign and use (1 << x) form for CE_* constants (merged to 'next' on 2010-11-24 at 6832306) + add: do not rely on dtype being NULL behavior Will merge to 'next'. * jh/gitweb-caching (2010-12-03) 4 commits - gitweb: Minimal testing of gitweb caching - gitweb: File based caching layer (from git.kernel.org) - gitweb: add output buffering and associated functions - gitweb: Prepare for splitting gitweb Slightly updated. * jn/parse-options-extra (2010-12-01) 10 commits - update-index: migrate to parse-options API - setup: save prefix (original cwd relative to toplevel) in startup_info - parse-options: make resuming easier after PARSE_OPT_STOP_AT_NON_OPTION - parse-options: allow git commands to invent new option types - parse-options: never suppress arghelp if LITERAL_ARGHELP is set - parse-options: do not infer PARSE_OPT_NOARG from option type - parse-options: sanity check PARSE_OPT_NOARG flag - parse-options: move NODASH sanity checks to parse_options_check - parse-options: clearer reporting of API misuse - parse-options: Don't call parse_options_check() so much (this branch is used by nd/extended-sha1-relpath.) Rerolled. * nd/setup (2010-11-26) 47 commits - git.txt: correct where --work-tree path is relative to - Revert "Documentation: always respect core.worktree if set" - t0001: test git init when run via an alias - Remove all logic from get_git_work_tree() - setup: rework setup_explicit_git_dir() - setup: clean up setup_discovered_git_dir() - t1020-subdirectory: test alias expansion in a subdirectory - setup: clean up setup_bare_git_dir() - setup: limit get_git_work_tree()'s to explicit setup case only - Use git_config_early() instead of git_config() during repo setup - Add git_config_early() - rev-parse: prints --git-dir relative to user's cwd - git-rev-parse.txt: clarify --git-dir - t1510: setup case #31 - t1510: setup case #30 - t1510: setup case #29 - t1510: setup case #28 - t1510: setup case #27 - t1510: setup case #26 - t1510: setup case #25 - t1510: setup case #24 - t1510: setup case #23 - t1510: setup case #22 - t1510: setup case #21 - t1510: setup case #20 - t1510: setup case #19 - t1510: setup case #18 - t1510: setup case #17 - t1510: setup case #16 - t1510: setup case #15 - t1510: setup case #14 - t1510: setup case #13 - t1510: setup case #12 - t1510: setup case #11 - t1510: setup case #10 - t1510: setup case #9 - t1510: setup case #8 - t1510: setup case #7 - t1510: setup case #6 - t1510: setup case #5 - t1510: setup case #4 - t1510: setup case #3 - t1510: setup case #2 - t1510: setup case #1 - t1510: setup case #0 - Add t1510 and basic rules that run repo setup - builtins: print setup info if repo is found Rerolled. * mg/maint-tag-rfc1991 (2010-11-10) 5 commits (merged to 'next' on 2010-11-24 at 03864ed) + tag: recognize rfc1991 signatures + tag: factor out sig detection for tag display + tag: factor out sig detection for body edits + verify-tag: factor out signature detection + t/t7004-tag: test handling of rfc1991 signatures * jk/diff-CBM (2010-10-21) 1 commit (merged to 'next' on 2010-11-05 at 9d1ec14) + diff: report bogus input to -C/-M/-B Will merge to master soonish. * jn/git-cmd-h-bypass-setup (2010-10-22) 7 commits - update-index -h: show usage even with corrupt index - merge -h: show usage even with corrupt index - ls-files -h: show usage even with corrupt index - gc -h: show usage even with broken configuration - commit/status -h: show usage even with broken configuration - checkout-index -h: show usage even in an invalid repository - branch -h: show usage even in an invalid repository Will merge to 'next'. * yd/dir-rename (2010-10-29) 5 commits - Allow hiding renames of individual files involved in a directory rename. - Unified diff output format for bulk moves. - Add testcases for the --detect-bulk-moves diffcore flag. - Raw diff output format for bulk moves. - Introduce bulk-move detection in diffcore. Yet to be rerolled. * il/remote-fd-ext (2010-11-17) 4 commits (merged to 'next' on 2010-11-24 at ef80cf1) + remote-fd/ext: finishing touches after code review (merged to 'next' on 2010-11-05 at 7413413) + git-remote-ext + git-remote-fd + Add bidirectional_transfer_loop() * jh/notes-merge (2010-11-09) 23 commits (merged to 'next' on 2010-11-24 at 6218115) + Provide 'git merge --abort' as a synonym to 'git reset --merge' + cmd_merge(): Parse options before checking MERGE_HEAD + Provide 'git notes get-ref' to easily retrieve current notes ref + git notes merge: Add testcases for merging notes trees at different fanouts + git notes merge: Add another auto-resolving strategy: "cat_sort_uniq" + git notes merge: --commit should fail if underlying notes ref has moved + git notes merge: List conflicting notes in notes merge commit message + git notes merge: Manual conflict resolution, part 2/2 + git notes merge: Manual conflict resolution, part 1/2 + Documentation: Preliminary docs on 'git notes merge' + git notes merge: Add automatic conflict resolvers (ours, theirs, union) + git notes merge: Handle real, non-conflicting notes merges + builtin/notes.c: Refactor creation of notes commits. + git notes merge: Initial implementation handling trivial merges only + builtin/notes.c: Split notes ref DWIMmery into a separate function + notes.c: Use two newlines (instead of one) when concatenating notes + (trivial) t3303: Indent with tabs instead of spaces for consistency + notes.h/c: Propagate combine_notes_fn return value to add_note() and beyond + notes.h/c: Allow combine_notes functions to remove notes + notes.c: Reorder functions in preparation for next commit + notes.h: Make default_notes_ref() available in notes API + (trivial) notes.h: Minor documentation fixes to copy_notes() + notes.c: Hexify SHA1 in die() message from init_notes() * nd/struct-pathspec (2010-09-20) 5 commits - ce_path_match: drop prefix matching in favor of match_pathspec - Convert ce_path_match() to use struct pathspec - tree_entry_interesting: turn to match_pathspec if wildcard is present - pathspec: add tree_recursive_diff parameter - pathspec: mark wildcard pathspecs from the beginning (this branch is tangled with en/object-list-with-pathspec.) This is related to something I have long been wanting to see happen. Wait Nguyen for another round (2010-11-11). * en/object-list-with-pathspec (2010-09-20) 8 commits - Add testcases showing how pathspecs are handled with rev-list --objects - Make rev-list --objects work together with pathspecs - Move tree_entry_interesting() to tree-walk.c and export it - tree_entry_interesting(): remove dependency on struct diff_options - Convert struct diff_options to use struct pathspec - pathspec: cache string length when initializing pathspec - diff-no-index: use diff_tree_setup_paths() - Add struct pathspec (this branch is tangled with nd/struct-pathspec.) * jl/fetch-submodule-recursive (2010-11-11) 3 commits - Submodules: Add the "fetchRecurseSubmodules" config option - Add the 'fetch.recurseSubmodules' config setting - fetch/pull: Add the --recurse-submodules option Will merge to 'next' soonish. * tr/merge-unborn-clobber (2010-08-22) 1 commit - Exhibit merge bug that clobbers index&WT * ab/i18n (2010-10-07) 161 commits - po/de.po: complete German translation - po/sv.po: add Swedish translation - gettextize: git-bisect bisect_next_check "You need to" message - gettextize: git-bisect [Y/n] messages - gettextize: git-bisect bisect_replay + $1 messages - gettextize: git-bisect bisect_reset + $1 messages - gettextize: git-bisect bisect_run + $@ messages - gettextize: git-bisect die + eval_gettext messages - gettextize: git-bisect die + gettext messages - gettextize: git-bisect echo + eval_gettext message - gettextize: git-bisect echo + gettext messages - gettextize: git-bisect gettext + echo message - gettextize: git-bisect add git-sh-i18n - gettextize: git-stash drop_stash say/die messages - gettextize: git-stash "unknown option" message - gettextize: git-stash die + eval_gettext $1 messages - gettextize: git-stash die + eval_gettext $* messages - gettextize: git-stash die + eval_gettext messages - gettextize: git-stash die + gettext messages - gettextize: git-stash say + gettext messages - gettextize: git-stash echo + gettext message - gettextize: git-stash add git-sh-i18n - gettextize: git-submodule "blob" and "submodule" messages - gettextize: git-submodule "path not initialized" message - gettextize: git-submodule "[...] path is ignored" message - gettextize: git-submodule "Entering [...]" message - gettextize: git-submodule $errmsg messages - gettextize: git-submodule "Submodule change[...]" messages - gettextize: git-submodule "cached cannot be used" message - gettextize: git-submodule $update_module say + die messages - gettextize: git-submodule die + eval_gettext messages - gettextize: git-submodule say + eval_gettext messages - gettextize: git-submodule echo + eval_gettext messages - gettextize: git-submodule add git-sh-i18n - gettextize: git-pull "rebase against" / "merge with" messages - gettextize: git-pull "[...] not currently on a branch" message - gettextize: git-pull "You asked to pull" message - gettextize: git-pull split up "no candidate" message - gettextize: git-pull eval_gettext + warning message - gettextize: git-pull eval_gettext + die message - gettextize: git-pull die messages - gettextize: git-pull add git-sh-i18n - gettext docs: add "Testing marked strings" section to po/README - gettext docs: the Git::I18N Perl interface - gettext docs: the git-sh-i18n.sh Shell interface - gettext docs: the gettext.h C interface - gettext docs: add "Marking strings for translation" section in po/README - gettext docs: add a "Testing your changes" section to po/README - po/pl.po: add Polish translation - po/hi.po: add Hindi Translation - po/en_GB.po: add British English translation - po/de.po: add German translation - Makefile: only add gettext tests on XGETTEXT_INCLUDE_TESTS=YesPlease - gettext docs: add po/README file documenting Git's gettext - gettextize: git-am printf(1) message to eval_gettext - gettextize: git-am core say messages - gettextize: git-am "Apply?" message - gettextize: git-am clean_abort messages - gettextize: git-am cannot_fallback messages - gettextize: git-am die messages - gettextize: git-am eval_gettext messages - gettextize: git-am multi-line getttext $msg; echo - gettextize: git-am one-line gettext $msg; echo - gettextize: git-am add git-sh-i18n - gettext tests: add GETTEXT_POISON tests for shell scripts - gettext tests: add GETTEXT_POISON support for shell scripts - Makefile: MSGFMT="msgfmt --check" under GNU_GETTEXT - Makefile: add GNU_GETTEXT, set when we expect GNU gettext - gettextize: git-shortlog basic messages - gettextize: git-revert split up "could not revert/apply" message - gettextize: git-revert literal "me" messages - gettextize: git-revert "Your local changes" message - gettextize: git-revert basic messages - gettextize: git-notes "Refusing to %s notes in %s" message - gettextize: git-notes GIT_NOTES_REWRITE_MODE error message - gettextize: git-notes basic commands - gettextize: git-gc "Auto packing the repository" message - gettextize: git-gc basic messages - gettextize: git-describe basic messages - gettextize: git-clean clean.requireForce messages - gettextize: git-clean basic messages - gettextize: git-bundle basic messages - gettextize: git-archive basic messages - gettextize: git-status "renamed: " message - gettextize: git-status "Initial commit" message - gettextize: git-status "Changes to be committed" message - gettextize: git-status shortstatus messages - gettextize: git-status "nothing to commit" messages - gettextize: git-status basic messages - gettextize: git-push "prevent you from losing" message - gettextize: git-push basic messages - gettextize: git-tag tag_template message - gettextize: git-tag basic messages - gettextize: git-reset "Unstaged changes after reset" message - gettextize: git-reset reset_type_names messages - gettextize: git-reset basic messages - gettextize: git-rm basic messages - gettextize: git-mv "bad" messages - gettextize: git-mv basic messages - gettextize: git-merge "Wonderful" message - gettextize: git-merge "You have not concluded your merge" messages - gettextize: git-merge "Updating %s..%s" message - gettextize: git-merge basic messages - gettextize: git-log "--OPT does not make sense" messages - gettextize: git-log basic messages - gettextize: git-grep "--open-files-in-pager" message - gettextize: git-grep basic messages - gettextize: git-fetch split up "(non-fast-forward)" message - gettextize: git-fetch update_local_ref messages - gettextize: git-fetch formatting messages - gettextize: git-fetch basic messages - gettextize: git-diff basic messages - gettextize: git-commit advice messages - gettextize: git-commit "enter the commit message" message - gettextize: git-commit print_summary messages - gettextize: git-commit formatting messages - gettextize: git-commit "middle of a merge" message - gettextize: git-commit basic messages - gettextize: git-checkout "Switched to a .. branch" message - gettextize: git-checkout "HEAD is now at" message - gettextize: git-checkout describe_detached_head messages - gettextize: git-checkout: our/their version message - gettextize: git-checkout basic messages - gettextize: git-branch "(no branch)" message - gettextize: git-branch "git branch -v" messages - gettextize: git-branch "Deleted branch [...]" message - gettextize: git-branch "remote branch '%s' not found" message - gettextize: git-branch basic messages - gettextize: git-add refresh_index message - gettextize: git-add "remove '%s'" message - gettextize: git-add "pathspec [...] did not match" message - gettextize: git-add "Use -f if you really want" message - gettextize: git-add "no files added" message - gettextize: git-add basic messages - gettextize: git-clone "Cloning into" message - gettextize: git-clone basic messages - gettext tests: test message re-encoding under C - po/is.po: add Icelandic translation - gettext tests: mark a test message as not needing translation - gettext tests: test re-encoding with a UTF-8 msgid under Shell - gettext tests: test message re-encoding under Shell - gettext tests: add detection for is_IS.ISO-8859-1 locale - gettext tests: test if $VERSION exists before using it - gettextize: git-init "Initialized [...] repository" message - gettextize: git-init basic messages - gettext tests: skip lib-gettext.sh tests under GETTEXT_POISON - gettext tests: add GETTEXT_POISON=YesPlease Makefile parameter - gettext.c: use libcharset.h instead of langinfo.h when available - gettext.c: work around us not using setlocale(LC_CTYPE, "") - builtin.h: Include gettext.h - Makefile: use variables and shorter lines for xgettext - Makefile: tell xgettext(1) that our source is in UTF-8 - Makefile: provide a --msgid-bugs-address to xgettext(1) - Makefile: A variable for options used by xgettext(1) calls - gettext tests: locate i18n lib&data correctly under --valgrind - gettext: setlocale(LC_CTYPE, "") breaks Git's C function assumptions - gettext tests: rename test to work around GNU gettext bug - gettext: add infrastructure for translating Git with gettext - builtin: use builtin.h for all builtin commands - tests: use test_cmp instead of piping to diff(1) - t7004-tag.sh: re-arrange git tag comment for clarity It is getting ridiculously painful to keep re-resolving the conflicts with other topics in flight, even with the help with rerere. Needs a bit more minor work to get the basic code structure right. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-05 6:30 What's cooking in git.git (Dec 2010, #01; Sat, 4) Junio C Hamano @ 2010-12-05 7:39 ` Jeff King 2010-12-05 19:54 ` Junio C Hamano 2010-12-05 10:13 ` Yann Dirson ` (4 subsequent siblings) 5 siblings, 1 reply; 27+ messages in thread From: Jeff King @ 2010-12-05 7:39 UTC (permalink / raw To: Junio C Hamano; +Cc: Aleksi Aalto, git On Sat, Dec 04, 2010 at 10:30:21PM -0800, Junio C Hamano wrote: > * aa/status-hilite-branch (2010-11-18) 1 commit > - status: show branchname with a configurable color > > I am indifferent/uninterested; I don't see anything wrong with it, but I > do not find coloring the field particularly useful myself. I am not particularly interested, either, but FWIW, the gitcommit syntax highlighting that ships with vim does highlight this, so there are at least other people who think this is a good idea. However, I'm not sure about the default. The original patch defaulted to magenta. Your fixup defaults to "plain", but that is a regression (albeit a minor one) for people who have status.header set. I think the correct default is "the same as status.header", but that is sadly not trivial to implement because of the way we parse and store colors. I don't know if it is worth holding up the patch. It is only a regression to the user's eyes, and it is reasonably easy for them to tweak their config. -Peff ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-05 7:39 ` Jeff King @ 2010-12-05 19:54 ` Junio C Hamano 2010-12-06 0:54 ` aleksi.aalto 2010-12-09 17:27 ` Jeff King 0 siblings, 2 replies; 27+ messages in thread From: Junio C Hamano @ 2010-12-05 19:54 UTC (permalink / raw To: Jeff King; +Cc: Aleksi Aalto, git Jeff King <peff@peff.net> writes: > On Sat, Dec 04, 2010 at 10:30:21PM -0800, Junio C Hamano wrote: > >> * aa/status-hilite-branch (2010-11-18) 1 commit >> - status: show branchname with a configurable color >> >> I am indifferent/uninterested; I don't see anything wrong with it, but I >> do not find coloring the field particularly useful myself. > > I am not particularly interested, either, but FWIW, the gitcommit syntax > highlighting that ships with vim does highlight this, so there are at > least other people who think this is a good idea. As you already know, when I say "'Meh' personally", I am not saying "I want to forbid others to want it". How does vim highlight the other parts of that particular line? Does it keep them intact, or paint them in some other color? > However, I'm not sure about the default. The original patch defaulted to > magenta. Your fixup defaults to "plain", but that is a regression > (albeit a minor one) for people who have status.header set. This patch is a regression for them either way, isn't it? Except for those who chose to use magenta to paint status.header, that is. I had this suspicion that the class of people who choose a non default status.header color and the class of people who choose plain there (or have been happy with the default) expect different things. The former prefer louder output, different pieces of information painted in different colors to help them chromatically distinguish them. The latter (including myself) favor subdued output, without too many colors distacting them while reading the output. This suspicion further led me to think that the former would want this new feature to paint the branch name in a color different from status.header color, while the latter would want it in plain. So the default of "plain" would be a win for both audiences. Another thiking behind "plain" is that it avoids using "magenta" which we didn't use in the default colored output from this command. We have been trying to make the default coloring not too loud, and keeping the number of colors used low has been one way of doing so. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-05 19:54 ` Junio C Hamano @ 2010-12-06 0:54 ` aleksi.aalto 2010-12-09 17:27 ` Jeff King 1 sibling, 0 replies; 27+ messages in thread From: aleksi.aalto @ 2010-12-06 0:54 UTC (permalink / raw To: Junio C Hamano; +Cc: Jeff King, git On Sun, 5 Dec 2010, Junio C Hamano wrote: > Jeff King <peff@peff.net> writes: > >> On Sat, Dec 04, 2010 at 10:30:21PM -0800, Junio C Hamano wrote: >> >>> * aa/status-hilite-branch (2010-11-18) 1 commit >>> - status: show branchname with a configurable color >>> >>> I am indifferent/uninterested; I don't see anything wrong with it, but I >>> do not find coloring the field particularly useful myself. >> >> I am not particularly interested, either, but FWIW, the gitcommit syntax >> highlighting that ships with vim does highlight this, so there are at >> least other people who think this is a good idea. > > As you already know, when I say "'Meh' personally", I am not saying "I > want to forbid others to want it". > > How does vim highlight the other parts of that particular line? Does it > keep them intact, or paint them in some other color? The default colorscheme results in the branchname being colored with a different color than the rest of the header. Also the texts "Changes to be committed:" and "Untracked files" are colored with the same color. However with some other colorschemes, these texts have a different color from the branchname. > I had this suspicion that the class of people who choose a non default > status.header color and the class of people who choose plain there (or > have been happy with the default) expect different things. The former > prefer louder output, different pieces of information painted in different > colors to help them chromatically distinguish them. The latter (including > myself) favor subdued output, without too many colors distacting them > while reading the output. > > This suspicion further led me to think that the former would want this new > feature to paint the branch name in a color different from status.header > color, while the latter would want it in plain. So the default of "plain" > would be a win for both audiences. This reasoning sounds good to me. :Aga ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-05 19:54 ` Junio C Hamano 2010-12-06 0:54 ` aleksi.aalto @ 2010-12-09 17:27 ` Jeff King 2010-12-10 19:55 ` Junio C Hamano 1 sibling, 1 reply; 27+ messages in thread From: Jeff King @ 2010-12-09 17:27 UTC (permalink / raw To: Junio C Hamano; +Cc: Aleksi Aalto, git On Sun, Dec 05, 2010 at 11:54:00AM -0800, Junio C Hamano wrote: > >> * aa/status-hilite-branch (2010-11-18) 1 commit > >> - status: show branchname with a configurable color > [...] > > I am not particularly interested, either, but FWIW, the gitcommit syntax > > highlighting that ships with vim does highlight this, so there are at > > least other people who think this is a good idea. > > As you already know, when I say "'Meh' personally", I am not saying "I > want to forbid others to want it". > > How does vim highlight the other parts of that particular line? Does it > keep them intact, or paint them in some other color? It colors everything marked with a "#" as blue (which is also how I have my color.status.header configured). > > However, I'm not sure about the default. The original patch defaulted to > > magenta. Your fixup defaults to "plain", but that is a regression > > (albeit a minor one) for people who have status.header set. > > This patch is a regression for them either way, isn't it? Except for > those who chose to use magenta to paint status.header, that is. Yes, I should have been more clear. _Both_ cases can be a regression, depending on the user's config; the only way to avoid a regression is to default to "same as color.status.header". > I had this suspicion that the class of people who choose a non default > status.header color and the class of people who choose plain there (or > have been happy with the default) expect different things. The former > prefer louder output, different pieces of information painted in different > colors to help them chromatically distinguish them. The latter (including > myself) favor subdued output, without too many colors distacting them > while reading the output. > > This suspicion further led me to think that the former would want this new > feature to paint the branch name in a color different from status.header > color, while the latter would want it in plain. So the default of "plain" > would be a win for both audiences. I see your reasoning, but as someone in the "former" group of your description, I consider the default of "plain" worse than not highlighting it at all. Mostly because the _rest_ of my terminal output tends to be plain, so rather than appearing highlighted, the branch name appears to be connected to that output. It's hard to describe in words how ugly it is, but try: mkdir foo && cd foo && git init git config color.status.header blue git status Maybe we should put this on top? -- >8 -- Subject: [PATCH] default color.status.branch to "same as header" This gives it the same behavior as we had prior to 1d28232 (status: show branchname with a configurable color). To do this we need the concept of a "NIL" color, which is provided by color.[ch]. The implementation is very simple; in particular, there are no precautions taken against code accidentally printing the NIL. This should be fine in practice because: 1. You can't input a NIL color in the config, so it must come from the in-code defaults. Which means it is up the client code to handle the NILs it defines. 2. If we do ever print a NIL, it will be obvious what the problem is, and the bug can be fixed. Signed-off-by: Jeff King <peff@peff.net> --- I resisted the urge to make a generic "same as $X" token, which would allow users to do something like: [color "status"] branch = from:color.status.header if they really wanted. But that would be a lot more code, and I'm not sure it would be all that useful (it would be if people did stuff like theming git colors like they do window managers, but I don't think we are at quite that level). This is simple, solves the current regression, and provides an easy blueprint for handling the case in the future. color.c | 5 +++++ color.h | 5 +++++ wt-status.c | 7 +++++-- 3 files changed, 15 insertions(+), 2 deletions(-) diff --git a/color.c b/color.c index 1b00554..6a5a54e 100644 --- a/color.c +++ b/color.c @@ -211,3 +211,8 @@ int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...) va_end(args); return r; } + +int color_is_nil(const char *c) +{ + return !strcmp(c, "NIL"); +} diff --git a/color.h b/color.h index 03ca064..170ff40 100644 --- a/color.h +++ b/color.h @@ -43,6 +43,9 @@ #define GIT_COLOR_BG_MAGENTA "\033[45m" #define GIT_COLOR_BG_CYAN "\033[46m" +/* A special value meaning "no color selected" */ +#define GIT_COLOR_NIL "NIL" + /* * This variable stores the value of color.ui */ @@ -62,4 +65,6 @@ int color_fprintf(FILE *fp, const char *color, const char *fmt, ...); __attribute__((format (printf, 3, 4))) int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...); +int color_is_nil(const char *color); + #endif /* COLOR_H */ diff --git a/wt-status.c b/wt-status.c index e62388c..123582b 100644 --- a/wt-status.c +++ b/wt-status.c @@ -21,12 +21,15 @@ static char default_wt_status_colors[][COLOR_MAXLEN] = { GIT_COLOR_RED, /* WT_STATUS_UNMERGED */ GIT_COLOR_GREEN, /* WT_STATUS_LOCAL_BRANCH */ GIT_COLOR_RED, /* WT_STATUS_REMOTE_BRANCH */ - GIT_COLOR_NORMAL, /* WT_STATUS_ONBRANCH */ + GIT_COLOR_NIL, /* WT_STATUS_ONBRANCH */ }; static const char *color(int slot, struct wt_status *s) { - return s->use_color > 0 ? s->color_palette[slot] : ""; + const char *c = s->use_color > 0 ? s->color_palette[slot] : ""; + if (slot == WT_STATUS_ONBRANCH && color_is_nil(c)) + c = s->color_palette[WT_STATUS_HEADER]; + return c; } void wt_status_prepare(struct wt_status *s) -- 1.7.3.3.713.gb2a8.dirty ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-09 17:27 ` Jeff King @ 2010-12-10 19:55 ` Junio C Hamano 0 siblings, 0 replies; 27+ messages in thread From: Junio C Hamano @ 2010-12-10 19:55 UTC (permalink / raw To: Jeff King; +Cc: Junio C Hamano, Aleksi Aalto, git Jeff King <peff@peff.net> writes: > Subject: [PATCH] default color.status.branch to "same as header" > > This gives it the same behavior as we had prior to 1d28232 > (status: show branchname with a configurable color). > > To do this we need the concept of a "NIL" color, which is > provided by color.[ch]. The implementation is very simple; > in particular, there are no precautions taken against code > accidentally printing the NIL. This should be fine in > practice because: > > 1. You can't input a NIL color in the config, so it must > come from the in-code defaults. Which means it is up > the client code to handle the NILs it defines. > > 2. If we do ever print a NIL, it will be obvious what the > problem is, and the bug can be fixed. > > Signed-off-by: Jeff King <peff@peff.net> > --- > I resisted the urge to make a generic "same as $X" token, which would > allow users to do something like: > > [color "status"] > branch = from:color.status.header > > if they really wanted. But that would be a lot more code, and I'm not > sure it would be all that useful (it would be if people did stuff like > theming git colors like they do window managers, but I don't think we > are at quite that level). Also if you go that route you would need to worry about dependencies, which would not be worth it. > This is simple, solves the current regression, and provides an easy > blueprint for handling the case in the future. As I said, I don't care deeply, but you obviously cared enough to produce a patch that is pretty simple and straightforward. Let's take it. Thanks. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-05 6:30 What's cooking in git.git (Dec 2010, #01; Sat, 4) Junio C Hamano 2010-12-05 7:39 ` Jeff King @ 2010-12-05 10:13 ` Yann Dirson 2010-12-05 20:23 ` Junio C Hamano 2010-12-05 12:36 ` aleksi.aalto ` (3 subsequent siblings) 5 siblings, 1 reply; 27+ messages in thread From: Yann Dirson @ 2010-12-05 10:13 UTC (permalink / raw To: Junio C Hamano; +Cc: git On Sat, Dec 04, 2010 at 10:30:21PM -0800, Junio C Hamano wrote: > * kb/diff-C-M-synonym (2010-11-29) 1 commit > - diff: add --detect-copies-harder as a synonym for --find-copies-harder > > Will merge to 'next' soon. If we go this way, don't we want to deprecate --find-copies-harder as well ? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-05 10:13 ` Yann Dirson @ 2010-12-05 20:23 ` Junio C Hamano 2010-12-06 7:29 ` Yann Dirson 0 siblings, 1 reply; 27+ messages in thread From: Junio C Hamano @ 2010-12-05 20:23 UTC (permalink / raw To: Yann Dirson; +Cc: git Yann Dirson <ydirson@free.fr> writes: > On Sat, Dec 04, 2010 at 10:30:21PM -0800, Junio C Hamano wrote: >> * kb/diff-C-M-synonym (2010-11-29) 1 commit >> - diff: add --detect-copies-harder as a synonym for --find-copies-harder >> >> Will merge to 'next' soon. > > If we go this way, don't we want to deprecate --find-copies-harder as well ? Why? We are being nice to people who did not know --find-copies-harder but learned the --detect-renames long name before learning it, which by definition is are people because the long names have been there only for the last few months; they may expect "detect" to work there. That is the sole purpose of the additional synonym. I do not think we would get much benefit from panalizing people who knew about and have used the --find-copies-harder option for long time by marking it to be deprecated. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-05 20:23 ` Junio C Hamano @ 2010-12-06 7:29 ` Yann Dirson 2010-12-06 8:13 ` Miles Bader 0 siblings, 1 reply; 27+ messages in thread From: Yann Dirson @ 2010-12-06 7:29 UTC (permalink / raw To: gitster; +Cc: git list >> On Sat, Dec 04, 2010 at 10:30:21PM -0800, Junio C Hamano wrote: >>> * kb/diff-C-M-synonym (2010-11-29) 1 commit >>> - diff: add --detect-copies-harder as a synonym for >>> --find-copies-harder >>> >>> Will merge to 'next' soon. >> >> If we go this way, don't we want to deprecate --find-copies-harder as >> well ? > >Why? > >We are being nice to people who did not know --find-copies-harder but >learned the --detect-renames long name before learning it, which by >definition is are people because the long names have been there only for >the last few months; they may expect "detect" to work there. That is >the sole purpose of the additional synonym. But then, why not simply use --find-renames (since --detect-renames has luckily not been released ontl the masses yet), and avoid making similar-usage opts dissimilar and then adding a synonym just to make them similar the other way ? IOW, we already have tons of options everywhere, let's not just add clutter. We'll end up here with those people used to using --detect-copies-harder willing shell completion; that will just add one more item to the list we get after "--<TAB>", and it will eat precious screen space for pretty much nothing. Just my 0.02€... -- Yann Dirson - Bertin Technologies ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-06 7:29 ` Yann Dirson @ 2010-12-06 8:13 ` Miles Bader 2010-12-06 8:21 ` Yann Dirson 0 siblings, 1 reply; 27+ messages in thread From: Miles Bader @ 2010-12-06 8:13 UTC (permalink / raw To: Yann Dirson; +Cc: gitster, git list Yann Dirson <dirson@bertin.fr> writes: > But then, why not simply use --find-renames (since --detect-renames has > luckily not been released ontl the masses yet), and avoid making similar-usage > opts dissimilar and then adding a synonym just to make them similar the other > way ? "Find" and "detect" have different nuances. "Detect" sounds somewhat passive/minor, so "detect renames" makes it more clear that renames are detected _in addition_ to normal processing. "Find," by contrast, is active/major, so "find renames" makes it sounds like an action to be performed _instead_ of some normal processing. -Miles -- 97% of everything is grunge ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-06 8:13 ` Miles Bader @ 2010-12-06 8:21 ` Yann Dirson 2010-12-06 8:39 ` Miles Bader 0 siblings, 1 reply; 27+ messages in thread From: Yann Dirson @ 2010-12-06 8:21 UTC (permalink / raw To: Miles Bader; +Cc: gitster, git list On Mon, 06 Dec 2010 17:13:46 +0900 Miles Bader <miles@gnu.org> wrote: > Yann Dirson <dirson@bertin.fr> writes: > > But then, why not simply use --find-renames (since --detect-renames > > has luckily not been released ontl the masses yet), and avoid > > making similar-usage opts dissimilar and then adding a synonym just > > to make them similar the other way ? > > "Find" and "detect" have different nuances. > > "Detect" sounds somewhat passive/minor, so "detect renames" makes it > more clear that renames are detected _in addition_ to normal > processing. Seen that argument before. 1. does anyone care ? (I personally don't) 2. whether we care or not we have IMHO to face the implications, see my other mails about implications of both paths -- Yann Dirson - Bertin Technologies ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-06 8:21 ` Yann Dirson @ 2010-12-06 8:39 ` Miles Bader 2010-12-06 8:48 ` Yann Dirson 0 siblings, 1 reply; 27+ messages in thread From: Miles Bader @ 2010-12-06 8:39 UTC (permalink / raw To: Yann Dirson; +Cc: gitster, git list On Mon, Dec 6, 2010 at 5:21 PM, Yann Dirson <dirson@bertin.fr> wrote: > Seen that argument before. > 1. does anyone care ? (I personally don't) If nobody cared, you wouldn't get an argument. -Miles -- Cat is power. Cat is peace. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-06 8:39 ` Miles Bader @ 2010-12-06 8:48 ` Yann Dirson 2010-12-06 9:13 ` Miles Bader 0 siblings, 1 reply; 27+ messages in thread From: Yann Dirson @ 2010-12-06 8:48 UTC (permalink / raw To: Miles Bader; +Cc: gitster, git list On Mon, 06 Dec 2010 17:39:54 +0900 Miles Bader <miles@gnu.org> wrote: > On Mon, Dec 6, 2010 at 5:21 PM, Yann Dirson <dirson@bertin.fr> wrote: > > Seen that argument before. > > 1. does anyone care ? (I personally don't) > > If nobody cared, you wouldn't get an argument. OK, I can hear that - but well, noone complained till now that --find-copies-harder would sound like "an action to be performed _instead_ of some normal processing". But most importantly, I don't get much feedback on the direct implication of that choice: are we going to have 2 exact synonyms (--find-copies-harder and --detect-copies-harder) forever, and to what extent (see prev. mail about completion) ? In the end, I still think the implications for the usability are what matters, more than arguing about a subtle nuance of vocabulary. -- Yann Dirson - Bertin Technologies ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-06 8:48 ` Yann Dirson @ 2010-12-06 9:13 ` Miles Bader 2010-12-06 11:31 ` Yann Dirson ` (2 more replies) 0 siblings, 3 replies; 27+ messages in thread From: Miles Bader @ 2010-12-06 9:13 UTC (permalink / raw To: Yann Dirson; +Cc: gitster, git list On Mon, Dec 6, 2010 at 5:48 PM, Yann Dirson <dirson@bertin.fr> wrote: > In the end, I still think the implications for the usability are what > matters, more than arguing about a subtle nuance of vocabulary. There is no "usability" problem. it's is normal and good that option names are sometimes revisited and improved -- nothing is perfect on the first try. By keeping the old option around as a deprecated alias, we avoid compatibility issues. That doesn't mean there aren't _any_ issues, but they tend to be pretty minor (such as the "space used by the deprecation option" that you complain about). Maybe if you renamed every option simultaneously, there would be confusion, but seriously, it's only one option. It's not going to be a problem. -Miles -- Cat is power. Cat is peace. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-06 9:13 ` Miles Bader @ 2010-12-06 11:31 ` Yann Dirson 2010-12-06 11:37 ` Matthieu Moy 2010-12-10 21:59 ` Junio C Hamano 2 siblings, 0 replies; 27+ messages in thread From: Yann Dirson @ 2010-12-06 11:31 UTC (permalink / raw To: Miles Bader; +Cc: gitster, git list On Mon, 06 Dec 2010 18:13:06 +0900 Miles Bader <miles@gnu.org> wrote: > On Mon, Dec 6, 2010 at 5:48 PM, Yann Dirson <dirson@bertin.fr> wrote: > it's is normal and good that option names are sometimes revisited and > improved -- nothing is perfect on the first try. By keeping the old > option around as a deprecated alias, we avoid compatibility issues. ... except Junio advocates *not* deprecating this one, since it is here since ages. > That doesn't mean there aren't _any_ issues, but they tend to be > pretty minor (such as the "space used by the deprecation option" that > you complain about). > > Maybe if you renamed every option simultaneously, there would be > confusion, but seriously, it's only one option. It's not going to be > a problem. I'm not sure we want to use "it's only one option" as an excuse. It can easily become a bad habit. > There is no "usability" problem. Completion of "git diff --<TAB>" in stable branch gives 44 choices here. One of the most frequent criticisms about git I hear among coworkers is that there are so many commands and options. Will be funny to explain them that "we just added another one, for no technical reason". -- Yann Dirson - Bertin Technologies ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-06 9:13 ` Miles Bader 2010-12-06 11:31 ` Yann Dirson @ 2010-12-06 11:37 ` Matthieu Moy 2010-12-10 21:59 ` Junio C Hamano 2 siblings, 0 replies; 27+ messages in thread From: Matthieu Moy @ 2010-12-06 11:37 UTC (permalink / raw To: Miles Bader; +Cc: Yann Dirson, gitster, git list Miles Bader <miles@gnu.org> writes: > it's is normal and good that option names are sometimes revisited and > improved -- nothing is perfect on the first try. By keeping the old > option around as a deprecated alias, we avoid compatibility issues. The problem is that the old name isn't kept as a _deprecated_ alias, but just as an alias: --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -251,6 +251,7 @@ endif::git-log[] If `n` is specified, it has the same meaning as for `-M<n>`. --find-copies-harder:: +--detect-copies-harder:: For performance reasons, by default, `-C` option finds copies only if the original file of the copy was modified in the same changeset. This flag makes the command I'd rather have stg like ---find-copies-harder:: +--detect-copies-harder:: ... +--find-copies-harder:: + Deprecated alias for --detect-copies-harder. + even if the old alias is kept forever. It's good to let old-timers use the old name, but we shouldn't confuse new users with two names without a hint on which one they're supposed to use. Otherwise, the addition of an alias doesn't really have any benefit for anyone. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-06 9:13 ` Miles Bader 2010-12-06 11:31 ` Yann Dirson 2010-12-06 11:37 ` Matthieu Moy @ 2010-12-10 21:59 ` Junio C Hamano 2 siblings, 0 replies; 27+ messages in thread From: Junio C Hamano @ 2010-12-10 21:59 UTC (permalink / raw To: Miles Bader; +Cc: Yann Dirson, git list Miles Bader <miles@gnu.org> writes: > Maybe if you renamed every option simultaneously, there would be > confusion, but seriously, it's only one option. It's not going to be > a problem. Well, let's avoid all of that trouble before it is too late, by putting this on top of what is in 'next' and ship 1.7.4 with it. Between "find" and "detect", I do not have much preference either way. It may sound more active to "find" them, but if told to "detect" them, git goes ahead and actively changes its internal behaviour in order to do so, which amounts to an active "find"ing anyway, so... -- >8 -- From: Yann Dirson <ydirson@altern.org> Date: Wed, 10 Nov 2010 21:27:12 +0100 Subject: [PATCH] diff: use "find" instead of "detect" as prefix for long forms of -M and -C It is more consistent with existing --find-copies-harder; luckily "detect" variant has not appeared in any officially released version of git. Signed-off-by: Yann Dirson <ydirson@altern.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> --- Documentation/diff-options.txt | 5 ++--- diff.c | 18 +++++++++--------- 2 files changed, 11 insertions(+), 12 deletions(-) diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt index 7246e10..c93124b 100644 --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -230,7 +230,7 @@ eligible for being picked up as a possible source of a rename to another file. -M[<n>]:: ---detect-renames[=<n>]:: +--find-renames[=<n>]:: ifndef::git-log[] Detect renames. endif::git-log[] @@ -246,12 +246,11 @@ endif::git-log[] hasn't changed. -C[<n>]:: ---detect-copies[=<n>]:: +--find-copies[=<n>]:: Detect copies as well as renames. See also `--find-copies-harder`. If `n` is specified, it has the same meaning as for `-M<n>`. --find-copies-harder:: ---detect-copies-harder:: For performance reasons, by default, `-C` option finds copies only if the original file of the copy was modified in the same changeset. This flag makes the command diff --git a/diff.c b/diff.c index dee0bd8..b5ef1ec 100644 --- a/diff.c +++ b/diff.c @@ -3150,14 +3150,14 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac) if ((options->break_opt = diff_scoreopt_parse(arg)) == -1) return -1; } - else if (!prefixcmp(arg, "-M") || !prefixcmp(arg, "--detect-renames=") || - !strcmp(arg, "--detect-renames")) { + else if (!prefixcmp(arg, "-M") || !prefixcmp(arg, "--find-renames=") || + !strcmp(arg, "--find-renames")) { if ((options->rename_score = diff_scoreopt_parse(arg)) == -1) return -1; options->detect_rename = DIFF_DETECT_RENAME; } - else if (!prefixcmp(arg, "-C") || !prefixcmp(arg, "--detect-copies=") || - !strcmp(arg, "--detect-copies")) { + else if (!prefixcmp(arg, "-C") || !prefixcmp(arg, "--find-copies=") || + !strcmp(arg, "--find-copies")) { if (options->detect_rename == DIFF_DETECT_COPY) DIFF_OPT_SET(options, FIND_COPIES_HARDER); if ((options->rename_score = diff_scoreopt_parse(arg)) == -1) @@ -3194,7 +3194,7 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac) DIFF_OPT_SET(options, TEXT); else if (!strcmp(arg, "-R")) DIFF_OPT_SET(options, REVERSE_DIFF); - else if (!strcmp(arg, "--find-copies-harder") || !strcmp(arg, "--detect-copies-harder")) + else if (!strcmp(arg, "--find-copies-harder")) DIFF_OPT_SET(options, FIND_COPIES_HARDER); else if (!strcmp(arg, "--follow")) DIFF_OPT_SET(options, FOLLOW_RENAMES); @@ -3380,12 +3380,12 @@ static int diff_scoreopt_parse(const char *opt) opt += strlen("break-rewrites"); if (*opt == 0 || *opt++ == '=') cmd = 'B'; - } else if (!prefixcmp(opt, "detect-copies")) { - opt += strlen("detect-copies"); + } else if (!prefixcmp(opt, "find-copies")) { + opt += strlen("find-copies"); if (*opt == 0 || *opt++ == '=') cmd = 'C'; - } else if (!prefixcmp(opt, "detect-renames")) { - opt += strlen("detect-renames"); + } else if (!prefixcmp(opt, "find-renames")) { + opt += strlen("find-renames"); if (*opt == 0 || *opt++ == '=') cmd = 'M'; } -- 1.7.3.3.710.g2d012 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-05 6:30 What's cooking in git.git (Dec 2010, #01; Sat, 4) Junio C Hamano 2010-12-05 7:39 ` Jeff King 2010-12-05 10:13 ` Yann Dirson @ 2010-12-05 12:36 ` aleksi.aalto 2010-12-05 15:51 ` Patrick Rouleau 2010-12-05 13:00 ` Erik Faye-Lund ` (2 subsequent siblings) 5 siblings, 1 reply; 27+ messages in thread From: aleksi.aalto @ 2010-12-05 12:36 UTC (permalink / raw To: Junio C Hamano; +Cc: git On Sat, 4 Dec 2010, Junio C Hamano wrote: > * aa/status-hilite-branch (2010-11-18) 1 commit > - status: show branchname with a configurable color > > I am indifferent/uninterested; I don't see anything wrong with it, but I > do not find coloring the field particularly useful myself. The idea for this patch came from my daywork, where I have lately been trying to teach new users effective use of Git. We promote heavy usage of "git status" for new users in order for them to understand what all the basic commands do. A great amount of users fail to notice in which branch they are even when looking at the status message. I think this small tweak could help at least some of such new users without causing considerable harm for more advanced users. And as Jeff pointed out, this is already the default beharivour in vim for commit messages. I have always found it quite reasonable. :Aga ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-05 12:36 ` aleksi.aalto @ 2010-12-05 15:51 ` Patrick Rouleau 0 siblings, 0 replies; 27+ messages in thread From: Patrick Rouleau @ 2010-12-05 15:51 UTC (permalink / raw To: git <aleksi.aalto <at> iki.fi> writes: > > On Sat, 4 Dec 2010, Junio C Hamano wrote: > > * aa/status-hilite-branch (2010-11-18) 1 commit > > - status: show branchname with a configurable color > > > > I am indifferent/uninterested; I don't see anything wrong with it, but I > > do not find coloring the field particularly useful myself. > > The idea for this patch came from my daywork, where I have lately been > trying to teach new users effective use of Git. We promote heavy usage of > "git status" for new users in order for them to understand what all the > basic commands do. A great amount of users fail to notice in which branch > they are even when looking at the status message. I think this small tweak > could help at least some of such new users without causing considerable > harm for more advanced users. I see the same problem at my daywork. But like others, I'm not sure about the default color. I would opt for green which is the default used by the branch command for highlight the current branch. Maybe we can add an empty line after the branch name, to make it stand out a bit more, with or without color? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-05 6:30 What's cooking in git.git (Dec 2010, #01; Sat, 4) Junio C Hamano ` (2 preceding siblings ...) 2010-12-05 12:36 ` aleksi.aalto @ 2010-12-05 13:00 ` Erik Faye-Lund 2010-12-05 20:15 ` Junio C Hamano 2010-12-05 15:00 ` Michael J Gruber 2010-12-08 11:23 ` t9010 broken in pu [Re: What's cooking in git.git (Dec 2010, #01; Sat, 4)] Thomas Rast 5 siblings, 1 reply; 27+ messages in thread From: Erik Faye-Lund @ 2010-12-05 13:00 UTC (permalink / raw To: Junio C Hamano; +Cc: git On Sun, Dec 5, 2010 at 7:30 AM, 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'. The ones > marked with '.' do not appear in any of the integration branches, but I am > still holding onto them. > > -------------------------------------------------- > [New Topics] > > * aa/status-hilite-branch (2010-11-18) 1 commit > - status: show branchname with a configurable color > > I am indifferent/uninterested; I don't see anything wrong with it, but I > do not find coloring the field particularly useful myself. > > * ef/help-cmd-prefix (2010-11-26) 2 commits > - (jc) review comments > - help: always suggest common-cmds if prefix of cmd > > Reroll, or squash? I was planning on re-rolling, but looking at it with fresh eyes it doesn't seem like there's much useful I can do. So feel free to just squash it. I think the original commit message still makes sense. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-05 13:00 ` Erik Faye-Lund @ 2010-12-05 20:15 ` Junio C Hamano 0 siblings, 0 replies; 27+ messages in thread From: Junio C Hamano @ 2010-12-05 20:15 UTC (permalink / raw To: kusmabite; +Cc: git Erik Faye-Lund <kusmabite@gmail.com> writes: >> Reroll, or squash? > > I was planning on re-rolling, but looking at it with fresh eyes it > doesn't seem like there's much useful I can do. So feel free to just > squash it. I think the original commit message still makes sense. Thanks. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-05 6:30 What's cooking in git.git (Dec 2010, #01; Sat, 4) Junio C Hamano ` (3 preceding siblings ...) 2010-12-05 13:00 ` Erik Faye-Lund @ 2010-12-05 15:00 ` Michael J Gruber 2010-12-05 20:06 ` Junio C Hamano 2010-12-08 11:23 ` t9010 broken in pu [Re: What's cooking in git.git (Dec 2010, #01; Sat, 4)] Thomas Rast 5 siblings, 1 reply; 27+ messages in thread From: Michael J Gruber @ 2010-12-05 15:00 UTC (permalink / raw To: Junio C Hamano; +Cc: git Junio C Hamano venit, vidit, dixit 05.12.2010 07:30: ... > > * mg/cvsimport (2010-11-28) 3 commits > - cvsimport.txt: document the mapping between config and options > - cvsimport: fix the parsing of uppercase config options > - cvsimport: partial whitespace cleanup > > I was being lazy and said "Ok" to "cvsimport.capital-r" but luckily other > people injected sanity to the discussion. Weatherbaloon patch sent, but I assume I should try and not read too much into this... Michael ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-05 15:00 ` Michael J Gruber @ 2010-12-05 20:06 ` Junio C Hamano 2010-12-06 8:55 ` Michael J Gruber 0 siblings, 1 reply; 27+ messages in thread From: Junio C Hamano @ 2010-12-05 20:06 UTC (permalink / raw To: Michael J Gruber; +Cc: git Michael J Gruber <git@drmicha.warpmail.net> writes: > Junio C Hamano venit, vidit, dixit 05.12.2010 07:30: > ... >> >> * mg/cvsimport (2010-11-28) 3 commits >> - cvsimport.txt: document the mapping between config and options >> - cvsimport: fix the parsing of uppercase config options >> - cvsimport: partial whitespace cleanup >> >> I was being lazy and said "Ok" to "cvsimport.capital-r" but luckily other >> people injected sanity to the discussion. Weatherbaloon patch sent, but > > I assume I should try and not read too much into this... No, you shouldn't. I wasn't questioning _your_ sanity, and if you took it that way, I apologize. I as the maintainer have different priority from contributors. The contributed patches want to "get the job done" first, and their solution only need to be "correct and not too ugly". I however in addition need to make sure that the changes make sense in the longer term, and my saying "Ok" to "capital-r" instead of rejecting the patch totally went against that obligation of mine. I'll have a hard time justifying why users need to type that long string that does not convey much information in three months. It was _my_ temporary insanity that came from fatigue. So an weatherbaloon patch was sent as a counterproposal, which I think it shows the best course of action given the existing constraints, but there may be better ones. If you agree, and if you have time and inclination, a reroll in that direction would be appreciated. And it does not have to be you but others on the list. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-05 20:06 ` Junio C Hamano @ 2010-12-06 8:55 ` Michael J Gruber 2010-12-06 15:39 ` Thiago Farina 0 siblings, 1 reply; 27+ messages in thread From: Michael J Gruber @ 2010-12-06 8:55 UTC (permalink / raw To: Junio C Hamano; +Cc: git Junio C Hamano venit, vidit, dixit 05.12.2010 21:06: > Michael J Gruber <git@drmicha.warpmail.net> writes: > >> Junio C Hamano venit, vidit, dixit 05.12.2010 07:30: >> ... >>> >>> * mg/cvsimport (2010-11-28) 3 commits >>> - cvsimport.txt: document the mapping between config and options >>> - cvsimport: fix the parsing of uppercase config options >>> - cvsimport: partial whitespace cleanup >>> >>> I was being lazy and said "Ok" to "cvsimport.capital-r" but luckily other >>> people injected sanity to the discussion. Weatherbaloon patch sent, but >> >> I assume I should try and not read too much into this... > > No, you shouldn't. I wasn't questioning _your_ sanity, and if you took it > that way, I apologize. No need to. I was pointing out a potentially misunderstandable formulation without misunderstanding it ;) > I as the maintainer have different priority from contributors. The > contributed patches want to "get the job done" first, and their solution > only need to be "correct and not too ugly". > > I however in addition need to make sure that the changes make sense in the > longer term, Exactly, and you're doing a good job of it. It can lead to the impression (on the contributors' side) that even simple patches are difficult to "get in", and can lead to frustration, of course. But it also ensures that we don't have even more work later on, trying to work around a half-thought-through earlier change. [In this particular case, I reckoned cvsimport basically hasn't got much "later" left, but who knows when cvs2git is ready for incremental sync.] Michael ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: What's cooking in git.git (Dec 2010, #01; Sat, 4) 2010-12-06 8:55 ` Michael J Gruber @ 2010-12-06 15:39 ` Thiago Farina 0 siblings, 0 replies; 27+ messages in thread From: Thiago Farina @ 2010-12-06 15:39 UTC (permalink / raw To: Michael J Gruber; +Cc: Junio C Hamano, git On Mon, Dec 6, 2010 at 6:55 AM, Michael J Gruber <git@drmicha.warpmail.net> wrote: > Exactly, and you're doing a good job of it. Yeah, he does a good a job. :) > It can lead to the impression (on the contributors' side) that even simple patches are > difficult to "get in", and can lead to frustration, of course. This resumes some of my frustrations here, and maybe the other contributors here too. So is not just me that has this impression. Hope the experience can be improved in future. > But it also ensures that we don't have even more work later on, trying to work > around a half-thought-through earlier change. > And this is also true. ^ permalink raw reply [flat|nested] 27+ messages in thread
* t9010 broken in pu [Re: What's cooking in git.git (Dec 2010, #01; Sat, 4)] 2010-12-05 6:30 What's cooking in git.git (Dec 2010, #01; Sat, 4) Junio C Hamano ` (4 preceding siblings ...) 2010-12-05 15:00 ` Michael J Gruber @ 2010-12-08 11:23 ` Thomas Rast 2010-12-08 11:28 ` Jonathan Nieder 5 siblings, 1 reply; 27+ messages in thread From: Thomas Rast @ 2010-12-08 11:23 UTC (permalink / raw To: Junio C Hamano; +Cc: git, Jonathan Nieder Junio C Hamano wrote: > * jn/svn-fe (2010-11-19) 17 commits > - vcs-svn: Implement Prop-delta handling > - vcs-svn: Sharpen parsing of property lines > - vcs-svn: Split off function for handling of individual properties > - vcs-svn: Make source easier to read on small screens > - vcs-svn: More dump format sanity checks > - vcs-svn: Reject path nodes without Node-action > - vcs-svn: Delay read of per-path properties > - vcs-svn: Combine repo_replace and repo_modify functions > - vcs-svn: Replace = Delete + Add > - vcs-svn: handle_node: Handle deletion case early > - vcs-svn: Use mark to indicate nodes with included text > - vcs-svn: Unclutter handle_node by introducing have_props var > - vcs-svn: Eliminate node_ctx.mark global > - vcs-svn: Eliminate node_ctx.srcRev global > - vcs-svn: Check for errors from open() > - vcs-svn: Allow simple v3 dumps (no deltas yet) > - vcs-svn: Error out for v3 dumps > > Some RFC patches, to give them early and wider exposure. If I'm reading the test report right, the merge conflict in t/t9010-svn-fe.sh broke tests. It bisects to 5ea8b68 (Merge branch 'jn/svn-fe' into pu, 2010-12-07), failing with expecting success: svnadmin create simple-svn && svnadmin load simple-svn <"$TEST_DIRECTORY/t9135/svn.dump" && svn_cmd export "file://$PWD/simple-svn" simple-svnco && git init simple-git && test-svn-fe "$TEST_DIRECTORY/t9135/svn.dump" >simple.fe && ( cd simple-git && git fast-import <../simple.fe ) && ( cd simple-svnco && git init && git add . && git fetch ../simple-git master && git diff --exit-code FETCH_HEAD ) svnadmin: Repository creation failed svnadmin: Could not create top-level directory svnadmin: 'simple-svn' exists and is non-empty not ok - 18 t9135/svn.dump A quick reading of the merge suggests that you concatenated with an earlier test that goes test_dump () { label=$1 dump=$2 test_expect_success "$dump" ' svnadmin create "$label-svn" && # <snip> ' } test_dump simple t9135/svn.dump hence creating simple-svn, too. So a rename or rm -rf should suffice. -- Thomas Rast trast@{inf,student}.ethz.ch ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: t9010 broken in pu [Re: What's cooking in git.git (Dec 2010, #01; Sat, 4)] 2010-12-08 11:23 ` t9010 broken in pu [Re: What's cooking in git.git (Dec 2010, #01; Sat, 4)] Thomas Rast @ 2010-12-08 11:28 ` Jonathan Nieder 0 siblings, 0 replies; 27+ messages in thread From: Jonathan Nieder @ 2010-12-08 11:28 UTC (permalink / raw To: Thomas Rast; +Cc: Junio C Hamano, git Thomas Rast wrote: > If I'm reading the test report right, the merge conflict in > t/t9010-svn-fe.sh broke tests. It bisects to 5ea8b68 (Merge branch > 'jn/svn-fe' into pu, 2010-12-07), failing with [...] > A quick reading of the merge suggests that you concatenated with an > earlier test that goes > > test_dump () { [...] > hence creating simple-svn, too. So a rename or rm -rf should suffice. Thanks for the analysis. Even better would be to remove the redundant definition and invocation of test_dump, like this (imitating b3e5bce, vcs-svn: Error out for v3 dumps, 2010-11-17): --- diff --git a/t/t9010-svn-fe.sh b/t/t9010-svn-fe.sh index 6e3b6ad..d207aeb 100755 --- a/t/t9010-svn-fe.sh +++ b/t/t9010-svn-fe.sh @@ -14,31 +14,6 @@ svn_cmd () { svn "$subcommand" --config-dir "$svnconf" "$@" } -test_dump () { - label=$1 - dump=$2 - test_expect_success "$dump" ' - svnadmin create "$label-svn" && - svnadmin load "$label-svn" < "$TEST_DIRECTORY/$dump" && - svn_cmd export "file://$PWD/$label-svn" "$label-svnco" && - git init "$label-git" && - test-svn-fe "$TEST_DIRECTORY/$dump" >"$label.fe" && - ( - cd "$label-git" && - git fast-import < ../"$label.fe" - ) && - ( - cd "$label-svnco" && - git init && - git add . && - git fetch "../$label-git" master && - git diff --exit-code FETCH_HEAD - ) - ' -} - -test_dump simple t9135/svn.dump - reinit_git () { rm -fr .git && git init ^ permalink raw reply related [flat|nested] 27+ messages in thread
end of thread, other threads:[~2010-12-10 22:00 UTC | newest] Thread overview: 27+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-12-05 6:30 What's cooking in git.git (Dec 2010, #01; Sat, 4) Junio C Hamano 2010-12-05 7:39 ` Jeff King 2010-12-05 19:54 ` Junio C Hamano 2010-12-06 0:54 ` aleksi.aalto 2010-12-09 17:27 ` Jeff King 2010-12-10 19:55 ` Junio C Hamano 2010-12-05 10:13 ` Yann Dirson 2010-12-05 20:23 ` Junio C Hamano 2010-12-06 7:29 ` Yann Dirson 2010-12-06 8:13 ` Miles Bader 2010-12-06 8:21 ` Yann Dirson 2010-12-06 8:39 ` Miles Bader 2010-12-06 8:48 ` Yann Dirson 2010-12-06 9:13 ` Miles Bader 2010-12-06 11:31 ` Yann Dirson 2010-12-06 11:37 ` Matthieu Moy 2010-12-10 21:59 ` Junio C Hamano 2010-12-05 12:36 ` aleksi.aalto 2010-12-05 15:51 ` Patrick Rouleau 2010-12-05 13:00 ` Erik Faye-Lund 2010-12-05 20:15 ` Junio C Hamano 2010-12-05 15:00 ` Michael J Gruber 2010-12-05 20:06 ` Junio C Hamano 2010-12-06 8:55 ` Michael J Gruber 2010-12-06 15:39 ` Thiago Farina 2010-12-08 11:23 ` t9010 broken in pu [Re: What's cooking in git.git (Dec 2010, #01; Sat, 4)] Thomas Rast 2010-12-08 11:28 ` Jonathan Nieder
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git 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 read-only IMAP folder(s) and NNTP newsgroup(s).