{"thread":{"id":"31496","subject":"What's cooking in git.git (Sep 2012, #03; Mon, 10)","startedAt":"2012-09-10T23:55:08Z","lastAt":"2012-09-14T20:20:44Z","messageCount":22,"participants":["Junio C Hamano","Jens Lehmann","Jeff King","Dan Johnson","Philip Oakley","Andrew Ardill","Michael Haggerty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"198753","messageId":"7vpq5tjuw3.fsf@alter.siamese.dyndns.org","threadId":"31496","inReplyTo":null,"subject":"What's cooking in git.git (Sep 2012, #03; Mon, 10)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-10T23:55:08Z","receivedAt":"2012-09-10T23:55:08Z","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 '-' are\nonly in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.\n\nThe fifth batch of topics have started graduating to 'master'.\n\nI'm planning to keep this cycle reasonably short and aim for tagging\nthe result as 1.8.0 at the end of 9th week, on October 21st, after\nwhich I'd disappear for a few weeks.  http://tinyurl.com/gitCal is\nwhere you can always find my rough tagging schedule at.\n\nYou can find the changes described here in the integration branches of the\nrepositories listed at\n\n    http://git-blame.blogspot.com/p/git-public-repositories.html\n\n--------------------------------------------------\n[New Topics]\n\n* jc/ll-merge-binary-ours (2012-09-08) 2 commits\n - attr: \"binary\" attribute should choose built-in \"binary\" merge driver\n - merge: teach -Xours/-Xtheirs to binary ll-merge driver\n\n\"git merge -Xtheirs\" did not help content-level merge of binary\nfiles; it should just take their version.  Also \"*.jpg binary\" in\nthe attributes did not imply they should use the binary ll-merge\ndriver.\n\n* jc/mailinfo-RE (2012-09-09) 1 commit\n - mailinfo: strip \"RE: \" prefix\n\nWe strip the prefix from \"Re: subject\" and also from a less common\n\"re: subject\", but left even less common \"RE: subject\" intact.\n\n* js/compat-mkdir (2012-09-08) 1 commit\n - Document MKDIR_WO_TRAILING_SLASH in Makefile\n\nFinishing touches to recently added wrapper for mkdir() that do not\nwant to see trailing slashes.\n\nWill merge to 'next'.\n\n* mh/string-list (2012-09-10) 6 commits\n - api-string-list.txt: initialize the string_list the easy way\n - string_list: add a function string_list_longest_prefix()\n - string_list: add a new function, string_list_remove_duplicates()\n - string_list: add a new function, filter_string_list()\n - string_list: add two new functions for splitting strings\n - string_list: add function string_list_append_nodup()\n (this branch is used by mh/fetch-filter-refs.)\n\n--------------------------------------------------\n[Graduated to \"master\"]\n\n* cn/branch-set-upstream-to (2012-08-30) 3 commits\n  (merged to 'next' on 2012-08-31 at d550ecd)\n + branch: deprecate --set-upstream and show help if we detect possible mistaken use\n + branch: add --unset-upstream option\n + branch: introduce --set-upstream-to\n\n\"git branch --set-upstream origin/master\" is a common mistake to\ncreate a local branch 'origin/master' and set it to integrate with\nthe current branch.  With a plan to deprecate this option, introduce\n\"git branch (-u|--set-upstream-to) origin/master\" that sets the\ncurrent branch to integrate with 'origin/master' remote tracking\nbranch.\n\n* jk/maint-quiet-is-synonym-to-s-in-log (2012-08-28) 1 commit\n  (merged to 'next' on 2012-08-31 at 06f6953)\n + log: fix --quiet synonym for -s\n\nWe tried to bend backwards to allow \"--quiet\" to be a synonym as\n\"-s\" when given as e.g. \"git show --quiet\", but did not quite\nsucceed.\n\n* mz/cherry-pick-cmdline-order (2012-08-30) 3 commits\n  (merged to 'next' on 2012-08-31 at fc8eec4)\n + cherry-pick/revert: respect order of revisions to pick\n + demonstrate broken 'git cherry-pick three one two'\n + teach log --no-walk=unsorted, which avoids sorting\n\n\"git cherry-pick A C B\" used to replay changes in A and then B and\nthen C if these three commits had committer timestamps in that\norder, which is not what the user who said \"A C B\" naturally expects.\n\n* ph/credential-gnome-keyring (2012-08-24) 1 commit\n  (merged to 'next' on 2012-08-31 at 6f3b1de)\n + contrib: add credential helper for GnomeKeyring\n (this branch is used by ph/credential-refactor.)\n\nThe later refactoring of the shared code in the original series may\nnot be worth the trouble, so it is split into a separate topic that\nbuilds on top of this one, which independently should be useful.\n\n--------------------------------------------------\n[Stalled]\n\n* ph/credential-refactor (2012-09-02) 5 commits\n - wincred: port to generic credential helper\n - Merge branch 'ef/win32-cred-helper' into ph/credential-refactor\n - osxkeychain: port to generic credential helper implementation\n - gnome-keyring: port to generic helper implementation\n - contrib: add generic credential helper\n\nAttempts to refactor to share code among OSX keychain, Gnome keyring\nand Win32 credential helpers.\n\n* jc/maint-name-rev (2012-09-04) 7 commits\n - describe --contains: use \"name-rev --weight\"\n - name-rev --weight: tests and documentation\n - name-rev --weight: cache the computed weight in notes\n - name-rev --weight: trivial optimization\n - name-rev: --weight option\n - name_rev: clarify the logic to assign a new tip-name to a commit\n - name-rev: lose unnecessary typedef\n\n\"git name-rev\" names the given revision based on a ref that can be\nreached in the smallest number of steps from the rev, but that is\nnot useful when the caller wants to know which tag is the oldest one\nthat contains the rev.  This teaches a new mode to the command that\nuses the oldest ref among those which contain the rev.\n\nI am not sure if this is worth it; for one thing, even with the help\nfrom notes-cache, it seems to make the \"describe --contains\" even\nslower. Also the command will be unusably slow for a user who does\nnot have a write access (hence unable to create or update the\nnotes-cache).\n\nNeeds another round to at least find a better name for the option,\nand possibly a cheaper but still better than the current \"close to\nthe tip\" heuristics.\n\n* ms/contrib-thunderbird-updates (2012-08-31) 2 commits\n - [SQUASH] minimum fixup\n - Thunderbird: fix appp.sh format problems\n\nUpdate helper to send out format-patch output using Thunderbird.\nSeems to have design regression for silent users.\n\n* as/check-ignore (2012-09-02) 10 commits\n . fixup: decl-after-stmt etc.\n . Add git-check-ignore\n . Provide free_directory() for reclaiming dir_struct memory\n . Extract some useful pathspec handling code from builtin/add.c into a library\n . For each exclude pattern, store information about where it came from\n . dir.c: refactor excluded() and path_excluded()\n . dir.c: refactor excluded_from_list()\n . dir.c: rename cryptic 'which' variable to more consistent name\n . Improve documentation and comments regarding directory traversal API\n . Update directory listing API doc to match code\n\nWill be rerolled.\n\n* jx/test-real-path (2012-08-27) 1 commit\n - test: set the realpath of CWD as TRASH_DIRECTORY\n\nRunning tests with the \"trash\" directory elsewhere with the \"--root\"\noption did not work well if the directory was specified by a symbolic\nlink pointing at it.\n\nSeems broken as it makes $(pwd) and TRASH_DIRECTORY inconsistent.\nNeeds rerolling.\n\n* jc/maint-push-refs-all (2012-08-27) 2 commits\n - get_fetch_map(): tighten checks on dest refs\n - [BROKEN] fetch/push: allow refs/*:refs/*\n\nAllows pushing and fetching everything including refs/stash.\nThis is broken (see the log message there).\n\n* er/doc-fast-import-done (2012-08-22) 1 commit\n - fast-import: document the --done option\n\nParked in 'pu' in case ESR responds with \"Sorry, forgot to sign-off\".\n\n* jc/add-delete-default (2012-08-13) 1 commit\n - git add: notice removal of tracked paths by default\n\n\"git add dir/\" updated modified files and added new files, but does\nnot notice removed files, which may be \"Huh?\" to some users.  They\ncan of course use \"git add -A dir/\", but why should they?\n\nResurrected from graveyard, as I thought it was a worthwhile thing\nto do in the longer term; waiting for comments.\n\n* tx/relative-in-the-future (2012-08-16) 2 commits\n - date: show relative dates in the future\n - date: refactor the relative date logic from presentation\n\nNot my itch; rewritten an earlier submission by Tom Xue into\nsomewhat more maintainable form, though it breaks existing i18n.\n\nAnybody interested in fixing it up?  Otherwise may discard.\n\n* tg/index-v5 (2012-08-17) 13 commits\n . p0002-index.sh: add perf test for the index formats\n . update-index.c: rewrite index when index-version is given\n . Write resolve-undo data for index-v5\n . Write index-v5 cache-tree data\n . Write index-v5\n . Read cache-tree in index-v5\n . Read resolve-undo data\n . Read index-v5\n . Make in-memory format aware of stat_crc\n . Add documentation of the index-v5 file format\n . t2104: Don't fail for index versions other than [23]\n . read-cache.c: Re-read index if index file changed\n . Move index v2 specific functions to their own file\n\nA GSoC project.  Was waiting for comments from mentors and\nstakeholders, but nothing seems to be happening, other than breakage\nfixes on Cygwin.  May discard.\n\n* mz/rebase-range (2012-07-18) 7 commits\n . rebase (without -p): correctly calculate patches to rebase\n . rebase -p: don't request --left-right only to ignore left side\n . rebase -p: use --cherry-mark for todo file\n . git-rebase--interactive.sh: look up subject in add_pick_line\n . git-rebase--interactive: group all $preserve_merges code\n . git-rebase--interactive.sh: extract function for adding \"pick\" line\n . git-rebase--am.sh: avoid special-casing --keep-empty\n\nExpecting a reroll.\n\nPerformance concerns from Windows folks.  Also the series lacks\nproper sign-offs.\n\n* mb/remote-default-nn-origin (2012-07-11) 6 commits\n - Teach get_default_remote to respect remote.default.\n - Test that plain \"git fetch\" uses remote.default when on a detached HEAD.\n - Teach clone to set remote.default.\n - Teach \"git remote\" about remote.default.\n - Teach remote.c about the remote.default configuration setting.\n - Rename remote.c's default_remote_name static variables.\n\nWhen the user does not specify what remote to interact with, we\noften attempt to use 'origin'.  This can now be customized via a\nconfiguration variable.\n\nExpecting a reroll.\n\n\"The first remote becomes the default\" bit is better done as a\nseparate step.\n\n* jc/split-blob (2012-04-03) 6 commits\n - chunked-object: streaming checkout\n - chunked-object: fallback checkout codepaths\n - bulk-checkin: support chunked-object encoding\n - bulk-checkin: allow the same data to be multiply hashed\n - new representation types in the packstream\n - packfile: use varint functions\n\nNot ready.\n\nI finished the streaming checkout codepath, but as explained in\n127b177 (bulk-checkin: support chunked-object encoding, 2011-11-30),\nthese are still early steps of a long and painful journey. At least\npack-objects and fsck need to learn the new encoding for the series\nto be usable locally, and then index-pack/unpack-objects needs to\nlearn it to be used remotely.\n\nGiven that I heard a lot of noise that people want large files, and\nthat I was asked by somebody at GitTogether'11 privately for an\nadvice on how to pay developers (not me) to help adding necessary\nsupport, I am somewhat dissapointed that the original patch series\nthat was sent long time ago still remains here without much comments\nand updates from the developer community. I even made the interface\nto the logic that decides where to split chunks easily replaceable,\nand I deliberately made the logic in the original patch extremely\nstupid to entice others, especially the \"bup\" fanbois, to come up\nwith a better logic, thinking that giving people an easy target to\nshoot for, they may be encouraged to help out. The plan is not\nworking :-<.\n\n--------------------------------------------------\n[Cooking]\n\n* pw/p4-submit-conflicts (2012-09-10) 12 commits\n - git-p4: add submit --conflict option and config varaiable\n - git p4: add submit --prepare-p4-only option\n - git p4: add submit --dry-run option\n - git p4: accept -v for --verbose\n - git p4: revert deleted files after submit cancel\n - git p4: rearrange submit template construction\n - git p4: test clean-up after failed submit, fix added files\n - git p4: standardize submit cancel due to unchanged template\n - git p4: move conflict prompt into run, add [q]uit input\n - git p4: remove submit failure options [a]pply and [w]rite\n - git p4: gracefully fail if some commits could not be applied\n - git p4 test: remove bash-ism of combined export/assignment\n\nRerolled.\n\nWaiting for comments.\n\n* kd/cvsimport-avoid-invalid-tag (2012-09-06) 1 commit\n - cvsimport: strip all inappropriate tag strings\n\n\"cvsimport\" tried to create a tag taken from CVS without\nsufficiently sanitizing it, causing the import to fail when an\ninvalid character in the tagname made underlying \"git tag\" to fail.\n\nWill merge to 'next'.\n\n* mh/abspath (2012-09-10) 9 commits\n - t0060: split absolute path test in two to exercise some of it on Windows\n - t0060: verify that real_path() removes extra slashes\n - real_path(): properly handle nonexistent top-level paths\n - t0060: verify that real_path() works correctly with absolute paths\n - real_path(): reject the empty string\n - t0060: verify that real_path() fails if passed the empty string\n - absolute_path(): reject the empty string\n - t0060: verify that absolute_path() fails if passed the empty string\n - t0060: move tests of real_path() from t0000 to here\n\nWill merge to 'next'.\n\n* nd/i18n-status (2012-09-06) 1 commit\n - status: remove i18n legos\n\nWill merge to 'next'.\n\n* nd/log-n-doc (2012-09-06) 1 commit\n - doc: move rev-list option -<n> from git-log.txt to rev-list-options.txt\n\nWill merge to 'next'.\n\n* nd/maint-remote-remove (2012-09-06) 1 commit\n - remote: prefer subcommand name 'remove' to 'rm'\n\nWill merge to 'next'.\n\n* sb/send-email-reconfirm-fix (2012-09-06) 1 commit\n - send-email: initial_to and initial_reply_to are both optional\n\nWill merge to 'next'.\n\n* sn/ls-remote-get-url-doc (2012-09-07) 1 commit\n - ls-remote: document the '--get-url' option\n\nWill merge to 'next'.\n\n* dj/fetch-all-tags (2012-09-07) 1 commit\n - fetch --all: pass --tags/--no-tags through to each remote\n (this branch uses jk/argv-array.)\n\n\"git fetch --all\", when passed \"--no-tags\", did not honor the\n\"--no-tags\" option while fetching from individual remotes (the same\nissue existed with \"--tags\", but combination \"--all --tags\" makes\nmuch less sense than \"--all --no-tags\").\n\nWill merge to 'next'.\n\n* jc/maint-ident-missing-human-name (2012-08-31) 1 commit\n  (merged to 'next' on 2012-09-07 at 0e99b20)\n + split_ident_line(): make best effort when parsing author/committer line\n\n\"git show --format='%ci'\" did not give timestamp correctly for\ncommits created without human readable name on \"committer\" line.\n\nWill merge to 'master' as part of the fifth batch.\n\n* jk/argv-array (2012-09-02) 4 commits\n  (merged to 'next' on 2012-09-07 at 98dbd14)\n + submodule: use argv_array instead of hand-building arrays\n + fetch: use argv_array instead of hand-building arrays\n + argv-array: fix bogus cast when freeing array\n + argv-array: add pop function\n (this branch is used by dj/fetch-all-tags.)\n\nUse argv-array API in \"git fetch\" implementation.\n\nWill merge to 'master' as part of the fifth batch.\n\n* rj/tap-fix (2012-09-02) 6 commits\n - test-lib.sh: Suppress the \"passed all ...\" message if no tests run\n - test-lib.sh: Add check for invalid use of 'skip_all' facility\n - test-lib.sh: Fix some shell coding style violations\n - t4016-*.sh: Skip all tests rather than each test\n - t3902-*.sh: Skip all tests rather than each test\n - t3300-*.sh: Fix a TAP parse error\n\nWill merge to 'next'.\n\n* rj/test-regex (2012-09-02) 1 commit\n  (merged to 'next' on 2012-09-07 at e7e3527)\n + test-regex: Add a test to check for a bug in the regex routines\n\nGit ships with a fall-back regexp implementation for platforms with\nbuggy regexp library; give people a tool to see if they should be\nusing it on their platform.\n\nWill merge to 'master' as part of the fifth batch.\n\n* jc/maint-checkout-fileglob-doc (2012-09-10) 3 commits\n - gitcli: contrast wildcard given to shell and to git\n - gitcli: formatting fix\n - Document file-glob for \"git checkout -- '*.c'\"\n\nUpdated with help from Peff.\n\nWill merge to 'next'.\n\n* jc/xprm-generation (2012-09-04) 1 commit\n - test-generation: compute generation numbers and clock skews\n\n* rj/path-cleanup (2012-09-04) 5 commits\n - Call mkpathdup() rather than xstrdup(mkpath(...))\n - Call git_pathdup() rather than xstrdup(git_path(\"...\"))\n - path.c: Use vsnpath() in the implementation of git_path()\n - path.c: Don't discard the return value of vsnpath()\n - path.c: Remove the 'git_' prefix from a file scope function\n\nWill merge to 'next'.\n\n* rs/archive-zip-utf8 (2012-09-04) 1 commit\n - archive-zip: support UTF-8 paths\n\nWill merge to 'next'.\n\n* nd/i18n-index-pack (2012-08-31) 1 commit\n  (merged to 'next' on 2012-09-07 at bbcece1)\n + i18n: mark more index-pack strings for translation\n\nWill merge to 'master' as part of the fifth batch.\n\n* nd/checkout-option-parsing-fix (2012-09-07) 4 commits\n - fixup! checkout: reorder option handling\n - checkout: reorder option handling\n - checkout: move more parameters to struct checkout_opts\n - checkout: pass \"struct checkout_opts *\" as const pointer\n\nThe option parsing of \"git checkout\" had error checking, dwim and\ndefaulting missing options, all mixed in the code, and issuing an\nappropriate error message with useful context was getting harder.\nReorganize the code and allow giving a proper diagnosis when the\nuser says \"git checkout -b -t foo bar\" (e.g. \"-t\" is not a good name\nfor a branch).\n\nWill merge to 'next' after squashing the tip two.\n\n* js/compat-itimer (2012-09-08) 1 commit\n - Add a no-op setitimer() wrapper\n\nPieces to support compilation on __TANDEM.\n\nWill merge to 'next'.\n\n* mh/fetch-filter-refs (2012-09-10) 14 commits\n - fetch-pack: eliminate spurious error messages\n - cmd_fetch_pack(): simplify computation of return value\n - fetch-pack: report missing refs even if no existing refs were received\n - cmd_fetch_pack(): return early if finish_connect() fails\n - filter_refs(): simplify logic\n - filter_refs(): build refs list as we go\n - filter_refs(): delete matched refs from sought list\n - fetch_pack(): update sought->nr to reflect number of unique entries\n - filter_refs(): do not check the same sought_pos twice\n - Change fetch_pack() and friends to take string_list arguments\n - fetch_pack(): reindent function decl and defn\n - Rename static function fetch_pack() to http_fetch_pack()\n - t5500: add tests of fetch-pack --all --depth=N $URL $REF\n - t5500: add tests of error output for missing refs\n (this branch uses mh/string-list.)\n\nCode simplification and clarification.\n\nWaiting for the mh/string-list to settle.\n\n* jc/merge-bases (2012-08-31) 9 commits\n  (merged to 'next' on 2012-09-07 at ab0974d)\n + reduce_heads(): reimplement on top of remove_redundant()\n + merge-base: \"--is-ancestor A B\"\n + get_merge_bases_many(): walk from many tips in parallel\n + in_merge_bases(): use paint_down_to_common()\n + merge_bases_many(): split out the logic to paint history\n + in_merge_bases(): omit unnecessary redundant common ancestor reduction\n + http-push: use in_merge_bases() for fast-forward check\n + receive-pack: use in_merge_bases() for fast-forward check\n + in_merge_bases(): support only one \"other\" commit\n\nOptimise the \"merge-base\" computation a bit, and also update its\nusers that do not need the full merge-base information to call a\ncheaper subset.\n\nWill merge to 'master' as part of the fifth batch.\n\n* jl/submodule-rm (2012-08-27) 1 commit\n - Teach rm to remove submodules unless they contain a git directory\n\n\"git rm submodule\" cannot blindly remove a submodule directory as\nits working tree may have local changes, and worse yet, it may even\nhave its repository embedded in it.  Teach it some special cases\nwhere it is safe to remove a submodule, specifically, when there is\nno local changes in the submodule working tree, and its repository\nis not embedded in its working tree but is elsewhere and uses the\ngitfile mechanism to point at it.\n\nI lost track; what is the doneness of the discussion on this patch?\n\n* fa/remote-svn (2012-08-28) 16 commits\n - Add a test script for remote-svn\n - remote-svn: add marks-file regeneration\n - Add a svnrdump-simulator replaying a dump file for testing\n - remote-svn: add incremental import\n - remote-svn: Activate import/export-marks for fast-import\n - Create a note for every imported commit containing svn metadata\n - vcs-svn: add fast_export_note to create notes\n - Allow reading svn dumps from files via file:// urls\n - remote-svn, vcs-svn: Enable fetching to private refs\n - When debug==1, start fast-import with \"--stats\" instead of \"--quiet\"\n - Add documentation for the 'bidi-import' capability of remote-helpers\n - Connect fast-import to the remote-helper via pipe, adding 'bidi-import' capability\n - Add argv_array_detach and argv_array_free_detached\n - Add svndump_init_fd to allow reading dumps from arbitrary FDs\n - Add git-remote-testsvn to Makefile and .gitignore\n - Implement a remote helper for svn in C\n (this branch is used by fa/vcs-svn.)\n\nA GSoC project.  Looked promising.\nWaiting for comments from mentors and stakeholders.\n\n* fa/vcs-svn (2012-08-28) 4 commits\n - vcs-svn: remove repo_tree\n - vcs-svn/svndump: rewrite handle_node(), begin|end_revision()\n - vcs-svn/svndump: restructure node_ctx, rev_ctx handling\n - svndump: move struct definitions to .h\n (this branch uses fa/remote-svn.)\n\nA GSoC project.  Looked promising.\nWaiting for comments from mentors and stakeholders.\n\n* jk/no-more-pre-exec-callback (2012-06-05) 1 commit\n - pager: drop \"wait for output to run less\" hack\n\n(Originally merged to 'next' on 2012-07-23)\n\nWill defer until the end of the 2012.\nwhile waiting for older \"less\" to go extinct.\n\n--------------------------------------------------\n[Discarded]\n\n* jc/sanitize-nkd-lazy-iconv-open (2012-07-31) 1 commit\n . macos: lazily initialize iconv\n\nTeach the code that works around NKD/NKC gotcha on MacOS to call\niconv_open() only when it is necessary, in the hope of avoiding\nset-up overhead.  It turns out that there was no noticeable\nimprovements.\n\n* nd/checkout-branch-name-check (2012-08-27) 1 commit\n . checkout: verify new branch name's validity early\n\n\"git checkout -b --opt y\" errors out saying that creating a new\nbranch to check it out and grabbing contents for paths out of a\ncommit are incompatible operations.  While it is technically correct\n(the command line wants to create a new branch whose name is \"--opt\"\nand check it out, and there shouldn't be anything else left on the\ncommand line, but there is \"y\"), \"--opt\" is not a valid name of the\nbranch to begin with, so even without \"y\", the command will not\nsucceed.  Treat this case specially to complain that \"--opt\" is not\na valid branch name.\n"},{"id":"198805","messageId":"504F8427.1020507@web.de","threadId":"31496","inReplyTo":"7vpq5tjuw3.fsf@alter.siamese.dyndns.org","subject":"[PATCH v3] Teach rm to remove submodules unless they contain a git directory","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-09-11T18:34:15Z","receivedAt":"2012-09-11T18:34:15Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Currently using \"git rm\" on a submodule - populated or not - fails with\nthis error:\n\tfatal: git rm: '<submodule path>': Is a directory\nThis made sense in the past as there was no way to remove a submodule\nwithout possibly removing unpushed parts of the submodule's history\ncontained in its .git directory too, so erroring out here protected the\nuser from possible loss of data.\n\nBut submodules cloned with a recent git version do not contain the .git\ndirectory anymore, they use a gitfile to point to their git directory\nwhich is safely stored inside the superproject's .git directory. The work\ntree of these submodules can safely be removed without loosing history, so\nlet's teach git to do so.\n\nUsing rm on an unpopulated submodule now removes the empty directory from\nthe work tree and the gitlink from the index. If the submodule's directory\nis missing from the work tree, it will still be removed from the index.\n\nUsing rm on a populated submodule using a gitfile will apply the usual\nchecks for work tree modification adapted to submodules (unless forced).\nFor a submodule that means that the HEAD is the same as recorded in the\nindex, no tracked files are modified and no untracked files that aren't\nignored are present in the submodules work tree (ignored files are deemed\nexpendable and won't stop a submodule's work tree from being removed).\nThat logic has to be applied in all nested submodules too.\n\nUsing rm on a submodule which has its .git directory inside the work trees\ntop level directory will just error out like it did before to protect the\nrepository, even when forced. In the future git could either provide a\nmessage informing the user to convert the submodule to use a gitfile or\neven attempt to do the conversion itself, but that is not part of this\nchange.\n\nSigned-off-by: Jens Lehmann <Jens.Lehmann@web.de>\n---\n\nAm 11.09.2012 01:55, schrieb Junio C Hamano:\n> * jl/submodule-rm (2012-08-27) 1 commit\n>  - Teach rm to remove submodules unless they contain a git directory\n> \n> \"git rm submodule\" cannot blindly remove a submodule directory as\n> its working tree may have local changes, and worse yet, it may even\n> have its repository embedded in it.  Teach it some special cases\n> where it is safe to remove a submodule, specifically, when there is\n> no local changes in the submodule working tree, and its repository\n> is not embedded in its working tree but is elsewhere and uses the\n> gitfile mechanism to point at it.\n> \n> I lost track; what is the doneness of the discussion on this patch?\n\nThe review of v2 revealed that in case of submodule merge conflicts\nthe necessary checks weren't done. This (and the minor issues raised\nin http://permalink.gmane.org/gmane.comp.version-control.git/204370)\nis fixed in this version.\n\n\n Documentation/git-rm.txt |  15 +++\n builtin/rm.c             | 107 ++++++++++++++---\n submodule.c              |  80 +++++++++++++\n submodule.h              |   2 +\n t/t3600-rm.sh            | 291 +++++++++++++++++++++++++++++++++++++++++++++++\n 5 files changed, 480 insertions(+), 15 deletions(-)\n\ndiff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt\nindex 5d31860..882cb11 100644\n--- a/Documentation/git-rm.txt\n+++ b/Documentation/git-rm.txt\n@@ -107,6 +107,21 @@ as well as modifications of existing paths.\n Typically you would first remove all tracked files from the working\n tree using this command:\n\n+Submodules\n+~~~~~~~~~~\n+Only submodules using a gitfile (which means they were cloned\n+with a git version 1.7.8 or newer) will be removed from the work\n+tree, as their repository lives inside the .git directory of the\n+superproject. If a submodule (or one of those nested inside it)\n+still uses a .git directory, `git rm` will fail - no matter if forced\n+or not - to protect the submodule's history.\n+\n+A submodule is considered up-to-date when the HEAD is the same as\n+recorded in the index, no tracked files are modified and no untracked\n+files that aren't ignored are present in the submodules work tree.\n+Ignored files are deemed expendable and won't stop a submodule's work\n+tree from being removed.\n+\n ----------------\n git ls-files -z | xargs -0 rm -f\n ----------------\ndiff --git a/builtin/rm.c b/builtin/rm.c\nindex b384c4c..0e7ea7c 100644\n--- a/builtin/rm.c\n+++ b/builtin/rm.c\n@@ -9,6 +9,7 @@\n #include \"cache-tree.h\"\n #include \"tree-walk.h\"\n #include \"parse-options.h\"\n+#include \"submodule.h\"\n\n static const char * const builtin_rm_usage[] = {\n \tN_(\"git rm [options] [--] <file>...\"),\n@@ -17,9 +18,43 @@ static const char * const builtin_rm_usage[] = {\n\n static struct {\n \tint nr, alloc;\n-\tconst char **name;\n+\tstruct {\n+\t\tconst char *name;\n+\t\tchar is_submodule;\n+\t} *entry;\n } list;\n\n+static int check_submodules_use_gitfiles(void)\n+{\n+\tint i;\n+\tint errs = 0;\n+\n+\tfor (i = 0; i < list.nr; i++) {\n+\t\tconst char *name = list.entry[i].name;\n+\t\tint pos;\n+\t\tstruct cache_entry *ce;\n+\t\tstruct stat st;\n+\n+\t\tpos = cache_name_pos(name, strlen(name));\n+\t\tif (pos < 0)\n+\t\t\tpos = -pos-1;\n+\t\tce = active_cache[pos];\n+\n+\t\tif (!S_ISGITLINK(ce->ce_mode) ||\n+\t\t    (lstat(ce->name, &st) < 0) ||\n+\t\t    is_empty_dir(name))\n+\t\t\tcontinue;\n+\n+\t\tif (!submodule_uses_gitfile(name))\n+\t\t\terrs = error(_(\"submodule '%s' (or one of its nested \"\n+\t\t\t\t     \"submodules) uses a .git directory\\n\"\n+\t\t\t\t     \"(use 'rm -rf' if you really want to remove \"\n+\t\t\t\t     \"it including all of its history)\"), name);\n+\t}\n+\n+\treturn errs;\n+}\n+\n static int check_local_mod(unsigned char *head, int index_only)\n {\n \t/*\n@@ -37,15 +72,23 @@ static int check_local_mod(unsigned char *head, int index_only)\n \t\tstruct stat st;\n \t\tint pos;\n \t\tstruct cache_entry *ce;\n-\t\tconst char *name = list.name[i];\n+\t\tconst char *name = list.entry[i].name;\n \t\tunsigned char sha1[20];\n \t\tunsigned mode;\n \t\tint local_changes = 0;\n \t\tint staged_changes = 0;\n\n \t\tpos = cache_name_pos(name, strlen(name));\n-\t\tif (pos < 0)\n-\t\t\tcontinue; /* removing unmerged entry */\n+\t\tif (pos < 0) {\n+\t\t\t/*\n+\t\t\t * Skip unmerged entries except for populated submodules\n+\t\t\t * that could loose history when removed.\n+\t\t\t */\n+\t\t\tpos = -pos-1;\n+\t\t\tif (!S_ISGITLINK(active_cache[pos]->ce_mode) ||\n+\t\t\t    is_empty_dir(name))\n+\t\t\t\tcontinue;\n+\t\t}\n \t\tce = active_cache[pos];\n\n \t\tif (lstat(ce->name, &st) < 0) {\n@@ -58,9 +101,10 @@ static int check_local_mod(unsigned char *head, int index_only)\n \t\t\t/* if a file was removed and it is now a\n \t\t\t * directory, that is the same as ENOENT as\n \t\t\t * far as git is concerned; we do not track\n-\t\t\t * directories.\n+\t\t\t * directories unless they are submodules.\n \t\t\t */\n-\t\t\tcontinue;\n+\t\t\tif (!S_ISGITLINK(ce->ce_mode))\n+\t\t\t\tcontinue;\n \t\t}\n\n \t\t/*\n@@ -80,8 +124,11 @@ static int check_local_mod(unsigned char *head, int index_only)\n\n \t\t/*\n \t\t * Is the index different from the file in the work tree?\n+\t\t * If it's a submodule, is its work tree modified?\n \t\t */\n-\t\tif (ce_match_stat(ce, &st, 0))\n+\t\tif (ce_match_stat(ce, &st, 0) ||\n+\t\t    (S_ISGITLINK(ce->ce_mode) &&\n+\t\t     !ok_to_remove_submodule(ce->name)))\n \t\t\tlocal_changes = 1;\n\n \t\t/*\n@@ -115,10 +162,18 @@ static int check_local_mod(unsigned char *head, int index_only)\n \t\t\t\terrs = error(_(\"'%s' has changes staged in the index\\n\"\n \t\t\t\t\t     \"(use --cached to keep the file, \"\n \t\t\t\t\t     \"or -f to force removal)\"), name);\n-\t\t\tif (local_changes)\n-\t\t\t\terrs = error(_(\"'%s' has local modifications\\n\"\n-\t\t\t\t\t     \"(use --cached to keep the file, \"\n-\t\t\t\t\t     \"or -f to force removal)\"), name);\n+\t\t\tif (local_changes) {\n+\t\t\t\tif (S_ISGITLINK(ce->ce_mode) &&\n+\t\t\t\t    !submodule_uses_gitfile(name)) {\n+\t\t\t\t\terrs = error(_(\"submodule '%s' (or one of its nested \"\n+\t\t\t\t\t\t     \"submodules) uses a .git directory\\n\"\n+\t\t\t\t\t\t     \"(use 'rm -rf' if you really want to remove \"\n+\t\t\t\t\t\t     \"it including all of its history)\"), name);\n+\t\t\t\t} else\n+\t\t\t\t\terrs = error(_(\"'%s' has local modifications\\n\"\n+\t\t\t\t\t\t     \"(use --cached to keep the file, \"\n+\t\t\t\t\t\t     \"or -f to force removal)\"), name);\n+\t\t\t}\n \t\t}\n \t}\n \treturn errs;\n@@ -173,8 +228,9 @@ int cmd_rm(int argc, const char **argv, const char *prefix)\n \t\tstruct cache_entry *ce = active_cache[i];\n \t\tif (!match_pathspec(pathspec, ce->name, ce_namelen(ce), 0, seen))\n \t\t\tcontinue;\n-\t\tALLOC_GROW(list.name, list.nr + 1, list.alloc);\n-\t\tlist.name[list.nr++] = ce->name;\n+\t\tALLOC_GROW(list.entry, list.nr + 1, list.alloc);\n+\t\tlist.entry[list.nr].name = ce->name;\n+\t\tlist.entry[list.nr++].is_submodule = S_ISGITLINK(ce->ce_mode);\n \t}\n\n \tif (pathspec) {\n@@ -215,6 +271,9 @@ int cmd_rm(int argc, const char **argv, const char *prefix)\n \t\t\thashclr(sha1);\n \t\tif (check_local_mod(sha1, index_only))\n \t\t\texit(1);\n+\t} else if (!index_only) {\n+\t\tif (check_submodules_use_gitfiles())\n+\t\t\texit(1);\n \t}\n\n \t/*\n@@ -222,7 +281,7 @@ int cmd_rm(int argc, const char **argv, const char *prefix)\n \t * the index unless all of them succeed.\n \t */\n \tfor (i = 0; i < list.nr; i++) {\n-\t\tconst char *path = list.name[i];\n+\t\tconst char *path = list.entry[i].name;\n \t\tif (!quiet)\n \t\t\tprintf(\"rm '%s'\\n\", path);\n\n@@ -244,7 +303,25 @@ int cmd_rm(int argc, const char **argv, const char *prefix)\n \tif (!index_only) {\n \t\tint removed = 0;\n \t\tfor (i = 0; i < list.nr; i++) {\n-\t\t\tconst char *path = list.name[i];\n+\t\t\tconst char *path = list.entry[i].name;\n+\t\t\tif (list.entry[i].is_submodule) {\n+\t\t\t\tif (is_empty_dir(path)) {\n+\t\t\t\t\tif (!rmdir(path)) {\n+\t\t\t\t\t\tremoved = 1;\n+\t\t\t\t\t\tcontinue;\n+\t\t\t\t\t}\n+\t\t\t\t} else {\n+\t\t\t\t\tstruct strbuf buf = STRBUF_INIT;\n+\t\t\t\t\tstrbuf_addstr(&buf, path);\n+\t\t\t\t\tif (!remove_dir_recursively(&buf, 0)) {\n+\t\t\t\t\t\tremoved = 1;\n+\t\t\t\t\t\tstrbuf_release(&buf);\n+\t\t\t\t\t\tcontinue;\n+\t\t\t\t\t}\n+\t\t\t\t\tstrbuf_release(&buf);\n+\t\t\t\t\t/* Fallthrough and let remove_path() fail. */\n+\t\t\t\t}\n+\t\t\t}\n \t\t\tif (!remove_path(path)) {\n \t\t\t\tremoved = 1;\n \t\t\t\tcontinue;\ndiff --git a/submodule.c b/submodule.c\nindex 19dc6a6..acb2fe0 100644\n--- a/submodule.c\n+++ b/submodule.c\n@@ -758,6 +758,86 @@ unsigned is_submodule_modified(const char *path, int ignore_untracked)\n \treturn dirty_submodule;\n }\n\n+int submodule_uses_gitfile(const char *path)\n+{\n+\tstruct child_process cp;\n+\tconst char *argv[] = {\n+\t\t\"submodule\",\n+\t\t\"foreach\",\n+\t\t\"--quiet\",\n+\t\t\"--recursive\",\n+\t\t\"test -f .git\",\n+\t\tNULL,\n+\t};\n+\tstruct strbuf buf = STRBUF_INIT;\n+\tconst char *git_dir;\n+\n+\tstrbuf_addf(&buf, \"%s/.git\", path);\n+\tgit_dir = read_gitfile(buf.buf);\n+\tif (!git_dir) {\n+\t\tstrbuf_release(&buf);\n+\t\treturn 0;\n+\t}\n+\tstrbuf_release(&buf);\n+\n+\t/* Now test that all nested submodules use a gitfile too */\n+\tmemset(&cp, 0, sizeof(cp));\n+\tcp.argv = argv;\n+\tcp.env = local_repo_env;\n+\tcp.git_cmd = 1;\n+\tcp.no_stdin = 1;\n+\tcp.no_stderr = 1;\n+\tcp.no_stdout = 1;\n+\tcp.dir = path;\n+\tif (run_command(&cp))\n+\t\treturn 0;\n+\n+\treturn 1;\n+}\n+\n+int ok_to_remove_submodule(const char *path)\n+{\n+\tstruct stat st;\n+\tssize_t len;\n+\tstruct child_process cp;\n+\tconst char *argv[] = {\n+\t\t\"status\",\n+\t\t\"--porcelain\",\n+\t\t\"-u\",\n+\t\t\"--ignore-submodules=none\",\n+\t\tNULL,\n+\t};\n+\tstruct strbuf buf = STRBUF_INIT;\n+\tint ok_to_remove = 1;\n+\n+\tif ((lstat(path, &st) < 0) || is_empty_dir(path))\n+\t\treturn 1;\n+\n+\tif (!submodule_uses_gitfile(path))\n+\t\treturn 0;\n+\n+\tmemset(&cp, 0, sizeof(cp));\n+\tcp.argv = argv;\n+\tcp.env = local_repo_env;\n+\tcp.git_cmd = 1;\n+\tcp.no_stdin = 1;\n+\tcp.out = -1;\n+\tcp.dir = path;\n+\tif (start_command(&cp))\n+\t\tdie(\"Could not run 'git status --porcelain -uall --ignore-submodules=none' in submodule %s\", path);\n+\n+\tlen = strbuf_read(&buf, cp.out, 1024);\n+\tif (len > 2)\n+\t\tok_to_remove = 0;\n+\tclose(cp.out);\n+\n+\tif (finish_command(&cp))\n+\t\tdie(\"'git status --porcelain -uall --ignore-submodules=none' failed in submodule %s\", path);\n+\n+\tstrbuf_release(&buf);\n+\treturn ok_to_remove;\n+}\n+\n static int find_first_merges(struct object_array *result, const char *path,\n \t\tstruct commit *a, struct commit *b)\n {\ndiff --git a/submodule.h b/submodule.h\nindex e105b0e..9c0f6a4 100644\n--- a/submodule.h\n+++ b/submodule.h\n@@ -27,6 +27,8 @@ int fetch_populated_submodules(int num_options, const char **options,\n \t\t\t       const char *prefix, int command_line_option,\n \t\t\t       int quiet);\n unsigned is_submodule_modified(const char *path, int ignore_untracked);\n+int submodule_uses_gitfile(const char *path);\n+int ok_to_remove_submodule(const char *path);\n int merge_submodule(unsigned char result[20], const char *path, const unsigned char base[20],\n \t\t    const unsigned char a[20], const unsigned char b[20], int search);\n int find_unpushed_submodules(unsigned char new_sha1[20], const char *remotes_name,\ndiff --git a/t/t3600-rm.sh b/t/t3600-rm.sh\nindex 9fd28bc..61ef529 100755\n--- a/t/t3600-rm.sh\n+++ b/t/t3600-rm.sh\n@@ -262,4 +262,295 @@ test_expect_success 'rm removes subdirectories recursively' '\n \t! test -d dir\n '\n\n+cat >expect <<EOF\n+D  submod\n+EOF\n+\n+cat >expect.modified <<EOF\n+ M submod\n+EOF\n+\n+test_expect_success 'rm removes empty submodules from work tree' '\n+\tmkdir submod &&\n+\tgit update-index --add --cacheinfo 160000 $(git rev-parse HEAD) submod &&\n+\tgit config -f .gitmodules submodule.sub.url ./. &&\n+\tgit config -f .gitmodules submodule.sub.path submod &&\n+\tgit submodule init &&\n+\tgit add .gitmodules &&\n+\tgit commit -m \"add submodule\" &&\n+\tgit rm submod &&\n+\ttest ! -e submod &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success 'rm removes removed submodule from index' '\n+\tgit reset --hard &&\n+\tgit submodule update &&\n+\trm -rf submod &&\n+\tgit rm submod &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success 'rm removes work tree of unmodified submodules' '\n+\tgit reset --hard &&\n+\tgit submodule update &&\n+\tgit rm submod &&\n+\ttest ! -d submod &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success 'rm of a populated submodule with different HEAD fails unless forced' '\n+\tgit reset --hard &&\n+\tgit submodule update &&\n+\t(cd submod &&\n+\t\tgit checkout HEAD^\n+\t) &&\n+\ttest_must_fail git rm submod &&\n+\ttest -d submod &&\n+\ttest -f submod/.git &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\ttest_cmp expect.modified actual &&\n+\tgit rm -f submod &&\n+\ttest ! -d submod &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success 'rm of a populated submodule with modifications fails unless forced' '\n+\tgit reset --hard &&\n+\tgit submodule update &&\n+\t(cd submod &&\n+\t\techo X >empty\n+\t) &&\n+\ttest_must_fail git rm submod &&\n+\ttest -d submod &&\n+\ttest -f submod/.git &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\ttest_cmp expect.modified actual &&\n+\tgit rm -f submod &&\n+\ttest ! -d submod &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success 'rm of a populated submodule with untracked files fails unless forced' '\n+\tgit reset --hard &&\n+\tgit submodule update &&\n+\t(cd submod &&\n+\t\techo X >untracked\n+\t) &&\n+\ttest_must_fail git rm submod &&\n+\ttest -d submod &&\n+\ttest -f submod/.git &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\ttest_cmp expect.modified actual &&\n+\tgit rm -f submod &&\n+\ttest ! -d submod &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success 'setup submodule conflict' '\n+\tgit reset --hard &&\n+\tgit submodule update &&\n+\tgit checkout -b branch1 &&\n+\techo 1 >nitfol &&\n+\tgit add nitfol &&\n+\tgit commit -m \"added nitfol 1\" &&\n+\tgit checkout -b branch2 master &&\n+\techo 2 >nitfol &&\n+\tgit add nitfol &&\n+\tgit commit -m \"added nitfol 2\" &&\n+\tgit checkout -b conflict1 master &&\n+\t(cd submod &&\n+\t\tgit fetch &&\n+\t\tgit checkout branch1\n+\t) &&\n+\tgit add submod &&\n+\tgit commit -m \"submod 1\" &&\n+\tgit checkout -b conflict2 master &&\n+\t(cd submod &&\n+\t\tgit checkout branch2\n+\t) &&\n+\tgit add submod &&\n+\tgit commit -m \"submod 2\"\n+'\n+\n+cat >expect.conflict <<EOF\n+UU submod\n+EOF\n+\n+test_expect_success 'rm of a conflicted populated submodule fails unless forced' '\n+\tgit checkout conflict1 &&\n+\tgit reset --hard &&\n+\tgit submodule update &&\n+\ttest_must_fail git merge conflict2 &&\n+\ttest_must_fail git rm submod &&\n+\ttest -d submod &&\n+\ttest -f submod/.git &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\ttest_cmp expect.conflict actual &&\n+\tgit rm -f submod &&\n+\ttest ! -d submod &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success 'rm of a conflicted populated submodule with a .git directory fails even when forced' '\n+\tgit checkout conflict1 &&\n+\tgit reset --hard &&\n+\tgit submodule update &&\n+\t(cd submod &&\n+\t\trm .git &&\n+\t\tcp -a ../.git/modules/sub .git &&\n+\t\tGIT_WORK_TREE=. git config --unset core.worktree\n+\t) &&\n+\ttest_must_fail git merge conflict2 &&\n+\ttest_must_fail git rm submod &&\n+\ttest -d submod &&\n+\ttest -d submod/.git &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\ttest_cmp expect.conflict actual &&\n+\ttest_must_fail git rm -f submod &&\n+\ttest -d submod &&\n+\ttest -d submod/.git &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\ttest_cmp expect.conflict actual &&\n+\tgit merge --abort &&\n+\trm -rf submod\n+'\n+\n+test_expect_success 'rm of a conflicted unpopulated submodule succeeds' '\n+\tgit checkout conflict1 &&\n+\tgit reset --hard &&\n+\ttest_must_fail git merge conflict2 &&\n+\tgit rm submod &&\n+\ttest ! -d submod &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success 'rm of a populated submodule with a .git directory fails even when forced' '\n+\tgit checkout -f master &&\n+\tgit reset --hard &&\n+\tgit submodule update &&\n+\t(cd submod &&\n+\t\trm .git &&\n+\t\tcp -a ../.git/modules/sub .git &&\n+\t\tGIT_WORK_TREE=. git config --unset core.worktree\n+\t) &&\n+\ttest_must_fail git rm submod &&\n+\ttest -d submod &&\n+\ttest -d submod/.git &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\t! test -s actual &&\n+\ttest_must_fail git rm -f submod &&\n+\ttest -d submod &&\n+\ttest -d submod/.git &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\t! test -s actual &&\n+\trm -rf submod\n+'\n+\n+cat >expect.deepmodified <<EOF\n+ M submod/subsubmod\n+EOF\n+\n+test_expect_success 'setup subsubmodule' '\n+\tgit reset --hard &&\n+\tgit submodule update &&\n+\t(cd submod &&\n+\t\tgit update-index --add --cacheinfo 160000 $(git rev-parse HEAD) subsubmod &&\n+\t\tgit config -f .gitmodules submodule.sub.url ../. &&\n+\t\tgit config -f .gitmodules submodule.sub.path subsubmod &&\n+\t\tgit submodule init &&\n+\t\tgit add .gitmodules &&\n+\t\tgit commit -m \"add subsubmodule\" &&\n+\t\tgit submodule update subsubmod\n+\t) &&\n+\tgit commit -a -m \"added deep submodule\"\n+'\n+\n+test_expect_success 'rm recursively removes work tree of unmodified submodules' '\n+\tgit rm submod &&\n+\ttest ! -d submod &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success 'rm of a populated nested submodule with different nested HEAD fails unless forced' '\n+\tgit reset --hard &&\n+\tgit submodule update --recursive &&\n+\t(cd submod/subsubmod &&\n+\t\tgit checkout HEAD^\n+\t) &&\n+\ttest_must_fail git rm submod &&\n+\ttest -d submod &&\n+\ttest -f submod/.git &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\ttest_cmp expect.modified actual &&\n+\tgit rm -f submod &&\n+\ttest ! -d submod &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success 'rm of a populated nested submodule with nested modifications fails unless forced' '\n+\tgit reset --hard &&\n+\tgit submodule update --recursive &&\n+\t(cd submod/subsubmod &&\n+\t\techo X >empty\n+\t) &&\n+\ttest_must_fail git rm submod &&\n+\ttest -d submod &&\n+\ttest -f submod/.git &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\ttest_cmp expect.modified actual &&\n+\tgit rm -f submod &&\n+\ttest ! -d submod &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success 'rm of a populated nested submodule with nested untracked files fails unless forced' '\n+\tgit reset --hard &&\n+\tgit submodule update --recursive &&\n+\t(cd submod/subsubmod &&\n+\t\techo X >untracked\n+\t) &&\n+\ttest_must_fail git rm submod &&\n+\ttest -d submod &&\n+\ttest -f submod/.git &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\ttest_cmp expect.modified actual &&\n+\tgit rm -f submod &&\n+\ttest ! -d submod &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success 'rm of a populated nested submodule with a nested .git directory fails even when forced' '\n+\tgit reset --hard &&\n+\tgit submodule update --recursive &&\n+\t(cd submod/subsubmod &&\n+\t\trm .git &&\n+\t\tcp -a ../../.git/modules/sub/modules/sub .git &&\n+\t\tGIT_WORK_TREE=. git config --unset core.worktree\n+\t) &&\n+\ttest_must_fail git rm submod &&\n+\ttest -d submod &&\n+\ttest -d submod/subsubmod/.git &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\t! test -s actual &&\n+\ttest_must_fail git rm -f submod &&\n+\ttest -d submod &&\n+\ttest -d submod/subsubmod/.git &&\n+\tgit status -s -uno --ignore-submodules=none > actual &&\n+\t! test -s actual &&\n+\trm -rf submod\n+'\n+\n test_done\n-- \n1.7.12.316.gac65367\n"},{"id":"198807","messageId":"7vhar4gxdq.fsf@alter.siamese.dyndns.org","threadId":"31496","inReplyTo":"504F8427.1020507@web.de","subject":"Re: [PATCH v3] Teach rm to remove submodules unless they contain a git directory","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-11T19:41:53Z","receivedAt":"2012-09-11T19:41:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann <Jens.Lehmann@web.de> writes:\n\n>> * jl/submodule-rm (2012-08-27) 1 commit\n>>  - Teach rm to remove submodules unless they contain a git directory\n>> \n>> \"git rm submodule\" cannot blindly remove a submodule directory as\n>> its working tree may have local changes, and worse yet, it may even\n>> have its repository embedded in it.  Teach it some special cases\n>> where it is safe to remove a submodule, specifically, when there is\n>> no local changes in the submodule working tree, and its repository\n>> is not embedded in its working tree but is elsewhere and uses the\n>> gitfile mechanism to point at it.\n>> \n>> I lost track; what is the doneness of the discussion on this patch?\n>\n> The review of v2 revealed that in case of submodule merge conflicts\n> the necessary checks weren't done. This (and the minor issues raised\n> in http://permalink.gmane.org/gmane.comp.version-control.git/204370)\n> is fixed in this version.\n\nThanks.  I wish all others paid attention to \"What's cooking\" like\nyou did here.\n\nAnd if it is hard to do so for whatever reason, suggest a better way\nfor me to publish \"What's cooking\" or an equivalent (I am interested\nin finding the least bureaucratic way to help people and keep the\nballs rolling).\n\n> +static int check_submodules_use_gitfiles(void)\n> +{\n> +\tint i;\n> +\tint errs = 0;\n> +\n> +\tfor (i = 0; i < list.nr; i++) {\n> +\t\tconst char *name = list.entry[i].name;\n> +\t\tint pos;\n> +\t\tstruct cache_entry *ce;\n> +\t\tstruct stat st;\n> +\n> +\t\tpos = cache_name_pos(name, strlen(name));\n> +\t\tif (pos < 0)\n> +\t\t\tpos = -pos-1;\n> +\t\tce = active_cache[pos];\n> +\n> +\t\tif (!S_ISGITLINK(ce->ce_mode) ||\n> +\t\t    (lstat(ce->name, &st) < 0) ||\n> +\t\t    is_empty_dir(name))\n> +\t\t\tcontinue;\n\nIf the name doesn't exist in the index (i.e. \"list\" has names that\ndo not exist in the index for whatever reason), a negative pos is\nreturned to tell you where it _would_ be inserted if you said \"git\nadd\" the path.  But these names in the \"list\" are guaranteed to\nexist in the index in _some_ form, so for a negative pos, (-pos-1)\nwill have the conflicted entry at the lowest stage (typically the\ncommon ancestor's version).  I am not sure checking only that one is\nsufficient, though.  Wouldn't you want to at least check stage #2\n(ours, which should most resemble the working tree)?  If this were\n\"common ancestor had it as a submodule, our side removed it and\ncreated something else, their side updated the submodule\" conflict,\nthe stage #2 would not be a gitlink (it would be a blob if that\nsomething else is a file, or may be missing if the submodule was\nreplaced with a directory), and the path ce->name would definitely\nnot be a submodule.\n\n> +\t\tif (!submodule_uses_gitfile(name))\n> +\t\t\terrs = error(_(\"submodule '%s' (or one of its nested \"\n> +\t\t\t\t     \"submodules) uses a .git directory\\n\"\n> +\t\t\t\t     \"(use 'rm -rf' if you really want to remove \"\n> +\t\t\t\t     \"it including all of its history)\"), name);\n> +\t}\n> +\n> +\treturn errs;\n> +}\n> +\n>  static int check_local_mod(unsigned char *head, int index_only)\n>  {\n>  \t/*\n> @@ -37,15 +72,23 @@ static int check_local_mod(unsigned char *head, int index_only)\n>  \t\tstruct stat st;\n>  \t\tint pos;\n>  \t\tstruct cache_entry *ce;\n> -\t\tconst char *name = list.name[i];\n> +\t\tconst char *name = list.entry[i].name;\n>  \t\tunsigned char sha1[20];\n>  \t\tunsigned mode;\n>  \t\tint local_changes = 0;\n>  \t\tint staged_changes = 0;\n>\n>  \t\tpos = cache_name_pos(name, strlen(name));\n> -\t\tif (pos < 0)\n> -\t\t\tcontinue; /* removing unmerged entry */\n> +\t\tif (pos < 0) {\n> +\t\t\t/*\n> +\t\t\t * Skip unmerged entries except for populated submodules\n> +\t\t\t * that could loose history when removed.\n\ns/loose/lose/\n\n> +\t\t\t */\n> +\t\t\tpos = -pos-1;\n> +\t\t\tif (!S_ISGITLINK(active_cache[pos]->ce_mode) ||\n> +\t\t\t    is_empty_dir(name))\n> +\t\t\t\tcontinue;\n> +\t\t}\n\nLilewise.  It may make sense to introduce a helper function to tell\nif it is a submodule on our side by checking only the stage #2 entry\nwhen you see a nagetive pos returned from cache_name_pos() and call\nit \"is_ours_submodule?()\" or something.\n"},{"id":"198872","messageId":"5050E0CA.7080907@web.de","threadId":"31496","inReplyTo":"7vhar4gxdq.fsf@alter.siamese.dyndns.org","subject":"Suggestions for \"What's cooking\"","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-09-12T19:21:46Z","receivedAt":"2012-09-12T19:21:46Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 11.09.2012 21:41, schrieb Junio C Hamano:\n> Thanks.  I wish all others paid attention to \"What's cooking\" like\n> you did here.\n> \n> And if it is hard to do so for whatever reason, suggest a better way\n> for me to publish \"What's cooking\" or an equivalent (I am interested\n> in finding the least bureaucratic way to help people and keep the\n> balls rolling).\n\nI think \"What's cooking\" makes lots of sense in its current form\nas one gets a very good overview over current development tracks.\n\nMaybe in addition it would be nice to email the author(s) of a\nseries when the state changes or new comments are added (and to\nonly include the relevant part from \"What's cooking\" there). For\nme it's not a big problem as I just have to grep for \"submodule\"\nto get the bits I care about, but I suspect others might have to\ninvest much more time to check the current state of their series\nand may appreciate being mailed directly when something happens.\nOpinions?\n"},{"id":"198873","messageId":"5050E161.9080203@web.de","threadId":"31496","inReplyTo":"7vhar4gxdq.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v3] Teach rm to remove submodules unless they contain a git directory","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-09-12T19:24:17Z","receivedAt":"2012-09-12T19:24:17Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 11.09.2012 21:41, schrieb Junio C Hamano:\n> Lilewise.  It may make sense to introduce a helper function to tell\n> if it is a submodule on our side by checking only the stage #2 entry\n> when you see a nagetive pos returned from cache_name_pos() and call\n> it \"is_ours_submodule?()\" or something.\n\nThanks, will do so.\n"},{"id":"198874","messageId":"20120912193705.GA26587@sigill.intra.peff.net","threadId":"31496","inReplyTo":"5050E0CA.7080907@web.de","subject":"Re: Suggestions for \"What's cooking\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-09-12T19:37:05Z","receivedAt":"2012-09-12T19:37:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Sep 12, 2012 at 09:21:46PM +0200, Jens Lehmann wrote:\n\n> Am 11.09.2012 21:41, schrieb Junio C Hamano:\n> > Thanks.  I wish all others paid attention to \"What's cooking\" like\n> > you did here.\n> > \n> > And if it is hard to do so for whatever reason, suggest a better way\n> > for me to publish \"What's cooking\" or an equivalent (I am interested\n> > in finding the least bureaucratic way to help people and keep the\n> > balls rolling).\n> \n> I think \"What's cooking\" makes lots of sense in its current form\n> as one gets a very good overview over current development tracks.\n>\n> Maybe in addition it would be nice to email the author(s) of a\n> series when the state changes or new comments are added (and to\n> only include the relevant part from \"What's cooking\" there).\n\nYeah, in general I think the current system is fine. It might be\nslightly more convenient to send out the update email, but finding the\nright thread is more work for Junio (I guess you could just ignore that\nand start a new thread, but for readers it is nice if it is connected to\nthe original series thread).\n\nAnd I personally think it is nice to read through the whole list of\ntopics and their current status occasionally. I sometimes end up\ncommenting on a topic that I probably would not have otherwise seen that\nway.  Of course, I likely have a lot more git time than most people, so\nthe effort of skimming \"what's cooking\" is not too high for me.\n\n-Peff\n"},{"id":"198877","messageId":"CAPBPrnu9adK0mPLyVfimAzBEo7ZH+6HhqtLBRFWAvEA9mEGFfg@mail.gmail.com","threadId":"31496","inReplyTo":"5050E0CA.7080907@web.de","subject":"Re: Suggestions for \"What's cooking\"","fromName":"Dan Johnson","fromEmail":"computerdruid@gmail.com","sentAt":"2012-09-12T20:08:40Z","receivedAt":"2012-09-12T20:08:40Z","isPatch":false,"sender":{"key":"computerdruid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/34696?v=4"},"body":"On Wed, Sep 12, 2012 at 3:21 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:\n> Am 11.09.2012 21:41, schrieb Junio C Hamano:\n>> Thanks.  I wish all others paid attention to \"What's cooking\" like\n>> you did here.\n>>\n>> And if it is hard to do so for whatever reason, suggest a better way\n>> for me to publish \"What's cooking\" or an equivalent (I am interested\n>> in finding the least bureaucratic way to help people and keep the\n>> balls rolling).\n>\n> I think \"What's cooking\" makes lots of sense in its current form\n> as one gets a very good overview over current development tracks.\n>\n> Maybe in addition it would be nice to email the author(s) of a\n> series when the state changes or new comments are added (and to\n> only include the relevant part from \"What's cooking\" there). For\n> me it's not a big problem as I just have to grep for \"submodule\"\n> to get the bits I care about, but I suspect others might have to\n> invest much more time to check the current state of their series\n> and may appreciate being mailed directly when something happens.\n> Opinions?\n\nI was thinking about this earlier. I wondered if it might even be\nworth it just to CC the authors of all topics whose status has changed\nsince the last what's cooking, to make sure that they see updates\npertinent to them. I know that I at least have filters which catch\nemails which CC me and promote them to my inbox, so I would see them\nmore readily.\n\nMy normal mode of operation is that when I have a patch in I check all\nthe \"What's cooking\" messages as if I was F5-ing a webpage, to follow\nits status. Were I CCd on the message, I would be updated whenever the\nmail was sent, which I would appreciate. This also has the nice side\neffect of updating patch authors who are not subscribed to the list.\n\nOn the other hand, its possible some people would find that this\ngenerated lots of noise, and it might also cause unrelated replies to\nthe \"What's Cooking\" message to CC all authors.\n-- \n-Dan\n"},{"id":"198888","messageId":"7vligec3o5.fsf@alter.siamese.dyndns.org","threadId":"31496","inReplyTo":"CAPBPrnu9adK0mPLyVfimAzBEo7ZH+6HhqtLBRFWAvEA9mEGFfg@mail.gmail.com","subject":"Re: Suggestions for \"What's cooking\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-12T21:49:30Z","receivedAt":"2012-09-12T21:49:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dan Johnson <computerdruid@gmail.com> writes:\n\n> I was thinking about this earlier. I wondered if it might even be\n> worth it just to CC the authors of all topics whose status has changed\n> since the last what's cooking, to make sure that they see updates\n> pertinent to them. I know that I at least have filters which catch\n> emails which CC me and promote them to my inbox, so I would see them\n> more readily.\n\nI've done that a few times per release cycle, usually before we go\ninto the pre-release freeze, but doing so manually is very time\nconsuming.  It's the kind of bureaucratic overhead I'd rather avoid.\nIf somebody volunteers to write a script that takes something like\n\n    git diff whats-cooking.txt\n\nin a checkout of the 'todo' branch and figure out whom to Cc, and do\nso reliably, it may be an option.\n\nThanks.\n"},{"id":"198895","messageId":"A7A1DB46082142E683753CFBC0A22A6B@PhilipOakley","threadId":"31496","inReplyTo":"5050E0CA.7080907@web.de","subject":"Re: Suggestions for \"What's cooking\"","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2012-09-12T22:49:15Z","receivedAt":"2012-09-12T22:49:15Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jens Lehmann\" <Jens.Lehmann@web.de>\nSent: Wednesday, September 12, 2012 8:21 PM\n> Am 11.09.2012 21:41, schrieb Junio C Hamano:\n>> Thanks.  I wish all others paid attention to \"What's cooking\" like\n>> you did here.\n>>\n>> And if it is hard to do so for whatever reason, suggest a better way\n>> for me to publish \"What's cooking\" or an equivalent (I am interested\n>> in finding the least bureaucratic way to help people and keep the\n>> balls rolling).\n>\n> I think \"What's cooking\" makes lots of sense in its current form\n> as one gets a very good overview over current development tracks.\n>\n> Maybe in addition it would be nice to email the author(s) of a\n> series when the state changes or new comments are added (and to\n> only include the relevant part from \"What's cooking\" there). For\n> me it's not a big problem as I just have to grep for \"submodule\"\n> to get the bits I care about, but I suspect others might have to\n> invest much more time to check the current state of their series\n> and may appreciate being mailed directly when something happens.\n> Opinions?\n\nMy comment, as a simple reader, is that I misread the order of the \nitems, in that I miss-associate the description paragraph with the * \ntitle _below_. That is, I see the description first and then read on...\n\nThinking about it, if the description paragraph was indented by one \nspace then the * title  would create that obvious content indent that (I \nam) would be expected.\n\nObviously only a useful suggestion if it's easy to implement...\n\nPhilip \n"},{"id":"198898","messageId":"CAH5451kmwZehys4nL+NV8m8VGjDJtkSxru3o44_J_d3jD5ipxA@mail.gmail.com","threadId":"31496","inReplyTo":"A7A1DB46082142E683753CFBC0A22A6B@PhilipOakley","subject":"Re: Suggestions for \"What's cooking\"","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-09-13T05:14:26Z","receivedAt":"2012-09-13T05:14:26Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"(sorry about double replying - html sub-part creeped in!)\nOn 13 September 2012 08:49, Philip Oakley <philipoakley@iee.org> wrote:\n>\n> From: \"Jens Lehmann\" <Jens.Lehmann@web.de>\n> Sent: Wednesday, September 12, 2012 8:21 PM\n>\n>> Am 11.09.2012 21:41, schrieb Junio C Hamano:\n>>>\n>>> Thanks.  I wish all others paid attention to \"What's cooking\" like\n>>> you did here.\n>>>\n>>> And if it is hard to do so for whatever reason, suggest a better way\n>>> for me to publish \"What's cooking\" or an equivalent (I am interested\n>>> in finding the least bureaucratic way to help people and keep the\n>>> balls rolling).\n>>\n>>\n>> I think \"What's cooking\" makes lots of sense in its current form\n>> as one gets a very good overview over current development tracks.\n>>\n>> Maybe in addition it would be nice to email the author(s) of a\n>> series when the state changes or new comments are added (and to\n>> only include the relevant part from \"What's cooking\" there). For\n>> me it's not a big problem as I just have to grep for \"submodule\"\n>> to get the bits I care about, but I suspect others might have to\n>> invest much more time to check the current state of their series\n>> and may appreciate being mailed directly when something happens.\n>> Opinions?\n>\n>\n> My comment, as a simple reader, is that I misread the order of the items, in that I miss-associate the description paragraph with the * title _below_. That is, I see the description first and then read on...\n>\n> Thinking about it, if the description paragraph was indented by one space then the * title  would create that obvious content indent that (I am) would be expected.\n>\n> Obviously only a useful suggestion if it's easy to implement...\n\n\nI can attest to the fact that the format can be at times difficult to\nparse, and I often find myself rereading sections to make sure I\nunderstood what each was referring to.\n\nAs a casual reader, interested in the development that is going on,\nthe things I am interested in for each branch/topic are like:\n - Branch/Topic description\n - Current integration status\n - Next steps required\n - Notes and memoranda\n\nI understand that references to where the branch is found (it's name)\nand what it includes (commit list) are important too, but these are\nless important for me.\n\nCurrently, the output for each branch looks something like:\n* <branch-name> (<creation-date>) <number-of-commits>\n  (<merge-status>)\n [list-of-commits]\n  (<branch-usage>)\n<long-description>\n<notes-and-memoranda>\n<next-steps>\n\nand these are grouped by current integration status (new, graduated,\nstalled etc)\n\nA format that would make this information easier for me to parse would\nbe something like:\n\n<short-branch-description>\n  <long-branch-description>\n  <notes>\n  <next-steps>\n  * <branch-name> (<creation-date>) <number-of-commits>\n    (<merge-status>)\n   [list-of-commits]\n    (<branch-usage>)\n\nEssentially, shifting the details of the branch to the bottom, and\nadding a short description for the entire branch. Indent everything\nafter the short description to make it clear that they belong\ntogether.\n\nThe only real 'new' information required is the short description, but\nthat could be replaced with the topic name if short description is not\navailable (or the topic name is self explanatory).\n\nMost of the parsing benefit would come from the indentation, but\nhaving the 'summary' information near the top would let me skip things\nI am not interested in without having to scan the list of commits and\nother details.\n\nRegards,\n\nAndrew Ardill\n"},{"id":"198901","messageId":"505186A0.40500@alum.mit.edu","threadId":"31496","inReplyTo":"A7A1DB46082142E683753CFBC0A22A6B@PhilipOakley","subject":"Re: Suggestions for \"What's cooking\"","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-09-13T07:09:20Z","receivedAt":"2012-09-13T07:09:20Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 09/13/2012 12:49 AM, Philip Oakley wrote:\n> My comment, as a simple reader, is that I misread the order of the \n> items, in that I miss-associate the description paragraph with the * \n> title _below_. That is, I see the description first and then read on...\n> \n> Thinking about it, if the description paragraph was indented by one \n> space then the * title  would create that obvious content indent that (I \n> am) would be expected.\n\n+1.  When I started reading the \"What's cooking\", I found it hard to\ntell/remember whether text comments apply to the list of patches above\nthem or below them.  If you don't want to make bigger changes to the\nformat, then even an extra blank line between the section about each\npatch series would remove the ambiguity.\n\nOtherwise, I think that \"What's cooking\" emails are a great service that\nyou provide to the community.  They help mitigate the inconvenience of\nusing emails rather than pull requests for exchanging and managing\npatches :-)\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"198904","messageId":"90925598F9104F7FAC680544FABE0A79@PhilipOakley","threadId":"31496","inReplyTo":"A7A1DB46082142E683753CFBC0A22A6B@PhilipOakley","subject":"Re: Suggestions for \"What's cooking\"","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2012-09-13T07:21:45Z","receivedAt":"2012-09-13T07:21:45Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Philip Oakley\" <philipoakley@iee.org>\nSent: Wednesday, September 12, 2012 11:49 PM\n> From: \"Jens Lehmann\" <Jens.Lehmann@web.de>\n> Sent: Wednesday, September 12, 2012 8:21 PM\n>> Am 11.09.2012 21:41, schrieb Junio C Hamano:\n>>> Thanks.  I wish all others paid attention to \"What's cooking\" like\n>>> you did here.\n>>>\n>>> And if it is hard to do so for whatever reason, suggest a better way\n>>> for me to publish \"What's cooking\" or an equivalent (I am interested\n>>> in finding the least bureaucratic way to help people and keep the\n>>> balls rolling).\n>>\n>> I think \"What's cooking\" makes lots of sense in its current form\n>> as one gets a very good overview over current development tracks.\n>>\n>> Maybe in addition it would be nice to email the author(s) of a\n>> series when the state changes or new comments are added (and to\n>> only include the relevant part from \"What's cooking\" there). For\n>> me it's not a big problem as I just have to grep for \"submodule\"\n>> to get the bits I care about, but I suspect others might have to\n>> invest much more time to check the current state of their series\n>> and may appreciate being mailed directly when something happens.\n>> Opinions?\n>\n> My comment, as a simple reader, is that I misread the order of the \n> items, in that I miss-associate the description paragraph with the * \n> title _below_. That is, I see the description first and then read \n> on...\n>\n> Thinking about it, if the description paragraph was indented by one \n> space then the * title  would create that obvious content indent that \n> (I am) would be expected.\n>\n> Obviously only a useful suggestion if it's easy to implement...\n>\n> Philip\nThinking overnight. One very simple option is to just add a double line \nspacing between items to give a clearer break.\n\n i.e.\nprevious item ends.LF\nLF\nLF\n* Next Item \n"},{"id":"198927","messageId":"7vlige9cyx.fsf@alter.siamese.dyndns.org","threadId":"31496","inReplyTo":"90925598F9104F7FAC680544FABE0A79@PhilipOakley","subject":"Re: Suggestions for \"What's cooking\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-13T15:09:10Z","receivedAt":"2012-09-13T15:09:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" <philipoakley@iee.org> writes:\n\n>> Thinking about it, if the description paragraph was indented by one\n>> space then the * title  would create that obvious content indent\n>> that (I am) would be expected.\n>>\n>> Obviously only a useful suggestion if it's easy to implement...\n>>\n>> Philip\n> Thinking overnight. One very simple option is to just add a double\n> line spacing between items to give a clearer break.\n\nI've played with both and have prepared patches to Reintegrate and\ncook (both in the 'todo' branch).  Will play with the changes a bit\nmore and then decide.\n\nThanks.\n"},{"id":"198945","messageId":"7vmx0t94rc.fsf@alter.siamese.dyndns.org","threadId":"31496","inReplyTo":"CAH5451kmwZehys4nL+NV8m8VGjDJtkSxru3o44_J_d3jD5ipxA@mail.gmail.com","subject":"Re: Suggestions for \"What's cooking\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-13T18:06:31Z","receivedAt":"2012-09-13T18:06:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Ardill <andrew.ardill@gmail.com> writes:\n\n> Currently, the output for each branch looks something like:\n> * <branch-name> (<creation-date>) <number-of-commits>\n>   (<merge-status>)\n>  [list-of-commits]\n>   (<branch-usage>)\n> <long-description>\n> <notes-and-memoranda>\n> <next-steps>\n>\n> and these are grouped by current integration status (new, graduated,\n> stalled etc)\n\nYes.  Thanks for a concise summary.\n\n> A format that would make this information easier for me to parse would\n> be something like:\n>\n> <short-branch-description>\n>   <long-branch-description>\n>   <notes>\n>   <next-steps>\n>   * <branch-name> (<creation-date>) <number-of-commits>\n>     (<merge-status>)\n>    [list-of-commits]\n>     (<branch-usage>)\n\nI do not see how it makes any sense to have the \"This is where the\nsection begins with, and its name is this\" line in the middle of a\nblock indented in such a way.  Care to explain?\n\nI can see some people may care more about the description than the\nlist of commits [*1*], though.\n\n\n[Footnote]\n\n*1* It however is an indication that the title of each commit needs\nto be improved to convey enough information so that I do not have to\nwrite the branch description myself for them.\n"},{"id":"198988","messageId":"CAH5451n3bAkidWrtu4sy=NXPYZ7wWc+WFoReOm98xq2S22+55w@mail.gmail.com","threadId":"31496","inReplyTo":"7vmx0t94rc.fsf@alter.siamese.dyndns.org","subject":"Re: Suggestions for \"What's cooking\"","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-09-14T02:11:49Z","receivedAt":"2012-09-14T02:11:49Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 14 September 2012 04:06, Junio C Hamano <gitster@pobox.com> wrote:\n> Andrew Ardill <andrew.ardill@gmail.com> writes:\n>\n>> Currently, the output for each branch looks something like:\n>> * <branch-name> (<creation-date>) <number-of-commits>\n>>   (<merge-status>)\n>>  [list-of-commits]\n>>   (<branch-usage>)\n>> <long-description>\n>> <notes-and-memoranda>\n>> <next-steps>\n>>\n>> and these are grouped by current integration status (new, graduated,\n>> stalled etc)\n>\n> Yes.  Thanks for a concise summary.\n>\n>> A format that would make this information easier for me to parse would\n>> be something like:\n>>\n>> <short-branch-description>\n>>   <long-branch-description>\n>>   <notes>\n>>   <next-steps>\n>>   * <branch-name> (<creation-date>) <number-of-commits>\n>>     (<merge-status>)\n>>    [list-of-commits]\n>>     (<branch-usage>)\n>\n> I do not see how it makes any sense to have the \"This is where the\n> section begins with, and its name is this\" line in the middle of a\n> block indented in such a way.  Care to explain?\n\nI'm not quite sure what aspect you are referring to, so let me just\nexpand my reasoning a little bit and hopefully that clears things up.\n\nFirst of all, I didn't spend that much time thinking through the\nlayout, merely re-arranged things so that what I considered most\nimportant was at the start of each listing. I kept everything else the\nsame, with an extra level of indentation for everything except the\nfirst line of each listing. Perhaps modifying the existing indentation\nto better fit in this layout is in order, but that is in some ways\northogonal to the ideas I was trying to present.\n\nI am not against changing how each listing is laid out in a more\ndisruptive way, this was just a first attempt at making it easier to\nparse.\n\nI like the idea proposed by others to increase whitespace between\nlistings to make each stand out, however I think indentation is a\nbetter method.\n* Increased whitespace between listings lengthens the entire list,\nrequiring more scrolling and decreasing the amount of information on\neach page. Simply indenting most lines by a few columns of whitespace\nmay cause some lines to wrap, but in general will not lengthen the\nlisting or decrease information density. [edit] I realised after\nwriting this that the addition of a <short-branch-description> does\nactually increase the length of the listing, however it does not\ndecrease information density as much as a blank line.\n* The visual difference between two blank lines and one is\nsignificant, but not as distinct as the presence (or not) of a\ncharacter in the first column of text. In scanning a long document, I\npropose that finding a line that starts in the first column of text is\neasier than finding the next line which is preceded by two blank\nlines. Similarly jumping forwards or backwards a listing would be\neasier.\n\nThis is all a little academic though, so lets compare both versions\nwith an excerpt from the most recent \"What's cooking\"!\n\nFirst, the extra blank line\n\n-- >8 --\n* jc/maint-blame-no-such-path (2012-09-10) 1 commit\n - blame $path: avoid getting fooled by case insensitive filesystems\n\n\"git blame MAKEFILE\" run in a history that has \"Makefile\" but not\n\"MAKEFILE\" should say \"No such file MAKEFILE in HEAD\", but got\nconfused on a case insensitive filesystem.\n\n\n* sl/autoconf (2012-09-11) 2 commits\n - build: don't duplicate substitution of make variables\n - build: improve GIT_CONF_SUBST signature\n\n\n* cn/branch-set-upstream-to (2012-09-11) 2 commits\n - completion: complete branch name for \"branch --set-upstream-to=\"\n - completion: add --set-upstream-to and --unset-upstream\n\nWill merge to 'next'.\n\n--------------------------------------------------\n[Graduated to \"master\"]\n\n* jc/maint-ident-missing-human-name (2012-08-31) 1 commit\n  (merged to 'next' on 2012-09-07 at 0e99b20)\n + split_ident_line(): make best effort when parsing author/committer line\n\n\"git show --format='%ci'\" did not give timestamp correctly for\ncommits created without human readable name on \"committer\" line.\n\n\n* jc/merge-bases (2012-08-31) 9 commits\n  (merged to 'next' on 2012-09-07 at ab0974d)\n + reduce_heads(): reimplement on top of remove_redundant()\n + merge-base: \"--is-ancestor A B\"\n + get_merge_bases_many(): walk from many tips in parallel\n + in_merge_bases(): use paint_down_to_common()\n + merge_bases_many(): split out the logic to paint history\n + in_merge_bases(): omit unnecessary redundant common ancestor reduction\n + http-push: use in_merge_bases() for fast-forward check\n + receive-pack: use in_merge_bases() for fast-forward check\n + in_merge_bases(): support only one \"other\" commit\n\nOptimise the \"merge-base\" computation a bit, and also update its\nusers that do not need the full merge-base information to call a\ncheaper subset.\n\n-- 8< --\n\nNow, the extra indentation and re-organised contents\n\n-- >8 --\njc/maint-blame-no-such-path\n  \"git blame MAKEFILE\" run in a history that has \"Makefile\" but not\n  \"MAKEFILE\" should say \"No such file MAKEFILE in HEAD\", but got\n  confused on a case insensitive filesystem.\n\n  * jc/maint-blame-no-such-path (2012-09-10) 1 commit\n   - blame $path: avoid getting fooled by case insensitive filesystems\n\nsl/autoconf\n  * sl/autoconf (2012-09-11) 2 commits\n   - build: don't duplicate substitution of make variables\n   - build: improve GIT_CONF_SUBST signature\n\ncn/branch-set-upstream-to\n  Will merge to 'next'.\n\n  * cn/branch-set-upstream-to (2012-09-11) 2 commits\n   - completion: complete branch name for \"branch --set-upstream-to=\"\n   - completion: add --set-upstream-to and --unset-upstream\n\n--------------------------------------------------\n[Graduated to \"master\"]\n\njc/maint-ident-missing-human-name\n  \"git show --format='%ci'\" did not give timestamp correctly for\n  commits created without human readable name on \"committer\" line.\n\n  * jc/maint-ident-missing-human-name (2012-08-31) 1 commit\n    (merged to 'next' on 2012-09-07 at 0e99b20)\n   + split_ident_line(): make best effort when parsing author/committer line\n\njc/merge-bases\n  Optimise the \"merge-base\" computation a bit, and also update its\n  users that do not need the full merge-base information to call a\n  cheaper subset.\n\n  * jc/merge-bases (2012-08-31) 9 commits\n    (merged to 'next' on 2012-09-07 at ab0974d)\n   + reduce_heads(): reimplement on top of remove_redundant()\n   + merge-base: \"--is-ancestor A B\"\n   + get_merge_bases_many(): walk from many tips in parallel\n   + in_merge_bases(): use paint_down_to_common()\n   + merge_bases_many(): split out the logic to paint history\n   + in_merge_bases(): omit unnecessary redundant common ancestor reduction\n   + http-push: use in_merge_bases() for fast-forward check\n   + receive-pack: use in_merge_bases() for fast-forward check\n   + in_merge_bases(): support only one \"other\" commit\n-- 8< --\n\nI personally find the second much more useful, but perhaps the\ncomparison will help other people evaluate them both.\n\n>\n> I can see some people may care more about the description than the\n> list of commits [*1*], though.\n>\n>\n> [Footnote]\n>\n> *1* It however is an indication that the title of each commit needs\n> to be improved to convey enough information so that I do not have to\n> write the branch description myself for them.\n\nI remember something about including topic descriptions being\ndescribed when signed tag pull requests were being designed, could\nthat information potentially be coerced if available?\n\nRegards,\n\nAndrew Ardill\n"},{"id":"198989","messageId":"7vboh99w1z.fsf@alter.siamese.dyndns.org","threadId":"31496","inReplyTo":"CAH5451n3bAkidWrtu4sy=NXPYZ7wWc+WFoReOm98xq2S22+55w@mail.gmail.com","subject":"Re: Suggestions for \"What's cooking\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-14T02:29:12Z","receivedAt":"2012-09-14T02:29:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Ardill <andrew.ardill@gmail.com> writes:\n\n> On 14 September 2012 04:06, Junio C Hamano <gitster@pobox.com> wrote:\n>> Andrew Ardill <andrew.ardill@gmail.com> writes:\n>>\n>>> <short-branch-description>\n>>>   <long-branch-description>\n>>>   <notes>\n>>>   <next-steps>\n>>>   * <branch-name> (<creation-date>) <number-of-commits>\n>>>     (<merge-status>)\n>>>    [list-of-commits]\n>>>     (<branch-usage>)\n>>\n>> I do not see how it makes any sense to have the \"This is where the\n>> section begins with, and its name is this\" line in the middle of a\n>> block indented in such a way.  Care to explain?\n>\n> I'm not quite sure what aspect you are referring to,...\n\nJust this part, as I do not have much time.  Here is your reordered\none I will reject:\n\n  A > jc/maint-blame-no-such-path\n    >   \"git blame MAKEFILE\" run in a history that has \"Makefile\" but not\n    >   \"MAKEFILE\" should say \"No such file MAKEFILE in HEAD\", but got\n    >   confused on a case insensitive filesystem.\n    >\n  B >   * jc/maint-blame-no-such-path (2012-09-10) 1 commit\n    >    - blame $path: avoid getting fooled by case insensitive filesystems\n\nI was noting that B which *is* formatted as a header line (it EVEN\nhas a leading asterisk to make it clear that it begins something\nnew) is in the middle, and you added a redundant A that is not even\nmarked clearly as a header line.\n"},{"id":"198990","messageId":"CAH5451m28z_5Hbtyqx3+YkR-CoTNFB9bjLx6A1cJJXtj3hVjQQ@mail.gmail.com","threadId":"31496","inReplyTo":"7vboh99w1z.fsf@alter.siamese.dyndns.org","subject":"Re: Suggestions for \"What's cooking\"","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-09-14T03:58:05Z","receivedAt":"2012-09-14T03:58:05Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 14 September 2012 12:29, Junio C Hamano <gitster@pobox.com> wrote:\n> Andrew Ardill <andrew.ardill@gmail.com> writes:\n>\n>> On 14 September 2012 04:06, Junio C Hamano <gitster@pobox.com> wrote:\n>>> Andrew Ardill <andrew.ardill@gmail.com> writes:\n>>>\n>>>> <short-branch-description>\n>>>>   <long-branch-description>\n>>>>   <notes>\n>>>>   <next-steps>\n>>>>   * <branch-name> (<creation-date>) <number-of-commits>\n>>>>     (<merge-status>)\n>>>>    [list-of-commits]\n>>>>     (<branch-usage>)\n>>>\n>>> I do not see how it makes any sense to have the \"This is where the\n>>> section begins with, and its name is this\" line in the middle of a\n>>> block indented in such a way.  Care to explain?\n>>\n>> I'm not quite sure what aspect you are referring to,...\n>\n> Just this part, as I do not have much time.  Here is your reordered\n> one I will reject:\n>\n>   A > jc/maint-blame-no-such-path\n>     >   \"git blame MAKEFILE\" run in a history that has \"Makefile\" but not\n>     >   \"MAKEFILE\" should say \"No such file MAKEFILE in HEAD\", but got\n>     >   confused on a case insensitive filesystem.\n>     >\n>   B >   * jc/maint-blame-no-such-path (2012-09-10) 1 commit\n>     >    - blame $path: avoid getting fooled by case insensitive filesystems\n>\n> I was noting that B which *is* formatted as a header line (it EVEN\n> has a leading asterisk to make it clear that it begins something\n> new) is in the middle, and you added a redundant A that is not even\n> marked clearly as a header line.\n\nThe leading asterisk is actually not as useful to me, as indicating a\nheader line, as the 'out-denting' I am proposing. I think this is due\nto the similarities between the asterisk and the other symbols used to\nindicate commits. This is maybe just a typographic issue, but I think\nin general the contrast between letters and spaces appearing in the\nfirst columns of text is stronger than either of characters and\nletters, or spaces and characters. A quick comparison of all three:\n\n--Letters and Spaces--\njc/maint-ident-missing-human-name\n  \"git show --format='%ci'\" did not give timestamp correctly for...\n   + split_ident_line(): make best effort when parsing author/committer line\n\n--Characters and Letters--\n* jc/maint-ident-missing-human-name\n\"git show --format='%ci'\" did not give timestamp correctly for...\n + split_ident_line(): make best effort when parsing author/committer line\n\n--Characters and Spaces--\n* jc/maint-ident-missing-human-name\n  \"git show --format='%ci'\" did not give timestamp correctly for\n   + split_ident_line(): make best effort when parsing author/committer line\n\nMy preference would be first for letters and spaces, or if that is not\ngood enough then characters and spaces.\n\n\nWith regards to the comment that the old header line appears in the\nmiddle of the output, as I said earlier that was a consequence of\nreordering and indenting everything but otherwise leaving it as is.\nThis should be changed, so how about:\n\n<branch-name> (<creation-date>)\n  <branch-description?>\n  <notes-and-memoranda?>\n  <next-steps?>\n\n  <#-commits> (<merge-status?>)\n   [list-of-commits]\n  (<branch-usage?>)\n\neg:\njc/maint-ident-missing-human-name (2012-08-31)\n  \"git show --format='%ci'\" did not give timestamp correctly for\n  commits created without human readable name on \"committer\" line.\n\n  1 commit (merged to 'next' on 2012-09-07 at 0e99b20)\n   + split_ident_line(): make best effort when parsing author/committer line\n\n\nwith no description:\nsl/autoconf (2012-09-11)\n  2 commits\n   - build: don't duplicate substitution of make variables\n   - build: improve GIT_CONF_SUBST signature\n\n\nHopefully that makes more sense and addresses the concerns you raised.\nAdding an asterisk at the start is ok by me, if that is something you\nthink is needed.\n\nOne thing I did think about, when leaving the asterisk in the middle\nof the listing in the first version, was how machine readable the\nformat was. I'm not sure if that is important, but the asterisk was a\nclear signal that what followed was a listing of commits. In any case,\nthe new and revised format is perhaps slightly less machine readable\nas a result.\n\n\nI feel a little bit like I might be bikeshedding this, however I do\nthink an improvement to the formatting of \"What's cooking\" is a\nmeaningful one for the project!\n\nRegards,\n\nAndrew Ardill\n"},{"id":"198992","messageId":"7v7grx9qpk.fsf@alter.siamese.dyndns.org","threadId":"31496","inReplyTo":"CAH5451m28z_5Hbtyqx3+YkR-CoTNFB9bjLx6A1cJJXtj3hVjQQ@mail.gmail.com","subject":"Re: Suggestions for \"What's cooking\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-14T04:24:39Z","receivedAt":"2012-09-14T04:24:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Ardill <andrew.ardill@gmail.com> writes:\n\n> I feel a little bit like I might be bikeshedding this...\n\nYes you are.\n"},{"id":"198994","messageId":"7vy5kd8b2w.fsf@alter.siamese.dyndns.org","threadId":"31496","inReplyTo":"7vlige9cyx.fsf@alter.siamese.dyndns.org","subject":"Re: Suggestions for \"What's cooking\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-14T04:47:35Z","receivedAt":"2012-09-14T04:47:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> I've played with both and have prepared patches to Reintegrate and\n> cook (both in the 'todo' branch).  Will play with the changes a bit\n> more and then decide.\n\nSo here is how tonight's \"What's cooking\" may look like with extra\nindentation and blank lines.\n\nThe tools that read this file to help my workflow have been\nminimally adjusted.  I am hoping that the updates to them I made\nwere enough to make the format tweak not to negatively affect me,\nand so far things are going smoothly, but I may find some corner\ncases later. Knock wood...\n\n-- >8 --\n\nTo: git@vger.kernel.org\nBcc: lwn@lwn.net\nSubject: What's cooking in git.git (Sep 2012, #05; Thu, 13)\nX-master-at: ce5cf6ffc6feb9fb4f9a50cdfa2f527fa119c94f\nX-next-at: dd7cb6d65b94d88f3bfb9efefabd5818614bf587\n\nWhat's cooking in git.git (Sep 2012, #05; Thu, 13)\n--------------------------------------------------\n\nHere are the topics that have been cooking.  Commits prefixed with '-' are\nonly in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.\n\n***BLURB***\n\nI'm planning to keep this cycle reasonably short and aim for tagging\nthe result as 1.8.0 at the end of 9th week, on October 21st, after\nwhich I'd disappear for a few weeks.  http://tinyurl.com/gitCal is\nwhere you can always find my rough tagging schedule at.\n\nYou can find the changes described here in the integration branches of the\nrepositories listed at\n\n    http://git-blame.blogspot.com/p/git-public-repositories.html\n\n--------------------------------------------------\n[New Topics]\n\n* jw/doc-commit-title (2012-09-13) 1 commit\n - Documentation: describe subject more precisely\n\n Update parts of document that talked about \"first line of commit\n log\" to say \"title of commit\" with definition of what that \"title\"\n is.\n\n Will merge to 'next' after eyeballing.\n\n\n* nd/maint-diffstat-summary (2012-09-13) 1 commit\n - Revert diffstat summary back to English\n\n Earlier we made the diffstat summary line that shows the number of\n lines added/deleted localizable, but it was found irritating having\n to see them in various languages on a list whose discussion language\n is English.\n\n Breaks many tests which need to be fixed before moving forward.\n\n\n* nd/fetch-status-alignment (2012-09-12) 2 commits\n - [FIXUP] %.*s width must be int, not size_t\n - fetch: align per-ref summary report in UTF-8 locales\n\n Will merge to 'next' after squashing the fix-up.\n\n\n* mv/cherry-pick-s (2012-09-13) 1 commit\n . cherry-pick: don't forget -s on failure\n\n\n* jc/maint-log-grep-all-match (2012-09-13) 3 commits\n - log: document use of multiple commit limiting options\n - log --grep/--author: honor --all-match honored for multiple --grep patterns\n - grep: teach --debug option to dump the parse tree\n\n Fix a long-standing bug in \"git log --grep\" when multiple \"--grep\"\n are used together with \"--all-match\" and \"--author\" or \"--committer\".\n\n--------------------------------------------------\n[Stalled]\n\n* ph/credential-refactor (2012-09-02) 5 commits\n - wincred: port to generic credential helper\n - Merge branch 'ef/win32-cred-helper' into ph/credential-refactor\n - osxkeychain: port to generic credential helper implementation\n - gnome-keyring: port to generic helper implementation\n - contrib: add generic credential helper\n\n Attempts to refactor to share code among OSX keychain, Gnome keyring\n and Win32 credential helpers.\n\n\n* jc/maint-name-rev (2012-09-04) 7 commits\n - describe --contains: use \"name-rev --weight\"\n - name-rev --weight: tests and documentation\n - name-rev --weight: cache the computed weight in notes\n - name-rev --weight: trivial optimization\n - name-rev: --weight option\n - name_rev: clarify the logic to assign a new tip-name to a commit\n - name-rev: lose unnecessary typedef\n\n \"git name-rev\" names the given revision based on a ref that can be\n reached in the smallest number of steps from the rev, but that is\n not useful when the caller wants to know which tag is the oldest one\n that contains the rev.  This teaches a new mode to the command that\n uses the oldest ref among those which contain the rev.\n\n I am not sure if this is worth it; for one thing, even with the help\n from notes-cache, it seems to make the \"describe --contains\" even\n slower. Also the command will be unusably slow for a user who does\n not have a write access (hence unable to create or update the\n notes-cache).\n\n Needs another round to at least find a better name for the option,\n and possibly a cheaper but still better than the current \"close to\n the tip\" heuristics.\n\n\n* ms/contrib-thunderbird-updates (2012-08-31) 2 commits\n - [SQUASH] minimum fixup\n - Thunderbird: fix appp.sh format problems\n\n Update helper to send out format-patch output using Thunderbird.\n Seems to have design regression for silent users.\n\n\n* as/check-ignore (2012-09-02) 10 commits\n . fixup: decl-after-stmt etc.\n . Add git-check-ignore\n . Provide free_directory() for reclaiming dir_struct memory\n . Extract some useful pathspec handling code from builtin/add.c into a library\n . For each exclude pattern, store information about where it came from\n . dir.c: refactor excluded() and path_excluded()\n . dir.c: refactor excluded_from_list()\n . dir.c: rename cryptic 'which' variable to more consistent name\n . Improve documentation and comments regarding directory traversal API\n . Update directory listing API doc to match code\n\n Will be rerolled.\n\n\n* jx/test-real-path (2012-08-27) 1 commit\n - test: set the realpath of CWD as TRASH_DIRECTORY\n\n Running tests with the \"trash\" directory elsewhere with the \"--root\"\n option did not work well if the directory was specified by a symbolic\n link pointing at it.\n\n Seems broken as it makes $(pwd) and TRASH_DIRECTORY inconsistent.\n Needs rerolling.\n\n\n* jc/maint-push-refs-all (2012-08-27) 2 commits\n - get_fetch_map(): tighten checks on dest refs\n - [BROKEN] fetch/push: allow refs/*:refs/*\n\n Allows pushing and fetching everything including refs/stash.\n This is broken (see the log message there).\n\n Not ready.\n\n\n* er/doc-fast-import-done (2012-08-22) 1 commit\n - fast-import: document the --done option\n\n Parked in 'pu' in case ESR responds with \"Sorry, forgot to sign-off\".\n\n\n* jc/add-delete-default (2012-08-13) 1 commit\n - git add: notice removal of tracked paths by default\n\n \"git add dir/\" updated modified files and added new files, but does\n not notice removed files, which may be \"Huh?\" to some users.  They\n can of course use \"git add -A dir/\", but why should they?\n\n Resurrected from graveyard, as I thought it was a worthwhile thing\n to do in the longer term.\n\n Waiting for comments.\n\n\n* tx/relative-in-the-future (2012-08-16) 2 commits\n - date: show relative dates in the future\n - date: refactor the relative date logic from presentation\n\n Not my itch; rewritten an earlier submission by Tom Xue into\n somewhat more maintainable form, though it breaks existing i18n.\n\n Waiting for a voluteer to fix it up.\n Otherwise may discard.\n\n\n* tg/index-v5 (2012-08-17) 13 commits\n . p0002-index.sh: add perf test for the index formats\n . update-index.c: rewrite index when index-version is given\n . Write resolve-undo data for index-v5\n . Write index-v5 cache-tree data\n . Write index-v5\n . Read cache-tree in index-v5\n . Read resolve-undo data\n . Read index-v5\n . Make in-memory format aware of stat_crc\n . Add documentation of the index-v5 file format\n . t2104: Don't fail for index versions other than [23]\n . read-cache.c: Re-read index if index file changed\n . Move index v2 specific functions to their own file\n\n A GSoC project.  Was waiting for comments from mentors and\n stakeholders, but nothing seems to be happening, other than breakage\n fixes on Cygwin.  May discard.\n\n\n* mz/rebase-range (2012-07-18) 7 commits\n . rebase (without -p): correctly calculate patches to rebase\n . rebase -p: don't request --left-right only to ignore left side\n . rebase -p: use --cherry-mark for todo file\n . git-rebase--interactive.sh: look up subject in add_pick_line\n . git-rebase--interactive: group all $preserve_merges code\n . git-rebase--interactive.sh: extract function for adding \"pick\" line\n . git-rebase--am.sh: avoid special-casing --keep-empty\n\n Expecting a reroll.\n\n Performance concerns from Windows folks.  Also the series lacks\n proper sign-offs.\n\n\n* mb/remote-default-nn-origin (2012-07-11) 6 commits\n - Teach get_default_remote to respect remote.default.\n - Test that plain \"git fetch\" uses remote.default when on a detached HEAD.\n - Teach clone to set remote.default.\n - Teach \"git remote\" about remote.default.\n - Teach remote.c about the remote.default configuration setting.\n - Rename remote.c's default_remote_name static variables.\n\n When the user does not specify what remote to interact with, we\n often attempt to use 'origin'.  This can now be customized via a\n configuration variable.\n\n Expecting a reroll.\n\n \"The first remote becomes the default\" bit is better done as a\n separate step.\n\n\n* jc/split-blob (2012-04-03) 6 commits\n - chunked-object: streaming checkout\n - chunked-object: fallback checkout codepaths\n - bulk-checkin: support chunked-object encoding\n - bulk-checkin: allow the same data to be multiply hashed\n - new representation types in the packstream\n - packfile: use varint functions\n\n Not ready.\n\n I finished the streaming checkout codepath, but as explained in\n 127b177 (bulk-checkin: support chunked-object encoding, 2011-11-30),\n these are still early steps of a long and painful journey. At least\n pack-objects and fsck need to learn the new encoding for the series\n to be usable locally, and then index-pack/unpack-objects needs to\n learn it to be used remotely.\n\n Given that I heard a lot of noise that people want large files, and\n that I was asked by somebody at GitTogether'11 privately for an\n advice on how to pay developers (not me) to help adding necessary\n support, I am somewhat dissapointed that the original patch series\n that was sent long time ago still remains here without much comments\n and updates from the developer community. I even made the interface\n to the logic that decides where to split chunks easily replaceable,\n and I deliberately made the logic in the original patch extremely\n stupid to entice others, especially the \"bup\" fanbois, to come up\n with a better logic, thinking that giving people an easy target to\n shoot for, they may be encouraged to help out. The plan is not\n working :-<.\n\n--------------------------------------------------\n[Cooking]\n\n* dg/run-command-child-cleanup (2012-09-11) 1 commit\n  (merged to 'next' on 2012-09-12 at aa5f9e2)\n + run-command.c: fix broken list iteration in clear_child_for_cleanup\n\n The code to wait for subprocess and remove it from our internal queue\n wasn't quite right.\n\n Will merge to 'master' as part of the seventh batch.\n\n\n* jc/maint-blame-no-such-path (2012-09-11) 2 commits\n - blame: allow \"blame file\" in the middle of a conflicted merge\n - blame $path: avoid getting fooled by case insensitive filesystems\n\n \"git blame MAKEFILE\" run in a history that has \"Makefile\" but not\n \"MAKEFILE\" should say \"No such file MAKEFILE in HEAD\", but got\n confused on a case insensitive filesystem and failed to do so.\n\n Even during a conflicted merge, \"git blame $path\" always meant to\n blame uncommitted changes to the \"working tree\" version; make it\n more useful by showing cleanly merged parts as coming from the other\n branch that is being merged.\n\n Will merge to 'next'.\n\n\n* sl/autoconf (2012-09-11) 2 commits\n  (merged to 'next' on 2012-09-12 at 6ebe199)\n + build: don't duplicate substitution of make variables\n + build: improve GIT_CONF_SUBST signature\n\n Reduces repetition in configure.ac.\n\n Will merge to 'master' as part of the seventh batch.\n\n\n* cn/branch-set-upstream-to (2012-09-11) 2 commits\n  (merged to 'next' on 2012-09-12 at e162318)\n + completion: complete branch name for \"branch --set-upstream-to=\"\n + completion: add --set-upstream-to and --unset-upstream\n\n Finishing touches to the recently graduated topic to introduce\n \"git branch --set-upstream-to\" option.\n\n Will merge to 'master' as part of the seventh batch.\n\n\n* jc/ll-merge-binary-ours (2012-09-12) 3 commits\n  (merged to 'next' on 2012-09-12 at 9a7a6b3)\n + ll-merge: warn about inability to merge binary files only when we can't\n + attr: \"binary\" attribute should choose built-in \"binary\" merge driver\n + merge: teach -Xours/-Xtheirs to binary ll-merge driver\n\n \"git merge -Xtheirs\" did not help content-level merge of binary\n files; it should just take their version.  Also \"*.jpg binary\" in\n the attributes did not imply they should use the binary ll-merge\n driver.\n\n Will merge to 'master' as part of the seventh batch.\n\n\n* jc/mailinfo-RE (2012-09-09) 1 commit\n  (merged to 'next' on 2012-09-12 at 131edbf)\n + mailinfo: strip \"RE: \" prefix\n\n We strip the prefix from \"Re: subject\" and also from a less common\n \"re: subject\", but left even less common \"RE: subject\" intact.\n\n Will merge to 'master' as part of the seventh batch.\n\n\n* mh/string-list (2012-09-12) 6 commits\n - api-string-list.txt: initialize the string_list the easy way\n - string_list: add a function string_list_longest_prefix()\n - string_list: add a new function, string_list_remove_duplicates()\n - string_list: add a new function, filter_string_list()\n - string_list: add two new functions for splitting strings\n - string_list: add function string_list_append_nodup()\n (this branch is used by mh/fetch-filter-refs.)\n\n Will merge to 'next'.\n\n\n* pw/p4-submit-conflicts (2012-09-10) 12 commits\n - git-p4: add submit --conflict option and config varaiable\n - git p4: add submit --prepare-p4-only option\n - git p4: add submit --dry-run option\n - git p4: accept -v for --verbose\n - git p4: revert deleted files after submit cancel\n - git p4: rearrange submit template construction\n - git p4: test clean-up after failed submit, fix added files\n - git p4: standardize submit cancel due to unchanged template\n - git p4: move conflict prompt into run, add [q]uit input\n - git p4: remove submit failure options [a]pply and [w]rite\n - git p4: gracefully fail if some commits could not be applied\n - git p4 test: remove bash-ism of combined export/assignment\n\n Waiting for comments.\n\n\n* mh/abspath (2012-09-10) 9 commits\n  (merged to 'next' on 2012-09-11 at 5e29b53)\n + t0060: split absolute path test in two to exercise some of it on Windows\n + t0060: verify that real_path() removes extra slashes\n + real_path(): properly handle nonexistent top-level paths\n + t0060: verify that real_path() works correctly with absolute paths\n + real_path(): reject the empty string\n + t0060: verify that real_path() fails if passed the empty string\n + absolute_path(): reject the empty string\n + t0060: verify that absolute_path() fails if passed the empty string\n + t0060: move tests of real_path() from t0000 to here\n\n Will merge to 'master' as part of the sixth batch.\n\n\n* nd/i18n-status (2012-09-06) 1 commit\n  (merged to 'next' on 2012-09-11 at 7cfa224)\n + status: remove i18n legos\n\n Will merge to 'master' as part of the sixth batch.\n\n\n* sn/ls-remote-get-url-doc (2012-09-07) 1 commit\n  (merged to 'next' on 2012-09-11 at 9d09780)\n + ls-remote: document the '--get-url' option\n\n Will merge to 'master' as part of the sixth batch.\n\n\n* dj/fetch-all-tags (2012-09-07) 1 commit\n  (merged to 'next' on 2012-09-11 at 083a029)\n + fetch --all: pass --tags/--no-tags through to each remote\n\n \"git fetch --all\", when passed \"--no-tags\", did not honor the\n \"--no-tags\" option while fetching from individual remotes (the same\n issue existed with \"--tags\", but combination \"--all --tags\" makes\n much less sense than \"--all --no-tags\").\n\n Will merge to 'master' as part of the sixth batch.\n\n\n* rj/tap-fix (2012-09-02) 6 commits\n  (merged to 'next' on 2012-09-11 at 4104358)\n + test-lib.sh: Suppress the \"passed all ...\" message if no tests run\n + test-lib.sh: Add check for invalid use of 'skip_all' facility\n + test-lib.sh: Fix some shell coding style violations\n + t4016-*.sh: Skip all tests rather than each test\n + t3902-*.sh: Skip all tests rather than each test\n + t3300-*.sh: Fix a TAP parse error\n\n Will merge to 'master' as part of the sixth batch.\n\n\n* jc/xprm-generation (2012-09-04) 1 commit\n - test-generation: compute generation numbers and clock skews\n\n\n* rj/path-cleanup (2012-09-04) 5 commits\n  (merged to 'next' on 2012-09-11 at 9e8da84)\n + Call mkpathdup() rather than xstrdup(mkpath(...))\n + Call git_pathdup() rather than xstrdup(git_path(\"...\"))\n + path.c: Use vsnpath() in the implementation of git_path()\n + path.c: Don't discard the return value of vsnpath()\n + path.c: Remove the 'git_' prefix from a file scope function\n\n Will merge to 'master' as part of the sixth batch.\n\n\n* rs/archive-zip-utf8 (2012-09-04) 1 commit\n  (merged to 'next' on 2012-09-11 at 3b1f071)\n + archive-zip: support UTF-8 paths\n\n Need help from people on platforms on which Zip matters to see\n compatiblity with other people's zip implementations.\n\n Will merge to 'master' as part of the sixth batch.\n\n\n* nd/checkout-option-parsing-fix (2012-09-11) 3 commits\n  (merged to 'next' on 2012-09-11 at 3d3ef13)\n + checkout: reorder option handling\n + checkout: move more parameters to struct checkout_opts\n + checkout: pass \"struct checkout_opts *\" as const pointer\n\n The option parsing of \"git checkout\" had error checking, dwim and\n defaulting missing options, all mixed in the code, and issuing an\n appropriate error message with useful context was getting harder.\n Reorganize the code and allow giving a proper diagnosis when the\n user says \"git checkout -b -t foo bar\" (e.g. \"-t\" is not a good name\n for a branch).\n\n Will merge to 'master' as part of the sixth batch.\n\n\n* mh/fetch-filter-refs (2012-09-12) 14 commits\n - fetch-pack: eliminate spurious error messages\n - cmd_fetch_pack(): simplify computation of return value\n - fetch-pack: report missing refs even if no existing refs were received\n - cmd_fetch_pack(): return early if finish_connect() fails\n - filter_refs(): simplify logic\n - filter_refs(): build refs list as we go\n - filter_refs(): delete matched refs from sought list\n - fetch_pack(): update sought->nr to reflect number of unique entries\n - filter_refs(): do not check the same sought_pos twice\n - Change fetch_pack() and friends to take string_list arguments\n - fetch_pack(): reindent function decl and defn\n - Rename static function fetch_pack() to http_fetch_pack()\n - t5500: add tests of fetch-pack --all --depth=N $URL $REF\n - t5500: add tests of error output for missing refs\n (this branch uses mh/string-list.)\n\n Code simplification and clarification.\n\n Will merge to 'next'.\n\n\n* jl/submodule-rm (2012-08-27) 1 commit\n - Teach rm to remove submodules unless they contain a git directory\n\n \"git rm submodule\" cannot blindly remove a submodule directory as\n its working tree may have local changes, and worse yet, it may even\n have its repository embedded in it.  Teach it some special cases\n where it is safe to remove a submodule, specifically, when there is\n no local changes in the submodule working tree, and its repository\n is not embedded in its working tree but is elsewhere and uses the\n gitfile mechanism to point at it.\n\n Replacement sent but was still iffy around conflicted merge cases.\n\n\n* fa/remote-svn (2012-08-28) 16 commits\n - Add a test script for remote-svn\n - remote-svn: add marks-file regeneration\n - Add a svnrdump-simulator replaying a dump file for testing\n - remote-svn: add incremental import\n - remote-svn: Activate import/export-marks for fast-import\n - Create a note for every imported commit containing svn metadata\n - vcs-svn: add fast_export_note to create notes\n - Allow reading svn dumps from files via file:// urls\n - remote-svn, vcs-svn: Enable fetching to private refs\n - When debug==1, start fast-import with \"--stats\" instead of \"--quiet\"\n - Add documentation for the 'bidi-import' capability of remote-helpers\n - Connect fast-import to the remote-helper via pipe, adding 'bidi-import' capability\n - Add argv_array_detach and argv_array_free_detached\n - Add svndump_init_fd to allow reading dumps from arbitrary FDs\n - Add git-remote-testsvn to Makefile and .gitignore\n - Implement a remote helper for svn in C\n (this branch is used by fa/vcs-svn.)\n\n A GSoC project.  Looked promising.\n Waiting for comments from mentors and stakeholders.\n\n\n* fa/vcs-svn (2012-08-28) 4 commits\n - vcs-svn: remove repo_tree\n - vcs-svn/svndump: rewrite handle_node(), begin|end_revision()\n - vcs-svn/svndump: restructure node_ctx, rev_ctx handling\n - svndump: move struct definitions to .h\n (this branch uses fa/remote-svn.)\n\n A GSoC project.  Looked promising.\n Waiting for comments from mentors and stakeholders.\n\n\n* jk/no-more-pre-exec-callback (2012-06-05) 1 commit\n - pager: drop \"wait for output to run less\" hack\n\n (Originally merged to 'next' on 2012-07-23)\n\n Will defer until the end of the 2012.\n while waiting for older \"less\" to go extinct.\n"},{"id":"198999","messageId":"03339FB2E0624FCA858255742B9CA7FD@PhilipOakley","threadId":"31496","inReplyTo":"7vboh99w1z.fsf@alter.siamese.dyndns.org","subject":"Re: Suggestions for \"What's cooking\"","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2012-09-14T06:00:53Z","receivedAt":"2012-09-14T06:00:53Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" <gitster@pobox.com>\nSent: Friday, September 14, 2012 3:29 AM\n> Andrew Ardill <andrew.ardill@gmail.com> writes:\n>\n>> On 14 September 2012 04:06, Junio C Hamano <gitster@pobox.com> wrote:\n>>> Andrew Ardill <andrew.ardill@gmail.com> writes:\n>>>\n>>>> <short-branch-description>\n>>>>   <long-branch-description>\n>>>>   <notes>\n>>>>   <next-steps>\n>>>>   * <branch-name> (<creation-date>) <number-of-commits>\n>>>>     (<merge-status>)\n>>>>    [list-of-commits]\n>>>>     (<branch-usage>)\n>>>\n>>> I do not see how it makes any sense to have the \"This is where the\n>>> section begins with, and its name is this\" line in the middle of a\n>>> block indented in such a way.  Care to explain?\n>>\n>> I'm not quite sure what aspect you are referring to,...\n>\n> Just this part, as I do not have much time.  Here is your reordered\n> one I will reject:\n>\n>  A > jc/maint-blame-no-such-path\n>    >   \"git blame MAKEFILE\" run in a history that has \"Makefile\" but \n> not\n>    >   \"MAKEFILE\" should say \"No such file MAKEFILE in HEAD\", but got\n>    >   confused on a case insensitive filesystem.\n>    >\n>  B >   * jc/maint-blame-no-such-path (2012-09-10) 1 commit\n>    >    - blame $path: avoid getting fooled by case insensitive \n> filesystems\n>\n> I was noting that B which *is* formatted as a header line (it EVEN\n> has a leading asterisk to make it clear that it begins something\n> new) is in the middle, and you added a redundant A that is not even\n> marked clearly as a header line.\n>\nAre we all working with Black text on a White background? (or is it vice \nversa) as this changes which bits of emphasis the eye will pick up. I'm \nreading the emails as black text against a white background.\n\nI find that for black text, in a block format, that one does not notice \nany special inital character, such as the '*', when it is part of a \nrectangular block. In fact I feel I tend to, if anything, down grade \ntext begining with special characters as being bullet points below some \nmain block text. Hence my suggestion to have either a visual break \n(extra line above), or a block indent (extra left hand space).\n\nChanging the contrast to white text on a black background totally \nchanges what the eye/brain will see/notice [$dayjob is electro-optic \nvision systems where contrast inversion is a standard requirement for \nthat reason]. It maybe that we are seeing different personal effects \nbecause of our set-ups.\n"},{"id":"199003","messageId":"5052DC39.4050108@alum.mit.edu","threadId":"31496","inReplyTo":"7vy5kd8b2w.fsf@alter.siamese.dyndns.org","subject":"Re: Suggestions for \"What's cooking\"","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-09-14T07:26:49Z","receivedAt":"2012-09-14T07:26:49Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 09/14/2012 06:47 AM, Junio C Hamano wrote:\n> So here is how tonight's \"What's cooking\" may look like with extra\n> indentation and blank lines. [...]\n\nI find this much more readable than the old format.  Thanks!\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"199070","messageId":"43ECB621483D4E739080309A2F3AA66A@PhilipOakley","threadId":"31496","inReplyTo":"7vy5kd8b2w.fsf@alter.siamese.dyndns.org","subject":"Re: Suggestions for \"What's cooking\"","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2012-09-14T20:20:44Z","receivedAt":"2012-09-14T20:20:44Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" <gitster@pobox.com>\nSent: Friday, September 14, 2012 5:47 AM\n> Junio C Hamano <gitster@pobox.com> writes:\n> \n>> I've played with both and have prepared patches to Reintegrate and\n>> cook (both in the 'todo' branch).  Will play with the changes a bit\n>> more and then decide.\n> \n> So here is how tonight's \"What's cooking\" may look like with extra\n> indentation and blank lines.\n> \n> The tools that read this file to help my workflow have been\n> minimally adjusted.  I am hoping that the updates to them I made\n> were enough to make the format tweak not to negatively affect me,\n> and so far things are going smoothly, but I may find some corner\n> cases later. Knock wood...\n> \n> -- >8 --\n<snip>\n\n+1. It looks good even when printed with a proportional width font.\n"}]}