{"thread":{"id":"21154","subject":"What's cooking in git.git (Oct 2009, #01; Wed, 07)","startedAt":"2009-10-08T06:33:57Z","lastAt":"2009-10-30T12:41:36Z","messageCount":17,"participants":["Junio C Hamano","Johannes Schindelin","Sverre Rabbelier","Marius Storm-Olsen","Shawn O. Pearce","Erik Faye-Lund","Jakub Narebski","Matt McClure","Ian Clatworthy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"124362","messageId":"7viqeqjsx6.fsf@alter.siamese.dyndns.org","threadId":"21154","inReplyTo":null,"subject":"What's cooking in git.git (Oct 2009, #01; Wed, 07)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-08T06:33:57Z","receivedAt":"2009-10-08T06:33:57Z","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' while commits prefixed with '+' are in 'next'.  The ones\nmarked with '.' do not appear in any of the integration branches, but I am\nstill holding onto them.\n\nIn 1.7.0, we plan to correct handful of warts in the interfaces everybody\nagrees that they were mistakes.  The resulting system may not be strictly\nbackward compatible.  Currently planeed changes are:\n\n * refuse push to update the checked out branch in a non-bare repo by\n   default\n\n   Make \"git push\" into a repository to update the branch that is checked\n   out fail by default.  You can countermand this default by setting a\n   configuration variable in the receiving repository.\n\n   http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007\n\n * refuse push to delete the current branch by default\n\n   Make \"git push $there :$killed\" to delete the branch that is pointed at\n   by its HEAD fail by default.  You can countermand this default by\n   setting a configuration variable in the receiving repository.\n\n   http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936\n\n * git-send-email won't make deep threads by default\n\n   Many people said that by default when sending more than 2 patches the\n   threading git-send-email makes by default is hard to read, and they\n   prefer the default be one cover letter and each patch as a direct\n   follow-up to the cover letter.  You can countermand this by setting a\n   configuration variable.\n\n   http://article.gmane.org/gmane.comp.version-control.git/109790\n\n * git-status won't be \"git-commit --dry-run\" anymore\n\n   http://thread.gmane.org/gmane.comp.version-control.git/125989/focus=125993\n\n * \"git-diff -w --exit-code\" will exit success if only differences it\n   found are whitespace changes that are stripped away from the output.\n\n   http://thread.gmane.org/gmane.comp.version-control.git/119731/focus=119751\n\nWe are in pre-release feature freeze.  'next' will hold topics meant for\n1.6.6 and 1.7.0.\n\nTonight's tip of 'master' is 1.6.5-rc3.\n\n--------------------------------------------------\n[New Topics]\n\n* ch/am-header (2009-09-25) 2 commits\n  (merged to 'next' on 2009-09-25 at f86e197)\n + git-am: force egrep to use correct characters set\n + git-am: fixed patch_format detection according to RFC2822\n\n* dk/blame-el (2009-09-29) 1 commit\n - git-blame.el: Change how blame information is shown.\n\n* ef/msvc-noreturn (2009-09-30) 2 commits\n  (merged to 'next' on 2009-10-07 at 66137a0)\n + add NORETURN_PTR for function pointers\n + increase portability of NORETURN declarations\n\njk: This is the latest round and I think should be ready for at least\n'next' (maybe even 'master' as it is really about the build and not about\nfunctionality).\n\n* ef/msys-imap (2009-10-03) 7 commits\n - mingw: enable OpenSSL\n - mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle\n - imap-send: provide fall-back random-source\n - imap-send: build imap-send on Windows\n - imap-send: fix compilation-error on Windows\n - imap-send: use run-command API for tunneling\n - imap-send: use separate read and write fds\n\njk: This is from an RFC which has generated some comments. He should be\nposting another round soon. 'pu' at best.\n\n* fc/mutt-alias (2009-09-30) 1 commit\n  (merged to 'next' on 2009-10-07 at df7ac20)\n + send-email: fix mutt regex for grouped aliases\n\njk: Latest round that addressed comments. Ready for 'next' if not\n'master'.\n\n* jk/reflog-date (2009-09-24) 1 commit\n  (merged to 'next' on 2009-09-29 at 43d444a)\n + improve reflog date/number heuristic\n\n* jn/gitweb-patch (2009-09-30) 1 commit\n - gitweb: Do not show 'patch' link in 'commit' view for merges\n\njk: After some comments with Jakub, I think the code is right but he\npromised a re-roll with more in the commit message.\n\n* mr/gitweb-snapshot (2009-09-26) 2 commits\n - gitweb: append short hash ids to snapshot files\n - gitweb: check given hash before trying to create snapshot\n\njk: He posted a v5 of his series. I didn't look at it closely, but Jakub\nack'd it.\n\n* mr/instaweb-cgid (2009-09-26) 1 commit\n  (merged to 'next' on 2009-09-29 at 3524604)\n + instaweb: support mod_cgid for apache2\n\n* tf/doc-pt-br (2009-09-23) 1 commit\n - Documentation: update pt-BR\n\nThe current AsciiDoc may barf on NOME and SINOPSE, as pt_BR language\ndefinition is not widely distributed yet (it just hit the development\ntree).  Need to revert these headings (or change the length of the section\nunderlines to match the length of translated names).\n\n* jc/pretty-lf (2009-10-04) 1 commit\n - Pretty-format: %[+-]x to tweak inter-item newlines\n\nI am not happy with this one yet.  I am contemplating to introduce a new\nsyntax \"%[magic(param)<anything>%]\" to generalize expressions of this and\nline wrapping features in an extensible way.\n\n* js/log-rewrap (2008-11-10) 3 commits\n . Add \"%w\" to pretty formats, which rewraps the commit message\n - Add strbuf_add_wrapped_text() to utf8.[ch]\n - print_wrapped_text(): allow hard newlines\n\n... and the first two from this series will be useful to implement an\nexample magic \"wrap\", e.g. \"%{wrap(i,j,w)%s%+b%]\".\n\n* jg/log-format-body-indent (2009-09-19) 1 commit\n . git-log --format: Add %B tag with %B(x) option\n\nI think we should redo this on top of the first two patches from\njs/log-rewrap series; %B(x) is just a special case %B(x,x,0), no?  If a\nmagic value 0 (or negative) given to wrap-width does not disable wrapping,\nwe probably should make it so.  I merged this to 'pu' but then ejected it\nbecause it seems to break at least t6006.\n\n* bg/rebase-reword (2009-10-07) 1 commit\n - Teach 'rebase -i' the command \"reword\"\n\n* js/diff-verbose-submodule (2009-10-04) 1 commit\n - Add the --submodule-summary option to the diff option family\n\nDscho sounded like he has some corrections after list comments, but I did\nnot pick up his interdiff in the middle.\n\n--------------------------------------------------\n[Stalled]\n\n* je/send-email-no-subject (2009-08-05) 1 commit\n  (merged to 'next' on 2009-08-30 at b6455c2)\n + send-email: confirm on empty mail subjects\n\nThe existing tests cover the positive case (i.e. as long as the user says\n\"yes\" to the \"do you really want to send this message that lacks subject\",\nthe message is sent) of this feature, but the feature itself needs its own\ntest to verify the negative case (i.e. does it correctly stop if the user\nsays \"no\"?)\n\n* jh/cvs-helper (2009-08-18) 8 commits\n - More fixes to the git-remote-cvs installation procedure\n - Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs\n - Add simple selftests of git-remote-cvs functionality\n - git-remote-cvs: Remote helper program for CVS repositories\n - 2/2: Add Python support library for CVS remote helper\n - 1/2: Add Python support library for CVS remote helper\n - Basic build infrastructure for Python scripts\n - Allow helpers to request marks for fast-import\n (this branch uses db/vcs-helper-rest.)\n\nBuilds on db/vcs-helper.  There is a re-roll planned.\n\n* ne/rev-cache (2009-09-07) 7 commits\n - support for commit grafts, slight change to general mechanism\n - support for path name caching in rev-cache\n - full integration of rev-cache into git, completed test suite\n - administrative functions for rev-cache, start of integration into git\n - support for non-commit object caching in rev-cache\n - basic revision cache system, no integration or features\n - man page and technical discussion for rev-cache\n\nI merged this to 'pu' but then ejected it because it seems to break at\nleast t6001.\n\n--------------------------------------------------\n[Cooking]\n\n* jl/submodule-add-noname (2009-09-22) 1 commit\n - git submodule add: make the <path> parameter optional\n\nDscho started an interesting discussion regarding the larger workflow in\nwhich the \"submodule add\" is used.  I think the patch itself makes sense\nbut at the same time it probably makes sense to also take the <path> and\ninfer the <repository> as Dscho suggested, probably in \"git submodule\nadd\", not in \"git add\" proper, at least initially.\n\n* jc/fix-tree-walk (2009-09-14) 9 commits\n - read-tree --debug-unpack\n - unpack-trees.c: look ahead in the index\n - unpack-trees.c: prepare for looking ahead in the index\n - traverse_trees(): handle D/F conflict case sanely\n - more D/F conflict tests\n - tests: move convenience regexp to match object names to test-lib.sh\n - unpack_callback(): use unpack_failed() consistently\n - unpack-trees: typofix\n - diff-lib.c: fix misleading comments on oneway_diff()\n\nThis is my replacement for Linus's lt/maint-traverse-trees-fix patch.  It\nis not so much as a counter-proposal; I originally thought it might make\nsense to walk the index and drive the walker to return the entries from\ntrees to match entries from the index, but I ended up doing pretty much\nwhat Linus outlined --- walk the trees, and have the index walker follow\nit.  It turned out that the index side also needed some hairy look-ahead,\nand I am only half satisfied with the current status of the series.\n\nTo fix the resolve merge regression seen in t6035, git-merge-resolve needs\nto be rewritten not to use the one-path-at-a-time \"git merge-index\".\n\n* jp/fetch-tag-match (2009-09-17) 1 commit\n - fetch: Speed up fetch by rewriting find_non_local_tags\n\nI did not have much energy left while dealing with the \"fix-tree-walk\"\nseries, so I just queued this without reading nor thinking about it very\nmuch.  I personally liked my version that had far smaller number of lines\nchanged (which means I can be fairly certain that it did not introduce any\nregression), but perhaps the majorly rewritten logic this patch gives us\nmay be easier to follow and maintain.  We'll see.\n\n* jc/maint-blank-at-eof (2009-09-15) 0 commits.\n (this branch uses jc/maint-1.6.0-blank-at-eof.)\n\nThe series does not have a commit of its own but is a preparation for\nmerging the original jc/1.6.0-maint-blank-at-eof topic to 'maint' and then\n'master'.  It is a fix for longstanding bug and 1.6.5 will not contain\nthis topic.\n\n* db/vcs-helper-rest (2009-09-03) 6 commits\n - Allow helpers to report in \"list\" command that the ref is unchanged\n - Add support for \"import\" helper command\n - Add a config option for remotes to specify a foreign vcs\n - Allow programs to not depend on remotes having urls\n - Allow fetch to modify refs\n - Use a function to determine whether a remote is valid\n (this branch is used by jh/cvs-helper.)\n\nThis holds the remainder of the db/vcs-helper topic that has already\nmerged for 1.6.5.\n\n* jh/notes (2009-09-12) 13 commits\n - Selftests verifying semantics when loading notes trees with various fanouts\n - Teach the notes lookup code to parse notes trees with various fanout schemes\n - notes.[ch] fixup: avoid old-style declaration\n - Teach notes code to free its internal data structures on request.\n - Add '%N'-format for pretty-printing commit notes\n - Add flags to get_commit_notes() to control the format of the note string\n - t3302-notes-index-expensive: Speed up create_repo()\n - fast-import: Add support for importing commit notes\n - Teach \"-m <msg>\" and \"-F <file>\" to \"git notes edit\"\n - Add an expensive test for git-notes\n - Speed up git notes lookup\n - Add a script to edit/inspect notes\n - Introduce commit notes\n (this branch uses sr/gfi-options.)\n\nRerolled and queued.\n\n* jn/gitweb-show-size (2009-09-07) 1 commit\n - gitweb: Add 'show-sizes' feature to show blob sizes in tree view\n\n* lt/maint-traverse-trees-fix (2009-09-06) 1 commit.\n . Prepare 'traverse_trees()' for D/F conflict lookahead\n\nEjected from 'pu' (see jc/fix-tree-walk above).\n\n* jc/maint-1.6.0-blank-at-eof (2009-09-14) 15 commits.\n  (merged to 'next' on 2009-09-15 at 9cbfa00)\n + diff -B: colour whitespace errors\n + diff.c: emit_add_line() takes only the rest of the line\n + diff.c: split emit_line() from the first char and the rest of the line\n + diff.c: shuffling code around\n + diff --whitespace: fix blank lines at end\n  (merged to 'next' on 2009-09-07 at 165dc3c)\n + core.whitespace: split trailing-space into blank-at-{eol,eof}\n + diff --color: color blank-at-eof\n + diff --whitespace=warn/error: fix blank-at-eof check\n + diff --whitespace=warn/error: obey blank-at-eof\n + diff.c: the builtin_diff() deals with only two-file comparison\n + apply --whitespace: warn blank but not necessarily empty lines at EOF\n + apply --whitespace=warn/error: diagnose blank at EOF\n + apply.c: split check_whitespace() into two\n + apply --whitespace=fix: detect new blank lines at eof correctly\n + apply --whitespace=fix: fix handling of blank lines at the eof\n (this branch is used by jc/maint-blank-at-eof.)\n\nThis is a fix for an ancient bug (or inconsistent set of features); the\ntopic is based on an ancient codebase and is designed to be merged\nupwards.  jc/maint-blank-at-eof serves that purpose.\n\nWill not be in 1.6.5.\n\n* jn/gitweb-blame (2009-09-01) 5 commits\n - gitweb: Minify gitweb.js if JSMIN is defined\n - gitweb: Create links leading to 'blame_incremental' using JavaScript\n  (merged to 'next' on 2009-09-07 at 3622199)\n + gitweb: Colorize 'blame_incremental' view during processing\n + gitweb: Incremental blame (using JavaScript)\n + gitweb: Add optional \"time to generate page\" info in footer\n\nAjax-y blame.\n\n* sr/gfi-options (2009-09-06) 6 commits\n  (merged to 'next' on 2009-09-07 at 5f6b0ff)\n + fast-import: test the new option command\n + fast-import: add option command\n + fast-import: test the new feature command\n + fast-import: add feature command\n + fast-import: put marks reading in it's own function\n + fast-import: put option parsing code in separate functions\n (this branch is used by jh/notes.)\n\nPing?\n\n* nd/sparse (2009-08-20) 19 commits\n - sparse checkout: inhibit empty worktree\n - Add tests for sparse checkout\n - read-tree: add --no-sparse-checkout to disable sparse checkout support\n - unpack-trees(): ignore worktree check outside checkout area\n - unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index\n - unpack-trees(): \"enable\" sparse checkout and load $GIT_DIR/info/sparse-checkout\n - unpack-trees.c: generalize verify_* functions\n - unpack-trees(): add CE_WT_REMOVE to remove on worktree alone\n - Introduce \"sparse checkout\"\n - dir.c: export excluded_1() and add_excludes_from_file_1()\n - excluded_1(): support exclude files in index\n - unpack-trees(): carry skip-worktree bit over in merged_entry()\n - Read .gitignore from index if it is skip-worktree\n - Avoid writing to buffer in add_excludes_from_file_1()\n - Teach Git to respect skip-worktree bit (writing part)\n - Teach Git to respect skip-worktree bit (reading part)\n - Introduce \"skip-worktree\" bit in index, teach Git to get/set this bit\n - Add test-index-version\n - update-index: refactor mark_valid() in preparation for new options\n\n--------------------------------------------------\n[For 1.7.0]\n\n* jk/1.7.0-status (2009-09-05) 5 commits\n - docs: note that status configuration affects only long format\n  (merged to 'next' on 2009-09-07 at 8a7c563)\n + commit: support alternate status formats\n + status: add --porcelain output format\n + status: refactor format option parsing\n + status: refactor short-mode printing to its own function\n (this branch uses jc/1.7.0-status.)\n\nGives the --short output format to post 1.7.0 \"git commit --dry-run\" that\nis similar to that of post 1.7.0 \"git status\".\n\n* jc/1.7.0-status (2009-09-05) 4 commits\n  (merged to 'next' on 2009-09-06 at 19d4beb)\n + status: typo fix in usage\n  (merged to 'next' on 2009-08-22 at b3507bb)\n + git status: not \"commit --dry-run\" anymore\n + git stat -s: short status output\n + git stat: the beginning of \"status that is not a dry-run of commit\"\n (this branch is used by jk/1.7.0-status.)\n\nWith this, \"git status\" is no longer \"git commit --dry-run\".\n\n* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit\n  (merged to 'next' on 2009-08-22 at 5106de8)\n + send-email: make --no-chain-reply-to the default\n\n* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.\n  (merged to 'next' on 2009-08-30 at 0623572)\n + diff.c: fix typoes in comments\n  (merged to 'next' on 2009-08-27 at 81fb2bd)\n + Make test case number unique\n  (merged to 'next' on 2009-08-02 at 9c08420)\n + diff: Rename QUIET internal option to QUICK\n + diff: change semantics of \"ignore whitespace\" options\n\nThis changes exit code from \"git diff --ignore-whitespace\" and friends\nwhen there is no actual output.  It is a backward incompatible change, but\nwe could argue that it is a bugfix.\n\n* jc/1.7.0-push-safety (2009-02-09) 2 commits\n  (merged to 'next' on 2009-08-02 at 38b82fe)\n + Refuse deleting the current branch via push\n + Refuse updating the current branch in a non-bare repository via push\n\n--------------------------------------------------\n[I have been too busy to purge these]\n\n* jc/log-tz (2009-03-03) 1 commit.\n - Allow --date=local --date=other-format to work as expected\n\nMaybe some people care about this.  I dunno.\n\n* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.\n - mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker\n\nMaybe some people care about this.  I dunno.\n\n* lt/read-directory (2009-05-15) 3 commits.\n . Add initial support for pathname conversion to UTF-8\n . read_directory(): infrastructure for pathname character set conversion\n . Add 'fill_directory()' helper function for directory traversal\n\n* cc/reset-merge (2009-09-16) 4 commits\n . reset: add test cases for \"--merge-safe\" option\n . reset: add option \"--merge-safe\" to \"git reset\"\n . reset: use \"unpack_trees()\" directly instead of \"git read-tree\"\n . reset: add a few tests for \"git reset --merge\"\n\n* cc/sequencer-rebase-i (2009-08-28) 15 commits\n . rebase -i: use \"git sequencer--helper --cherry-pick\"\n . sequencer: add \"--cherry-pick\" option to \"git sequencer--helper\"\n . sequencer: add \"do_commit()\" and related functions working on \"next_commit\"\n . pick: libify \"pick_help_msg()\"\n . revert: libify cherry-pick and revert functionnality\n . rebase -i: use \"git sequencer--helper --fast-forward\"\n . sequencer: let \"git sequencer--helper\" callers set \"allow_dirty\"\n . sequencer: add \"--fast-forward\" option to \"git sequencer--helper\"\n . sequencer: add \"do_fast_forward()\" to perform a fast forward\n . rebase -i: use \"git sequencer--helper --reset-hard\"\n . sequencer: add \"--reset-hard\" option to \"git sequencer--helper\"\n . sequencer: add \"reset_almost_hard()\" and related functions\n . rebase -i: use \"git sequencer--helper --make-patch\"\n . sequencer: add \"make_patch\" function to save a patch\n . sequencer: add \"builtin-sequencer--helper.c\"\n"},{"id":"124363","messageId":"alpine.DEB.1.00.0910080848380.4985@pacific.mpi-cbg.de","threadId":"21154","inReplyTo":"7viqeqjsx6.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-10-08T06:49:32Z","receivedAt":"2009-10-08T06:49:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 7 Oct 2009, Junio C Hamano wrote:\n\n> * sr/gfi-options (2009-09-06) 6 commits\n>   (merged to 'next' on 2009-09-07 at 5f6b0ff)\n>  + fast-import: test the new option command\n>  + fast-import: add option command\n>  + fast-import: test the new feature command\n>  + fast-import: add feature command\n>  + fast-import: put marks reading in it's own function\n>  + fast-import: put option parsing code in separate functions\n>  (this branch is used by jh/notes.)\n> \n> Ping?\n\nShawn, last time I heard of this issue, it was stuck in your review queue.\n\nCiao,\nDscho\n"},{"id":"124364","messageId":"fabb9a1e0910072349q68d6756cgebb041a0bbe2ba65@mail.gmail.com","threadId":"21154","inReplyTo":"alpine.DEB.1.00.0910080848380.4985@pacific.mpi-cbg.de","subject":"Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-10-08T06:49:32Z","receivedAt":"2009-10-08T06:49:32Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Thu, Oct 8, 2009 at 08:49, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Shawn, last time I heard of this issue, it was stuck in your review queue.\n\nCorrect, am waiting for Shawn's decision on whether to drop options\nand replace them with additional features or not.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"124365","messageId":"4ACD8D8E.3060606@gmail.com","threadId":"21154","inReplyTo":"7viqeqjsx6.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)","fromName":"Marius Storm-Olsen","fromEmail":"mstormo@gmail.com","sentAt":"2009-10-08T06:58:22Z","receivedAt":"2009-10-08T06:58:22Z","isPatch":false,"sender":{"key":"mstormo@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1500?v=4"},"body":"Junio C Hamano said the following on 08.10.2009 08:33:\n> * ef/msys-imap (2009-10-03) 7 commits\n>  - mingw: enable OpenSSL\n>  - mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle\n>  - imap-send: provide fall-back random-source\n>  - imap-send: build imap-send on Windows\n>  - imap-send: fix compilation-error on Windows\n>  - imap-send: use run-command API for tunneling\n>  - imap-send: use separate read and write fds\n\nDon't forget about the MSVC patch ontop of this series:\nMessage-ID: <18cd41840910031300i32c74b15t74eb9eee23ff8469@mail.gmail.com>\nSubject: [PATCH] MSVC: Enable OpenSSL, and translate -lcrypto\n\n--\n.marius\n"},{"id":"124395","messageId":"20091008173900.GI9261@spearce.org","threadId":"21154","inReplyTo":"fabb9a1e0910072349q68d6756cgebb041a0bbe2ba65@mail.gmail.com","subject":"Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-10-08T17:39:00Z","receivedAt":"2009-10-08T17:39:00Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sverre Rabbelier <srabbelier@gmail.com> wrote:\n> On Thu, Oct 8, 2009 at 08:49, Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n> > Shawn, last time I heard of this issue, it was stuck in your review queue.\n> \n> Correct, am waiting for Shawn's decision on whether to drop options\n> and replace them with additional features or not.\n\nUh.  Wow, it has been a while.\n\nIIRC my problem with options was we weren't enforcing them, and yet\nthey were necessary for a successful import, e.g. import-marks or\nexport-marks.  A minor error could cause a successful looking import\nthat is wrong due to the marks being messed up, or not saved out.\n\nSo I was leaning towards making these features, but then they\naren't necessarily compatible with the other fast-import tools.\nWhich led me to a stalemate, and I forgot about the thread.\n\nDammit.\n\nWe should run this past the fast-import list but I think we want\nto declare features for import-marks and export-marks:\n\n  feature import-marks=in.marks\n  feature export-marks=out.marks\n\nand define these as paths to local files which store a VCS specific\nformatted mapping of fast-import mark numbers to VCS labels.\n\n\nOther options that are clearly git should be declared as:\n\n  option git max-pack-size=2048\n\nwith the meaning of option being declared something like:\n\n  If the parsing VCS name appears as the first argument, the parsing\n  VCS must recognize and support the supplied option, and if not\n  recognized or not supported must abort parsing altogether.\n\n  If the parsing VCS name is not the first argument, it must entirely\n  ignore the option command and not try to process its contents.\n\n-- \nShawn.\n"},{"id":"124396","messageId":"fabb9a1e0910081058m59527600o392a6b438b18512e@mail.gmail.com","threadId":"21154","inReplyTo":"20091008173900.GI9261@spearce.org","subject":"Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-10-08T17:58:48Z","receivedAt":"2009-10-08T17:58:48Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\n[edited Shawn's message somewhat to be more relevant to vcs-fast-import-dev]\n\nOn Thu, Oct 8, 2009 at 19:39, Shawn O. Pearce <spearce@spearce.org> wrote:\n> IIRC my problem with options was we weren't enforcing them, and yet\n> they were necessary for a successful import, e.g. import-marks or\n> export-marks.  A minor error could cause a successful looking import\n> that is wrong due to the marks being messed up, or not saved out.\n>\n> So I was leaning towards making these features, but then they\n> aren't necessarily compatible with the other fast-import tools.\n>\n> I think we want to declare features for import-marks and export-marks:\n>\n>  feature import-marks=in.marks\n>  feature export-marks=out.marks\n>\n> and define these as paths to local files which store a VCS specific\n> formatted mapping of fast-import mark numbers to VCS labels.\n>\n>\n> Other options that are clearly git should be declared as:\n>\n>  option git max-pack-size=2048\n>\n> with the meaning of option being declared something like:\n>\n>  If the parsing VCS name appears as the first argument, the parsing\n>  VCS must recognize and support the supplied option, and if not\n>  recognized or not supported must abort parsing altogether.\n>\n>  If the parsing VCS name is not the first argument, it must entirely\n>  ignore the option command and not try to process its contents.\n\nI think it makes to ignore options that are not for our vcs, as long\nas options that change import behavior (such as marks, date-format)\nare combined with, say, 'feature tool=git'. This way we can be sure\nthat when outputting out a vcs specific stream, it is only parsed by\nthat vcs.\n\nNote: yes, I know that marks and date-format are features now, but\nthere's really no other suitable example that I could think of).\n\nvcs fast import devs please ack this idea (and perhaps suggest\nsomething other than \"feature tool=git\" if preferable) so that I can\nreroll my gfi-options series :).\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"124397","messageId":"40aa078e0910081115q1bf924e8s22f3ee11dbe7c8b7@mail.gmail.com","threadId":"21154","inReplyTo":"4ACD8D8E.3060606@gmail.com","subject":"Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2009-10-08T18:15:58Z","receivedAt":"2009-10-08T18:15:58Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Thu, Oct 8, 2009 at 8:58 AM, Marius Storm-Olsen <mstormo@gmail.com> wrote:\n> Junio C Hamano said the following on 08.10.2009 08:33:\n>>\n>> * ef/msys-imap (2009-10-03) 7 commits\n>>  - mingw: enable OpenSSL\n>>  - mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle\n>>  - imap-send: provide fall-back random-source\n>>  - imap-send: build imap-send on Windows\n>>  - imap-send: fix compilation-error on Windows\n>>  - imap-send: use run-command API for tunneling\n>>  - imap-send: use separate read and write fds\n>\n> Don't forget about the MSVC patch ontop of this series:\n> Message-ID: <18cd41840910031300i32c74b15t74eb9eee23ff8469@mail.gmail.com>\n> Subject: [PATCH] MSVC: Enable OpenSSL, and translate -lcrypto\n\nI will include it in the next round I send out (unless someone objects)\n\n-- \nErik \"kusma\" Faye-Lund\nkusmabite@gmail.com\n(+47) 986 59 656\n"},{"id":"124415","messageId":"m3iqepgxcc.fsf@localhost.localdomain","threadId":"21154","inReplyTo":"7viqeqjsx6.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-10-09T01:38:48Z","receivedAt":"2009-10-09T01:38:48Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> --------------------------------------------------\n> [New Topics]\n\n> * jn/gitweb-patch (2009-09-30) 1 commit\n>  - gitweb: Do not show 'patch' link in 'commit' view for merges\n> \n> jk: After some comments with Jakub, I think the code is right but he\n> promised a re-roll with more in the commit message.\n\nNot only better commit message, but a more complete patch as well.\n \n> * mr/gitweb-snapshot (2009-09-26) 2 commits\n>  - gitweb: append short hash ids to snapshot files\n>  - gitweb: check given hash before trying to create snapshot\n> \n> jk: He posted a v5 of his series. I didn't look at it closely, but Jakub\n> ack'd it.\n\nActually I acked first patch in series (the \"check hash\" one), but the\nsecond needs review, and I think corrections.  First there is matter\nof tests and matter of not calling git_get_short_hash if it would not\nbe used (what was mentioned in my review).  But what is more important\nthat now that gitweb doesn't use full SHA-1 unconditionally, we have\nto deal with stripping prefix from refs/tags/v1.6.3-rc3 and\nrefs/heads/master, and with hierarchical branch names such as\n'mr/gitweb-snapshot'.  I'll post improved review soon.\n\nIn short: first patch is a go, second needs more work.\n\n> * jc/pretty-lf (2009-10-04) 1 commit\n>  - Pretty-format: %[+-]x to tweak inter-item newlines\n> \n> I am not happy with this one yet.  I am contemplating to introduce a new\n> syntax \"%[magic(param)<anything>%]\" to generalize expressions of this and\n> line wrapping features in an extensible way.\n> \n> * js/log-rewrap (2008-11-10) 3 commits\n>  . Add \"%w\" to pretty formats, which rewraps the commit message\n>  - Add strbuf_add_wrapped_text() to utf8.[ch]\n>  - print_wrapped_text(): allow hard newlines\n> \n> ... and the first two from this series will be useful to implement an\n> example magic \"wrap\", e.g. \"%{wrap(i,j,w)%s%+b%]\".\n\nSo... it is magic %[...%] or %{...} or %{...%}?\n\nBTW we can take rpm's queryformat as an example (or counterexample).\nAlso perhaps we can reuse minilanguage of git-for-each-ref format,\ni.e. %(field:modifier).\n  \n> --------------------------------------------------\n> [Cooking]\n\n> * jn/gitweb-show-size (2009-09-07) 1 commit\n>  - gitweb: Add 'show-sizes' feature to show blob sizes in tree view\n\nWhat this one requires (beside better name for a feature)?\n\n> * jn/gitweb-blame (2009-09-01) 5 commits\n>  - gitweb: Minify gitweb.js if JSMIN is defined\n>  - gitweb: Create links leading to 'blame_incremental' using JavaScript\n>   (merged to 'next' on 2009-09-07 at 3622199)\n>  + gitweb: Colorize 'blame_incremental' view during processing\n>  + gitweb: Incremental blame (using JavaScript)\n>  + gitweb: Add optional \"time to generate page\" info in footer\n> \n> Ajax-y blame.\n\nI reordered patches so JSMIN one is first (as it is less\ncontroversial), but the 'create blame_incremental links' one needs\nmore work.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"124426","messageId":"7vk4z56p59.fsf@alter.siamese.dyndns.org","threadId":"21154","inReplyTo":"m3iqepgxcc.fsf@localhost.localdomain","subject":"Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-09T06:46:10Z","receivedAt":"2009-10-09T06:46:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> --------------------------------------------------\n>> [New Topics]\n>\n>> * jn/gitweb-patch (2009-09-30) 1 commit\n>>  - gitweb: Do not show 'patch' link in 'commit' view for merges\n>> \n>> jk: After some comments with Jakub, I think the code is right but he\n>> promised a re-roll with more in the commit message.\n>\n> Not only better commit message, but a more complete patch as well.\n\nOk; I'll wait.\n\n>> * mr/gitweb-snapshot (2009-09-26) 2 commits\n>>  - gitweb: append short hash ids to snapshot files\n>>  - gitweb: check given hash before trying to create snapshot\n>> \n>> jk: He posted a v5 of his series. I didn't look at it closely, but Jakub\n>> ack'd it.\n> ...\n> In short: first patch is a go, second needs more work.\n\nOk; I'll merge fdb0c36 (gitweb: check given hash before trying to create\nsnapshot, 2009-09-26) to 'next'.\n\n>> * jc/pretty-lf (2009-10-04) 1 commit\n>>  - Pretty-format: %[+-]x to tweak inter-item newlines\n>> \n>> I am not happy with this one yet.  I am contemplating to introduce a new\n>> syntax \"%[magic(param)<anything>%]\" to generalize expressions of this and\n>> line wrapping features in an extensible way.\n>> ...\n> So... it is magic %[...%] or %{...} or %{...%}?\n\nThe escape does not matter. %() is fine, too.  It is non-essential for the\npurpose of the upcoming release so I have backburnered coming up with and\nthinking the details through.\n\n>> --------------------------------------------------\n>> [Cooking]\n>\n>> * jn/gitweb-show-size (2009-09-07) 1 commit\n>>  - gitweb: Add 'show-sizes' feature to show blob sizes in tree view\n>\n> What this one requires (beside better name for a feature)?\n\nName before 'next', and then the usual cooking, I guess.\n\n>> * jn/gitweb-blame (2009-09-01) 5 commits\n>> ...\n>> Ajax-y blame.\n>\n> I reordered patches so JSMIN one is first (as it is less\n> controversial), but the 'create blame_incremental links' one needs\n> more work.\n\nOk; I'll wait.\n\nThanks.\n"},{"id":"124427","messageId":"7v7hv56p3m.fsf@alter.siamese.dyndns.org","threadId":"21154","inReplyTo":"40aa078e0910081115q1bf924e8s22f3ee11dbe7c8b7@mail.gmail.com","subject":"Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-09T06:47:09Z","receivedAt":"2009-10-09T06:47:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Erik Faye-Lund <kusmabite@googlemail.com> writes:\n\n> On Thu, Oct 8, 2009 at 8:58 AM, Marius Storm-Olsen <mstormo@gmail.com> wrote:\n>> Junio C Hamano said the following on 08.10.2009 08:33:\n>>>\n>>> * ef/msys-imap (2009-10-03) 7 commits\n>> ...\n>> Don't forget about the MSVC patch ontop of this series:\n>> Message-ID: <18cd41840910031300i32c74b15t74eb9eee23ff8469@mail.gmail.com>\n>> Subject: [PATCH] MSVC: Enable OpenSSL, and translate -lcrypto\n>\n> I will include it in the next round I send out (unless someone objects)\n\nThanks.\n"},{"id":"124601","messageId":"e48c5e540910110440k33e3d0dcp6d8c1480b5848366@mail.gmail.com","threadId":"21154","inReplyTo":"fabb9a1e0910081058m59527600o392a6b438b18512e@mail.gmail.com","subject":"Re: [Vcs-fast-import-devs] What's cooking in git.git (Oct 2009, #01; Wed, 07)","fromName":"Matt McClure","fromEmail":"mlm@aya.yale.edu","sentAt":"2009-10-11T11:40:27Z","receivedAt":"2009-10-11T11:40:27Z","isPatch":false,"sender":{"key":"mlm@aya.yale.edu","avatar":"https://gravatar.com/avatar/1f1c0a8463848f10e33560e11dc081fa290e3d7fbd4273fec0a11e1fc6cf2516?d=mp&s=160"},"body":"On Thu, Oct 8, 2009 at 1:58 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:\n> On Thu, Oct 8, 2009 at 19:39, Shawn O. Pearce <spearce@spearce.org> wrote:\n>> Other options that are clearly git should be declared as:\n>>\n>>  option git max-pack-size=2048\n>>\n>> with the meaning of option being declared something like:\n>>\n>>  If the parsing VCS name appears as the first argument, the parsing\n>>  VCS must recognize and support the supplied option, and if not\n>>  recognized or not supported must abort parsing altogether.\n>>\n>>  If the parsing VCS name is not the first argument, it must entirely\n>>  ignore the option command and not try to process its contents.\n>\n> I think it makes to ignore options that are not for our vcs, as long\n> as options that change import behavior (such as marks, date-format)\n> are combined with, say, 'feature tool=git'. This way we can be sure\n> that when outputting out a vcs specific stream, it is only parsed by\n> that vcs.\n\nI prefer option-scope VCS specifiers over stream-scope specifiers.\nThe latter would artificially reduce interoperability between VCSs.\nWho is the fast-output developer to say that only one fast-import tool\nshould use his stream?\n\n-- \nMatt\nhttp://www.google.com/profiles/matthewlmcclure\n"},{"id":"124602","messageId":"fabb9a1e0910110458x430dd67co330ba5f5bd550f9c@mail.gmail.com","threadId":"21154","inReplyTo":"e48c5e540910110440k33e3d0dcp6d8c1480b5848366@mail.gmail.com","subject":"Re: [Vcs-fast-import-devs] What's cooking in git.git (Oct 2009, #01; Wed, 07)","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-10-11T11:58:59Z","receivedAt":"2009-10-11T11:58:59Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Sun, Oct 11, 2009 at 13:40, Matt McClure <mlm@aya.yale.edu> wrote:\n> Who is the fast-output developer to say that only one fast-import tool\n> should use his stream?\n\nHe knows that a foreign tool that does not heed his 'option git\nstream-changing-option' will mis-parse the stream. For example the\nBazaar people were talking about adding some Bazaar-specific options\nso facilitate bzr-bzr traffic, it would be impossible for a non-bzr\nimporter to properly understand the stream if they were to ignore the\nbzr-specific options. So either options should only affect things that\ndo not change semantics (such as perhaps whether or not to be quiet,\nwhether to try and limit memory usage, etc), or it should be possible\nto indicate that an option is changes semantic and cannot be ignored.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"126179","messageId":"fabb9a1e0910281508m3e9bb8a6g7b39abc29fceae78@mail.gmail.com","threadId":"21154","inReplyTo":"fabb9a1e0910081058m59527600o392a6b438b18512e@mail.gmail.com","subject":"Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-10-28T22:08:11Z","receivedAt":"2009-10-28T22:08:11Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Thu, Oct 8, 2009 at 10:58, Sverre Rabbelier <srabbelier@gmail.com> wrote:\n> I think it makes to ignore options that are not for our vcs, as long\n> as options that change import behavior (such as marks, date-format)\n> are combined with, say, 'feature tool=git'. This way we can be sure\n> that when outputting out a vcs specific stream, it is only parsed by\n> that vcs.\n>\n> Note: yes, I know that marks and date-format are features now, but\n> there's really no other suitable example that I could think of).\n>\n> vcs fast import devs please ack this idea (and perhaps suggest\n> something other than \"feature tool=git\" if preferable) so that I can\n> reroll my gfi-options series :).\n\nShawn, what do you want to do with this, it seems the vcs devs are not\nvery interested in this feature, should I implement it as described\nabove? That is:\n  * If you use any option that is stream-changing you should include\n\"feature tool=git\" in your stream\n  * import-marks and export-marks are made into features\n  * \"option vcs\" is ignored if vcs is a different vcs\n  * \"option vcs\" must be recognised if vcs is this vcs\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"126190","messageId":"4AE8D19B.6030403@canonical.com","threadId":"21154","inReplyTo":"fabb9a1e0910281508m3e9bb8a6g7b39abc29fceae78@mail.gmail.com","subject":"Re: [Vcs-fast-import-devs] What's cooking in git.git (Oct 2009, #01; Wed, 07)","fromName":"Ian Clatworthy","fromEmail":"ian.clatworthy@canonical.com","sentAt":"2009-10-28T23:19:55Z","receivedAt":"2009-10-28T23:19:55Z","isPatch":false,"sender":{"key":"ian.clatworthy@canonical.com","avatar":null},"body":"Sverre Rabbelier wrote:\n\n> Shawn, what do you want to do with this, it seems the vcs devs are not\n> very interested in this feature, should I implement it as described\n> above?\n\nSverre,\n\nI'll try to take a look today. Sorry for the lack of response so far -\nother stuff has been swamping my time and this hasn't reached the top of\nmy TODO list unfortunately.\n\nIan C.\n"},{"id":"126260","messageId":"alpine.DEB.1.00.0910291151330.3687@felix-maschine","threadId":"21154","inReplyTo":"fabb9a1e0910281508m3e9bb8a6g7b39abc29fceae78@mail.gmail.com","subject":"Re: What's cooking in git.git (Oct 2009, #01; Wed, 07)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-10-29T10:54:35Z","receivedAt":"2009-10-29T10:54:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 28 Oct 2009, Sverre Rabbelier wrote:\n\n> On Thu, Oct 8, 2009 at 10:58, Sverre Rabbelier <srabbelier@gmail.com> wrote:\n> > I think it makes to ignore options that are not for our vcs, as long \n> > as options that change import behavior (such as marks, date-format) \n> > are combined with, say, 'feature tool=git'. This way we can be sure \n> > that when outputting out a vcs specific stream, it is only parsed by \n> > that vcs.\n> >\n> > Note: yes, I know that marks and date-format are features now, but\n> > there's really no other suitable example that I could think of).\n> >\n> > vcs fast import devs please ack this idea (and perhaps suggest\n> > something other than \"feature tool=git\" if preferable) so that I can\n> > reroll my gfi-options series :).\n> \n> Shawn, what do you want to do with this, it seems the vcs devs are not\n> very interested in this feature, should I implement it as described\n> above? That is:\n>   * If you use any option that is stream-changing you should include\n>     \"feature tool=git\" in your stream\n>   * import-marks and export-marks are made into features\n>   * \"option vcs\" is ignored if vcs is a different vcs\n>   * \"option vcs\" must be recognised if vcs is this vcs\n\nIt would be quite nice if this issue moved forward for a change.\n\nAs a consequence of it moving forward, I could nudge Sverre into \ncontinuing with his git-remote-hg work that will allow me to work \ntransparently on a Mercurial repository using Git.\n\nTransparent as in \"no hassles\".\n\nIt also will serve nicely as a perfect excuse to fix some design mistakes \nin the foreign vcs stuff.\n\nCiao,\nDscho\n"},{"id":"126351","messageId":"4AEA626D.8060804@canonical.com","threadId":"21154","inReplyTo":"fabb9a1e0910081058m59527600o392a6b438b18512e@mail.gmail.com","subject":"Re: [Vcs-fast-import-devs] What's cooking in git.git (Oct 2009, #01; Wed, 07)","fromName":"Ian Clatworthy","fromEmail":"ian.clatworthy@canonical.com","sentAt":"2009-10-30T03:50:05Z","receivedAt":"2009-10-30T03:50:05Z","isPatch":false,"sender":{"key":"ian.clatworthy@canonical.com","avatar":null},"body":"Sverre Rabbelier wrote:\n> Heya,\n> \n> [edited Shawn's message somewhat to be more relevant to vcs-fast-import-dev]\n\nThanks Sverre. Before I start, sorry for taking so long to reply to this.\n\n> On Thu, Oct 8, 2009 at 19:39, Shawn O. Pearce <spearce@spearce.org> wrote:\n>> IIRC my problem with options was we weren't enforcing them, and yet\n>> they were necessary for a successful import, e.g. import-marks or\n>> export-marks.  A minor error could cause a successful looking import\n>> that is wrong due to the marks being messed up, or not saved out.\n>>\n>> So I was leaning towards making these features, but then they\n>> aren't necessarily compatible with the other fast-import tools.\n\nMy strong preference is for:\n\n* feature = anything impacting semantics\n* option = tool-specific with no impact on semantics permitted.\n\nBoth features and options ought to OS independent (where possible).\n\n>> I think we want to declare features for import-marks and export-marks:\n>>\n>>  feature import-marks=in.marks\n>>  feature export-marks=out.marks\n>>\n>> and define these as paths to local files which store a VCS specific\n>> formatted mapping of fast-import mark numbers to VCS labels.\n\n+1 to making these features and to tightening up the semantics so we can\nreliably use them across tools. Explicitly specifying the local path\nnames worries me though. Consider someone using fastimport tools to\nmaintain multiple mirrors in different tools:\n\n1. Step 1 is fast-export from tool A\n2. Step 2 is fast-import into tool B\n3. Step 3 is fast-import into tool C\n\nWhat should the stream look like then? Does it need to change if we want\nan additional mirror in tool D? (Note that the mark files will need to\nbe reused to transfer changes back to the master.)\n\n>> Other options that are clearly git should be declared as:\n>>\n>>  option git max-pack-size=2048\n>>\n>> with the meaning of option being declared something like:\n>>\n>>  If the parsing VCS name appears as the first argument, the parsing\n>>  VCS must recognize and support the supplied option, and if not\n>>  recognized or not supported must abort parsing altogether.\n>>\n>>  If the parsing VCS name is not the first argument, it must entirely\n>>  ignore the option command and not try to process its contents.\n\n+1. By forcing tools to know about options specific to them, we avoid a\nrange of bugs processing newer streams with older tools.\n\n> I think it makes to ignore options that are not for our vcs, as long\n> as options that change import behavior (such as marks, date-format)\n> are combined with, say, 'feature tool=git'. This way we can be sure\n> that when outputting out a vcs specific stream, it is only parsed by\n> that vcs.\n\nI don't think options should be permitted to change import behavior. In\nother words, we should actively discourage vcs-specific streams. Any VCS\nusing features has a (moral) responsibility IMO to at least define those\npublicly. Here's a poor start (EBNF syntax would be far better than just\ntext) on the Bazaar side:\nhttp://doc.bazaar-vcs.org/migration/en/data-migration/fast-export.html#interoperability.\n\nMaybe we need a central wiki page (say) where these can be registered?\nI'd offer to setup a \"fastimport\" web site in a Bazaar branch and track\nfeature specification bugs in Launchpad but maybe a wiki page would be a\nlittle more neutral ground. :-) :-)\n\nIan C.\n"},{"id":"126381","messageId":"fabb9a1e0910300541w40d17242rbf0683654d97457f@mail.gmail.com","threadId":"21154","inReplyTo":"4AEA626D.8060804@canonical.com","subject":"Re: [Vcs-fast-import-devs] What's cooking in git.git (Oct 2009, #01; Wed, 07)","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-10-30T12:41:36Z","receivedAt":"2009-10-30T12:41:36Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Thu, Oct 29, 2009 at 20:50, Ian Clatworthy\n<ian.clatworthy@canonical.com> wrote:\n>> On Thu, Oct 8, 2009 at 19:39, Shawn O. Pearce <spearce@spearce.org> wrote:\n> Sverre Rabbelier wrote:\n>> [edited Shawn's message somewhat to be more relevant to vcs-fast-import-dev]\n>\n> Thanks Sverre. Before I start, sorry for taking so long to reply to this.\n\nThanks for the review :).\n\n> My strong preference is for:\n>\n> * feature = anything impacting semantics\n> * option = tool-specific with no impact on semantics permitted.\n>\n> Both features and options ought to OS independent (where possible).\n\nEven better, Shawn, if this LGTY I will reroll the series implementing this.\n\n>>> I think we want to declare features for import-marks and export-marks\n>>> and define these as paths to local files which store a VCS specific\n>>> formatted mapping of fast-import mark numbers to VCS labels.\n>\n> Explicitly specifying the local path names worries me though. Consider someone\n> using fastimport tools to maintain multiple mirrors in different tools.\n> What should the stream look like then? Does it need to change if we want\n> an additional mirror.\n\nI think the stream should not have to change, which works if you\ndefine the files to be local to the repo being exported to.  That is,\nin git the line \"feature export-marks=out.marks\" would result in a\nmarks file located in \"/path/to/repo/.git/fast-import/out.marks\". Or\nis that not what you mean?\n\n> +1. By forcing tools to know about options specific to them, we avoid a\n> range of bugs processing newer streams with older tools.\n\nIt is not possible to change the semantics using options though, what\nkind of bugs could arise this way?\n\n> I don't think options should be permitted to change import behavior. In\n> other words, we should actively discourage vcs-specific streams\n\nSounds fair, I reckon that a wiki in addition to the\nvcs-fast-import-devs list would not hurt :).\n\n-- \nCheers,\n\nSverre Rabbelier\n"}]}