{"thread":{"id":"26617","subject":"What's cooking in git.git (Feb 2011, #06; Sun, 27)","startedAt":"2011-02-28T06:48:32Z","lastAt":"2011-03-10T16:37:29Z","messageCount":12,"participants":["Junio C Hamano","Sverre Rabbelier","Jeff King","Piotr Krukowiecki","Jakub Narebski","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"162399","messageId":"7vy650k62n.fsf@alter.siamese.dyndns.org","threadId":"26617","inReplyTo":null,"subject":"What's cooking in git.git (Feb 2011, #06; Sun, 27)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-28T06:48:32Z","receivedAt":"2011-02-28T06:48:32Z","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\n--------------------------------------------------\n[Graduated to \"master\"]\n\n* en/object-list-with-pathspec (2010-09-20) 2 commits\n  (merged to 'next' on 2011-02-09 at ccf6c6a)\n + Add testcases showing how pathspecs are handled with rev-list --objects\n + Make rev-list --objects work together with pathspecs\n (this branch uses nd/struct-pathspec; is tangled with jc/grep--no-index-pathspec-fix.)\n\n* hv/mingw-fs-funnies (2011-02-07) 5 commits\n  (merged to 'next' on 2011-02-09 at 3d0bb1a)\n + mingw_rmdir: set errno=ENOTEMPTY when appropriate\n + mingw: add fallback for rmdir in case directory is in use\n + mingw: make failures to unlink or move raise a question\n + mingw: work around irregular failures of unlink on windows\n + mingw: move unlink wrapper to mingw.c\n\n* jh/push-default-upstream-configname (2011-02-16) 1 commit\n  (merged to 'next' on 2011-02-23 at b5c25fa)\n + push.default: Rename 'tracking' to 'upstream'\n\n* js/detach-doc (2011-02-20) 1 commit\n  (merged to 'next' on 2011-02-21 at c384c3c)\n + git-checkout.txt: improve detached HEAD documentation\n\n* js/maint-merge-use-prepare-commit-msg-hook (2011-02-14) 1 commit\n  (merged to 'next' on 2011-02-22 at 6458c4b)\n + merge: honor prepare-commit-msg hook\n\n* lp/config-vername-check (2011-02-01) 2 commits\n  (merged to 'next' on 2011-02-23 at 426d48d)\n + Disallow empty section and variable names\n + Sanity-check config variable names\n\n* mg/patch-id (2011-02-17) 2 commits\n  (merged to 'next' on 2011-02-22 at 6f4acd8)\n + git-patch-id: do not trip over \"no newline\" markers\n + git-patch-id: test for \"no newline\" markers\n\n* mg/placeholders-are-lowercase (2011-02-17) 5 commits\n  (merged to 'next' on 2011-02-22 at 2754e21)\n + Make <identifier> lowercase in Documentation\n + Make <identifier> lowercase as per CodingGuidelines\n + Make <identifier> lowercase as per CodingGuidelines\n + Make <identifier> lowercase as per CodingGuidelines\n + CodingGuidelines: downcase placeholders in usage messages\n\n* mo/perl-bidi-pipe-envfix (2011-02-15) 1 commit\n  (merged to 'next' on 2011-02-15 at c36e816)\n + perl: command_bidi_pipe() method should set-up git environmens\n\n* mz/rerere-remaining (2011-02-16) 2 commits\n  (merged to 'next' on 2011-02-22 at fa2d5ab)\n + mergetool: don't skip modify/remove conflicts\n + rerere \"remaining\"\n\n* nd/hash-object-sanity (2011-02-05) 1 commit\n  (merged to 'next' on 2011-02-22 at 09acf6f)\n + Make hash-object more robust against malformed objects\n\n* nd/sorted-builtin-command-list (2011-02-15) 1 commit\n  (merged to 'next' on 2011-02-22 at 91fccd1)\n + git.c: reorder builtin command list\n\n* nd/struct-pathspec (2011-01-31) 22 commits\n  (merged to 'next' on 2011-02-09 at b1e64ee)\n + t6004: add pathspec globbing test for log family\n + t7810: overlapping pathspecs and depth limit\n + grep: drop pathspec_matches() in favor of tree_entry_interesting()\n + grep: use writable strbuf from caller for grep_tree()\n + grep: use match_pathspec_depth() for cache/worktree grepping\n + grep: convert to use struct pathspec\n + Convert ce_path_match() to use match_pathspec_depth()\n + Convert ce_path_match() to use struct pathspec\n + struct rev_info: convert prune_data to struct pathspec\n + pathspec: add match_pathspec_depth()\n + tree_entry_interesting(): optimize wildcard matching when base is matched\n + tree_entry_interesting(): support wildcard matching\n + tree_entry_interesting(): fix depth limit with overlapping pathspecs\n + tree_entry_interesting(): support depth limit\n + tree_entry_interesting(): refactor into separate smaller functions\n + diff-tree: convert base+baselen to writable strbuf\n + glossary: define pathspec\n + Move tree_entry_interesting() to tree-walk.c and export it\n + tree_entry_interesting(): remove dependency on struct diff_options\n + Convert struct diff_options to use struct pathspec\n + diff-no-index: use diff_tree_setup_paths()\n + Add struct pathspec\n (this branch is used by en/object-list-with-pathspec and jc/grep--no-index-pathspec-fix.)\n\n* pw/p4 (2011-02-19) 8 commits\n  (merged to 'next' on 2011-02-21 at 1a7b7d2)\n + git-p4: support clone --bare\n + git-p4: decode p4 wildcard characters\n + git-p4: better message for \"git-p4 sync\" when not cloned\n + git-p4: reinterpret confusing p4 message\n + git-p4: accommodate new move/delete type in p4\n + git-p4: add missing newline in initial import message\n + git-p4: fix key error for p4 problem\n + git-p4: test script\n\n* sp/maint-smart-http-sans-100-continue (2011-02-15) 1 commit\n  (merged to 'next' on 2011-02-15 at 553e3e5)\n + smart-http: Don't use Expect: 100-Continue\n\n* uk/checkout-ambiguous-ref (2011-02-15) 5 commits\n  (merged to 'next' on 2011-02-15 at 645dad6)\n + Rename t2019 with typo \"amiguous\" that meant \"ambiguous\"\n + checkout: rearrange update_refs_for_switch for clarity\n + checkout: introduce --detach synonym for \"git checkout foo^{commit}\"\n + checkout: split off a function to peel away branchname arg\n  (merged to 'next' on 2011-02-03 at 9044724)\n + checkout: fix bug with ambiguous refs\n\n* va/p4 (2011-02-20) 2 commits\n  (merged to 'next' on 2011-02-21 at d981b23)\n + git-p4: Add copy detection support\n + git-p4: Improve rename detection support\n\n--------------------------------------------------\n[New Topics]\n\n* jn/maint-commit-missing-template (2011-02-25) 1 commit\n  (merged to 'next' on 2011-02-25 at c95589d)\n + commit: error out for missing commit message template\n\n* mg/maint-difftool-vim-readonly (2011-02-25) 1 commit\n  (merged to 'next' on 2011-02-25 at 990579c)\n + mergetool-lib: call vim in readonly mode for diffs\n\n* fk/maint-cvsimport-early-failure (2011-01-31) 1 commit\n - git-cvsimport.perl: Bail out right away when reading from the server fails\n\n* jk/strbuf-vaddf (2011-02-25) 2 commits\n - strbuf: add strbuf_vaddf\n - compat: provide a fallback va_copy definition\n (this branch is used by ab/i18n-st, jk/trace-sifter and jn/status-translatable.)\n\n* jk/trace-sifter (2011-02-24) 6 commits\n - trace: give repo_setup trace its own key\n - add packet tracing debug code\n - trace: add trace_strbuf\n - trace: factor out \"do we want to trace\" logic\n - trace: refactor to support multiple env variables\n - trace: add trace_vprintf\n (this branch uses jk/strbuf-vaddf; is tangled with ab/i18n-st and jn/status-translatable.)\n\n* jn/maint-instaweb-plack-fix (2011-02-26) 1 commit\n - git-instaweb: Change how gitweb.psgi is made runnable as standalone app\n\n* jn/status-translatable (2011-02-25) 3 commits\n - commit, status: use status_printf{,_ln,_more} helpers\n - commit: refer to commit template as s->fp\n - wt-status: add helpers for printing wt-status lines\n (this branch is used by ab/i18n-st and ab/i18n-st; uses jk/strbuf-vaddf; is tangled with jk/trace-sifter.)\n\n* mh/p4 (2011-02-25) 1 commit\n  (merged to 'next' on 2011-02-26 at 1693331)\n + git-p4 submit: prevent 'Jobs' section from being removed from p4 change log\n\n* nd/rfc-add-u-full-tree (2011-02-07) 1 commit\n - add: make \"add -u\" update full tree without pathspec\n\n* ss/git-gui-mergetool (2011-02-26) 2 commits\n - mergetool--lib: Add Beyond Compare 3 as a tool\n - mergetool--lib: Sort tools alphabetically for easier lookup\n\n* ss/mergetool--lib (2011-02-27) 2 commits\n - mergetool--lib: Add Beyond Compare 3 as a tool\n - mergetool--lib: Sort tools alphabetically for easier lookup\n\n--------------------------------------------------\n[Stalled]\n\n* jh/merge-sans-branch (2011-02-10) 4 commits\n . merge: add support for merging from upstream by default\n - merge: introduce per-branch-configuration helper function\n - merge: introduce setup_merge_commit helper function\n - merge: update the usage information to be more modern\n\nThere was an objection to the tip one that determines the upstream in a\nwrong way?\n\n* jk/tag-contains (2010-07-05) 4 commits\n - Why is \"git tag --contains\" so slow?\n - default core.clockskew variable to one day\n - limit \"contains\" traversals based on commit timestamp\n - tag: speed up --contains calculation\n\nThe idea of the bottom one is probably Ok, except that the use of object\nflags needs to be rethought, or at least the helper needs to be moved to\nbuiltin/tag.c to make it clear that it should not be used outside the\ncurrent usage context.\n\n* jc/rename-degrade-cc-to-c (2011-01-06) 3 commits\n . diffcore-rename: fall back to -C when -C -C busts the rename limit\n . diffcore-rename: record filepair for rename src\n . diffcore-rename: refactor \"too many candidates\" logic\n\n--------------------------------------------------\n[Cooking]\n\n* nd/index-doc (2010-09-06) 1 commit\n - doc: technical details about the index file format\n\n* ab/i18n-st (2011-02-22) 74 commits\n - i18n: git-shortlog basic messages\n - i18n: git-revert split up \"could not revert/apply\" message\n - i18n: git-revert literal \"me\" messages\n - i18n: git-revert \"Your local changes\" message\n - i18n: git-revert basic messages\n - i18n: git-notes GIT_NOTES_REWRITE_MODE error message\n - i18n: git-notes basic commands\n - i18n: git-gc \"Auto packing the repository\" message\n - i18n: git-gc basic messages\n - i18n: git-describe basic messages\n - i18n: git-clean clean.requireForce messages\n - i18n: git-clean basic messages\n - i18n: git-bundle basic messages\n - i18n: git-archive basic messages\n - i18n: git-status \"renamed: \" message\n - i18n: git-status \"Initial commit\" message\n - i18n: git-status \"Changes to be committed\" message\n - i18n: git-status shortstatus messages\n - i18n: git-status \"nothing to commit\" messages\n - i18n: git-status basic messages\n - i18n: git-push \"prevent you from losing\" message\n - i18n: git-push basic messages\n - i18n: git-tag tag_template message\n - i18n: git-tag basic messages\n - i18n: git-reset \"Unstaged changes after reset\" message\n - i18n: git-reset reset_type_names messages\n - i18n: git-reset basic messages\n - i18n: git-rm basic messages\n - i18n: git-mv \"bad\" messages\n - i18n: git-mv basic messages\n - i18n: git-merge \"Wonderful\" message\n - i18n: git-merge \"You have not concluded your merge\" messages\n - i18n: git-merge \"Updating %s..%s\" message\n - i18n: git-merge basic messages\n - i18n: git-log \"--OPT does not make sense\" messages\n - i18n: git-log basic messages\n - i18n: git-grep \"--open-files-in-pager\" message\n - i18n: git-grep basic messages\n - i18n: git-fetch split up \"(non-fast-forward)\" message\n - i18n: git-fetch update_local_ref messages\n - i18n: git-fetch formatting messages\n - i18n: git-fetch basic messages\n - i18n: git-diff basic messages\n - i18n: git-commit advice messages\n - i18n: git-commit \"enter the commit message\" message\n - i18n: git-commit print_summary messages\n - i18n: git-commit formatting messages\n - i18n: git-commit \"middle of a merge\" message\n - i18n: git-commit basic messages\n - i18n: git-checkout \"Switched to a .. branch\" message\n - i18n: git-checkout \"HEAD is now at\" message\n - i18n: git-checkout describe_detached_head messages\n - i18n: git-checkout: our/their version message\n - i18n: git-checkout basic messages\n - i18n: git-branch \"(no branch)\" message\n - i18n: git-branch \"git branch -v\" messages\n - i18n: git-branch \"Deleted branch [...]\" message\n - i18n: git-branch \"remote branch '%s' not found\" message\n - i18n: git-branch basic messages\n - i18n: git-add \"Unstaged changes\" message\n - i18n: git-add \"remove '%s'\" message\n - i18n: git-add \"did not match any files\" message\n - i18n: git-add \"The following paths are ignored\" message\n - i18n: git-add basic messages\n - i18n: git-clone \"Cloning into\" message\n - i18n: git-clone \"Cloning into\" message\n - i18n: git-clone basic messages\n - i18n: git-init \"Initialized [...] repository\" message\n - i18n: git-init basic messages\n - i18n: \"make distclean\" should clean up after \"make pot\"\n - i18n: Makefile: \"pot\" target to extract messages marked for translation\n - i18n: do not poison translations unless GIT_GETTEXT_POISON envvar is set\n - i18n: add GETTEXT_POISON to simulate unfriendly translator\n - i18n: add no-op _() and N_() wrappers\n (this branch uses jk/strbuf-vaddf, jn/status-translatable and jn/status-translatable; is tangled with jk/trace-sifter.)\n\nRebased on other infrastructure adjustments (tentatively renamed the\nbranch).  I'd like to fast-track the basics (especially the bottom 3\npatches), and am even tempted to rebase other patches on 'pu' that are not\nyet in 'next' on top of them, to make the transition easier.\n\n* gr/cvsimport-alternative-cvspass-location (2011-02-18) 1 commit\n - Look for password in both CVS and CVSNT password files.\n\n* jc/checkout-orphan-warning (2011-02-18) 1 commit\n - commit: give final warning when reattaching HEAD to leave commits behind\n\nLikes, dislikes?\n\n* jh/maint-do-not-track-non-branches (2011-02-17) 1 commit\n - branch/checkout --track: Ensure that upstream branch is indeed a branch\n\n* jk/diffstat-binary (2011-02-19) 2 commits\n  (merged to 'next' on 2011-02-23 at 49da967)\n + diff: don't retrieve binary blobs for diffstat\n + diff: handle diffstat of rewritten binary files\n\n* jk/fail-null-clone (2011-02-17) 1 commit\n  (merged to 'next' on 2011-02-23 at a4217f5)\n + clone: die when trying to clone missing local path\n\n* jk/merge-rename-ux (2011-02-20) 6 commits\n - pull: propagate --progress to merge\n - merge: enable progress reporting for rename detection\n - add inexact rename detection progress infrastructure\n - commit: stop setting rename limit\n - bump rename limit defaults (again)\n - merge: improve inexact rename limit warning\n\nThe above three all seemed sensible improvements.\n\n* jn/test-terminal-punt-on-osx-breakage (2011-02-17) 1 commit\n  (merged to 'next' on 2011-02-23 at d754139)\n + tests: skip terminal output tests on OS X\n\n* js/cherry-pick-usability (2011-02-19) 4 commits\n  (merged to 'next' on 2011-02-23 at 95db30e)\n + Teach commit about CHERRY_PICK_HEAD\n + bash: teach __git_ps1 about CHERRY_PICK_HEAD\n + Introduce CHERRY_PICK_HEAD\n + t3507: introduce pristine-detach helper\n\n* lt/rename-no-extra-copy-detection (2011-02-18) 3 commits\n  (merged to 'next' on 2011-02-23 at 2c1f271)\n + diffcore-rename: improve estimate_similarity() heuristics\n + diffcore-rename: properly honor the difference between -M and -C\n + for_each_hash: allow passing a 'void *data' pointer to callback\n\n* mg/rev-list-one-side-only (2011-02-22) 6 commits\n - t6007: test rev-list --cherry\n - log --cherry: a synonym\n - rev-list: --left/right-only are mutually exclusive\n - rev-list: documentation and test for --left/right-only\n - t6007: Make sure we test --cherry-pick\n - revlist.c: introduce --left/right-only for unsymmetric picking\n\n* so/submodule-no-update-first-time (2011-02-17) 2 commits\n  (merged to 'next' on 2011-02-23 at 2c6e8c9)\n + t7406: \"git submodule update {--merge|--rebase]\" with new submodules\n + submodule: no [--merge|--rebase] when newly cloned\n\n* jc/complete-symmetric-diff (2011-02-23) 1 commit\n - completion: complete \"git diff ...branc<TAB>\"\n\n* jh/submodule-fetch-on-demand (2011-02-23) 6 commits\n - submodule update: Don't fetch when the submodule commit is already present\n - fetch/pull: Don't recurse into a submodule when commits are already present\n - Submodules: Add 'on-demand' value for the 'fetchRecurseSubmodule' option\n - config: teach the fetch.recurseSubmodules option the 'on-demand' value\n - fetch/pull: Add the 'on-demand' value to the --recurse-submodules option\n - fetch/pull: recurse into submodules when necessary\n\n* jk/format-patch-multiline-header (2011-02-23) 3 commits\n - format-patch: rfc2047-encode newlines in headers\n - format-patch: wrap long header lines\n - strbuf: add fixed-length version of add_wrapped_text\n\n* js/checkout-untracked-symlink (2011-02-20) 2 commits\n  (merged to 'next' on 2011-02-23 at 52a35ce)\n + do not overwrite untracked symlinks\n + Demonstrate breakage: checkout overwrites untracked symlink with directory\n\n* jc/grep--no-index-pathspec-fix (2011-02-16) 1 commit\n  (merged to 'next' on 2011-02-23 at 58b03b1)\n + grep --no-index: honor pathspecs correctly\n\n* mz/rebase (2011-02-24) 33 commits\n  (merged to 'next' on 2011-02-25 at 52caa7a)\n + Makefile: do not install sourced rebase scripts\n  (merged to 'next' on 2011-02-22 at 3219155)\n + rebase: use @{upstream} if no upstream specified\n + rebase -i: remove unnecessary state rebase-root\n + rebase -i: don't read unused variable preserve_merges\n + git-rebase--am: remove unnecessary --3way option\n + rebase -m: don't print exit code 2 when merge fails\n + rebase -m: remember allow_rerere_autoupdate option\n + rebase: remember strategy and strategy options\n + rebase: remember verbose option\n + rebase: extract code for writing basic state\n + rebase: factor out sub command handling\n + rebase: make -v a tiny bit more verbose\n + rebase -i: align variable names\n + rebase: show consistent conflict resolution hint\n + rebase: extract am code to new source file\n + rebase: extract merge code to new source file\n + rebase: remove $branch as synonym for $orig_head\n + rebase -i: support --stat\n + rebase: factor out call to pre-rebase hook\n + rebase: factor out clean work tree check\n + rebase: factor out reference parsing\n + rebase: reorder validation steps\n + rebase -i: remove now unnecessary directory checks\n + rebase: factor out command line option processing\n + rebase: align variable content\n + rebase: align variable names\n + rebase: stricter check of standalone sub command\n + rebase: act on command line outside parsing loop\n + rebase: improve detection of rebase in progress\n + rebase: remove unused rebase state 'prev_head'\n + rebase: read state outside loop\n + rebase: refactor reading of state\n + rebase: clearer names for directory variables\n\nMinor UI regression was reported but otherwise it looked like that the\ntopic is in a good shape.\n\n--------------------------------------------------\n[Discarded]\n\n* cp/mergetool-beyondcompare (2011-02-18) 1 commit\n . mergetool--lib: add support for beyond compare\n\nss/mergetool--lib replaces this.\n"},{"id":"162440","messageId":"AANLkTikW1GVzFoq=zUxvi7MTcUYBLO6fbjJPVZziLUk8@mail.gmail.com","threadId":"26617","inReplyTo":"7vy650k62n.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Feb 2011, #06; Sun, 27)","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-02-28T13:22:42Z","receivedAt":"2011-02-28T13:22:42Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Feb 28, 2011 at 07:48, Junio C Hamano <gitster@pobox.com> wrote:\n> * jc/checkout-orphan-warning (2011-02-18) 1 commit\n>  - commit: give final warning when reattaching HEAD to leave commits behind\n>\n> Likes, dislikes?\n\nI can't find a message containing this commit title, can you link to\nthe relevant thread? I did find that in the last what's cooking Ævar\nreplied and said +1? I agree that this is something we want to do\nthough, I'd like all operations in git to be as data-preserving as\npossible, and to be similarly helpful to users about not losing data.\nI think this is a good step in that direction.\n\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"162450","messageId":"7v7hckje4n.fsf@alter.siamese.dyndns.org","threadId":"26617","inReplyTo":"AANLkTikW1GVzFoq=zUxvi7MTcUYBLO6fbjJPVZziLUk8@mail.gmail.com","subject":"Re: What's cooking in git.git (Feb 2011, #06; Sun, 27)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-28T16:52:08Z","receivedAt":"2011-02-28T16:52:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier <srabbelier@gmail.com> writes:\n\n> Heya,\n>\n> On Mon, Feb 28, 2011 at 07:48, Junio C Hamano <gitster@pobox.com> wrote:\n>> * jc/checkout-orphan-warning (2011-02-18) 1 commit\n>>  - commit: give final warning when reattaching HEAD to leave commits behind\n>>\n>> Likes, dislikes?\n>\n> I can't find a message containing this commit title, can you link to\n> the relevant thread?\n\nThis is a re-roll of a fallout from this thread:\n\n    http://thread.gmane.org/gmane.comp.version-control.git/166595/focus=167133\n\nI do think the safety net for detached HEAD is a bit too flimsy, and that\nis the motivation behind this.\n\nAs I don't think it is necessarily a good idea to attempt to make every\npossible operation revertible (e.g., I do not think \"oops, I did 'git add'\nand I have only \"git lost-and-found\" to find the old index entry\" is a\nproblem worth solving with extra complexity and storage cost), we should\nstrike a good balance by adding safety only at key places in reasonable\nworkflows (as opposed to every step to clutter the \"undo log\").\n\nI am not convinced that this patch nailed that balance at exactly the\nright place, even though I think we are getting closer than before.  In\nthis sequence:\n\n    $ git checkout somewhere^0\n    $ git commit\n    $ git reset --hard somewhere_else\n    $ git commit\n    $ git checkout master\n\nThe second commit is protected with the patch, but not the first one,\nwhich is still protected by the reflog on HEAD (i.e. \"git log -g HEAD\").\nYou have to know the reflog on HEAD if you _intend to_ work on detached\nHEAD anyway, and you don't need this patch if you do---the second commit\ncan also be recovered from the reflog on HEAD.\n\nSo this patch is not about helping people who _chose to_ work on detached\nHEAD; instead the patch in its current form is about helping sightseers\nwho has become _only_ a bit adventurous.  To help people who accidentally\nstarted from a detached state (i.e. starting from sightseeing but then got\nvery adventurous, forgetting that they are not on any branch) and spent\nsignificant amount of time committing and resetting, the advice message\nshould teach them to use \"log -g HEAD\" more explicitly, instead of giving\ndetails of the last state (i.e. \"you are leaving %n commits behind...\").\n"},{"id":"162586","messageId":"20110301205424.GA18793@sigill.intra.peff.net","threadId":"26617","inReplyTo":"7v7hckje4n.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Feb 2011, #06; Sun, 27)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-01T20:54:24Z","receivedAt":"2011-03-01T20:54:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 28, 2011 at 08:52:08AM -0800, Junio C Hamano wrote:\n\n> > On Mon, Feb 28, 2011 at 07:48, Junio C Hamano <gitster@pobox.com> wrote:\n> >> * jc/checkout-orphan-warning (2011-02-18) 1 commit\n> >>  - commit: give final warning when reattaching HEAD to leave commits behind\n> >>\n> >> Likes, dislikes?\n> >\n> > I can't find a message containing this commit title, can you link to\n> > the relevant thread?\n> \n> This is a re-roll of a fallout from this thread:\n> \n>     http://thread.gmane.org/gmane.comp.version-control.git/166595/focus=167133\n> \n> I do think the safety net for detached HEAD is a bit too flimsy, and that\n> is the motivation behind this.\n\nI've been meaning to look more closely at this for a while. I like it.\nThere is some small overhead in the revision traversal, but in my\n(admittedly not very rigorous) tests it is not noticeable.\n\nI complained before about the possibility of going to the roots, but of\ncourse that doesn't happen here because the regular traversal does\nrespect commit timestamps as a hint to stop (so it is subject to skew,\nbut that is nothing new).\n\n> I am not convinced that this patch nailed that balance at exactly the\n> right place, even though I think we are getting closer than before.  In\n> this sequence:\n> \n>     $ git checkout somewhere^0\n>     $ git commit\n>     $ git reset --hard somewhere_else\n>     $ git commit\n>     $ git checkout master\n> \n> The second commit is protected with the patch, but not the first one,\n> which is still protected by the reflog on HEAD (i.e. \"git log -g HEAD\").\n> You have to know the reflog on HEAD if you _intend to_ work on detached\n> HEAD anyway, and you don't need this patch if you do---the second commit\n> can also be recovered from the reflog on HEAD.\n\nI really wouldn't expect it to help here. The problem isn't that you're\non a detached HEAD. It's that you're using \"git reset\" at all. If you\ndid that while on a branch, you would still have to pull the result from\nthe reflog. Maybe somebody has a clever idea to deal with that, but it\nis a separate problem (and personally, I think the answer is \"reset is\ndangerous; don't use it\". That isn't the case with the detached head,\nbecause checkout and commit are usually safe, and it is more about\npeople being confused about their state when they make commits).\n\nAs far as the balance struck in the patch, the decisions I see are:\n\n  1. When to warn. I think \"when commit does not match a ref exactly\" is\n     going to have too many false positives. Reachability seems like the\n     best answer, as long as the computation time doesn't turn out to be\n     too expensive.\n\n  2. Whether to block the checkout or warn.  You chose warn, and I\n     agree. The advice for fixing it is the same whether we go through\n     with the checkout or not. Blocking it just makes the \"so what, I\n     want to throw those away\" choice unnecessarily annoying.\n\nSo I'm curious what you think is missing in the balance you mentioned\nabove.\n\nA few other things I noticed are:\n\n  - I like that you show the commits about to be dropped. That helps the\n    user make the decision, and it is not expensive to calculate since\n    we are in the uncommon \"safety valve kicks in\" case.\n\n    I did find the \" - oneline\" format a little off. Maybe just because\n    I am so used to regular git output. But I think just using \" %h %s\",\n    e.g.:\n\n       1234abcd commit subject one\n       5678defa commit subject two\n\n    would be better. Users are (hopefully) used to seeing commits listed\n    in that form, and the sha1s are useful if you are a clueful user and\n    your decision isn't to make a branch, but rather to say \"Oh, the top\n    one is junk but the second is useful\". And then you can cherry-pick\n    it, look at it in more detail, or whatever.\n\n    In other words, I think this safety valve is not just useful for\n    clueless people who make commits without realizing they're on a\n    detached HEAD. It is also useful for clueful people as a helpful\n    reminder that they may be leaving commits behind, and they can\n    ignore or deal with it as appropriate. I tend to ignore the\n    \"Previous HEAD was...\" message because it shows _every time_,\n    whether those are my new commits or not.\n\n  - It should probably be wrapped in advice.abandonDetachedCommits or\n    something. If turned off, we can omit the check altogether\n    (and possibly retain the \"Previous HEAD was...\" message, though I'm\n    not sure). But I can also imagine a \"short\" version that just shows\n    a single-line \"warning: you are leaving %d commits behind\" and the\n    oneline of each, but without the \"here's where to go from there\"\n    advice. I would probably use the short version myself.\n\n  - Nit: you nicely use \"%d commit%s\" to handle the single/plural case\n    in the warning message, but then you \"them\" later on. It needs\n    (1 < lost) ? \"them\" : \"it\".\n\n> So this patch is not about helping people who _chose to_ work on detached\n> HEAD; instead the patch in its current form is about helping sightseers\n> who has become _only_ a bit adventurous.  To help people who accidentally\n> started from a detached state (i.e. starting from sightseeing but then got\n> very adventurous, forgetting that they are not on any branch) and spent\n> significant amount of time committing and resetting, the advice message\n> should teach them to use \"log -g HEAD\" more explicitly, instead of giving\n> details of the last state (i.e. \"you are leaving %n commits behind...\").\n\nAh, I think this is maybe where your reset example comes in. I remember\nin early discussions of detached HEAD you recommending the workflow:\n\n  # sightsee to some tag\n  git checkout v1.7.4\n  # now sightsee somewhere else\n  git reset --hard v1.7.3\n  # now go back to a branch\n  git checkout master\n\nBut isn't that second step much better accomplished with \"git checkout\nv1.7.3\" ? It's conceptually much simpler (you use the same command to\nsightsee the first time as the second, and you don't have to know what\nin the world --hard means), it's less typing, and it has better safety\nvalves (even before the valve we are talking about).\n\nSo I don't think it is worth thinking too hard about people doing random\nresets in the middle of a detached HEAD. We should just not recommend\nreset as a command for this (and indeed, I think it already has a bit of\na reputation among newer git users as a dangerous and scary thing to\ndo. Which is probably fine).\n\nIf we do want to teach reset users about reflog, then I think that is a\nseparate issue from the detached HEAD case (and I would _certainly_ wrap\nthat in an advice.* config :) ).\n\n-Peff\n"},{"id":"162616","messageId":"7vlj0yff6m.fsf@alter.siamese.dyndns.org","threadId":"26617","inReplyTo":"20110301205424.GA18793@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Feb 2011, #06; Sun, 27)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-02T02:07:29Z","receivedAt":"2011-03-02T02:07:29Z","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 Mon, Feb 28, 2011 at 08:52:08AM -0800, Junio C Hamano wrote:\n>\n>> I am not convinced that this patch nailed that balance at exactly the\n>> right place, even though I think we are getting closer than before.  In\n>> this sequence:\n>> \n>>     $ git checkout somewhere^0\n>>     $ git commit\n>>     $ git reset --hard somewhere_else\n>>     $ git commit\n>>     $ git checkout master\n>> ...\n> I really wouldn't expect it to help here. The problem isn't that you're\n> on a detached HEAD. It's that you're using \"git reset\" at all.\n\nAs you would realize later in your message, the \"reset --hard\" can instead\nbe \"checkout v1.7.3\".  And the bothersome thing is that there is no safety\nagainst that.  We don't bother users while they are jumping around on\ndetached HEAD, and it is not new; we don't say where the previous detached\nHEAD was.\n\nPerhaps that needs to be changed to have the same safety?  IOW, regardless\nof your \"checkout\" destination, whenever you leave a detached commit that\nwould become unreachable, we should warn the same way?\n\nI suspect I would loath it as being too loud; I dunno...\n"},{"id":"162620","messageId":"7vwrkiccy6.fsf@alter.siamese.dyndns.org","threadId":"26617","inReplyTo":"20110301205424.GA18793@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Feb 2011, #06; Sun, 27)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-02T05:24:01Z","receivedAt":"2011-03-02T05:24:01Z","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> So I'm curious what you think is missing in the balance you mentioned\n> above.\n\nI touched this in a separate message, I think...\n\n> A few other things I noticed are:\n> ...\n>     I am so used to regular git output. But I think just using \" %h %s\",\n>     e.g.:\n>\n>        1234abcd commit subject one\n>        5678defa commit subject two\n\nThat would be better, I agree.\n\n> ...\n>     In other words, I think this safety valve is not just useful for\n>     clueless people who make commits without realizing they're on a\n>     detached HEAD. It is also useful for clueful people as a helpful\n>     reminder that they may be leaving commits behind, and they can\n>     ignore or deal with it as appropriate. I tend to ignore the\n>     \"Previous HEAD was...\" message because it shows _every time_,\n>     whether those are my new commits or not.\n\n... never thought about this from that angle.  Perhaps you are right.\n\n>   - Nit: you nicely use \"%d commit%s\" to handle the single/plural case\n>     in the warning message, but then you \"them\" later on. It needs\n>     (1 < lost) ? \"them\" : \"it\".\n\nI actually don't like playing games like that, especially when i18n topic\nis in flight.  Among the languages I know rules reasonably well, two has\nthe rule that a countable noun is spelled differently depending on the\nnumber of that thing is one or more, and one spells the noun the same way\nregardless of the number.  Who knows if git needs to be translated into a\nlanguage whose noun changes its shape three-way, depending on the number\nbeing one, two, or more?\n"},{"id":"162625","messageId":"AANLkTi=+iBR3OBZ=4fi_g=JMQKi=47F47hRsWxK=RbMv@mail.gmail.com","threadId":"26617","inReplyTo":"7vwrkiccy6.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Feb 2011, #06; Sun, 27)","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2011-03-02T07:17:38Z","receivedAt":"2011-03-02T07:17:38Z","isPatch":false,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"On Wed, Mar 2, 2011 at 6:24 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Jeff King <peff@peff.net> writes:\n>>   - Nit: you nicely use \"%d commit%s\" to handle the single/plural case\n>>     in the warning message, but then you \"them\" later on. It needs\n>>     (1 < lost) ? \"them\" : \"it\".\n>\n> I actually don't like playing games like that, especially when i18n topic\n> is in flight.  Among the languages I know rules reasonably well, two has\n> the rule that a countable noun is spelled differently depending on the\n> number of that thing is one or more, and one spells the noun the same way\n> regardless of the number.  Who knows if git needs to be translated into a\n> language whose noun changes its shape three-way, depending on the number\n> being one, two, or more?\n\nFor gettex this is described at\nhttp://www.gnu.org/software/gettext/manual/gettext.html#Plural-forms\n\nDon't know how it's handled in shell scripts or perl or whatever other\nlanguage (which does not use gettext?)\n\n\n-- \nPiotrek\n"},{"id":"162629","messageId":"m3k4gh7r0m.fsf@localhost.localdomain","threadId":"26617","inReplyTo":"AANLkTi=+iBR3OBZ=4fi_g=JMQKi=47F47hRsWxK=RbMv@mail.gmail.com","subject":"Re: What's cooking in git.git (Feb 2011, #06; Sun, 27)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-03-02T10:32:23Z","receivedAt":"2011-03-02T10:32:23Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Piotr Krukowiecki <piotr.krukowiecki@gmail.com> writes:\n> On Wed, Mar 2, 2011 at 6:24 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Jeff King <peff@peff.net> writes:\n\n>>>   - Nit: you nicely use \"%d commit%s\" to handle the single/plural case\n>>>     in the warning message, but then you \"them\" later on. It needs\n>>>     (1 < lost) ? \"them\" : \"it\".\n>>\n>> I actually don't like playing games like that, especially when i18n topic\n>> is in flight.  Among the languages I know rules reasonably well, two has\n>> the rule that a countable noun is spelled differently depending on the\n>> number of that thing is one or more, and one spells the noun the same way\n>> regardless of the number.  Who knows if git needs to be translated into a\n>> language whose noun changes its shape three-way, depending on the number\n>> being one, two, or more?\n\nWell, one of such languages with spelling depending in number of\nthings is Russian, for which we have translation for git-gui, so\nI guess somebody would add one for git itself.\n \n> For gettex this is described at\n> http://www.gnu.org/software/gettext/manual/gettext.html#Plural-forms\n\nWhich includes example for Polish language:\n\n    1 file       =  1 plik\n    2,3,4 files  =  2,3,4 pliki\n    5-21 files   =  5-21  plików\n    22-24 files  =  22-24 pliki\n    25-31 files  =  25-31 plików\n    and so on\n\n  [...]  \n  \n  Three forms, special case for one and some numbers ending in 2, 3, or 4\n     The header entry would look like this:\n\n          Plural-Forms: nplurals=3; \\\n              plural=n==1 ? 0 : \\\n                     n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n\n     Languages with this property include:\n\n     Slavic family\n          Polish\n\n \n> Don't know how it's handled in shell scripts or perl or whatever other\n> language (which does not use gettext?)\n\nBoth shell scripts and Perl scripts would use gettext: gettext.sh for\nshell, Locale::Messages for Perl (we need lower level than Text::Domain,\nand Locale::Maketext is first no longer recommended, and second does\nnot use gettext at least by default).\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"162674","messageId":"20110302212724.GE20400@sigill.intra.peff.net","threadId":"26617","inReplyTo":"7vlj0yff6m.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Feb 2011, #06; Sun, 27)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-02T21:27:24Z","receivedAt":"2011-03-02T21:27:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 01, 2011 at 06:07:29PM -0800, Junio C Hamano wrote:\n\n> > On Mon, Feb 28, 2011 at 08:52:08AM -0800, Junio C Hamano wrote:\n> >\n> >> I am not convinced that this patch nailed that balance at exactly the\n> >> right place, even though I think we are getting closer than before.  In\n> >> this sequence:\n> >> \n> >>     $ git checkout somewhere^0\n> >>     $ git commit\n> >>     $ git reset --hard somewhere_else\n> >>     $ git commit\n> >>     $ git checkout master\n> >> ...\n> > I really wouldn't expect it to help here. The problem isn't that you're\n> > on a detached HEAD. It's that you're using \"git reset\" at all.\n> \n> As you would realize later in your message, the \"reset --hard\" can instead\n> be \"checkout v1.7.3\".  And the bothersome thing is that there is no safety\n> against that.  We don't bother users while they are jumping around on\n> detached HEAD, and it is not new; we don't say where the previous detached\n> HEAD was.\n\nNo, \"checkout v1.7.3\" should engage the safety valve. And in your patch,\nit does. So replacing your reset --hard with checkout _is_ safe. And I\nthink that behavior is reasonable. Reset's purpose is about shifting\nHEAD to drop history, whether you are on a detached HEAD or not. Having\nit warn would be annoying and pointless.\n\nCheckout, on the other hand, is about moving your working tree to a\ndifferent place in history, and we _should_ warn about dropping history.\nSo it is really just a matter of educating users to use the appropriate\ntool for sight-seeing (and I don't think there is much education to be\ndone; checkout seems like the obvious choice given it is how you got to\nthe first commit).\n\n-Peff\n"},{"id":"162675","messageId":"20110302212824.GF20400@sigill.intra.peff.net","threadId":"26617","inReplyTo":"7vwrkiccy6.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Feb 2011, #06; Sun, 27)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-02T21:28:24Z","receivedAt":"2011-03-02T21:28:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 01, 2011 at 09:24:01PM -0800, Junio C Hamano wrote:\n\n> >   - Nit: you nicely use \"%d commit%s\" to handle the single/plural case\n> >     in the warning message, but then you \"them\" later on. It needs\n> >     (1 < lost) ? \"them\" : \"it\".\n> \n> I actually don't like playing games like that, especially when i18n topic\n> is in flight.  Among the languages I know rules reasonably well, two has\n> the rule that a countable noun is spelled differently depending on the\n> number of that thing is one or more, and one spells the noun the same way\n> regardless of the number.  Who knows if git needs to be translated into a\n> language whose noun changes its shape three-way, depending on the number\n> being one, two, or more?\n\nOK, I am showing my English-centric ignorance then, I think. :) I will\nleave that topic for the i18n people to deal with.\n\n-Peff\n"},{"id":"163125","messageId":"AANLkTikD2M=33B9E2mpBEmT5rLsZHPFc-T5Yqp3EMRJx@mail.gmail.com","threadId":"26617","inReplyTo":"m3k4gh7r0m.fsf@localhost.localdomain","subject":"Re: What's cooking in git.git (Feb 2011, #06; Sun, 27)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2011-03-10T09:44:31Z","receivedAt":"2011-03-10T09:44:31Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Mar 2, 2011 at 11:32, Jakub Narebski <jnareb@gmail.com> wrote:\n> Piotr Krukowiecki <piotr.krukowiecki@gmail.com> writes:\n>> Don't know how it's handled in shell scripts or perl or whatever other\n>> language (which does not use gettext?)\n>\n> Both shell scripts and Perl scripts would use gettext: gettext.sh for\n> shell, Locale::Messages for Perl (we need lower level than Text::Domain,\n> and Locale::Maketext is first no longer recommended, and second does\n> not use gettext at least by default).\n\nThe i18n series uses Locale::Maketext:\nhttps://github.com/avar/git/blob/ab%2Fi18n/perl/Git/I18N.pm\n\nWhat do you mean it's not recommended? There are some articles about\nPerl i18n saying you shouldn't use it, effectively because:\n\n * Building GNU gettext is hard, let's go shopping.\n\n * There were some bugs in it, which do not apply to us.\n\nSo using it is fine. I might still write some Gettext::XS::Tiny module\nthat works with both GNU gettext and Solaris, stick it on the CPAN and\nmake us depend on it. It would more closely align with what we\nneed. But that's something for the far future.\n"},{"id":"163154","messageId":"201103101737.32237.jnareb@gmail.com","threadId":"26617","inReplyTo":"AANLkTikD2M=33B9E2mpBEmT5rLsZHPFc-T5Yqp3EMRJx@mail.gmail.com","subject":"Re: What's cooking in git.git (Feb 2011, #06; Sun, 27)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-03-10T16:37:29Z","receivedAt":"2011-03-10T16:37:29Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Thu, 10 Mar 2011, Ævar Arnfjörð Bjarmason wrote:\n> On Wed, Mar 2, 2011 at 11:32, Jakub Narebski <jnareb@gmail.com> wrote:\n> > Piotr Krukowiecki <piotr.krukowiecki@gmail.com> writes:\n\n> > > Don't know how it's handled in shell scripts or perl or whatever other\n> > > language (which does not use gettext?)\n> >\n> > Both shell scripts and Perl scripts would use gettext: gettext.sh for\n> > shell, Locale::Messages for Perl (we need lower level than Text::Domain,\n> > and Locale::Maketext is first no longer recommended, and second does\n> > not use gettext at least by default).\n> \n> The i18n series uses Locale::Maketext:\n> https://github.com/avar/git/blob/ab%2Fi18n/perl/Git/I18N.pm\n\nIf I remember correctly previous version (maybe a few iterations in\nthe back) used Locale::Messages for Perl i18n, isn't it?\n\n> What do you mean it's not recommended? There are some articles about\n> Perl i18n saying you shouldn't use it, effectively because:\n> \n>  * Building GNU gettext is hard, let's go shopping.\n\nGit would use gettext for C and shell anyway, so this doesn't apply.\n\n>  * There were some bugs in it, which do not apply to us.\n\n   * Gettext support for plural forms etc. (ngettext) is better\n     and easier to use for translators; Locale::Maketext requires one to\n     be a programmer.\n\n> So using it is fine. I might still write some Gettext::XS::Tiny module\n> that works with both GNU gettext and Solaris, stick it on the CPAN and\n> make us depend on it. It would more closely align with what we\n> need. But that's something for the far future.\n\nThe Perl Journal article on using Locale::Maketext is supposedly outdated,\nsee http://rassie.org/archives/247 (On the state of i18n in Perl) from 2009.\n\n<blockquote>\n  One basic, but fatal, mistake Maketext does is off-loading a lot of\n  linguistic work onto programmer.\n\n    * One particularly important point is the plural forms support ('1 apple',\n      '2 apples'), which is important for many languages outside of USA and\n      Western Europe . Maketext requires you to write a quant function that\n      gets a string and a number as parameters and does some voodoo to\n      produce the right string. Voodoo is undefined. In gettext it is --\n      a formula for producing plural forms is defined which selects one of\n      provided plural phrases.\n\n    * No translator in his sane mind will ever write a Perl module for a\n      language (they aren't programmers, remember?), the programmer will\n      have to do it and will also have to understand the implications.\n\n    * The quant notation (\"Your search matched [quant,_1,document]!\")\n      foolishly assumes word order is the same in all languages.\n      Implementing a quant method properly would require passing the whole\n      sentence into the function and doing a complete linguistic\n      transformation which is highly non-trivial and better done by human.\n\n    * Most of those linguistic “conventions” like number formatting or\n      plural forms do not change over time and can be compiled at one place.\n      One such place is Unicode’s CLDR project, which also includes plural\n      form building and number/date formatting among other country- and\n      language-dependant data.\n\n    * It can’t even be assumed that the translators actually know all of\n      these conventions! They might assume they know them, but translator\n      is not necessarily doing translations for a living, he might be a\n      volunteer, like in most open source projects. Imagine what happens\n      when an amateur translator explains the inner workings of his native\n      language to a programmer?\n\n</blockquote>\n-- \nJakub Narebski\nPoland\n"}]}