{"thread":{"id":"33977","subject":"What's cooking in git.git (May 2013, #09; Wed, 29)","startedAt":"2013-05-29T23:58:00Z","lastAt":"2013-07-01T22:05:12Z","messageCount":23,"participants":["Junio C Hamano","Thomas Rast","Ramkumar Ramachandra","Jens Lehmann","Øystein Walle","John Keeping","Heiko Voigt","Phil Hord"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"218910","messageId":"7va9ndqqyf.fsf@alter.siamese.dyndns.org","threadId":"33977","inReplyTo":null,"subject":"What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-29T23:58:00Z","receivedAt":"2013-05-29T23:58:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed with\n'-' are only in 'pu' (proposed updates) while commits prefixed with\n'+' are in 'next'.\n\nUsually I avoid issuing \"What's cooking\" back-to-back, but because I\nwill be offline for a few days, here is a snapshot of tonight's\nstatus.\n\nSome topics that have been cooking in 'next' from the previous cycle\nhave now graduated to 'master', so the RelNotes have been updated.\n\nNothing new in 'next', and it has not been rewound yet, which will\nhopefully happen this weekend, and after that post 1.8.3 cycle\nreally starts.\n\nAlso a rather serious regression on path-exclusion logic (most\nnotably seen in .gitignore) has been found and quickly patched (it\nhasn't been merged to 'master' yet, though).\n\nYou can find the changes described here in the integration branches\nof the repositories listed at\n\n    http://git-blame.blogspot.com/p/git-public-repositories.html\n\n--------------------------------------------------\n[Graduated to \"master\"]\n\n* as/check-ignore (2013-04-29) 6 commits\n  (merged to 'next' on 2013-04-30 at 646931f)\n + t0008: use named pipe (FIFO) to test check-ignore streaming\n  (merged to 'next' on 2013-04-21 at 7515aa8)\n + Documentation: add caveats about I/O buffering for check-{attr,ignore}\n + check-ignore: allow incremental streaming of queries via --stdin\n + check-ignore: move setup into cmd_check_ignore()\n + check-ignore: add -n / --non-matching option\n + t0008: remove duplicated test fixture data\n\n Enhance \"check-ignore\" (1.8.2 update) to work more like \"check-attr\"\n over bidi-pipes.\n\n\n* fc/transport-helper-error-reporting (2013-05-10) 12 commits\n  (merged to 'next' on 2013-05-10 at 2a9af4b)\n + transport-helper: fix remote helper namespace regression\n + test: remote-helper: add missing and\n  (merged to 'next' on 2013-04-25 at 3358f1a)\n + t5801: \"VAR=VAL shell_func args\" is forbidden\n  (merged to 'next' on 2013-04-22 at 5ba6467)\n + transport-helper: update remote helper namespace\n + transport-helper: trivial code shuffle\n + transport-helper: warn when refspec is not used\n + transport-helper: clarify pushing without refspecs\n + transport-helper: update refspec documentation\n + transport-helper: clarify *:* refspec\n + transport-helper: improve push messages\n + transport-helper: mention helper name when it dies\n + transport-helper: report errors properly\n (this branch is tangled with js/transport-helper-error-reporting-fix.)\n\n Update transport helper to report errors and maintain ref hierarchy\n used to keep track of remote helper state better.\n\n\n* jc/prune-all (2013-04-25) 4 commits\n  (merged to 'next' on 2013-04-26 at 97a7387)\n + prune: introduce OPT_EXPIRY_DATE() and use it\n  (merged to 'next' on 2013-04-22 at b00ccf6)\n + api-parse-options.txt: document \"no-\" for non-boolean options\n + git-gc.txt, git-reflog.txt: document new expiry options\n + date.c: add parse_expiry_date()\n (this branch is used by mh/packed-refs-various.)\n\n We used the approxidate() parser for \"--expire=<timestamp>\" options\n of various commands, but it is better to treat --expire=all and\n --expire=now a bit more specially than using the current timestamp.\n Update \"git gc\" and \"git reflog\" with a new parsing function for\n expiry dates.\n\n\n* jh/checkout-auto-tracking (2013-04-21) 8 commits\n  (merged to 'next' on 2013-04-22 at 2356700)\n + glossary: Update and rephrase the definition of a remote-tracking branch\n + branch.c: Validate tracking branches with refspecs instead of refs/remotes/*\n + t9114.2: Don't use --track option against \"svn-remote\"-tracking branches\n + t7201.24: Add refspec to keep --track working\n + t3200.39: tracking setup should fail if there is no matching refspec.\n + checkout: Use remote refspecs when DWIMming tracking branches\n + t2024: Show failure to use refspec when DWIMming remote branch names\n + t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'\n\n Updates \"git checkout foo\" that DWIMs the intended \"upstream\" and\n turns it into \"git checkout -t -b foo remotes/origin/foo\" to\n correctly take existing remote definitions into account.  The\n remote \"origin\" may be what uniquely map its own branch to\n remotes/some/where/foo but that some/where may not be \"origin\".\n\n\n* jk/lookup-object-prefer-latest (2013-05-02) 1 commit\n  (merged to 'next' on 2013-05-06 at cc59dcc)\n + lookup_object: prioritize recently found objects\n\n Optimizes object lookup when the object hashtable starts to become\n crowded.\n\n\n* jk/subtree-do-not-push-if-split-fails (2013-05-01) 1 commit\n  (merged to 'next' on 2013-05-06 at 81bdf37)\n + contrib/subtree: don't delete remote branches if split fails\n\n \"git subtree\" (in contrib/) had one codepath with loose error\n checks to lose data at the remote side.\n\n\n* jk/test-output (2013-05-06) 3 commits\n  (merged to 'next' on 2013-05-06 at 7c03af3)\n + t/Makefile: don't define TEST_RESULTS_DIRECTORY recursively\n  (merged to 'next' on 2013-05-01 at 63827c9)\n + test output: respect $TEST_OUTPUT_DIRECTORY\n + t/Makefile: fix result handling with TEST_OUTPUT_DIRECTORY\n\n When TEST_OUTPUT_DIRECTORY setting is used, it was handled somewhat\n inconsistently between the test framework and t/Makefile, and logic\n to summarize the results looked at a wrong place.\n\n\n* jn/config-ignore-inaccessible (2013-04-15) 1 commit\n  (merged to 'next' on 2013-05-07 at 4f09e24)\n + config: allow inaccessible configuration under $HOME\n\n When $HOME is misconfigured to point at an unreadable directory, we\n used to complain and die. This loosens the check.\n\n\n* js/transport-helper-error-reporting-fix (2013-04-28) 13 commits\n  (merged to 'next' on 2013-04-29 at 8cc4bb8)\n + git-remote-testgit: build it to run under $SHELL_PATH\n + git-remote-testgit: further remove some bashisms\n + git-remote-testgit: avoid process substitution\n  (merged to 'next' on 2013-04-25 at 3358f1a)\n + t5801: \"VAR=VAL shell_func args\" is forbidden\n  (merged to 'next' on 2013-04-22 at 5ba6467)\n + transport-helper: update remote helper namespace\n + transport-helper: trivial code shuffle\n + transport-helper: warn when refspec is not used\n + transport-helper: clarify pushing without refspecs\n + transport-helper: update refspec documentation\n + transport-helper: clarify *:* refspec\n + transport-helper: improve push messages\n + transport-helper: mention helper name when it dies\n + transport-helper: report errors properly\n (this branch is tangled with fc/transport-helper-error-reporting.)\n\n Finishing touches to fc/transport-helper-error-reporting topic.\n\n\n* mh/fetch-into-shallow (2013-05-02) 2 commits\n  (merged to 'next' on 2013-05-03 at 3fadc61)\n + t5500: add test for fetching with an unknown 'shallow'\n  (merged to 'next' on 2013-04-29 at a167d3e)\n + upload-pack: ignore 'shallow' lines with unknown obj-ids\n\n\n* mh/packed-refs-various (2013-05-01) 33 commits\n  (merged to 'next' on 2013-05-01 at e527153)\n + refs: handle the main ref_cache specially\n + refs: change do_for_each_*() functions to take ref_cache arguments\n + pack_one_ref(): do some cheap tests before a more expensive one\n + pack_one_ref(): use write_packed_entry() to do the writing\n + pack_one_ref(): use function peel_entry()\n + refs: inline function do_not_prune()\n + pack_refs(): change to use do_for_each_entry()\n + refs: use same lock_file object for both ref-packing functions\n + pack_one_ref(): rename \"path\" parameter to \"refname\"\n + pack-refs: merge code from pack-refs.{c,h} into refs.{c,h}\n + pack-refs: rename handle_one_ref() to pack_one_ref()\n + refs: extract a function write_packed_entry()\n + repack_without_ref(): write peeled refs in the rewritten file\n + t3211: demonstrate loss of peeled refs if a packed ref is deleted\n + refs: change how packed refs are deleted\n + search_ref_dir(): return an index rather than a pointer\n + repack_without_ref(): silence errors for dangling packed refs\n + t3210: test for spurious error messages for dangling packed refs\n + refs: change the internal reference-iteration API\n + refs: extract a function peel_entry()\n + peel_ref(): fix return value for non-peelable, not-current reference\n + peel_object(): give more specific information in return value\n + refs: extract function peel_object()\n + refs: extract a function ref_resolves_to_object()\n + repack_without_ref(): use function get_packed_ref()\n + peel_ref(): use function get_packed_ref()\n + get_packed_ref(): return a ref_entry\n + do_for_each_ref_in_dirs(): remove dead code\n + refs: define constant PEELED_LINE_LENGTH\n + refs: document how current_ref is used\n + refs: document do_for_each_ref() and do_one_ref()\n + refs: document the fields of struct ref_value\n + refs: document flags constants REF_*\n (this branch uses jc/prune-all.)\n\n Updates reading and updating packed-refs file, correcting corner\n case bugs.\n\n\n* rj/sparse (2013-04-28) 10 commits\n  (merged to 'next' on 2013-05-01 at 649e16c)\n + sparse: Fix mingw_main() argument number/type errors\n + compat/mingw.c: Fix some sparse warnings\n + compat/win32mmap.c: Fix some sparse warnings\n + compat/poll/poll.c: Fix a sparse warning\n + compat/win32/pthread.c: Fix a sparse warning\n + compat/unsetenv.c: Fix a sparse warning\n + compat/nedmalloc: Fix compiler warnings on linux\n + compat/nedmalloc: Fix some sparse warnings\n + compat/fnmatch/fnmatch.c: Fix a sparse error\n + compat/regex/regexec.c: Fix some sparse warnings\n\n--------------------------------------------------\n[New Topics]\n\n* ap/diff-ignore-blank-lines (2013-05-29) 1 commit\n - diff: add --ignore-blank-lines option\n\n \"git diff\" learned a mode that ignores hunks whose change consists\n only of additions and removals of blank lines, which is the same as\n \"diff -B\" (ignore blank lines) of GNU diff.\n\n\n* fc/show-branch-in-rebase-am (2013-05-29) 1 commit\n - prompt: fix for simple rebase\n\n The bash prompt code (in contrib/) displayed the name of the branch\n being rebased when \"rebase -i/-m/-p\" modes are in use, but not the\n plain vanilla \"rebase\".\n\n Will merge to 'next'.\n\n\n* kb/status-ignored-optim-2 (2013-05-29) 1 commit\n - dir.c: fix ignore processing within not-ignored directories\n\n Fix 1.8.3 regressions in the .gitignore path exclusion logic.\n\n\n* ks/difftool-dir-diff-copy-fix (2013-05-29) 1 commit\n - difftool --dir-diff: allow changing any clean working tree file\n\n \"difftool --dir-diff\" did not copy back changes made by the\n end-user in the diff tool backend to the working tree in some\n cases.\n\n\n* rr/push-head (2013-05-29) 3 commits\n - push: make push.default = current use resolved HEAD\n - push: fail early with detached HEAD and current\n - push: factor out the detached HEAD error message\n\n \"git push $there HEAD:branch\" did not resolve HEAD early enough, so\n it was easy to flip it around while push is still going on and push\n out a branch that the user did not originally intended when the\n command was started.\n\n Will merge to 'next'.\n\n\n* sb/archive-zip-double-assignment-fix (2013-05-29) 1 commit\n - archive-zip:write_zip_entry: Remove second reset of size variable to zero.\n\n Will merge to 'next'.\n\n--------------------------------------------------\n[Stalled]\n\n* mg/more-textconv (2013-05-10) 7 commits\n  (merged to 'next' on 2013-05-21 at 701cdb7)\n + grep: honor --textconv for the case rev:path\n + grep: allow to use textconv filters\n + t7008: demonstrate behavior of grep with textconv\n + cat-file: do not die on --textconv without textconv filters\n + show: honor --textconv for blobs\n + diff_opt: track whether flags have been set explicitly\n + t4030: demonstrate behavior of show with textconv\n\n Make \"git grep\" and \"git show\" pay attention to --textconv when\n dealing with blob objects.\n\n I thought this was pretty well designed and executed, but it seems\n there are some doubts on the list.\n\n\n* mh/multimail (2013-04-21) 1 commit\n - git-multimail: a replacement for post-receive-email\n\n Waiting for the initial history to pull from.\n $gmane/223564\n\n\n* jc/format-patch (2013-04-22) 2 commits\n - format-patch: --inline-single\n - format-patch: rename \"no_inline\" field\n\n A new option to send a single patch to the standard output to be\n appended at the bottom of a message.  I personally have no need for\n this, but it was easy enough to cobble together.  Tests, docs and\n stripping out more MIMEy stuff are left as exercises to interested\n parties.\n\n Not ready for inclusion.\n\n Will discard unless we hear from anybody who is interested in\n tying its loose ends.\n\n\n* jk/gitweb-utf8 (2013-04-08) 4 commits\n - gitweb: Fix broken blob action parameters on blob/commitdiff pages\n - gitweb: Don't append ';js=(0|1)' to external links\n - gitweb: Make feed title valid utf8\n - gitweb: Fix utf8 encoding for blob_plain, blobdiff_plain, commitdiff_plain, and patch\n\n Various fixes to gitweb.\n\n Waiting for a reroll after a review.\n Will discard unless we hear from anybody who is interested in\n tying its loose ends.\n\n* jk/commit-info-slab (2013-04-19) 3 commits\n - commit-slab: introduce a macro to define a slab for new type\n - commit-slab: avoid large realloc\n - commit: allow associating auxiliary info on-demand\n (this branch is used by jc/show-branch.)\n\n Technology demonstration to show a way we could use unbound number\n of flag bits on commit objects.\n\n--------------------------------------------------\n[Cooking]\n\n* rj/mingw-cygwin (2013-05-08) 2 commits\n - cygwin: Remove the CYGWIN_V15_WIN32API build variable\n - mingw: rename WIN32 cpp macro to GIT_WINDOWS_NATIVE\n\n Update build for Cygwin 1.[57].  Torsten Bögershausen reports that\n this is fine with Cygwin 1.7 ($gmane/225824) so let's try moving it\n ahead.\n \n Will merge to 'next'.\n\n\n* rr/rebase-autostash (2013-05-29) 7 commits\n - rebase: implement --[no-]autostash and rebase.autostash\n - rebase --merge: return control to caller, for housekeeping\n - rebase -i: return control to caller, for housekeeping\n - am: return control to caller, for housekeeping\n - rebase: prepare to do generic housekeeping\n - rebase -i: don't error out if $state_dir already exists\n - am: tighten a conditional that checks for $dotest\n\n Will merge to 'next'.\n\n\n* nd/urls-doc-no-file-hyperlink-fix (2013-05-24) 1 commit\n - urls.txt: avoid auto converting to hyperlink\n\n Will merge to 'next'.\n\n\n* cb/log-follow-with-combined (2013-05-28) 1 commit\n - fix segfault with git log -c --follow\n\n Will merge to 'next'.\n\n\n* fc/cleanups (2013-05-28) 3 commits\n - test: rebase: fix --interactive test\n - test: trivial cleanups\n - remote: trivial style cleanup\n\n Will merge to 'next'.\n\n\n* fc/makefile (2013-05-26) 5 commits\n - build: do not install git-remote-testpy\n - build: add NO_INSTALL variable\n - build: cleanup using $<\n - build: cleanup using $^\n - build: trivial simplification\n (this branch is used by fc/remote-helpers-use-specified-python.)\n\n Will merge to 'next'.\n\n\n* fc/remote-helpers-use-specified-python (2013-05-28) 4 commits\n - remote-helpers: add exec-path links\n - remote-helpers: allow direct test execution\n - remote-helpers: rename tests\n - remote-helpers: generate scripts\n (this branch uses fc/makefile.)\n\n I do not particularly think the second from the bottom is a good\n change, but it takes the remainder of the series hostage.\n Will hopefully be rerolled without it.\n\n\n* fc/send-email-chainreplyto-warning (2013-05-28) 1 commit\n - send-email: remove warning about unset chainreplyto\n\n An overdue removal od \"behaviour changed at 1.7.0; if you were\n living in a cave, here is what you can adjust to it\" message.\n\n Will merge to 'next'.\n\n\n* ks/difftool-dirdiff-copy-all (2013-05-28) 1 commit\n - difftool --dir-diff: always use identical working tree file\n\n \"difftool --dir-diff\" populates a temporary directory with files,\n inviting the user to modify them in place, but in some cases we\n weren't expecting the user to modify them and did not take the\n change back to the working tree.\n\n Will merge to 'next'.\n\n\n* nd/prune-packed-dryrun-verbose (2013-05-28) 1 commit\n - prune-packed: avoid implying \"1\" is DRY_RUN in prune_packed_objects()\n\n Will merge to 'next'.\n\n\n* rj/mingw-compat-st-mode-bits (2013-05-28) 1 commit\n - path: Fix a sparse warning\n\n Will merge to 'next'.\n\n\n* rs/commit-m-no-edit (2013-05-28) 1 commit\n - commit: don't start editor if empty message is given with -m\n\n Will merge to 'next'.\n\n\n* xq/credential-osxkeychain (2013-05-28) 1 commit\n - credential-osxkeychain: support more protocols\n\n Will merge to 'next'.\n\n\n* jc/core-checkstat (2013-05-06) 1 commit\n - deprecate core.statinfo at Git 2.0 boundary\n (this branch is used by jc/core-checkstat-2.0.)\n\n Will merge to 'next'.\n\n\n* tr/line-log (2013-04-22) 13 commits\n  (merged to 'next' on 2013-04-22 at 8f2c1de)\n + git-log(1): remove --full-line-diff description\n  (merged to 'next' on 2013-04-21 at cd92620)\n + line-log: fix documentation formatting\n  (merged to 'next' on 2013-04-15 at 504559e)\n + log -L: improve comments in process_all_files()\n + log -L: store the path instead of a diff_filespec\n + log -L: test merge of parallel modify/rename\n + t4211: pass -M to 'git log -M -L...' test\n  (merged to 'next' on 2013-04-05 at 5afb00c)\n + log -L: fix overlapping input ranges\n + log -L: check range set invariants when we look it up\n  (merged to 'next' on 2013-04-01 at 5be920c)\n + Speed up log -L... -M\n + log -L: :pattern:file syntax to find by funcname\n + Implement line-history search (git log -L)\n + Export rewrite_parents() for 'log -L'\n + Refactor parse_loc\n\n Will merge to 'master'.\n\n\n* mh/reflife (2013-05-28) 25 commits\n - refs: document the lifetime of the args passed to each_ref_fn\n - register_ref(): make a copy of the bad reference SHA-1\n - exclude_existing(): set existing_refs.strdup_strings\n - string_list_add_refs_by_glob(): add a comment about memory management\n - string_list_add_one_ref(): rename first parameter to \"refname\"\n - show_head_ref(): rename first parameter to \"refname\"\n - show_head_ref(): do not shadow name of argument\n - add_existing(): do not retain a reference to sha1\n - do_fetch(): clean up existing_refs before exiting\n - do_fetch(): reduce scope of peer_item\n - object_array_entry: fix memory handling of the name field\n - find_first_merges(): remove unnecessary code\n - find_first_merges(): initialize merges variable using initializer\n - fsck: don't put a void*-shaped peg in a char*-shaped hole\n - object_array_remove_duplicates(): rewrite to reduce copying\n - revision: use object_array_filter() in implementation of gc_boundary()\n - object_array: add function object_array_filter()\n - revision: split some overly-long lines\n - cmd_diff(): make it obvious which cases are exclusive of each other\n - cmd_diff(): rename local variable \"list\" -> \"entry\"\n - cmd_diff(): use an object_array for holding trees\n - builtin_diff_tree(): make it obvious that function wants two entries\n - add_rev_cmdline(): make a copy of the name argument\n - fetch: make own copies of refnames\n - describe: make own copy of refname\n\n Define memory ownership and lifetime rules for what for-each-ref\n feeds to its callbacks (in short, \"you do not own it, so make a\n copy if you want to keep it\").\n\n Will merge to 'next'.\n\n\n* th/bisect-skip-report-range-fix (2013-05-22) 1 commit\n - bisect: Fix log output for multi-parent skip ranges\n\n Fix for an additional bisect log comments.\n\n Will merge to 'next'.\n\n\n* mm/mediawiki-https-fail-message (2013-05-29) 1 commit\n - git-remote-mediawiki: better error message when HTTP(S) access fails\n\n Hint users when https:// connection failed to check the\n certificate; it is a good hint if we assumie that it is common\n error for the end users to make.\n\n Will merge to 'next'.\n\n\n* tg/maint-zsh-svn-remote-prompt (2013-05-22) 1 commit\n - prompt: fix show upstream with svn and zsh\n\n zsh prompt script that borrowed from bash prompt script did not\n work due to slight differences in array variable notation between\n these two shells.\n\n Will merge to 'next'.\n\n\n* tr/push-no-verify-doc (2013-05-23) 1 commit\n - Document push --no-verify\n\n \"git push --[no-]verify\" was not documented.\n\n Will merge to 'next'.\n\n\n* dm/unbash-subtree (2013-05-21) 1 commit\n - contrib/git-subtree: Use /bin/sh interpreter instead of /bin/bash\n\n It turns out that git-subtree script does not have to be run with\n bash.\n\n Will merge to 'next'.\n\n\n* fc/transport-helper-no-refspec (2013-05-21) 2 commits\n - transport-helper: check if the dry-run is supported\n - transport-helper: barf when user tries old:new\n\n With \"export\" remote-helper protocol, (1) a push that tries to\n update a remote ref whose name is different from the pushing side\n does not work yet, and (2) the helper may not know how to do\n --dry-run, so detect such problematic cases and disable them for\n now.\n\n Will merge to 'next'.\n\n\n* rr/die-on-missing-upstream (2013-05-22) 2 commits\n - sha1_name: fix error message for @{<N>}, @{<date>}\n - sha1_name: fix error message for @{u}\n\n When a reflog notation is used for implicit \"current branch\", we\n did not say which branch and worse said \"branch ''\".\n\n Will merge to 'next'.\n\n\n* jc/show-branch (2013-05-21) 5 commits\n - show-branch: use commit slab to represent bitflags of arbitrary width\n - show-branch.c: remove \"all_mask\"\n - show-branch.c: abstract out \"flags\" operation\n - show-branch.c: lift all_mask/all_revs to a global static\n - show-branch.c: update comment style\n (this branch uses jk/commit-info-slab.)\n\n Waiting for the final step to lift the hard-limit before sending it out.\n\n\n* fc/remote-bzr (2013-05-28) 8 commits\n - remote-bzr: add fallback check for a partial clone\n - remote-bzr: reorganize the way 'wanted' works\n - remote-bzr: trivial cleanups\n - remote-bzr: change global repo\n - remote-bzr: delay cloning/pulling\n - remote-bzr: simplify get_remote_branch()\n - remote-bzr: fix for files with spaces\n - remote-bzr: recover from failed clones\n\n Will merge to 'next'.\n\n\n* jx/clean-interactive (2013-05-22) 15 commits\n - test: add t7301 for git-clean--interactive\n - git-clean: add documentation for interactive git-clean\n - git-clean: add ask each interactive action\n - git-clean: add select by numbers interactive action\n - git-clean: add filter by pattern interactive action\n - git-clean: use a git-add-interactive compatible UI\n - git-clean: add colors to interactive git-clean\n - git-clean: show items of del_list in columns\n - git-clean: add support for -i/--interactive\n - git-clean: refactor git-clean into two phases\n - Refactor write_name_quoted_relative, remove unused params\n - Refactor quote_path_relative, remove unused params\n - quote.c: remove path_relative, use relative_path instead\n - path.c: refactor relative_path(), not only strip prefix\n - test: add test cases for relative_path\n\n Still under discussion, e.g. $gmane/225139.\n\n\n* tr/test-v-and-v-subtest-only (2013-05-16) 6 commits\n - test-lib: support running tests under valgrind in parallel\n - test-lib: allow prefixing a custom string before \"ok N\" etc.\n - test-lib: valgrind for only tests matching a pattern\n - test-lib: verbose mode for only tests matching a pattern\n - test-lib: refactor $GIT_SKIP_TESTS matching\n - test-lib: enable MALLOC_* for the actual tests\n\n Allows N instances of tests run in parallel, each running 1/N parts\n of the test suite under Valgrind, to speed things up.\n\n The tip one may be useful in practice but is a tad ugly ;-)\n\n There seem to be some miscounting by toggling the verbose/valgrind\n mode at wrong places?  Cf. $gmane/225735\n\n\n* rh/merge-options-doc-fix (2013-05-16) 1 commit\n  (merged to 'next' on 2013-05-21 at f76baf3)\n + Documentation/merge-options.txt: restore `-e` option\n\n Will merge to 'master'.\n\n\n* rr/zsh-color-prompt (2013-05-17) 3 commits\n - prompt: colorize ZSH prompt\n - prompt: factor out gitstring coloring logic\n - prompt: introduce GIT_PS1_STATESEPARATOR\n\n Will merge to 'next'.\n\n\n* an/diff-index-doc (2013-05-20) 1 commit\n  (merged to 'next' on 2013-05-21 at 6e1459b)\n + Documentation/diff-index: mention two modes of operation\n\n Will merge to 'master'.\n\n\n* fc/contrib-related (2013-05-20) 1 commit\n - Add new git-related helper to contrib\n\n Waiting the design review for this earliest part to settle.\n\n\n* mc/describe-first-parent (2013-05-20) 1 commit\n  (merged to 'next' on 2013-05-21 at 2e02ffc)\n + describe: Add --first-parent option\n\n Will merge to 'master'.\n\n\n* rs/tar-tests (2013-05-20) 6 commits\n  (merged to 'next' on 2013-05-21 at aed12a7)\n + t5000: test long filenames\n + t5000: simplify tar-tree tests\n + t5000: use check_tar for prefix test\n + t5000: factor out check_tar\n + t5000, t5003: create directories for extracted files lazily\n + t5000: integrate export-subst tests into regular tests\n\n Will merge to 'master'.\n\n\n* da/darwin (2013-05-21) 4 commits\n  (merged to 'next' on 2013-05-21 at 0497edb)\n + imap-send: eliminate HMAC deprecation warnings on Mac OS X\n + cache.h: eliminate SHA-1 deprecation warnings on Mac OS X\n + Makefile: add support for Apple CommonCrypto facility\n + Makefile: fix default regex settings on Darwin\n\n Newer MacOS X encourages the programs to compile and link with\n their CommonCrypto, not with OpenSSL.\n\n Will merge to 'master'.\n\n\n* fc/macos-x-clipped-write (2013-05-17) 1 commit\n  (merged to 'next' on 2013-05-21 at 510b0dd)\n + compate/clipped-write.c: large write(2) fails on Mac OS X/XNU\n\n Mac OS X does not like to write(2) more than INT_MAX number of\n bytes.\n\n Will merge to 'master'.\n\n\n* fc/remote-hg (2013-05-28) 50 commits\n - remote-hg: add support for --force\n - remote-hg: add support for --dry-run\n - remote-hg: check if a fetch is needed\n - remote-hg: trivial cleanup\n - remote-helpers: improve marks usage\n - remote-hg: add check_push() helper\n - remote-hg: add setup_big_push() helper\n - remote-hg: remove files before modifications\n - remote-hg: improve lightweight tag author\n - remote-hg: use remote 'default' not local one\n - remote-hg: improve branch listing\n - remote-hg: simplify branch_tip()\n - remote-hg: check diverged bookmarks\n - remote-hg: pass around revision refs\n - remote-hg: implement custom checkheads()\n - remote-hg: implement custom push()\n - remote-hg: only update necessary revisions\n - remote-hg: force remote bookmark push selectively\n - remote-hg: reorganize bookmark handling\n - remote-hg: add test for failed double push\n - remote-hg: add test for big push\n - remote-hg: add test for new bookmark special\n - remote-hg: add test for bookmark diverge\n - remote-hg: add test for diverged push\n - remote-hg: add test to push new bookmark\n - remote-hg: add remote tests\n - remote-hg: update bookmarks when using a remote\n - remote-hg: add check_bookmark() test helper\n - remote-bzr: simplify test checks\n - remote-hg: add tests for 'master' bookmark\n - remote-hg: always point HEAD to master\n - remote-hg: improve progress calculation\n - remote-hg: trivial cleanups\n - remote-hg: ensure remote rebasing works\n - remote-hg: upgrade version 1 marks\n - remote-hg: switch from revisions to SHA-1 noteids\n - remote-hg: add version checks to the marks\n - remote-hg: improve node traversing\n - remote-hg: shuffle some code\n - remote-hg: use a shared repository store\n - remote-hg: load all extensions\n - remote-hg: test: simplify previous branch checkout\n - remote-helpers: test: simplify remote URLs\n - remote-helpers: tests: general improvements\n - remote-helpers: test: cleanup style\n - remote-helpers: test: cleanup white-spaces\n - remote-hg: trivial reorganization\n - remote-hg: test: be a little more quiet\n - remote-hg: tests: fix hg merge\n - remote-helpers: tests: use python directly\n\n Will merge to 'next'.\n\n\n* hv/config-from-blob (2013-05-12) 5 commits\n - do not die when error in config parsing of buf occurs\n - teach config --blob option to parse config from database\n - config: make parsing stack struct independent from actual data source\n - config: drop cf validity check in get_next_char()\n - config: factor out config file stack management\n\n Will see a resubmit.\n $gmane/223964\n\n\n* jc/t5551-posix-sed-bre (2013-05-12) 1 commit\n  (merged to 'next' on 2013-05-21 at d597ca1)\n + t5551: do not use unportable sed '\\+'\n\n POSIX fix for a test script.\n\n Will merge to 'master'.\n\n\n* jk/fetch-always-update-tracking (2013-05-28) 5 commits\n  (merged to 'next' on 2013-05-28 at c6abf3f)\n + fetch: don't try to update unfetched tracking refs\n  (merged to 'next' on 2013-05-21 at f7e4b16)\n + fetch: opportunistically update tracking refs\n + refactor \"ref->merge\" flag\n + fetch/pull doc: untangle meaning of bare <ref>\n + t5510: start tracking-ref tests from a known state\n\n \"git fetch origin master\" unlike \"git fetch origin\" or \"git fetch\"\n does not update \"refs/remotes/origin/master\" and it was an early\n design decision to keep the update of remote tracking branches\n predictable, but in practice it turns out that people find it more\n convenient to opportunisticly update them whenever we have a\n chance, and we have been updating them when we run \"git push\" which\n already breaks the original \"predictability\" anyway.\n\n Will merge to 'master'.\n\n\n* nd/clone-connectivity-shortcut (2013-05-28) 4 commits\n - clone: open a shortcut for connectivity check\n - index-pack: remove dead code (it should never happen)\n - fetch-pack: prepare updated shallow file before fetching the pack\n - clone: let the user know when check_everything_connected is run\n\n Will merge to 'next'.\n\n\n* kb/ancestry-path-threedots (2013-05-16) 2 commits\n  (merged to 'next' on 2013-05-21 at 5d75bd3)\n + revision.c: treat A...B merge bases as if manually specified\n + t6019: demonstrate --ancestry-path A...B breakage\n (this branch is used by kb/full-history-compute-treesame-carefully-2.)\n\n \"git log --ancestry-path A...B\" did not work as expected, as it did\n not pay attention to the fact that the merge base between A and B\n was the bottom of the range being specified.\n\n Will merge to 'master'.\n\n\n* kb/full-history-compute-treesame-carefully-2 (2013-05-16) 15 commits\n - revision.c: make default history consider bottom commits\n - revision.c: don't show all merges for --parents\n - revision.c: discount side branches when computing TREESAME\n - revision.c: add BOTTOM flag for commits\n - simplify-merges: drop merge from irrelevant side branch\n - simplify-merges: never remove all TREESAME parents\n - t6012: update test for tweaked full-history traversal\n - revision.c: Make --full-history consider more merges\n - Documentation: avoid \"uninteresting\"\n - rev-list-options.txt: correct TREESAME for P\n - t6111: add parents to tests\n - t6111: allow checking the parents as well\n - t6111: new TREESAME test set\n - t6019: test file dropped in -s ours merge\n - decorate.c: compact table when growing\n (this branch uses kb/ancestry-path-threedots.)\n\n Major update to a very core part of the system to improve culling\n of irrelevant parents while traversing a mergy history.\n\n Will not be a 1.8.3 material, but is an important topic.\n\n Will merge to 'next'.\n\n\n* jc/strbuf-branchname-fix (2013-05-16) 1 commit\n  (merged to 'next' on 2013-05-21 at 5db8872)\n + strbuf_branchname(): do not double-expand @{-1}~22\n\n \"git merge @{-1}~22\" was rewritten to \"git merge frotz@{1}~22\"\n incorrectly when your previous branch was \"frotz\" (it should be\n rewritten to \"git merge frotz~22\" instead).\n\n Will merge to 'master'.\n\n\n* mk/combine-diff-context-horizon-fix (2013-05-15) 1 commit\n  (merged to 'next' on 2013-05-21 at f462c02)\n + combine-diff.c: Fix output when changes are exactly 3 lines apart\n\n \"git diff -c -p\" was not showing a deleted line from a hunk when\n another hunk immediately begins where the earlier one ends.\n\n Will merge to 'master'.\n\n\n* mm/color-auto-default (2013-05-15) 2 commits\n - make color.ui default to 'auto'\n - config: refactor management of color.ui's default value\n\n Flip the default for color.ui to 'auto', which is what many\n tutorials recommend new users to do.  The updated code claims the\n switch happened at Git 2.0 in the past tense, but we might want to\n expedite it, as this change is not all that important to deserve a\n major version bump.\n\n I'd vote for merging this without waiting for 2.0.  Comments?\n Waiting for a reroll.\n\n\n* tr/coverage (2013-05-13) 4 commits\n  (merged to 'next' on 2013-05-21 at 8480007)\n + coverage: build coverage-untested-functions by default\n + coverage: set DEFAULT_TEST_TARGET to avoid using prove\n + coverage: do not delete .gcno files before building\n + coverage: split build target into compile and test\n\n Update the test coverage support that was left to bitrot for some\n time.\n\n Will merge to 'master'.\n\n\n* jh/shorten-refname (2013-05-07) 4 commits\n - t1514: refname shortening is done after dereferencing symbolic refs\n - shorten_unambiguous_ref(): Fix shortening refs/remotes/origin/HEAD to origin\n - t1514: Demonstrate failure to correctly shorten \"refs/remotes/origin/HEAD\"\n - t1514: Add tests of shortening refnames in strict/loose mode\n\n When remotes/origin/HEAD is not a symbolic ref, \"rev-parse\n --abbrev-ref remotes/origin/HEAD\" ought to show \"origin\", not\n \"origin/HEAD\", which is fixed with this series (if it is a symbolic\n ref that points at remotes/origin/something, then it should show\n \"origin/something\" and it already does).\n\n Expecting a reroll, as an early part of a larger series.\n\n\n* nd/clone-local-with-colon (2013-05-07) 1 commit\n  (merged to 'next' on 2013-05-21 at 3e293bd)\n + clone: allow cloning local paths with colons in them\n\n \"git clone foo/bar:baz\" cannot be a request to clone from a remote\n over git-over-ssh specified in the scp style.  Detect this case and\n clone from a local repository at \"foo/bar:baz\".\n\n Will merge to 'master'.\n\n\n* nd/warn-ambiguous-object-name (2013-05-29) 1 commit\n - get_sha1: warn about full or short object names that look like refs\n\n \"git cmd <name>\", when <name> happens to be a 40-hex string,\n directly uses the 40-hex string as an object name, even if a ref\n \"refs/<some hierarchy>/<name>\" exists.  This disambiguation order\n is unlikely to change, but we should warn about the ambiguity just\n like we warn when more than one refs/ hierachies share the same\n name.\n\n\n* fc/zsh-leftover-bits (2013-05-29) 3 commits\n  (merged to 'next' on 2013-05-29 at b367b4e)\n + completion: zsh: improve bash script loading\n  (merged to 'next' on 2013-05-21 at 1b84ec1)\n + completion: synchronize zsh wrapper\n + completion: cleanup zsh wrapper\n\n Will merge to 'master'.\n\n\n* rs/empty-archive (2013-05-09) 2 commits\n  (merged to 'next' on 2013-05-21 at 3e9e288)\n + t5004: resurrect original empty tar archive test\n + t5004: avoid using tar for checking emptiness of archive\n\n Fixes tests added in 1.8.2 era that are broken on BSDs.\n\n Will merge to 'master'.\n\n\n* vv/help-unknown-ref (2013-05-08) 2 commits\n  (merged to 'next' on 2013-05-21 at 77a2941)\n + merge: use help_unknown_ref()\n + help: add help_unknown_ref()\n\n Detect \"git merge foo\" that might have meant \"git merge origin/foo\"\n and give an error message that is more specific than \"foo is not\n something we can merge\".\n\n Will merge to 'master'.\n\n\n* fc/fast-export-persistent-marks (2013-05-07) 3 commits\n  (merged to 'next' on 2013-05-21 at 10b8214)\n + fast-{import,export}: use get_sha1_hex() to read from marks file\n + fast-export: don't parse commits while reading marks file\n + fast-export: do not parse non-commit objects while reading marks file\n\n Optimization for fast-export by avoiding unnecessarily resolving\n arbitrary object name and parsing object when only presence and\n type information is necessary, etc.\n\n Will merge to 'master'.\n\n\n* jk/packed-refs-race (2013-05-06) 4 commits\n - for_each_ref: load all loose refs before packed refs\n - get_packed_refs: reload packed-refs file when it changes\n - add a stat_validity struct\n - resolve_ref: close race condition for packed refs\n\n What is the status of this thing?\n\n\n* fc/at-head (2013-05-08) 13 commits\n - sha1_name: compare variable with constant, not constant with variable\n - Add new @ shortcut for HEAD\n - sha1_name: refactor reinterpret()\n - sha1_name: check @{-N} errors sooner\n - sha1_name: reorganize get_sha1_basic()\n - sha1_name: don't waste cycles in the @-parsing loop\n - sha1_name: remove unnecessary braces\n - sha1_name: remove no-op\n - tests: at-combinations: @{N} versus HEAD@{N}\n - tests: at-combinations: increase coverage\n - tests: at-combinations: improve nonsense()\n - tests: at-combinations: check ref names directly\n - tests: at-combinations: simplify setup\n\n Instead of typing four capital letters \"HEAD\", you can say \"@\"\n instead.\n\n Will merge to 'next'.\n\n\n* fc/completion (2013-04-27) 9 commits\n  (merged to 'next' on 2013-05-21 at aba6ef1)\n + completion: remove __git_index_file_list_filter()\n + completion: add space after completed filename\n + completion: add hack to enable file mode in bash < 4\n + completion: refactor __git_complete_index_file()\n + completion: refactor diff_index wrappers\n + completion: use __gitcompadd for __gitcomp_file\n + completion; remove unuseful comments\n + completion: document tilde expansion failure in tests\n + completion: add file completion tests\n\n Will merge to 'master'.\n\n\n* jk/submodule-subdirectory-ok (2013-04-24) 3 commits\n  (merged to 'next' on 2013-04-24 at 6306b29)\n + submodule: fix quoting in relative_path()\n  (merged to 'next' on 2013-04-22 at f211e25)\n + submodule: drop the top-level requirement\n + rev-parse: add --prefix option\n\n Allow various subcommands of \"git submodule\" to be run not from the\n top of the working tree of the superproject.\n\n Will be commented by Jens.\n\n\n* jl/submodule-mv (2013-04-23) 5 commits\n  (merged to 'next' on 2013-04-23 at c04f574)\n + submodule.c: duplicate real_path's return value\n  (merged to 'next' on 2013-04-19 at 45ae3c9)\n + rm: delete .gitmodules entry of submodules removed from the work tree\n + Teach mv to update the path entry in .gitmodules for moved submodules\n + Teach mv to move submodules using a gitfile\n + Teach mv to move submodules together with their work trees\n\n \"git mv A B\" when moving a submodule A does \"the right thing\",\n inclusing relocating its working tree and adjusting the paths in\n the .gitmodules file.\n\n Will be commented by Jens.\n\n\n* jn/add-2.0-u-A-sans-pathspec (2013-04-26) 1 commit\n - git add: -u/-A now affects the entire working tree\n\n Will cook in 'next' until Git 2.0.\n\n\n* jc/core-checkstat-2.0 (2013-05-06) 1 commit\n - core.statinfo: remove as promised in Git 2.0\n (this branch uses jc/core-checkstat.)\n\n Will cook in 'next' until Git 2.0.\n\n\n* jc/push-2.0-default-to-simple (2013-04-03) 1 commit\n - push: switch default from \"matching\" to \"simple\"\n\n Will cook in 'next' until Git 2.0.\n\n\n* jc/add-2.0-ignore-removal (2013-04-22) 1 commit\n - git add <pathspec>... defaults to \"-A\"\n\n Updated endgame for \"git add <pathspec>\" that defaults to \"--all\"\n aka \"--no-ignore-removal\".\n\n Will cook in 'next' until Git 2.0.\n"},{"id":"218959","messageId":"87bo7slrz1.fsf@linux-k42r.v.cablecom.net","threadId":"33977","inReplyTo":"7va9ndqqyf.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-05-30T09:47:14Z","receivedAt":"2013-05-30T09:47:14Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> * rr/die-on-missing-upstream (2013-05-22) 2 commits\n>  - sha1_name: fix error message for @{<N>}, @{<date>}\n>  - sha1_name: fix error message for @{u}\n>\n>  When a reflog notation is used for implicit \"current branch\", we\n>  did not say which branch and worse said \"branch ''\".\n>\n>  Will merge to 'next'.\n\nThis interacts with the tests from\n\n> * fc/at-head (2013-05-08) 13 commits\n\nto fail valgrind in t1508 like so:\n\n  ==22927== Invalid read of size 1\n  ==22927==    at 0x4C2C71B: __GI_strnlen (mc_replace_strmem.c:377)\n  ==22927==    by 0x567FF6B: vfprintf (in /lib64/libc-2.17.so)\n  ==22927==    by 0x56AC194: vsnprintf (in /lib64/libc-2.17.so)\n  ==22927==    by 0x4EAC39: vreportf (usage.c:12)\n  ==22927==    by 0x4EACA4: die_builtin (usage.c:36)\n  ==22927==    by 0x4EAEE0: die (usage.c:103)\n  ==22927==    by 0x4D8C51: get_sha1_1 (sha1_name.c:542)\n  ==22927==    by 0x4D8E5D: get_sha1_with_context_1 (sha1_name.c:1299)\n  ==22927==    by 0x4D992A: get_sha1_with_context (sha1_name.c:1417)\n  ==22927==    by 0x4D99E1: get_sha1 (sha1_name.c:1124)\n  ==22927==    by 0x45E1AC: cmd_rev_parse (rev-parse.c:761)\n  ==22927==    by 0x4051B3: handle_internal_command (git.c:284)\n  ==22927==  Address 0x5bebccb is 11 bytes inside a block of size 22 free'd\n  ==22927==    at 0x4C2ACDA: free (vg_replace_malloc.c:468)\n  ==22927==    by 0x4D8C37: get_sha1_1 (sha1_name.c:541)\n  ==22927==    by 0x4D8E5D: get_sha1_with_context_1 (sha1_name.c:1299)\n  ==22927==    by 0x4D992A: get_sha1_with_context (sha1_name.c:1417)\n  ==22927==    by 0x4D99E1: get_sha1 (sha1_name.c:1124)\n  ==22927==    by 0x45E1AC: cmd_rev_parse (rev-parse.c:761)\n  ==22927==    by 0x4051B3: handle_internal_command (git.c:284)\n  ==22927==    by 0x4053E7: main (git.c:492)\n\nI think it's enough to squash this little change; leaking some memory\nimmediately before die() is not too bad, especially if we're going to\npass real_ref+11 into die()...\n\ndiff --git i/sha1_name.c w/sha1_name.c\nindex 5ea16ff..a07558d 100644\n--- i/sha1_name.c\n+++ w/sha1_name.c\n@@ -538,7 +538,6 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)\n \t\t\t\t\t\"back to %s.\", len, str,\n \t\t\t\t\tshow_date(co_time, co_tz, DATE_RFC2822));\n \t\t\telse {\n-\t\t\t\tfree(real_ref);\n \t\t\t\tdie(\"Log for '%.*s' only has %d entries.\",\n \t\t\t\t    len, str, co_cnt);\n \t\t\t}\n\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"218960","messageId":"CALkWK0nnFjTASAMA5pZa2=epK9HwSYY7U_S8SKOoiMAf-NovTA@mail.gmail.com","threadId":"33977","inReplyTo":"87bo7slrz1.fsf@linux-k42r.v.cablecom.net","subject":"Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-05-30T09:56:18Z","receivedAt":"2013-05-30T09:56:18Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Thomas Rast wrote:\n> diff --git i/sha1_name.c w/sha1_name.c\n> index 5ea16ff..a07558d 100644\n> --- i/sha1_name.c\n> +++ w/sha1_name.c\n> @@ -538,7 +538,6 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)\n>                                         \"back to %s.\", len, str,\n>                                         show_date(co_time, co_tz, DATE_RFC2822));\n>                         else {\n> -                               free(real_ref);\n>                                 die(\"Log for '%.*s' only has %d entries.\",\n>                                     len, str, co_cnt);\n>                         }\n\nAh, good catch.  Thanks.\n\nSorry I didn't notice this while writing the patch.\n"},{"id":"219038","messageId":"51A7A5F9.2030107@web.de","threadId":"33977","inReplyTo":"7va9ndqqyf.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-05-30T19:18:17Z","receivedAt":"2013-05-30T19:18:17Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 30.05.2013 01:58, schrieb Junio C Hamano:\n> * jl/submodule-mv (2013-04-23) 5 commits\n>   (merged to 'next' on 2013-04-23 at c04f574)\n>  + submodule.c: duplicate real_path's return value\n>   (merged to 'next' on 2013-04-19 at 45ae3c9)\n>  + rm: delete .gitmodules entry of submodules removed from the work tree\n>  + Teach mv to update the path entry in .gitmodules for moved submodules\n>  + Teach mv to move submodules using a gitfile\n>  + Teach mv to move submodules together with their work trees\n> \n>  \"git mv A B\" when moving a submodule A does \"the right thing\",\n>  inclusing relocating its working tree and adjusting the paths in\n>  the .gitmodules file.\n\nThere are only two issues I'm aware of:\n\n*) When the .gitmodules file is already modified but unchanged\n   running rm or mv on a submodule will stage those changes too.\n\n*) There is a harmless but unnecessary double invocation of strlen()\n   in the function (fixed by the diff below).\n\nI plan to fix the first issue in another patch which would also get\nrid of the second issue, as exactly that code would have to be touched\nanyways.\n\nDoes that make sense?\n\n----------8<-----------------\ndiff --git a/submodule.c b/submodule.c\nindex edfc23c..4670af7 100644\n--- a/submodule.c\n+++ b/submodule.c\n@@ -102,7 +102,7 @@ void stage_updated_gitmodules(void)\n        struct cache_entry *ce;\n        int namelen = strlen(\".gitmodules\");\n\n-       pos = cache_name_pos(\".gitmodules\", strlen(\".gitmodules\"));\n+       pos = cache_name_pos(\".gitmodules\", namelen);\n        if (pos < 0) {\n                warning(_(\"could not find .gitmodules in index\"));\n                return;\n"},{"id":"219039","messageId":"51A7A73C.6070103@web.de","threadId":"33977","inReplyTo":"7va9ndqqyf.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-05-30T19:23:40Z","receivedAt":"2013-05-30T19:23:40Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 30.05.2013 01:58, schrieb Junio C Hamano:\n> * jk/submodule-subdirectory-ok (2013-04-24) 3 commits\n>   (merged to 'next' on 2013-04-24 at 6306b29)\n>  + submodule: fix quoting in relative_path()\n>   (merged to 'next' on 2013-04-22 at f211e25)\n>  + submodule: drop the top-level requirement\n>  + rev-parse: add --prefix option\n> \n>  Allow various subcommands of \"git submodule\" to be run not from the\n>  top of the working tree of the superproject.\n\nThe summary and status commands are looking good in this version\n(they are now showing the submodule directory paths relative to\nthe current directory). Apart from that my other remarks from\ngmane $221575 still seem to apply. And this series has only tests\nfor status, summary and add (and that just with an absolute URL),\nI'd rather like to see a test for each submodule command (and a\nrelative add to) to document the desired behavior.\n\nBut I'm not sure if it's better to have another iteration of this\nseries or to address the open issues a follow-up series. Having\nstatus, summary and add - at least with absolute URLs - lose the\ntoplevel requirement is already a huge improvement IMO. Opinions?\n"},{"id":"219057","messageId":"loom.20130531T081035-747@post.gmane.org","threadId":"33977","inReplyTo":"7va9ndqqyf.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"Øystein Walle","fromEmail":"oystwa@gmail.com","sentAt":"2013-05-31T06:16:45Z","receivedAt":"2013-05-31T06:16:45Z","isPatch":false,"sender":{"key":"oystwa@gmail.com","avatar":"https://avatars.githubusercontent.com/u/794585?v=4"},"body":"Junio C Hamano <gitster <at> pobox.com> writes:\n\n> * kb/status-ignored-optim-2 (2013-05-29) 1 commit\n>  - dir.c: fix ignore processing within not-ignored directories\n> \n>  Fix 1.8.3 regressions in the .gitignore path exclusion logic.\n\nHi,\n\nI see that the Tested-by line in kb/status-ignored-optim-2 (3973cbd)\ndoesn't contain my e-mail address. I personally have no particular\npreference whether it's there or not, but I noticed that it usually is\non Tested-by lines, so I'm wondering if I have slipped on some standard\npractice. Would be useful to know in case I get the chance to help out\nmore :)\n\nThanks,\nØsse\n"},{"id":"219105","messageId":"20130531194051.GC1072@serenity.lan","threadId":"33977","inReplyTo":"51A7A73C.6070103@web.de","subject":"Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-05-31T19:40:51Z","receivedAt":"2013-05-31T19:40:51Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Thu, May 30, 2013 at 09:23:40PM +0200, Jens Lehmann wrote:\n> Am 30.05.2013 01:58, schrieb Junio C Hamano:\n> > * jk/submodule-subdirectory-ok (2013-04-24) 3 commits\n> >   (merged to 'next' on 2013-04-24 at 6306b29)\n> >  + submodule: fix quoting in relative_path()\n> >   (merged to 'next' on 2013-04-22 at f211e25)\n> >  + submodule: drop the top-level requirement\n> >  + rev-parse: add --prefix option\n> > \n> >  Allow various subcommands of \"git submodule\" to be run not from the\n> >  top of the working tree of the superproject.\n> \n> The summary and status commands are looking good in this version\n> (they are now showing the submodule directory paths relative to\n> the current directory). Apart from that my other remarks from\n> gmane $221575 still seem to apply. And this series has only tests\n> for status, summary and add (and that just with an absolute URL),\n> I'd rather like to see a test for each submodule command (and a\n> relative add to) to document the desired behavior.\n\nTo summarize what I think are the outstanding issues from your email:\n\n* Should '$sm_path' be relative in \"submodule foreach\"?\n* \"submodule add\" with a relative path\n* \"submodule init\" initializes all submodules\n* Tests\n\nThe current version does make '$sm_path' relative in \"submodule\nforeach\", although it's hard to spot because we have to leave doing so\nuntil right before the \"eval\".\n\nI'm not sure what you mean about \"submodule add\" - the new version\ntreats the \"path\" argument as relative (providing it is not an absolute\npath).  The \"repository\" argument is not changed by running from a\nsubdirectory but I think that's correct since it is documented as being\nrelative to the superproject's origin repository.\n\n\"submodule init\" is behaving in the same way as \"deinit\" - if you say\n\"submodule init .\" then it will only initialize submodules below the\ncurrent directory.  The difference is that \"deinit\" dies if it is not\ngiven any arguments whereas \"init\" will initialize everything from the\ntop level down.  I'm not sure whether to change this; given the\ndirection \"git add -u\" is heading in for 2.0 I think the current\nbehaviour is the most consistent with the rest of Git.\n\n> But I'm not sure if it's better to have another iteration of this\n> series or to address the open issues a follow-up series. Having\n> status, summary and add - at least with absolute URLs - lose the\n> toplevel requirement is already a huge improvement IMO. Opinions?\n\nI think the only thing outstanding is tests.  I'm happy to add those as\na follow-up or in a re-roll.\n"},{"id":"219181","messageId":"7v61xwpct5.fsf@alter.siamese.dyndns.org","threadId":"33977","inReplyTo":"51A7A5F9.2030107@web.de","subject":"Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-02T18:50:14Z","receivedAt":"2013-06-02T18:50:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann <Jens.Lehmann@web.de> writes:\n\n> Am 30.05.2013 01:58, schrieb Junio C Hamano:\n>> * jl/submodule-mv (2013-04-23) 5 commits\n>>   (merged to 'next' on 2013-04-23 at c04f574)\n>>  + submodule.c: duplicate real_path's return value\n>>   (merged to 'next' on 2013-04-19 at 45ae3c9)\n>>  + rm: delete .gitmodules entry of submodules removed from the work tree\n>>  + Teach mv to update the path entry in .gitmodules for moved submodules\n>>  + Teach mv to move submodules using a gitfile\n>>  + Teach mv to move submodules together with their work trees\n>> \n>>  \"git mv A B\" when moving a submodule A does \"the right thing\",\n>>  inclusing relocating its working tree and adjusting the paths in\n>>  the .gitmodules file.\n>\n> There are only two issues I'm aware of:\n>\n> *) When the .gitmodules file is already modified but unchanged\n>    running rm or mv on a submodule will stage those changes too.\n>\n> *) There is a harmless but unnecessary double invocation of strlen()\n>    in the function (fixed by the diff below).\n>\n> I plan to fix the first issue in another patch which would also get\n> rid of the second issue, as exactly that code would have to be touched\n> anyways.\n>\n> Does that make sense?\n\nIn general I think whatever you think that makes sense in this area\nwould make sense ;-).\n\nI do not feel confident that I am reading what you mean by \"already\nmodified but unchanged\" right.  Do you mean the working tree version\nis different from both HEAD and the index (HEAD and the index may or\nmay not match and that does not change the situation)?  Assuming\nthat is the case, i.e. the situation you are worried about is:\n\n    When \".gitmodules\" has a local modification the user chose not\n    to \"add\" yet.  Then the user does \"git rm/mv\" on a submodule\n    that is unrelated to the submodule whose setting the user has\n    changes for.\n\nI am curious what the plan is to \"fix\" this.  An obviously safe\nthing to do is to error out with a \"You have local modification;\nplease 'git add .gitmodules' first.\" but if that advice/suggestion\nis always the right course of action for the user, it invites \"then\nwhy doesn't Git do so for me?\", which would in turn support that it\nis not an issue in the first place (it deserves to be mentioned in a\nwarning, \"adding your local modifications together with change\nneeded for rm/mv\", though).\n\nI think in the ideal world, you may want to apply the change needed\nfor rm/mv to the version in the index, and then update the working\ntree version by doing a 3-way merge. We already know that eventually\nwe would need a merge driver that is specific to the file format\nthat git-config uses, possibly even taking an advantage of the\nknowledge of not just the file format but also the semantics of\nindividual variables [*1*], so we may want to keep it in mind that a\nthree-way merge would be the eventual goal, while settling on an\n\"error out on local mod\" just like \"git checkout anotherbranch\" used\nto always stop (before we taught the \"-m\" option to it) when a local\nchange needed a 3-way merge to be carried along to the new branch.\n\nSo my gut feeling of the \"fix\" at this point in the evolution of the\nprogram may be to error out with a message like \"You have local\nchanges to .gitmodules; please stash it before moving or removing\".\n\n[Footnote]\n\n*1* I think all the variables in .gitmodules are single-valued, so\n    the original submodule.dir.path's value was \"dir\", the local\n    modification by the user was to make it \"folder\", and rm wants\n    to delete an unrelated submodule.mod.* altogether, we can apply\n    the usual 3-way merge policy per variable basis to update\n    submodule.dir.pah to \"folder\".\n\n    A more general merge driver to handle git-config format files\n    would have a way to be told that some variables are additive\n    with the -X<driver-specific-option> mechanism.  When variable\n    foo.bar is specified as a multi-valued set of variables, the\n    original has a single foo.bar=\"xyzzy\", one side adds a\n    foo.bar=\"frotz while the other side modifies the original to\n    foo.bar=\"nitfol\", the ideal way for such a merge driver to\n    operate is to leave two definitions (xyzzy will be gone and\n    frotz and nitfol remain).\n\n    But I highly suspect that would need a much larger change to the\n    configuration file parser and writer that is totally out of\n    scope with this change, and that is why my recommendation at\n    this point is just to follow the example of pre-\"-m\" era of \"git\n    checkout anotherbranch\".\n\n\n> ----------8<-----------------\n> diff --git a/submodule.c b/submodule.c\n> index edfc23c..4670af7 100644\n> --- a/submodule.c\n> +++ b/submodule.c\n> @@ -102,7 +102,7 @@ void stage_updated_gitmodules(void)\n>         struct cache_entry *ce;\n>         int namelen = strlen(\".gitmodules\");\n>\n> -       pos = cache_name_pos(\".gitmodules\", strlen(\".gitmodules\"));\n> +       pos = cache_name_pos(\".gitmodules\", namelen);\n>         if (pos < 0) {\n>                 warning(_(\"could not find .gitmodules in index\"));\n>                 return;\n"},{"id":"219204","messageId":"7vr4gkkrhk.fsf@alter.siamese.dyndns.org","threadId":"33977","inReplyTo":"87bo7slrz1.fsf@linux-k42r.v.cablecom.net","subject":"Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-02T23:44:23Z","receivedAt":"2013-06-02T23:44:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast <trast@inf.ethz.ch> writes:\n\n> This interacts with the tests from\n>\n>> * fc/at-head (2013-05-08) 13 commits\n>\n> to fail valgrind in t1508 like so:\n>\n>   ==22927== Invalid read of size 1\n>   ==22927==    at 0x4C2C71B: __GI_strnlen (mc_replace_strmem.c:377)\n>   ==22927==    by 0x567FF6B: vfprintf (in /lib64/libc-2.17.so)\n>   ==22927==    by 0x56AC194: vsnprintf (in /lib64/libc-2.17.so)\n>   ==22927==    by 0x4EAC39: vreportf (usage.c:12)\n>   ==22927==    by 0x4EACA4: die_builtin (usage.c:36)\n>   ==22927==    by 0x4EAEE0: die (usage.c:103)\n>   ==22927==    by 0x4D8C51: get_sha1_1 (sha1_name.c:542)\n>   ==22927==    by 0x4D8E5D: get_sha1_with_context_1 (sha1_name.c:1299)\n>   ==22927==    by 0x4D992A: get_sha1_with_context (sha1_name.c:1417)\n>   ==22927==    by 0x4D99E1: get_sha1 (sha1_name.c:1124)\n>   ==22927==    by 0x45E1AC: cmd_rev_parse (rev-parse.c:761)\n>   ==22927==    by 0x4051B3: handle_internal_command (git.c:284)\n>   ==22927==  Address 0x5bebccb is 11 bytes inside a block of size 22 free'd\n>   ==22927==    at 0x4C2ACDA: free (vg_replace_malloc.c:468)\n>   ==22927==    by 0x4D8C37: get_sha1_1 (sha1_name.c:541)\n>   ==22927==    by 0x4D8E5D: get_sha1_with_context_1 (sha1_name.c:1299)\n>   ==22927==    by 0x4D992A: get_sha1_with_context (sha1_name.c:1417)\n>   ==22927==    by 0x4D99E1: get_sha1 (sha1_name.c:1124)\n>   ==22927==    by 0x45E1AC: cmd_rev_parse (rev-parse.c:761)\n>   ==22927==    by 0x4051B3: handle_internal_command (git.c:284)\n>   ==22927==    by 0x4053E7: main (git.c:492)\n>\n> I think it's enough to squash this little change; leaking some memory\n> immediately before die() is not too bad, especially if we're going to\n> pass real_ref+11 into die()...\n\nGood catch, thanks.  when !len and real_ref is the current branch,\nstr just points into real_ref that is geting freed.\n\n>\n> diff --git i/sha1_name.c w/sha1_name.c\n> index 5ea16ff..a07558d 100644\n> --- i/sha1_name.c\n> +++ w/sha1_name.c\n> @@ -538,7 +538,6 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)\n>  \t\t\t\t\t\"back to %s.\", len, str,\n>  \t\t\t\t\tshow_date(co_time, co_tz, DATE_RFC2822));\n>  \t\t\telse {\n> -\t\t\t\tfree(real_ref);\n>  \t\t\t\tdie(\"Log for '%.*s' only has %d entries.\",\n>  \t\t\t\t    len, str, co_cnt);\n>  \t\t\t}\n"},{"id":"219228","messageId":"20130603145405.GJ1072@serenity.lan","threadId":"33977","inReplyTo":"20130531194051.GC1072@serenity.lan","subject":"Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-06-03T14:54:05Z","receivedAt":"2013-06-03T14:54:05Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Fri, May 31, 2013 at 08:40:51PM +0100, John Keeping wrote:\n> On Thu, May 30, 2013 at 09:23:40PM +0200, Jens Lehmann wrote:\n> > Am 30.05.2013 01:58, schrieb Junio C Hamano:\n> > > * jk/submodule-subdirectory-ok (2013-04-24) 3 commits\n> > >   (merged to 'next' on 2013-04-24 at 6306b29)\n> > >  + submodule: fix quoting in relative_path()\n> > >   (merged to 'next' on 2013-04-22 at f211e25)\n> > >  + submodule: drop the top-level requirement\n> > >  + rev-parse: add --prefix option\n> > > \n> > >  Allow various subcommands of \"git submodule\" to be run not from the\n> > >  top of the working tree of the superproject.\n> > \n> > The summary and status commands are looking good in this version\n> > (they are now showing the submodule directory paths relative to\n> > the current directory). Apart from that my other remarks from\n> > gmane $221575 still seem to apply. And this series has only tests\n> > for status, summary and add (and that just with an absolute URL),\n> > I'd rather like to see a test for each submodule command (and a\n> > relative add to) to document the desired behavior.\n> \n> To summarize what I think are the outstanding issues from your email:\n> \n> * Should '$sm_path' be relative in \"submodule foreach\"?\n> * \"submodule add\" with a relative path\n> * \"submodule init\" initializes all submodules\n> * Tests\n> \n> The current version does make '$sm_path' relative in \"submodule\n> foreach\", although it's hard to spot because we have to leave doing so\n> until right before the \"eval\".\n> \n> I'm not sure what you mean about \"submodule add\" - the new version\n> treats the \"path\" argument as relative (providing it is not an absolute\n> path).  The \"repository\" argument is not changed by running from a\n> subdirectory but I think that's correct since it is documented as being\n> relative to the superproject's origin repository.\n> \n> \"submodule init\" is behaving in the same way as \"deinit\" - if you say\n> \"submodule init .\" then it will only initialize submodules below the\n> current directory.  The difference is that \"deinit\" dies if it is not\n> given any arguments whereas \"init\" will initialize everything from the\n> top level down.  I'm not sure whether to change this; given the\n> direction \"git add -u\" is heading in for 2.0 I think the current\n> behaviour is the most consistent with the rest of Git.\n> \n> > But I'm not sure if it's better to have another iteration of this\n> > series or to address the open issues a follow-up series. Having\n> > status, summary and add - at least with absolute URLs - lose the\n> > toplevel requirement is already a huge improvement IMO. Opinions?\n> \n> I think the only thing outstanding is tests.  I'm happy to add those as\n> a follow-up or in a re-roll.\n\nI started looking at this over the weekend but didn't get time to get\nsomething ready to be submitted.  I did find a couple of issues in\ncmd_foreach that make me think this topic should be dropped when \"next\"\nis rewound and held in pu waiting for a re-roll.\n"},{"id":"219232","messageId":"7vk3mbjjos.fsf@alter.siamese.dyndns.org","threadId":"33977","inReplyTo":"20130603145405.GJ1072@serenity.lan","subject":"Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-03T15:30:27Z","receivedAt":"2013-06-03T15:30:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping <john@keeping.me.uk> writes:\n\n> I started looking at this over the weekend but didn't get time to get\n> something ready to be submitted.  I did find a couple of issues in\n> cmd_foreach that make me think this topic should be dropped when \"next\"\n> is rewound and held in pu waiting for a re-roll.\n\nThanks for a heads-up.\n"},{"id":"219303","messageId":"51AD0A25.5080101@web.de","threadId":"33977","inReplyTo":"7v61xwpct5.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-06-03T21:27:01Z","receivedAt":"2013-06-03T21:27:01Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 02.06.2013 20:50, schrieb Junio C Hamano:\n> Jens Lehmann <Jens.Lehmann@web.de> writes:\n> \n>> Am 30.05.2013 01:58, schrieb Junio C Hamano:\n>>> * jl/submodule-mv (2013-04-23) 5 commits\n>>>   (merged to 'next' on 2013-04-23 at c04f574)\n>>>  + submodule.c: duplicate real_path's return value\n>>>   (merged to 'next' on 2013-04-19 at 45ae3c9)\n>>>  + rm: delete .gitmodules entry of submodules removed from the work tree\n>>>  + Teach mv to update the path entry in .gitmodules for moved submodules\n>>>  + Teach mv to move submodules using a gitfile\n>>>  + Teach mv to move submodules together with their work trees\n>>>\n>>>  \"git mv A B\" when moving a submodule A does \"the right thing\",\n>>>  inclusing relocating its working tree and adjusting the paths in\n>>>  the .gitmodules file.\n\n<detailed discussion snipped>\n\n> So my gut feeling of the \"fix\" at this point in the evolution of the\n> program may be to error out with a message like \"You have local\n> changes to .gitmodules; please stash it before moving or removing\".\n\nYeah, me too thinks that this is a sane short term solution (even\nthough a \"git submodule add\" currently happily stages any unstaged\nmodifications to the .gitmodules file too, that should not stop us\nfrom doing better for rm and mv ;-).\n\nAnd I also agree that in the long run the the git-config aware merge\ndriver together with the 3-way merge of a modified .gitmodules file\nyou described is the best solution. But I'd really like to complete\nthe recursive update before tackling that, so for now I just added\nthese two to the to-do list on my GitHub wiki page.\n\nI'll resubmit this series with the strlen() fix and the erroring out\nin case of unstaged modifications of the .gitmodules file as soon as\nI find some time.\n"},{"id":"219306","messageId":"51AD0EEB.4020106@web.de","threadId":"33977","inReplyTo":"20130531194051.GC1072@serenity.lan","subject":"Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-06-03T21:47:23Z","receivedAt":"2013-06-03T21:47:23Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 31.05.2013 21:40, schrieb John Keeping:\n> On Thu, May 30, 2013 at 09:23:40PM +0200, Jens Lehmann wrote:\n>> Am 30.05.2013 01:58, schrieb Junio C Hamano:\n>>> * jk/submodule-subdirectory-ok (2013-04-24) 3 commits\n>>>   (merged to 'next' on 2013-04-24 at 6306b29)\n>>>  + submodule: fix quoting in relative_path()\n>>>   (merged to 'next' on 2013-04-22 at f211e25)\n>>>  + submodule: drop the top-level requirement\n>>>  + rev-parse: add --prefix option\n>>>\n>>>  Allow various subcommands of \"git submodule\" to be run not from the\n>>>  top of the working tree of the superproject.\n>>\n>> The summary and status commands are looking good in this version\n>> (they are now showing the submodule directory paths relative to\n>> the current directory). Apart from that my other remarks from\n>> gmane $221575 still seem to apply. And this series has only tests\n>> for status, summary and add (and that just with an absolute URL),\n>> I'd rather like to see a test for each submodule command (and a\n>> relative add to) to document the desired behavior.\n> \n> To summarize what I think are the outstanding issues from your email:\n> \n> * Should '$sm_path' be relative in \"submodule foreach\"?\n> * \"submodule add\" with a relative path\n> * \"submodule init\" initializes all submodules\n> * Tests\n> \n> The current version does make '$sm_path' relative in \"submodule\n> foreach\", although it's hard to spot because we have to leave doing so\n> until right before the \"eval\".\n\nYes. If I read the code correctly the submodule is cd'ed in before\nthe foreach command is executed, so $sm_path should only be used for\ndisplaying info about where the command is executed anyway. Looks\nlike your code is doing the right thing adjusting $sm_path to be\nrelative to the directory the user is in. But a test showing that\nwould really be nice ;-)\n\n> I'm not sure what you mean about \"submodule add\" - the new version\n> treats the \"path\" argument as relative (providing it is not an absolute\n> path).  The \"repository\" argument is not changed by running from a\n> subdirectory but I think that's correct since it is documented as being\n> relative to the superproject's origin repository.\n\nSorry, I should have been more specific here. I saw that you did some\nchanges to make \"submodule add\" do the right thing with relative paths,\nbut the following change to t7406 does not work like I believe it\nshould but instead makes the test fail:\n-------------------8<---------------------\ndiff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh\nindex a4ffea0..9766b9e 100755\n--- a/t/t7406-submodule-update.sh\n+++ b/t/t7406-submodule-update.sh\n@@ -559,7 +559,9 @@ test_expect_success 'add different submodules to the same pa\n test_expect_success 'submodule add places git-dir in superprojects git-dir' '\n        (cd super &&\n         mkdir deeper &&\n-        git submodule add ../submodule deeper/submodule &&\n+        (cd deeper &&\n+         git submodule add ../../submodule submodule\n+        ) &&\n         (cd deeper/submodule &&\n          git log > ../../expected\n         ) &&\n-------------------8<---------------------\n\n> \"submodule init\" is behaving in the same way as \"deinit\" - if you say\n> \"submodule init .\" then it will only initialize submodules below the\n> current directory.  The difference is that \"deinit\" dies if it is not\n> given any arguments whereas \"init\" will initialize everything from the\n> top level down.  I'm not sure whether to change this; given the\n> direction \"git add -u\" is heading in for 2.0 I think the current\n> behaviour is the most consistent with the rest of Git.\n\nI meant that both commands still print the submodule names from the\ntop-level directory, not the one the user is in.\n"},{"id":"219309","messageId":"20130603222341.GL1072@serenity.lan","threadId":"33977","inReplyTo":"51AD0EEB.4020106@web.de","subject":"Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-06-03T22:23:41Z","receivedAt":"2013-06-03T22:23:41Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Mon, Jun 03, 2013 at 11:47:23PM +0200, Jens Lehmann wrote:\n> Am 31.05.2013 21:40, schrieb John Keeping:\n> > The current version does make '$sm_path' relative in \"submodule\n> > foreach\", although it's hard to spot because we have to leave doing so\n> > until right before the \"eval\".\n> \n> Yes. If I read the code correctly the submodule is cd'ed in before\n> the foreach command is executed, so $sm_path should only be used for\n> displaying info about where the command is executed anyway. Looks\n> like your code is doing the right thing adjusting $sm_path to be\n> relative to the directory the user is in. But a test showing that\n> would really be nice ;-)\n\nAgreed.  I've also noticed that the legacy \"path\" variable hasn't been\nadjusted and the printing of the module paths does not make them\nrelative.  I'll fix them in the next version.\n\n> > I'm not sure what you mean about \"submodule add\" - the new version\n> > treats the \"path\" argument as relative (providing it is not an absolute\n> > path).  The \"repository\" argument is not changed by running from a\n> > subdirectory but I think that's correct since it is documented as being\n> > relative to the superproject's origin repository.\n> \n> Sorry, I should have been more specific here. I saw that you did some\n> changes to make \"submodule add\" do the right thing with relative paths,\n> but the following change to t7406 does not work like I believe it\n> should but instead makes the test fail:\n> -------------------8<---------------------\n> diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh\n> index a4ffea0..9766b9e 100755\n> --- a/t/t7406-submodule-update.sh\n> +++ b/t/t7406-submodule-update.sh\n> @@ -559,7 +559,9 @@ test_expect_success 'add different submodules to the same pa\n>  test_expect_success 'submodule add places git-dir in superprojects git-dir' '\n>         (cd super &&\n>          mkdir deeper &&\n> -        git submodule add ../submodule deeper/submodule &&\n> +        (cd deeper &&\n> +         git submodule add ../../submodule submodule\n> +        ) &&\n>          (cd deeper/submodule &&\n>           git log > ../../expected\n>          ) &&\n> -------------------8<---------------------\n\nAh, ok.  I think this case is problematic because the repository\nargument is either relative to \"remote.origin.url\" or to the top of the\nworking tree if there is no \"origin\" remote.  I wonder if we should just\ndie when a relative path is given for the repository and we're not at\nthe top of the working tree.\n\n> > \"submodule init\" is behaving in the same way as \"deinit\" - if you say\n> > \"submodule init .\" then it will only initialize submodules below the\n> > current directory.  The difference is that \"deinit\" dies if it is not\n> > given any arguments whereas \"init\" will initialize everything from the\n> > top level down.  I'm not sure whether to change this; given the\n> > direction \"git add -u\" is heading in for 2.0 I think the current\n> > behaviour is the most consistent with the rest of Git.\n> \n> I meant that both commands still print the submodule names from the\n> top-level directory, not the one the user is in.\n\nWill fix.\n"},{"id":"219321","messageId":"20130604052950.GA2943@book.hvoigt.net","threadId":"33977","inReplyTo":"20130603222341.GL1072@serenity.lan","subject":"Re: Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2013-06-04T05:29:51Z","receivedAt":"2013-06-04T05:29:51Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Mon, Jun 03, 2013 at 11:23:41PM +0100, John Keeping wrote:\n> > Sorry, I should have been more specific here. I saw that you did some\n> > changes to make \"submodule add\" do the right thing with relative paths,\n> > but the following change to t7406 does not work like I believe it\n> > should but instead makes the test fail:\n> > -------------------8<---------------------\n> > diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh\n> > index a4ffea0..9766b9e 100755\n> > --- a/t/t7406-submodule-update.sh\n> > +++ b/t/t7406-submodule-update.sh\n> > @@ -559,7 +559,9 @@ test_expect_success 'add different submodules to the same pa\n> >  test_expect_success 'submodule add places git-dir in superprojects git-dir' '\n> >         (cd super &&\n> >          mkdir deeper &&\n> > -        git submodule add ../submodule deeper/submodule &&\n> > +        (cd deeper &&\n> > +         git submodule add ../../submodule submodule\n> > +        ) &&\n> >          (cd deeper/submodule &&\n> >           git log > ../../expected\n> >          ) &&\n> > -------------------8<---------------------\n> \n> Ah, ok.  I think this case is problematic because the repository\n> argument is either relative to \"remote.origin.url\" or to the top of the\n> working tree if there is no \"origin\" remote.  I wonder if we should just\n> die when a relative path is given for the repository and we're not at\n> the top of the working tree.\n\nWhy not behave as if we are at the top of the working tree for relative\npaths? If there is an origin remote thats fine. If there is no origin\nremote you could warn that the path used is taken relative from the root\nof the superproject during add. What do you think?\n\nCheers Heiko\n"},{"id":"219338","messageId":"20130604081045.GM1072@serenity.lan","threadId":"33977","inReplyTo":"20130604052950.GA2943@book.hvoigt.net","subject":"Re: Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-06-04T08:10:45Z","receivedAt":"2013-06-04T08:10:45Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Tue, Jun 04, 2013 at 03:29:51PM +1000, Heiko Voigt wrote:\n> On Mon, Jun 03, 2013 at 11:23:41PM +0100, John Keeping wrote:\n> > > Sorry, I should have been more specific here. I saw that you did some\n> > > changes to make \"submodule add\" do the right thing with relative paths,\n> > > but the following change to t7406 does not work like I believe it\n> > > should but instead makes the test fail:\n> > > -------------------8<---------------------\n> > > diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh\n> > > index a4ffea0..9766b9e 100755\n> > > --- a/t/t7406-submodule-update.sh\n> > > +++ b/t/t7406-submodule-update.sh\n> > > @@ -559,7 +559,9 @@ test_expect_success 'add different submodules to the same pa\n> > >  test_expect_success 'submodule add places git-dir in superprojects git-dir' '\n> > >         (cd super &&\n> > >          mkdir deeper &&\n> > > -        git submodule add ../submodule deeper/submodule &&\n> > > +        (cd deeper &&\n> > > +         git submodule add ../../submodule submodule\n> > > +        ) &&\n> > >          (cd deeper/submodule &&\n> > >           git log > ../../expected\n> > >          ) &&\n> > > -------------------8<---------------------\n> > \n> > Ah, ok.  I think this case is problematic because the repository\n> > argument is either relative to \"remote.origin.url\" or to the top of the\n> > working tree if there is no \"origin\" remote.  I wonder if we should just\n> > die when a relative path is given for the repository and we're not at\n> > the top of the working tree.\n> \n> Why not behave as if we are at the top of the working tree for relative\n> paths? If there is an origin remote thats fine. If there is no origin\n> remote you could warn that the path used is taken relative from the root\n> of the superproject during add. What do you think?\n\nThat's what the patch currently queued on \"pu\" does, which Jens wants to\nchange, isn't it?\n"},{"id":"219346","messageId":"20130604111717.GA306@book.hvoigt.net","threadId":"33977","inReplyTo":"20130604081045.GM1072@serenity.lan","subject":"Re: Re: Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2013-06-04T11:17:17Z","receivedAt":"2013-06-04T11:17:17Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Tue, Jun 04, 2013 at 09:10:45AM +0100, John Keeping wrote:\n> On Tue, Jun 04, 2013 at 03:29:51PM +1000, Heiko Voigt wrote:\n> > On Mon, Jun 03, 2013 at 11:23:41PM +0100, John Keeping wrote:\n> > > > Sorry, I should have been more specific here. I saw that you did some\n> > > > changes to make \"submodule add\" do the right thing with relative paths,\n> > > > but the following change to t7406 does not work like I believe it\n> > > > should but instead makes the test fail:\n> > > > -------------------8<---------------------\n> > > > diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh\n> > > > index a4ffea0..9766b9e 100755\n> > > > --- a/t/t7406-submodule-update.sh\n> > > > +++ b/t/t7406-submodule-update.sh\n> > > > @@ -559,7 +559,9 @@ test_expect_success 'add different submodules to the same pa\n> > > >  test_expect_success 'submodule add places git-dir in superprojects git-dir' '\n> > > >         (cd super &&\n> > > >          mkdir deeper &&\n> > > > -        git submodule add ../submodule deeper/submodule &&\n> > > > +        (cd deeper &&\n> > > > +         git submodule add ../../submodule submodule\n> > > > +        ) &&\n> > > >          (cd deeper/submodule &&\n> > > >           git log > ../../expected\n> > > >          ) &&\n> > > > -------------------8<---------------------\n> > > \n> > > Ah, ok.  I think this case is problematic because the repository\n> > > argument is either relative to \"remote.origin.url\" or to the top of the\n> > > working tree if there is no \"origin\" remote.  I wonder if we should just\n> > > die when a relative path is given for the repository and we're not at\n> > > the top of the working tree.\n> > \n> > Why not behave as if we are at the top of the working tree for relative\n> > paths? If there is an origin remote thats fine. If there is no origin\n> > remote you could warn that the path used is taken relative from the root\n> > of the superproject during add. What do you think?\n> \n> That's what the patch currently queued on \"pu\" does, which Jens wants to\n> change, isn't it?\n\nTrue I did not realize this when reading it the first time. But I think\nwe should still not die when in a subdirectory. After all this series is\ntrying to archive that the submodule command works in subdirectories\nseamlessly right? So you probably want to translate a relative path\nwithout \"origin\" remote given from a subdirectory to the superproject\nlevel and use that. Then you do not have to die.\n\nCheers Heiko\n"},{"id":"219364","messageId":"20130604124826.GN1072@serenity.lan","threadId":"33977","inReplyTo":"20130604111717.GA306@book.hvoigt.net","subject":"Re: Re: Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-06-04T12:48:26Z","receivedAt":"2013-06-04T12:48:26Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Tue, Jun 04, 2013 at 09:17:17PM +1000, Heiko Voigt wrote:\n> On Tue, Jun 04, 2013 at 09:10:45AM +0100, John Keeping wrote:\n> > On Tue, Jun 04, 2013 at 03:29:51PM +1000, Heiko Voigt wrote:\n> > > On Mon, Jun 03, 2013 at 11:23:41PM +0100, John Keeping wrote:\n> > > > > Sorry, I should have been more specific here. I saw that you did some\n> > > > > changes to make \"submodule add\" do the right thing with relative paths,\n> > > > > but the following change to t7406 does not work like I believe it\n> > > > > should but instead makes the test fail:\n> > > > > -------------------8<---------------------\n> > > > > diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh\n> > > > > index a4ffea0..9766b9e 100755\n> > > > > --- a/t/t7406-submodule-update.sh\n> > > > > +++ b/t/t7406-submodule-update.sh\n> > > > > @@ -559,7 +559,9 @@ test_expect_success 'add different submodules to the same pa\n> > > > >  test_expect_success 'submodule add places git-dir in superprojects git-dir' '\n> > > > >         (cd super &&\n> > > > >          mkdir deeper &&\n> > > > > -        git submodule add ../submodule deeper/submodule &&\n> > > > > +        (cd deeper &&\n> > > > > +         git submodule add ../../submodule submodule\n> > > > > +        ) &&\n> > > > >          (cd deeper/submodule &&\n> > > > >           git log > ../../expected\n> > > > >          ) &&\n> > > > > -------------------8<---------------------\n> > > > \n> > > > Ah, ok.  I think this case is problematic because the repository\n> > > > argument is either relative to \"remote.origin.url\" or to the top of the\n> > > > working tree if there is no \"origin\" remote.  I wonder if we should just\n> > > > die when a relative path is given for the repository and we're not at\n> > > > the top of the working tree.\n> > > \n> > > Why not behave as if we are at the top of the working tree for relative\n> > > paths? If there is an origin remote thats fine. If there is no origin\n> > > remote you could warn that the path used is taken relative from the root\n> > > of the superproject during add. What do you think?\n> > \n> > That's what the patch currently queued on \"pu\" does, which Jens wants to\n> > change, isn't it?\n> \n> True I did not realize this when reading it the first time. But I think\n> we should still not die when in a subdirectory. After all this series is\n> trying to archive that the submodule command works in subdirectories\n> seamlessly right? So you probably want to translate a relative path\n> without \"origin\" remote given from a subdirectory to the superproject\n> level and use that. Then you do not have to die.\n\nThe problem is that sometimes you do want to adjust the path and\nsometimes you don't.  Reading git-submodule(1), it says:\n\n     This may be either an absolute URL, or (if it begins with ./ or\n     ../), the location relative to the superproject’s origin\n     repository.\n     [snip]\n     If the superproject doesn’t have an origin configured the\n     superproject is its own authoritative upstream and the current\n     working directory is used instead.\n\nSo I think it's quite reasonable to have a server layout that looks like\nthis:\n\n    project\n    |- libs\n    |  |- libA\n    |  `- libB\n    |- core.git\n\nand with only core.git on your local system do:\n\n    cd core/libs\n    git submodule add ../libs/libB\n\nexpecting that to point to libB.  But if we adjust the path then the\nuser has to do:\n\n    git submodule add ../../libs/libB\n\nHowever, it is also perfectly reasonable to have no remote configured\nand the library next to the repository itself.  In which case we do want\nto specify the additional \"../\" so that shell completion works in the\nnatural way.\n\nThe only way I can see to resolve the ambiguity is to die when we hit\nthis particular case.  This should be acceptable because people\nshouldn't be adding new submodules anywhere near as often as they\nperform other submodule operations and it doesn't affect absolute URLs.\n"},{"id":"219416","messageId":"51AE5E8D.7080007@web.de","threadId":"33977","inReplyTo":"20130604124826.GN1072@serenity.lan","subject":"Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-06-04T21:39:25Z","receivedAt":"2013-06-04T21:39:25Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 04.06.2013 14:48, schrieb John Keeping:\n> On Tue, Jun 04, 2013 at 09:17:17PM +1000, Heiko Voigt wrote:\n>> On Tue, Jun 04, 2013 at 09:10:45AM +0100, John Keeping wrote:\n>>> On Tue, Jun 04, 2013 at 03:29:51PM +1000, Heiko Voigt wrote:\n>>>> On Mon, Jun 03, 2013 at 11:23:41PM +0100, John Keeping wrote:\n>>>>>> Sorry, I should have been more specific here. I saw that you did some\n>>>>>> changes to make \"submodule add\" do the right thing with relative paths,\n>>>>>> but the following change to t7406 does not work like I believe it\n>>>>>> should but instead makes the test fail:\n>>>>>> -------------------8<---------------------\n>>>>>> diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh\n>>>>>> index a4ffea0..9766b9e 100755\n>>>>>> --- a/t/t7406-submodule-update.sh\n>>>>>> +++ b/t/t7406-submodule-update.sh\n>>>>>> @@ -559,7 +559,9 @@ test_expect_success 'add different submodules to the same pa\n>>>>>>  test_expect_success 'submodule add places git-dir in superprojects git-dir' '\n>>>>>>         (cd super &&\n>>>>>>          mkdir deeper &&\n>>>>>> -        git submodule add ../submodule deeper/submodule &&\n>>>>>> +        (cd deeper &&\n>>>>>> +         git submodule add ../../submodule submodule\n>>>>>> +        ) &&\n>>>>>>          (cd deeper/submodule &&\n>>>>>>           git log > ../../expected\n>>>>>>          ) &&\n>>>>>> -------------------8<---------------------\n>>>>>\n>>>>> Ah, ok.  I think this case is problematic because the repository\n>>>>> argument is either relative to \"remote.origin.url\" or to the top of the\n>>>>> working tree if there is no \"origin\" remote.  I wonder if we should just\n>>>>> die when a relative path is given for the repository and we're not at\n>>>>> the top of the working tree.\n>>>>\n>>>> Why not behave as if we are at the top of the working tree for relative\n>>>> paths? If there is an origin remote thats fine. If there is no origin\n>>>> remote you could warn that the path used is taken relative from the root\n>>>> of the superproject during add. What do you think?\n>>>\n>>> That's what the patch currently queued on \"pu\" does, which Jens wants to\n>>> change, isn't it?\n>>\n>> True I did not realize this when reading it the first time. But I think\n>> we should still not die when in a subdirectory. After all this series is\n>> trying to archive that the submodule command works in subdirectories\n>> seamlessly right? So you probably want to translate a relative path\n>> without \"origin\" remote given from a subdirectory to the superproject\n>> level and use that. Then you do not have to die.\n> \n> The problem is that sometimes you do want to adjust the path and\n> sometimes you don't.  Reading git-submodule(1), it says:\n> \n>      This may be either an absolute URL, or (if it begins with ./ or\n>      ../), the location relative to the superproject’s origin\n>      repository.\n>      [snip]\n>      If the superproject doesn’t have an origin configured the\n>      superproject is its own authoritative upstream and the current\n>      working directory is used instead.\n> \n> So I think it's quite reasonable to have a server layout that looks like\n> this:\n> \n>     project\n>     |- libs\n>     |  |- libA\n>     |  `- libB\n>     |- core.git\n> \n> and with only core.git on your local system do:\n> \n>     cd core/libs\n>     git submodule add ../libs/libB\n> \n> expecting that to point to libB.  But if we adjust the path then the\n> user has to do:\n> \n>     git submodule add ../../libs/libB\n> \n> However, it is also perfectly reasonable to have no remote configured\n> and the library next to the repository itself.  In which case we do want\n> to specify the additional \"../\" so that shell completion works in the\n> natural way.\n\nExactly.\n\n> The only way I can see to resolve the ambiguity is to die when we hit\n> this particular case.\n\nHmm, I'm not so sure about that. Don't the first three lines in\nresolve_relative_url() show how to distinguish between these two\ncases?\n\nresolve_relative_url ()\n{\n\tremote=$(get_default_remote)\n\tremoteurl=$(git config \"remote.$remote.url\") ||\n\t\tremoteurl=$(pwd) # the repository is its own authoritative upstream\n...\n\nAnd this looks like a central place to handle this issue too (but I\nadmit I only glanced over the call sites of resolve_relative_url(),\nso I might be missing something here).\n"},{"id":"219419","messageId":"20130604220418.GP1072@serenity.lan","threadId":"33977","inReplyTo":"51AE5E8D.7080007@web.de","subject":"Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-06-04T22:04:18Z","receivedAt":"2013-06-04T22:04:18Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Tue, Jun 04, 2013 at 11:39:25PM +0200, Jens Lehmann wrote:\n> Am 04.06.2013 14:48, schrieb John Keeping:\n> > The problem is that sometimes you do want to adjust the path and\n> > sometimes you don't.  Reading git-submodule(1), it says:\n> > \n> >      This may be either an absolute URL, or (if it begins with ./ or\n> >      ../), the location relative to the superproject’s origin\n> >      repository.\n> >      [snip]\n> >      If the superproject doesn’t have an origin configured the\n> >      superproject is its own authoritative upstream and the current\n> >      working directory is used instead.\n> > \n> > So I think it's quite reasonable to have a server layout that looks like\n> > this:\n> > \n> >     project\n> >     |- libs\n> >     |  |- libA\n> >     |  `- libB\n> >     |- core.git\n> > \n> > and with only core.git on your local system do:\n> > \n> >     cd core/libs\n> >     git submodule add ../libs/libB\n> > \n> > expecting that to point to libB.  But if we adjust the path then the\n> > user has to do:\n> > \n> >     git submodule add ../../libs/libB\n> > \n> > However, it is also perfectly reasonable to have no remote configured\n> > and the library next to the repository itself.  In which case we do want\n> > to specify the additional \"../\" so that shell completion works in the\n> > natural way.\n> \n> Exactly.\n> \n> > The only way I can see to resolve the ambiguity is to die when we hit\n> > this particular case.\n> \n> Hmm, I'm not so sure about that. Don't the first three lines in\n> resolve_relative_url() show how to distinguish between these two\n> cases?\n>\n> resolve_relative_url ()\n> {\n> \tremote=$(get_default_remote)\n> \tremoteurl=$(git config \"remote.$remote.url\") ||\n> \t\tremoteurl=$(pwd) # the repository is its own authoritative upstream\n> ...\n\nIf it's this simple, yes.  But I think there's also a third possibility\nthat combines both of these: what if the local directory structure is\nthe same as that on the \"origin\" remote?  Then \"origin\" exists but we\nstill want to adjust for the subdirectory.\n\nThe risk is that I can't see a behaviour that doesn't seem to choose\nwhether to convert the given path or not arbitrarily.  Even knowing the\nrules, I expect that I could end up being surprised by this if I create\na new repository and haven't set up \"origin\" yet.\n"},{"id":"219424","messageId":"CABURp0qPt8S4WWhjb22qEJwnUOoT7SFr9=cZBv3Syp-uEX-ycg@mail.gmail.com","threadId":"33977","inReplyTo":"20130604124826.GN1072@serenity.lan","subject":"Re: Re: Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2013-06-04T22:57:34Z","receivedAt":"2013-06-04T22:57:34Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Tue, Jun 4, 2013 at 8:48 AM, John Keeping <john@keeping.me.uk> wrote:\n> On Tue, Jun 04, 2013 at 09:17:17PM +1000, Heiko Voigt wrote:\n>> On Tue, Jun 04, 2013 at 09:10:45AM +0100, John Keeping wrote:\n>> > On Tue, Jun 04, 2013 at 03:29:51PM +1000, Heiko Voigt wrote:\n>> > > On Mon, Jun 03, 2013 at 11:23:41PM +0100, John Keeping wrote:\n>> > > > > Sorry, I should have been more specific here. I saw that you did some\n>> > > > > changes to make \"submodule add\" do the right thing with relative paths,\n>> > > > > but the following change to t7406 does not work like I believe it\n>> > > > > should but instead makes the test fail:\n>> > > > > -------------------8<---------------------\n>> > > > > diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh\n>> > > > > index a4ffea0..9766b9e 100755\n>> > > > > --- a/t/t7406-submodule-update.sh\n>> > > > > +++ b/t/t7406-submodule-update.sh\n>> > > > > @@ -559,7 +559,9 @@ test_expect_success 'add different submodules to the same pa\n>> > > > >  test_expect_success 'submodule add places git-dir in superprojects git-dir' '\n>> > > > >         (cd super &&\n>> > > > >          mkdir deeper &&\n>> > > > > -        git submodule add ../submodule deeper/submodule &&\n>> > > > > +        (cd deeper &&\n>> > > > > +         git submodule add ../../submodule submodule\n>> > > > > +        ) &&\n>> > > > >          (cd deeper/submodule &&\n>> > > > >           git log > ../../expected\n>> > > > >          ) &&\n>> > > > > -------------------8<---------------------\n>> > > >\n>> > > > Ah, ok.  I think this case is problematic because the repository\n>> > > > argument is either relative to \"remote.origin.url\" or to the top of the\n>> > > > working tree if there is no \"origin\" remote.  I wonder if we should just\n>> > > > die when a relative path is given for the repository and we're not at\n>> > > > the top of the working tree.\n>> > >\n>> > > Why not behave as if we are at the top of the working tree for relative\n>> > > paths? If there is an origin remote thats fine. If there is no origin\n>> > > remote you could warn that the path used is taken relative from the root\n>> > > of the superproject during add. What do you think?\n>> >\n>> > That's what the patch currently queued on \"pu\" does, which Jens wants to\n>> > change, isn't it?\n>>\n>> True I did not realize this when reading it the first time. But I think\n>> we should still not die when in a subdirectory. After all this series is\n>> trying to archive that the submodule command works in subdirectories\n>> seamlessly right? So you probably want to translate a relative path\n>> without \"origin\" remote given from a subdirectory to the superproject\n>> level and use that. Then you do not have to die.\n>\n> The problem is that sometimes you do want to adjust the path and\n> sometimes you don't.  Reading git-submodule(1), it says:\n>\n>      This may be either an absolute URL, or (if it begins with ./ or\n>      ../), the location relative to the superproject’s origin\n>      repository.\n>      [snip]\n>      If the superproject doesn’t have an origin configured the\n>      superproject is its own authoritative upstream and the current\n>      working directory is used instead.\n>\n> So I think it's quite reasonable to have a server layout that looks like\n> this:\n>\n>     project\n>     |- libs\n>     |  |- libA\n>     |  `- libB\n>     |- core.git\n>\n> and with only core.git on your local system do:\n>\n>     cd core/libs\n>     git submodule add ../libs/libB\n>\n> expecting that to point to libB.  But if we adjust the path then the\n> user has to do:\n>\n>     git submodule add ../../libs/libB\n>\n> However, it is also perfectly reasonable to have no remote configured\n> and the library next to the repository itself.  In which case we do want\n> to specify the additional \"../\" so that shell completion works in the\n> natural way.\n\nIn submodule add, the leading '../' prefix on the repository url has\nalways meant that the url is relative to the url of the current repo.\nThe given repo-url is precisely what ends up in .gitmodules'\nsubmodule.$name.url.  It works this way whether there is a remote\nconfigured or not.\n\nIt does seem like we need to be cautious around this change.\n\n> The only way I can see to resolve the ambiguity is to die when we hit\n> this particular case.  This should be acceptable because people\n> shouldn't be adding new submodules anywhere near as often as they\n> perform other submodule operations and it doesn't affect absolute URLs.\n\nI don't think I like that.  But I don't know if I like anything I\ndreamed up, either.\n\nP\n"},{"id":"219446","messageId":"20130605081901.GQ1072@serenity.lan","threadId":"33977","inReplyTo":"CABURp0qPt8S4WWhjb22qEJwnUOoT7SFr9=cZBv3Syp-uEX-ycg@mail.gmail.com","subject":"Re: Re: Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-06-05T08:19:02Z","receivedAt":"2013-06-05T08:19:02Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Tue, Jun 04, 2013 at 06:57:34PM -0400, Phil Hord wrote:\n> On Tue, Jun 4, 2013 at 8:48 AM, John Keeping <john@keeping.me.uk> wrote:\n> > The problem is that sometimes you do want to adjust the path and\n> > sometimes you don't.  Reading git-submodule(1), it says:\n> >\n> >      This may be either an absolute URL, or (if it begins with ./ or\n> >      ../), the location relative to the superproject’s origin\n> >      repository.\n> >      [snip]\n> >      If the superproject doesn’t have an origin configured the\n> >      superproject is its own authoritative upstream and the current\n> >      working directory is used instead.\n> >\n> > So I think it's quite reasonable to have a server layout that looks like\n> > this:\n> >\n> >     project\n> >     |- libs\n> >     |  |- libA\n> >     |  `- libB\n> >     |- core.git\n> >\n> > and with only core.git on your local system do:\n> >\n> >     cd core/libs\n> >     git submodule add ../libs/libB\n> >\n> > expecting that to point to libB.  But if we adjust the path then the\n> > user has to do:\n> >\n> >     git submodule add ../../libs/libB\n> >\n> > However, it is also perfectly reasonable to have no remote configured\n> > and the library next to the repository itself.  In which case we do want\n> > to specify the additional \"../\" so that shell completion works in the\n> > natural way.\n> \n> In submodule add, the leading '../' prefix on the repository url has\n> always meant that the url is relative to the url of the current repo.\n> The given repo-url is precisely what ends up in .gitmodules'\n> submodule.$name.url.  It works this way whether there is a remote\n> configured or not.\n> \n> It does seem like we need to be cautious around this change.\n> \n> > The only way I can see to resolve the ambiguity is to die when we hit\n> > this particular case.  This should be acceptable because people\n> > shouldn't be adding new submodules anywhere near as often as they\n> > perform other submodule operations and it doesn't affect absolute URLs.\n> \n> I don't think I like that.  But I don't know if I like anything I\n> dreamed up, either.\n\nI've decided that I will make it die (unless anyone comes up with an\nobviously correct solution before I get around to sending the reroll)\nbecause it's a lot easier to loosen that in the future than to change it\nif we get the behaviour wrong now.  I don't want to hold every other\nsubcommand hostage to this one case.\n"},{"id":"222313","messageId":"7vd2r2aq00.fsf@alter.siamese.dyndns.org","threadId":"33977","inReplyTo":"51AD0A25.5080101@web.de","subject":"Re: What's cooking in git.git (May 2013, #09; Wed, 29)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-01T22:05:12Z","receivedAt":"2013-07-01T22:05:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann <Jens.Lehmann@web.de> writes:\n\n> Am 02.06.2013 20:50, schrieb Junio C Hamano:\n>> Jens Lehmann <Jens.Lehmann@web.de> writes:\n>> \n>>> Am 30.05.2013 01:58, schrieb Junio C Hamano:\n>>>> * jl/submodule-mv (2013-04-23) 5 commits\n>>>>   (merged to 'next' on 2013-04-23 at c04f574)\n>>>>  + submodule.c: duplicate real_path's return value\n>>>>   (merged to 'next' on 2013-04-19 at 45ae3c9)\n>>>>  + rm: delete .gitmodules entry of submodules removed from the work tree\n>>>>  + Teach mv to update the path entry in .gitmodules for moved submodules\n>>>>  + Teach mv to move submodules using a gitfile\n>>>>  + Teach mv to move submodules together with their work trees\n>>>>\n>>>>  \"git mv A B\" when moving a submodule A does \"the right thing\",\n>>>>  inclusing relocating its working tree and adjusting the paths in\n>>>>  the .gitmodules file.\n>\n> <detailed discussion snipped>\n>\n>> So my gut feeling of the \"fix\" at this point in the evolution of the\n>> program may be to error out with a message like \"You have local\n>> changes to .gitmodules; please stash it before moving or removing\".\n>\n> Yeah, me too thinks that this is a sane short term solution (even\n> though a \"git submodule add\" currently happily stages any unstaged\n> modifications to the .gitmodules file too, that should not stop us\n> from doing better for rm and mv ;-).\n>\n> And I also agree that in the long run the the git-config aware merge\n> driver together with the 3-way merge of a modified .gitmodules file\n> you described is the best solution. But I'd really like to complete\n> the recursive update before tackling that, so for now I just added\n> these two to the to-do list on my GitHub wiki page.\n>\n> I'll resubmit this series with the strlen() fix and the erroring out\n> in case of unstaged modifications of the .gitmodules file as soon as\n> I find some time.\n\nPing?\n\nNo need to hurry, but just to make sure this didn't disappear from\neverybody's radar.\n\nThanks.\n"}]}