{"thread":{"id":"32696","subject":"What's cooking in git.git (Jan 2013, #08; Tue, 22)","startedAt":"2013-01-22T22:44:48Z","lastAt":"2013-01-25T09:09:41Z","messageCount":15,"participants":["Junio C Hamano","John Keeping","Chris Rorvick"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"207533","messageId":"7va9s0n8gv.fsf@alter.siamese.dyndns.org","threadId":"32696","inReplyTo":null,"subject":"What's cooking in git.git (Jan 2013, #08; Tue, 22)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-22T22:44:48Z","receivedAt":"2013-01-22T22:44:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed with\n'-' are only in 'pu' (proposed updates) while commits prefixed with\n'+' are in 'next'.\n\nAs usual, this cycle is expected to last for 8 to 10 weeks, with a\npreview -rc0 sometime in the middle of next month.\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* bc/fix-array-syntax-for-3.0-in-completion-bash (2013-01-18) 1 commit\n - git-completion.bash: replace zsh notation that breaks bash 3.X\n\n Fix use of an array notation that older versions of bash do not\n understand.\n\n Will merge to 'next'.\n\n\n* jc/help (2013-01-18) 1 commit\n - help: include <common-cmds.h> only in one file\n\n A header file that has the definition of a static array was\n included in two places, wasting the space.\n\n Will merge to 'next'.\n\n\n* jc/hidden-refs (2013-01-18) 2 commits\n - upload-pack: allow hiding ref hiearchies\n - upload-pack: share more code\n\n Allow the server side to unclutter the refs/ namespace it shows by\n default, while still allowing requests for histories leading to the\n tips of hidden refs by updated clients (which are not written yet).\n\n\n* jk/update-install-for-p4 (2013-01-20) 1 commit\n - INSTALL: git-p4 doesn't support Python 3\n\n Will merge to 'next'.\n\n\n* tb/t0050-maint (2013-01-21) 3 commits\n - t0050: Use TAB for indentation\n - t0050: honor CASE_INSENSITIVE_FS in add (with different case)\n - t0050: known breakage vanished in merge (case change)\n\n Will merge to 'next'.\n\n\n* nd/magic-pathspec-from-root (2013-01-21) 2 commits\n - grep: avoid accepting ambiguous revision\n - Update :/abc ambiguity check\n\n Will merge to 'next'.\n\n\n* ta/doc-no-small-caps (2013-01-21) 7 commits\n - Add rule for when to use 'git' and when to use 'Git'\n - Change 'git' to 'Git' whenever the whole system is referred to #4\n - Change 'git' to 'Git' whenever the whole system is referred to #3\n - Change 'git' to 'Git' whenever the whole system is referred to #2\n - Change 'git' to 'Git' whenever the whole system is referred to #1\n - Documentation: update two leftover small caps\n - Documentation: avoid poor-man's small caps\n\n Update documentation to change \"GIT\" which was a poor-man's small\n caps to \"Git\" which was the intended spelling.  Also change \"git\"\n spelled in all-lowercase to \"Git\" when it refers to the system as\n the whole or the concept it embodies, as opposed to the command the\n end users would type.\n\n\n* rr/minimal-stat (2013-01-22) 1 commit\n - Enable minimal stat checking\n\n Some reimplementations of Git does not write all the stat info back\n to the index due to their implementation limitations (e.g. jgit\n running on Java).  A configuration option can tell Git to ignore\n changes to most of the stat fields and only pay attention to mtime\n and size, which these implementations can reliably update.  This\n avoids excessive revalidation of contents.\n\n Will merge to 'next'.\n\n--------------------------------------------------\n[Graduated to \"master\"]\n\n* ap/log-mailmap (2013-01-10) 11 commits\n  (merged to 'next' on 2013-01-10 at 8544084)\n + log --use-mailmap: optimize for cases without --author/--committer search\n + log: add log.mailmap configuration option\n + log: grep author/committer using mailmap\n + test: add test for --use-mailmap option\n + log: add --use-mailmap option\n + pretty: use mailmap to display username and email\n + mailmap: add mailmap structure to rev_info and pp\n + mailmap: simplify map_user() interface\n + mailmap: remove email copy and length limitation\n + Use split_ident_line to parse author and committer\n + string-list: allow case-insensitive string list\n\n Teach commands in the \"log\" family to optionally pay attention to\n the mailmap.\n\n\n* ds/completion-silence-in-tree-path-probe (2013-01-11) 1 commit\n  (merged to 'next' on 2013-01-15 at 7542d21)\n + git-completion.bash: silence \"not a valid object\" errors\n\n An internal ls-tree call made by completion code only to probe if\n a path exists in the tree recorded in a commit object leaked error\n messages when the path is not there.  It is not an error at all and\n should not be shown to the end user.\n\n\n* fc/remote-hg-fixup-url (2013-01-15) 1 commit\n  (merged to 'next' on 2013-01-15 at d2acb2d)\n + remote-hg: store converted URL\n\n Update to the Hg remote helper (in contrib/).\n\n\n* jn/maint-trim-vim-contrib (2013-01-10) 1 commit\n  (merged to 'next' on 2013-01-15 at ad80a9d)\n + contrib/vim: simplify instructions for old vim support\n\n Remove stale insn to support older versions of vim and point users\n to the upstream resources.\n\n\n* mh/remote-hg-mode-bits-fix (2013-01-15) 1 commit\n  (merged to 'next' on 2013-01-15 at ad57d9f)\n + remote-hg: fix handling of file perms when pushing\n\n Update to the Hg remote helper (in contrib/).\n\n\n* mk/complete-tcsh (2013-01-07) 1 commit\n  (merged to 'next' on 2013-01-11 at b8b30b1)\n + Prevent space after directories in tcsh completion\n\n Update tcsh command line completion so that an unwanted space is\n not added to a single directory name.\n\n\n* mz/reset-misc (2013-01-16) 20 commits\n  (merged to 'next' on 2013-01-16 at 937bc20)\n + reset: update documentation to require only tree-ish with paths\n  (merged to 'next' on 2013-01-15 at a93b394)\n + reset [--mixed]: use diff-based reset whether or not pathspec was given\n + reset: allow reset on unborn branch\n + reset $sha1 $pathspec: require $sha1 only to be treeish\n + reset.c: inline update_index_refresh()\n + reset.c: finish entire cmd_reset() whether or not pathspec is given\n + reset [--mixed]: only write index file once\n + reset.c: move lock, write and commit out of update_index_refresh()\n + reset.c: move update_index_refresh() call out of read_from_tree()\n + reset.c: replace switch by if-else\n + reset: avoid redundant error message\n + reset --keep: only write index file once\n + reset.c: share call to die_if_unmerged_cache()\n + reset.c: extract function for updating {ORIG_,}HEAD\n + reset.c: remove unnecessary variable 'i'\n + reset.c: extract function for parsing arguments\n + reset: don't allow \"git reset -- $pathspec\" in bare repo\n + reset.c: pass pathspec around instead of (prefix, argv) pair\n + reset $pathspec: exit with code 0 if successful\n + reset $pathspec: no need to discard index\n\n Various 'reset' optimizations and clean-ups, followed by a change\n to allow \"git reset\" to work even on an unborn branch.\n\n\n* nd/attr-debug-fix (2013-01-15) 1 commit\n  (merged to 'next' on 2013-01-15 at 8460acf)\n + attr: make it build with DEBUG_ATTR again\n\n Fix debugging support that was broken in earlier change.\n\n\n* nd/clone-no-separate-git-dir-with-bare (2013-01-10) 1 commit\n  (merged to 'next' on 2013-01-15 at 64f441a)\n + clone: forbid --bare --separate-git-dir <dir>\n\n Forbid a useless combination of options to \"git clone\".\n\n\n* nd/fix-directory-attrs-off-by-one (2013-01-16) 2 commits\n  (merged to 'next' on 2013-01-16 at bd63e61)\n + attr: avoid calling find_basename() twice per path\n  (merged to 'next' on 2013-01-15 at e0a0129)\n + attr: fix off-by-one directory component length calculation\n\n Fix performance regression introduced by an earlier change to let\n attributes apply to directories.\n\n\n* nd/fix-perf-parameters-in-tests (2013-01-15) 1 commit\n  (merged to 'next' on 2013-01-15 at fedbdb9)\n + test-lib.sh: unfilter GIT_PERF_*\n\n Allow GIT_PERF_* environment variables to be passed through the\n test framework.\n\n\n* pe/doc-email-env-is-trumped-by-config (2013-01-10) 1 commit\n  (merged to 'next' on 2013-01-14 at 6b4d555)\n + git-commit-tree(1): correct description of defaults\n\n In the precedence order, the environment variable $EMAIL comes\n between the built-in default (i.e. taking value by asking the\n system's gethostname() etc.) and the user.email configuration\n variable; the documentation implied that it is stronger than the\n configuration like $GIT_COMMITTER_EMAIL is, which is wrong.\n\n\n* ph/rebase-preserve-all-merges (2013-01-14) 1 commit\n  (merged to 'next' on 2013-01-15 at 3a67878)\n + rebase --preserve-merges: keep all merge commits including empty ones\n\n An earlier change to add --keep-empty option broke \"git rebase\n --preserve-merges\" and lost merge commits that end up being the\n same as its parent.\n\n\n* pw/p4-branch-fixes (2013-01-15) 14 commits\n  (merged to 'next' on 2013-01-15 at 1ee379e)\n + git p4: fix submit when no master branch\n + git p4 test: keep P4CLIENT changes inside subshells\n + git p4: fix sync --branch when no master branch\n + git p4: fail gracefully on sync with no master branch\n + git p4: rearrange self.initialParent use\n + git p4: allow short ref names to --branch\n + git p4 doc: fix branch detection example\n + git p4: clone --branch should checkout master\n + git p4: verify expected refs in clone --bare test\n + git p4: create p4/HEAD on initial clone\n + git p4: inline listExistingP4GitBranches\n + git p4: add comments to p4BranchesInGit\n + git p4: rearrange and simplify hasOrigin handling\n + git p4: test sync/clone --branch behavior\n\n Fix \"git p4\" around branch handling.\n\n\n* rs/pretty-use-prefixcmp (2013-01-14) 1 commit\n  (merged to 'next' on 2013-01-15 at d76452d)\n + pretty: use prefixcmp instead of memcmp on NUL-terminated strings\n\n\n* rt/commit-cleanup-config (2013-01-10) 1 commit\n  (merged to 'next' on 2013-01-15 at c4742ae)\n + commit: make default of \"cleanup\" option configurable\n\n Add a configuration variable to set default clean-up mode other\n than \"strip\".\n\n\n* ss/help-htmlpath-config-doc (2013-01-15) 1 commit\n  (merged to 'next' on 2013-01-17 at 99bfae2)\n + config.txt: Document help.htmlpath config parameter\n\n Add missing doc.\n\n\n* zk/clean-report-failure (2013-01-14) 1 commit\n  (merged to 'next' on 2013-01-15 at 5b31614)\n + git-clean: Display more accurate delete messages\n\n \"git clean\" states what it is going to remove and then goes on to\n remove it, but sometimes it only discovers things that cannot be\n removed after recursing into a directory, which makes the output\n confusing and even wrong.\n\n--------------------------------------------------\n[Stalled]\n\n* mp/complete-paths (2013-01-11) 1 commit\n - git-completion.bash: add support for path completion\n\n The completion script used to let the default completer to suggest\n pathnames, which gave too many irrelevant choices (e.g. \"git add\"\n would not want to add an unmodified path).  Teach it to use a more\n git-aware logic to enumerate only relevant ones.\n\n Waiting for area-experts' help and review.\n\n\n* jl/submodule-deinit (2012-12-04) 1 commit\n - submodule: add 'deinit' command\n\n There was no Porcelain way to say \"I no longer am interested in\n this submodule\", once you express your interest in a submodule with\n \"submodule init\".  \"submodule deinit\" is the way to do so.\n\n Expecting a reroll.\n $gmane/212884\n\n\n* jk/lua-hackery (2012-10-07) 6 commits\n - pretty: fix up one-off format_commit_message calls\n - Minimum compilation fixup\n - Makefile: make \"lua\" a bit more configurable\n - add a \"lua\" pretty format\n - add basic lua infrastructure\n - pretty: make some commit-parsing helpers more public\n\n Interesting exercise. When we do this for real, we probably would want\n to wrap a commit to make it more like an \"object\" with methods like\n \"parents\", etc.\n\n\n* rc/maint-complete-git-p4 (2012-09-24) 1 commit\n - Teach git-completion about git p4\n\n Comment from Pete will need to be addressed ($gmane/206172).\n\n\n* jc/maint-name-rev (2012-09-17) 7 commits\n - describe --contains: use \"name-rev --algorithm=weight\"\n - name-rev --algorithm=weight: tests and documentation\n - name-rev --algorithm=weight: cache the computed weight in notes\n - name-rev --algorithm=weight: trivial optimization\n - name-rev: --algorithm 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 Stalled mostly due to lack of responses.\n\n\n* jc/xprm-generation (2012-09-14) 1 commit\n - test-generation: compute generation numbers and clock skews\n\n A toy to analyze how bad the clock skews are in histories of real\n world projects.\n\n Stalled mostly due to lack of responses.\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 Stalled mostly due to lack of responses.\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 $gmane/210151\n\n \"The first remote becomes the default\" bit is better done as a\n separate step.\n\n--------------------------------------------------\n[Cooking]\n\n* mh/imap-send-shrinkage (2013-01-15) 14 commits\n  (merged to 'next' on 2013-01-18 at 1b7c5ba)\n + imap-send.c: simplify logic in lf_to_crlf()\n + imap-send.c: fold struct store into struct imap_store\n + imap-send.c: remove unused field imap_store::uidvalidity\n + imap-send.c: use struct imap_store instead of struct store\n + imap-send.c: remove unused field imap_store::trashnc\n + imap-send.c: remove namespace fields from struct imap\n + imap-send.c: remove struct imap argument to parse_imap_list_l()\n + imap-send.c: inline parse_imap_list() in parse_list()\n + imap-send.c: remove some unused fields from struct store\n + imap-send.c: remove struct message\n + imap-send.c: remove struct store_conf\n + iamp-send.c: remove unused struct imap_store_conf\n + imap-send.c: remove struct msg_data\n + imap-send.c: remove msg_data::flags, which was always zero\n\n Remove a lot of unused code from \"git imap-send\".\n\n Will merge to 'master'.\n\n\n* cr/push-force-tag-update (2013-01-21) 4 commits\n - push: further simplify the logic to assign rejection status\n - push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE\n - push: further clean up fields of \"struct ref\"\n  (merged to 'next' on 2013-01-18 at c9091d5)\n + push: fix \"refs/tags/ hierarchy cannot be updated without --force\"\n\n Regression fix (the bottom one), and error/advice message\n improvements (the rest).\n\n Will merge to 'master' the bottom one soonish.\n The remainder can cook in 'next' like any other topic.\n\n\n* jk/suppress-clang-warning (2013-01-16) 1 commit\n  (merged to 'next' on 2013-01-18 at 7c0bda7)\n + fix clang -Wunused-value warnings for error functions\n\n Will merge to 'master'.\n\n\n* rs/clarify-entry-cmp-sslice (2013-01-16) 1 commit\n  (merged to 'next' on 2013-01-18 at d584dc6)\n + refs: use strncmp() instead of strlen() and memcmp()\n\n Will merge to 'master'.\n\n\n* ch/add-auto-submitted-in-sample-post-receive-email (2013-01-17) 1 commit\n  (merged to 'next' on 2013-01-18 at e3205db)\n + Add Auto-Submitted header to post-receive-email\n\n Will merge to 'master'.\n\n\n* jc/remove-treesame-parent-in-simplify-merges (2013-01-17) 1 commit\n - simplify-merges: drop merge from irrelevant side branch\n\n The --simplify-merges logic did not cull irrelevant parents from a\n merge that is otherwise not interesting with respect to the paths\n we are following.\n\n As this touches a fairly core part of the revision traversal\n infrastructure, it is appreciated to have an extra set of eyes for\n sanity check.\n\n Waiting for comments.\n\n\n* jk/remote-helpers-in-python-3 (2013-01-20) 8 commits\n - git-remote-testpy: call print as a function\n - git-remote-testpy: don't do unbuffered text I/O\n - git-remote-testpy: hash bytes explicitly\n - svn-fe: allow svnrdump_sim.py to run with Python 3\n - git_remote_helpers: use 2to3 if building with Python 3\n - git_remote_helpers: force rebuild if python version changes\n - git_remote_helpers: fix input when running under Python 3\n - git_remote_helpers: allow building with Python 3\n\n Prepare remote-helper test written in Python to be run with Python3.\n\n Will merge to 'next'.\n\n\n* jc/cvsimport-upgrade (2013-01-14) 8 commits\n - t9600: adjust for new cvsimport\n - t9600: further prepare for sharing\n - cvsimport-3: add a sample test\n - cvsimport: make tests reusable for cvsimport-3\n - cvsimport: start adding cvsps 3.x support\n - cvsimport: introduce a version-switch wrapper\n - cvsimport: allow setting a custom cvsps (2.x) program name\n - Makefile: add description on PERL/PYTHON_PATH\n\n The most important part of this series is the addition of the new\n cvsimport by Eric Raymond that works with cvsps 3.x.  Given some\n distros have inertia to be conservative, Git with cvsimport that\n does not work with both 3.x will block adoption of cvsps 3.x by\n them, and shipping Git with cvsimport that does not work with cvsps\n 2.x will block such a version of Git, so we'll do the proven \"both\n old and new are available, but we aim to deprecate and remove the\n old one in due time\" strategy that we used successfully in the\n past.\n\n Will merge to 'next'.\n\n\n* as/pre-push-hook (2013-01-18) 3 commits\n  (merged to 'next' on 2013-01-18 at 37fc4e8)\n + Add sample pre-push hook script\n + push: Add support for pre-push hooks\n + hooks: Add function to check if a hook exists\n\n Add an extra hook so that \"git push\" that is run without making\n sure what is being pushed is sane can be checked and rejected (as\n opposed to the user deciding not pushing).\n\n Will merge to 'master'.\n\n\n* dl/am-hg-locale (2013-01-18) 1 commit\n - am: invoke perl's strftime in C locale\n\n Datestamp recorded in \"Hg\" format patch was reformatted incorrectly\n to an e-mail looking date using locale dependant strftime, causing\n patch application to fail.\n\n Will merge to 'next'.\n\n\n* jk/config-parsing-cleanup (2013-01-14) 7 commits\n - [DONTMERGE] reroll coming\n - submodule: simplify memory handling in config parsing\n - submodule: use match_config_key when parsing config\n - userdiff: drop parse_driver function\n - convert some config callbacks to match_config_key\n - archive-tar: use match_config_key when parsing config\n - config: add helper function for parsing key names\n\n Expecting a reroll.\n\n\n* mp/diff-algo-config (2013-01-16) 3 commits\n - diff: Introduce --diff-algorithm command line option\n - config: Introduce diff.algorithm variable\n - git-completion.bash: Autocomplete --minimal and --histogram for git-diff\n\n Add diff.algorithm configuration so that the user does not type\n \"diff --histogram\".\n\n Looking better; may want tests to protect it from future breakages,\n but otherwise it looks ready for 'next'.\n\n Waiting for a follow-up to add tests.\n\n\n* rs/archive-tar-config-parsing-fix (2013-01-14) 1 commit\n - archive-tar: fix sanity check in config parsing\n\n Configuration parsing for tar.* configuration variables were\n broken; Peff's config parsing clean-up topic will address the same\n breakage, so this may be superseded by that other topic.\n\n Waiting for the other topic to make this unneeded.\n\n\n* jc/custom-comment-char (2013-01-16) 1 commit\n - Allow custom \"comment char\"\n\n An illustration to show codepaths that need to be touched to change\n the hint lines in the edited text to begin with something other\n than '#'.\n\n This is half my work and half by Ralf Thielow.  There may still be\n leftover '#' lurking around, though.  My \"git grep\" says C code\n should be already fine, but git-rebase--interactive.sh could be\n converted (it should not matter, as the file is not really a\n free-form text).\n\n I don't know how useful this will be in real life, though.\n\n Will merge to 'next'.\n\n\n* nd/fetch-depth-is-broken (2013-01-11) 3 commits\n  (merged to 'next' on 2013-01-15 at 70a5ca7)\n + fetch: elaborate --depth action\n + upload-pack: fix off-by-one depth calculation in shallow clone\n + fetch: add --unshallow for turning shallow repo into complete one\n\n \"git fetch --depth\" was broken in at least three ways.  The\n resulting history was deeper than specified by one commit, it was\n unclear how to wipe the shallowness of the repository with the\n command, and documentation was misleading.\n\n Will cook in 'next'.\n\n\n* jc/no-git-config-in-clone (2013-01-11) 1 commit\n  (merged to 'next' on 2013-01-15 at feeffe1)\n + clone: do not export and unexport GIT_CONFIG\n\n We stopped paying attention to $GIT_CONFIG environment that points\n at a single configuration file from any command other than \"git config\"\n quite a while ago, but \"git clone\" internally set, exported, and\n then unexported the variable during its operation unnecessarily.\n\n Will cook in 'next'.\n\n\n* dg/subtree-fixes (2013-01-08) 7 commits\n - contrib/subtree: mkdir the manual directory if needed\n - contrib/subtree: honor $(DESTDIR)\n - contrib/subtree: fix synopsis and command help\n - contrib/subtree: better error handling for \"add\"\n - contrib/subtree: add --unannotate option\n - contrib/subtree: use %B for split Subject/Body\n - t7900: remove test number comments\n\n contrib/subtree updates; there are a few more from T. Zheng that\n were posted separately, with an overlap.\n\n Expecting a reroll.\n\n\n* jc/push-2.0-default-to-simple (2013-01-16) 14 commits\n  (merged to 'next' on 2013-01-16 at 23f5df2)\n + t5570: do not assume the \"matching\" push is the default\n + t5551: do not assume the \"matching\" push is the default\n + t5550: do not assume the \"matching\" push is the default\n  (merged to 'next' on 2013-01-09 at 74c3498)\n + doc: push.default is no longer \"matching\"\n + push: switch default from \"matching\" to \"simple\"\n + t9401: do not assume the \"matching\" push is the default\n + t9400: do not assume the \"matching\" push is the default\n + t7406: do not assume the \"matching\" push is the default\n + t5531: do not assume the \"matching\" push is the default\n + t5519: do not assume the \"matching\" push is the default\n + t5517: do not assume the \"matching\" push is the default\n + t5516: do not assume the \"matching\" push is the default\n + t5505: do not assume the \"matching\" push is the default\n + t5404: do not assume the \"matching\" push is the default\n\n Will cook in 'next' until Git 2.0 ;-).\n\n\n* nd/parse-pathspec (2013-01-11) 20 commits\n . Convert more init_pathspec() to parse_pathspec()\n . Convert add_files_to_cache to take struct pathspec\n . Convert {read,fill}_directory to take struct pathspec\n . Convert refresh_index to take struct pathspec\n . Convert report_path_error to take struct pathspec\n . checkout: convert read_tree_some to take struct pathspec\n . Convert unmerge_cache to take struct pathspec\n . Convert read_cache_preload() to take struct pathspec\n . add: convert to use parse_pathspec\n . archive: convert to use parse_pathspec\n . ls-files: convert to use parse_pathspec\n . rm: convert to use parse_pathspec\n . checkout: convert to use parse_pathspec\n . rerere: convert to use parse_pathspec\n . status: convert to use parse_pathspec\n . commit: convert to use parse_pathspec\n . clean: convert to use parse_pathspec\n . Export parse_pathspec() and convert some get_pathspec() calls\n . Add parse_pathspec() that converts cmdline args to struct pathspec\n . pathspec: save the non-wildcard length part\n\n Uses the parsed pathspec structure in more places where we used to\n use the raw \"array of strings\" pathspec.\n\n Ejected from 'pu' for now; will take a look at the rerolled one\n later ($gmane/213340).\n\n\n* jc/doc-maintainer (2013-01-03) 2 commits\n  (merged to 'next' on 2013-01-11 at f35d582)\n + howto/maintain: mark titles for asciidoc\n + Documentation: update \"howto maintain git\"\n\n Describe tools for automation that were invented since this\n document was originally written.\n\n\n* mo/cvs-server-updates (2012-12-09) 18 commits\n  (merged to 'next' on 2013-01-08 at 75e2d11)\n + t9402: Use TABs for indentation\n + t9402: Rename check.cvsCount and check.list\n + t9402: Simplify git ls-tree\n + t9402: Add missing &&; Code style\n + t9402: No space after IO-redirection\n + t9402: Dont use test_must_fail cvs\n + t9402: improve check_end_tree() and check_end_full_tree()\n + t9402: sed -i is not portable\n + cvsserver Documentation: new cvs ... -r support\n + cvsserver: add t9402 to test branch and tag refs\n + cvsserver: support -r and sticky tags for most operations\n + cvsserver: Add version awareness to argsfromdir\n + cvsserver: generalize getmeta() to recognize commit refs\n + cvsserver: implement req_Sticky and related utilities\n + cvsserver: add misc commit lookup, file meta data, and file listing functions\n + cvsserver: define a tag name character escape mechanism\n + cvsserver: cleanup extra slashes in filename arguments\n + cvsserver: factor out git-log parsing logic\n\n Various git-cvsserver updates.\n\n Will merge to 'master'.\n\n\n* as/check-ignore (2013-01-16) 13 commits\n  (merged to 'next' on 2013-01-18 at ef45aff)\n + clean.c, ls-files.c: respect encapsulation of exclude_list_groups\n  (merged to 'next' on 2013-01-14 at 9df2afc)\n + t0008: avoid brace expansion\n + add git-check-ignore sub-command\n + setup.c: document get_pathspec()\n + add.c: extract new die_if_path_beyond_symlink() for reuse\n + add.c: extract check_path_for_gitlink() from treat_gitlinks() for reuse\n + pathspec.c: rename newly public functions for clarity\n + add.c: move pathspec matchers into new pathspec.c for reuse\n + add.c: remove unused argument from validate_pathspec()\n + dir.c: improve docs for match_pathspec() and match_pathspec_depth()\n + dir.c: provide clear_directory() for reclaiming dir_struct memory\n + dir.c: keep track of where patterns came from\n + dir.c: use a single struct exclude_list per source of excludes\n\n Add a new command \"git check-ignore\" for debugging .gitignore\n files.\n\n The variable names may want to get cleaned up but that can be done\n in-tree.\n\n Will merge to 'master'.\n\n\n* nd/retire-fnmatch (2013-01-01) 7 commits\n  (merged to 'next' on 2013-01-07 at ab31f9b)\n + Makefile: add USE_WILDMATCH to use wildmatch as fnmatch\n + wildmatch: advance faster in <asterisk> + <literal> patterns\n + wildmatch: make a special case for \"*/\" with FNM_PATHNAME\n + test-wildmatch: add \"perf\" command to compare wildmatch and fnmatch\n + wildmatch: support \"no FNM_PATHNAME\" mode\n + wildmatch: make dowild() take arbitrary flags\n + wildmatch: rename constants and update prototype\n\n Originally merged to 'next' on 2013-01-04\n\n Replace our use of fnmatch(3) with a more feature-rich wildmatch.\n A handful patches at the bottom have been moved to nd/wildmatch to\n graduate as part of that branch, before this series solidifies.\n\n Will merge to 'master'.\n\n\n* mb/gitweb-highlight-link-target (2012-12-20) 1 commit\n - Highlight the link target line in Gitweb using CSS\n\n Expecting a reroll.\n $gmane/211935\n\n\n* bc/append-signed-off-by (2013-01-21) 10 commits\n - Unify appending signoff in format-patch, commit and sequencer\n - format-patch: update append_signoff prototype\n - t4014: more tests about appending s-o-b lines\n - sequencer.c: teach append_signoff to avoid adding a duplicate newline\n - sequencer.c: teach append_signoff how to detect duplicate s-o-b\n - sequencer.c: always separate \"(cherry picked from\" from commit body\n - sequencer.c: recognize \"(cherry picked from ...\" as part of s-o-b footer\n - t/t3511: add some tests of 'cherry-pick -s' functionality\n - t/test-lib-functions.sh: allow to specify the tag name to test_commit\n - sequencer.c: remove broken support for rfc2822 continuation in footer\n\n Rerolled.\n\n Seems that we will see another round.\n\n--------------------------------------------------\n[Discarded]\n\n* er/replace-cvsimport (2013-01-12) 7 commits\n . t/lib-cvs: cvsimport no longer works without Python >= 2.7\n . t9605: test for cvsps commit ordering bug\n . t9604: fixup for new cvsimport\n . t9600: fixup for new cvsimport\n . t/lib-cvs.sh: allow cvsps version 3.x.\n . t/t960[123]: remove leftover scripts\n . cvsimport: rewrite to use cvsps 3.x to fix major bugs\n\n Rerolled as jc/cvsimport-upgrade.\n\n\n* jc/valgrind-memcmp-bsearch (2013-01-14) 1 commit\n . ignore memcmp() overreading in bsearch() callback\n\n Squelch false positive in valgrind tests; made unnecessary by\n rewriting the callsite that confuses the tool.\n"},{"id":"207537","messageId":"20130122234554.GI7498@serenity.lan","threadId":"32696","inReplyTo":"7va9s0n8gv.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-01-22T23:45:54Z","receivedAt":"2013-01-22T23:45:54Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Tue, Jan 22, 2013 at 02:44:48PM -0800, Junio C Hamano wrote:\n> * jc/cvsimport-upgrade (2013-01-14) 8 commits\n>  - t9600: adjust for new cvsimport\n>  - t9600: further prepare for sharing\n>  - cvsimport-3: add a sample test\n>  - cvsimport: make tests reusable for cvsimport-3\n>  - cvsimport: start adding cvsps 3.x support\n>  - cvsimport: introduce a version-switch wrapper\n>  - cvsimport: allow setting a custom cvsps (2.x) program name\n>  - Makefile: add description on PERL/PYTHON_PATH\n> \n>  The most important part of this series is the addition of the new\n>  cvsimport by Eric Raymond that works with cvsps 3.x.  Given some\n>  distros have inertia to be conservative, Git with cvsimport that\n>  does not work with both 3.x will block adoption of cvsps 3.x by\n>  them, and shipping Git with cvsimport that does not work with cvsps\n>  2.x will block such a version of Git, so we'll do the proven \"both\n>  old and new are available, but we aim to deprecate and remove the\n>  old one in due time\" strategy that we used successfully in the\n>  past.\n> \n>  Will merge to 'next'.\n\nWould you mind holding off on this?  As it stands there are a couple of\nissues with the cvsimport-3 script including:\n\n    * It doesn't read any configuration from \"git config\" as\n      git-cvsimport-2 does.\n\n    * Incremental import is copmletely broken - it needs to pass \"-i\" to\n      cvsps-3 and even then timestamp handling is completely broken.\n\nI have fixes for these that are nearly ready, but to fully fix the\nincremental import issue I'll need to persuade ESR to take a patch which\nlets us feed cvsps-3 a mapping from branch names to last commit times.\n\nI suspect people are already used to the ways in which cvsimport-2 is\nbroken so I think we should take a bit more time to get this right with\ncvsimport-3, especially since the people most likely to be using this\nwill be those regularly updating from a CVS repository with incremental\nupdates.\n\n\nJohn\n"},{"id":"207539","messageId":"7vobgglpv4.fsf@alter.siamese.dyndns.org","threadId":"32696","inReplyTo":"20130122234554.GI7498@serenity.lan","subject":"Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-23T00:11:59Z","receivedAt":"2013-01-23T00:11:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping <john@keeping.me.uk> writes:\n\n> On Tue, Jan 22, 2013 at 02:44:48PM -0800, Junio C Hamano wrote:\n>> * jc/cvsimport-upgrade (2013-01-14) 8 commits\n>>  - t9600: adjust for new cvsimport\n>>  - t9600: further prepare for sharing\n>>  - cvsimport-3: add a sample test\n>>  - cvsimport: make tests reusable for cvsimport-3\n>>  - cvsimport: start adding cvsps 3.x support\n>>  - cvsimport: introduce a version-switch wrapper\n>>  - cvsimport: allow setting a custom cvsps (2.x) program name\n>>  - Makefile: add description on PERL/PYTHON_PATH\n>> \n>>  The most important part of this series is the addition of the new\n>>  cvsimport by Eric Raymond that works with cvsps 3.x.  Given some\n>>  distros have inertia to be conservative, Git with cvsimport that\n>>  does not work with both 3.x will block adoption of cvsps 3.x by\n>>  them, and shipping Git with cvsimport that does not work with cvsps\n>>  2.x will block such a version of Git, so we'll do the proven \"both\n>>  old and new are available, but we aim to deprecate and remove the\n>>  old one in due time\" strategy that we used successfully in the\n>>  past.\n>> \n>>  Will merge to 'next'.\n>\n> Would you mind holding off on this?  As it stands there are a couple of\n> issues with the cvsimport-3 script including: ...\n\nActually I do. I think this, at least the early part of it, should\nbe merged to 'next' as soon as possible, *unless*\n\n (1) The cvsimport-2 & cvsps2 combo this series ships gives worse\n     experience than cvsimport we ship in v1.8.1 to end users of the\n     current cvsimport with cvsps2; and/or\n\n (2) The cvsimport-3 in this series, which is a copy of an older\n     version of what Eric has, is so broken that we are better off\n     starting cvsimport-3 by getting a fresh copy from Eric which\n     has been rewritten in a major way, than applying huge\n     incremental update patches that amounts to a total rewrite.\n\nThe point (1) is important from \"no regression\" point of view, and\nin a sense more important between the two because it is the first\nstep in the overall transition plan.\n\nEven though there may be remaining issues in cvsimport-3 and cvsps3\n(what new piece of software don't have issues?), my limited\nobservation of the exchanges between you and Eric suggests me that\nthe problem is not something that requires a total rewrite of how\ncvsimport-3 works, so I do not expect the point (2) to be true,\neither, but if I am mistaken, please let me know.\n\nBy advancing the topic to 'next', we will give people a more solid\n(read: not getting rewound) foundation to work with than \"if you are\nreally interested, grab the tip of 'pu', replace it with even newer\ncopy from Eric's repository and try it out\", so that more people can\nhelp us polish the scaffolding to let us ship two versions and also\nfind issues in the new cvsimport-3 and help fixing them.  At least,\nthat is what I've been hoping.\n\nI could stop at the first three patches, that is, introducing the\nversion switch wrapper that switches between cvsps2+cvsimport-2\ncombo and nothing, and then let you and Eric redo the \"start adding\ncvsps 3.x support\" and later patches when cvsimport-3 is ready.\nThat would give you a larger lattitude to rework cvsimport-3.  Is\nthat preferrable?\n"},{"id":"207578","messageId":"20130123092858.GJ7498@serenity.lan","threadId":"32696","inReplyTo":"7vobgglpv4.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-01-23T09:28:58Z","receivedAt":"2013-01-23T09:28:58Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Tue, Jan 22, 2013 at 04:11:59PM -0800, Junio C Hamano wrote:\n> John Keeping <john@keeping.me.uk> writes:\n>> Would you mind holding off on this?  As it stands there are a couple of\n>> issues with the cvsimport-3 script including: ...\n> \n> Actually I do. I think this, at least the early part of it, should\n> be merged to 'next' as soon as possible, *unless*\n> \n>  (1) The cvsimport-2 & cvsps2 combo this series ships gives worse\n>      experience than cvsimport we ship in v1.8.1 to end users of the\n>      current cvsimport with cvsps2; and/or\n> \n>  (2) The cvsimport-3 in this series, which is a copy of an older\n>      version of what Eric has, is so broken that we are better off\n>      starting cvsimport-3 by getting a fresh copy from Eric which\n>      has been rewritten in a major way, than applying huge\n>      incremental update patches that amounts to a total rewrite.\n> \n> The point (1) is important from \"no regression\" point of view, and\n> in a sense more important between the two because it is the first\n> step in the overall transition plan.\n> \n> Even though there may be remaining issues in cvsimport-3 and cvsps3\n> (what new piece of software don't have issues?), my limited\n> observation of the exchanges between you and Eric suggests me that\n> the problem is not something that requires a total rewrite of how\n> cvsimport-3 works, so I do not expect the point (2) to be true,\n> either, but if I am mistaken, please let me know.\n\nESR's cvsimport.py in the cvsps repository has no fixes over what's\nhere.  I think his comment in [1] indicates that he won't do any more\nwork on git-cvsimport.\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/214057\n\nIn my opinion the incremental import support really is substantially\nworse in cvsimport-3 than cvsimport-2.  cvsimport-2 looks at the output\nof git-for-each-ref to calculate the dates from which to continue each\nbranch.  cvsps cannot be told this information and so the cvsimport-3\nscript just takes the date of the last commit on the current branch.\n\nOn top of that, the incremental switch to cvsps-3 just causes it to\noutput:\n\n    from: refs/heads/branch^0\n\non the first commit for each branch, which I can't see working if a new\nbranch is created in CVS.\n\n> By advancing the topic to 'next', we will give people a more solid\n> (read: not getting rewound) foundation to work with than \"if you are\n> really interested, grab the tip of 'pu', replace it with even newer\n> copy from Eric's repository and try it out\", so that more people can\n> help us polish the scaffolding to let us ship two versions and also\n> find issues in the new cvsimport-3 and help fixing them.  At least,\n> that is what I've been hoping.\n\nThat's what I've done and it's convinced me that cvsps-3 is not ready\nfor use with incremental imports as it stands.\n\n> I could stop at the first three patches, that is, introducing the\n> version switch wrapper that switches between cvsps2+cvsimport-2\n> combo and nothing, and then let you and Eric redo the \"start adding\n> cvsps 3.x support\" and later patches when cvsimport-3 is ready.\n> That would give you a larger lattitude to rework cvsimport-3.  Is\n> that preferrable?\n\nMy preference would be for something like this, possibly with an\nexpanded examples section showing how to pipe the output of cvsps-3 or\ncvs2git into git-fast-import:\n\n-- >8 --\n\ndiff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt\nindex 9d5353e..20b846e 100644\n--- a/Documentation/git-cvsimport.txt\n+++ b/Documentation/git-cvsimport.txt\n@@ -18,6 +18,11 @@ SYNOPSIS\n \n DESCRIPTION\n -----------\n+*WARNING:* `git cvsimport` uses cvsps version 2, which is considered\n+deprecated; it does not work with cvsps version 3 and later.  If you are\n+performing a one-shot import of a CVS repository consider using cvsps-3,\n+cvs2git or parsecvs directly.\n+\n Imports a CVS repository into git. It will either create a new\n repository, or incrementally import into an existing one.\n \n-- 8< --\n\n\nJohn\n"},{"id":"207589","messageId":"CAEUsAPaUy5ug0_HPjWDTSnAG0kURhP-1-9nOu9_Tpn5nEv6N_Q@mail.gmail.com","threadId":"32696","inReplyTo":"20130123092858.GJ7498@serenity.lan","subject":"Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)","fromName":"Chris Rorvick","fromEmail":"chris@rorvick.com","sentAt":"2013-01-23T13:26:24Z","receivedAt":"2013-01-23T13:26:24Z","isPatch":false,"sender":{"key":"chris@rorvick.com","avatar":"https://avatars.githubusercontent.com/u/824726?v=4"},"body":"On Wed, Jan 23, 2013 at 3:28 AM, John Keeping <john@keeping.me.uk> wrote:\n> In my opinion the incremental import support really is substantially\n> worse in cvsimport-3 than cvsimport-2.  cvsimport-2 looks at the output\n> of git-for-each-ref to calculate the dates from which to continue each\n> branch.  cvsps cannot be told this information and so the cvsimport-3\n> script just takes the date of the last commit on the current branch.\n\nDo you really need a timestamp per branch, though?  If you have\nbranches A and B, and B has a commit timestamp 5 minutes after A, you\ncan infer that nothing happened on A for those five minutes, right?\nSo maybe a single timestamp is sufficient, it just may not be picking\nthe right one.  Instead cvsimport-3 should compute the latest\ntimestamp across all import branches.\n\nChris\n"},{"id":"207592","messageId":"20130123135510.GN7498@serenity.lan","threadId":"32696","inReplyTo":"CAEUsAPaUy5ug0_HPjWDTSnAG0kURhP-1-9nOu9_Tpn5nEv6N_Q@mail.gmail.com","subject":"Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-01-23T13:55:10Z","receivedAt":"2013-01-23T13:55:10Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Wed, Jan 23, 2013 at 07:26:24AM -0600, Chris Rorvick wrote:\n> On Wed, Jan 23, 2013 at 3:28 AM, John Keeping <john@keeping.me.uk> wrote:\n> > In my opinion the incremental import support really is substantially\n> > worse in cvsimport-3 than cvsimport-2.  cvsimport-2 looks at the output\n> > of git-for-each-ref to calculate the dates from which to continue each\n> > branch.  cvsps cannot be told this information and so the cvsimport-3\n> > script just takes the date of the last commit on the current branch.\n> \n> Do you really need a timestamp per branch, though?  If you have\n> branches A and B, and B has a commit timestamp 5 minutes after A, you\n> can infer that nothing happened on A for those five minutes, right?\n> So maybe a single timestamp is sufficient, it just may not be picking\n> the right one.  Instead cvsimport-3 should compute the latest\n> timestamp across all import branches.\n\nThe problem is telling which is an import branch, since it currently\njust used \"refs/heads/<branch>\".\n\nI do have a change to write the timestamp to a file, which takes the\nnewest commit across all of the branches that have changed during an\nimport.  That may well be good enough but doesn't let you incrementally\nupdate a repository that has been cloned from elsewhere.\n\n\nJohn\n"},{"id":"207610","messageId":"7vsj5rhlfs.fsf@alter.siamese.dyndns.org","threadId":"32696","inReplyTo":"20130123092858.GJ7498@serenity.lan","subject":"Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-23T17:13:27Z","receivedAt":"2013-01-23T17:13:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping <john@keeping.me.uk> writes:\n\n> My preference would be for something like this, possibly with an\n> expanded examples section showing how to pipe the output of cvsps-3 or\n> cvs2git into git-fast-import:\n>\n> -- >8 --\n>\n> diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt\n> index 9d5353e..20b846e 100644\n> --- a/Documentation/git-cvsimport.txt\n> +++ b/Documentation/git-cvsimport.txt\n> @@ -18,6 +18,11 @@ SYNOPSIS\n>  \n>  DESCRIPTION\n>  -----------\n> +*WARNING:* `git cvsimport` uses cvsps version 2, which is considered\n> +deprecated; it does not work with cvsps version 3 and later.  If you are\n> +performing a one-shot import of a CVS repository consider using cvsps-3,\n> +cvs2git or parsecvs directly.\n> +\n>  Imports a CVS repository into git. It will either create a new\n>  repository, or incrementally import into an existing one.\n>  \n> -- 8< --\n\nOK, that is certainly a lot simpler to explain.\n\nIs it \"it does not work yet with cvsps3\", or \"it will not ever work\nwith cvsps3\"?  The impression I am getting is that it is the latter.\n\nAlso, should we have a suggestion to people who are *not* performing\na one-shot import, i.e. doing incremental or bidirectional?\n"},{"id":"207638","messageId":"20130123211237.GR7498@serenity.lan","threadId":"32696","inReplyTo":"7vsj5rhlfs.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-01-23T21:12:37Z","receivedAt":"2013-01-23T21:12:37Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Wed, Jan 23, 2013 at 09:13:27AM -0800, Junio C Hamano wrote:\n> John Keeping <john@keeping.me.uk> writes:\n> \n> > My preference would be for something like this, possibly with an\n> > expanded examples section showing how to pipe the output of cvsps-3 or\n> > cvs2git into git-fast-import:\n> >\n> > -- >8 --\n> >\n> > diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt\n> > index 9d5353e..20b846e 100644\n> > --- a/Documentation/git-cvsimport.txt\n> > +++ b/Documentation/git-cvsimport.txt\n> > @@ -18,6 +18,11 @@ SYNOPSIS\n> >  \n> >  DESCRIPTION\n> >  -----------\n> > +*WARNING:* `git cvsimport` uses cvsps version 2, which is considered\n> > +deprecated; it does not work with cvsps version 3 and later.  If you are\n> > +performing a one-shot import of a CVS repository consider using cvsps-3,\n> > +cvs2git or parsecvs directly.\n> > +\n> >  Imports a CVS repository into git. It will either create a new\n> >  repository, or incrementally import into an existing one.\n> >  \n> > -- 8< --\n> \n> OK, that is certainly a lot simpler to explain.\n> \n> Is it \"it does not work yet with cvsps3\", or \"it will not ever work\n> with cvsps3\"?  The impression I am getting is that it is the latter.\n\nThe existing script (git-cvsimport.perl) won't ever work with cvsps-3\nsince features it relies on have been removed.\n\n> Also, should we have a suggestion to people who are *not* performing\n> a one-shot import, i.e. doing incremental or bidirectional?\n\nAs far as I know cvsps is the only backend that attempts to support\npartial exports but the support for that in its fast-export mode needs\nwork before I would consider it reliable.  For now the existing\ngit-cvsimport is the best option I'm aware of.\n\n\nJohn\n"},{"id":"207662","messageId":"7vip6ndveb.fsf@alter.siamese.dyndns.org","threadId":"32696","inReplyTo":"20130123211237.GR7498@serenity.lan","subject":"Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-24T05:04:12Z","receivedAt":"2013-01-24T05:04:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping <john@keeping.me.uk> writes:\n\n>> Is it \"it does not work yet with cvsps3\", or \"it will not ever work\n>> with cvsps3\"?  The impression I am getting is that it is the latter.\n>\n> The existing script (git-cvsimport.perl) won't ever work with cvsps-3\n> since features it relies on have been removed.\n\nI think you knew I already knew that.  I was hoping that cvsimport-3\nthat has multiple backend support may be able to start working by\nreading the fast-import stream cvsps3 produces, once you sort out\nthe \"last exported timestamp\" issue out.  As far as the end users\nare concerned, they would still be using cvsimport, even though the\nwrapper may redirect the invocation to cvsimport-3.\n\nIn any case, something like that will not happen in the near term,\nif ever, so \"cvsimport will not work if you only have cvsps3\" is a\ngood thing to add to its documentation.\n\nCare to roll a proper patch with a log message?  I'll discard the\ntopic for now and replace it with your documentation update.\n\n>> Also, should we have a suggestion to people who are *not* performing\n>> a one-shot import, i.e. doing incremental or bidirectional?\n>\n> As far as I know cvsps is the only backend that attempts to support\n> partial exports but the support for that in its fast-export mode needs\n> work before I would consider it reliable.  For now the existing\n> git-cvsimport is the best option I'm aware of.\n\nThanks.\n"},{"id":"207704","messageId":"20130124191845.GS7498@serenity.lan","threadId":"32696","inReplyTo":"7vip6ndveb.fsf@alter.siamese.dyndns.org","subject":"[PATCH] git-cvsimport.txt: cvsps-2 is deprecated","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-01-24T19:18:45Z","receivedAt":"2013-01-24T19:18:45Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"git-cvsimport relies on version 2 of cvsps and does not work with the\nnew version 3.  Since cvsps 3.x does not currently work as well as\nversion 2 for incremental import, document this fact.\n\nSpecifically, there is no way to make new git-cvsimport that supports\ncvsps 3.x and have a seamless transition for existing users since cvsps\n3.x needs a time from which to continue importing and git-cvsimport does\nnot save the time of the last import or import into a specific namespace\nso there is no safe way to calculate the time of the last import.\n\nSigned-off-by: John Keeping <john@keeping.me.uk>\n---\nOn Wed, Jan 23, 2013 at 09:04:12PM -0800, Junio C Hamano wrote:\n> Care to roll a proper patch with a log message?  I'll discard the\n> topic for now and replace it with your documentation update.\n\nHere it is.\n\n Documentation/git-cvsimport.txt | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt\nindex 9d5353e..f059ea9 100644\n--- a/Documentation/git-cvsimport.txt\n+++ b/Documentation/git-cvsimport.txt\n@@ -18,6 +18,12 @@ SYNOPSIS\n \n DESCRIPTION\n -----------\n+*WARNING:* `git cvsimport` uses cvsps version 2, which is considered\n+deprecated; it does not work with cvsps version 3 and later.  If you are\n+performing a one-shot import of a CVS repository consider using\n+link:http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or\n+link:https://github.com/BartMassey/parsecvs[parsecvs].\n+\n Imports a CVS repository into git. It will either create a new\n repository, or incrementally import into an existing one.\n \n-- \n1.8.1\n"},{"id":"207712","messageId":"7v7gn2bb5w.fsf@alter.siamese.dyndns.org","threadId":"32696","inReplyTo":"20130124191845.GS7498@serenity.lan","subject":"Re: [PATCH] git-cvsimport.txt: cvsps-2 is deprecated","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-24T20:04:11Z","receivedAt":"2013-01-24T20:04:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping <john@keeping.me.uk> writes:\n\n> git-cvsimport relies on version 2 of cvsps and does not work with the\n> new version 3.  Since cvsps 3.x does not currently work as well as\n> version 2 for incremental import, document this fact.\n>\n> Specifically, there is no way to make new git-cvsimport that supports\n> cvsps 3.x and have a seamless transition for existing users since cvsps\n> 3.x needs a time from which to continue importing and git-cvsimport does\n> not save the time of the last import or import into a specific namespace\n> so there is no safe way to calculate the time of the last import.\n\nIsn't the whole \"and git-cvsimport does not save the time...\"  part\nsomething that can be fixed in the new cvsimport that reads the\noutput from cvsps3?\n\nTo me, it sounds more like\n\n    cvsps2 + cvsimport has an unfixable bugs and there have been an\n    effort to rewrite cvsps2 from scratch.  The resulting cvsp3\n    currently is unusable with cvsimport, especially when importing\n    the history incrementally, and it isn't expected that it will\n    ever be usable with cvsimport again.\n\n    There are other tools that analyse the original history better\n    and emits more correct output when used to convert the whole\n    history, and hopefully cvsps3 + fast-import would become one of\n    them.  Suggest users to use them instead of cvsimport when they\n    are not doing an incremental import.\n\nBy the way, do we want to make any recommendation to the distro\nfolks which cvsps they should ship?  It appears that not shipping\ncvsps2 would be a major regression if cvsps3 does not plan to\nsupport incrementals, so shipping both might be the safest way for\nthem to support their users with different needs.\n\nThanks.  I think the patch text itself is good.\n\n> Signed-off-by: John Keeping <john@keeping.me.uk>\n> ---\n> On Wed, Jan 23, 2013 at 09:04:12PM -0800, Junio C Hamano wrote:\n>> Care to roll a proper patch with a log message?  I'll discard the\n>> topic for now and replace it with your documentation update.\n>\n> Here it is.\n>\n>  Documentation/git-cvsimport.txt | 6 ++++++\n>  1 file changed, 6 insertions(+)\n>\n> diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt\n> index 9d5353e..f059ea9 100644\n> --- a/Documentation/git-cvsimport.txt\n> +++ b/Documentation/git-cvsimport.txt\n> @@ -18,6 +18,12 @@ SYNOPSIS\n>  \n>  DESCRIPTION\n>  -----------\n> +*WARNING:* `git cvsimport` uses cvsps version 2, which is considered\n> +deprecated; it does not work with cvsps version 3 and later.  If you are\n> +performing a one-shot import of a CVS repository consider using\n> +link:http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or\n> +link:https://github.com/BartMassey/parsecvs[parsecvs].\n> +\n>  Imports a CVS repository into git. It will either create a new\n>  repository, or incrementally import into an existing one.\n"},{"id":"207713","messageId":"20130124201330.GT7498@serenity.lan","threadId":"32696","inReplyTo":"7v7gn2bb5w.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-cvsimport.txt: cvsps-2 is deprecated","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-01-24T20:13:30Z","receivedAt":"2013-01-24T20:13:30Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Thu, Jan 24, 2013 at 12:04:11PM -0800, Junio C Hamano wrote:\n> John Keeping <john@keeping.me.uk> writes:\n> \n> > git-cvsimport relies on version 2 of cvsps and does not work with the\n> > new version 3.  Since cvsps 3.x does not currently work as well as\n> > version 2 for incremental import, document this fact.\n> >\n> > Specifically, there is no way to make new git-cvsimport that supports\n> > cvsps 3.x and have a seamless transition for existing users since cvsps\n> > 3.x needs a time from which to continue importing and git-cvsimport does\n> > not save the time of the last import or import into a specific namespace\n> > so there is no safe way to calculate the time of the last import.\n> \n> Isn't the whole \"and git-cvsimport does not save the time...\"  part\n> something that can be fixed in the new cvsimport that reads the\n> output from cvsps3?\n\nYes it can be fixed there (and I have patches to do that) - my argument\nhere is that there cannot be a seamless upgrade for people who are\ncurrently using git-cvsimport incrementally.  If you don't have that\nfile then how do you create it to reflect the current state of your\nrepository?\n\n> To me, it sounds more like\n> \n>     cvsps2 + cvsimport has an unfixable bugs and there have been an\n>     effort to rewrite cvsps2 from scratch.  The resulting cvsp3\n>     currently is unusable with cvsimport, especially when importing\n>     the history incrementally, and it isn't expected that it will\n>     ever be usable with cvsimport again.\n\ncvsps3 isn't a re-write, it's cvsps2 with a lot of things ripped out and\na fast-export mode added.  And in fast-export mode it cannot inspect the\nGit repository in the same way that git-cvsimport does.\n\n>     There are other tools that analyse the original history better\n>     and emits more correct output when used to convert the whole\n>     history, and hopefully cvsps3 + fast-import would become one of\n>     them.  Suggest users to use them instead of cvsimport when they\n>     are not doing an incremental import.\n\nYes.  The consensus seems to be that cvs2git is the most correct.\n\n> By the way, do we want to make any recommendation to the distro\n> folks which cvsps they should ship?  It appears that not shipping\n> cvsps2 would be a major regression if cvsps3 does not plan to\n> support incrementals, so shipping both might be the safest way for\n> them to support their users with different needs.\n\nI agree.  cvsps is only one binary and a man page so I don't think it\nwould be too hard to ship both.\n\n\nJohn\n"},{"id":"207717","messageId":"7vmwvy9u3p.fsf@alter.siamese.dyndns.org","threadId":"32696","inReplyTo":"20130124201330.GT7498@serenity.lan","subject":"Re: [PATCH] git-cvsimport.txt: cvsps-2 is deprecated","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-24T20:58:02Z","receivedAt":"2013-01-24T20:58:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping <john@keeping.me.uk> writes:\n\n> On Thu, Jan 24, 2013 at 12:04:11PM -0800, Junio C Hamano wrote:\n>> John Keeping <john@keeping.me.uk> writes:\n>> \n>> > git-cvsimport relies on version 2 of cvsps and does not work with the\n>> > new version 3.  Since cvsps 3.x does not currently work as well as\n>> > version 2 for incremental import, document this fact.\n>> >\n>> > Specifically, there is no way to make new git-cvsimport that supports\n>> > cvsps 3.x and have a seamless transition for existing users since cvsps\n>> > 3.x needs a time from which to continue importing and git-cvsimport does\n>> > not save the time of the last import or import into a specific namespace\n>> > so there is no safe way to calculate the time of the last import.\n>> \n>> Isn't the whole \"and git-cvsimport does not save the time...\"  part\n>> something that can be fixed in the new cvsimport that reads the\n>> output from cvsps3?\n>\n> Yes it can be fixed there (and I have patches to do that) - my argument\n> here is that there cannot be a seamless upgrade for people who are\n> currently using git-cvsimport incrementally.  If you don't have that\n> file then how do you create it to reflect the current state of your\n> repository?\n\nI am not disagreeing with your patch text to warn the current users\nthat cvsimport will be made unusable if they lose cvsps2, and they\nare better off using other tools when doing a whole-history import.\n\nI was trying to make sure that my understanding of the current\nsituation and future possibilities matches yours.\n\nThanks, I think you clarified the situation better with your\nresponse.\n"},{"id":"207757","messageId":"CAEUsAPagzN9wWAsSpBVOv7+ei3fAix407dB0EAUd7q7k7SugPw@mail.gmail.com","threadId":"32696","inReplyTo":"20130123211237.GR7498@serenity.lan","subject":"Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)","fromName":"Chris Rorvick","fromEmail":"chris@rorvick.com","sentAt":"2013-01-25T04:55:57Z","receivedAt":"2013-01-25T04:55:57Z","isPatch":false,"sender":{"key":"chris@rorvick.com","avatar":"https://avatars.githubusercontent.com/u/824726?v=4"},"body":"On Wed, Jan 23, 2013 at 3:12 PM, John Keeping <john@keeping.me.uk> wrote:\n> The existing script (git-cvsimport.perl) won't ever work with cvsps-3\n> since features it relies on have been removed.\n\nNot reporting the ancestry branch seems to be the big one.  Are there\nothers?  I had a version of the Perl script sort of working, but only\nwell enough to pass the t9600 and t9604 tests.\n\nChris\n"},{"id":"207780","messageId":"20130125090941.GU7498@serenity.lan","threadId":"32696","inReplyTo":"CAEUsAPagzN9wWAsSpBVOv7+ei3fAix407dB0EAUd7q7k7SugPw@mail.gmail.com","subject":"Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-01-25T09:09:41Z","receivedAt":"2013-01-25T09:09:41Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Thu, Jan 24, 2013 at 10:55:57PM -0600, Chris Rorvick wrote:\n> On Wed, Jan 23, 2013 at 3:12 PM, John Keeping <john@keeping.me.uk> wrote:\n> > The existing script (git-cvsimport.perl) won't ever work with cvsps-3\n> > since features it relies on have been removed.\n> \n> Not reporting the ancestry branch seems to be the big one.  Are there\n> others?\n\nFor some reason I thought the non-fast-export output mode had already\nbeen removed, but now that I check it looks like it's still there just\nwith a warning that it may be removed in the future.\n\n\nJohn\n"}]}