{"thread":{"id":"28212","subject":"What's cooking in git.git (Aug 2011, #07; Wed, 24)","startedAt":"2011-08-25T00:09:09Z","lastAt":"2011-09-15T10:47:22Z","messageCount":13,"participants":["Junio C Hamano","Michael Haggerty","Jeff King","Heiko Voigt","Ted Zlatanov","John Szakmeister"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"174203","messageId":"7vk4a2mjx6.fsf@alter.siamese.dyndns.org","threadId":"28212","inReplyTo":null,"subject":"What's cooking in git.git (Aug 2011, #07; Wed, 24)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-25T00:09:09Z","receivedAt":"2011-08-25T00:09:09Z","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'.\n\nI've sifted topics to the ones meant for 1.7.7 and the others that I'd\nprefer to cook a bit longer in \"next\" during the upcoming feature freeze,\nwhich should happen by the end of the week.\n\nPlease help us make the upcoming release as solid as we could. Thanks.\n\n--------------------------------------------------\n[Stalled]\n\n* jk/add-i-hunk-filter (2011-07-27) 5 commits\n  (merged to 'next' on 2011-08-11 at 8ff9a56)\n + add--interactive: add option to autosplit hunks\n + add--interactive: allow negatation of hunk filters\n + add--interactive: allow hunk filtering on command line\n + add--interactive: factor out regex error handling\n + add--interactive: refactor patch mode argument processing\n\nNeeds documentation updates.\n\n* jh/receive-count-limit (2011-05-23) 10 commits\n - receive-pack: Allow server to refuse pushes with too many objects\n - pack-objects: Estimate pack size; abort early if pack size limit is exceeded\n - send-pack/receive-pack: Allow server to refuse pushing too large packs\n - pack-objects: Allow --max-pack-size to be used together with --stdout\n - send-pack/receive-pack: Allow server to refuse pushes with too many commits\n - pack-objects: Teach new option --max-commit-count, limiting #commits in pack\n - receive-pack: Prepare for addition of the new 'limit-*' family of capabilities\n - Tighten rules for matching server capabilities in server_supports()\n - send-pack: Attempt to retrieve remote status even if pack-objects fails\n - Update technical docs to reflect side-band-64k capability in receive-pack\n\nWould need another round to separate per-pack and per-session limits.\n\n* jm/mergetool-pathspec (2011-06-22) 2 commits\n - mergetool: Don't assume paths are unmerged\n - mergetool: Add tests for filename with whitespace\n\nI think this is a good idea, but it probably needs a re-roll.\nCf. $gmane/176254, 176255, 166256\n\n* jk/generation-numbers (2011-07-14) 7 commits\n - limit \"contains\" traversals based on commit generation\n - check commit generation cache validity against grafts\n - pretty: support %G to show the generation number of a commit\n - commit: add commit_generation function\n - add metadata-cache infrastructure\n - decorate: allow storing values instead of pointers\n - Merge branch 'jk/tag-contains-ab' (early part) into HEAD\n\nThe initial \"tag --contains\" de-pessimization without need for generation\nnumbers is already in; backburnered.\n\n* sr/transport-helper-fix-rfc (2011-07-19) 2 commits\n - t5800: point out that deleting branches does not work\n - t5800: document inability to push new branch with old content\n\n* po/cygwin-backslash (2011-08-05) 2 commits\n - On Cygwin support both UNIX and DOS style path-names\n - git-compat-util: add generic find_last_dir_sep that respects is_dir_sep\n\nI think a further refactoring (no, not my suggestion) was offered?\n\n--------------------------------------------------\n[Cooking]\n\n* jc/merge-reword (2011-05-25) 1 commit\n  (merged to 'next' on 2011-08-24 at aa5cf7b)\n + merge: reword the final message\n\nWill merge to \"master\".\n\n* nk/branch-v-abbrev (2011-07-01) 1 commit\n  (merged to 'next' on 2011-08-24 at e9152cf)\n + branch -v: honor core.abbrev\n\nWill merge to \"master\".\n\n* jk/pager-with-external-command (2011-08-19) 1 commit\n  (merged to 'next' on 2011-08-24 at 083f5da)\n + support pager.* for external commands\n (this branch is used by jk/pager-with-alias and jk/pager-with-alias; uses jk/color-and-pager.)\n\nUp to this part (but not \"alias\") the topic looked unconditionally a good\nthing to do.\n\nWill aim to merge to \"master\" by -rc1.\n\n* fk/use-kwset-pickaxe-grep-f (2011-08-20) 5 commits\n  (merged to 'next' on 2011-08-23 at 93ba509)\n + Use kwset in grep\n + Use kwset in pickaxe\n + Adapt the kwset code to Git\n + Add string search routines from GNU grep\n + Add obstack.[ch] from EGLIBC 2.10\n\nWill aim to merge to \"master\" by -rc1.\n\n* jc/maint-autofix-tag-in-head (2011-08-19) 1 commit\n  (merged to 'next' on 2011-08-23 at 18cee02)\n + commit: reduce use of redundant global variables\n\nWill merge to \"master\".\n\n* bw/doc-repo-layout (2011-08-23) 2 commits\n  (merged to 'next' on 2011-08-24 at 605c730)\n + Mark http-fetch without -a as deprecated\n + Documentation: Grammar correction, wording fixes and cleanup\n\nWill merge to \"master\".\n\n* ci/forbid-unwanted-current-branch-update (2011-08-22) 2 commits\n  (merged to 'next' on 2011-08-24 at 1e93b67)\n + Show interpreted branch name in error messages\n + Prevent force-updating of the current branch\n\nWill aim to merge to \"master\" by -rc1.\n\n* di/fast-import-blob-tweak (2011-08-22) 2 commits\n  (merged to 'next' on 2011-08-24 at 52eef2a)\n + fast-import: treat cat-blob as a delta base hint for next blob\n + fast-import: count and report # of calls to diff_delta in stats\n\nWill aim to merge to \"master\" by -rc1.\n\n* di/fast-import-tagging (2011-08-23) 2 commits\n  (merged to 'next' on 2011-08-24 at 67e0937)\n + fast-import: allow to tag newly created objects\n + fast-import: add tests for tagging blobs\n\nWill aim to merge to \"master\" by -rc1.\n\n* di/fast-import-deltified-tree (2011-08-14) 2 commits\n  (merged to 'next' on 2011-08-23 at ee30265)\n + fast-import: prevent producing bad delta\n + fast-import: add a test for tree delta base corruption\n\nWill aim to merge to \"master\" by -rc1.\n\n* di/fast-import-ident (2011-08-11) 5 commits\n  (merged to 'next' on 2011-08-23 at 9b86391)\n + fsck: improve committer/author check\n + fsck: add a few committer name tests\n + fast-import: check committer name more strictly\n + fast-import: don't fail on omitted committer name\n + fast-import: add input format tests\n\nWill aim to merge to \"master\" by -rc1.\n\n* di/fast-import-doc (2011-08-17) 1 commit\n  (merged to 'next' on 2011-08-23 at dab4088)\n + doc/fast-import: document feature import-marks-if-exists\n\nWill merge to \"master\".\n\n* jc/combine-diff-callback (2011-08-20) 1 commit\n  (merged to 'next' on 2011-08-24 at 9f9b42d)\n + combine-diff: support format_callback\n (this branch is used by fg/submodule-ff-check-before-push.)\n\nWill merge to \"master\".\n\n* jc/maint-clone-alternates (2011-08-23) 2 commits\n  (merged to 'next' on 2011-08-23 at 7280deb)\n + clone: clone from a repository with relative alternates\n + clone: allow more than one --reference\n\nWill aim to merge to \"master\" by -rc1.\n\n* nd/maint-clone-gitdir (2011-08-22) 2 commits\n  (merged to 'next' on 2011-08-24 at cbf052b)\n + clone: allow to clone from .git file\n + read_gitfile_gently(): rename misnamed function to read_gitfile()\n\nWill aim to merge to \"master\" by -rc1.\n\n* jc/traverse-commit-list (2011-08-22) 3 commits\n  (merged to 'next' on 2011-08-24 at df50dd7)\n + revision.c: update show_object_with_name() without using malloc()\n + revision.c: add show_object_with_name() helper function\n + rev-list: fix finish_object() call\n\nNot urgent; will not be in 1.7.7.\n\n* rc/diff-cleanup-records (2011-08-17) 2 commits\n  (merged to 'next' on 2011-08-23 at b8414f5)\n + Merge branch 'rc/histogram-diff' into HEAD\n + xdiff/xprepare: improve O(n*m) performance in xdl_cleanup_records()\n\nWill aim to merge to \"master\" by -rc1.\n\n* fk/make-auto-header-dependencies (2011-08-18) 1 commit\n  (merged to 'next' on 2011-08-24 at 3da2c25)\n + Makefile: Use computed header dependencies if the compiler supports it\n\nNot urgent; will not be in 1.7.7.\n\n* jk/color-and-pager (2011-08-19) 10 commits\n  (merged to 'next' on 2011-08-23 at cbb9495)\n + want_color: automatically fallback to color.ui\n + diff: don't load color config in plumbing\n + config: refactor get_colorbool function\n + color: delay auto-color decision until point of use\n + git_config_colorbool: refactor stdout_is_tty handling\n + diff: refactor COLOR_DIFF from a flag into an int\n + setup_pager: set GIT_PAGER_IN_USE\n + t7006: use test_config helpers\n + test-lib: add helper functions for config\n + t7006: modernize calls to unset\n (this branch is used by jk/pager-with-alias and jk/pager-with-external-command.)\n\nWill aim to merge to \"master\" by -rc1.\n\n* jk/pager-with-alias (2011-08-19) 1 commit\n - support pager.* for aliases\n (this branch uses jk/color-and-pager, jk/pager-with-external-command and jk/pager-with-external-command.)\n\nPerhaps will drop.\n\n* nd/decorate-grafts (2011-08-19) 5 commits\n  (merged to 'next' on 2011-08-23 at 475d27e)\n + log: decorate \"replaced\" on to replaced commits\n + log: decorate grafted commits with \"grafted\"\n + Move write_shallow_commits to fetch-pack.c\n + Add for_each_commit_graft() to iterate all grafts\n + decoration: do not mis-decorate refs with same prefix\n\nWill aim to merge to \"master\" by -rc1.\n\n* va/p4-branch-import (2011-08-22) 4 commits\n  (merged to 'next' on 2011-08-24 at f67f8af)\n + git-p4: Add simple test case for branch import\n + git-p4: Allow branch definition with git config\n + git-p4: Allow filtering Perforce branches by user\n + git-p4: Correct branch base depot path detection\n (this branch uses va/p4-rename-copy.)\n\nWill merge to \"master\".\n\n* va/p4-rename-copy (2011-08-22) 5 commits\n  (merged to 'next' on 2011-08-24 at f1faa94)\n + git-p4: Process detectCopiesHarder with --bool\n + git-p4: Add test case for copy detection\n + git-p4: Add test case for rename detection\n + git-p4: Add description of rename/copy detection options\n + git-p4: Allow setting rename/copy detection threshold\n (this branch is used by va/p4-branch-import.)\n\nWill merge to \"master\".\n\n* da/difftool-mergtool-refactor (2011-08-19) 4 commits\n  (merged to 'next' on 2011-08-23 at a1cc3be)\n + mergetools/meld: Use '--output' when available\n + mergetool--lib: Refactor tools into separate files\n + mergetool--lib: Make style consistent with git\n + difftool--helper: Make style consistent with git\n\nWill merge to \"master\".\n\n* mg/branch-set-upstream-previous (2011-08-19) 1 commit\n  (merged to 'next' on 2011-08-23 at acef0b6)\n + branch.c: use the parsed branch name\n\nWill merge to \"master\".\n\n* di/parse-options-split (2011-08-11) 2 commits\n  (merged to 'next' on 2011-08-23 at 6cd667f)\n + Reduce parse-options.o dependencies\n + parse-options: export opterr, optbug\n\nWill merge to \"master\".\n\n* mh/attr (2011-08-14) 7 commits\n  (merged to 'next' on 2011-08-23 at 22faa6e)\n + Unroll the loop over passes\n + Change while loop into for loop\n + Determine the start of the states outside of the pass loop\n + Change parse_attr() to take a pointer to struct attr_state\n + Increment num_attr in parse_attr_line(), not parse_attr()\n + Document struct match_attr\n + Add a file comment\n\nWill aim to merge to \"master\" by -rc1.\n\n* mh/iterate-refs (2011-08-14) 6 commits\n - Retain caches of submodule refs\n - Store the submodule name in struct cached_refs\n - Allocate cached_refs objects dynamically\n - Change the signature of read_packed_refs()\n - Access reference caches only through new function get_cached_refs()\n - Extract a function clear_cached_refs()\n\nI did not see anything fundamentally wrong with this series, but it was\nunclear what the benefit of these changes are.  If the series were to read\nparts of the ref hierarchy (like refs/heads/) lazily, the story would\nhave been different, though.\n\nNot urgent; will not be in 1.7.7.\n\n* jn/plug-empty-tree-leak (2011-08-16) 2 commits\n  (merged to 'next' on 2011-08-23 at aee2184)\n + merge-recursive: take advantage of hardcoded empty tree\n + revert: plug memory leak in \"cherry-pick root commit\" codepath\n\nWill merge to \"master\".\n\n* ac/describe-dirty-refresh (2011-08-11) 1 commit\n  (merged to 'next' on 2011-08-23 at b873611)\n + describe: Refresh the index when run with --dirty\n\nWill merge to \"master\".\n\n* en/merge-recursive-2 (2011-08-14) 57 commits\n  (merged to 'next' on 2011-08-23 at ba6ad0d)\n + merge-recursive: Don't re-sort a list whose order we depend upon\n + merge-recursive: Fix virtual merge base for rename/rename(1to2)/add-dest\n + t6036: criss-cross + rename/rename(1to2)/add-dest + simple modify\n + merge-recursive: Avoid unnecessary file rewrites\n + t6022: Additional tests checking for unnecessary updates of files\n + merge-recursive: Fix spurious 'refusing to lose untracked file...' messages\n + t6022: Add testcase for spurious \"refusing to lose untracked\" messages\n + t3030: fix accidental success in symlink rename\n + merge-recursive: Fix working copy handling for rename/rename/add/add\n + merge-recursive: add handling for rename/rename/add-dest/add-dest\n + merge-recursive: Have conflict_rename_delete reuse modify/delete code\n + merge-recursive: Make modify/delete handling code reusable\n + merge-recursive: Consider modifications in rename/rename(2to1) conflicts\n + merge-recursive: Create function for merging with branchname:file markers\n + merge-recursive: Record more data needed for merging with dual renames\n + merge-recursive: Defer rename/rename(2to1) handling until process_entry\n + merge-recursive: Small cleanups for conflict_rename_rename_1to2\n + merge-recursive: Fix rename/rename(1to2) resolution for virtual merge base\n + merge-recursive: Introduce a merge_file convenience function\n + merge-recursive: Fix modify/delete resolution in the recursive case\n + merge-recursive: When we detect we can skip an update, actually skip it\n + merge-recursive: Provide more info in conflict markers with file renames\n + merge-recursive: Cleanup and consolidation of rename_conflict_info\n + merge-recursive: Consolidate process_entry() and process_df_entry()\n + merge-recursive: Improve handling of rename target vs. directory addition\n + merge-recursive: Add comments about handling rename/add-source cases\n + merge-recursive: Make dead code for rename/rename(2to1) conflicts undead\n + merge-recursive: Fix deletion of untracked file in rename/delete conflicts\n + merge-recursive: Split update_stages_and_entry; only update stages at end\n + merge-recursive: Allow make_room_for_path() to remove D/F entries\n + string-list: Add API to remove an item from an unsorted list\n + merge-recursive: Split was_tracked() out of would_lose_untracked()\n + merge-recursive: Save D/F conflict filenames instead of unlinking them\n + merge-recursive: Fix code checking for D/F conflicts still being present\n + merge-recursive: Fix sorting order and directory change assumptions\n + merge-recursive: Fix recursive case with D/F conflict via add/add conflict\n + merge-recursive: Avoid working directory changes during recursive case\n + merge-recursive: Remember to free generated unique path names\n + merge-recursive: Consolidate different update_stages functions\n + merge-recursive: Mark some diff_filespec struct arguments const\n + merge-recursive: Correct a comment\n + merge-recursive: Make BUG message more legible by adding a newline\n + t6022: Add testcase for merging a renamed file with a simple change\n + t6022: New tests checking for unnecessary updates of files\n + t6022: Remove unnecessary untracked files to make test cleaner\n + t6036: criss-cross + rename/rename(1to2)/add-source + modify/modify\n + t6036: criss-cross w/ rename/rename(1to2)/modify+rename/rename(2to1)/modify\n + t6036: tests for criss-cross merges with various directory/file conflicts\n + t6036: criss-cross with weird content can fool git into clean merge\n + t6036: Add differently resolved modify/delete conflict in criss-cross test\n + t6042: Add failing testcases for rename/rename/add-{source,dest} conflicts\n + t6042: Ensure rename/rename conflicts leave index and workdir in sane state\n + t6042: Add tests for content issues with modify/rename/directory conflicts\n + t6042: Add a testcase where undetected rename causes silent file deletion\n + t6042: Add a pair of cases where undetected renames cause issues\n + t6042: Add failing testcase for rename/modify/add-source conflict\n + t6042: Add a testcase where git deletes an untracked file\n\nWill aim to merge to \"master\" by -rc1.\n\n* fg/submodule-ff-check-before-push (2011-08-20) 2 commits\n  (merged to 'next' on 2011-08-24 at 398e764)\n + push: teach --recurse-submodules the on-demand option\n + push: Don't push a repository with unpushed submodules\n (this branch uses jc/combine-diff-callback.)\n\nWill aim to merge to \"master\" by -rc1.\n\n* hv/submodule-update-none (2011-08-11) 2 commits\n  (merged to 'next' on 2011-08-24 at 5302fc1)\n + add update 'none' flag to disable update of submodule by default\n + submodule: move update configuration variable further up\n\nNot urgent; will not be in 1.7.7.\n\n* jc/lookup-object-hash (2011-08-11) 6 commits\n  (merged to 'next' on 2011-08-24 at 5825411)\n + object hash: replace linear probing with 4-way cuckoo hashing\n + object hash: we know the table size is a power of two\n + object hash: next_size() helper for readability\n + pack-objects --count-only\n + object.c: remove duplicated code for object hashing\n + object.c: code movement for readability\n\nI do not think there is anything fundamentally wrong with this series, but\nthe risk of breakage far outweighs observed performance gain in one\nparticular workload. Will keep it in 'next' at least for one cycle.\n\nNot urgent; will not be in 1.7.7.\n\n* js/i18n-scripts (2011-08-08) 5 commits\n  (merged to 'next' on 2011-08-23 at a1b5529)\n + submodule: take advantage of gettextln and eval_gettextln.\n + stash: take advantage of eval_gettextln\n + pull: take advantage of eval_gettextln\n + git-am: take advantage of gettextln and eval_gettextln.\n + gettext: add gettextln, eval_gettextln to encode common idiom\n\nWill merge to \"master\".\n\n* fg/submodule-git-file-git-dir (2011-08-22) 2 commits\n  (merged to 'next' on 2011-08-23 at 762194e)\n + Move git-dir for submodules\n + rev-parse: add option --resolve-git-dir <path>\n\nI do not think there is anything fundamentally wrong with this series, but\nthe risk of breakage outweighs any benefit for having this new\nfeature. Will keep it in 'next' at least for one cycle.\n\nNot urgent; will not be in 1.7.7.\n\n* jk/http-auth-keyring (2011-08-03) 13 commits\n  (merged to 'next' on 2011-08-03 at b06e80e)\n + credentials: add \"getpass\" helper\n + credentials: add \"store\" helper\n + credentials: add \"cache\" helper\n + docs: end-user documentation for the credential subsystem\n + http: use hostname in credential description\n + allow the user to configure credential helpers\n + look for credentials in config before prompting\n + http: use credential API to get passwords\n + introduce credentials API\n + http: retry authentication failures for all http requests\n + remote-curl: don't retry auth failures with dumb protocol\n + improve httpd auth tests\n + url: decode buffers that are not NUL-terminated\n\nLooked mostly reasonable except for the limitation that it is not clear\nhow to deal with a site at which a user needs to use different passwords \nfor different repositories. Will keep it in \"next\" at least for one cycle,\nuntil we start hearing real-world success reports on the list.\n\nNot urgent; will not be in 1.7.7.\n\n* rr/revert-cherry-pick-continue (2011-08-08) 18 commits\n  (merged to 'next' on 2011-08-24 at 712c115)\n + revert: Propagate errors upwards from do_pick_commit\n + revert: Introduce --continue to continue the operation\n + revert: Don't implicitly stomp pending sequencer operation\n + revert: Remove sequencer state when no commits are pending\n + reset: Make reset remove the sequencer state\n + revert: Introduce --reset to remove sequencer state\n + revert: Make pick_commits functionally act on a commit list\n + revert: Save command-line options for continuing operation\n + revert: Save data for continuing after conflict resolution\n + revert: Don't create invalid replay_opts in parse_args\n + revert: Separate cmdline parsing from functional code\n + revert: Introduce struct to keep command-line options\n + revert: Eliminate global \"commit\" variable\n + revert: Rename no_replay to record_origin\n + revert: Don't check lone argument in get_encoding\n + revert: Simplify and inline add_message_to_msg\n + config: Introduce functions to write non-standard file\n + advice: Introduce error_resolve_conflict\n\nWill keep it in 'next' at least for one cycle.\nNot urgent; will not be in 1.7.7.\n"},{"id":"174212","messageId":"4E55FD36.1020107@alum.mit.edu","threadId":"28212","inReplyTo":"7vk4a2mjx6.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Aug 2011, #07; Wed, 24)","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2011-08-25T07:43:50Z","receivedAt":"2011-08-25T07:43:50Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 08/25/2011 02:09 AM, Junio C Hamano wrote:\n> * mh/iterate-refs (2011-08-14) 6 commits\n>  - Retain caches of submodule refs\n>  - Store the submodule name in struct cached_refs\n>  - Allocate cached_refs objects dynamically\n>  - Change the signature of read_packed_refs()\n>  - Access reference caches only through new function get_cached_refs()\n>  - Extract a function clear_cached_refs()\n> \n> I did not see anything fundamentally wrong with this series, but it was\n> unclear what the benefit of these changes are.  If the series were to read\n> parts of the ref hierarchy (like refs/heads/) lazily, the story would\n> have been different, though.\n\nI am still working on lazy reading and hierarchical storage of reference\ncaches.  It's OK with me if you defer merging the above patch series\nuntil I have made more progress on the more significant improvements.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"174257","messageId":"20110825202057.GB6165@sigill.intra.peff.net","threadId":"28212","inReplyTo":"7vk4a2mjx6.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Aug 2011, #07; Wed, 24)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-08-25T20:20:57Z","receivedAt":"2011-08-25T20:20:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 24, 2011 at 05:09:09PM -0700, Junio C Hamano wrote:\n\n> * jk/add-i-hunk-filter (2011-07-27) 5 commits\n>   (merged to 'next' on 2011-08-11 at 8ff9a56)\n>  + add--interactive: add option to autosplit hunks\n>  + add--interactive: allow negatation of hunk filters\n>  + add--interactive: allow hunk filtering on command line\n>  + add--interactive: factor out regex error handling\n>  + add--interactive: refactor patch mode argument processing\n> \n> Needs documentation updates.\n\nI think Duy already mentioned this, but you may want to update your\n\"what's cooking\" note: it needs not just doc updates, but code to\nactually pass the options along from real git commands that use\nadd--interactive, like add, checkout, reset, and stash.\n\n> * jk/generation-numbers (2011-07-14) 7 commits\n>  - limit \"contains\" traversals based on commit generation\n>  - check commit generation cache validity against grafts\n>  - pretty: support %G to show the generation number of a commit\n>  - commit: add commit_generation function\n>  - add metadata-cache infrastructure\n>  - decorate: allow storing values instead of pointers\n>  - Merge branch 'jk/tag-contains-ab' (early part) into HEAD\n> \n> The initial \"tag --contains\" de-pessimization without need for generation\n> numbers is already in; backburnered.\n\nSo...what next? I don't really like leaving the contains traversal\nas-is. It's often much faster than the original version (because we do\nat most one to-the-roots traversal), but in some cases is slower\n(because the depth-first search doesn't cut itself off sanely, so an\nunlucky traversal means going to the roots instead of ending early).\n\nHere are the options:\n\n  1. Stick with timestamps as a proxy for generation numbers.\n\n     a. Assume they're good enough. Possibly provide options to turn off\n        this optimization (here, and possibly in name-rev) if you want\n        to be more correct in the face of skew (at the cost of\n        efficiency).\n\n     b. Implement some kind of \"this commit timestamp is bogus\" cache.\n\n     c. Make it easier to use and share replace objects with correct\n        commit timestamps.\n\n  2. Add generation numbers to headers, and try to calculate them on the\n     fly as much as possible (i.e., Linus's approach).\n\n  3. Add separate storage of generation numbers.\n\n     a. As an on-the-fly cache (i.e., my patches).\n\n     b. Combined with packfiles somehow (more efficient, less flaky, but\n        may require a bump in index format version; alternatively, you\n        could have pack-*.generation, which is a sparsely populated list\n        of 32-bit ints, in the exact same order as the pack-*.idx file.\n        No backwards compatibility issues, but slightly less efficient).\n\nThoughts?\n\n> * jk/http-auth-keyring (2011-08-03) 13 commits\n>   (merged to 'next' on 2011-08-03 at b06e80e)\n>  + credentials: add \"getpass\" helper\n>  + credentials: add \"store\" helper\n>  + credentials: add \"cache\" helper\n>  + docs: end-user documentation for the credential subsystem\n>  + http: use hostname in credential description\n>  + allow the user to configure credential helpers\n>  + look for credentials in config before prompting\n>  + http: use credential API to get passwords\n>  + introduce credentials API\n>  + http: retry authentication failures for all http requests\n>  + remote-curl: don't retry auth failures with dumb protocol\n>  + improve httpd auth tests\n>  + url: decode buffers that are not NUL-terminated\n> \n> Looked mostly reasonable except for the limitation that it is not clear\n> how to deal with a site at which a user needs to use different passwords \n> for different repositories. Will keep it in \"next\" at least for one cycle,\n> until we start hearing real-world success reports on the list.\n> \n> Not urgent; will not be in 1.7.7.\n\nI'm OK with holding this off for another round. I'd really like to get\nmore feedback from third-party helper writers. OTOH, I think we have a\nlittle bit of a chicken-and-egg problem with testing. Most experienced\ngit users aren't that interested in this, because they are just using\nssh keys and ssh-agent, anyway. I wonder if we would do better to put it\nin a released version with a big \"warning: this is ridiculously\nexperimental and the interface to helpers is subject to change\" warning.\nAnd that puts something in the hands of the people it was meant to help,\nand can get the attention of people to write helpers. I dunno.\n\n-Peff\n"},{"id":"174274","messageId":"20110825215035.GB67523@book.hvoigt.net","threadId":"28212","inReplyTo":"7vk4a2mjx6.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Aug 2011, #07; Wed, 24)","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2011-08-25T21:50:35Z","receivedAt":"2011-08-25T21:50:35Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi Junio,\n\nOn Wed, Aug 24, 2011 at 05:09:09PM -0700, Junio C Hamano wrote:\n> * fg/submodule-ff-check-before-push (2011-08-20) 2 commits\n>   (merged to 'next' on 2011-08-24 at 398e764)\n>  + push: teach --recurse-submodules the on-demand option\n>  + push: Don't push a repository with unpushed submodules\n>  (this branch uses jc/combine-diff-callback.)\n> \n> Will aim to merge to \"master\" by -rc1.\n\nHave you seen my fixes to the tests of this here:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/179883\n\n?\n\nCheers Heiko\n"},{"id":"174279","messageId":"7vhb55i11i.fsf@alter.siamese.dyndns.org","threadId":"28212","inReplyTo":"20110825202057.GB6165@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Aug 2011, #07; Wed, 24)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-25T22:22:49Z","receivedAt":"2011-08-25T22:22:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Wed, Aug 24, 2011 at 05:09:09PM -0700, Junio C Hamano wrote:\n>\n>> * jk/add-i-hunk-filter (2011-07-27) 5 commits\n>>   (merged to 'next' on 2011-08-11 at 8ff9a56)\n>>  + add--interactive: add option to autosplit hunks\n>>  + add--interactive: allow negatation of hunk filters\n>>  + add--interactive: allow hunk filtering on command line\n>>  + add--interactive: factor out regex error handling\n>>  + add--interactive: refactor patch mode argument processing\n>> \n>> Needs documentation updates.\n>\n> I think Duy already mentioned this, but you may want to update your\n> \"what's cooking\" note: it needs not just doc updates, but code to\n> actually pass the options along from real git commands that use\n> add--interactive, like add, checkout, reset, and stash.\n\nThanks. Also tests are lacking, too. Although I do not necessarily see the\nlack of integration with anything but \"add\" a show-stopper (I consider\n\"-p\" to chekout, reset and stash are \"nice to have\"), you are correct that\n\"add -i\" and then choosing '[p]atch' gets very confused with\n\n    Patch update>> \n    Use of uninitialized value in split at /git/git-pu/libexec/git-core/git-add--interactive line 742, <STDIN> line 3.\n    Unknown option: --\n    usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]\n               [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]\n               [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]\n               [-c name=value] [--help]\n               <command> [<args>]\n    Unknown option: --color\n    usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]\n               [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]\n               [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]\n               [-c name=value] [--help]\n               <command> [<args>]\n\nSo it certainly seems not ready for the prime time.\n\n>> * jk/generation-numbers (2011-07-14) 7 commits\n>>  - limit \"contains\" traversals based on commit generation\n>>  - check commit generation cache validity against grafts\n>>  - pretty: support %G to show the generation number of a commit\n>>  - commit: add commit_generation function\n>>  - add metadata-cache infrastructure\n>>  - decorate: allow storing values instead of pointers\n>>  - Merge branch 'jk/tag-contains-ab' (early part) into HEAD\n>> \n>> The initial \"tag --contains\" de-pessimization without need for generation\n>> numbers is already in; backburnered.\n>\n> So...what next? I don't really like leaving the contains traversal\n> as-is.\n\nHmm, honestly speaking, I do not see much problem with it. My knee-jerk\nreaction is to go with 1.a and if we really want to do something 1.b\nperhaps but I suspect \"these are bogus\" cache wouldn't be so useful by\nitself and we may need a bit more information.\n\n>> * jk/http-auth-keyring (2011-08-03) 13 commits\n>>   (merged to 'next' on 2011-08-03 at b06e80e)\n>>  ...\n>> Not urgent; will not be in 1.7.7.\n>\n> I'm OK with holding this off for another round. I'd really like to get\n> more feedback from third-party helper writers. ...\n\nI actually do not think the lack of finer-than-host level granularity a\nproblem we need to solve before moving forward. IIRC, when accessing\n\"http://github.com/frotz\" and \"http://github.com/nitfol\", you would key\nthe authentication material with something like \"http://github.com\" (or\nwas it \"http:github.com\"? the details do not matter for the purpose of\nthis discussion). If another site that has multiple independent userbases\nwithin the same host, i.e. the user \"xyzzy\" at \"http://gotheb.com/frotz\"\nand the user \"xyzzy\" at \"http://gotheb.com/nitfol\" need to be treated as\nseparate identities, it obviously is not enoug to use \"gotheb.com\" as the\nlook-up key for the authentication material, but in such a case, the user\nknows an important piece of information that git can never figure out by\nitself, namely, where the authentication domain boundary lies.\n\nWe need to add \"auth-domain\" support, perhaps from the command line option\nand configuration, if we ever need to support such a site.\n\nWe can consider what you already have as the default case for a more\ngeneral \"we cut off at the hostname and take that as the auth-domain\nboundary unless told otherwise\". We may not have the way to \"tell\notherwise\" yet, but as long as we are reasonably confident that we know\nhow to extend the system in a backward compatible way, it is not a\nshow-stopper.\n\nThe primary reason why I wanted to hold this topic off was because of the\nfrequency of bug report we saw this round to topics _after_ they hit the\n\"master\" branch, indicating that not many people are testing \"next\" during\nthe development cycle as they used to in olden days.\n"},{"id":"174280","messageId":"7vd3fti0tk.fsf@alter.siamese.dyndns.org","threadId":"28212","inReplyTo":"20110825215035.GB67523@book.hvoigt.net","subject":"Re: What's cooking in git.git (Aug 2011, #07; Wed, 24)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-25T22:27:35Z","receivedAt":"2011-08-25T22:27:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Heiko Voigt <hvoigt@hvoigt.net> writes:\n\n> Hi Junio,\n>\n> On Wed, Aug 24, 2011 at 05:09:09PM -0700, Junio C Hamano wrote:\n>> * fg/submodule-ff-check-before-push (2011-08-20) 2 commits\n>>   (merged to 'next' on 2011-08-24 at 398e764)\n>>  + push: teach --recurse-submodules the on-demand option\n>>  + push: Don't push a repository with unpushed submodules\n>>  (this branch uses jc/combine-diff-callback.)\n>> \n>> Will aim to merge to \"master\" by -rc1.\n>\n> Have you seen my fixes to the tests of this here:\n>\n> http://article.gmane.org/gmane.comp.version-control.git/179883\n\nNot really. Please send it as a separate patch, as the new _failure\ncase by itself is worth a comment in the \"git log\" output.\n\nThanks.\n"},{"id":"174324","messageId":"87aaawnpra.fsf_-_@lifelogs.com","threadId":"28212","inReplyTo":"7vhb55i11i.fsf@alter.siamese.dyndns.org","subject":"credential helpers (was: What's cooking in git.git (Aug 2011, #07; Wed, 24))","fromName":"Ted Zlatanov","fromEmail":"tzz@lifelogs.com","sentAt":"2011-08-26T15:42:17Z","receivedAt":"2011-08-26T15:42:17Z","isPatch":false,"sender":{"key":"tzz@lifelogs.com","avatar":"https://avatars.githubusercontent.com/u/67764?v=4"},"body":"On Thu, 25 Aug 2011 15:22:49 -0700 Junio C Hamano <gitster@pobox.com> wrote: \n\nJCH> We need to add \"auth-domain\" support, perhaps from the command line option\nJCH> and configuration, if we ever need to support such a site.\n\nJCH> We can consider what you already have as the default case for a more\nJCH> general \"we cut off at the hostname and take that as the auth-domain\nJCH> boundary unless told otherwise\". We may not have the way to \"tell\nJCH> otherwise\" yet, but as long as we are reasonably confident that we know\nJCH> how to extend the system in a backward compatible way, it is not a\nJCH> show-stopper.\n\nHow about a config variable with regular expressions like\n\nauth-domain.xyz.url = https://(.*@)?github.com/.*\n\nso then accessing a remote with that URL with or without a username\nwould pass \"auth-domain=xyz\" to the helper?  If there's no defined\nauth-domain then it's not passed to the helper, so it has to just use\nthe host name (if there is an auth-domain the helper gets it PLUS the\nhostname, of course).  \n\nI specify the \"url\" sub-key so we can add more auth-domain selection\ncriteria or other functionality in the future.\n\nThat gives the user a way to do, for instance:\n\nauth-domain.internalcompany.url = https://.*.mycompany.com/.*\n\nI also wanted to suggest that the credential helper should be able to\nspecify a SSL private user key and the passphrase for it for HTTPS\nconnections to servers that require such keys.\n\nJCH> The primary reason why I wanted to hold this topic off was because of the\nJCH> frequency of bug report we saw this round to topics _after_ they hit the\nJCH> \"master\" branch, indicating that not many people are testing \"next\" during\nJCH> the development cycle as they used to in olden days.\n\nI'll be sure to test credential helpers next week.\n\nThank you\nTed\n"},{"id":"174594","messageId":"20110831022017.GA3340@sigill.intra.peff.net","threadId":"28212","inReplyTo":"7vhb55i11i.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Aug 2011, #07; Wed, 24)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-08-31T02:20:17Z","receivedAt":"2011-08-31T02:20:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 25, 2011 at 03:22:49PM -0700, Junio C Hamano wrote:\n\n> > On Wed, Aug 24, 2011 at 05:09:09PM -0700, Junio C Hamano wrote:\n> >\n> >> * jk/add-i-hunk-filter (2011-07-27) 5 commits\n> >>   (merged to 'next' on 2011-08-11 at 8ff9a56)\n> >>  + add--interactive: add option to autosplit hunks\n> >>  + add--interactive: allow negatation of hunk filters\n> >>  + add--interactive: allow hunk filtering on command line\n> >>  + add--interactive: factor out regex error handling\n> >>  + add--interactive: refactor patch mode argument processing\n> >> \n> >> Needs documentation updates.\n> >\n> > I think Duy already mentioned this, but you may want to update your\n> > \"what's cooking\" note: it needs not just doc updates, but code to\n> > actually pass the options along from real git commands that use\n> > add--interactive, like add, checkout, reset, and stash.\n> \n> Thanks. Also tests are lacking, too. Although I do not necessarily see the\n> lack of integration with anything but \"add\" a show-stopper (I consider\n> \"-p\" to chekout, reset and stash are \"nice to have\"), [...]\n\nIt is less ready than that. You cannot even use it from \"git add\" at\nthis point. It is _only_ the perl bits, as I was just providing them to\nDuy, so he could write the C bits. So the patches as they are are\nuseless.  Hence no tests, since you can't even trigger the code without\nartifically calling add--interactive directly with the new options.\n\nSo it probably makes sense to just drop them (or just leave them in pu)\nfor the next cycle until the other half materializes.\n\n> you are correct that \"add -i\" and then choosing '[p]atch' gets very\n> confused with\n\nHmm, that is a regression probably caused by my refactoring. Thanks for\npointing it out. I'll take a look.\n\n> >> The initial \"tag --contains\" de-pessimization without need for generation\n> >> numbers is already in; backburnered.\n> >\n> > So...what next? I don't really like leaving the contains traversal\n> > as-is.\n> \n> Hmm, honestly speaking, I do not see much problem with it. My knee-jerk\n> reaction is to go with 1.a and if we really want to do something 1.b\n> perhaps but I suspect \"these are bogus\" cache wouldn't be so useful by\n> itself and we may need a bit more information.\n\nOK. I'll clean up and submit a patch for that, but I'll wait for\npost-1.7.7.\n\n-Peff\n"},{"id":"174595","messageId":"20110831023801.GB3340@sigill.intra.peff.net","threadId":"28212","inReplyTo":"7vhb55i11i.fsf@alter.siamese.dyndns.org","subject":"git credential helper design [was: What's cooking in git.git (Aug 2011, #07; Wed, 24)]","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-08-31T02:38:01Z","receivedAt":"2011-08-31T02:38:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 25, 2011 at 03:22:49PM -0700, Junio C Hamano wrote:\n\n> > I'm OK with holding this off for another round. I'd really like to get\n> > more feedback from third-party helper writers. ...\n> \n> I actually do not think the lack of finer-than-host level granularity a\n> problem we need to solve before moving forward. IIRC, when accessing\n> \"http://github.com/frotz\" and \"http://github.com/nitfol\", you would key\n> the authentication material with something like \"http://github.com\" (or\n> was it \"http:github.com\"? the details do not matter for the purpose of\n> this discussion).\n\nIt's \"http:github.com\", which has always looked a bit ugly to me. I had\nhoped they would just be opaque blobs and nobody would need to look at\nthem. But when you get into things like setting the username via the\nconfig, then users see them, and they need to look sane. Making them\nlook more like a canonicalized URL is probably a good thing.\n\nAfter seeing the helper that Lukas posted recently on the list, I am\nwondering if they should include the username, too. I had left it\nseparate, because I wanted helpers to be able to index \"foo@example.com\"\nand \"example.com\" in the same slot. I.e., to realize that the latter\ncould use the same credentials cached for the former. But it also\ncomplicates the helpers; instead of doing:\n\n  credential = secure_storage_lookup(unique_token);\n  return credential /* could be NULL */\n\nthey have to do:\n\n  for credential in secure_storage_lookup(unique_token) {\n    if (!username)\n      return credential; /* take first one arbitrarily */\n    else if (username == credential.username)\n      return credential; /* ok, matched preferred username */\n  }\n  return NULL;\n\nwhich implies that the secure storage can even store a list indexed\nunder the token.\n\nSo perhaps a better model is to give the helper some canonicalized URL,\nlike:\n\n  https://foo@example.com\n\n(where the canonicalization is important, because we want the helper to\nbe able to just treat it like a string of bytes if it wants).  And then\nwe can naturally extend that to:\n\n  https://foo@example.com/specific-repo.git\n\nif the user wants a repo-specific authentication context.\n\n> We can consider what you already have as the default case for a more\n> general \"we cut off at the hostname and take that as the auth-domain\n> boundary unless told otherwise\". We may not have the way to \"tell\n> otherwise\" yet, but as long as we are reasonably confident that we know\n> how to extend the system in a backward compatible way, it is not a\n> show-stopper.\n\nI think in either case it gets tacked onto the auth token. But it\nprobably makes sense now to choose a nice syntax for the token that will\nlook good when we extend it later.\n\nTed wrote:\n\n> How about a config variable with regular expressions like\n>\n> auth-domain.xyz.url = https://(.*@)?github.com/.*\n\nI like this. In fact, perhaps it makes sense for git to generate the\nmaximal token, like:\n\n  https://user@host.example.com/path/to/repo.git\n\nand then provide the user with configuration like this to narrow it down\nas they see fit. Perhaps even do a substitution regexp to let them\nrewrite it arbitrarily. And then if we want to be more permissive by\ndefault, provide some backup regexps to be used when they don't provide\ntheir own, like cutting out the pathname portion.\n\n-Peff\n"},{"id":"175162","messageId":"CAEBDL5XnoCtiKQB8jRxvueWc9zy-yzC+MxgTLmP1amY+U=7aOw@mail.gmail.com","threadId":"28212","inReplyTo":"20110831023801.GB3340@sigill.intra.peff.net","subject":"Re: git credential helper design [was: What's cooking in git.git (Aug 2011, #07; Wed, 24)]","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2011-09-09T09:55:38Z","receivedAt":"2011-09-09T09:55:38Z","isPatch":false,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Tue, Aug 30, 2011 at 10:38 PM, Jeff King <peff@peff.net> wrote:\n[snip]\n> It's \"http:github.com\", which has always looked a bit ugly to me. I had\n> hoped they would just be opaque blobs and nobody would need to look at\n> them. But when you get into things like setting the username via the\n> config, then users see them, and they need to look sane. Making them\n> look more like a canonicalized URL is probably a good thing.\n\nA little feedback here: I do look into my keychain on Mac OS X.  I\ntend to keep most of my credentials in a separate keychain that gets\nwhenever my computer sleeps or the screen saver kicks on.  So that\nblob ends up being user-visible to some degree.  Could I munge it into\nsomething else?  Sure.  But I do wonder if it might be better to make\nit something closer to what the user expects to see.\n\n> After seeing the helper that Lukas posted recently on the list, I am\n> wondering if they should include the username, too. I had left it\n> separate, because I wanted helpers to be able to index \"foo@example.com\"\n> and \"example.com\" in the same slot. I.e., to realize that the latter\n> could use the same credentials cached for the former. But it also\n> complicates the helpers; instead of doing:\n\nHaving the username separate is useful.  At least under Mac OS X, the\n\"account name\" field is a separate search field.  It does make it\neasier to fallback to just looking at the domain and path without\nhaving to parse the unique token.  But as it is, we stand a chance at\nbeing able to reuse credentials already cached by the browser.\n\n>  credential = secure_storage_lookup(unique_token);\n>  return credential /* could be NULL */\n>\n> they have to do:\n>\n>  for credential in secure_storage_lookup(unique_token) {\n>    if (!username)\n>      return credential; /* take first one arbitrarily */\n>    else if (username == credential.username)\n>      return credential; /* ok, matched preferred username */\n>  }\n>  return NULL;\n>\n> which implies that the secure storage can even store a list indexed\n> under the token.\n>\n> So perhaps a better model is to give the helper some canonicalized URL,\n> like:\n>\n>  https://foo@example.com\n>\n> (where the canonicalization is important, because we want the helper to\n> be able to just treat it like a string of bytes if it wants).  And then\n> we can naturally extend that to:\n>\n>  https://foo@example.com/specific-repo.git\n>\n> if the user wants a repo-specific authentication context.\n\nOr pass that the information via --domain and --path parameters.  It'd\nbe nice to keep most credential backends from having to parse urls.\nNot that its hard, just cumbersome.  But the keychain implementation\nand the gnome-keyring implementation could both benefit from having\nthe pieces broken out separately.  Likewise, it's probably not\ndifficult to parse it out of the token if we needed to.\n\n[snip good discussion]\n\nOne thing that crossed my mind while looking at this: what happens\nwhen a command is meant to be non-interactive?  Looking at the\nkdewallet implementation, it appears that not only is the credential\nhelper intended to help do the lookup, but also ask the user for a\npassword, if it doesn't find anything.  That doesn't seem like it\nwould play well in a non-interactive environment.  Additionally, the\nact of looking up the entry could pop up a dialog in most\nkeychain-like applications.  Is there a need to be sensitive to the\nfact that we may be run non-interactively?\n\n-John\n"},{"id":"175269","messageId":"20110910065332.GA10935@sigill.intra.peff.net","threadId":"28212","inReplyTo":"CAEBDL5XnoCtiKQB8jRxvueWc9zy-yzC+MxgTLmP1amY+U=7aOw@mail.gmail.com","subject":"Re: git credential helper design [was: What's cooking in git.git (Aug 2011, #07; Wed, 24)]","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-09-10T06:53:32Z","receivedAt":"2011-09-10T06:53:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Sep 09, 2011 at 05:55:38AM -0400, John Szakmeister wrote:\n\n> A little feedback here: I do look into my keychain on Mac OS X.  I\n> tend to keep most of my credentials in a separate keychain that gets\n> whenever my computer sleeps or the screen saver kicks on.  So that\n> blob ends up being user-visible to some degree.  Could I munge it into\n> something else?  Sure.  But I do wonder if it might be better to make\n> it something closer to what the user expects to see.\n\nSure, I agree. I guess my question is: what does the user expect to see?\n\n> >  https://foo@example.com/specific-repo.git\n> >\n> > if the user wants a repo-specific authentication context.\n> \n> Or pass that the information via --domain and --path parameters.  It'd\n> be nice to keep most credential backends from having to parse urls.\n> Not that its hard, just cumbersome.  But the keychain implementation\n> and the gnome-keyring implementation could both benefit from having\n> the pieces broken out separately.  Likewise, it's probably not\n> difficult to parse it out of the token if we needed to.\n\nPerhaps it's worth providing the information in two forms: parsed and\nbroken out by individual pieces, and as a more opaque blob. Then systems\nwhich care can use the pieces, and systems which are trying to be as\nsimple as possible can use the blob.\n\nThat still leaves the question of how the user specifies policy about\nwhich parts of the blob are relevant. That is, how do they say that only\nthe \"domain\" portion of the hostname is relevant? Or that the path is or\nis not relevant?\n\nI was really hoping for the user to be able to specify this at the git\nlevel, to give each storage helper roughly the same feature set.\n\nMaybe it would be enough to do something like:\n\n  1. Assemble all of the parts (protocol, username (if any), hostname,\n     path) into a canonicalized URL representing the authentication\n     context.\n\n  2. Look for git config matching the context URL, and allow\n     transformations (e.g., match and replace the whole thing, or even\n     regexp-style substitution).\n\n  3. Break the resulting context URL back into constituent parts.\n\n  4. Give the helper the context URL, and the broken down parts from\n     (3). It chooses which to use.\n\n> One thing that crossed my mind while looking at this: what happens\n> when a command is meant to be non-interactive?  Looking at the\n> kdewallet implementation, it appears that not only is the credential\n> helper intended to help do the lookup, but also ask the user for a\n> password, if it doesn't find anything.  That doesn't seem like it\n> would play well in a non-interactive environment.  Additionally, the\n> act of looking up the entry could pop up a dialog in most\n> keychain-like applications.  Is there a need to be sensitive to the\n> fact that we may be run non-interactively?\n\nI think this is somewhat outside the boundaries of what git can provide.\nWe don't know whether we are interactive or not; we can only make\nguesses based on things like whether there is a terminal available. The\nhelper should be able to make an even better guess, because it can ask\nfor system-specific things (e.g., a Linux one might check whether\n$DISPLAY is set before trying to pop up a dialog). And helpers are free\nto simply return nothing. Even though most people will only configure a\nsingle helper, there is actually a stack, and git will try the next one,\nand so on until it gets an answer (or if it hits the end without an\nanswer, will complain).\n\n-Peff\n"},{"id":"175392","messageId":"CAEBDL5UGhanJboiT2SppeXa6UaKbE1MOpajf9wSaQCkR9EdRYw@mail.gmail.com","threadId":"28212","inReplyTo":"20110910065332.GA10935@sigill.intra.peff.net","subject":"Re: git credential helper design [was: What's cooking in git.git (Aug 2011, #07; Wed, 24)]","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2011-09-13T08:29:30Z","receivedAt":"2011-09-13T08:29:30Z","isPatch":false,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Sat, Sep 10, 2011 at 2:53 AM, Jeff King <peff@peff.net> wrote:\n> On Fri, Sep 09, 2011 at 05:55:38AM -0400, John Szakmeister wrote:\n>\n>> A little feedback here: I do look into my keychain on Mac OS X.  I\n>> tend to keep most of my credentials in a separate keychain that gets\n>> whenever my computer sleeps or the screen saver kicks on.  So that\n>> blob ends up being user-visible to some degree.  Could I munge it into\n>> something else?  Sure.  But I do wonder if it might be better to make\n>> it something closer to what the user expects to see.\n>\n> Sure, I agree. I guess my question is: what does the user expect to see?\n\nOriginally I was going to use SecKeychainFindGenericPassword(), and\nthe token would have been the \"serviceName\".  However,\nSecKeychainFindInternetPassword() is clearly the better fit, which\nmeans busting out the individual bits.\n\n[snip]\n> Perhaps it's worth providing the information in two forms: parsed and\n> broken out by individual pieces, and as a more opaque blob. Then systems\n> which care can use the pieces, and systems which are trying to be as\n> simple as possible can use the blob.\n\nThat would be useful.  Right now, it looks like I'll be parsing the token.\n\n> That still leaves the question of how the user specifies policy about\n> which parts of the blob are relevant. That is, how do they say that only\n> the \"domain\" portion of the hostname is relevant? Or that the path is or\n> is not relevant?\n>\n> I was really hoping for the user to be able to specify this at the git\n> level, to give each storage helper roughly the same feature set.\n\nOoh... yeah, I'm not sure. :-(\n\n> Maybe it would be enough to do something like:\n>\n>  1. Assemble all of the parts (protocol, username (if any), hostname,\n>     path) into a canonicalized URL representing the authentication\n>     context.\n>\n>  2. Look for git config matching the context URL, and allow\n>     transformations (e.g., match and replace the whole thing, or even\n>     regexp-style substitution).\n\nThat seems burdensome.  There is a method in HTTP/HTTPS for saying\n\"use this set of credentials\".  You'd do that via the security domain.\n That doesn't necessarily apply to other urls (ssh, for example), but\nit would allow a storage backend to cache it for a specific path, but\nfallback to looking up the credential using the security domain.\n\n[snip]\n> I think this is somewhat outside the boundaries of what git can provide.\n> We don't know whether we are interactive or not; we can only make\n> guesses based on things like whether there is a terminal available. The\n> helper should be able to make an even better guess, because it can ask\n> for system-specific things (e.g., a Linux one might check whether\n> $DISPLAY is set before trying to pop up a dialog). And helpers are free\n> to simply return nothing. Even though most people will only configure a\n> single helper, there is actually a stack, and git will try the next one,\n> and so on until it gets an answer (or if it hits the end without an\n> answer, will complain).\n\nOkay, I won't worry about it then.  Thanks Jeff!\n\n-John\n"},{"id":"175568","messageId":"87vcsuaxqd.fsf@lifelogs.com","threadId":"28212","inReplyTo":"CAEBDL5UGhanJboiT2SppeXa6UaKbE1MOpajf9wSaQCkR9EdRYw@mail.gmail.com","subject":"Re: git credential helper design [","fromName":"Ted Zlatanov","fromEmail":"tzz@lifelogs.com","sentAt":"2011-09-15T10:47:22Z","receivedAt":"2011-09-15T10:47:22Z","isPatch":false,"sender":{"key":"tzz@lifelogs.com","avatar":"https://avatars.githubusercontent.com/u/67764?v=4"},"body":"On Tue, 13 Sep 2011 04:29:30 -0400 John Szakmeister <john@szakmeister.net> wrote: \n\nJS> On Sat, Sep 10, 2011 at 2:53 AM, Jeff King <peff@peff.net> wrote:\n>> On Fri, Sep 09, 2011 at 05:55:38AM -0400, John Szakmeister wrote:\n>> \n>>> A little feedback here: I do look into my keychain on Mac OS X.  I\n>>> tend to keep most of my credentials in a separate keychain that gets\n>>> whenever my computer sleeps or the screen saver kicks on.  So that\n>>> blob ends up being user-visible to some degree.  Could I munge it into\n>>> something else?  Sure.  But I do wonder if it might be better to make\n>>> it something closer to what the user expects to see.\n>> \n>> Sure, I agree. I guess my question is: what does the user expect to see?\n\nJS> Originally I was going to use SecKeychainFindGenericPassword(), and\nJS> the token would have been the \"serviceName\".  However,\nJS> SecKeychainFindInternetPassword() is clearly the better fit, which\nJS> means busting out the individual bits.\n\nI would make it work like Safari, period.\n\nJS> [snip]\n>> Perhaps it's worth providing the information in two forms: parsed and\n>> broken out by individual pieces, and as a more opaque blob. Then systems\n>> which care can use the pieces, and systems which are trying to be as\n>> simple as possible can use the blob.\n\nJS> That would be useful.  Right now, it looks like I'll be parsing the token.\n\n>> That still leaves the question of how the user specifies policy about\n>> which parts of the blob are relevant. That is, how do they say that only\n>> the \"domain\" portion of the hostname is relevant? Or that the path is or\n>> is not relevant?\n>> \n>> I was really hoping for the user to be able to specify this at the git\n>> level, to give each storage helper roughly the same feature set.\n\nJS> Ooh... yeah, I'm not sure. :-(\n\nI posted a simple proposal for auth domains, which would introduce an\nextra abstraction layer between the URL and the credential helper.  I\nthink that would help.\n\n>> Maybe it would be enough to do something like:\n>> \n>>  1. Assemble all of the parts (protocol, username (if any), hostname,\n>>     path) into a canonicalized URL representing the authentication\n>>     context.\n>> \n>>  2. Look for git config matching the context URL, and allow\n>>     transformations (e.g., match and replace the whole thing, or even\n>>     regexp-style substitution).\n\nJS> That seems burdensome.  There is a method in HTTP/HTTPS for saying\nJS> \"use this set of credentials\".  You'd do that via the security domain.\nJS>  That doesn't necessarily apply to other urls (ssh, for example), but\nJS> it would allow a storage backend to cache it for a specific path, but\nJS> fallback to looking up the credential using the security domain.\n\nThe HTTP security domain is set by the remote, not the Git user, and so\nis neither customizable nor reliable, unfortunately.  Also as you\nmentioned it won't work for non-HTTP URLs, and it is determined late in\nthe process, perhaps too late for some helpers.\n\nTed\n"}]}