{"thread":{"id":"26371","subject":"What's cooking in git.git (Jan 2011, #06; Sun, 30)","startedAt":"2011-01-31T05:53:11Z","lastAt":"2011-02-24T23:44:41Z","messageCount":126,"participants":["Junio C Hamano","Sverre Rabbelier","Jeff King","Nicolas Pitre","Felipe Contreras","Matthieu Moy","Thomas Rast","Jakub Narebski","Eugene Sajine","João P. Sampaio","Dmitry Potapov","Thomas Adam","Alex Budovski","Erik Faye-Lund","Nguyen Thai Ngoc Duy","Jay Soffian","Andreas Ericsson","Marc Branchaud","Scott Chacon","René Scharfe","Jonathan Nieder","A Large Angry SCM","Jens Lehmann","J.H.","Vincent Hanquez","Shawn Pearce","David Aguilar","Sam Vilain","Wesley J. Landaker","Thomas Hochstein","Joey Hess","Jared Hance","Martin von Zweigbergk","david@lang.hm","Pete Harlan","Thomas Koch","Pat Notz"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"160085","messageId":"7vzkqh8vqw.fsf@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":null,"subject":"What's cooking in git.git (Jan 2011, #06; Sun, 30)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-31T05:53:11Z","receivedAt":"2011-01-31T05:53:11Z","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\n1.7.4 is out. I'd like to stop and calm the tree down for a few days\nso that we can catch any brown-paper-bag bugs before moving things\nforward, and then open the floodgate for the next cycle, which I am\ninclined to designate as \"We would have done these differently if we\nwere creating git from scratch with the experience we have and wisdom\nwe have gained\" cycle, allowing minor backward incompatibilities,\nsomewhat like 1.6.0 but not so drastic.  The result would probably\nbe called 1.8.0--the details in a separate message.\n\n--------------------------------------------------\n[New Topics]\n\n* jc/fsck-fixes (2011-01-26) 2 commits\n - fsck: do not give up too early in fsck_dir()\n - fsck: drop unused parameter from traverse_one_object()\n\n--------------------------------------------------\n[Stalled]\n\n* nd/index-doc (2010-09-06) 1 commit\n - doc: technical details about the index file format\n\nHalf-written but it is a good start.  I may need to give some help in\ndescribing more recent index extensions.\n\n* cb/ignored-paths-are-precious (2010-08-21) 1 commit\n - checkout/merge: optionally fail operation when ignored files need to be overwritten\n\nThis needs tests; also we know of longstanding bugs in related area that\nneeds to be addressed---they do not have to be part of this series but\ntheir reproduction recipe would belong to the test script for this topic.\n\nIt would hurt users to make the new feature on by default, especially the\nones with subdirectories that come and go.\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\nIIRC, this was a weather-baloon \"if you wanted to, this may be how you\nwould do it\" without test updates.  People who care need to help moving\nthings forward.\n\n* jc/rerere-remaining (2011-01-06) 1 commit\n - rerere \"remaining\"\n\nJust a handful of weatherballoon patches without proper tests, in response\nto feature/minor fix requests.\n\n* ab/p4 (2011-01-11) 1 commit\n - git-p4: correct indenting and formatting\n\nLacks sign-off but is trivial.\n\n* tr/maint-branch-no-track-head (2010-12-14) 1 commit\n - branch: do not attempt to track HEAD implicitly\n\nProbably needs a re-roll to exclude either (1) any ref outside the\nhierarchies for branches (i.e. refs/{heads,remotes}/), or (2) only refs\noutside refs/ hierarchies (e.g. HEAD, ORIG_HEAD, ...).  The latter feels\nsafer and saner.\n\n* hv/mingw-fs-funnies (2010-12-14) 5 commits\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\nWill be rerolled (Heiko, 2010-12-23)\n\n* mz/rebase (2010-12-28) 31 commits\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\nWill be rerolled (Martin, Jan 28).\n\n--------------------------------------------------\n[Cooking]\n\n* jn/unpack-lstat-failure-report (2011-01-12) 2 commits\n  (merged to 'next' on 2011-01-24 at 1245180)\n + unpack-trees: handle lstat failure for existing file\n + unpack-trees: handle lstat failure for existing directory\n\n* rr/fi-import-marks-if-exists (2011-01-15) 1 commit\n - fast-import: Introduce --import-marks-if-exists\n\nLooked reasonable.\n\n* tr/diff-words-test (2011-01-18) 4 commits\n - t4034 (diff --word-diff): add a minimum Perl drier test vector\n - t4034 (diff --word-diff): style suggestions\n - userdiff: simplify word-diff safeguard\n - t4034: bulk verify builtin word regex sanity\n\nI thought this was Ok; further comments, anybody?\n\n* ef/alias-via-run-command (2011-01-07) 1 commit\n  (merged to 'next' on 2011-01-06 at 1fbd4a0)\n + alias: use run_command api to execute aliases\n\n* uk/checkout-ambiguous-ref (2011-01-11) 1 commit\n  (merged to 'next' on 2011-01-11 at 2aa30de)\n + checkout: fix bug with ambiguous refs\n\n* cb/setup (2010-12-27) 1 commit\n  (merged to 'next' on 2011-01-05 at 790b288)\n + setup: translate symlinks in filename when using absolute paths\n\n* ae/better-template-failure-report (2010-12-18) 1 commit\n  (merged to 'next' on 2011-01-05 at d3f9142)\n + Improve error messages when temporary file creation fails\n\n* jc/unpack-trees (2010-12-22) 2 commits\n - unpack_trees(): skip trees that are the same in all input\n - unpack-trees.c: cosmetic fix\n\n* jn/cherry-pick-strategy-option (2010-12-10) 1 commit\n  (merged to 'next' on 2011-01-05 at 3ccc590)\n + cherry-pick/revert: add support for -X/--strategy-option\n\n* nd/struct-pathspec (2010-12-15) 21 commits\n  (merged to 'next' on 2011-01-24 at 08f1774)\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.)\n\n* en/object-list-with-pathspec (2010-09-20) 2 commits\n  (merged to 'next' on 2011-01-24 at 134f65c)\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.)\n\nI've been toying with the above two topics and am reasonably happy.\nI suspect that there could be (and probably need to be) further\nconsolidation of the two remaining pathspec API, but this seems to\nbe already usable.\n\n* tr/merge-unborn-clobber (2010-08-22) 1 commit\n - Exhibit merge bug that clobbers index&WT\n\n* ab/i18n (2010-10-07) 161 commits\n - po/de.po: complete German translation\n - po/sv.po: add Swedish translation\n - gettextize: git-bisect bisect_next_check \"You need to\" message\n - gettextize: git-bisect [Y/n] messages\n - gettextize: git-bisect bisect_replay + $1 messages\n - gettextize: git-bisect bisect_reset + $1 messages\n - gettextize: git-bisect bisect_run + $@ messages\n - gettextize: git-bisect die + eval_gettext messages\n - gettextize: git-bisect die + gettext messages\n - gettextize: git-bisect echo + eval_gettext message\n - gettextize: git-bisect echo + gettext messages\n - gettextize: git-bisect gettext + echo message\n - gettextize: git-bisect add git-sh-i18n\n - gettextize: git-stash drop_stash say/die messages\n - gettextize: git-stash \"unknown option\" message\n - gettextize: git-stash die + eval_gettext $1 messages\n - gettextize: git-stash die + eval_gettext $* messages\n - gettextize: git-stash die + eval_gettext messages\n - gettextize: git-stash die + gettext messages\n - gettextize: git-stash say + gettext messages\n - gettextize: git-stash echo + gettext message\n - gettextize: git-stash add git-sh-i18n\n - gettextize: git-submodule \"blob\" and \"submodule\" messages\n - gettextize: git-submodule \"path not initialized\" message\n - gettextize: git-submodule \"[...] path is ignored\" message\n - gettextize: git-submodule \"Entering [...]\" message\n - gettextize: git-submodule $errmsg messages\n - gettextize: git-submodule \"Submodule change[...]\" messages\n - gettextize: git-submodule \"cached cannot be used\" message\n - gettextize: git-submodule $update_module say + die messages\n - gettextize: git-submodule die + eval_gettext messages\n - gettextize: git-submodule say + eval_gettext messages\n - gettextize: git-submodule echo + eval_gettext messages\n - gettextize: git-submodule add git-sh-i18n\n - gettextize: git-pull \"rebase against\" / \"merge with\" messages\n - gettextize: git-pull \"[...] not currently on a branch\" message\n - gettextize: git-pull \"You asked to pull\" message\n - gettextize: git-pull split up \"no candidate\" message\n - gettextize: git-pull eval_gettext + warning message\n - gettextize: git-pull eval_gettext + die message\n - gettextize: git-pull die messages\n - gettextize: git-pull add git-sh-i18n\n - gettext docs: add \"Testing marked strings\" section to po/README\n - gettext docs: the Git::I18N Perl interface\n - gettext docs: the git-sh-i18n.sh Shell interface\n - gettext docs: the gettext.h C interface\n - gettext docs: add \"Marking strings for translation\" section in po/README\n - gettext docs: add a \"Testing your changes\" section to po/README\n - po/pl.po: add Polish translation\n - po/hi.po: add Hindi Translation\n - po/en_GB.po: add British English translation\n - po/de.po: add German translation\n - Makefile: only add gettext tests on XGETTEXT_INCLUDE_TESTS=YesPlease\n - gettext docs: add po/README file documenting Git's gettext\n - gettextize: git-am printf(1) message to eval_gettext\n - gettextize: git-am core say messages\n - gettextize: git-am \"Apply?\" message\n - gettextize: git-am clean_abort messages\n - gettextize: git-am cannot_fallback messages\n - gettextize: git-am die messages\n - gettextize: git-am eval_gettext messages\n - gettextize: git-am multi-line getttext $msg; echo\n - gettextize: git-am one-line gettext $msg; echo\n - gettextize: git-am add git-sh-i18n\n - gettext tests: add GETTEXT_POISON tests for shell scripts\n - gettext tests: add GETTEXT_POISON support for shell scripts\n - Makefile: MSGFMT=\"msgfmt --check\" under GNU_GETTEXT\n - Makefile: add GNU_GETTEXT, set when we expect GNU gettext\n - gettextize: git-shortlog basic messages\n - gettextize: git-revert split up \"could not revert/apply\" message\n - gettextize: git-revert literal \"me\" messages\n - gettextize: git-revert \"Your local changes\" message\n - gettextize: git-revert basic messages\n - gettextize: git-notes \"Refusing to %s notes in %s\" message\n - gettextize: git-notes GIT_NOTES_REWRITE_MODE error message\n - gettextize: git-notes basic commands\n - gettextize: git-gc \"Auto packing the repository\" message\n - gettextize: git-gc basic messages\n - gettextize: git-describe basic messages\n - gettextize: git-clean clean.requireForce messages\n - gettextize: git-clean basic messages\n - gettextize: git-bundle basic messages\n - gettextize: git-archive basic messages\n - gettextize: git-status \"renamed: \" message\n - gettextize: git-status \"Initial commit\" message\n - gettextize: git-status \"Changes to be committed\" message\n - gettextize: git-status shortstatus messages\n - gettextize: git-status \"nothing to commit\" messages\n - gettextize: git-status basic messages\n - gettextize: git-push \"prevent you from losing\" message\n - gettextize: git-push basic messages\n - gettextize: git-tag tag_template message\n - gettextize: git-tag basic messages\n - gettextize: git-reset \"Unstaged changes after reset\" message\n - gettextize: git-reset reset_type_names messages\n - gettextize: git-reset basic messages\n - gettextize: git-rm basic messages\n - gettextize: git-mv \"bad\" messages\n - gettextize: git-mv basic messages\n - gettextize: git-merge \"Wonderful\" message\n - gettextize: git-merge \"You have not concluded your merge\" messages\n - gettextize: git-merge \"Updating %s..%s\" message\n - gettextize: git-merge basic messages\n - gettextize: git-log \"--OPT does not make sense\" messages\n - gettextize: git-log basic messages\n - gettextize: git-grep \"--open-files-in-pager\" message\n - gettextize: git-grep basic messages\n - gettextize: git-fetch split up \"(non-fast-forward)\" message\n - gettextize: git-fetch update_local_ref messages\n - gettextize: git-fetch formatting messages\n - gettextize: git-fetch basic messages\n - gettextize: git-diff basic messages\n - gettextize: git-commit advice messages\n - gettextize: git-commit \"enter the commit message\" message\n - gettextize: git-commit print_summary messages\n - gettextize: git-commit formatting messages\n - gettextize: git-commit \"middle of a merge\" message\n - gettextize: git-commit basic messages\n - gettextize: git-checkout \"Switched to a .. branch\" message\n - gettextize: git-checkout \"HEAD is now at\" message\n - gettextize: git-checkout describe_detached_head messages\n - gettextize: git-checkout: our/their version message\n - gettextize: git-checkout basic messages\n - gettextize: git-branch \"(no branch)\" message\n - gettextize: git-branch \"git branch -v\" messages\n - gettextize: git-branch \"Deleted branch [...]\" message\n - gettextize: git-branch \"remote branch '%s' not found\" message\n - gettextize: git-branch basic messages\n - gettextize: git-add refresh_index message\n - gettextize: git-add \"remove '%s'\" message\n - gettextize: git-add \"pathspec [...] did not match\" message\n - gettextize: git-add \"Use -f if you really want\" message\n - gettextize: git-add \"no files added\" message\n - gettextize: git-add basic messages\n - gettextize: git-clone \"Cloning into\" message\n - gettextize: git-clone basic messages\n - gettext tests: test message re-encoding under C\n - po/is.po: add Icelandic translation\n - gettext tests: mark a test message as not needing translation\n - gettext tests: test re-encoding with a UTF-8 msgid under Shell\n - gettext tests: test message re-encoding under Shell\n - gettext tests: add detection for is_IS.ISO-8859-1 locale\n - gettext tests: test if $VERSION exists before using it\n - gettextize: git-init \"Initialized [...] repository\" message\n - gettextize: git-init basic messages\n - gettext tests: skip lib-gettext.sh tests under GETTEXT_POISON\n - gettext tests: add GETTEXT_POISON=YesPlease Makefile parameter\n - gettext.c: use libcharset.h instead of langinfo.h when available\n - gettext.c: work around us not using setlocale(LC_CTYPE, \"\")\n - builtin.h: Include gettext.h\n - Makefile: use variables and shorter lines for xgettext\n - Makefile: tell xgettext(1) that our source is in UTF-8\n - Makefile: provide a --msgid-bugs-address to xgettext(1)\n - Makefile: A variable for options used by xgettext(1) calls\n - gettext tests: locate i18n lib&data correctly under --valgrind\n - gettext: setlocale(LC_CTYPE, \"\") breaks Git's C function assumptions\n - gettext tests: rename test to work around GNU gettext bug\n - gettext: add infrastructure for translating Git with gettext\n - builtin: use builtin.h for all builtin commands\n - tests: use test_cmp instead of piping to diff(1)\n - t7004-tag.sh: re-arrange git tag comment for clarity\n\nIt is getting ridiculously painful to keep re-resolving the conflicts with\nother topics in flight, even with the help with rerere.\n\nNeeds a bit more minor work to get the basic code structure right.\n"},{"id":"160094","messageId":"AANLkTik4jZWLt6T-SwMgK94FJ77ujyUC4-oFD46-eqN=@mail.gmail.com","threadId":"26371","inReplyTo":"7vzkqh8vqw.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jan 2011, #06; Sun, 30)","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-01-31T15:08:09Z","receivedAt":"2011-01-31T15:08:09Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Jan 31, 2011 at 06:53, Junio C Hamano <gitster@pobox.com> wrote:\n> 1.7.4 is out. I'd like to stop and calm the tree down for a few days\n> so that we can catch any brown-paper-bag bugs before moving things\n> forward, and then open the floodgate for the next cycle, which I am\n> inclined to designate as \"We would have done these differently if we\n> were creating git from scratch with the experience we have and wisdom\n> we have gained\" cycle, allowing minor backward incompatibilities,\n> somewhat like 1.6.0 but not so drastic.  The result would probably\n> be called 1.8.0--the details in a separate message.\n\nNice, is this based on the topics that are currently cooking, or on\npeople having indicated an intent to submit such patches?\n\n\n\nNow that we're past 1.7.4., perhaps it's time to resurrect a dead\nthread. From a past \"What's cooking\":\n\nOn Tue, Dec 14, 2010 at 03:20, Junio C Hamano <gitster@pobox.com> wrote:\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>\n>> On Mon, Dec 13, 2010 at 09:34, Junio C Hamano <gitster@pobox.com> wrote:\n>>\n>>> Needs a bit more minor work to get the basic code structure right.\n>>\n>> And I'm still not sure (see earlier replies to \"What's Cooking\" posts)\n>> what needs to be done to make it better.\n>\n> One open question was why you do not want to move 'LIB_OBJS += gettext.o'\n> away from the LIB_OBJS section down to the configuration evaluation\n> section, i.e., why gettext.o would be different from block-sha1/sha1.o.\n\nÆvar, you didn't respond to that message. Junio, do I understand\ncorrectly that if this problem is addressed the topic is ready to be\nmerged to next?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"160098","messageId":"7vwrll57ha.fsf@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"7vzkqh8vqw.fsf@alter.siamese.dyndns.org","subject":"Planning for 1.7.5 and 1.8.0","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-31T17:05:37Z","receivedAt":"2011-01-31T17:05:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Now the 1.7.4 release is out, I'd like people to help thinking about the\nnext cycle(s).\n\nAs a discussion-starter, here are my random wishes.  Even though this does\nnot attempt to be exhaustive, keeping the number of goals manageably small\nmay help us focus.\n\n * The i18n effort Ævar Arnfjörð Bjarmason started two cycles ago has\n   stalled. If enough people feel i18n's Porcelain UI is worth having, I\n   think we would need a brief calming period in the entire tree in order\n   for us to get the minimum support (definition of _() macro that is\n   empty is a good start) and _() mark-up of existing strings in, and then\n   ask everybody to rebase their ongoing work on top of it.\n\n * There was a discussion on documentation updates to reduce \"here we tell\n   you only the basics; see elsewhere for details\", and consolidating the\n   description of configuration options in one place.\n\n * Nguyễn has been scratching my longstanding itch by attempting to unify\n   two pathspec semantics (the ones based on tree-diff matches only\n   leading path while others know globs) to reduce inconsistencies. I\n   would really want to see this polished and in the main release.\n\n * Elijah's fix to \"rev-list --objects\", together with the updated\n   pathspec semantics will allow us to cleanly implement narrow cloning\n   (possibly deprecating and replacing the narrow checkout in the\n   future).  I am hoping that we can lay groundwork on this inside one\n   cycle and the initial end-to-end implementation in another.\n\n * Shawn Pearce says that the diff implementation JGit uses (histogram\n   diff) performs way better than the xdiff implementation we use by\n   default. It would be great if somebody can spend time taking a look at\n   it and possibly port it back to C-git.\n\n\nOver the time we have discussed minor glitches and inconsistencies that we\nall (or at least most of us anyway) agreed we would have done differently\nif we were writing Git from scratch, yet we cannot retroactively introduce\ndifferences not to harm existing users.  We may also want to revisit these\ndiscussions during this round--if there are reasonable number of them that\nwe can agree the benefit of tweaked semantics/behaviour outweighs the risk\nof breaking and having to update ancient scripts that exploited obscure\ncorner case behaviour of Git, we would want warn the users loudly, bite\nthe bullet and break them so that we can move forward.  We would however\nneed to roll such potentially disruptive changes into a big single cycle,\nlike we did in 1.6.0.\n\nI'll follow-up this message with a couple of example proposals.  Please\nsend your own, imitating the format of the message, as a reply to this\nmessage.  Do not forget to retitle your message when you do so (iow, I\ndon't want to see \"Re: Planning for 1.7.5 and 1.8.0\").\n\nThanks.\n"},{"id":"160099","messageId":"7vsjw957fq.fsf_-_@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"7vwrll57ha.fsf@alter.siamese.dyndns.org","subject":"[1.8.0] default \"git merge\" without argument to \"git merge @{u}\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-31T17:06:33Z","receivedAt":"2011-01-31T17:06:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Proposal:\n\nCurrently \"git merge\" without saying what to merge is a no-op, and\nsucceeds silently.  As many downstream developers (that are by definition\nmore numerous than people who do not have \"upstream\") run merge from the\nconfigured upstream of the current branch most of the time, it would make\nit more convenient for them to change the default to merge from the\nupstream of the current branch.  Running \"git merge\" without argument,\nwhen there is no upstream defined for the current branch, will be an\nerror.\n\nRisks:\n\nExisting scripts may prepare what to merge in an array (e.g. in Bourne,\naccumulating them in \"$@\" by repeatedly doing 'set \"$@\" \"$newbranch\"') and\ncall 'git merge \"$@\"', relying on the current behaviour that zero argument\nmeans no-op.  Such scripts will be broken by this change.  Driving \"git\nmerge\" with xargs without --no-run-if-empty (not POSIX), feeding the\nbranches to merge in an Octopus, will be broken the same way.\n\nMigration plan:\n\nAdd merge.defaultUpstream configuration variable, which defaults to false\nwhen unconfigured.  Change \"git merge\" so that when this configuration is\nset and the command is run without the commit to merge to use the\nconfigured upstream of the current branch (or error out if there isn't\none).  Merge this change in the next 1.7.x series.\n\nOne release before 1.8.0, issue a warning when \"git merge\" is run without\nthe commit to merge and this configuration variable is not explicitly set\neither way, and notify the user of upcoming incompatibility.\n\nIn 1.8.0, flip the default for merge.defaultUpstream to true.\n"},{"id":"160100","messageId":"7voc6x57el.fsf_-_@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"7vwrll57ha.fsf@alter.siamese.dyndns.org","subject":"[1.8.0] Unify \"pathspec\" semantics","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-31T17:07:14Z","receivedAt":"2011-01-31T17:07:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Proposal:\n\nTraditionally, Git had two distinct semantics for pathspecs.  Anything\nbased on tree-diff (i.e. \"log\" family of commands when limiting the\nhistory by paths or \"diff\" family of commands limiting the output) used\n\"leading paths match\" without globbing support.  All others (e.g. \"grep\",\n\"ls-files\") supported globbing.  This resulted in subtly inconsistent\nbehaviour when one part of the program collected paths from the index and\nthe working tree while another part of the program used differences\nbetween the index and the HEAD, e.g. \"git add\".  Unify \"pathspec\"\nsemantics to make all of them learn the globbing.\n\nRisks:\n\nIf coded poorly, performance bugs can be introduced to the tree-diff\ncodepath, making it inefficient.\n\nSome projects may track a file whose name is asterisk (e.g. \"foo/*\") and\noutput from \"git log 'foo/*'\" would look different.  Before the change,\nonly commits that touch that exact path would be shown, but after the\nchange, any commit that touch a path underneath \"foo/\" directory will be\nshown.  This is a backward incompatible change.\n\nMigration plan:\n\nWe could conditionally enable globbing support when implementing unified\npathspec API, default to the traditional and inconsisntent behaviour\nduring the 1.7.x series, and flip the default to accept globs everwhere in\nthe 1.8.0 release.  Practically, however, nobody sane would track paths\nthat have shell metacharacters in them, so we may not need to do the usual\n\"introduce as an opt-in, warn about incompatibility, and flip the default\"\nmigration.\n"},{"id":"160108","messageId":"20110131201419.GA9070@sigill.intra.peff.net","threadId":"26371","inReplyTo":"7vsjw957fq.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [1.8.0] default \"git merge\" without argument to \"git merge @{u}\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-01-31T20:14:19Z","receivedAt":"2011-01-31T20:14:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 31, 2011 at 09:06:33AM -0800, Junio C Hamano wrote:\n\n> Existing scripts may prepare what to merge in an array (e.g. in Bourne,\n> accumulating them in \"$@\" by repeatedly doing 'set \"$@\" \"$newbranch\"') and\n> call 'git merge \"$@\"', relying on the current behaviour that zero argument\n> means no-op.  Such scripts will be broken by this change.  Driving \"git\n> merge\" with xargs without --no-run-if-empty (not POSIX), feeding the\n> branches to merge in an Octopus, will be broken the same way.\n\nI am not sure these things are not already broken. \"git merge\" without\narguments right now is not a no-op. It is an error that spews usage to\nstderr and exits 129. Yes, there can be scripts which stupidly do not\nbother to see if the merge succeeded, but I'm not sure how much we\nshould care about such poorly written junk.\n\n> Migration plan:\n> \n> Add merge.defaultUpstream configuration variable, which defaults to false\n> when unconfigured.  Change \"git merge\" so that when this configuration is\n> set and the command is run without the commit to merge to use the\n> configured upstream of the current branch (or error out if there isn't\n> one).  Merge this change in the next 1.7.x series.\n\nOne nit: upon reading the name of the variable, I assumed it would be\n\"the default upstream to merge\". Perhaps \"merge.defaultToUpstream\" is a\nmore descriptive name?\n\n> One release before 1.8.0, issue a warning when \"git merge\" is run without\n> the commit to merge and this configuration variable is not explicitly set\n> either way, and notify the user of upcoming incompatibility.\n\nDon't we already issue a giant warning when \"git merge\" is run without a\ncommit, namely:\n\n  usage: git merge [options] <remote>...\n  ... etc ...\n\n? If people are already not paying attention to that (either because\nthey are throwing away stderr and exit code indiscriminately, or because\nthe no-arguments case is a simply an obscure corner that their script\ndoesn't usually exercise), why would they pay attention to a new\nwarning?\n\n> In 1.8.0, flip the default for merge.defaultUpstream to true.\n\nOther than that, I think the proposal and migration plan are fine.\n\n-Peff\n"},{"id":"160109","messageId":"7vaaig6d64.fsf@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"20110131201419.GA9070@sigill.intra.peff.net","subject":"Re: [1.8.0] default \"git merge\" without argument to \"git merge @{u}\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-31T20:17:23Z","receivedAt":"2011-01-31T20:17:23Z","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>> In 1.8.0, flip the default for merge.defaultUpstream to true.\n>\n> Other than that, I think the proposal and migration plan are fine.\n\nHeh, thanks.\n\nIt's not my proposal though ;-).  It is just an illustration of how I see\nan item from people's wishlist should look like to make it easier to\ndiscuss them.\n"},{"id":"160111","messageId":"alpine.LFD.2.00.1101311459000.8580@xanadu.home","threadId":"26371","inReplyTo":"7vwrll57ha.fsf@alter.siamese.dyndns.org","subject":"[1.8.0] reorganize the mess that the source tree has become","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-01-31T20:28:37Z","receivedAt":"2011-01-31T20:28:37Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"To me the source tree looks highly untidy to me.\n\nWe do have subdirectories for documentation, tests, contributions, etc.  \nBut a sizeable part of the tree is just a big splat of source files \ndumped right in the root of the tree.\n\nSo I'd suggest doing the following:\n\n1) Create a src/ directory and move *.c, *.h, *.sh, *.perl, *.py and \n   the builtin directory from the root directory to it.\n\n2) Create a build/ directory, or bin/ if prefered, to hold the result of \n   the build.\n\n3) Consider dropping the ppc/ directory.  Unless someone really cares \n   deeply, it would be nice to simply always use the block-sha1 code and \n   move it straight into src/.\n\n4) Consider moving some more directories into src/ such as xdiff/.\n   I'd leave compat/ outside src/ to make it more explicit that this is \n   not about Git proper.\n\n5) Rename t/ to testsuite/ so this doesn't look like some garbage \n   leftover.\n\n6) And fix up all the Makefiles to cope with the above movements.\n\nWhat do you think?\n\n\nNicolas\n"},{"id":"160112","messageId":"AANLkTintp8Je8msnn5X+T8MwvNjSrKm5m8KvshiWEuum@mail.gmail.com","threadId":"26371","inReplyTo":"7vaaig6d64.fsf@alter.siamese.dyndns.org","subject":"Re: [1.8.0] default \"git merge\" without argument to \"git merge @{u}\"","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-01-31T20:32:54Z","receivedAt":"2011-01-31T20:32:54Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Jan 31, 2011 at 10:17 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Jeff King <peff@peff.net> writes:\n>\n>>> In 1.8.0, flip the default for merge.defaultUpstream to true.\n>>\n>> Other than that, I think the proposal and migration plan are fine.\n>\n> Heh, thanks.\n>\n> It's not my proposal though ;-).  It is just an illustration of how I see\n> an item from people's wishlist should look like to make it easier to\n> discuss them.\n\nOk, I share the same opinion as Jeff; we should not care about scripts\ndoing something so wrong. But if the migration path is the only way to\nget the change in, I guess I can do that.\n\n-- \nFelipe Contreras\n"},{"id":"160113","messageId":"7vzkqg4x2h.fsf_-_@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"7vsjw957fq.fsf_-_@alter.siamese.dyndns.org","subject":"[1.8.0] (v2) default \"git merge\" without argument to \"git merge @{u}\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-31T20:50:30Z","receivedAt":"2011-01-31T20:50:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ok, here is an update.\n\nI wonder how we should keep track of the \"proposal\" series, though.\nSending the full-text replacement like I am doing here feels eh not\ngittish.\n\nPerhaps I should start a new directory in todo branch (say, 1.8.0), accept\npatches from people?  I'd grudgingly admit that using Wiki on k.org may be\nless burdensome (I hate editing inside the browser myself), but I'd want\nto keep the mailing list the center of discussion and am afraid that\nforcing people to go to Wiki would fragment the discussion.\n\nI dunno.\n\n--\n\nProposal:\n\nCurrently \"git merge\" without saying what to merge fails loudly.  As many\ndownstream developers (that are by definition more numerous than people\nwho do not have \"upstream\") run merge from the configured upstream of the\ncurrent branch most of the time, it would make it more convenient for them\nto change the default to merge from the upstream of the current branch.\nRunning \"git merge\" without argument, when there is no upstream defined\nfor the current branch, will be an error.\n\nRisks:\n\nExisting scripts may prepare what to merge in an array (e.g. in Bourne,\naccumulating them in \"$@\" by repeatedly doing 'set \"$@\" \"$newbranch\"') and\ncall 'git merge \"$@\"', relying on the current behaviour that zero argument\nwill flag an error condition.  Such scripts will be broken by this change.\n\nDriving \"git merge\" with xargs without --no-run-if-empty (not POSIX),\nfeeding the branches to merge in an Octopus, will be broken the same way.\n\nMigration plan:\n\nAdd merge.defaultToUpstream configuration variable, which defaults to\nfalse when unconfigured.  Change \"git merge\" so that when this variable is\nset and the command is run without the commit to merge to use the\nconfigured upstream of the current branch (or error out if there isn't one).\nMerge this change in the next 1.7.x series.\n\nUpdate the error message issued when when \"git merge\" is run without the\ncommit to merge and this configuration variable is not explicitly set\neither way to notify the user of upcoming incompatibility.\n\nIn 1.8.0, flip the default for merge.defaultUpstream to true.\n\nHelped-by: Jeff King <peff@peff.net>\n"},{"id":"160114","messageId":"7vvd144wrl.fsf@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"alpine.LFD.2.00.1101311459000.8580@xanadu.home","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-31T20:57:02Z","receivedAt":"2011-01-31T20:57:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre <nico@fluxnic.net> writes:\n\n> 1) Create a src/ directory and move *.c, *.h, *.sh, *.perl, *.py and \n>    the builtin directory from the root directory to it.\n>\n> 2) Create a build/ directory, or bin/ if prefered, to hold the result of \n>    the build.\n>...\n> 6) And fix up all the Makefiles to cope with the above movements.\n>\n> What do you think?\n\nKnee-jerk reaction: not very motivated to make the top-level directory\njust a skeleton that holds various directories with a handful of\nadministrative files like Makefile, README, etc.  Under your proposal, the\nbulk of the current content at the top would simply move to another single\ndirectory anyway, so I don't immediately see much point of such a move,\nother than adding merge burden on me and rebase burden on others, that\nis.\n\nBut that is just a knee-jerk reaction, just to fill the \"Risks:\" section\nyou didn't fill.  Your missing \"Migration Plans\" section might outline a\nclever approach to lessen the interim hurt while merging in-flight topics.\n"},{"id":"160115","messageId":"20110131210045.GB14419@sigill.intra.peff.net","threadId":"26371","inReplyTo":"alpine.LFD.2.00.1101311459000.8580@xanadu.home","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-01-31T21:00:45Z","receivedAt":"2011-01-31T21:00:45Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 31, 2011 at 03:28:37PM -0500, Nicolas Pitre wrote:\n\n> We do have subdirectories for documentation, tests, contributions, etc.  \n> But a sizeable part of the tree is just a big splat of source files \n> dumped right in the root of the tree.\n> \n> So I'd suggest doing the following:\n> \n> 1) Create a src/ directory and move *.c, *.h, *.sh, *.perl, *.py and \n>    the builtin directory from the root directory to it.\n\nWouldn't this just be the same giant splat of source files, but in a\ndifferent tree? I don't really see the advantage, and it seems like an\nextra annoyance. Besides being just one more directory to go up and\ndown, it does make history browsing more annoying. As much as I love\ngit's \"don't record renames\" philosophy, our handling of renames on the\nviewing side is often annoying. I already get annoyed sometimes\nfollowing stuff across the s!builtin-!builtin/! change. This would be\nlike that but more so.\n\nOr maybe it is a good thing for that reason, as we will eat our own\nrename dogfood. :)\n\n> 5) Rename t/ to testsuite/ so this doesn't look like some garbage \n>    leftover.\n\nUgh, more typing. :P\n\n-Peff\n"},{"id":"160116","messageId":"vpqwrlkg4r8.fsf@bauges.imag.fr","threadId":"26371","inReplyTo":"7vvd144wrl.fsf@alter.siamese.dyndns.org","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-01-31T21:08:59Z","receivedAt":"2011-01-31T21:08:59Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Knee-jerk reaction: not very motivated to make the top-level directory\n> just a skeleton that holds various directories with a handful of\n> administrative files like Makefile, README, etc.  Under your proposal, the\n> bulk of the current content at the top would simply move to another single\n> directory anyway, so I don't immediately see much point of such a move,\n\nThere would be at least one obvious benefit: currently, we have this\n\ngit$ ls | wc -l\n623\n\n(that's after a build)\n\nIt's a bit hard to find the interesting bits (README, Documentation/,\ncontrib/ for example) in the output of \"ls\".\n\n> other than adding merge burden on me and rebase burden on others, that\n> is.\n\nThat can be seen as a test of how good Git is at bulk rename\nmanagement ;-).\n\nAll that said, I cannot really say whether the benefit is higher than\nthe cost.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"160117","messageId":"alpine.LFD.2.00.1101311601370.8580@xanadu.home","threadId":"26371","inReplyTo":"7vvd144wrl.fsf@alter.siamese.dyndns.org","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-01-31T21:19:30Z","receivedAt":"2011-01-31T21:19:30Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 31 Jan 2011, Junio C Hamano wrote:\n\n> Nicolas Pitre <nico@fluxnic.net> writes:\n> \n> > 1) Create a src/ directory and move *.c, *.h, *.sh, *.perl, *.py and \n> >    the builtin directory from the root directory to it.\n> >\n> > 2) Create a build/ directory, or bin/ if prefered, to hold the result of \n> >    the build.\n> >...\n> > 6) And fix up all the Makefiles to cope with the above movements.\n> >\n> > What do you think?\n> \n> Knee-jerk reaction: not very motivated to make the top-level directory\n> just a skeleton that holds various directories with a handful of\n> administrative files like Makefile, README, etc.  Under your proposal, the\n> bulk of the current content at the top would simply move to another single\n> directory anyway, so I don't immediately see much point of such a move,\n> other than adding merge burden on me and rebase burden on others, that\n> is.\n\nI really think that the top directory is not the proper place for source \nfiles to live, especially considering how big a project Git is now.  \nThe top directory should be like a table of content and not the content \nitself.\n\nBut if you the maintainer doesn't see a long-term value in this to be \ngreater than the one-time burden, then I'm afraid there's nothing I can \ndo to help it.\n\n> But that is just a knee-jerk reaction, just to fill the \"Risks:\" section\n> you didn't fill.  Your missing \"Migration Plans\" section might outline a\n> clever approach to lessen the interim hurt while merging in-flight topics.\n\nWell, there is no such plan.  Given that 1.8 is meant to be an inflexion \npoint for users, it could as well be for developers the best time to \nclean up this mess too.\n\n\nNicolas\n"},{"id":"160118","messageId":"alpine.LFD.2.00.1101311621150.8580@xanadu.home","threadId":"26371","inReplyTo":"20110131210045.GB14419@sigill.intra.peff.net","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-01-31T21:28:49Z","receivedAt":"2011-01-31T21:28:49Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 31 Jan 2011, Jeff King wrote:\n\n> On Mon, Jan 31, 2011 at 03:28:37PM -0500, Nicolas Pitre wrote:\n> \n> > We do have subdirectories for documentation, tests, contributions, etc.  \n> > But a sizeable part of the tree is just a big splat of source files \n> > dumped right in the root of the tree.\n> > \n> > So I'd suggest doing the following:\n> > \n> > 1) Create a src/ directory and move *.c, *.h, *.sh, *.perl, *.py and \n> >    the builtin directory from the root directory to it.\n> \n> Wouldn't this just be the same giant splat of source files, but in a\n> different tree? I don't really see the advantage, and it seems like an\n> extra annoyance. \n\nLike I said to Junio, if you don't see the advantage, there's nothing I \ncan do for you.  To me this is simple good source code hygiene.\n\n> Besides being just one more directory to go up and down, it does make \n> history browsing more annoying. As much as I love git's \"don't record \n> renames\" philosophy, our handling of renames on the viewing side is \n> often annoying. I already get annoyed sometimes following stuff across \n> the s!builtin-!builtin/! change. This would be like that but more so.\n\nSo... we do suck at something?  So why not take this opportunity to \nshake yourself out of this easy comfort and improve Git as a result on \nboth front?  :-)\n\n> Or maybe it is a good thing for that reason, as we will eat our own\n> rename dogfood. :)\n\nExactly!  And maybe we'll make Git even more useful in the process.\n\n> > 5) Rename t/ to testsuite/ so this doesn't look like some garbage \n> >    leftover.\n> \n> Ugh, more typing. :P\n\nCome on!  You sound like an old fart now!  ;-)\n\n\nNicolas\n"},{"id":"160119","messageId":"alpine.LFD.2.00.1101311630010.8580@xanadu.home","threadId":"26371","inReplyTo":"vpqwrlkg4r8.fsf@bauges.imag.fr","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-01-31T21:33:22Z","receivedAt":"2011-01-31T21:33:22Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 31 Jan 2011, Matthieu Moy wrote:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n> \n> > other than adding merge burden on me and rebase burden on others, that\n> > is.\n> \n> That can be seen as a test of how good Git is at bulk rename\n> management ;-).\n> \n> All that said, I cannot really say whether the benefit is higher than\n> the cost.\n\nThere is a huge value in inflicting on ourselves such a test case for \nthe tool we produce.  That helps avoiding the ivory tower syndrome.\n\n\nNicolas\n"},{"id":"160121","messageId":"201101312244.10047.trast@student.ethz.ch","threadId":"26371","inReplyTo":"7vwrll57ha.fsf@alter.siamese.dyndns.org","subject":"[1.8.0] make two-argument fetch update remote branches","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-01-31T21:44:09Z","receivedAt":"2011-01-31T21:44:09Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Proposal:\n\nRunning \"git fetch origin master\" only updates FETCH_HEAD, not\norigin/master, which turns out to be quite confusing for newcomers\nespecially after running 'git pull origin master'.\n\nSince the remote branches in some sense reflect the \"last known state\"\nof the remote, it would make sense to also update them to whatever a\ntwo-argument fetch got.\n\nRisks:\n\nScripts might rely on the current behaviour.  The most likely case I\ncan think of would be to go along the lines of\n\n  git fetch origin master\n  git rev-list origin/master...FETCH_HEAD | do_something\n\nto avoid relying on reflogs to get the same result.  Seems a bit\narcane to me though.  Such usage would see the updated state, i.e.,\nprocess an empty range.\n\nMigration plan:\n\nAdd a fetch.updateRemoteNamespace (or so) configuration variable that\ndefaults to false.  When enabled, it turns on the auto-updating\nbehaviour.\n\nIn 1.8.0, flip the default.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"160123","messageId":"201101312255.59841.trast@student.ethz.ch","threadId":"26371","inReplyTo":"7vwrll57ha.fsf@alter.siamese.dyndns.org","subject":"[1.8.0] forbid full fetchspecs in git-pull","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-01-31T21:55:59Z","receivedAt":"2011-01-31T21:55:59Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Proposal:\n\ngit-pull inherits the full fetchspec invocation syntax from git-fetch,\nso that you can do e.g.\n\n  git pull origin master:master\n\nusually shooting yourself in the foot in the process.  See e.g.\n\n  http://thread.gmane.org/gmane.comp.version-control.git/130819/focus=130879 [item 1]\n\nProhibit this invocation, i.e., disallow any second argument to\ngit-pull that contains ':'.\n\n\nHistory:\n\nI submitted a patch ages ago:\n\n  http://article.gmane.org/gmane.comp.version-control.git/130822\n\nSean seemed to be the only one in favour of the old behaviour, but I\nwas too lazy to push it past him.  (There were some issues with the\ntest as well.)\n\nI honestly still don't see a valid use-case for the full syntax, let\nalone having seen one in the wild; in cases where you are inclined to\ndo\n\n  git pull origin foo:bar\n\nyou probably don't need 'bar' to begin with if you can use\n'origin/foo' instead, assuming the previous proposal on remote-branch\nupdating is also included.\n\n\nRisks:\n\nIt's an incompatibility, so scripts may break.\n\n\nMigration plan:\n\nNone; disallow it at the 1.8.0 boundary.\n\nIf someone makes a good case why his hands are trained that way, we\nmight introduce a config variable instead.\n\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"160124","messageId":"m3d3ncag7r.fsf_-_@localhost.localdomain","threadId":"26371","inReplyTo":"alpine.LFD.2.00.1101311459000.8580@xanadu.home","subject":"Re: [1.8.0] 't/' is standard name for directory with tests","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-01-31T21:59:35Z","receivedAt":"2011-01-31T21:59:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nicolas Pitre <nico@fluxnic.net> writes:\n\n> So I'd suggest doing the following:\n\n> 5) Rename t/ to testsuite/ so this doesn't look like some garbage \n>    leftover.\n\nNope.  't/' is the standard name for directory with \"normal\" tests, at\nleast in Perl / CPAN land, where TAP comes from ('xt/' is for extra\ntests)\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"160125","messageId":"7vpqrc4t1s.fsf@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"alpine.LFD.2.00.1101311621150.8580@xanadu.home","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-31T22:17:19Z","receivedAt":"2011-01-31T22:17:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre <nico@fluxnic.net> writes:\n\n> On Mon, 31 Jan 2011, Jeff King wrote:\n>\n>> Besides being just one more directory to go up and down, it does make \n>> history browsing more annoying. As much as I love git's \"don't record \n>> renames\" philosophy, our handling of renames on the viewing side is \n>> often annoying. I already get annoyed sometimes following stuff across \n>> the s!builtin-!builtin/! change. This would be like that but more so.\n>\n> So... we do suck at something?  So why not take this opportunity to \n> shake yourself out of this easy comfort and improve Git as a result on \n> both front?  :-)\n>\n>> Or maybe it is a good thing for that reason, as we will eat our own\n>> rename dogfood. :)\n>\n> Exactly!  And maybe we'll make Git even more useful in the process.\n\nThis part I _could_ actually buy; even though I do not think moving files\nwithout much reason is a good project hygine, it does happen in real life,\nand we would want to keep things smooth for real people.\n\n>> > 5) Rename t/ to testsuite/ so this doesn't look like some garbage \n>> >    leftover.\n\nI am not sure about this \"t/\" vs \"testsuite/\".\n\n>> Ugh, more typing. :P\n>\n> Come on!  You sound like an old fart now!  ;-)\n\nIf we make the top-level directory lean enough, we probably can tab\ncomplete after typing just \"cd t\" to go to testsuite/ or tests/ or\nwhatever you come up with, so \"more typing\" is not a huge issue to me\npersonally.\n\nI however think the directory name \"t/\" is not our invention but what we\ntook from somebody else (perhaps Perl?), and I suspect some people expect\nto find tests under there since we have had them there for a long time.\n"},{"id":"160126","messageId":"vpqipx4af91.fsf@bauges.imag.fr","threadId":"26371","inReplyTo":"201101312244.10047.trast@student.ethz.ch","subject":"Re: [1.8.0] make two-argument fetch update remote branches","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-01-31T22:18:50Z","receivedAt":"2011-01-31T22:18:50Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Thomas Rast <trast@student.ethz.ch> writes:\n\n> Running \"git fetch origin master\" only updates FETCH_HEAD, not\n> origin/master, which turns out to be quite confusing for newcomers\n> especially after running 'git pull origin master'.\n\n+1\n\nWe just got the case on this list of a newbie running \"git pull origin\nmaster\" to update his local branch, and \"git status\" still complaining\nthat the local branch was ahead of the remote by many commits.\n\nUpdating the remote-tracking in this case would avoid such confusion.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"160127","messageId":"7vlj204sqb.fsf@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"201101312244.10047.trast@student.ethz.ch","subject":"Re: [1.8.0] make two-argument fetch update remote branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-31T22:24:12Z","receivedAt":"2011-01-31T22:24:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast <trast@student.ethz.ch> writes:\n\n> Proposal:\n>\n> Running \"git fetch origin master\" only updates FETCH_HEAD, not\n> origin/master, which turns out to be quite confusing for newcomers\n> especially after running 'git pull origin master'.\n>\n> Since the remote branches in some sense reflect the \"last known state\"\n> of the remote, it would make sense to also update them to whatever a\n> two-argument fetch got.\n>\n> Risks:\n>\n> Scripts might rely on the current behaviour.  The most likely case I\n> can think of would be to go along the lines of\n>\n>   git fetch origin master\n>   git rev-list origin/master...FETCH_HEAD | do_something\n>\n> to avoid relying on reflogs to get the same result.  Seems a bit\n> arcane to me though.  Such usage would see the updated state, i.e.,\n> process an empty range.\n>\n> Migration plan:\n>\n> Add a fetch.updateRemoteNamespace (or so) configuration variable that\n> defaults to false.  When enabled, it turns on the auto-updating\n> behaviour.\n>\n> In 1.8.0, flip the default.\n\nThe overall goal is a good one, I think, but it is not a migration plan\nwithout a period where we issue a loud, in-your-face, warning to force\nusers to choose, is it?  I suspect you just didn't write it because it is\nso obvious, but I am just making sure it is written down somewhere, so\nthat whoever ends up implementing this will not forget.\n\nThanks.\n"},{"id":"160128","messageId":"AANLkTin2kTW85UC1r_1LUDVLiexcVDvt--9ndnXZ2ARS@mail.gmail.com","threadId":"26371","inReplyTo":"201101312244.10047.trast@student.ethz.ch","subject":"Re: [1.8.0] make two-argument fetch update remote branches","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2011-01-31T22:27:17Z","receivedAt":"2011-01-31T22:27:17Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"On Mon, Jan 31, 2011 at 4:44 PM, Thomas Rast <trast@student.ethz.ch> wrote:\n> Proposal:\n>\n> Running \"git fetch origin master\" only updates FETCH_HEAD, not\n> origin/master, which turns out to be quite confusing for newcomers\n> especially after running 'git pull origin master'.\n>\n> Since the remote branches in some sense reflect the \"last known state\"\n> of the remote, it would make sense to also update them to whatever a\n> two-argument fetch got.\n>\n> Risks:\n>\n> Scripts might rely on the current behaviour.  The most likely case I\n> can think of would be to go along the lines of\n>\n>  git fetch origin master\n>  git rev-list origin/master...FETCH_HEAD | do_something\n>\n> to avoid relying on reflogs to get the same result.  Seems a bit\n> arcane to me though.  Such usage would see the updated state, i.e.,\n> process an empty range.\n>\n> Migration plan:\n>\n> Add a fetch.updateRemoteNamespace (or so) configuration variable that\n> defaults to false.  When enabled, it turns on the auto-updating\n> behaviour.\n>\n> In 1.8.0, flip the default.\n>\n> --\n> Thomas Rast\n> trast@{inf,student}.ethz.ch\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n\n+1 I really wanted to write this one my self;)\n\nI would disagree with the migration plan though.\nIMHO there is no need to introduce the variable. If it will start\nupdate both FETCH_HEAD and the remote-tracking branches since 1.8 it\nwill not break any code, because it is added functionality...\nIn this case FETCH_HEAD will reflect the latest fetch and it doesn't\neven need to be removed later on.\n\njust my 2 cents...\n\nThanks,\nEugene\n"},{"id":"160129","messageId":"alpine.LFD.2.00.1101311728180.8580@xanadu.home","threadId":"26371","inReplyTo":"m3d3ncag7r.fsf_-_@localhost.localdomain","subject":"Re: [1.8.0] 't/' is standard name for directory with tests","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-01-31T22:32:53Z","receivedAt":"2011-01-31T22:32:53Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 31 Jan 2011, Jakub Narebski wrote:\n\n> Nicolas Pitre <nico@fluxnic.net> writes:\n> \n> > So I'd suggest doing the following:\n> \n> > 5) Rename t/ to testsuite/ so this doesn't look like some garbage \n> >    leftover.\n> \n> Nope.  't/' is the standard name for directory with \"normal\" tests, at\n> least in Perl / CPAN land, where TAP comes from ('xt/' is for extra\n> tests)\n\nSo what?  It is not because Perl has set this horrible precedent that we \nhave to perpetuate it.  I personally never saw t used as a directory \nname for tests before Git, and I'm not that young anymore unfortunately.\n\n\nNicolas\n"},{"id":"160130","messageId":"AANLkTikef6og4pttT0GKW1LUAtaKvVjTMVHTZaa3TO2h@mail.gmail.com","threadId":"26371","inReplyTo":"7vpqrc4t1s.fsf@alter.siamese.dyndns.org","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"João P. Sampaio","fromEmail":"jpmelos@gmail.com","sentAt":"2011-01-31T22:36:55Z","receivedAt":"2011-01-31T22:36:55Z","isPatch":false,"sender":{"key":"jpmelos@gmail.com","avatar":"https://gravatar.com/avatar/cf1eb89e5f7ab7a0f27eca3528460be048d790de7ca40b79212901161899255f?d=mp&s=160"},"body":"I think a good code hygiene is important, and some suggestions here\nare relevant:\n\n1) I also think there should be a directory for the source code\n(namely, src/), and the top level should act as a table of contents.\nAs a newcomer myself who's trying to grasp Git, I can say an organized\nproject makes people more inclined join. Therefore, directories should\nbe named as clearly as possible: see item 2;\n\n2) For item 1, t/ should be renamed to testsuite/. As Junio said, if\nwe get a more organized project, people could just \"cd t\" and tab to\nautocomplete, or \"cd tes\" at the worst scenario, which is not such a\nbig hassle. About people expecting the testsuite to be inside t/, once\nthey type \"cd t\" and get an error, most people would look for an\nalternative and eventually find the correct folder, or tabbing would\njust suggest the name.\n\n3) The top level should hold files that point people towards where\nthey want to go, helpful files like README and even some\nDocumentation/ files could get a promotion.\n\n3) As 1.8.0 can be an inflexion for users, so could be for the\ndevelopers as well.\n\n-- \nJoão Paulo Melo de Sampaio\nComputer Engineering Student @ UFSCar\nWebsite: http://www.jpmelos.com\nTwitter: twitter.com/jpmelos (@jpmelos)\n"},{"id":"160131","messageId":"alpine.LFD.2.00.1101311734140.8580@xanadu.home","threadId":"26371","inReplyTo":"7vpqrc4t1s.fsf@alter.siamese.dyndns.org","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-01-31T22:37:23Z","receivedAt":"2011-01-31T22:37:23Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 31 Jan 2011, Junio C Hamano wrote:\n\n> If we make the top-level directory lean enough, we probably can tab\n> complete after typing just \"cd t\" to go to testsuite/ or tests/ or\n> whatever you come up with, so \"more typing\" is not a huge issue to me\n> personally.\n> \n> I however think the directory name \"t/\" is not our invention but what we\n> took from somebody else (perhaps Perl?), and I suspect some people expect\n> to find tests under there since we have had them there for a long time.\n\nIf those people are not able to figure out that \"testsuite\" means where \ntests are, especially within a lean top directory, then we might \nquestion the reliability of the tests they might contribute.\n\n\nNicolas\n"},{"id":"160133","messageId":"7vhbco4s34.fsf@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"201101312255.59841.trast@student.ethz.ch","subject":"Re: [1.8.0] forbid full fetchspecs in git-pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-31T22:38:07Z","receivedAt":"2011-01-31T22:38:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast <trast@student.ethz.ch> writes:\n\n> Proposal:\n>\n> git-pull inherits the full fetchspec invocation syntax from git-fetch,\n> so that you can do e.g.\n>\n>   git pull origin master:master\n>\n> usually shooting yourself in the foot in the process.  See e.g.\n>\n>   http://thread.gmane.org/gmane.comp.version-control.git/130819/focus=130879 [item 1]\n>\n> Prohibit this invocation, i.e., disallow any second argument to\n> git-pull that contains ':'.\n>\n> History:\n>\n> I submitted a patch ages ago:\n>\n>   http://article.gmane.org/gmane.comp.version-control.git/130822\n>\n> Sean seemed to be the only one in favour of the old behaviour, but I\n> was too lazy to push it past him.  (There were some issues with the\n> test as well.)\n\nAs I summarized in $gmane/135813 I don't think there was any objection\nagainst forbidding \"git pull\" with refspec with colon.  There indeed was\nan interesting tangent topic that was about valid use cases of \"git fetch\"\nwith such refspec, but I think this is orthogonal to that issue.\n"},{"id":"160134","messageId":"20110131225529.GC14419@sigill.intra.peff.net","threadId":"26371","inReplyTo":"7vzkqg4x2h.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [1.8.0] (v2) default \"git merge\" without argument to \"git merge @{u}\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-01-31T22:55:29Z","receivedAt":"2011-01-31T22:55:29Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 31, 2011 at 12:50:30PM -0800, Junio C Hamano wrote:\n\n> Perhaps I should start a new directory in todo branch (say, 1.8.0), accept\n> patches from people?  I'd grudgingly admit that using Wiki on k.org may be\n> less burdensome (I hate editing inside the browser myself), but I'd want\n> to keep the mailing list the center of discussion and am afraid that\n> forcing people to go to Wiki would fragment the discussion.\n\nI really wish we had a git-backed wiki. I also hate using the browser\nfor such things (though browser extensions to edit textareas in a Real\nEditor at least make it tolerable, it still ends up clunky).\n\nGitHub's wiki gets this right. I'm not saying we should host our wiki\nthere (well, it _would_ make setting it up pretty damn easy). But their\nwiki system (gollum) is open-source, albeit in ruby. And surely there\nare other git-backed alternatives (it's been a while since I've looked).\n\n> Proposal:\n> [...]\n\nWell, I don't know this is still just an example, but your update looks\nfine to me. :)\n\n-Peff\n"},{"id":"160135","messageId":"7vd3nc4qr6.fsf@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"AANLkTin2kTW85UC1r_1LUDVLiexcVDvt--9ndnXZ2ARS@mail.gmail.com","subject":"Re: [1.8.0] make two-argument fetch update remote branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-31T23:06:53Z","receivedAt":"2011-01-31T23:06:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eugene Sajine <euguess@gmail.com> writes:\n\n> IMHO there is no need to introduce the variable. If it will start\n> update both FETCH_HEAD and the remote-tracking branches since 1.8 it\n> will not break any code, because it is added functionality...\n\nThen you didn't understand the risks section, did you?  Thomas clearly\nillustrated with an example where the script _expects_ origin/master to\nstay the same after \"git fetch origin master\".\n"},{"id":"160136","messageId":"20110131231210.GD14419@sigill.intra.peff.net","threadId":"26371","inReplyTo":"alpine.LFD.2.00.1101311621150.8580@xanadu.home","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-01-31T23:12:11Z","receivedAt":"2011-01-31T23:12:11Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 31, 2011 at 04:28:49PM -0500, Nicolas Pitre wrote:\n\n> > Besides being just one more directory to go up and down, it does make \n> > history browsing more annoying. As much as I love git's \"don't record \n> > renames\" philosophy, our handling of renames on the viewing side is \n> > often annoying. I already get annoyed sometimes following stuff across \n> > the s!builtin-!builtin/! change. This would be like that but more so.\n> \n> So... we do suck at something?  So why not take this opportunity to \n> shake yourself out of this easy comfort and improve Git as a result on \n> both front?  :-)\n\nYes, we do suck at rename following. The problem is that it is partially\nan implementation issue, and partially a fundamental issue. Obviously\n--follow sucks pretty hard right now, and that could be fixed. Namely it\nfollows only a single file, and it interacts very badly with history\nsimplification.\n\nBut even with those things fixed, there will still be annoyances.\n\nIt will still be _slower_ to turn it on all the time, for one[1]. And\nthat's due to fundamental design decisions of the git data structure.\nAnd I'm not knocking those decisions; I think they made the right\ntradeoff. But that doesn't mean we don't pay the cost for that tradeoff.\n\nAnd no matter what your model, renames can be annoying. On-going topics\nwill have a painful rebase or merge. And people looking at history will\nhave to deal with the code-base having different names at different\npoints. Yeah, you can say it's all just \"content\", but the filenames we\nput things in are actually useful.\n\nSo I don't think it's wrong to say \"renames are a pain, and so should\nnot be done lightly\". I do think it's wrong to say \"renames can't be\ndone\"; I just the cost needs to be considered.\n\n-Peff\n\n[1] I'd be interested to see how much we can get around that slowness\nusing a notes-cache.\n"},{"id":"160137","messageId":"AANLkTikxcd+gzeuJsQX1V5Wses8xWMnshdrOnYTvXgTq@mail.gmail.com","threadId":"26371","inReplyTo":"201101312255.59841.trast@student.ethz.ch","subject":"Re: [1.8.0] forbid full fetchspecs in git-pull","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2011-01-31T23:15:39Z","receivedAt":"2011-01-31T23:15:39Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Mon, Jan 31, 2011 at 10:55:59PM +0100, Thomas Rast wrote:\n> Proposal:\n>\n> git-pull inherits the full fetchspec invocation syntax from git-fetch,\n> so that you can do e.g.\n>\n>  git pull origin master:master\n>\n> usually shooting yourself in the foot in the process.  See e.g.\n>\n>  http://thread.gmane.org/gmane.comp.version-control.git/130819/focus=130879 [item 1]\n>\n> Prohibit this invocation, i.e., disallow any second argument to\n> git-pull that contains ':'.\n\nHmm... I have always thought about \"git pull repo refspec\" as\n\"git fetch repo refspec && git merge FETCH_HEAD\"\nand \"git fetch\" refuses to fetch into the current branch of a non-bare\nrepository, so I expected \"git merge\" to fail in this case too, but it\nsucceeded though with some warning that fetch updated the current\nbranch head. I think it is inconsistent and should be fixed, and that\nwill fix the mentioned confusion as well.\n\nAs to disallowing ':' in refspec completely, I am not so sure... Not\nthat I think it is very useful, but also I don't see how it can hurt\nsomeone provided that the target branch cannot be the current branch.\n\n\nDmitry\n"},{"id":"160138","messageId":"20110131232231.GE14419@sigill.intra.peff.net","threadId":"26371","inReplyTo":"201101312244.10047.trast@student.ethz.ch","subject":"Re: [1.8.0] make two-argument fetch update remote branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-01-31T23:22:31Z","receivedAt":"2011-01-31T23:22:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 31, 2011 at 10:44:09PM +0100, Thomas Rast wrote:\n\n> Running \"git fetch origin master\" only updates FETCH_HEAD, not\n> origin/master, which turns out to be quite confusing for newcomers\n> especially after running 'git pull origin master'.\n> \n> Since the remote branches in some sense reflect the \"last known state\"\n> of the remote, it would make sense to also update them to whatever a\n> two-argument fetch got.\n\nI like this one. FYI, I posted a patch in Aug 2009, and there was some\ndiscussion about the impacts (it spills over into the sibling\nsubthreads):\n\n  http://article.gmane.org/gmane.comp.version-control.git/127215\n\nI'm actually still carrying the patch in my repository (and using it\nevery day!). I guess I should get on polishing it up...\n\n-Peff\n"},{"id":"160139","messageId":"AANLkTinRo5KxC9OQWyZMnqQP4WHi0sR5qqw6byr4V+3a@mail.gmail.com","threadId":"26371","inReplyTo":"7vd3nc4qr6.fsf@alter.siamese.dyndns.org","subject":"Re: [1.8.0] make two-argument fetch update remote branches","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2011-01-31T23:39:19Z","receivedAt":"2011-01-31T23:39:19Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"On Mon, Jan 31, 2011 at 6:06 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Eugene Sajine <euguess@gmail.com> writes:\n>\n>> IMHO there is no need to introduce the variable. If it will start\n>> update both FETCH_HEAD and the remote-tracking branches since 1.8 it\n>> will not break any code, because it is added functionality...\n>\n> Then you didn't understand the risks section, did you?  Thomas clearly\n> illustrated with an example where the script _expects_ origin/master to\n> stay the same after \"git fetch origin master\".\n>\n\nI did understand what Thomas illustrated. I'm just thinking that the\nrange origin/master...FETCH_HEAD seems to be useful but in fact is\npretty useless, because you cannot guarantee the state of the\norigin/master _before_ the fetch and therefore you cannot rely on the\nresults of range selections involving it.\nBy \"guaranteeing the state\" i mean that because of the current\nimplementation origin/master doesn't always mean/reflect the same\nthing: it might be some _old_ and outdated push or it might be some\nnew state of the remote branch which are IMHO completely different\nsemantics.\n\nThat's exactly why it seems to me that it is important to always\nupdate remote-tracking branches upon any related network operation. So\nremote-tracking branch always represents the _same_ thing - the latest\nstate of the remote branch that you interacted with.\n\n\nThanks,\nEugene\n"},{"id":"160140","messageId":"AANLkTi=EX08rAucRm7uVCTLUgjOi+skoEF1rEhpHVMsi@mail.gmail.com","threadId":"26371","inReplyTo":"20110131225529.GC14419@sigill.intra.peff.net","subject":"Re: [1.8.0] (v2) default \"git merge\" without argument to \"git merge @{u}\"","fromName":"Thomas Adam","fromEmail":"thomas@xteddy.org","sentAt":"2011-02-01T00:01:10Z","receivedAt":"2011-02-01T00:01:10Z","isPatch":false,"sender":{"key":"thomas@xteddy.org","avatar":"https://gravatar.com/avatar/e7256db4738e501e5d2e84f00bb0bd99503165729573848a03330301fc2adc4a?d=mp&s=160"},"body":"On 31 January 2011 22:55, Jeff King <peff@peff.net> wrote:\n> On Mon, Jan 31, 2011 at 12:50:30PM -0800, Junio C Hamano wrote:\n>\n>> Perhaps I should start a new directory in todo branch (say, 1.8.0), accept\n>> patches from people?  I'd grudgingly admit that using Wiki on k.org may be\n>> less burdensome (I hate editing inside the browser myself), but I'd want\n>> to keep the mailing list the center of discussion and am afraid that\n>> forcing people to go to Wiki would fragment the discussion.\n>\n> I really wish we had a git-backed wiki. I also hate using the browser\n> for such things (though browser extensions to edit textareas in a Real\n> Editor at least make it tolerable, it still ends up clunky).\n\nYou mean like ikiwiki (were it used on the main sites)?\n\nhttp://ikiwiki.info\n\n-- Thomas Adam\n"},{"id":"160142","messageId":"AANLkTi=uOhgnKxRpA0Vm2uSe+uznPwjRB-=2e81VTf-f@mail.gmail.com","threadId":"26371","inReplyTo":"alpine.LFD.2.00.1101311728180.8580@xanadu.home","subject":"Re: [1.8.0] 't/' is standard name for directory with tests","fromName":"Alex Budovski","fromEmail":"abudovski@gmail.com","sentAt":"2011-02-01T00:12:58Z","receivedAt":"2011-02-01T00:12:58Z","isPatch":false,"sender":{"key":"abudovski@gmail.com","avatar":null},"body":">> Nope.  't/' is the standard name for directory with \"normal\" tests, at\n>> least in Perl / CPAN land, where TAP comes from ('xt/' is for extra\n>> tests)\n>\n> So what?  It is not because Perl has set this horrible precedent that we\n> have to perpetuate it.  I personally never saw t used as a directory\n> name for tests before Git, and I'm not that young anymore unfortunately.\n\nThe MySQL project (and its clones) also uses the t/ convention.\n"},{"id":"160143","messageId":"alpine.LFD.2.00.1101311903320.8580@xanadu.home","threadId":"26371","inReplyTo":"20110131231210.GD14419@sigill.intra.peff.net","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-02-01T00:29:54Z","receivedAt":"2011-02-01T00:29:54Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 31 Jan 2011, Jeff King wrote:\n\n> On Mon, Jan 31, 2011 at 04:28:49PM -0500, Nicolas Pitre wrote:\n> \n> > So... we do suck at something?  So why not take this opportunity to \n> > shake yourself out of this easy comfort and improve Git as a result on \n> > both front?  :-)\n> \n> Yes, we do suck at rename following. The problem is that it is partially\n> an implementation issue, and partially a fundamental issue. Obviously\n> --follow sucks pretty hard right now, and that could be fixed. Namely it\n> follows only a single file, and it interacts very badly with history\n> simplification.\n\nThis is no excuse not to do proper source tree reorganization.\n\nTelling people not to move files around because Git sucks at tracking \nthem is also the wrong answer.\n\n> But even with those things fixed, there will still be annoyances.\n> \n> It will still be _slower_ to turn it on all the time, for one[1]. And\n> that's due to fundamental design decisions of the git data structure.\n> And I'm not knocking those decisions; I think they made the right\n> tradeoff. But that doesn't mean we don't pay the cost for that tradeoff.\n\nI agree.  However sitting on our back and resisting a cleanup just \nbecause our very tool does poorly in that scenario is just like putting \nour heads in the sand and pretend that the problem doesn't exist.  \nBetter do what most people without internal knowledge of Git would do \nand just clean up the tree, and then benefit from this extraordinary \nopportunity of having this environment right at home where Git \ndevelopers have a much greater incentive to work on this issue and \nimprove things.\n\n> And no matter what your model, renames can be annoying. On-going topics\n> will have a painful rebase or merge. And people looking at history will\n> have to deal with the code-base having different names at different\n> points. Yeah, you can say it's all just \"content\", but the filenames we\n> put things in are actually useful.\n\nOf course.  But such is life.  Many projects out there are just like \nthat, and facing this situation ourselves will just help us figure out \nways to make Git even more useful to more people.\n\n> So I don't think it's wrong to say \"renames are a pain, and so should\n> not be done lightly\".\n\nI disagree.  This is like saying: \"renames are not well supported, so \nlet's avoid them while using Git.\"  People used to say that of merges \nwith CVS.  Are we going to follow suit de facto?  Imagine the Git \ndetractors taking our source tree mess to exemplify this Git flaw since \n\"Git developers themselves are unwilling to move files around because \nGit sucks at it\".\n\n> I do think it's wrong to say \"renames can't be\n> done\"; I just the cost needs to be considered.\n\nInstead, why not saying: \"Rename tracking is not as optimal as it could \nbe, so let's work it out.\" ?\n\n\nNicolas\n"},{"id":"160144","messageId":"alpine.LFD.2.00.1101311930280.8580@xanadu.home","threadId":"26371","inReplyTo":"AANLkTi=uOhgnKxRpA0Vm2uSe+uznPwjRB-=2e81VTf-f@mail.gmail.com","subject":"Re: [1.8.0] 't/' is standard name for directory with tests","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-02-01T00:33:16Z","receivedAt":"2011-02-01T00:33:16Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 1 Feb 2011, Alex Budovski wrote:\n\n> >> Nope.  't/' is the standard name for directory with \"normal\" tests, at\n> >> least in Perl / CPAN land, where TAP comes from ('xt/' is for extra\n> >> tests)\n> >\n> > So what?  It is not because Perl has set this horrible precedent that we\n> > have to perpetuate it.  I personally never saw t used as a directory\n> > name for tests before Git, and I'm not that young anymore unfortunately.\n> \n> The MySQL project (and its clones) also uses the t/ convention.\n\nOK, that makes for another one.\n\nNow what about those hundred counter-example projects _not_ using \"t\" \nbut something more descriptive?\n\n\nNicolas\n"},{"id":"160145","messageId":"AANLkTim6YN5k+JjxYBkfpXYze1MRxFNAmSeJ_0CQpBnf@mail.gmail.com","threadId":"26371","inReplyTo":"20110131231210.GD14419@sigill.intra.peff.net","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2011-02-01T00:35:16Z","receivedAt":"2011-02-01T00:35:16Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Tue, Feb 1, 2011 at 12:12 AM, Jeff King <peff@peff.net> wrote:\n> On Mon, Jan 31, 2011 at 04:28:49PM -0500, Nicolas Pitre wrote:\n>\n>> > Besides being just one more directory to go up and down, it does make\n>> > history browsing more annoying. As much as I love git's \"don't record\n>> > renames\" philosophy, our handling of renames on the viewing side is\n>> > often annoying. I already get annoyed sometimes following stuff across\n>> > the s!builtin-!builtin/! change. This would be like that but more so.\n>>\n>> So... we do suck at something?  So why not take this opportunity to\n>> shake yourself out of this easy comfort and improve Git as a result on\n>> both front?  :-)\n>\n> Yes, we do suck at rename following. The problem is that it is partially\n> an implementation issue, and partially a fundamental issue. Obviously\n> --follow sucks pretty hard right now, and that could be fixed. Namely it\n> follows only a single file, and it interacts very badly with history\n> simplification.\n>\n> But even with those things fixed, there will still be annoyances.\n>\n> It will still be _slower_ to turn it on all the time, for one[1]. And\n> that's due to fundamental design decisions of the git data structure.\n\nDoes it really have to be? I mean, for whole-file rename-detection, if\nwe say that we automatically enable rename-detection (by default) as\nwe reach the first commit that doesn't have a given tree-entry, then\nit would only kick in as we're about to terminate the log-output. And\nsince we're usually reading through a pager, it should means that it\ntakes a little bit more time before the user knows he's at the end of\nthe log. It shouldn't really affect the throughput of the data before\nthe point that becomes an annoyance, right?\n\nAt least that's the part that I find the most annoying with the\ncurrent rename detection; having to enable the flag as I reach the end\nof the history for a file, often having to search through a lot of\ncommits again.\n"},{"id":"160146","messageId":"201102010159.02694.jnareb@gmail.com","threadId":"26371","inReplyTo":"alpine.LFD.2.00.1101311930280.8580@xanadu.home","subject":"Re: [1.8.0] 't/' is standard name for directory with tests","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-02-01T00:58:57Z","receivedAt":"2011-02-01T00:58:57Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Tue, 1 Feb 2011, Nicolas Pitre wrote:\n> On Tue, 1 Feb 2011, Alex Budovski wrote:\n> \n> > >> Nope.  't/' is the standard name for directory with \"normal\" tests, at\n> > >> least in Perl / CPAN land, where TAP comes from ('xt/' is for extra\n> > >> tests)\n> > >\n> > > So what?  It is not because Perl has set this horrible precedent that we\n> > > have to perpetuate it.  I personally never saw t used as a directory\n> > > name for tests before Git, and I'm not that young anymore unfortunately.\n\nCPAN is around 21000 distributions and 88000 modules.  Most of those use\n't/' for tests (default CPAN client to download and install modules runs\nthose tests before installing module).\n\n> > The MySQL project (and its clones) also uses the t/ convention.\n> \n> OK, that makes for another one.\n> \n> Now what about those hundred counter-example projects _not_ using \"t\" \n> but something more descriptive?\n\nYou mean those counter-example projects that use and include comprehensive\ntests, isn't it?\n\nWell, GCC uses 'testsuite/'.  Mozilla uses 'testing/'.\n-- \nJakub Narebski\nPoland\n"},{"id":"160147","messageId":"AANLkTi=boNXZbryTGFth5igZ771BbTmEKmh7LOxko+T-@mail.gmail.com","threadId":"26371","inReplyTo":"20110131231210.GD14419@sigill.intra.peff.net","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-02-01T01:00:05Z","receivedAt":"2011-02-01T01:00:05Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Tue, Feb 1, 2011 at 00:12, Jeff King <peff@peff.net> wrote:\n> [1] I'd be interested to see how much we can get around that slowness\n> using a notes-cache.\n\nDo you mean something like a refs/notes/renames namespace in which we\nstick notes on commits indicating that a rename indicated at that\ncommit, with an option of the user, after-the-fact, adding this\ninformation manually?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"160148","messageId":"7v8vy04kvc.fsf@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"AANLkTinRo5KxC9OQWyZMnqQP4WHi0sR5qqw6byr4V+3a@mail.gmail.com","subject":"Re: [1.8.0] make two-argument fetch update remote branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-01T01:13:59Z","receivedAt":"2011-02-01T01:13:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eugene Sajine <euguess@gmail.com> writes:\n\n> I did understand what Thomas illustrated. I'm just thinking that the\n> range origin/master...FETCH_HEAD seems to be useful but in fact is\n> pretty useless, because you cannot guarantee the state of the\n> origin/master _before_ the fetch and therefore you cannot rely on the\n> results of range selections involving it.\n\nWith the current system, origin/master is what I _used to_ have before\nrunning this fetch, iow, what I have been looking at as a reference\nmaterial while I did my own work so far.  The current \"when fetching refs\nexplicitly, do not touch tracking branches\" behaviour guarantees that.\n\nThe range above shows what I already knew about the work the other people\ndid, and what is new on both sides, to help me decide what I want to do\nnext with the fetched result.  At least that is the workflow the \"when\nfetching refs explicitly, do not touch tracking branches\" behaviour allows\nus to support (I am not recommending that the workflow in particular, by\nthe way).  The next action after seeing what they added is sane may be to\nrun \"git pull\" (no arguments), which would fast-forward my view of the\nother side to whatever I reviewed this round.\n"},{"id":"160149","messageId":"7v4o8o4kt7.fsf@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"alpine.LFD.2.00.1101311930280.8580@xanadu.home","subject":"Re: [1.8.0] 't/' is standard name for directory with tests","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-01T01:15:16Z","receivedAt":"2011-02-01T01:15:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre <nico@fluxnic.net> writes:\n\n> On Tue, 1 Feb 2011, Alex Budovski wrote:\n> ...\n>> The MySQL project (and its clones) also uses the t/ convention.\n>\n> OK, that makes for another one.\n>\n> Now what about those hundred counter-example projects _not_ using \"t\" \n> but something more descriptive?\n\nI am fine with \"tests/\", by the way.\n"},{"id":"160150","messageId":"20110201014807.GA2722@sigill.intra.peff.net","threadId":"26371","inReplyTo":"alpine.LFD.2.00.1101311903320.8580@xanadu.home","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-01T01:48:07Z","receivedAt":"2011-02-01T01:48:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 31, 2011 at 07:29:54PM -0500, Nicolas Pitre wrote:\n\n> > Yes, we do suck at rename following. The problem is that it is partially\n> [...]\n> This is no excuse not to do proper source tree reorganization.\n\nI think this is the crux of our disagreement. I don't agree that your\nproposal is any way more \"proper\" than what is there now. Leaving the\nrename issue aside (i.e., if we were starting a new project), I would\nstill be slightly against a src/ directory. I find them annoying.\n\nBut I don't care _that_ much, and I would rather not waste either of our\ntime debating it more. I would much rather you spend your time on\npack v4. :)\n\n> I disagree.  This is like saying: \"renames are not well supported, so \n> let's avoid them while using Git.\"  People used to say that of merges \n> with CVS.  Are we going to follow suit de facto?  Imagine the Git \n> detractors taking our source tree mess to exemplify this Git flaw since \n> \"Git developers themselves are unwilling to move files around because \n> Git sucks at it\".\n\nFor the record, part of my argument was that renaming is annoying to\nsome degree in _all_ systems, not just git.\n\n> > I do think it's wrong to say \"renames can't be\n> > done\"; I just the cost needs to be considered.\n> \n> Instead, why not saying: \"Rename tracking is not as optimal as it could \n> be, so let's work it out.\" ?\n\nI did also say that. :)\n\n-Peff\n"},{"id":"160151","messageId":"20110201015312.GB2722@sigill.intra.peff.net","threadId":"26371","inReplyTo":"AANLkTim6YN5k+JjxYBkfpXYze1MRxFNAmSeJ_0CQpBnf@mail.gmail.com","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-01T01:53:12Z","receivedAt":"2011-02-01T01:53:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 01, 2011 at 01:35:16AM +0100, Erik Faye-Lund wrote:\n\n> > It will still be _slower_ to turn it on all the time, for one[1]. And\n> > that's due to fundamental design decisions of the git data structure.\n> \n> Does it really have to be? I mean, for whole-file rename-detection, if\n> we say that we automatically enable rename-detection (by default) as\n> we reach the first commit that doesn't have a given tree-entry, then\n> it would only kick in as we're about to terminate the log-output. And\n> since we're usually reading through a pager, it should means that it\n> takes a little bit more time before the user knows he's at the end of\n> the log. It shouldn't really affect the throughput of the data before\n> the point that becomes an annoyance, right?\n\nThat's not quite true. You may be following not just a single file, but\nsome arbitrary pathspec. Any time there is a file creation event that\nmatches that pathspec, you will want to rename-detect any possible\nsources for that created file, and add them to the list of interesting\npaths.\n\nBut yeah, we don't have to do rename detection for every single case. So\nthe slowness may turn out to be not that bad. When I had\narbitrary-pathspec following this summer I thought I did some numbers,\nbut I don't remember the results and I can't find them on the list.\n\n-Peff\n"},{"id":"160152","messageId":"20110201015736.GC2722@sigill.intra.peff.net","threadId":"26371","inReplyTo":"AANLkTi=boNXZbryTGFth5igZ771BbTmEKmh7LOxko+T-@mail.gmail.com","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-01T01:57:36Z","receivedAt":"2011-02-01T01:57:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 01, 2011 at 02:00:05AM +0100, Sverre Rabbelier wrote:\n\n> Heya,\n> \n> On Tue, Feb 1, 2011 at 00:12, Jeff King <peff@peff.net> wrote:\n> > [1] I'd be interested to see how much we can get around that slowness\n> > using a notes-cache.\n> \n> Do you mean something like a refs/notes/renames namespace in which we\n> stick notes on commits indicating that a rename indicated at that\n> commit, with an option of the user, after-the-fact, adding this\n> information manually?\n\nYes, without the \"option of the user...\" bit. Basically just cache the\nlist of renames for a given commit against its parent (which should be\nimmutable[1]), under the assumption that it is cheaper to look up the\nnote than it is to calculate the renames.\n\nBut I would make it purely a cache, not some place for users to stick\ntheir own generated rename information (if people really want to do\nthat, I would much rather see it go into the commit itself as a\npseudo-header).\n\n-Peff\n\n[1] It's technically not immutable if you limit the pathspec, or if you\nhave non-standard rename options. But you could define some \"canonical\"\nrename set, like all of the pairs found doing rename detection with -M90\nwhen considering the whole set of removed files as sources and added\nfiles as destinations. That would cover the common case of people\nrunning \"git log\", and then more specialized detection would not use the\ncache.\n"},{"id":"160153","messageId":"AANLkTikeqsg+qJ0z4iQ6ZmKL=_HB8YX_z20L=dFFApmA@mail.gmail.com","threadId":"26371","inReplyTo":"7vwrll57ha.fsf@alter.siamese.dyndns.org","subject":"Re: Planning for 1.7.5 and 1.8.0","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-01T03:20:43Z","receivedAt":"2011-02-01T03:20:43Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Feb 1, 2011 at 12:05 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Now the 1.7.4 release is out, I'd like people to help thinking about the\n> next cycle(s).\n>\n> As a discussion-starter, here are my random wishes.  Even though this does\n> not attempt to be exhaustive, keeping the number of goals manageably small\n> may help us focus.\n\nAnother random wish, which does not come with a proposal. How about\ntag namespace (ie. tags from a remote stay in remote namespace)?\n-- \nDuy\n"},{"id":"160154","messageId":"alpine.LFD.2.00.1101312238170.8580@xanadu.home","threadId":"26371","inReplyTo":"20110201014807.GA2722@sigill.intra.peff.net","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-02-01T04:05:36Z","receivedAt":"2011-02-01T04:05:36Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 31 Jan 2011, Jeff King wrote:\n\n> On Mon, Jan 31, 2011 at 07:29:54PM -0500, Nicolas Pitre wrote:\n> \n> > This is no excuse not to do proper source tree reorganization.\n> \n> I think this is the crux of our disagreement. I don't agree that your\n> proposal is any way more \"proper\" than what is there now. Leaving the\n> rename issue aside (i.e., if we were starting a new project), I would\n> still be slightly against a src/ directory. I find them annoying.\n\nLet's agree to disagree then.  What I see in the root of the Git source \ntree is a huge clutter of source files, binary files, scripts, and \nsubdirectories all mixed together.  If you know by hart where things are \nbecause you've been hacking on them for the last 5 years then of course \nyou might not see the point.  But since I didn't work much on Git \nlately, things are not as obvious to me as they used to be.  Looking \nback at it now with some distance, this tree looks like a mess and it is \nreally annoying to work with.\n\n> But I don't care _that_ much, and I would rather not waste either of our\n> time debating it more. I would much rather you spend your time on\n> pack v4. :)\n\nI wish... I wish.  But I have a plan which might involve taking some \nvacation from $day_job in the Caribbeans with $wife and no kids, where \n$wife is going to do scuba diving with her club mates while I'll be \nalone with a laptop and no net connection and therefore nothing else to \ndo for a week.  I've been craving for such free time for quite a while \nnow.\n\n\nNicolas\n"},{"id":"160155","messageId":"alpine.LFD.2.00.1101312312540.8580@xanadu.home","threadId":"26371","inReplyTo":"AANLkTikeqsg+qJ0z4iQ6ZmKL=_HB8YX_z20L=dFFApmA@mail.gmail.com","subject":"Re: Planning for 1.7.5 and 1.8.0","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-02-01T04:16:13Z","receivedAt":"2011-02-01T04:16:13Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 1 Feb 2011, Nguyen Thai Ngoc Duy wrote:\n\n> On Tue, Feb 1, 2011 at 12:05 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> > Now the 1.7.4 release is out, I'd like people to help thinking about the\n> > next cycle(s).\n> >\n> > As a discussion-starter, here are my random wishes.  Even though this does\n> > not attempt to be exhaustive, keeping the number of goals manageably small\n> > may help us focus.\n> \n> Another random wish, which does not come with a proposal. How about\n> tag namespace (ie. tags from a remote stay in remote namespace)?\n\nPlease make this into a proper proposal.  this would be indeed a huge \nimprovement.\n\n\nNicolas\n"},{"id":"160158","messageId":"AANLkTi=Y9PBs_jXyCiAL9YLA8Y_jzWwqxw63hKm7fVBO@mail.gmail.com","threadId":"26371","inReplyTo":"201101312244.10047.trast@student.ethz.ch","subject":"Re: [1.8.0] make two-argument fetch update remote branches","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-01T07:04:47Z","receivedAt":"2011-02-01T07:04:47Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Jan 31, 2011 at 4:44 PM, Thomas Rast <trast@student.ethz.ch> wrote:\n> Add a fetch.updateRemoteNamespace (or so) configuration variable that\n> defaults to false.  When enabled, it turns on the auto-updating\n> behaviour.\n\nWould it make sense to group the pre-1.8 compatibility switches\ntogether in some way, if there will be several of them? Maybe\n\n[compat]\n   fetchUpdateRemoteNamespace = false\n   ...\n\n(Thinking out loud.)\n\nj.\n"},{"id":"160160","messageId":"AANLkTinx9HnKpyjqc34sGnDAiChB67Nd68apOhz9HEFJ@mail.gmail.com","threadId":"26371","inReplyTo":"20110131231210.GD14419@sigill.intra.peff.net","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-01T07:24:44Z","receivedAt":"2011-02-01T07:24:44Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Jan 31, 2011 at 6:12 PM, Jeff King <peff@peff.net> wrote:\n> And no matter what your model, renames can be annoying. On-going topics\n> will have a painful rebase or merge. And people looking at history will\n> have to deal with the code-base having different names at different\n> points. Yeah, you can say it's all just \"content\", but the filenames we\n> put things in are actually useful.\n\nI have been dealing with this quite a bit lately as Chromium has been\ndoing mass renaming. It's no small project and sometimes those merges\nare big:\n\n[diff]\n\trenames = copies\n\trenameLimit = 2000\n\n:-)\n\nWhat I can say is, yes, it's annoying, but also: git does quite a\ndecent job of it. I've found myself having to do this occasionally,\nbut not too often:\n\n  git diff ...MERGE_HEAD -- /path/to/old/name | patch /path/to/new/name\n\n(Typically when a header is renamed, a stub is left in place at the\nold name which just includes the new name, and the local changes don't\ncome across to the new name 100% cleanly.)\n\nAnyway, I would welcome git.git getting a little taste of that. :-) :-) :-)\n\nj.\n"},{"id":"160212","messageId":"20110201111429.GA10165@elie","threadId":"26371","inReplyTo":"201102011342.06910.trast@student.ethz.ch","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-01T11:14:29Z","receivedAt":"2011-02-01T11:14:29Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Thomas Rast wrote:\n\n> In particular a prospective git hacker would not care whether\n> something is a source file or a script (you seem to imply the\n> opposite).  He would instead expect to find git-foo implemented in\n> something named of that sort, so we could probably help him by mapping\n> \n>   git-foo.sh      ->   git-foo.sh\n>   builtin/bar.c   ->   git-bar.c\n>   baz.c           ->   lib/baz.c\n\nI agree.  This sets off my \"time to resist change\" alarms much\nless than \"git mv *.c *.sh src/\", for what it's worth.\n\n>   baz.o           ->   build/baz.o (or whatever, just elsewhere)\n>   baz.gcov        ->   build/baz.gcov (ditto)\n\nMaybe something like this to start?\n\n-- 8< --\nSubject: Makefile: basic support for separate build dir\n\n - python and perl machinery haven't been tweaked yet\n - requires good VPATH support\n - relies on COMPUTE_HEADER_DIRECTORIES to make the object file\n   directories\n - does not support paths with spaces\n\nUsage:\n\n\tmkdir output\n\tcd output\n\techo COMPUTE_HEADER_DIRECTORIES=1 >config.mak\n\tmake -f ../Makefile GIT_SRC=$(pwd)/../ -j2\n\nSigned-off-by: Jonathan Nieder <jrnieder@gmail.com>\n---\n Makefile            |   41 ++++++++++++++++++++++++++---------------\n generate-cmdlist.sh |    4 ++--\n perl/Makefile       |    2 +-\n 3 files changed, 29 insertions(+), 18 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 775ee83..b258a24 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -243,8 +243,18 @@ all::\n #\n # Define NATIVE_CRLF if your platform uses CRLF for line endings.\n \n+# Absolute path to the toplevel of the git sources, with trailing /.\n+# Leave empty for an in-place build.\n+GIT_SRC =\n+ifdef GIT_SRC\n+\tNO_PYTHON = YesPlease\n+\tNO_PERL_MAKEMAKER = YesPlease\n+endif\n+\n+VPATH := $(if $(GIT_SRC),$(GIT_SRC),$(CURDIR))\n+\n GIT-VERSION-FILE: FORCE\n-\t@$(SHELL_PATH) ./GIT-VERSION-GEN\n+\t@$(SHELL_PATH) $(GIT_SRC)/GIT-VERSION-GEN\n -include GIT-VERSION-FILE\n \n uname_S := $(shell sh -c 'uname -s 2>/dev/null || echo not')\n@@ -305,6 +315,7 @@ lib = lib\n pathsep = :\n \n export prefix bindir sharedir sysconfdir gitwebdir\n+export GIT_SRC\n \n CC = gcc\n AR = ar\n@@ -333,7 +344,7 @@ SPARSE_FLAGS = -D__BIG_ENDIAN__ -D__powerpc__\n # Those must not be GNU-specific; they are shared with perl/ which may\n # be built by a different compiler. (Note that this is an artifact now\n # but it still might be nice to keep that distinction.)\n-BASIC_CFLAGS = -I.\n+BASIC_CFLAGS = -I$(GIT_SRC). -I.\n BASIC_LDFLAGS =\n \n # Guard against environment variables\n@@ -1562,7 +1573,7 @@ ifeq ($(PYTHON_PATH),)\n NO_PYTHON=NoThanks\n endif\n \n-QUIET_SUBDIR0  = +$(MAKE) -C # space to separate -C and subdir\n+QUIET_SUBDIR0  = +$(MAKE) -C $(GIT_SRC)# no space before subdir\n QUIET_SUBDIR1  =\n \n ifneq ($(findstring $(MAKEFLAGS),w),w)\n@@ -1582,7 +1593,7 @@ ifndef V\n \tQUIET_GCOV     = @echo '   ' GCOV $@;\n \tQUIET_SUBDIR0  = +@subdir=\n \tQUIET_SUBDIR1  = ;$(NO_SUBDIR) echo '   ' SUBDIR $$subdir; \\\n-\t\t\t $(MAKE) $(PRINT_DIR) -C $$subdir\n+\t\t\t $(MAKE) $(PRINT_DIR) -C $(GIT_SRC)$$subdir\n \texport V\n \texport QUIET_GEN\n \texport QUIET_BUILT_IN\n@@ -1696,10 +1707,10 @@ $(BUILT_INS): git$X\n \tln -s git$X $@ 2>/dev/null || \\\n \tcp git$X $@\n \n-common-cmds.h: ./generate-cmdlist.sh command-list.txt\n+common-cmds.h: generate-cmdlist.sh command-list.txt\n \n common-cmds.h: $(wildcard Documentation/git-*.txt)\n-\t$(QUIET_GEN)./generate-cmdlist.sh > $@+ && mv $@+ $@\n+\t$(QUIET_GEN)$(GIT_SRC)./generate-cmdlist.sh > $@+ && mv $@+ $@\n \n define cmd_munge_script\n $(RM) $@ $@+ && \\\n@@ -1709,7 +1720,7 @@ sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \\\n     -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \\\n     -e 's/@@NO_CURL@@/$(NO_CURL)/g' \\\n     -e $(BROKEN_PATH_FIX) \\\n-    $@.sh >$@+\n+    $(GIT_SRC)$@.sh >$@+\n endef\n \n $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh\n@@ -1729,7 +1740,7 @@ perl/perl.mak: GIT-CFLAGS perl/Makefile perl/Makefile.PL\n \n $(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl\n \t$(QUIET_GEN)$(RM) $@ $@+ && \\\n-\tINSTLIBDIR=`MAKEFLAGS= $(MAKE) -C perl -s --no-print-directory instlibdir` && \\\n+\tINSTLIBDIR=`MAKEFLAGS= $(MAKE) -C $(GIT_SRC)perl -s --no-print-directory instlibdir` && \\\n \tsed -e '1{' \\\n \t    -e '\ts|#!.*perl|#!$(PERL_PATH_SQ)|' \\\n \t    -e '\th' \\\n@@ -1738,7 +1749,7 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl\n \t    -e '\tx' \\\n \t    -e '}' \\\n \t    -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \\\n-\t    $@.perl >$@+ && \\\n+\t    $(GIT_SRC)$@.perl >$@+ && \\\n \tchmod +x $@+ && \\\n \tmv $@+ $@\n \n@@ -1780,7 +1791,7 @@ git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/static/gitweb.css gitweb/\n \t    -e 's/@@NO_CURL@@/$(NO_CURL)/g' \\\n \t    -e 's|@@GITWEBDIR@@|$(gitwebdir_SQ)|g' \\\n \t    -e 's|@@PERL@@|$(PERL_PATH_SQ)|g' \\\n-\t    $@.sh > $@+ && \\\n+\t    $(GIT_SRC)$@.sh > $@+ && \\\n \tchmod +x $@+ && \\\n \tmv $@+ $@\n else # NO_PERL\n@@ -1788,7 +1799,7 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)) git-instaweb: % : unimplemented.sh\n \t$(QUIET_GEN)$(RM) $@ $@+ && \\\n \tsed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \\\n \t    -e 's|@@REASON@@|NO_PERL=$(NO_PERL)|g' \\\n-\t    unimplemented.sh >$@+ && \\\n+\t    $(GIT_SRC)unimplemented.sh >$@+ && \\\n \tchmod +x $@+ && \\\n \tmv $@+ $@\n endif # NO_PERL\n@@ -1803,7 +1814,7 @@ $(patsubst %.py,%,$(SCRIPT_PYTHON)): % : %.py\n \tsed -e '1s|#!.*python|#!$(PYTHON_PATH_SQ)|' \\\n \t    -e 's|\\(os\\.getenv(\"GITPYTHONLIB\"\\)[^)]*)|\\1,\"@@INSTLIBDIR@@\")|' \\\n \t    -e 's|@@INSTLIBDIR@@|'\"$$INSTLIBDIR\"'|g' \\\n-\t    $@.py >$@+ && \\\n+\t    $(GIT_SRC)$@.py >$@+ && \\\n \tchmod +x $@+ && \\\n \tmv $@+ $@\n else # NO_PYTHON\n@@ -1811,7 +1822,7 @@ $(patsubst %.py,%,$(SCRIPT_PYTHON)): % : unimplemented.sh\n \t$(QUIET_GEN)$(RM) $@ $@+ && \\\n \tsed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \\\n \t    -e 's|@@REASON@@|NO_PYTHON=$(NO_PYTHON)|g' \\\n-\t    unimplemented.sh >$@+ && \\\n+\t    $(GIT_SRC)unimplemented.sh >$@+ && \\\n \tchmod +x $@+ && \\\n \tmv $@+ $@\n endif # NO_PYTHON\n@@ -2142,7 +2153,7 @@ test-%$X: test-%.o $(GITLIBS)\n \t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(filter %.a,$^) $(LIBS)\n \n check-sha1:: test-sha1$X\n-\t./test-sha1.sh\n+\t$(GIT_SRC)./test-sha1.sh\n \n check: common-cmds.h\n \tif sparse; \\\n@@ -2229,7 +2240,7 @@ endif\n \t\tln -s \"git-remote-http$X\" \"$$execdir/$$p\" 2>/dev/null || \\\n \t\tcp \"$$execdir/git-remote-http$X\" \"$$execdir/$$p\" || exit; \\\n \tdone && \\\n-\t./check_bindir \"z$$bindir\" \"z$$execdir\" \"$$bindir/git-add$X\"\n+\t$(GIT_SRC)./check_bindir \"z$$bindir\" \"z$$execdir\" \"$$bindir/git-add$X\"\n \n install-gitweb:\n \t$(MAKE) -C gitweb install\ndiff --git a/generate-cmdlist.sh b/generate-cmdlist.sh\nindex 75c68d9..f718633 100755\n--- a/generate-cmdlist.sh\n+++ b/generate-cmdlist.sh\n@@ -9,7 +9,7 @@ struct cmdname_help\n \n static struct cmdname_help common_cmds[] = {\"\n \n-sed -n -e 's/^git-\\([^ \t]*\\)[ \t].* common.*/\\1/p' command-list.txt |\n+sed -n -e 's/^git-\\([^ \t]*\\)[ \t].* common.*/\\1/p' \"$GIT_SRC\"command-list.txt |\n sort |\n while read cmd\n do\n@@ -19,6 +19,6 @@ do\n             x\n             s/.*git-'\"$cmd\"' - \\(.*\\)/  {\"'\"$cmd\"'\", \"\\1\"},/\n \t    p\n-     }' \"Documentation/git-$cmd.txt\"\n+     }' \"${GIT_SRC}Documentation/git-$cmd.txt\"\n done\n echo \"};\"\ndiff --git a/perl/Makefile b/perl/Makefile\nindex a2ffb64..7c3a82a 100644\n--- a/perl/Makefile\n+++ b/perl/Makefile\n@@ -44,4 +44,4 @@ endif\n # this is just added comfort for calling make directly in perl dir\n # (even though GIT-CFLAGS aren't used yet. If ever)\n ../GIT-CFLAGS:\n-\t$(MAKE) -C .. GIT-CFLAGS\n+\t$(MAKE) -C $(GIT_SRC).. GIT-CFLAGS\n-- \n1.7.2.3\n"},{"id":"160213","messageId":"20110201112202.GC10165@elie","threadId":"26371","inReplyTo":"20110201111429.GA10165@elie","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-01T11:22:02Z","receivedAt":"2011-02-01T11:22:02Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jonathan Nieder wrote:\n\n> \tmkdir output\n> \tcd output\n> \techo COMPUTE_HEADER_DIRECTORIES=1 >config.mak\n> \tmake -f ../Makefile GIT_SRC=$(pwd)/../ -j2\n\nErm, COMPUTE_HEADER_DEPENDENCIES.  Anyway, if someone wants to make\nsetting GIT_SRC take care of making the directories automatically, I\nwouldn't mind. ;-)\n"},{"id":"160163","messageId":"201102011342.06910.trast@student.ethz.ch","threadId":"26371","inReplyTo":"alpine.LFD.2.00.1101312238170.8580@xanadu.home","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-02-01T12:42:06Z","receivedAt":"2011-02-01T12:42:06Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Nicolas Pitre wrote:\n> What I see in the root of the Git source \n> tree is a huge clutter of source files, binary files, scripts, and \n> subdirectories all mixed together.  If you know by hart where things are \n> because you've been hacking on them for the last 5 years then of course \n> you might not see the point.  But since I didn't work much on Git \n> lately, things are not as obvious to me as they used to be.  Looking \n> back at it now with some distance, this tree looks like a mess and it is \n> really annoying to work with.\n\nBut judging by that assessment, shouldn't we strive to make it\n*easier* to find things?\n\nIn particular a prospective git hacker would not care whether\nsomething is a source file or a script (you seem to imply the\nopposite).  He would instead expect to find git-foo implemented in\nsomething named of that sort, so we could probably help him by mapping\n\n  git-foo.sh      ->   git-foo.sh\n  builtin/bar.c   ->   git-bar.c\n  baz.c           ->   lib/baz.c\n  baz.o           ->   build/baz.o (or whatever, just elsewhere)\n  baz.gcov        ->   build/baz.gcov (ditto)\n\n\n(I'm no huge fan of src/ either, but this should be orthogonal.)\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"160164","messageId":"alpine.LFD.2.00.1102010805420.8580@xanadu.home","threadId":"26371","inReplyTo":"201102011342.06910.trast@student.ethz.ch","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-02-01T13:08:14Z","receivedAt":"2011-02-01T13:08:14Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 1 Feb 2011, Thomas Rast wrote:\n\n> Nicolas Pitre wrote:\n> > What I see in the root of the Git source \n> > tree is a huge clutter of source files, binary files, scripts, and \n> > subdirectories all mixed together.  If you know by hart where things are \n> > because you've been hacking on them for the last 5 years then of course \n> > you might not see the point.  But since I didn't work much on Git \n> > lately, things are not as obvious to me as they used to be.  Looking \n> > back at it now with some distance, this tree looks like a mess and it is \n> > really annoying to work with.\n> \n> But judging by that assessment, shouldn't we strive to make it\n> *easier* to find things?\n> \n> In particular a prospective git hacker would not care whether\n> something is a source file or a script (you seem to imply the\n> opposite).  He would instead expect to find git-foo implemented in\n> something named of that sort, so we could probably help him by mapping\n> \n>   git-foo.sh      ->   git-foo.sh\n>   builtin/bar.c   ->   git-bar.c\n>   baz.c           ->   lib/baz.c\n>   baz.o           ->   build/baz.o (or whatever, just elsewhere)\n>   baz.gcov        ->   build/baz.gcov (ditto)\n\nI'm not proposing to go that far, especially given the current \nresistance to any changes.  IMHO anything that unclutters the top \ndirectory is good.\n\nNicolas\n"},{"id":"160172","messageId":"4D481BC4.2050104@op5.se","threadId":"26371","inReplyTo":"alpine.LFD.2.00.1101311621150.8580@xanadu.home","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2011-02-01T14:42:12Z","receivedAt":"2011-02-01T14:42:12Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 01/31/2011 10:28 PM, Nicolas Pitre wrote:\n> On Mon, 31 Jan 2011, Jeff King wrote:\n> \n>> On Mon, Jan 31, 2011 at 03:28:37PM -0500, Nicolas Pitre wrote:\n>>\n>>> We do have subdirectories for documentation, tests, contributions, etc.\n>>> But a sizeable part of the tree is just a big splat of source files\n>>> dumped right in the root of the tree.\n>>>\n>>> So I'd suggest doing the following:\n>>>\n>>> 1) Create a src/ directory and move *.c, *.h, *.sh, *.perl, *.py and\n>>>     the builtin directory from the root directory to it.\n>>\n>> Wouldn't this just be the same giant splat of source files, but in a\n>> different tree? I don't really see the advantage, and it seems like an\n>> extra annoyance.\n> \n> Like I said to Junio, if you don't see the advantage, there's nothing I\n> can do for you.  To me this is simple good source code hygiene.\n> \n>> Besides being just one more directory to go up and down, it does make\n>> history browsing more annoying. As much as I love git's \"don't record\n>> renames\" philosophy, our handling of renames on the viewing side is\n>> often annoying. I already get annoyed sometimes following stuff across\n>> the s!builtin-!builtin/! change. This would be like that but more so.\n> \n> So... we do suck at something?  So why not take this opportunity to\n> shake yourself out of this easy comfort and improve Git as a result on\n> both front?  :-)\n> \n>> Or maybe it is a good thing for that reason, as we will eat our own\n>> rename dogfood. :)\n> \n> Exactly!  And maybe we'll make Git even more useful in the process.\n> \n>>> 5) Rename t/ to testsuite/ so this doesn't look like some garbage\n>>>     leftover.\n>>\n>> Ugh, more typing. :P\n> \n> Come on!  You sound like an old fart now!  ;-)\n> \n\nPersonally, I kinda like the capital D in Documentation for tab\ncompletion reasons. Keeping frequently used files and directories\nwith short unique prefixes makes perfect sense from a typing point\nof view. Using longer mnemonic names makes perfect sense from a\nregex search/replace point of view.\n\nI'm kinda with Junio on the ./*.[ch] -> src/*.[ch] move though, but\nperhaps that's just because I hate autoconf projects which generate\na ton of cruft in the root before one can even start building it.\n\nIt would probably help matters along if buildproducts ended up in\ntheir own directory though. That way .gitignore won't have so many\nextra commits when new source files are added, and 'make clean'\ngets easier to maintain.\n\nSo to sum up what I'm for;\n\nt/ -> Test/ (or Testsuite, but some more mnemonic name anyways\nwith a short unique prefix for tab completion). This would also\nexercise our rename machinery quite a bit, altohugh not to the\npoint where people get annoyed if it gets sort-of-broken.\n\nbuildproducts to Build/ (capital B to avoid completing against\nbuiltin*). This also has the benefit that %.o: %.c rules makes\ntab completion work better when object files are already built,\nand \"git add git-foo.*\" doesn't throw the \"git-foo.o is ignored\"\nerror and forces one to re-type it as \"git-foo.[ch]\"\n\nThe ppc stuff I don't really care about and it wouldn't be hard\nto resurrect if we remove it and people complain. Everything\nwill also still work if we do, although with possibly a slight\ndecrease in performance.\n\nBulk of source-files stay as ./*.[ch]. I see absolutely no\nbenefit to moving them, but two potential drawbacks. One is that\nit'll cause more typing for those of us who use console-based\neditors and run 'make' manually (yes, we do exist). The afore-\nmentioned merge+rebase hell is also a considerable drawback,\neven though that's primarily an issue for maint releases.\n\nRisks: Well... dunno about that really. Mucking up the build and\ntest systems, I suppose, but it's easy enough to test.\n\nCons: Rebasing and merging stuff to the Makefile and test-stuff\nwill suck a bit, but as has been pointed out that's not only a\nbad thing.\n\nPros: Less typing all-round. Simpler \"make clean\" rules. Fewer\ntacked-on .gitignore patches for new commands. We (well, Junio)\nget to experience first-hand the problems of directory renames\nacross releases but on a smaller scale than moving *everything*\naround in one go.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"160175","messageId":"4D481EA0.9090802@xiplink.com","threadId":"26371","inReplyTo":"AANLkTikeqsg+qJ0z4iQ6ZmKL=_HB8YX_z20L=dFFApmA@mail.gmail.com","subject":"[1.8.0] Tag namespaces","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-02-01T14:54:24Z","receivedAt":"2011-02-01T14:54:24Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 11-01-31 10:20 PM, Nguyen Thai Ngoc Duy wrote:\n> On Tue, Feb 1, 2011 at 12:05 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Now the 1.7.4 release is out, I'd like people to help thinking about the\n>> next cycle(s).\n>>\n>> As a discussion-starter, here are my random wishes.  Even though this does\n>> not attempt to be exhaustive, keeping the number of goals manageably small\n>> may help us focus.\n> \n> Another random wish, which does not come with a proposal. How about\n> tag namespace (ie. tags from a remote stay in remote namespace)?\n\nI had just started writing up such a proposal yesterday.  What I have so far\nis pretty preliminary:\n\n\nProposal:\n\nChange tag refspecs to distinguish between remote and local tags.  An\nunadorned tag \"foo\" could point to different commits in different\nrepositories.  A remote could move/edit it's \"foo\" tag and have that update\nsmoothly propagated to clones.\n\nI believe this was last brought up in November while discussing the refs base\nfor notes:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/160503/focus=160655\n\n\nRisks:\n\nI think the main risk lies in breaking plain <tagname> refs, as they would\nbecome \"origin/<tagname>\" refs instead.  But I think that can be mitagated\nagainst (see below).\n\nThe other risk folks might raise, though I disagree, is breaking the\nimmutability assumption for tags.  I'm willing to debate this, though (see\nthe above-linked thread).\n\nAnother \"risk\" is that this change might be too much of an earthquake.  It\nmay be something more suitable to a major release, like 2.0.\n\n\nMigration plan:\n\nAdd a \"tags.relative\" (name TBD) configuration variable which defaults to\nfalse.  When tags.relative is true, \"git fetch\" puts any received tags under\n(location TBD) refs/remotes/<remote>/tags/.  In 1.8.0 we flip tags.realtive's\ndefault value.\n\nTo help mitigate the risk of breaking plain \"<tagname>\" refs, \"git rev-parse\"\ncan look for plain names (i.e. ones without a /) in the remote tags location.\n\n\n\t\tM.\n"},{"id":"160176","messageId":"AANLkTinQBQaL0zE+EYAADPBhroi71sgKAcprCjLy_SKB@mail.gmail.com","threadId":"26371","inReplyTo":"7voc6x57el.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [1.8.0] Unify \"pathspec\" semantics","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-01T14:56:06Z","receivedAt":"2011-02-01T14:56:06Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Feb 1, 2011 at 12:07 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Some projects may track a file whose name is asterisk (e.g. \"foo/*\") and\n> output from \"git log 'foo/*'\" would look different.  Before the change,\n> only commits that touch that exact path would be shown, but after the\n> change, any commit that touch a path underneath \"foo/\" directory will be\n> shown.  This is a backward incompatible change.\n\nCan we support quoting wildcards? I can imagine a file name such as\n'***DO NOT DO IT***'. People who wish to match exactly that file would\nhave hard time ahead without a way to tell git those stars are\nliteral.\n\nA prefix/special leading symbol or cmdline option to indicate the\ngiven pathspec is literal is fine too (e.g \"!literal:***hey***\" or\n--literal \"***hey***\"). In fact I can extend that to support negative\npathspecs.\n-- \nDuy\n"},{"id":"160178","messageId":"201102011614.57366.trast@student.ethz.ch","threadId":"26371","inReplyTo":"AANLkTikxcd+gzeuJsQX1V5Wses8xWMnshdrOnYTvXgTq@mail.gmail.com","subject":"Re: [1.8.0] forbid full fetchspecs in git-pull","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-02-01T15:14:57Z","receivedAt":"2011-02-01T15:14:57Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Dmitry Potapov wrote:\n> As to disallowing ':' in refspec completely, I am not so sure... Not\n> that I think it is very useful, but also I don't see how it can hurt\n> someone provided that the target branch cannot be the current branch.\n\nIRC experience shows that people, while on some topic branch, run\n\n  git pull origin master:master\n\nexpecting it to \"pull master into master\" (or even worse with three\ndifferent branch names).  So no, the current branch safeguard does\nnot prevent the fundamental mistake.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"160179","messageId":"AANLkTi=kwU+-UxfnCnDj0dD2NLPovTTsCPbSf-RQ3L5P@mail.gmail.com","threadId":"26371","inReplyTo":"4D481EA0.9090802@xiplink.com","subject":"Re: [1.8.0] Tag namespaces","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-01T15:21:32Z","receivedAt":"2011-02-01T15:21:32Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Feb 1, 2011 at 9:54 PM, Marc Branchaud <marcnarc@xiplink.com> wrote:\n> On 11-01-31 10:20 PM, Nguyen Thai Ngoc Duy wrote:\n>> On Tue, Feb 1, 2011 at 12:05 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>>> Now the 1.7.4 release is out, I'd like people to help thinking about the\n>>> next cycle(s).\n>>>\n>>> As a discussion-starter, here are my random wishes.  Even though this does\n>>> not attempt to be exhaustive, keeping the number of goals manageably small\n>>> may help us focus.\n>>\n>> Another random wish, which does not come with a proposal. How about\n>> tag namespace (ie. tags from a remote stay in remote namespace)?\n>\n> I had just started writing up such a proposal yesterday.  What I have so far\n> is pretty preliminary:\n\nThanks. I wrote another proposal (should we have more or less standard\n\"Git Enhancement Proposal\" process like Python's PEP or Scheme's SRFI\nto keep track of these over time?) but it's good to see others look at\nit too.\n\n> Proposal:\n>\n> Change tag refspecs to distinguish between remote and local tags.  An\n> unadorned tag \"foo\" could point to different commits in different\n> repositories.  A remote could move/edit it's \"foo\" tag and have that update\n> smoothly propagated to clones.\n>\n> I believe this was last brought up in November while discussing the refs base\n> for notes:\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/160503/focus=160655\n\nOne problem with the proposed ref layout is that it breaks current\nlayout (remotes/<remote>/head -> remotes/<remote>/heads/head). Some\nsort of migration support is needed. On the other hand, new layout is\ncleaner than my proposal (remote-tags/<remote>/tag).\n\n> Risks:\n>\n> I think the main risk lies in breaking plain <tagname> refs, as they would\n> become \"origin/<tagname>\" refs instead.  But I think that can be mitagated\n> against (see below).\n> ...\n> To help mitigate the risk of breaking plain \"<tagname>\" refs, \"git rev-parse\"\n> can look for plain names (i.e. ones without a /) in the remote tags location.\n\nHmm I thought \"a-ref\" would check \"refs/tags/a-ref\" and\n\"refs/remotes/*/a-ref\". But you are right. Maybe \"tags.relative\" can\ntake three values instead of boolean (names TBD):\n\n - deprecated (current behavior)\n - migrating (fetch tags to refs/remotes, but tag lookup will look in\nrefs/tags as well as refs/remotes/*/tags)\n - migrated (fetch tags to refs/remotes, look up in order)\n\nWe may slowly turn default value step by step until it becomes \"migrated\".\n-- \nDuy\n"},{"id":"160182","messageId":"AANLkTinns+M1=50jj7RAFnnp6-WPv+CpuWkO0xq_qko9@mail.gmail.com","threadId":"26371","inReplyTo":"AANLkTi=Y9PBs_jXyCiAL9YLA8Y_jzWwqxw63hKm7fVBO@mail.gmail.com","subject":"Re: [1.8.0] make two-argument fetch update remote branches","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-01T15:58:11Z","receivedAt":"2011-02-01T15:58:11Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Feb 1, 2011 at 2:04 PM, Jay Soffian <jaysoffian@gmail.com> wrote:\n> On Mon, Jan 31, 2011 at 4:44 PM, Thomas Rast <trast@student.ethz.ch> wrote:\n>> Add a fetch.updateRemoteNamespace (or so) configuration variable that\n>> defaults to false.  When enabled, it turns on the auto-updating\n>> behaviour.\n>\n> Would it make sense to group the pre-1.8 compatibility switches\n> together in some way, if there will be several of them? Maybe\n>\n> [compat]\n>   fetchUpdateRemoteNamespace = false\n>   ...\n\nIt is. I was thinking of it as a group of \"short\"-lived configs to\nhelp maintain backward compatibility for some time (not for ever)\nuntil users are forced to migrate.\n-- \nDuy\n"},{"id":"160183","messageId":"AANLkTimgv6Hhbu8B9wiydwn9WQrgKfmT+hEyJKbkO6RB@mail.gmail.com","threadId":"26371","inReplyTo":"201102011342.06910.trast@student.ethz.ch","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-01T16:02:48Z","receivedAt":"2011-02-01T16:02:48Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Feb 1, 2011 at 7:42 PM, Thomas Rast <trast@student.ethz.ch> wrote:\n> Nicolas Pitre wrote:\n>> What I see in the root of the Git source\n>> tree is a huge clutter of source files, binary files, scripts, and\n>> subdirectories all mixed together.  If you know by hart where things are\n>> because you've been hacking on them for the last 5 years then of course\n>> you might not see the point.  But since I didn't work much on Git\n>> lately, things are not as obvious to me as they used to be.  Looking\n>> back at it now with some distance, this tree looks like a mess and it is\n>> really annoying to work with.\n>\n> But judging by that assessment, shouldn't we strive to make it\n> *easier* to find things?\n>\n> In particular a prospective git hacker would not care whether\n> something is a source file or a script (you seem to imply the\n> opposite).  He would instead expect ...\n\nA hacker is expected to RTFM first, IMO. Put up a document describing\nhow things are organized in git and we're good. git-grep will take\ncare from there.\n-- \nDuy\n"},{"id":"160201","messageId":"m38vxzaa03.fsf_-_@localhost.localdomain","threadId":"26371","inReplyTo":"alpine.LFD.2.00.1101311459000.8580@xanadu.home","subject":"[1.8.0] split largest remaining scripts, gitk and gitweb","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-02-01T18:26:08Z","receivedAt":"2011-02-01T18:26:08Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Two largest files in git repository are gitk and gitweb, see the\noutput of the following command\n\n  $ git ls-tree --abbrev -r -t -l v1.7.4 | sort -k4,4 -n | tail\n\nI can't say much about splitting gitk, besides the fact that git-gui\nwhich was of comparable size IIRC got split into smaller files; I\nguess similar thing could be done for gitk.\n\n\nThere was an attempt (ultimately failed) on splitting gitweb during\nGoogle Summer of Code 2010.  At least providing infrastructure for\nmultiple gitweb modules is very much required for adding\ncode-intensive new features, like gitweb output caching.\n\nOn the other hand this might make gitweb harder to install...\n\n\nNext in size is compat/nedmalloc/malloc.c.h (I don't know if it can be\nreduced in size), and git-svn.  I think we could separate core\nfunctionality into Git::Svn module or something, and make git-svn\nsmaller (perhaps reusing some code in/from svn remote helper).\n\n\nWhat do you think?\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"160203","messageId":"AANLkTimHCp_JKUw1keJoA4zD_q7Sci+rOwPeAs_T=7xH@mail.gmail.com","threadId":"26371","inReplyTo":"20110131225529.GC14419@sigill.intra.peff.net","subject":"Re: [1.8.0] (v2) default \"git merge\" without argument to \"git merge @{u}\"","fromName":"Scott Chacon","fromEmail":"schacon@gmail.com","sentAt":"2011-02-01T18:34:24Z","receivedAt":"2011-02-01T18:34:24Z","isPatch":false,"sender":{"key":"schacon@gmail.com","avatar":"https://gravatar.com/avatar/9b13a8a078e1dcf8588c4eea9554445d51ebed6c41b51f56f4d96738130b05c6?d=mp&s=160"},"body":"Hey,\n\nOn Mon, Jan 31, 2011 at 2:55 PM, Jeff King <peff@peff.net> wrote:\n> On Mon, Jan 31, 2011 at 12:50:30PM -0800, Junio C Hamano wrote:\n>\n>> Perhaps I should start a new directory in todo branch (say, 1.8.0), accept\n>> patches from people?  I'd grudgingly admit that using Wiki on k.org may be\n>> less burdensome (I hate editing inside the browser myself), but I'd want\n>> to keep the mailing list the center of discussion and am afraid that\n>> forcing people to go to Wiki would fragment the discussion.\n>\n> I really wish we had a git-backed wiki. I also hate using the browser\n> for such things (though browser extensions to edit textareas in a Real\n> Editor at least make it tolerable, it still ends up clunky).\n>\n> GitHub's wiki gets this right. I'm not saying we should host our wiki\n> there (well, it _would_ make setting it up pretty damn easy). But their\n> wiki system (gollum) is open-source, albeit in ruby. And surely there\n> are other git-backed alternatives (it's been a while since I've looked).\n\nIf you want to use the wiki on the git/git repo on GitHub that is\nbeing mirrored from the canonical repository, I've added Junio and\npeff to the account.  If you want to use that wiki, anyone with a\ngithub account can edit wiki pages on the site or clone and edit it\nlocally and push changes up.  You can also turn off site edits so\npeople have to send Junio a patch instead.  It's up to you guys, but\nthe access is there now if you want.\n\nScott\n"},{"id":"160205","messageId":"4D4852EE.6080605@lsrfire.ath.cx","threadId":"26371","inReplyTo":"7vwrll57ha.fsf@alter.siamese.dyndns.org","subject":"[1.8.0] Remove deprecated commands","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2011-02-01T18:37:34Z","receivedAt":"2011-02-01T18:37:34Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"The following four commands have been marked as deprecated in\ncommand-list.txt for quite some time[*]:\n\n   command          deprecated since replaced by\n   ---------------- ---------------- ---------------------\n   git-lost-found   2007-11-08       git fsck --lost-found\n   git-peek-remote  2007-11-24       git ls-remote\n   git-repo-config  2008-01-17       git config\n   git-tar-tree     2007-11-08       git archive\n\nLet's just remove them.  There's a risk that someone is still using the\nold commands, of course, but they have been deprecated long enough now.\n\n\n[*] data source:\n    git blame -C command-list.txt |\n    sed -n 's/.*\\(....-..-..\\).*\\(git-[^ ]*\\).*deprecated.*/\\2\\t\\1/p'\n"},{"id":"160211","messageId":"20110201201144.GA16003@sigill.intra.peff.net","threadId":"26371","inReplyTo":"AANLkTimHCp_JKUw1keJoA4zD_q7Sci+rOwPeAs_T=7xH@mail.gmail.com","subject":"moving to a git-backed wiki","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-01T20:11:44Z","receivedAt":"2011-02-01T20:11:44Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 01, 2011 at 10:34:24AM -0800, Scott Chacon wrote:\n\n> > GitHub's wiki gets this right. I'm not saying we should host our wiki\n> > there (well, it _would_ make setting it up pretty damn easy). But their\n> > wiki system (gollum) is open-source, albeit in ruby. And surely there\n> > are other git-backed alternatives (it's been a while since I've looked).\n> \n> If you want to use the wiki on the git/git repo on GitHub that is\n> being mirrored from the canonical repository, I've added Junio and\n> peff to the account.  If you want to use that wiki, anyone with a\n> github account can edit wiki pages on the site or clone and edit it\n> locally and push changes up.  You can also turn off site edits so\n> people have to send Junio a patch instead.  It's up to you guys, but\n> the access is there now if you want.\n\nOut of curiosity, I scraped the kernel wiki and put it into gollum. The\nresults are here, if people want to see what it looks like:\n\n  https://github.com/peff/foo/wiki\n\nIt's extremely quick and dirty, which is why I didn't put it in the\nactual git/git/wiki spot you made. Some of the formatting is off (note\nthat I didn't do any conversion; it understands mediawiki natively), and\nsome of the content is probably missing (my scraper was extremely\nnaive). For a real import I would try to get the actual wiki db from\nkernel.org and import the entire history.\n\nI dunno what the next step would be. I would really prefer a git-backed\nwiki, but moving to something like this is a pretty big step in workflow\nfor people who use the current wiki. I would be curious to hear general\nopinions (on the idea of moving, assuming we did a conversion that\nactually looked good). I'll change the subject and see if we get any\ncomments.\n\n-Peff\n"},{"id":"160215","messageId":"AANLkTi=YsYXTHT-3RgaFF38hwK7O6mt+Ba0bZvEHPEWM@mail.gmail.com","threadId":"26371","inReplyTo":"201102011614.57366.trast@student.ethz.ch","subject":"Re: [1.8.0] forbid full fetchspecs in git-pull","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2011-02-01T20:23:47Z","receivedAt":"2011-02-01T20:23:47Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Tue, Feb 01, 2011 at 04:14:57PM +0100, Thomas Rast wrote:\n> Dmitry Potapov wrote:\n> > As to disallowing ':' in refspec completely, I am not so sure... Not\n> > that I think it is very useful, but also I don't see how it can hurt\n> > someone provided that the target branch cannot be the current branch.\n>_\n> IRC experience shows that people, while on some topic branch, run\n>_\n>   git pull origin master:master\n>_\n> expecting it to \"pull master into master\" (or even worse with three\n> different branch names).  So no, the current branch safeguard does\n> not prevent the fundamental mistake.\n\nI am not sure what you mean by three different branches names. You\nreferred to item 1, and I agree it is confusing, but it can be prevented\nby the current branch safeguard.\n\nand the current semantic of \"git pull\" is very clear:\n\n\"git pull repo refspec\" = \"git fetch repo refspec && git merge FETCH_HEAD\"\n\nIMHO, the full confusion was caused by incorrect information on github,\nwhich was corrected a long time ago. Have you heard about any new\nusers who are confused by git-pull?\n\nAnd if we really want to disallow ':' in git pull refspec then the\ndocumentation should be corrected too. For instance, if there are\noptions to git fetch that make no sense if you cannot specify lbranch.\nAlso description of refspec should be corrected in git pull man page.\n\n\nDmitry\n"},{"id":"160216","messageId":"4D4875B2.4070008@gmail.com","threadId":"26371","inReplyTo":"201101312244.10047.trast@student.ethz.ch","subject":"Re: [1.8.0] make two-argument fetch update remote branches","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2011-02-01T21:05:54Z","receivedAt":"2011-02-01T21:05:54Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"On 01/31/2011 04:44 PM, Thomas Rast wrote:\n> Proposal:\n>\n> Running \"git fetch origin master\" only updates FETCH_HEAD, not\n> origin/master, which turns out to be quite confusing for newcomers\n> especially after running 'git pull origin master'.\n>\n> Since the remote branches in some sense reflect the \"last known state\"\n> of the remote, it would make sense to also update them to whatever a\n> two-argument fetch got.\n>\n\nIf this is proposing to break:\n\n\tget-fetch ${REPO} ${SRC_REF}:${DST_REF}\n\nthen I am against this since that form _is_ used and *is* plumbing.\n"},{"id":"160225","messageId":"4D487DF7.8060109@web.de","threadId":"26371","inReplyTo":"7vwrll57ha.fsf@alter.siamese.dyndns.org","subject":"[1.8.0] Handle submodule config options consistently in diff plumbing","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-02-01T21:41:11Z","receivedAt":"2011-02-01T21:41:11Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Proposal:\n\nHandle the submodule options \"diff.ignoreSubmodules\" and\n\"submodule.<name>.ignore\" consistently in diff plumbing.\n\nI see two basic ways to change the behavior of the plumbing diff\ncommands:\n\na) Let them use the \"diff.ignoreSubmodules\" configuration too.\n\nb) Don't let them use the \"submodule.<name>.ignore\" entries either.\n   But if we go that way, we might have to revert the default of\n   recursing into populated submodules too, as it might cause\n   unexpected behavior when all configuration options introduced\n   to control that recursion are just ignored unless explicitly\n   told otherwise.\n\n\nHistory:\n\nWhen the submodule recursion for the diff commands was introduced,\nall diff commands - including plumbing - learned to recurse into\nsubmodules by default. This was done to mark submodules with\nuncommitted changes as dirty so no user could accidentally forget\nto commit his changes there before pushing in the superproject.\n\nSome time after that \"--ignore-submodules\" learned some values to\nachieve more control over what conditions mark a submodule dirty.\nThen the \"submodule.<name>.ignore\" option was added to .git/config\nand the .gitmodules file to to be able to specify these values for\none or more submodules. In a later commit the \"diff.ignoreSubmodules\"\noption was added, but the plumbing diff commands weren't taught to\nuse that config option.\n\n\nRisks:\n\na) Those scripts which depend on the plumbing commands to ignore\n   the setting from \"diff.ignoreSubmodules\" will break.\n\nb) All scripts written or changed since 1.7.0 which depend on the\n   current behavior to recurse into submodules and use the\n   \"submodule.<name>.ignore\" entries will be broken.\n\nMe thinks the risks are much smaller when doing a), as people who\nlearned to use the recursive behavior since 1.7.0 will see that\nchanged under their feet when we do b) and I expect much more code\nto rely on the recursion than on the \"diff.ignoreSubmodules\"\nsetting. And doing a) would fix a real life problem too, see [1].\n\n\nMigration plan:\n\na) During the 1.7.x series a new \"noconfig\" value is added for the\n   \"--ignore-submodules\" command line option for people who don't\n   want user configuration to interfere with the recursion, e.g. in\n   scripts (turning off the recursion is already implemented, just\n   use the \"--ignore-submodules\" option). And then starting with\n   1.8.0 \"diff.ignoreSubmodules\" will be used by diff plumbing.\n\nb) During the 1.7.x series a new value for \"--ignore-submodules\"\n   called \"porcelain\" is added which enables recursion and also\n   tells diff plumbing use all configuration settings. Then all\n   relevant call sites (like git gui, gitk and PS1 from completion\n   and others) are changed to use this option. Changing the default\n   behavior to ignore \"submodule.<name>.ignore\" and to not recurse\n   anymore will be done in the 1.8.0 release.\n\nPersonally I'm in favor of solution a), but lets hear what other\npeople say.\n\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/164166/focus=164172\n"},{"id":"160228","messageId":"7v1v3rzaj7.fsf@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"20110201014807.GA2722@sigill.intra.peff.net","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-01T21:53:48Z","receivedAt":"2011-02-01T21:53:48Z","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, Jan 31, 2011 at 07:29:54PM -0500, Nicolas Pitre wrote:\n>\n>> > Yes, we do suck at rename following. The problem is that it is partially\n>> [...]\n>> This is no excuse not to do proper source tree reorganization.\n>\n> I think this is the crux of our disagreement. I don't agree that your\n> proposal is any way more \"proper\" than what is there now. Leaving the\n> rename issue aside (i.e., if we were starting a new project), I would\n> still be slightly against a src/ directory. I find them annoying.\n>\n> But I don't care _that_ much, and I would rather not waste either of our\n> time debating it more. I would much rather you spend your time on\n> pack v4. :)\n\nI am with you, both counts on this topic.  I don't necessarily agree that\nhaving sources at the top-level is bad, I don't want to see Nico wasting\nhis time arguing, and I do see some value in the proposal that gives us an\nopportunity for dogfooding (but we already have done so with builtin/ and\nit was not all that annoying---I think the timing was rather good and the\ntree was semi-quiescent).\n\nEhh, that makes it not \"both\" but \"two and half\" counts ;-).\n\nAs long as the new directories are named sanely (one of the things I\ndetest is abbreviated uppercase silliness like \"Src\", \"Lib\"), I am fine\nwith the proposal.  Also I have a mild preference to keep build-products\nnext to the source (i.e. no separate \"obj\" directory).\n"},{"id":"160229","messageId":"7vwrljxv8w.fsf@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"AANLkTi=Y9PBs_jXyCiAL9YLA8Y_jzWwqxw63hKm7fVBO@mail.gmail.com","subject":"Re: [1.8.0] make two-argument fetch update remote branches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-01T22:09:19Z","receivedAt":"2011-02-01T22:09:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jay Soffian <jaysoffian@gmail.com> writes:\n\n> Would it make sense to group the pre-1.8 compatibility switches\n> together in some way, if there will be several of them? Maybe\n>\n> [compat]\n>    fetchUpdateRemoteNamespace = false\n>    ...\n\nI don't think so.\n\nIf these configuration variables are expected to be removed in some\nfuture, such a layout might make sense, but what is proposed is to default\nthem to a different behaviour from today at 1.8.0 boundary, and we are not\ngoing to remove the ability to invoke the current behaviour with these\nvariables.  It would make it a lot easier to find and understand if the\nvariables are grouped by functionality like all the other regular\nvariables, as these new ones are after all regular ones.\n\nJust thinking aloud, too.\n"},{"id":"160230","messageId":"7vsjw7xuy3.fsf@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"m38vxzaa03.fsf_-_@localhost.localdomain","subject":"Re: [1.8.0] split largest remaining scripts, gitk and gitweb","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-01T22:15:48Z","receivedAt":"2011-02-01T22:15:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> Two largest files in git repository are gitk and gitweb, see the\n> ...\n> What do you think?\n\nWhat does this have to do anything with 1.8.0?  Isn't this all internal\nimplementation that can be brought in without affecting end users?\n"},{"id":"160231","messageId":"7voc6vxux9.fsf@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"4D4852EE.6080605@lsrfire.ath.cx","subject":"Re: [1.8.0] Remove deprecated commands","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-01T22:16:18Z","receivedAt":"2011-02-01T22:16:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:\n\n> The following four commands have been marked as deprecated in\n> command-list.txt for quite some time[*]:\n>\n>    command          deprecated since replaced by\n>    ---------------- ---------------- ---------------------\n>    git-lost-found   2007-11-08       git fsck --lost-found\n>    git-peek-remote  2007-11-24       git ls-remote\n>    git-repo-config  2008-01-17       git config\n>    git-tar-tree     2007-11-08       git archive\n>\n> Let's just remove them.  There's a risk that someone is still using the\n> old commands, of course, but they have been deprecated long enough now.\n\nSounds fine.\n"},{"id":"160232","messageId":"AANLkTikfzzELUaN3B+20rh9D51St8mUYs4p-WYjp8JVV@mail.gmail.com","threadId":"26371","inReplyTo":"20110201201144.GA16003@sigill.intra.peff.net","subject":"Re: moving to a git-backed wiki","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-01T22:36:49Z","receivedAt":"2011-02-01T22:36:49Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Tue, Feb 1, 2011 at 3:11 PM, Jeff King <peff@peff.net> wrote:\n>  https://github.com/peff/foo/wiki\n\nA git-backed git wiki would be great. As a related matter, the hosting\ninfrastructure for https://git.wiki.kernel.org/index.php/Main_Page\nseems overloaded. About half the time I try to access it, it's either\ndown completely or very slow to respond. If the wiki were git-backed I\ncould get to it even if the central site were down. :-)\n\nThat said, didn't the wiki just migrate to Mediawiki recently?\n\nj.\n"},{"id":"160233","messageId":"201102012339.31684.trast@student.ethz.ch","threadId":"26371","inReplyTo":"4D4875B2.4070008@gmail.com","subject":"Re: [1.8.0] make two-argument fetch update remote branches","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-02-01T22:39:31Z","receivedAt":"2011-02-01T22:39:31Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"A Large Angry SCM wrote:\n> On 01/31/2011 04:44 PM, Thomas Rast wrote:\n> >\n> > Since the remote branches in some sense reflect the \"last known state\"\n> > of the remote, it would make sense to also update them to whatever a\n> > two-argument fetch got.\n> \n> If this is proposing to break:\n> \n> \tget-fetch ${REPO} ${SRC_REF}:${DST_REF}\n> \n> then I am against this since that form _is_ used and *is* plumbing.\n\nYou're mixing up the two proposals.  This one is to teach\n\n  git fetch repo foo\n\nto update refs/remotes/repo/foo with the new value (maybe we should\nalso have it update in the foo:bar case, but I haven't thought that\nthrough).\n\nThe other one is to forbid 'git pull repo foo:bar' and would not\nchange git-fetch at all.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"160234","messageId":"4D488DCD.3080305@eaglescrag.net","threadId":"26371","inReplyTo":"AANLkTikfzzELUaN3B+20rh9D51St8mUYs4p-WYjp8JVV@mail.gmail.com","subject":"Re: moving to a git-backed wiki","fromName":"J.H.","fromEmail":"warthog19@eaglescrag.net","sentAt":"2011-02-01T22:48:45Z","receivedAt":"2011-02-01T22:48:45Z","isPatch":false,"sender":{"key":"warthog19@eaglescrag.net","avatar":null},"body":"On 02/01/2011 02:36 PM, Jay Soffian wrote:\n> On Tue, Feb 1, 2011 at 3:11 PM, Jeff King <peff@peff.net> wrote:\n>>  https://github.com/peff/foo/wiki\n> \n> A git-backed git wiki would be great. As a related matter, the hosting\n> infrastructure for https://git.wiki.kernel.org/index.php/Main_Page\n> seems overloaded. About half the time I try to access it, it's either\n> down completely or very slow to respond. If the wiki were git-backed I\n> could get to it even if the central site were down. :-)\n\nThe wiki will almost universally have a \"central site\" no matter what\nthe backend.  Personally I see little advantage to having a git backed\nwiki myself.\n\nSpeaking to the slowness, it's caused by at least 2 different kernel\nrelated bugs on the two boxes that run the wikis that I haven't had\nenough time to track down to nail to specific developers to fix.  I have\n20u of equipment sitting in my apartment that is heading to Portland in\nthe next two weeks to eliminate the bits I'm pretty sure are the root\ncause of the problems.\n\nTrust me when I say it's not only been a thorn in my side, and something\nI've been rather angry at several people about, but it's something that\nhas kept me up at night trying to get fixed.\n\n> That said, didn't the wiki just migrate to Mediawiki recently?\n\nIt did.\n\n- John 'Warthog9' Hawley\n"},{"id":"160239","messageId":"201102020020.30622.jnareb@gmail.com","threadId":"26371","inReplyTo":"7vsjw7xuy3.fsf@alter.siamese.dyndns.org","subject":"Re: [1.8.0] split largest remaining scripts, gitk and gitweb","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-02-01T23:20:28Z","receivedAt":"2011-02-01T23:20:28Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia wtorek 1. lutego 2011 23:15, Junio C Hamano napisał:\n> Jakub Narebski <jnareb@gmail.com> writes:\n> \n> > Two largest files in git repository are gitk and gitweb, see the\n> > ...\n> > What do you think?\n> \n> What does this have to do anything with 1.8.0?  Isn't this all internal\n> implementation that can be brought in without affecting end users?\n\nIn the case of gitk we have \"prior art\" i.e. git-gui, which got split.\nIn the case of gitweb I am not sure if there having multiple files to\ninstall wouldn't be inconvenient for users (though with \"install-gitweb\"\ntarget...)\n\nAnyway, I have posted this in subthread of\n\n  [1.8.0] reorganize the mess that the source tree has become\n\nbecause it is also code reorganization.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"160240","messageId":"4D489664.1020005@gmail.com","threadId":"26371","inReplyTo":"201102012339.31684.trast@student.ethz.ch","subject":"Re: [1.8.0] make two-argument fetch update remote branches","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2011-02-01T23:25:24Z","receivedAt":"2011-02-01T23:25:24Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"On 02/01/2011 05:39 PM, Thomas Rast wrote:\n> A Large Angry SCM wrote:\n>> On 01/31/2011 04:44 PM, Thomas Rast wrote:\n>>>\n>>> Since the remote branches in some sense reflect the \"last known state\"\n>>> of the remote, it would make sense to also update them to whatever a\n>>> two-argument fetch got.\n>>\n>> If this is proposing to break:\n>>\n>> \tget-fetch ${REPO} ${SRC_REF}:${DST_REF}\n>>\n>> then I am against this since that form _is_ used and *is* plumbing.\n>\n> You're mixing up the two proposals.  This one is to teach\n>\n>    git fetch repo foo\n>\n> to update refs/remotes/repo/foo with the new value (maybe we should\n> also have it update in the foo:bar case, but I haven't thought that\n> through).\n>\n> The other one is to forbid 'git pull repo foo:bar' and would not\n> change git-fetch at all.\n>\n\nI'm not concerned about the pull proposal (I haven't really thought \nabout it, yet) but I am concerned that your proposal may break (as in \nchange the behavior of) the case I identified above.\n"},{"id":"160244","messageId":"20110202005748.GA13803@elie","threadId":"26371","inReplyTo":"4D4852EE.6080605@lsrfire.ath.cx","subject":"Re: [1.8.0] Remove deprecated commands","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-02T00:57:48Z","receivedAt":"2011-02-02T00:57:48Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nRené Scharfe wrote:\n\n>    command          deprecated since replaced by\n>    ---------------- ---------------- ---------------------\n\nSome quick thoughts based on a code search:\n\n - removing lost-found seems safe\n - removing peek-remote seems safe\n - repo-config should probably warn before it is removed\n - removing tar-tree will probably break \"make dist\" for old\n   projects.  I still am tempted to say removing it should be\n   okay.\n\n>    git-lost-found   2007-11-08       git fsck --lost-found\n\nIt can stay in contrib/examples for inspiration.\n\n>    git-peek-remote  2007-11-24       git ls-remote\n\nNo one seems to be using it\n(github.com/gitpan/App-GitHub-FindRepository.git uses it as a fallback\nwhen ls-remote is not present).\n\n>    git-repo-config  2008-01-17       git config\n\ngiggle[1] still uses it --- see libgiggle-git/giggle-git-config-read.c\nand giggle-git-config-write.c.\n\nLikewise darcs2git[2] and the stgit testsuite.\n\nwebkit's VCSUtils.pm only uses repo-config as a fallback when git\nconfig is not present.\n\n>    git-tar-tree     2007-11-08       git archive\n\nAlready prints a deprecation notice.  WWW::PkgFind from CPAN uses it\nbut doesn't seem to be maintained.\n\npilgrim[3] uses tar-tree in its \"make dist\" target.  I wouldn't be\nsurprised if some other projects use it in a similar way.\n\nJonathan\n\n[1] git://git.gnome.org/giggle.git\n[2] git://repo.or.cz/darcs2git.git\n[3] git://git.fedorahosted.org/pilgrim.git\n"},{"id":"160262","messageId":"4D4929F4.3020805@snarc.org","threadId":"26371","inReplyTo":"4D488DCD.3080305@eaglescrag.net","subject":"Re: moving to a git-backed wiki","fromName":"Vincent Hanquez","fromEmail":"tab@snarc.org","sentAt":"2011-02-02T09:55:00Z","receivedAt":"2011-02-02T09:55:00Z","isPatch":false,"sender":{"key":"tab@snarc.org","avatar":"https://gravatar.com/avatar/f639df78e7af804fd54c86e32a2b7b1853d3765ba8e66f878e24c933efc30a2a?d=mp&s=160"},"body":"  On 01/02/11 22:48, J.H. wrote:\n> The wiki will almost universally have a \"central site\" no matter what\n> the backend.  Personally I see little advantage to having a git backed\n> wiki myself.\nwith git based wiki, you can clone the whole wiki on your local machine, \nand read/edit/commit on it locally using standard editor tool (i.e. \n$EDITOR). and the history/revision/diff is completely built-in.\n\n-- \nVincent\n"},{"id":"160263","messageId":"AANLkTi=07yifUAQYqabA8Dv1qmBTe=50+BDN-b0YZ1zb@mail.gmail.com","threadId":"26371","inReplyTo":"4D4929F4.3020805@snarc.org","subject":"Re: moving to a git-backed wiki","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-02-02T10:53:51Z","receivedAt":"2011-02-02T10:53:51Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Feb 2, 2011 at 11:55 AM, Vincent Hanquez <tab@snarc.org> wrote:\n>  On 01/02/11 22:48, J.H. wrote:\n>>\n>> The wiki will almost universally have a \"central site\" no matter what\n>> the backend.  Personally I see little advantage to having a git backed\n>> wiki myself.\n>\n> with git based wiki, you can clone the whole wiki on your local machine, and\n> read/edit/commit on it locally using standard editor tool (i.e. $EDITOR).\n> and the history/revision/diff is completely built-in.\n\nBut there's no git based wiki (or any other wiki) that has even a\nfraction of the features that MediaWiki has, or IMO a markup format\nsimilarly sane.\n\n-- \nFelipe Contreras\n"},{"id":"160264","messageId":"m34o8maduw.fsf@localhost.localdomain","threadId":"26371","inReplyTo":"AANLkTi=07yifUAQYqabA8Dv1qmBTe=50+BDN-b0YZ1zb@mail.gmail.com","subject":"Re: moving to a git-backed wiki","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-02-02T11:14:56Z","receivedAt":"2011-02-02T11:14:56Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n> On Wed, Feb 2, 2011 at 11:55 AM, Vincent Hanquez <tab@snarc.org> wrote:\n>>  On 01/02/11 22:48, J.H. wrote:\n>>>\n>>> The wiki will almost universally have a \"central site\" no matter what\n>>> the backend.  Personally I see little advantage to having a git backed\n>>> wiki myself.\n>>\n>> with git based wiki, you can clone the whole wiki on your local machine, and\n>> read/edit/commit on it locally using standard editor tool (i.e. $EDITOR).\n>> and the history/revision/diff is completely built-in.\n> \n> But there's no git based wiki (or any other wiki) that has even a\n> fraction of the features that MediaWiki has, or IMO a markup format\n> similarly sane.\n\nGollum (the engine used by git-based wikis on GitHub) offers support\nfor MediaWiki format.  I don't know how it is with editing and\npresenting history (end e.g. reverting spam), especially on older or\ntext browsers.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"160265","messageId":"m3zkqe8xc8.fsf_-_@localhost.localdomain","threadId":"26371","inReplyTo":"7vwrll57ha.fsf@alter.siamese.dyndns.org","subject":"[1.8.0] Tracking empty directories","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-02-02T11:56:08Z","receivedAt":"2011-02-02T11:56:08Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"See \"Tracking empty directories\" subthread on git mailing list,\nstarting with\n\n  http://thread.gmane.org/gmane.comp.version-control.git/165655/focus=165831\n\nThe idea is for git to be able to track empty directories without the\n.keepme (or empty .gitignore) file trick.  This was one of the most\nrequested features is native support for tracking empty directories,\nwith 35.2% support (from those who answered question) in \n\"Git User's Survey 2010\":\n\n  https://git.wiki.kernel.org/index.php/GitSurvey2010#17._Which_of_the_following_features_would_you_like_to_see_implemented_in_git.3F\n\n\nThere were some concerns about *backwards compatibility* of this\nfeature, see for example this email (which I would summarize here).\n\n  http://thread.gmane.org/gmane.comp.version-control.git/165655/focus=165847\n\nThat's why it is in 1.8.0 proposals.\n\nThe problem with backward compatibility is twofold.  First and more\nimportant is while git supports empty tree object (it has it hardcoded\nfor some time, as it is necessary e.g. for initial diff, or merging\nunrelated branches without common ancestor), and there is no problem\nwith entry for empty tree in a tree object\n\n  040000 tree 22d5826c087c4b9dcc72e2131c2cfb061403f7eb\tempty\n\nthere is (supposedly) problem when checking out such tree (see email\nreferenced above) with an old git.\n\nSecond is that tracking empty directories would require extension to the\ngit index (storing trees in index, like we store submodules)... but that\nis purely local matter.\n\nThere is also issue with pre-change git automatically removing empty\ndirectories, but that is probably matter for pre-commit hook to check,\nor pre-receive hook in publishing repository.\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"160276","messageId":"201102021823.19559.trast@student.ethz.ch","threadId":"26371","inReplyTo":"7vwrll57ha.fsf@alter.siamese.dyndns.org","subject":"[1.8.0] git-stash invocation changes","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-02-02T17:23:19Z","receivedAt":"2011-02-02T17:23:19Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Proposal:\n\n1. Change 'git stash <not-a-stash-command>' to give a usage message\n   instead of using <not-a-stash-command> as the stash message.\n\n2. Change 'git stash -p <args>' to treat the <args> as filename\n   arguments similar to add -p.  Possibly add a -m option that lets\n   you specify a message anyway, if desired.\n\n\nRationale:\n\nThe first one has long been a pet peeve of others, too.  It makes the\nstash command prone to typo accidents and such.\n\nThe second one was my own fault, and breaks the symmetry with the rest\nof the -p family.\n\n\nRisks:\n\nUsers trained to either usage will obviously have to retrain their\nfingers.  Scripts may also have to be changed, but if anything they\nprobably use a 'git stash; do_something; git stash pop' pattern which\nwould not be affected.  (I also suspect most scripts using this\npattern forget to check whether there is anything to stash, and thus\nare broken if there isn't.)\n\n\nMigration plan:\n\nIn 1.7.5, give a loud warning for both syntaxes.\n\nIn 1.8.0, switch them as described.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"160277","messageId":"AANLkTimu=drR+4v+B_aB+Y4jVqzaBghh1XYSZoACsBry@mail.gmail.com","threadId":"26371","inReplyTo":"201102021823.19559.trast@student.ethz.ch","subject":"Re: [1.8.0] git-stash invocation changes","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2011-02-02T17:35:52Z","receivedAt":"2011-02-02T17:35:52Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Wed, Feb 2, 2011 at 09:23, Thomas Rast <trast@student.ethz.ch> wrote:\n> Proposal:\n>\n> 1. Change 'git stash <not-a-stash-command>' to give a usage message\n>   instead of using <not-a-stash-command> as the stash message.\n\nOh please, yes, please do this.  We should have done this long, long\nago.  Its easy enough to train your fingers or fix your scripts to say\n`git stash save list` rather than `git stash lsit` once stash errors\nout and gives you a usage message once.\n\n> Migration plan:\n>\n> In 1.7.5, give a loud warning for both syntaxes.\n>\n> In 1.8.0, switch them as described.\n\nJust fix it.  I can't imagine anyone cares enough that `git stash\nblah` stops working without first saying save.\n\n-- \nShawn.\n"},{"id":"160281","messageId":"vpqtygmwbee.fsf@bauges.imag.fr","threadId":"26371","inReplyTo":"AANLkTimu=drR+4v+B_aB+Y4jVqzaBghh1XYSZoACsBry@mail.gmail.com","subject":"Re: [1.8.0] git-stash invocation changes","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-02-02T18:15:37Z","receivedAt":"2011-02-02T18:15:37Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Shawn Pearce <spearce@spearce.org> writes:\n\n> On Wed, Feb 2, 2011 at 09:23, Thomas Rast <trast@student.ethz.ch> wrote:\n>> Proposal:\n>>\n>> 1. Change 'git stash <not-a-stash-command>' to give a usage message\n>>   instead of using <not-a-stash-command> as the stash message.\n>\n> Oh please, yes, please do this.  We should have done this long, long\n> ago.  Its easy enough to train your fingers or fix your scripts to say\n> `git stash save list` rather than `git stash lsit` once stash errors\n> out and gives you a usage message once.\n\nErr, hasn't this been fixed long ago already?\n\n$ git stash not-a-stash-command\nUsage: git stash list [<options>]\n   or: git stash show [<stash>]\n   or: git stash drop [-q|--quiet] [<stash>]\n   or: git stash ( pop | apply ) [--index] [-q|--quiet] [<stash>]\n   or: git stash branch <branchname> [<stash>]\n   or: git stash [save [--patch] [-k|--[no-]keep-index] [-q|--quiet] [<message>]]\n   or: git stash clear\n$ git stash save --no-such-option\nerror: unknown option for 'stash save': --no-such-option\n       To provide a message, use git stash save -- '--no-such-option'\nUsage: [...]\n\nOnly this could be seen as a problem:\n\n$ git stash save this-is-not-a-stash-name\nSaved working directory and index state On master: this-is-not-a-stash-name\n\nin particular, it is wrt:\n\nThomas Rast <trast@student.ethz.ch> writes:\n\n> 2. Change 'git stash -p <args>' to treat the <args> as filename\n>    arguments similar to add -p.  Possibly add a -m option that lets\n>    you specify a message anyway, if desired.\n\nI'm not a user of \"stash with messages\" myself, so I can't say how\nannoying the migration would be, but -m \"message\" sounds good to me.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"160283","messageId":"201102021951.31883.trast@student.ethz.ch","threadId":"26371","inReplyTo":"vpqtygmwbee.fsf@bauges.imag.fr","subject":"Re: [1.8.0] git-stash invocation changes","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-02-02T18:51:31Z","receivedAt":"2011-02-02T18:51:31Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Matthieu Moy wrote:\n> Shawn Pearce <spearce@spearce.org> writes:\n> \n> > On Wed, Feb 2, 2011 at 09:23, Thomas Rast <trast@student.ethz.ch> wrote:\n> >> Proposal:\n> >>\n> >> 1. Change 'git stash <not-a-stash-command>' to give a usage message\n> >>   instead of using <not-a-stash-command> as the stash message.\n> >\n> > Oh please, yes, please do this.  We should have done this long, long\n> > ago.  Its easy enough to train your fingers or fix your scripts to say\n> > `git stash save list` rather than `git stash lsit` once stash errors\n> > out and gives you a usage message once.\n> \n> Err, hasn't this been fixed long ago already?\n\nOh, you're actually right.  I have totally missed this, and should\nobviously have tested first.\n\nStill, I think the change to 'git stash -p' is also worthwhile.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"160296","messageId":"AANLkTi=bK7mFS3eWVMWXqZSnv73tafL9AGazk4jPLddp@mail.gmail.com","threadId":"26371","inReplyTo":"m3zkqe8xc8.fsf_-_@localhost.localdomain","subject":"Re: [1.8.0] Tracking empty directories","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-02T23:23:07Z","receivedAt":"2011-02-02T23:23:07Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Wed, Feb 2, 2011 at 6:56 AM, Jakub Narebski <jnareb@gmail.com> wrote:\n> The problem with backward compatibility is twofold.  First and more\n> important is while git supports empty tree object (it has it hardcoded\n> for some time, as it is necessary e.g. for initial diff, or merging\n> unrelated branches without common ancestor), and there is no problem\n> with entry for empty tree in a tree object\n>\n>  040000 tree 22d5826c087c4b9dcc72e2131c2cfb061403f7eb  empty\n>\n> there is (supposedly) problem when checking out such tree (see email\n> referenced above) with an old git.\n>\n> Second is that tracking empty directories would require extension to the\n> git index (storing trees in index, like we store submodules)... but that\n> is purely local matter.\n\nInstead of using an empty tree, construct a tree containing a single\nsentinel file whose contents are a suitable warning not to delete/edit\nsaid file using pre-1.8.0 git. Meanwhile git-1.8.0 never writes the\nfile to the filesystem. Too ugly?\n\nj.\n"},{"id":"160297","messageId":"4928FF12-E593-4CDB-AC68-B4078CC5920E@gmail.com","threadId":"26371","inReplyTo":"AANLkTi=bK7mFS3eWVMWXqZSnv73tafL9AGazk4jPLddp@mail.gmail.com","subject":"Re: [1.8.0] Tracking empty directories","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2011-02-02T23:33:09Z","receivedAt":"2011-02-02T23:33:09Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Feb 2, 2011, at 3:23 PM, Jay Soffian <jaysoffian@gmail.com> wrote:\n\n> On Wed, Feb 2, 2011 at 6:56 AM, Jakub Narebski <jnareb@gmail.com>  \n> wrote:\n>> The problem with backward compatibility is twofold.  First and more\n>> important is while git supports empty tree object (it has it  \n>> hardcoded\n>> for some time, as it is necessary e.g. for initial diff, or merging\n>> unrelated branches without common ancestor), and there is no problem\n>> with entry for empty tree in a tree object\n>>\n>>  040000 tree 22d5826c087c4b9dcc72e2131c2cfb061403f7eb  empty\n>>\n>> there is (supposedly) problem when checking out such tree (see email\n>> referenced above) with an old git.\n>>\n>> Second is that tracking empty directories would require extension  \n>> to the\n>> git index (storing trees in index, like we store submodules)... but  \n>> that\n>> is purely local matter.\n>\n> Instead of using an empty tree, construct a tree containing a single\n> sentinel file whose contents are a suitable warning not to delete/edit\n> said file using pre-1.8.0 git. Meanwhile git-1.8.0 never writes the\n> file to the filesystem. Too ugly?\n>\n> j.\n\nI don't like where this is going. Users are not always right.  \nTouch .gitignore and be done with it.   This is a big change with  \nnegligible benefits.  I don't understand why this is needed.\n"},{"id":"160298","messageId":"201102030052.44940.jnareb@gmail.com","threadId":"26371","inReplyTo":"4928FF12-E593-4CDB-AC68-B4078CC5920E@gmail.com","subject":"Re: [1.8.0] Tracking empty directories","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-02-02T23:52:43Z","receivedAt":"2011-02-02T23:52:43Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia czwartek 3. lutego 2011 00:33, David Aguilar napisał:\n> On Feb 2, 2011, at 3:23 PM, Jay Soffian <jaysoffian@gmail.com> wrote:\n>> On Wed, Feb 2, 2011 at 6:56 AM, Jakub Narebski <jnareb@gmail.com> wrote:\n>>>\n>>> The problem with backward compatibility is twofold.  First and more\n>>> important is while git supports empty tree object (it has it  \n>>> hardcoded\n>>> for some time, as it is necessary e.g. for initial diff, or merging\n>>> unrelated branches without common ancestor), and there is no problem\n>>> with entry for empty tree in a tree object\n>>>\n>>>  040000 tree 22d5826c087c4b9dcc72e2131c2cfb061403f7eb  empty\n>>>\n>>> there is (supposedly) problem when checking out such tree (see email\n>>> referenced above) with an old git.\n>>>\n>>> Second is that tracking empty directories would require extension  \n>>> to the\n>>> git index (storing trees in index, like we store submodules)... but  \n>>> that\n>>> is purely local matter.\n>>\n>> Instead of using an empty tree, construct a tree containing a single\n>> sentinel file whose contents are a suitable warning not to delete/edit\n>> said file using pre-1.8.0 git. Meanwhile git-1.8.0 never writes the\n>> file to the filesystem. Too ugly?\n\nToo ugly.\n\n> I don't like where this is going. Users are not always right.  \n> Touch .gitignore and be done with it.   This is a big change with  \n> negligible benefits.  I don't understand why this is needed.\n\nTwo issues: first is interaction with other SCM which keep empty files\n(or keep empty files when requested).  Second is skeleton of directory\nstructure automatically generated by some git-unaware tool.\n\nI've never felt the need but more than 50% of Git User's Survey 2010\nresponders did.\n-- \nJakub Narebski\nPoland\n"},{"id":"160299","messageId":"4D49EF02.1050201@vilain.net","threadId":"26371","inReplyTo":"7v4o8o4kt7.fsf@alter.siamese.dyndns.org","subject":"Re: [1.8.0] 't/' is standard name for directory with tests","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2011-02-02T23:55:46Z","receivedAt":"2011-02-02T23:55:46Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On 01/02/11 14:15, Junio C Hamano wrote:\n> I am fine with \"tests/\", by the way.\n\nFWIW, CCAN and Rubygems both use plain \"test\".\n\n\"t/\" is a long standing convention for many projects, dating back to at\nleast 1987 with Perl 1.0.  As far as I know it was unusual at the time\nfor being a very test-driven development and inventing the TAP (Test\nAnything Protocol).  It is something of a mark of respect to the\nheritage of TDD to have it there, but that doesn't mean that \"test\"\nmight be better for the project now.\n\nI'd also think about removing the \"t\" from the front of all the test\nscript names, those are a PITA :-).  And possibly allowing the scripts\nto be broken into subdirectories.\n\nSam\n"},{"id":"160303","messageId":"201102021921.53755.wjl@icecavern.net","threadId":"26371","inReplyTo":"4928FF12-E593-4CDB-AC68-B4078CC5920E@gmail.com","subject":"Re: [1.8.0] Tracking empty directories","fromName":"Wesley J. Landaker","fromEmail":"wjl@icecavern.net","sentAt":"2011-02-03T02:21:53Z","receivedAt":"2011-02-03T02:21:53Z","isPatch":false,"sender":{"key":"wjl@icecavern.net","avatar":"https://avatars.githubusercontent.com/u/67229?v=4"},"body":"On Wednesday, February 02, 2011 16:33:09 David Aguilar wrote:\n> I don't like where this is going. Users are not always right.\n> Touch .gitignore and be done with it.   This is a big change with\n> negligible benefits.  I don't understand why this is needed.\n\nI am not usually bothered too much that git doesn't story directories, and \nwhen I need to do it, I can do the .gitignore trick just like anyone else.\n\nHowever here are a few reasons that I miss this feature sometimes:\n\n  1) Why WOULDN'T you want to track empty directories? We track empty files: \nisn't that just as pointless? What if git couldn't track empty files and \nautomatically removed files when they became empty? Well, I could live with \nthat just as well, with some silly workarounds every once in a while (e.g. \necho empty > some_file).\n\n  2) One of git's best strengths is that it's so easy to interact with other \nSCM software, primarily because git's features are a SUPERSET of other SCMs. \nHowever, almost every other SCM can track empty directories, except git, \nwhich makes it much harder to use as universal tool, where I can trust that \neverything will round-trip as well as possible. Also, other SCMs don't want \n\".gitignore\" files cluttering their repository any more than we want their \nSCM tool's random control files in our repositories.\n\n  3) Forget for a moment the cuddly git idosynchracies that through use we \nhave come to know and \"love\". From a design perspective, does putting and \ntracking, a file called IGNORE in a directory you want to KEEP make sense? \nIt's one thing to use \"touch .gitignore\" in an empty directory to keep it \n*as a workaround*, based on implementation details (i.e. any file in the \ndirectory will do, but we probably will have a .gitignore anyway eventually, \nso might as well as use that) but it's a strange *design*. =)\n\n  4) On many projects I work on with a huge number of people, the workflow \nis to create a very, very intricate directory hierarchy skeleton, so that \nit's clear to everyone where everything goes and how it is organized, even \nbefore any work is started. In this case with git, it's annoying to do this \nbecause there are worthless .gitignore files cluttering up everything, which \nmakes it harder to find where there are *actual* ignore rules being applied.\n\n  5) Git not tracking empty directories and the (perceived?) arrogant \nreaction from git experts (\"no big deal, just touch .gitignore\" -- I've said \nthis to people too, since it's the canonical answer, but I always feel a \nlittle chagrined after hyping up everything git can do) sometimes is just \none more thing that makes git harder to sell to others, especially when they \nare already in love with Subversion or whatever.\n\nMost of all, think of it this way: maybe git doesn't need to track empty \ndirectories in order to be awesome, but is there some reason that tracking \nempty directories would make it less awesome?\n\nAnyway, just some thoughts.\n"},{"id":"160304","messageId":"4D4A11D7.4040103@eaglescrag.net","threadId":"26371","inReplyTo":"4D4929F4.3020805@snarc.org","subject":"Re: moving to a git-backed wiki","fromName":"J.H.","fromEmail":"warthog19@eaglescrag.net","sentAt":"2011-02-03T02:24:23Z","receivedAt":"2011-02-03T02:24:23Z","isPatch":false,"sender":{"key":"warthog19@eaglescrag.net","avatar":null},"body":"On 02/02/2011 01:55 AM, Vincent Hanquez wrote:\n>  On 01/02/11 22:48, J.H. wrote:\n>> The wiki will almost universally have a \"central site\" no matter what\n>> the backend.  Personally I see little advantage to having a git backed\n>> wiki myself.\n> with git based wiki, you can clone the whole wiki on your local machine,\n> and read/edit/commit on it locally using standard editor tool (i.e.\n> $EDITOR). and the history/revision/diff is completely built-in.\n\nThat would be fine for things like source code or documentation, but you\nend up with a single person who would need to merge / push things to a\ncentral location, a-la git.wiki.kernel.org.  You are now taking\nsomething, that is already editable by anyone, and making it only\neditable by a single person.\n\nYou also have a scalability problem.  Git is *VERY* memory and i/o\nintensive.  While you basically have a cache of data that is static (the\nbasic pages you are viewing) things like the history, edits, etc can be\nquite expensive to generate.\n\nThink about a site, we'll use git.wiki.kernel.org, where it's not\nrunning on a single machine, but a cluster of machines (how many web\ninfrastructures, including git.wiki.kernel.org run) and now you have a\nproblem of an edit happens and commits on node3, a different conflicting\nedit happens on node9 and when those try to merge - you get conflicts.\n\nLet me be clear here, I think the idea is interesting, but I think in\ntrying to replace a full wiki it's a horrible idea, particularly since\nyou are pushing a lot of manual work - somewhere, and trying to use git\nas a nosql database without some sort of locking system.\n\nJust my $0.02 though.\n\n- John 'Warthog9' Hawley\n"},{"id":"160314","messageId":"20110203055359.GA23220@elie","threadId":"26371","inReplyTo":"201102021921.53755.wjl@icecavern.net","subject":"Re: [1.8.0] Tracking empty directories","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-03T05:53:59Z","receivedAt":"2011-02-03T05:53:59Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Wesley J. Landaker wrote:\n\n>   1) Why WOULDN'T you want to track empty directories? We track empty files: \n> isn't that just as pointless?\n\nSee http://thread.gmane.org/gmane.comp.version-control.git/52875\n\n>   2) One of git's best strengths is that it's so easy to interact with other \n> SCM software, primarily because git's features are a SUPERSET of other SCMs. \n\nNot really.  For example, many other SCMs can store per-file comments,\narbitrary revision properties, a detailed provenance of a file, and\ndetailed permissions for each directory entry.\n\nWhat might make git nice as an interoperability tool is that it tracks\nthe _relevant_ information for the history of a software project.\nExample of what is not relevant information and why that matters:\n\n http://thread.gmane.org/gmane.comp.version-control.git/53494\n\nAll that said, I do want support for explicitly[1] tracking empty\ndirectories, mostly for the sake of the ability to clone an svn repo\nwith empty directories in a simple way.\n\nThe aforementioned \"share a project skeleton\" use case is just a nice\nbonus.\n\nHope that helps,\nJonathan\n\n[1] Part of the value of the \"explicitly\" is to make it explicit that\nearly adopters are asking for trouble. :)  FWIW I imagine a transition\nlike this:\n\n 1. Teach \"git read-tree\" and \"git checkout-index\" to honor empty\n    directories (but not \"git update-index\" or \"git write-tree\").\n\n 2. Teach \"git write-tree\" to accept empty directories.\n\n 3. Teach \"git update-index\" to accept empty directories if a\n    configuration item indicates so.  That configuration would\n    default to false.\n\n 4. (Maybe) add porcelain support for tracking of empty directories.\n    Also teach \"git diff-tree\" and \"git apply\" about empty\n    directories.\n\n 5. Change the default to true.\n\nAn orthogonal question is how the empty directories would be stored.\nI do not like the idea of a \".empty-directory\" file, since what\nhappens when you try to import a repository with a genuine\n\".empty-directory\" file?\n\nBased on a quick test, currently read-tree _ignores_ empty tree\nentries.  Would it be okay to say that anyone who turns on the switch\nfrom step (3) has declared he is willing to write tree objects that\ngit fsck versions before v1.5.5-rc0~63 (fsck.c: fix bogus \"empty tree\"\ncheck, 2008-03-04) will reject and current git might mishandle?\n"},{"id":"160321","messageId":"vpqbp2tqvm1.fsf@bauges.imag.fr","threadId":"26371","inReplyTo":"201102021921.53755.wjl@icecavern.net","subject":"Re: [1.8.0] Tracking empty directories","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-02-03T10:07:50Z","receivedAt":"2011-02-03T10:07:50Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"\"Wesley J. Landaker\" <wjl@icecavern.net> writes:\n\n>   2) One of git's best strengths is that it's so easy to interact with other \n> SCM software, primarily because git's features are a SUPERSET of other SCMs. \n> However, almost every other SCM can track empty directories, except\n> git, \n[...]\n>   4) On many projects I work on with a huge number of people, the workflow \n> is to create a very, very intricate directory hierarchy skeleton, so that \n> it's clear to everyone where everything goes and how it is organized, even \n> before any work is started.\n\nJust adding my 2 cents: my first clash with Git's non-management of\nempty directories was a combination of both. A colleague created an\nSVN project with several empty directories, along the lines of \"Here\nit is. Now, put your stuff in there\".\n\ngit-svn didn't import these empty directories (I think I actually\ncould have worked around this with \"git svn mkdirs\"). Adding\n.gitignore files would have been a really dirty workaround since I\ndidn't want to put Git stuff in the SVN repo.\n\nI don't think my colleague did anything wrong, I did want to use Git,\nand that was still frustrating to see such a simple scenario not\nmanaged by my favorite tool.\n\nSo, yes, I can clearly leave without empty directory support, but that\nwould be a nice addition to Git.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"160340","messageId":"20110203174518.GA14871@sigill.intra.peff.net","threadId":"26371","inReplyTo":"4D4A11D7.4040103@eaglescrag.net","subject":"Re: moving to a git-backed wiki","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-03T17:45:18Z","receivedAt":"2011-02-03T17:45:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 02, 2011 at 06:24:23PM -0800, J.H. wrote:\n\n> On 02/02/2011 01:55 AM, Vincent Hanquez wrote:\n> >  On 01/02/11 22:48, J.H. wrote:\n> >> The wiki will almost universally have a \"central site\" no matter what\n> >> the backend.  Personally I see little advantage to having a git backed\n> >> wiki myself.\n> > with git based wiki, you can clone the whole wiki on your local machine,\n> > and read/edit/commit on it locally using standard editor tool (i.e.\n> > $EDITOR). and the history/revision/diff is completely built-in.\n> \n> That would be fine for things like source code or documentation, but you\n> end up with a single person who would need to merge / push things to a\n> central location, a-la git.wiki.kernel.org.  You are now taking\n> something, that is already editable by anyone, and making it only\n> editable by a single person.\n\nI don't think it makes sense to use the same workflow for the wiki as\ngit.git itself uses. The point of having a wiki is to keep the barrier\nto editing extremely low; the point of source code control is to keep\nthe quality of contributions high.\n\nBut that doesn't mean they can't be accessed by the same tool.\n\nForget about a git-backed wiki for a moment, and imagine a regular old\nMediawiki. What are the operations you can perform? You can look at\nthe current or any past version of a page, you can do diffs between\nversions of pages, and you can create a new version of a page. All\nthrough some CGI forms.\n\nSo what stops us from replacing the CGI interface with a git one (or\nadding it alongside)? Given the ability to retrieve current and past\nversions of all pages, I could surely build a git repository of the\nwhole wiki (and update it incrementally as new edits were made).  And\npushing a set of commits is just a sequential series of page edits, no?\n\nAnd I think that would be enough for the purposes of this discussion.\nMost of us don't really care if git is the ultimate storage mechanism. I\ncould even build the git interface as a purely client thing on top of\nthe CGI interface; the problem is that scraping the wiki pages for new\nversions over the net would be horribly inefficient.\n\nBut the point is that accessing the wiki via git is not about changing\nthe wiki workflow. It's about providing a richer set of tools for doing\nthose page views, diffs, and edits.\n\nGetting back to git as the actual backend:\n\n> You also have a scalability problem.  Git is *VERY* memory and i/o\n> intensive.  While you basically have a cache of data that is static (the\n> basic pages you are viewing) things like the history, edits, etc can be\n> quite expensive to generate.\n\nSure. But is that any worse than running gitweb, which you already do?\nOr a site like GitHub, which basically is just running git constantly on\na bunch of repos? Or how much worse is it than running regular wiki\nsoftware? I mean, Foswiki is backed by RCS, for god's sake. Surely git\nis more efficient than that. ;)\n\nIf it sounds like I'm handwaving away scalability problems, I am. I'd be\ncurious to see some performance numbers for gollum or ikiwiki versus\nmore traditional wiki formats.\n\n> Think about a site, we'll use git.wiki.kernel.org, where it's not\n> running on a single machine, but a cluster of machines (how many web\n> infrastructures, including git.wiki.kernel.org run) and now you have a\n> problem of an edit happens and commits on node3, a different conflicting\n> edit happens on node9 and when those try to merge - you get conflicts.\n\nDon't you have the same problem with a regular wiki? Or with stock git\nrepos, for that matter? You need database consistency.\n\n-Peff\n"},{"id":"160405","messageId":"AANLkTikshY8qHoFvghSu8q21j5Unp==Hf583OE2tkNrS@mail.gmail.com","threadId":"26371","inReplyTo":"20110203174518.GA14871@sigill.intra.peff.net","subject":"Re: moving to a git-backed wiki","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-02-03T19:06:34Z","receivedAt":"2011-02-03T19:06:34Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Thu, Feb 3, 2011 at 18:45, Jeff King <peff@peff.net> wrote:\n> Most of us don't really care if git is the ultimate storage mechanism. I\n> could even build the git interface as a purely client thing on top of\n> the CGI interface; the problem is that scraping the wiki pages for new\n> versions over the net would be horribly inefficient.\n\nNote that MediaWiki has a stable API that you could use instead :).\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"160350","messageId":"AANLkTi=qR5xYBg3NKRASuyatnEm1k3fVNc-i5VOwszpM@mail.gmail.com","threadId":"26371","inReplyTo":"20110203174518.GA14871@sigill.intra.peff.net","subject":"Re: moving to a git-backed wiki","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-02-03T20:34:38Z","receivedAt":"2011-02-03T20:34:38Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Feb 3, 2011 at 7:45 PM, Jeff King <peff@peff.net> wrote:\n> On Wed, Feb 02, 2011 at 06:24:23PM -0800, J.H. wrote:\n>\n>> On 02/02/2011 01:55 AM, Vincent Hanquez wrote:\n>> >  On 01/02/11 22:48, J.H. wrote:\n>> >> The wiki will almost universally have a \"central site\" no matter what\n>> >> the backend.  Personally I see little advantage to having a git backed\n>> >> wiki myself.\n>> > with git based wiki, you can clone the whole wiki on your local machine,\n>> > and read/edit/commit on it locally using standard editor tool (i.e.\n>> > $EDITOR). and the history/revision/diff is completely built-in.\n>>\n>> That would be fine for things like source code or documentation, but you\n>> end up with a single person who would need to merge / push things to a\n>> central location, a-la git.wiki.kernel.org.  You are now taking\n>> something, that is already editable by anyone, and making it only\n>> editable by a single person.\n>\n> I don't think it makes sense to use the same workflow for the wiki as\n> git.git itself uses. The point of having a wiki is to keep the barrier\n> to editing extremely low; the point of source code control is to keep\n> the quality of contributions high.\n>\n> But that doesn't mean they can't be accessed by the same tool.\n>\n> Forget about a git-backed wiki for a moment, and imagine a regular old\n> Mediawiki. What are the operations you can perform? You can look at\n> the current or any past version of a page, you can do diffs between\n> versions of pages, and you can create a new version of a page. All\n> through some CGI forms.\n\nHowe about these?\n\n1) Support for discussion; since changes can be controversial.\n\n2) Support for article move; so everything is kept organized.\n\n3) Support for \"who is linking here\". Also helps reorganization.\n\n4) Support for categories. Ditto.\n\n5) Support for watchlist, e-mail notifications. So that you are\nup-to-date with the changes.\n\n6) Support for contribution backtracking. So that it's easy to know who's who.\n\n7) Personal wiki pages (with discussion). So you can put information\nabout yourself, and general notes.\n\n-- \nFelipe Contreras\n"},{"id":"160376","messageId":"20110204060306.GA2455@sigill.intra.peff.net","threadId":"26371","inReplyTo":"AANLkTikshY8qHoFvghSu8q21j5Unp==Hf583OE2tkNrS@mail.gmail.com","subject":"Re: moving to a git-backed wiki","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-04T06:03:06Z","receivedAt":"2011-02-04T06:03:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 03, 2011 at 08:06:34PM +0100, Sverre Rabbelier wrote:\n\n> On Thu, Feb 3, 2011 at 18:45, Jeff King <peff@peff.net> wrote:\n> > Most of us don't really care if git is the ultimate storage mechanism. I\n> > could even build the git interface as a purely client thing on top of\n> > the CGI interface; the problem is that scraping the wiki pages for new\n> > versions over the net would be horribly inefficient.\n> \n> Note that MediaWiki has a stable API that you could use instead :).\n\nThe initial import is still pretty painful over the network, but at\nleast I know I am getting accurate data from the API now. And I can\nshare the git repository, and just use the RecentChanges API to get\nupdates.\n\nThe result is at:\n\n  https://github.com/peff/wikitest/wiki\n\nYou can see an example of the full history:\n\n  https://github.com/peff/wikitest/wiki/_history\n\nor a page history:\n\n  https://github.com/peff/wikitest/wiki/GitFaq/_history\n\nOr download the repository for yourself:\n\n  git://github.com/peff/wikitest.wiki.git\n\nThe whole git wiki is about a 4M git repository (and at least some of\nthat is spam that's deleted but still in the history).\n\nThis is has been a cute exercise, but I'm not sure mirroring it in a\ngollum wiki really makes sense. It's cool that gollum understands\nMediaWiki enough to actually render the pages at all, but there are\nobviously lots of corner cases that it just doesn't get (formatting\nissues, missing images, some redirect naming issues).\n\nStill, it's useful as a local repo doing diffs. I just wrote the initial\nimporter (which I'm happy to share if somebody wants to see some ugly\ncode), but to act as a useful client, it still needs:\n\n  1. Incremental updating from the RecentChanges API.\n\n  2. Push support (or more likely something similar to \"git svn\n     dcommit\") to push edits back.\n\n-Peff\n"},{"id":"160377","messageId":"20110204061622.GB2455@sigill.intra.peff.net","threadId":"26371","inReplyTo":"AANLkTi=qR5xYBg3NKRASuyatnEm1k3fVNc-i5VOwszpM@mail.gmail.com","subject":"Re: moving to a git-backed wiki","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-04T06:16:22Z","receivedAt":"2011-02-04T06:16:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 03, 2011 at 10:34:38PM +0200, Felipe Contreras wrote:\n\n> > Forget about a git-backed wiki for a moment, and imagine a regular old\n> > Mediawiki. What are the operations you can perform? You can look at\n> > the current or any past version of a page, you can do diffs between\n> > versions of pages, and you can create a new version of a page. All\n> > through some CGI forms.\n> \n> Howe about these?\n\nI've never really used a wiki in any in-depth way, so be gentle if my\nutter cluelessness about these features shows through.\n\n> 1) Support for discussion; since changes can be controversial.\n\nDoesn't this just happen on special Talk: pages? Couldn't these just be\npages with special names?\n\n> 2) Support for article move; so everything is kept organized.\n\nIsn't that even simpler in a git-backed wiki? You just move the files.\nObviously you would want to update links, too, and presumably the wiki\nsoftware helps with that. But that is outside the scope of data storage.\nIn a git-backed wiki, you would get one atomic commit with the move and\nlink updating.\n\n> 3) Support for \"who is linking here\". Also helps reorganization.\n\nAgain, is that a fundamental storage issue? It seems like you could\nimplement that easily on top of basic storage with a grep (and some\ncaching if you are going to let people do it a lot via the web).\n\n> 4) Support for categories. Ditto.\n\nI have no idea how categories work. Special page naming and/or\ndirectories?\n\n> 5) Support for watchlist, e-mail notifications. So that you are\n> up-to-date with the changes.\n\nPost-receive hook?\n\n> 6) Support for contribution backtracking. So that it's easy to know who's who.\n\ngit log? git blame? :)\n\n> 7) Personal wiki pages (with discussion). So you can put information\n> about yourself, and general notes.\n\nSpecially named pages for people?\n\n\nObviously I'm just filling in these features off the top of my head.\nMediaWiki is a mature system, and I doubt that either ikiwiki or gollum\nhas nearly the same featureset. But that was never my point. In the bit\nyou quoted, my point was that a git-interface to a wiki was useful and\nfeasible. And I stand by that.\n\nEven with just the basic functionality of fetch/diff/push, that still\nmakes it a useful interface into an existing wiki for a large number of\nusers who just want to do simple stuff (or power users who happen to be\ndoing simple stuff at the moment).\n\nI also happen to think you could put all of those features into a\ngit-backed wiki, and build the web features on _top_ of git access. But\nI'm not volunteering to work on that.\n\n-Peff\n"},{"id":"160378","messageId":"gcvg.1102040831.409@thorondor.akallabeth.de","threadId":"26371","inReplyTo":"20110131225529.GC14419@sigill.intra.peff.net","subject":"Re: [1.8.0] (v2) default \"git merge\" without argument to \"git merge @{u}\"","fromName":"Thomas Hochstein","fromEmail":"thh@inter.net","sentAt":"2011-02-04T07:31:54Z","receivedAt":"2011-02-04T07:31:54Z","isPatch":false,"sender":{"key":"thh@inter.net","avatar":"https://avatars.githubusercontent.com/u/365129?v=4"},"body":"Jeff King schrieb:\n\n> And surely there\n> are other git-backed alternatives (it's been a while since I've looked).\n\nikiwiki, for example, with Hosting on <http://branchable.com/>?\n"},{"id":"160398","messageId":"20110204143421.GA6449@gnu.kitenet.net","threadId":"26371","inReplyTo":"20110203174518.GA14871@sigill.intra.peff.net","subject":"Re: moving to a git-backed wiki","fromName":"Joey Hess","fromEmail":"joey@kitenet.net","sentAt":"2011-02-04T14:34:21Z","receivedAt":"2011-02-04T14:34:21Z","isPatch":false,"sender":{"key":"joey@kitenet.net","avatar":"https://avatars.githubusercontent.com/u/16392?v=4"},"body":"Jeff King wrote:\n> If it sounds like I'm handwaving away scalability problems, I am. I'd be\n> curious to see some performance numbers for gollum or ikiwiki versus\n> more traditional wiki formats.\n\nIkiwiki builds static pages, this tends to mean it doesn't have\nperformance, because there is little more to perform than\nhttpd < file > network :)\nSo I've routinely had ikiwiki sites slashdotted, and not noticed.\n\nIkiwiki is not enormously fast in the rare cases when it does have to\nrun as a CGI, but little of that has to do with git. About the worst\ncase is that saving a page edit leads to a git commit -- if git\ndecides to gc the repository right then, it could make the save stall\nfor a while. There are easy ways to avoid that. (ie, git gc in cron job)\nIn general, though ikiwiki as a CGI is fast enough to not be annoying -- \nalthough it won't scale to a site the size of wikipedia.\n\nSince I'm lazy, ikiwiki does not include a history or diff viewer. It\njust points off to gitweb or a similar tool. As you say, gitweb can be\nfast enough, and really most wiki users do read their current content,\nor maybe make an edit; digging in the history is comparatively rare.\nAnd once users realize the wiki is in git, they can use gitk to dig in\nthe history without using any server resources. :)\n\nThe feature I like best with using git for a wiki (besides ease of\nbranching) is that it can actually make a legitimate use of the\nwoefully underused git push over git:// feature. Ikiwiki can be\nconfigured to check such pushes, running via the pre-receive hook. This\nallows it to limit the changes that can be pushed anonymously to changes\nthat could be made using the web interface. So if you've chosen to lock\nsome pages, or virus filter attachments, or whatever, in the web side of\nthe wiki, that all applies to the anonymous git pushes too. Details at\n<http://ikiwiki.info/tips/untrusted_git_push/>\n\n-- \nsee shy jo\n"},{"id":"160402","messageId":"AANLkTimytxjqoCf-LbxQqSgmAW2+FqmSLN5c_8fSJhLy@mail.gmail.com","threadId":"26371","inReplyTo":"20110204061622.GB2455@sigill.intra.peff.net","subject":"Re: moving to a git-backed wiki","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-02-04T17:50:28Z","receivedAt":"2011-02-04T17:50:28Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Feb 4, 2011 at 8:16 AM, Jeff King <peff@peff.net> wrote:\n> On Thu, Feb 03, 2011 at 10:34:38PM +0200, Felipe Contreras wrote:\n>\n>> > Forget about a git-backed wiki for a moment, and imagine a regular old\n>> > Mediawiki. What are the operations you can perform? You can look at\n>> > the current or any past version of a page, you can do diffs between\n>> > versions of pages, and you can create a new version of a page. All\n>> > through some CGI forms.\n>>\n>> Howe about these?\n>\n> I've never really used a wiki in any in-depth way, so be gentle if my\n> utter cluelessness about these features shows through.\n>\n>> 1) Support for discussion; since changes can be controversial.\n>\n> Doesn't this just happen on special Talk: pages? Couldn't these just be\n> pages with special names?\n\nCould be.\n\n>> 2) Support for article move; so everything is kept organized.\n>\n> Isn't that even simpler in a git-backed wiki? You just move the files.\n> Obviously you would want to update links, too, and presumably the wiki\n> software helps with that. But that is outside the scope of data storage.\n> In a git-backed wiki, you would get one atomic commit with the move and\n> link updating.\n\nYeah.\n\n>> 3) Support for \"who is linking here\". Also helps reorganization.\n>\n> Again, is that a fundamental storage issue? It seems like you could\n> implement that easily on top of basic storage with a grep (and some\n> caching if you are going to let people do it a lot via the web).\n\nI doubt that. That's where you need an SQL database, to make it fast.\n\n>> 4) Support for categories. Ditto.\n>\n> I have no idea how categories work. Special page naming and/or\n> directories?\n\nEach page has a tag [[Category::Tips]], and then the the\nCategory::Tips page gets a new link automatically. Again, SQL helps.\n\n>> 5) Support for watchlist, e-mail notifications. So that you are\n>> up-to-date with the changes.\n>\n> Post-receive hook?\n\nYeah, but you need to store the watchers, and their preferences. Again, SQL.\n\n>> 6) Support for contribution backtracking. So that it's easy to know who's who.\n>\n> git log? git blame? :)\n\nSure, 'git log' would do it... Very inefficiently.\n\n>> 7) Personal wiki pages (with discussion). So you can put information\n>> about yourself, and general notes.\n>\n> Specially named pages for people?\n\nRight.\n\n> Obviously I'm just filling in these features off the top of my head.\n> MediaWiki is a mature system, and I doubt that either ikiwiki or gollum\n> has nearly the same featureset. But that was never my point. In the bit\n> you quoted, my point was that a git-interface to a wiki was useful and\n> feasible. And I stand by that.\n\nIt might be possible to implement some functionality of a full blown\nwiki such as MediaWiki on a git backed wiki, but my point is that it's\nnot there _now_, and more likely would never be.\n\n> Even with just the basic functionality of fetch/diff/push, that still\n> makes it a useful interface into an existing wiki for a large number of\n> users who just want to do simple stuff (or power users who happen to be\n> doing simple stuff at the moment).\n>\n> I also happen to think you could put all of those features into a\n> git-backed wiki, and build the web features on _top_ of git access. But\n> I'm not volunteering to work on that.\n\nExactly, and nobody is volunteering for that. MediaWiki is the best,\nit has all the features, and it's already there.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"160414","messageId":"1296860479-17517-1-git-send-email-jaredhance@gmail.com","threadId":"26371","inReplyTo":"7vsjw957fq.fsf_-_@alter.siamese.dyndns.org","subject":"[PATCH/RFC] Add support for merging from upstream by default.","fromName":"Jared Hance","fromEmail":"jaredhance@gmail.com","sentAt":"2011-02-04T23:01:19Z","receivedAt":"2011-02-04T23:01:19Z","isPatch":true,"sender":{"key":"jaredhance@gmail.com","avatar":"https://avatars.githubusercontent.com/u/170192?v=4"},"body":"Adds the option merge.defaultupstream to add support for merging from the\nupstream branch by default. The upstream branch is found using\nbranch.[name].upstream.\n---\n\nThis is just testing code; it works but I'm not yet sure if it breaks other\nthings. I tried to code it so it doesn't.\n\nNote: First time using git send-email; I hope I set it up correctly with the\nIn-reply-to and Cc's and such.\n\n builtin/merge.c |   41 +++++++++++++++++++++++++++++++++++------\n 1 files changed, 35 insertions(+), 6 deletions(-)\n\ndiff --git a/builtin/merge.c b/builtin/merge.c\nindex 42fff38..a69b69f 100644\n--- a/builtin/merge.c\n+++ b/builtin/merge.c\n@@ -37,6 +37,7 @@ struct strategy {\n };\n \n static const char * const builtin_merge_usage[] = {\n+        \"git merge\",\n \t\"git merge [options] <remote>...\",\n \t\"git merge [options] <msg> HEAD <remote>\",\n \tNULL\n@@ -58,6 +59,8 @@ static int option_renormalize;\n static int verbosity;\n static int allow_rerere_auto;\n static int abort_current_merge;\n+static int default_upstream;\n+static const char *upstream_branch;\n \n static struct strategy all_strategy[] = {\n \t{ \"recursive\",  DEFAULT_TWOHEAD | NO_TRIVIAL },\n@@ -519,8 +522,15 @@ static int git_merge_config(const char *k, const char *v, void *cb)\n \t\t\t      builtin_merge_usage, 0);\n \t\tfree(buf);\n \t}\n-\n-\tif (!strcmp(k, \"merge.diffstat\") || !strcmp(k, \"merge.stat\"))\n+        else if(branch && !prefixcmp(k, \"branch.\") &&\n+                !prefixcmp(k + 7, branch) &&\n+                !strcmp(k + 7 + strlen(branch), \".upstream\")) {\n+                return git_config_string(&upstream_branch, k, v);\n+        }\n+\n+        if (!strcmp(k, \"merge.defaultupstream\"))\n+                default_upstream = git_config_bool(k, v);\n+        else if (!strcmp(k, \"merge.diffstat\") || !strcmp(k, \"merge.stat\"))\n \t\tshow_diffstat = git_config_bool(k, v);\n \telse if (!strcmp(k, \"pull.twohead\"))\n \t\treturn git_config_string(&pull_twohead, k, v);\n@@ -983,9 +993,28 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \tif (!allow_fast_forward && fast_forward_only)\n \t\tdie(\"You cannot combine --no-ff with --ff-only.\");\n \n-\tif (!argc)\n-\t\tusage_with_options(builtin_merge_usage,\n-\t\t\tbuiltin_merge_options);\n+\tif (!argc) {\n+                if(default_upstream && upstream_branch) {\n+\t\t        struct object *o;\n+                        struct commit *commit;\n+\n+                        o = peel_to_type(upstream_branch, 0, NULL, OBJ_COMMIT);\n+                        if (!o)\n+                            die(\"%s - not something we can merge\", argv[i]);\n+                        commit = lookup_commit(o->sha1);\n+                        commit->util = (void *)upstream_branch;\n+                        remotes = &commit_list_insert(commit, remotes)->next;\n+\n+                        strbuf_addf(&buf, \"GITHEAD_%s\", sha1_to_hex(o->sha1));\n+                        setenv(buf.buf, upstream_branch, 1);\n+                        strbuf_reset(&buf);\n+                }\n+                else {\n+\t\t        usage_with_options(builtin_merge_usage,\n+\t\t\t        builtin_merge_options);\n+\n+                }\n+        }\n \n \t/*\n \t * This could be traditional \"merge <msg> HEAD <commit>...\"  and\n@@ -1048,7 +1077,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \t\t}\n \t}\n \n-\tif (head_invalid || !argc)\n+\tif (head_invalid || (!argc && !(default_upstream && upstream_branch)))\n \t\tusage_with_options(builtin_merge_usage,\n \t\t\tbuiltin_merge_options);\n \n-- \n1.7.4\n"},{"id":"160422","messageId":"alpine.DEB.1.10.1102042152070.14767@debian","threadId":"26371","inReplyTo":"alpine.LFD.2.00.1101311459000.8580@xanadu.home","subject":"Re: [1.8.0] reorganize the mess that the source tree has become","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-02-05T03:21:01Z","receivedAt":"2011-02-05T03:21:01Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Mon, 31 Jan 2011, Nicolas Pitre wrote:\n\n> 2) Create a build/ directory, or bin/ if prefered, to hold the result of \n>    the build.\n\nI don't care much about the other items on the list, but I do agree\nwith this one. The biggest reason I like this is because it makes it\neasier to tab complete. In all the cases so far that I have tab\ncompleted \"git-rebase--i\" to open it in an editor or to run some git\ncommand on it, I have wanted \"git-rebase--interactive.sh\"; I have\nnever wanted the build result.\n\nIt is also nice to have one less file to edit (.gitignore) when you\nadd a new source file, but that is of course much less important.\n\nAre there any arguments against this part of Nicolas's proposal?\n\nBtw, this is not really related to 1.8.0, is it? It seems to me like\nit could be done at any time...\n\n\n/Martin\n"},{"id":"160426","messageId":"alpine.DEB.2.00.1102042259520.8162@asgard.lang.hm","threadId":"26371","inReplyTo":"20110204143421.GA6449@gnu.kitenet.net","subject":"Re: moving to a git-backed wiki","fromName":"","fromEmail":"david@lang.hm","sentAt":"2011-02-05T07:00:16Z","receivedAt":"2011-02-05T07:00:16Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 4 Feb 2011, Joey Hess wrote:\n\n> Jeff King wrote:\n>> If it sounds like I'm handwaving away scalability problems, I am. I'd be\n>> curious to see some performance numbers for gollum or ikiwiki versus\n>> more traditional wiki formats.\n>\n> Ikiwiki builds static pages, this tends to mean it doesn't have\n> performance, because there is little more to perform than\n> httpd < file > network :)\n> So I've routinely had ikiwiki sites slashdotted, and not noticed.\n\nI think you mean it doesn't have performance _problems_ ;-)\n\nDavid Lang\n\n> Ikiwiki is not enormously fast in the rare cases when it does have to\n> run as a CGI, but little of that has to do with git. About the worst\n> case is that saving a page edit leads to a git commit -- if git\n> decides to gc the repository right then, it could make the save stall\n> for a while. There are easy ways to avoid that. (ie, git gc in cron job)\n> In general, though ikiwiki as a CGI is fast enough to not be annoying --\n> although it won't scale to a site the size of wikipedia.\n>\n> Since I'm lazy, ikiwiki does not include a history or diff viewer. It\n> just points off to gitweb or a similar tool. As you say, gitweb can be\n> fast enough, and really most wiki users do read their current content,\n> or maybe make an edit; digging in the history is comparatively rare.\n> And once users realize the wiki is in git, they can use gitk to dig in\n> the history without using any server resources. :)\n>\n> The feature I like best with using git for a wiki (besides ease of\n> branching) is that it can actually make a legitimate use of the\n> woefully underused git push over git:// feature. Ikiwiki can be\n> configured to check such pushes, running via the pre-receive hook. This\n> allows it to limit the changes that can be pushed anonymously to changes\n> that could be made using the web interface. So if you've chosen to lock\n> some pages, or virus filter attachments, or whatever, in the web side of\n> the wiki, that all applies to the anonymous git pushes too. Details at\n> <http://ikiwiki.info/tips/untrusted_git_push/>\n>\n>\n"},{"id":"160427","messageId":"4D4CFFB4.2040508@pcharlan.com","threadId":"26371","inReplyTo":"4928FF12-E593-4CDB-AC68-B4078CC5920E@gmail.com","subject":"Re: [1.8.0] Tracking empty directories","fromName":"Pete Harlan","fromEmail":"pgit@pcharlan.com","sentAt":"2011-02-05T07:43:48Z","receivedAt":"2011-02-05T07:43:48Z","isPatch":false,"sender":{"key":"pgit@pcharlan.com","avatar":null},"body":"On 02/02/2011 03:33 PM, David Aguilar wrote:\n> I don't like where this is going. Users are not always right. Touch\n> .gitignore and be done with it.  This is a big change with\n> negligible benefits.  I don't understand why this is needed.\n\nI worked for a huge company that was converting a large project to\nGit.  They had a wiki about the conversion.  There was a section\ntitled \"Git Gotchas\" that had one entry: Git Doesn't Track Empty\nDirectories.\n\nThis has come up as something to be worked around in each of the\nconversions to Git I've been part of.\n\nAnd unlike other things Git doesn't track, such as permissions or\nmodification times, I can't argue that Git's behavior here is superior\nto what they were expecting.  I'd love to see this feature in Git if\nonly to make the issue go away.  And I don't think it's a slippery\nslope, that once this is in then they'll be clamoring for resource\nforks and ACLs.  Developers know some things aren't handled by SCMs,\nthey just don't think that includes directories.\n\n--Pete\n"},{"id":"160459","messageId":"201102051931.10979.thomas@koch.ro","threadId":"26371","inReplyTo":"m3zkqe8xc8.fsf_-_@localhost.localdomain","subject":"Re: [1.8.0] Tracking empty directories","fromName":"Thomas Koch","fromEmail":"thomas@koch.ro","sentAt":"2011-02-05T18:31:10Z","receivedAt":"2011-02-05T18:31:10Z","isPatch":false,"sender":{"key":"thomas@koch.ro","avatar":null},"body":"Jakub Narebski:\n> there is (supposedly) problem when checking out such tree (see email\n> referenced above) with an old git.\nProposal:\n\n- Implement the possibility to checkout/read/handle empty directories as soon \nas possible, even in the next 1.7.x release.\n- Don't implement the possibility to create/commit empty directories yet.\n- Implement the possibility to checkin empty directories next year, but allow \nit only, if the user knows that this breaks backwards compatibility of the \nrepo. (Generate warning and require --commit-empty-directories option)\n\nSorry if this should be crap. I'm not a GIT dev.\n\nBest regards,\n\nThomas Koch, http://www.koch.ro\n"},{"id":"160460","messageId":"AANLkTikX5Y=TrXayXj-MCaR5p0=Tokc_5ihGqHFL9CQx@mail.gmail.com","threadId":"26371","inReplyTo":"201102051931.10979.thomas@koch.ro","subject":"Re: [1.8.0] Tracking empty directories","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-02-05T19:00:47Z","receivedAt":"2011-02-05T19:00:47Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Sat, Feb 5, 2011 at 19:31, Thomas Koch <thomas@koch.ro> wrote:\n> - Implement the possibility to checkout/read/handle empty directories as soon\n> as possible, even in the next 1.7.x release.\n\nI think regardless of whatever else we do, this makes sense. I think\nit's been suggested by Junio in a neighboring thread as well.\n\n> - Implement the possibility to checkin empty directories next year, but allow\n> it only, if the user knows that this breaks backwards compatibility of the\n> repo. (Generate warning and require --commit-empty-directories option)\n\nI don't know about this part though.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"160467","messageId":"1296945433.3616.2.camel@localhost.localdomain","threadId":"26371","inReplyTo":"AANLkTikX5Y=TrXayXj-MCaR5p0=Tokc_5ihGqHFL9CQx@mail.gmail.com","subject":"Re: [1.8.0] Tracking empty directories","fromName":"Jared Hance","fromEmail":"jaredhance@gmail.com","sentAt":"2011-02-05T22:37:13Z","receivedAt":"2011-02-05T22:37:13Z","isPatch":false,"sender":{"key":"jaredhance@gmail.com","avatar":"https://avatars.githubusercontent.com/u/170192?v=4"},"body":"> > - Implement the possibility to checkin empty directories next year, but allow\n> > it only, if the user knows that this breaks backwards compatibility of the\n> > repo. (Generate warning and require --commit-empty-directories option)\n> \n> I don't know about this part though.\n> \n\nI would say that if we are going to require an option, it should be\ncore.emptyDirectory , which would default to false. It would be much\nmore annoying than having to supply an option every time. I also\ndisagree with warning for this.\n"},{"id":"160487","messageId":"AANLkTinHicAkOmOnXOX4h5N-44C55bGnFmutXZBcssWP@mail.gmail.com","threadId":"26371","inReplyTo":"201102051931.10979.thomas@koch.ro","subject":"Re: [1.8.0] Tracking empty directories","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-06T04:42:54Z","receivedAt":"2011-02-06T04:42:54Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sun, Feb 6, 2011 at 1:31 AM, Thomas Koch <thomas@koch.ro> wrote:\n> Jakub Narebski:\n>> there is (supposedly) problem when checking out such tree (see email\n>> referenced above) with an old git.\n> Proposal:\n>\n\n(Elaborate the \"handle\" part from your first item)\n\n- Teach diff machinery about empty trees. At least diff-tree should\nshow empty tree addition/removal. diff-index and diff-files can learn\nlater when index supports empty trees.\n\n- Teach merge empty trees.\n\n> - Implement the possibility to checkout/read/handle empty directories as soon\n> as possible, even in the next 1.7.x release.\n> - Don't implement the possibility to create/commit empty directories yet.\n> - Implement the possibility to checkin empty directories next year, but allow\n> it only, if the user knows that this breaks backwards compatibility of the\n> repo. (Generate warning and require --commit-empty-directories option)\n-- \nDuy\n"},{"id":"160547","messageId":"7vmxm8x5dx.fsf@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"AANLkTikX5Y=TrXayXj-MCaR5p0=Tokc_5ihGqHFL9CQx@mail.gmail.com","subject":"Re: [1.8.0] Tracking empty directories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-06T20:41:30Z","receivedAt":"2011-02-06T20:41:30Z","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> On Sat, Feb 5, 2011 at 19:31, Thomas Koch <thomas@koch.ro> wrote:\n>> - Implement the possibility to checkout/read/handle empty directories as soon\n>> as possible, even in the next 1.7.x release.\n>\n> I think regardless of whatever else we do, this makes sense. I think\n> it's been suggested by Junio in a neighboring thread as well.\n\nHuh?\n"},{"id":"160549","messageId":"AANLkTimo44R_=CLqZ=+TZmtctAnBXbxEakEBdgUVeY1L@mail.gmail.com","threadId":"26371","inReplyTo":"7vmxm8x5dx.fsf@alter.siamese.dyndns.org","subject":"Re: [1.8.0] Tracking empty directories","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-02-06T20:46:34Z","receivedAt":"2011-02-06T20:46:34Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Sun, Feb 6, 2011 at 21:41, Junio C Hamano <gitster@pobox.com> wrote:\n> Huh?\n\nTo teach the plumbing to handle empty directories first, and then in a\nlater release add porcelain?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"160706","messageId":"AANLkTikyHANL3y8VZ3LWu7bXkJwEHiiDLJ5NDZaA7z=b@mail.gmail.com","threadId":"26371","inReplyTo":"AANLkTik4jZWLt6T-SwMgK94FJ77ujyUC4-oFD46-eqN=@mail.gmail.com","subject":"Re: What's cooking in git.git (Jan 2011, #06; Sun, 30)","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-02-08T17:48:24Z","receivedAt":"2011-02-08T17:48:24Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Jan 31, 2011 at 16:08, Sverre Rabbelier <srabbelier@gmail.com> wrote:\n> On Tue, Dec 14, 2010 at 03:20, Junio C Hamano <gitster@pobox.com> wrote:\n>> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>>> On Mon, Dec 13, 2010 at 09:34, Junio C Hamano <gitster@pobox.com> wrote:\n>>>\n>>>> Needs a bit more minor work to get the basic code structure right.\n>>>\n>>> And I'm still not sure (see earlier replies to \"What's Cooking\" posts)\n>>> what needs to be done to make it better.\n>>\n>> One open question was why you do not want to move 'LIB_OBJS += gettext.o'\n>> away from the LIB_OBJS section down to the configuration evaluation\n>> section, i.e., why gettext.o would be different from block-sha1/sha1.o.\n>\n> Ævar, you didn't respond to that message. Junio, do I understand\n> correctly that if this problem is addressed the topic is ready to be\n> merged to next?\n\nIt's been a week, no response from either Junio or Ævar ? :(\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"160710","messageId":"7v4o8eqqcs.fsf@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"AANLkTikyHANL3y8VZ3LWu7bXkJwEHiiDLJ5NDZaA7z=b@mail.gmail.com","subject":"Re: What's cooking in git.git (Jan 2011, #06; Sun, 30)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-08T19:27:15Z","receivedAt":"2011-02-08T19:27:15Z","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>> Ævar, you didn't respond to that message. Junio, do I understand\n>> correctly that if this problem is addressed the topic is ready to be\n>> merged to next?\n\nNecessary? yes. Sufficient? I dunno, but it is a good start, I think.\n"},{"id":"160765","messageId":"AANLkTineuxosCRRRJosziv9umgtO9uN3nAAh_v=f3Vfk@mail.gmail.com","threadId":"26371","inReplyTo":"201102021951.31883.trast@student.ethz.ch","subject":"Re: [1.8.0] git-stash invocation changes","fromName":"Pat Notz","fromEmail":"patnotz@gmail.com","sentAt":"2011-02-09T14:35:38Z","receivedAt":"2011-02-09T14:35:38Z","isPatch":false,"sender":{"key":"patnotz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45364?v=4"},"body":"On Wed, Feb 2, 2011 at 11:51 AM, Thomas Rast <trast@student.ethz.ch> wrote:\n> Matthieu Moy wrote:\n>> Shawn Pearce <spearce@spearce.org> writes:\n>>\n>> > On Wed, Feb 2, 2011 at 09:23, Thomas Rast <trast@student.ethz.ch> wrote:\n>> >> Proposal:\n>> >>\n>> >> 1. Change 'git stash <not-a-stash-command>' to give a usage message\n>> >>   instead of using <not-a-stash-command> as the stash message.\n>> >\n>> > Oh please, yes, please do this.  We should have done this long, long\n>> > ago.  Its easy enough to train your fingers or fix your scripts to say\n>> > `git stash save list` rather than `git stash lsit` once stash errors\n>> > out and gives you a usage message once.\n>>\n>> Err, hasn't this been fixed long ago already?\n>\n> Oh, you're actually right.  I have totally missed this, and should\n> obviously have tested first.\n>\n> Still, I think the change to 'git stash -p' is also worthwhile.\n>\n\nThere's still something annoyingly different about git-stash. Most git\ncommands that take sub-commands simply list useful information when\nyou don't provide a sub-command:\n\ngit branch --> lists local branches\ngit tag --> lists tags\ngit remote --> lists remotes\ngit stash --> creates a new stash\n\nIt would be much more predictable if git-stash without a sub-command\njust listed the current stashes. But, at this point it's probably too\nlate to change that behavior.\n\n> --\n> Thomas Rast\n> trast@{inf,student}.ethz.ch\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"160834","messageId":"4D543FB4.1040709@lsrfire.ath.cx","threadId":"26371","inReplyTo":"20110202005748.GA13803@elie","subject":"Re: [1.8.0] Remove deprecated commands","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2011-02-10T19:42:44Z","receivedAt":"2011-02-10T19:42:44Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 02.02.2011 01:57, schrieb Jonathan Nieder:\n>>     git-lost-found   2007-11-08       git fsck --lost-found\n>\n> It can stay in contrib/examples for inspiration.\n\nSure.\n\n>>     git-peek-remote  2007-11-24       git ls-remote\n>\n> No one seems to be using it\n> (github.com/gitpan/App-GitHub-FindRepository.git uses it as a fallback\n> when ls-remote is not present).\n\nHow did you search for current usage?  How comprehensive are the results?\n\n>>     git-repo-config  2008-01-17       git config\n>\n> giggle[1] still uses it --- see libgiggle-git/giggle-git-config-read.c\n> and giggle-git-config-write.c.\n>\n> Likewise darcs2git[2] and the stgit testsuite.\n>\n> webkit's VCSUtils.pm only uses repo-config as a fallback when git\n> config is not present.\n\nWell, the release notes for 1.5.4 promised that the \"next feature \nrelease will remove it\".  Perhaps notifying the developers of the \nprojects you discovered is enough?\n\nThat said, the benefit for final removal of this command, which is \neffectively just an alias, is the smallest of the four.\n\n>>     git-tar-tree     2007-11-08       git archive\n>\n> Already prints a deprecation notice.  WWW::PkgFind from CPAN uses it\n> but doesn't seem to be maintained.\n>\n> pilgrim[3] uses tar-tree in its \"make dist\" target.  I wouldn't be\n> surprised if some other projects use it in a similar way.\n\nPossibly, and this shows that deprecation warnings don't fully solve the \nproblem of educating users to switch to the replacements.\n\nI think it's relatively safe to remove the command anyway because the \nusers in this case are developers and packagers, i.e. the ones who put \nthe command in the Makefile in the first place.  They should be able to \ncope easily.\n\nRené\n"},{"id":"160836","messageId":"20110210205620.GD21144@elie","threadId":"26371","inReplyTo":"4D543FB4.1040709@lsrfire.ath.cx","subject":"Re: [1.8.0] Remove deprecated commands","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-10T20:56:20Z","receivedAt":"2011-02-10T20:56:20Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"René Scharfe wrote:\n\n> How did you search for current usage?  How comprehensive are the results?\n\nBy searching for \"peek-remote\" at http://www.google.com/codesearch\n\nI tried to check out all hits that weren't just enumerating git\ncommands, but that doesn't rule out unindexed or non-public use.\nNo interesting hits.\n\nBut that's pretty weird, given that there was no deprecation\nnotice, nor anything else to encourage a transition.\n\n*checks history*\n\nAh, peek-remote and ls-remote seem to have been introduced at the same\ntime.  ls-remote could use all git-supported protocols, while\npeek-remote could only use git protocol.  So very few people had\nreason to use peek-remote, anyway.\n\n> Am 02.02.2011 01:57, schrieb Jonathan Nieder:\n\n>>>    git-repo-config  2008-01-17       git config\n>>\n>> giggle[1] still uses it\n[...]\n>> Likewise darcs2git[2] and the stgit testsuite.\n[...]\n> Well, the release notes for 1.5.4 promised that the \"next feature\n> release will remove it\".  Perhaps notifying the developers of the\n> projects you discovered is enough?\n\nThe list is probably not exhaustive.  On the bright side, repo-config\ntends to be run in user-visible contexts, so I think a deprecation\nnotice could be effective.\n\n> That said, the benefit for final removal of this command, which is\n> effectively just an alias, is the smallest of the four.\n\nAfter adding a deprecation notice and filing some bugs, I think we\ncan forget about it and wait another year. ;-)\n\n>>>    git-tar-tree     2007-11-08       git archive\n[...]\n>> pilgrim[3] uses tar-tree in its \"make dist\" target.  I wouldn't be\n>> surprised if some other projects use it in a similar way.\n>\n> Possibly, and this shows that deprecation warnings don't fully solve\n> the problem of educating users to switch to the replacements.\n>\n> I think it's relatively safe to remove the command anyway because\n> the users in this case are developers and packagers\n\nI agree.  The remaining users look like holdouts that will be hard to\nget at by other means.\n"},{"id":"160837","messageId":"7vlj1n38ej.fsf@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"20110210205620.GD21144@elie","subject":"Re: [1.8.0] Remove deprecated commands","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-10T21:08:04Z","receivedAt":"2011-02-10T21:08:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> Ah, peek-remote and ls-remote seem to have been introduced at the same\n> time.  ls-remote could use all git-supported protocols, while\n> peek-remote could only use git protocol.\n\nYes, peek-remote was a backend for ls-remote, just like http-fetch was one\nof the backends for fetch.\n"},{"id":"160949","messageId":"4D5689FA.90804@lsrfire.ath.cx","threadId":"26371","inReplyTo":"20110210205620.GD21144@elie","subject":"Re: [1.8.0] Remove deprecated commands","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2011-02-12T13:24:10Z","receivedAt":"2011-02-12T13:24:10Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 10.02.2011 21:56, schrieb Jonathan Nieder:\n> René Scharfe wrote:\n>> Am 02.02.2011 01:57, schrieb Jonathan Nieder:\n>>>>     git-repo-config  2008-01-17       git config\n>>>\n>>> giggle[1] still uses it\n> [...]\n>>> Likewise darcs2git[2] and the stgit testsuite.\n> [...]\n>> Well, the release notes for 1.5.4 promised that the \"next feature\n>> release will remove it\".  Perhaps notifying the developers of the\n>> projects you discovered is enough?\n> \n> The list is probably not exhaustive.  On the bright side, repo-config\n> tends to be run in user-visible contexts, so I think a deprecation\n> notice could be effective.\n> \n>> That said, the benefit for final removal of this command, which is\n>> effectively just an alias, is the smallest of the four.\n> \n> After adding a deprecation notice and filing some bugs, I think we\n> can forget about it and wait another year. ;-)\n\n-- >8 --\nSubject: [PATCH] repo-config: add deprecation warning\n\nrepo-config was deprecated in 5c66d0d4 on 2008-01-17.  Warn the\nremaining users that it has been replaced by config and is going to\nbe removed eventually.\n\nSigned-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>\n---\n builtin.h        |    3 ++-\n builtin/config.c |    6 ++++++\n git.c            |    2 +-\n 3 files changed, 9 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin.h b/builtin.h\nindex 904e067..0e9da90 100644\n--- a/builtin.h\n+++ b/builtin.h\n@@ -57,6 +57,7 @@ extern int cmd_clone(int argc, const char **argv, const char *prefix);\n extern int cmd_clean(int argc, const char **argv, const char *prefix);\n extern int cmd_commit(int argc, const char **argv, const char *prefix);\n extern int cmd_commit_tree(int argc, const char **argv, const char *prefix);\n+extern int cmd_config(int argc, const char **argv, const char *prefix);\n extern int cmd_count_objects(int argc, const char **argv, const char *prefix);\n extern int cmd_describe(int argc, const char **argv, const char *prefix);\n extern int cmd_diff_files(int argc, const char **argv, const char *prefix);\n@@ -110,7 +111,7 @@ extern int cmd_reflog(int argc, const char **argv, const char *prefix);\n extern int cmd_remote(int argc, const char **argv, const char *prefix);\n extern int cmd_remote_ext(int argc, const char **argv, const char *prefix);\n extern int cmd_remote_fd(int argc, const char **argv, const char *prefix);\n-extern int cmd_config(int argc, const char **argv, const char *prefix);\n+extern int cmd_repo_config(int argc, const char **argv, const char *prefix);\n extern int cmd_rerere(int argc, const char **argv, const char *prefix);\n extern int cmd_reset(int argc, const char **argv, const char *prefix);\n extern int cmd_rev_list(int argc, const char **argv, const char *prefix);\ndiff --git a/builtin/config.c b/builtin/config.c\nindex ca4a0db..dad86fe 100644\n--- a/builtin/config.c\n+++ b/builtin/config.c\n@@ -500,3 +500,9 @@ int cmd_config(int argc, const char **argv, const char *prefix)\n \n \treturn 0;\n }\n+\n+int cmd_repo_config(int argc, const char **argv, const char *prefix)\n+{\n+\tfprintf(stderr, \"WARNING: git repo-config is deprecated in favor of git config.\\n\");\n+\treturn cmd_config(argc, argv, prefix);\n+}\ndiff --git a/git.c b/git.c\nindex 23610aa..65ed68f 100644\n--- a/git.c\n+++ b/git.c\n@@ -392,7 +392,7 @@ static void handle_internal_command(int argc, const char **argv)\n \t\t{ \"remote-ext\", cmd_remote_ext },\n \t\t{ \"remote-fd\", cmd_remote_fd },\n \t\t{ \"replace\", cmd_replace, RUN_SETUP },\n-\t\t{ \"repo-config\", cmd_config, RUN_SETUP_GENTLY },\n+\t\t{ \"repo-config\", cmd_repo_config, RUN_SETUP_GENTLY },\n \t\t{ \"rerere\", cmd_rerere, RUN_SETUP },\n \t\t{ \"reset\", cmd_reset, RUN_SETUP },\n \t\t{ \"rev-list\", cmd_rev_list, RUN_SETUP },\n-- \n1.7.4\n"},{"id":"160959","messageId":"20110212210431.GA8808@elie","threadId":"26371","inReplyTo":"4D5689FA.90804@lsrfire.ath.cx","subject":"Re: [1.8.0] Remove deprecated commands","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-12T21:04:31Z","receivedAt":"2011-02-12T21:04:31Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"René Scharfe wrote:\n\n> Subject: [PATCH] repo-config: add deprecation warning\n>\n> repo-config was deprecated in 5c66d0d4 on 2008-01-17.  Warn the\n> remaining users that it has been replaced by config and is going to\n> be removed eventually.\n>\n> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>\n\nLooks good to me, for what it's worth.  Thanks for taking care of it.\n"},{"id":"161017","messageId":"7vzkpzv879.fsf@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"4D5689FA.90804@lsrfire.ath.cx","subject":"Re: [1.8.0] Remove deprecated commands","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-13T23:14:02Z","receivedAt":"2011-02-13T23:14:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thanks; applied.\n"},{"id":"162050","messageId":"4D65660D.3040501@web.de","threadId":"26371","inReplyTo":"7vwrll57ha.fsf@alter.siamese.dyndns.org","subject":"[1.8.0] Don't copy \"submodule.<name>.update\" to .git/config on submodule init","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-02-23T19:54:53Z","receivedAt":"2011-02-23T19:54:53Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Proposal:\n\nStop copying the \"submodule.<name>.update\" entries into .git/config\non \"git submodule init\". The current behavior makes it impossible\nfor upstream to change defaults later, as this value can only be\naltered through user intervention when it resides in .git/config.\nThis is a good thing when he chose to copy it there, but it doesn't\nseem to make much sense doing it by default. When for example\nupstream wants to provide a branch for hacking on an otherwise\nignored submodule, it cannot do that without the users intervention\nright now.\n\nThis change also makes sense in preparation of recursive submodule\ncheckout, as that will be controlled by this option. Also notice\nthat the proposed behavior is already used for the \"ignore\" and\n\"fetchRecurseSubmodules\" entries.\n\nHistory:\n\nI can't tell why that copy is done as I wasn't following the list\nclosely at the time this was implemented. Maybe someone else can\nshed some light on that?\n\nRisks:\n\nUsers could be surprised that upstream can change the value of the\n\"update\" configuration when the submodule was initialized with a\ngit version >= 1.8.0.\n\nMigration plan:\n\nIn 1.8.0 stop copying the \"submodule.<name>.update\" entries into\n.git/config and add an option (\"--update\"?) to reactivate the old\nbehavior of \"git submodule init\" if the user wants that. Announce\nboth in the release notes of 1.8.0.\n"},{"id":"162051","messageId":"7v7hcq8pil.fsf@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"4D65660D.3040501@web.de","subject":"Re: [1.8.0] Don't copy \"submodule.<name>.update\" to .git/config on submodule init","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-23T20:28:02Z","receivedAt":"2011-02-23T20:28:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann <Jens.Lehmann@web.de> writes:\n\n> Proposal:\n>\n> Stop copying the \"submodule.<name>.update\" entries into .git/config\n> on \"git submodule init\". The current behavior makes it impossible\n> for upstream to change defaults later, as this value can only be\n> altered through user intervention when it resides in .git/config.\n> This is a good thing when he chose to copy it there, but it doesn't\n> seem to make much sense doing it by default.\n\nDoesn't it just come from the usual \"upstream can give a sane default as\nrecommendation to users who may not bother to set up .git/config, and the\nuser can tweak that if that doesn't suit his/her needs\" convention?\n\nI have a feeling that the correct fix (not limited to \"update\" but all the\nsubmodule related configuration that share the same \"give default, allow\ntweak\" philosophy) is to:\n\n (1) record submodule.<name>.update at initialization time, to allow the\n     upstream a chance to give a sensible default, as we do now;\n\n (2) in addition to that, record the fact that the value came as upstream\n     default.  You could do so in multiple ways:\n\n     a) record the commit that gave the suggested default to .git/config,\n     perhaps submodule.<name>.defaultedFrom (notice that this is\n     independent from \"update\", and covers all such configuration\n     variables with a single value); or\n\n     b) record the value the upstream gave to .git/config in a separate\n     variable, perhaps submodule.<name>.updateSuggested; or\n\n     c) some other clever way you can think of, as long as it lets us do\n     the next step.\n\n (3) when updating from the upstream results in a change in .gitmodules\n     file that changes the previously suggested default the user\n     considered, tell that to the user and have him/her choose.  If you\n     took (a) in the previous step, you can use \"git diff\" to determine if\n     the suggested default has changed; if you took (b) in the previous\n     step, you can compare submodule.<name>.update in .gitmodules with\n     submodule.<name>.updateSuggested to do so; if you did (c), you are on\n     your own ;-).  After the user updates (or chooses to keep the current\n     setting), record the current suggested default just like you did at\n     the init time in step (2).\n\nOne thing to be careful is in (3) you should not bother users who chose to\nignore the upstream default (i.e. has submodule.<name>.update set\ndifferently from what is suggested by the .gitmodules at the time of\ninitialization).  The reason (3) updates the \"current suggested default\"\nis exactly for that purpose---the user has seen what the last suggested\ndefault was, and decided to either go with it or have his/her own setting.\n"},{"id":"162061","messageId":"4D658D8F.2040203@web.de","threadId":"26371","inReplyTo":"7v7hcq8pil.fsf@alter.siamese.dyndns.org","subject":"Re: [1.8.0] Don't copy \"submodule.<name>.update\" to .git/config on submodule init","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-02-23T22:43:27Z","receivedAt":"2011-02-23T22:43:27Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 23.02.2011 21:28, schrieb Junio C Hamano:\n> Jens Lehmann <Jens.Lehmann@web.de> writes:\n> \n>> Proposal:\n>>\n>> Stop copying the \"submodule.<name>.update\" entries into .git/config\n>> on \"git submodule init\". The current behavior makes it impossible\n>> for upstream to change defaults later, as this value can only be\n>> altered through user intervention when it resides in .git/config.\n>> This is a good thing when he chose to copy it there, but it doesn't\n>> seem to make much sense doing it by default.\n> \n> Doesn't it just come from the usual \"upstream can give a sane default as\n> recommendation to users who may not bother to set up .git/config, and the\n> user can tweak that if that doesn't suit his/her needs\" convention?\n\nYup, but when *copying* it locally upstream won't be able to change that\ndefault ever again. Wouldn't it suffice to copy that *only* if the user\nreally wants to tweak it?\n\nAnd now I read that again I notice that I forgot to add a very important\nsentence, sorry about that:\n\n\"Take the setting from .gitmodules if submodule.<name>.update is not\nconfigured by the user in .git/config.\"\n\n> I have a feeling that the correct fix (not limited to \"update\" but all the\n> submodule related configuration that share the same \"give default, allow\n> tweak\" philosophy) is to:\n\nI agree that all should behave the same way for consistency reasons.\n\n>  (1) record submodule.<name>.update at initialization time, to allow the\n>      upstream a chance to give a sensible default, as we do now;\n> \n>  (2) in addition to that, record the fact that the value came as upstream\n>      default.  You could do so in multiple ways:\n> \n>      a) record the commit that gave the suggested default to .git/config,\n>      perhaps submodule.<name>.defaultedFrom (notice that this is\n>      independent from \"update\", and covers all such configuration\n>      variables with a single value); or\n> \n>      b) record the value the upstream gave to .git/config in a separate\n>      variable, perhaps submodule.<name>.updateSuggested; or\n> \n>      c) some other clever way you can think of, as long as it lets us do\n>      the next step.\n\nMy proposal uses the values in .gitmodules for those proposed by upstream\nand those in .git/config as those tweaked by the user. Isn't that simpler\nthan 1) and 2) while giving us the same functionality? And additionally it\nis not setting the upstream default in stone (which is rather arbitrary as\nit just happened to be present in our .gitmodules when we did the \"git\nsubmodule init\" and might be different at another point in the history)?\n\n>  (3) when updating from the upstream results in a change in .gitmodules\n>      file that changes the previously suggested default the user\n>      considered, tell that to the user and have him/her choose.  If you\n>      took (a) in the previous step, you can use \"git diff\" to determine if\n>      the suggested default has changed; if you took (b) in the previous\n>      step, you can compare submodule.<name>.update in .gitmodules with\n>      submodule.<name>.updateSuggested to do so; if you did (c), you are on\n>      your own ;-).  After the user updates (or chooses to keep the current\n>      setting), record the current suggested default just like you did at\n>      the init time in step (2).\n> \n> One thing to be careful is in (3) you should not bother users who chose to\n> ignore the upstream default (i.e. has submodule.<name>.update set\n> differently from what is suggested by the .gitmodules at the time of\n> initialization).  The reason (3) updates the \"current suggested default\"\n> is exactly for that purpose---the user has seen what the last suggested\n> default was, and decided to either go with it or have his/her own setting.\n\nConsider the following situation: The .git directories of the submodules\nreside in the .git directory of the superproject so their work trees can\nbe safely deleted and we have means to let upstream configure which\nsubmodules should be populated on clone. (Hopefully this is the future ;-)\n\nWhat happens when we fetch a commit which records a new submodule marked\nto be populated on clone in the .gitmodules of that commit? I assume we\nwould want to fetch the bare submodule into a subdirectory of the .git\ndirectory of the superproject so that we have it present so we can\npopulate it when the superproject's commit is checked out later, no?\n\nShould we ask the user if he wants to fetch the bare submodule into the\n.git directory of the superproject or to ignore the clone setting while\nfetching? Should we ask him again on checkout time if he wants to use the\nupstream setting of checking out the submodule? Or should we just let it\nhappen and when the user decides that he never wanted this submodule he\nsays so in his .git/config while everybody who is happy with the default\njust moves on? (And of course we would honor any configurations the user\ndid beforehand, like e.g. ignoring all upstream clone defaults)\n\nI have the impression that using submodules won't work smoothly unless\nwe honor the defaults set by upstream until told otherwise by the user.\nIf we copy the settings into .git/config right away we take away much of\nthe flexibility that I believe is needed here, and I can't really see\nthe upsides of that. But the downside is that the setting is copied at\nan random point in time and therefore is rather arbitrary.\n\nAnother example is the repo where submodules normally use the on-demand\nfetch mode (so everybody only gets those submodule commits he really\nneeds) while having topic branches where certain submodules are always\nfetched in full to be able to record new commits of those in the\nsuperproject. Depending on what branch you were when the copy into\n.git/config occurred you would be stuck with either setting, which I\nthink is suboptimal.\n\nWhat am I missing?\n"},{"id":"162088","messageId":"7vwrkq46e2.fsf@alter.siamese.dyndns.org","threadId":"26371","inReplyTo":"4D658D8F.2040203@web.de","subject":"Re: [1.8.0] Don't copy \"submodule.<name>.update\" to .git/config on submodule init","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-24T00:34:45Z","receivedAt":"2011-02-24T00:34:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann <Jens.Lehmann@web.de> writes:\n\n> And now I read that again I notice that I forgot to add a very important\n> sentence, sorry about that:\n>\n> \"Take the setting from .gitmodules if submodule.<name>.update is not\n> configured by the user in .git/config.\"\n\nYeah, that changes everything.\n\n> My proposal uses the values in .gitmodules for those proposed by upstream\n> and those in .git/config as those tweaked by the user. Isn't that simpler\n> than 1) and 2) while giving us the same functionality?\n\nIt actually is even more flexible, in that it allows the user to say \"I\ndon't care either way; I'll follow along whatever the version that I\nhappen to have checked out says\"; I am however tempted to think that this\nparticular flexibility is not necessarily a good thing to have.\n\n> And additionally it\n> is not setting the upstream default in stone (which is rather arbitrary as\n> it just happened to be present in our .gitmodules when we did the \"git\n> submodule init\" and might be different at another point in the history)?\n\nIf the setting changes the behaviour of the command so drastically, would\nthe \"I'll follow along\" mode be really sensible?  A setting in .gitmodules\nmight be different between 'maint' and 'master' from the upstream and\ndepending on which branch is checked out and you are working on, you may\nget different behaviour (e.g. 'checkout' vs 'merge' vs 'rebase' depending\non the value-of-the-day in submodule.<name>.update).  Depending on the\nnature of the setting, it may or may not be.\n\nThe \"record once and then help the users to adjust but make aware of the\nnew duggestion\" actually comes from a very old discussion circa 1.5.2\ndays:\n\n  Cf. http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47621\n\nImagine the upstream URL to fetch submodule from has changed over time.\nYou don't want to interact with an ancient and now defunct URL only\nbecause you happen to have a checkout of an old version by reading from\nits .gitmodules file.  The (2) and (3) in the previous message when taken\nto their logical conclusion will be the \"seen values\" that is hinted in\nthe above message from May 2007.  Let the user record what s/he wants\nunder the condition that s/he has seen these choices, and do not bother\nher/im again when choices do not change, but do ask permission and/or\nconfirmation when a new choice appears.  git-submodule script hasn't\nlearned to do that yet, unfortunately.\n\nIn any case, URL is a good example of variables that would want to stay\naround (while giving the user helping hand to update it when choice\nchanges).  \"update\" would be a good example of a variable that may want to\nbe per branch (e.g. 'maint' might encourage \"checkout\" while 'master'\nmight encourage \"rebase\").  So most likely we would need to support both\nmodes of operation.\n\n> Consider the following situation: The .git directories of the submodules\n> reside in the .git directory of the superproject so their work trees can\n> be safely deleted and we have means to let upstream configure which\n> submodules should be populated on clone. (Hopefully this is the future ;-)\n\nYes, this is very much needed and that is one of the reasons we introduced\nthe support for textual \".git\" file.\n\n> What happens when we fetch a commit which records a new submodule marked\n> to be populated on clone in the .gitmodules of that commit? I assume we\n\nMarked by who?  The supplier of the superproject?\n\n> would want to fetch the bare submodule into a subdirectory of the .git\n> directory of the superproject so that we have it present so we can\n> populate it when the superproject's commit is checked out later, no?\n\nIf the user consents (e.g. \"git clone --recursive\"), yes.\n\n> Should we ask the user if he wants to fetch the bare submodule into the\n> .git directory of the superproject or to ignore the clone setting while\n> fetching?\n\nIf we don't know what the user wants yet, yes.  Note that explicit command\nline options \"git clone --recursive\" and $HOME/.gitconfig counts as the\nuser letting us know what s/he wants.\n\n> ... Should we ask him again on checkout time if he wants to use the\n> upstream setting of checking out the submodule?\n\nYes if the available choice and/or suggestion by the upstream has changed,\notherwise no.\n"},{"id":"162200","messageId":"4D66ED69.7090806@web.de","threadId":"26371","inReplyTo":"7vwrkq46e2.fsf@alter.siamese.dyndns.org","subject":"Re: [1.8.0] Don't copy \"submodule.<name>.update\" to .git/config on submodule init","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-02-24T23:44:41Z","receivedAt":"2011-02-24T23:44:41Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 24.02.2011 01:34, schrieb Junio C Hamano:\n> Jens Lehmann <Jens.Lehmann@web.de> writes:\n> In any case, URL is a good example of variables that would want to stay\n> around (while giving the user helping hand to update it when choice\n> changes).  \"update\" would be a good example of a variable that may want to\n> be per branch (e.g. 'maint' might encourage \"checkout\" while 'master'\n> might encourage \"rebase\").  So most likely we would need to support both\n> modes of operation.\n\nYeah, I totally agree that the URL has to be copied to .git/config and\nmust be updated only on the users request. I'm not sure the \"giving the\nuser a helping hand\" approach will work so well as I suspect switching\nback and forth between branches might spam the user with helping hands\nevery time, but maybe I'm missing something here.\n\n>> Should we ask the user if he wants to fetch the bare submodule into the\n>> .git directory of the superproject or to ignore the clone setting while\n>> fetching?\n> \n> If we don't know what the user wants yet, yes.  Note that explicit command\n> line options \"git clone --recursive\" and $HOME/.gitconfig counts as the\n> user letting us know what s/he wants.\n\nLooks like we are in the same boat here. Only if either the always-recurse\nor on-demand mode for fetch is enabled - either by command line or by\nconfiguration - fetch should do that automatically. Otherwise it would do\nnothing (me not being so sure about the feasibility of asking the user).\n"}]}