{"thread":{"id":"6893","subject":"What's cooking in git.git (topics)","startedAt":"2007-02-20T07:42:57Z","lastAt":"2007-03-27T19:51:38Z","messageCount":28,"participants":["Junio C Hamano","Eric Wong","Alexander Litvinov","Johannes Schindelin","Marco Costalba","Linus Torvalds","Matthias Lederhofer","Julian Phillips","Santi Béjar","Florian Weimer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"35087","messageId":"7v7iudz33y.fsf@assigned-by-dhcp.cox.net","threadId":"6893","inReplyTo":null,"subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-20T07:42:57Z","receivedAt":"2007-02-20T07:42:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'.  The topics list the commits in reverse chronological\norder.\n\n* jc/apply-config (Tue Feb 20 03:45:49 2007 +0100) 5 commits\n - apply: fix memory leak in prefix_one()\n + git-apply: require -p<n> when working in a subdirectory.\n + git-apply: do not lose cwd when run from a subdirectory.\n + Teach 'git apply' to look at $HOME/.gitconfig even outside of a\n   repository\n + Teach 'git apply' to look at $GIT_DIR/config\n\n* lt/crlf (Sat Feb 17 12:37:25 2007 -0800) 4 commits\n + Teach core.autocrlf to 'git apply'\n + t0020: add test for auto-crlf\n + Make AutoCRLF ternary variable.\n + Lazy man's auto-CRLF\n\nThe above two series are to help MinGW and people who suffer\nfrom CRLF in general.  I think they are good enough for general\nconsumption now.  Will perhaps push them out sometime this week.\n\n* js/fetch-progress (Tue Feb 20 03:01:44 2007 +0100) 1 commit\n - fetch & clone: do not output progress when not on a tty\n* js/name-rev-fix (Tue Feb 20 01:08:48 2007 +0100) 1 commit\n + name-rev: avoid \"^0\" when unneeded\n* js/grep-pager (Mon Feb 19 15:56:04 2007 +0100) 1 commit\n - git grep: use pager\n* js/no-limit-boundary (Mon Feb 19 03:14:59 2007 +0100) 1 commit\n + rev-list --max-age, --max-count: support --boundary\n* fk/autoconf (Sun Feb 18 09:44:42 2007 +0100) 1 commit\n + New autoconf test for iconv\n* js/etc-config (Wed Feb 14 12:48:14 2007 +0100) 1 commit\n - config: read system-wide defaults from /etc/gitconfig\n* mw/64bit (Sat Feb 17 10:13:10 2007 +0100) 1 commit\n - Support for large files on 32bit systems.\n* sb/merge (Thu Feb 15 16:39:53 2007 +0100) 1 commit\n - t/t5515-fetch-merge-logic.sh: Added tests for the merge logic in\n   git-fetch\n\nThese should be Ok.  All should cook in 'next' and graduate to\n'master' by end of next week at the latest.\n\n* jc/fetch (Tue Feb 13 01:21:41 2007 +0000) 8 commits\n - Use stdin reflist passing in git-fetch.sh\n - Use stdin reflist passing in parse-remote\n - Allow fetch--tool to read from stdin\n - git-fetch: rewrite expand_ref_wildcard in C\n - git-fetch: rewrite another shell loop in C\n - git-fetch: move more code into C.\n - git-fetch--tool: start rewriting parts of git-fetch in C.\n - git-fetch: split fetch_main into fetch_dumb and fetch_native\n\nStalled.  If somebody wants to take this over I'll push this out\nto 'next'.\n\n* js/diff-2 (Sun Feb 18 12:44:43 2007 +0100) 1 commit\n - Add `git diff2`, a GNU diff workalike\n\nUndecided.  Perhaps will merge to 'next' to see if somebody else\ncomes up with a better naming idea.\n\n* jc/merge-subtree (Thu Feb 15 16:32:45 2007 -0800) 1 commit\n - A new merge stragety 'subtree'.\n\nSeems to work very well, but I do not see great urgency to merge\nthis to 'next' yet.\n\n* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits\n - test-para: combined diff between HEAD, index and working tree.\n - para-walk: walk n trees, index and working tree in parallel\n\nStalled.\n\n* js/objhash (Sat Feb 17 18:38:50 2007 +0100) 2 commits\n . Add `struct object_hash` (fixup)\n . Add `struct object_hash`\n\nStalled.\n"},{"id":"35089","messageId":"20070220082020.GA27084@localdomain","threadId":"6893","inReplyTo":"7v7iudz33y.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-02-20T08:20:20Z","receivedAt":"2007-02-20T08:20:20Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> * js/diff-2 (Sun Feb 18 12:44:43 2007 +0100) 1 commit\n>  - Add `git diff2`, a GNU diff workalike\n> \n> Undecided.  Perhaps will merge to 'next' to see if somebody else\n> comes up with a better naming idea.\n\nWith this, we can get rid of any test dependency on an external diff\nand have a consistent replacement for cmp[1], as well.\n\n`git gdiff`?  `git xdiff`?  `gdiff` would be easier on the fingers\n(assuming querty), but `xdiff` is probably a more accurate name.\n\n[1] - <200702172225.12758.johannes.sixt@telecom.at>\n-- \nEric Wong\n"},{"id":"35090","messageId":"200702201430.54852.litvinov2004@gmail.com","threadId":"6893","inReplyTo":"7v7iudz33y.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Alexander Litvinov","fromEmail":"litvinov2004@gmail.com","sentAt":"2007-02-20T08:30:54Z","receivedAt":"2007-02-20T08:30:54Z","isPatch":false,"sender":{"key":"litvinov2004@gmail.com","avatar":null},"body":"В сообщении от Tuesday 20 February 2007 13:42 Junio C Hamano написал:\n>\n> * lt/crlf (Sat Feb 17 12:37:25 2007 -0800) 4 commits\n>  + Teach core.autocrlf to 'git apply'\n>  + t0020: add test for auto-crlf\n>  + Make AutoCRLF ternary variable.\n>  + Lazy man's auto-CRLF\n>\n> The above two series are to help MinGW and people who suffer\n> from CRLF in general.  I think they are good enough for general\n> consumption now.  Will perhaps push them out sometime this week.\n\nI use the auto crlf convertion as far as Linus made it. Under cygwin it works \nand I have not seen any problems except converting repo from \\r\\n to \\n \nstyle. Convertion produce a lot of confilcts then merge branches.\n\nAll other sides of git I am using works well.\n"},{"id":"35091","messageId":"7v1wklz0p7.fsf@assigned-by-dhcp.cox.net","threadId":"6893","inReplyTo":"20070220082020.GA27084@localdomain","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-20T08:35:00Z","receivedAt":"2007-02-20T08:35:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Wong <normalperson@yhbt.net> writes:\n\n> Junio C Hamano <junkio@cox.net> wrote:\n>> * js/diff-2 (Sun Feb 18 12:44:43 2007 +0100) 1 commit\n>>  - Add `git diff2`, a GNU diff workalike\n>> \n>> Undecided.  Perhaps will merge to 'next' to see if somebody else\n>> comes up with a better naming idea.\n>\n> With this, we can get rid of any test dependency on an external diff\n> and have a consistent replacement for cmp[1], as well.\n>\n> `git gdiff`?  `git xdiff`?  `gdiff` would be easier on the fingers\n> (assuming querty), but `xdiff` is probably a more accurate name.\n\nWell, my trouble was that it is anything other than \"diff\".\n\nAn obvious alternative is the same command name (at least\nsuperficially) with an option, such as \"diff --fs\".  I am not\nsure if that is any better than \"git {something}diff\", though.\n"},{"id":"35311","messageId":"7v8xep8dfk.fsf@assigned-by-dhcp.cox.net","threadId":"6893","inReplyTo":"7v7iudz33y.fsf@assigned-by-dhcp.cox.net","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-23T08:51:11Z","receivedAt":"2007-02-23T08:51: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\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'.  The topics list the commits in reverse chronological\norder.\n\n* js/bundle (Fri Feb 23 03:17:51 2007 +0100) 5 commits\n + git-bundle: record commit summary in the prerequisite data\n + git-bundle: fix 'create --all'\n + git-bundle: avoid fork() in verify_bundle()\n + git-bundle: assorted fixes\n + Add git-bundle: move objects and references by archive\n\nJohannes muttered something about leak in \"create --all\" but I\ndo not think there is any --- they are pointing at memory\nlocation in refs.c:cached_refs.{loose,packed}.  I haven't\nchecked if the prerequisite logic is done correctly yet -- I\ntrust that the list can verify it for me before I get around to\nit myself.\n\n* js/no-limit-boundary (Mon Feb 19 03:14:59 2007 +0100) 1 commit\n + rev-list --max-age, --max-count: support --boundary\n\nThis should graduate to 'master' soon.\n\n* js/etc-config (Thu Feb 15 11:43:56 2007 +0100) 2 commits\n + Make tests independent of global config files\n + config: read system-wide defaults from /etc/gitconfig\n\nI think this is Ok, I do not have a real need for this myself\nbut it was done in response to a specific user request, so I can\nbe easily persuaded to make this graduate to 'master' by a\ngentle reminder with a success report.\n\n* js/commit-format (Fri Feb 23 01:35:03 2007 +0100) 1 commit\n - pretty-formats: add 'format:<string>'\n\nCute, but probably can be cleaned up.\n\n* js/diff-ni (Thu Feb 22 21:50:10 2007 +0100) 1 commit\n - Teach git-diff-files the new option `--no-index`\n\nWith a minor code restructure I think it got much nicer.\n\n* js/apply (Thu Feb 22 20:11:21 2007 +0100) 1 commit\n + apply: make --verbose a little more useful\n\nNice touch.  I think this is ready and I'll merge after I have a\nchance or two to exercise it myself in real-life.\n\n* jc/status (Thu Feb 22 02:07:56 2007 -0800) 5 commits\n - git-status: use in-core --refresh in a read-only repository.\n - git-runstatus --refresh\n + run_diff_{files,index}(): update calling convention.\n + update-index: do not die too early in a read-only repository.\n + git-status: do not be totally useless in a read-only repository.\n\nThe first (meaning bottom in the list) two are true improvement\nfor obscure corner case, the third is a code cleanup to make\nfuture enhancements (and the later ones in the series) easier.\nI have not decided if it is worth to have the remaining two, so\nthey are left in 'pu'.\n\n* js/fetch-progress (Tue Feb 20 03:01:44 2007 +0100) 1 commit\n + fetch & clone: do not output progress when not on a tty\n\nI'll see it in action from my cron job.\n\n* jc/fetch (Tue Feb 13 01:21:41 2007 +0000) 8 commits\n - Use stdin reflist passing in git-fetch.sh\n - Use stdin reflist passing in parse-remote\n - Allow fetch--tool to read from stdin\n - git-fetch: rewrite expand_ref_wildcard in C\n - git-fetch: rewrite another shell loop in C\n - git-fetch: move more code into C.\n - git-fetch--tool: start rewriting parts of git-fetch in C.\n - git-fetch: split fetch_main into fetch_dumb and fetch_native\n\nWorks, does not break anything, very ugly.  Probably needs\nreworking if we were to have this in 'next'.\n\n* sb/merge (Thu Feb 15 16:39:53 2007 +0100) 1 commit\n - t/t5515-fetch-merge-logic.sh: Added tests for the merge logic in\n   git-fetch\n\n* jc/merge-subtree (Thu Feb 15 16:32:45 2007 -0800) 1 commit\n - A new merge stragety 'subtree'.\n\nI agree with Shawn that its tree-shifting logic should be based\non something similar to tree-diff rename detection before moving\nit into 'next'.\n\n* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits\n - test-para: combined diff between HEAD, index and working tree.\n - para-walk: walk n trees, index and working tree in parallel\n\nStalled.\n"},{"id":"35323","messageId":"Pine.LNX.4.63.0702231258400.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6893","inReplyTo":"7v8xep8dfk.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-23T14:48:33Z","receivedAt":"2007-02-23T14:48:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 23 Feb 2007, Junio C Hamano wrote:\n\n> * js/fetch-progress (Tue Feb 20 03:01:44 2007 +0100) 1 commit\n>  + fetch & clone: do not output progress when not on a tty\n> \n> I'll see it in action from my cron job.\n\nThat's how I tried to test it. It does not work. The problem is that the \nremote git-upload-pack is unlikely to understand the option \n\"--no-progress\".\n\nSo maybe we have to make this a new pack protocol option?\n\nCiao,\nDscho\n"},{"id":"35338","messageId":"7virds4uad.fsf@assigned-by-dhcp.cox.net","threadId":"6893","inReplyTo":"Pine.LNX.4.63.0702231258400.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-23T18:12:58Z","receivedAt":"2007-02-23T18:12:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> On Fri, 23 Feb 2007, Junio C Hamano wrote:\n>\n>> * js/fetch-progress (Tue Feb 20 03:01:44 2007 +0100) 1 commit\n>>  + fetch & clone: do not output progress when not on a tty\n>> \n>> I'll see it in action from my cron job.\n>\n> That's how I tried to test it. It does not work. The problem is that the \n> remote git-upload-pack is unlikely to understand the option \n> \"--no-progress\".\n>\n> So maybe we have to make this a new pack protocol option?\n\nYes.\n"},{"id":"36233","messageId":"7v7itx5mep.fsf@assigned-by-dhcp.cox.net","threadId":"6893","inReplyTo":"7v8xep8dfk.fsf@assigned-by-dhcp.cox.net","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-04T10:32:46Z","receivedAt":"2007-03-04T10:32:46Z","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\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'.  The topics list the commits in reverse chronological\norder.\n\n* js/attach (Sun Mar 4 00:12:06 2007 +0100) 1 commit\n - format-patch: add --inline option and make --attach a true\n   attachment\n\nWith this, --attach makes a mixed/multipart message with\n\"content-disposition: attachment\"; the previous behaviour to\nemit \"content-disposition: inline\" is available with the new\noption --inline.  It is an improvement in the sense that it\nmakes the option name and behaviour match each other, but it\nchanges the behaviour, so some people may not like it.  I think\nI'll merge to 'next' anyway, if only to see if anybody screams.\n\n* js/symlink (Sat Mar 3 20:38:00 2007 +0100) 3 commits\n + Tell multi-parent diff about core.symlinks.\n + Handle core.symlinks=false case in merge-recursive.\n + Add core.symlinks to mark filesystems that do not support symbolic\n   links.\n\nThis is to help the MinGW port; I think this topic is ready to\ngraduate to 'master'.\n\n* js/config-rename (Fri Mar 2 21:53:33 2007 +0100) 1 commit\n + git-config: document --rename-section, provide --remove-section\n\nThis would help clean-up after removing branches and remotes.\n\n* js/gnucl (Fri Mar 2 15:29:08 2007 +0100) 2 commits\n - --pretty=gnucl: avoid line wrapping before the comma\n - Add --pretty=gnucl\n\nThis is to output logs in the GNU ChangeLog format.\n\n* jc/pathattr (Thu Mar 1 01:20:21 2007 -0800) 5 commits\n - pathattr: allow piping to external program.\n - pathattr: read from git_config().\n - git-show: use pathattr to run \"display\"\n - pathattr: path based configuration of various attributes.\n + convert: add scaffolding for path based selection of conversion\n   routines.\n\nThis is a continuation of the CRLF munging topic that is already\nin the 'master' branch, but I am expecting to have to redo\nalmost all of them.  This is left in 'pu' just as a reference.\n\n* js/revert-cherry (Thu Mar 1 05:26:30 2007 +0100) 1 commit\n + Make git-revert & git-cherry-pick a builtin\n\nWill cook for some time.\n\n* jc/fetch (Wed Feb 28 17:02:18 2007 -0800) 14 commits\n + builtin-fetch--tool: fix reflog notes.\n + git-fetch: retire update-local-ref which is not used anymore.\n + builtin-fetch--tool: make sure not to overstep ls-remote-result\n   buffer.\n + fetch--tool: fix uninitialized buffer when reading from stdin\n + builtin-fetch--tool: adjust to updated sha1_object_info().\n + git-fetch--tool takes flags before the subcommand.\n + Use stdin reflist passing in git-fetch.sh\n + Use stdin reflist passing in parse-remote\n + Allow fetch--tool to read from stdin\n + git-fetch: rewrite expand_ref_wildcard in C\n + git-fetch: rewrite another shell loop in C\n + git-fetch: move more code into C.\n + git-fetch--tool: start rewriting parts of git-fetch in C.\n + git-fetch: split fetch_main into fetch_dumb and fetch_native\n\nBeginning of built-in git-fetch, primarily to speed up fetching\nbetween repositories with insane number of refs.\n\n* jb/per-user-exclude (Tue Feb 27 22:31:10 2007 -0500) 1 commit\n - add: Support specifying an excludes file with a configuration\n   variable\n\nI was hoping that the attribute system would make this\nunnecessary (you assign 'ignored' attribute to paths, instead of\nspelling them out in the additional .gitignore), but that is a\nbit in the future.\n\n* js/diff-ni (Sun Feb 25 23:36:53 2007 +0100) 4 commits\n + Get rid of the dependency to GNU diff in the tests\n + diff --no-index: support /dev/null as filename\n + diff-ni: fix the diff with standard input\n + diff: support reading a file from stdin via \"-\"\n\nI've fixed up this series since it was posted, and I think it is\nin a testable shape now, so it is in 'next'.\n\n* js/fetch-progress (Sun Feb 25 13:13:17 2007 -0800) 3 commits\n . git-fetch: add --quiet\n + Fixup no-progress for fetch & clone\n + fetch & clone: do not output progress when not on a tty\n\nThe early parts that have been in 'next' should be ready to go\nto 'master' now.  The last one I am not sure.\n\n* jc/status (Thu Feb 22 02:07:56 2007 -0800) 2 commits\n - git-status: use in-core --refresh in a read-only repository.\n - git-runstatus --refresh\n\nThese two were done for the specific purpose of helping qgit,\nbut I haven't heard about them, so they are on hold.  If they\nare not needed by qgit nor people who like to run git-status in\na read-only repository, I do not see any reason to keep them.\n\n* jc/merge-subtree (Thu Feb 15 16:32:45 2007 -0800) 1 commit\n - A new merge stragety 'subtree'.\n\nThis is still my useful toy at this stage.  I agree with Shawn\nthat subtree identification needs to be improved.\n\n* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits\n - test-para: combined diff between HEAD, index and working tree.\n - para-walk: walk n trees, index and working tree in parallel\n\nThis is just a reference, waiting for a day somebody has enough\nenergy to rewrite diff family with a unified tree walker.\n"},{"id":"36235","messageId":"Pine.LNX.4.63.0703041321290.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6893","inReplyTo":"7v7itx5mep.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-04T12:32:21Z","receivedAt":"2007-03-04T12:32:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 4 Mar 2007, Junio C Hamano wrote:\n\n> * js/attach (Sun Mar 4 00:12:06 2007 +0100) 1 commit\n>\n> [...]\n>\n> * js/symlink (Sat Mar 3 20:38:00 2007 +0100) 3 commits\n\nThe prefix system is showing its limitation... :-)\n\n> * js/gnucl (Fri Mar 2 15:29:08 2007 +0100) 2 commits\n>  - --pretty=gnucl: avoid line wrapping before the comma\n>  - Add --pretty=gnucl\n> \n> This is to output logs in the GNU ChangeLog format.\n\nFWIW I am opposed to include that. After letting it sink in, Linus' \nremarks convinced me that this format is not as useful as our other log \nformats, and for those people who really want it, there is git2cl.\n\n> * js/revert-cherry (Thu Mar 1 05:26:30 2007 +0100) 1 commit\n>  + Make git-revert & git-cherry-pick a builtin\n> \n> Will cook for some time.\n\nYes. I worked with them a bit, but nowhere enough to say that they are \nnot introducing regressions.\n\n> * js/diff-ni (Sun Feb 25 23:36:53 2007 +0100) 4 commits\n>  + Get rid of the dependency to GNU diff in the tests\n>  + diff --no-index: support /dev/null as filename\n>  + diff-ni: fix the diff with standard input\n>  + diff: support reading a file from stdin via \"-\"\n> \n> I've fixed up this series since it was posted, and I think it is\n> in a testable shape now, so it is in 'next'.\n\nThank you.\n\n> * js/fetch-progress (Sun Feb 25 13:13:17 2007 -0800) 3 commits\n>  . git-fetch: add --quiet\n>  + Fixup no-progress for fetch & clone\n>  + fetch & clone: do not output progress when not on a tty\n> \n> The early parts that have been in 'next' should be ready to go to \n> 'master' now.  The last one I am not sure.\n\nBTW I just added this to my fetches in crontab: ' | sed -e \"s/^.*\\r//g\"' \nThis is the workaround Nico proposed, only a little bit more obvious (and \nremovable).\n\nCiao,\nDscho\n"},{"id":"36236","messageId":"e5bfff550703040440q45b58e63pb24f17e4a1b10e31@mail.gmail.com","threadId":"6893","inReplyTo":"7v7itx5mep.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-03-04T12:40:57Z","receivedAt":"2007-03-04T12:40:57Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 3/4/07, Junio C Hamano <junkio@cox.net> wrote:\n>\n> * jc/status (Thu Feb 22 02:07:56 2007 -0800) 2 commits\n>  - git-status: use in-core --refresh in a read-only repository.\n>  - git-runstatus --refresh\n>\n> These two were done for the specific purpose of helping qgit,\n> but I haven't heard about them, so they are on hold.  If they\n> are not needed by qgit nor people who like to run git-status in\n> a read-only repository, I do not see any reason to keep them.\n>\n\nCurrently they are not needed by qgit. Probably neither in the future.\nIt is better to keep working dir view disabled if in a read-only repo\nthen wait for a sloooow command to return incorrect data (BTW _all_\nrepo files are always marked as 'modified' due to an issue with\ndifferent implementations of lstat in cygwin and ntfs kernel driver).\n"},{"id":"36264","messageId":"Pine.LNX.4.64.0703041401030.3953@woody.linux-foundation.org","threadId":"6893","inReplyTo":"Pine.LNX.4.63.0703041321290.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: What's cooking in git.git (topics)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-03-04T22:26:05Z","receivedAt":"2007-03-04T22:26:05Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 4 Mar 2007, Johannes Schindelin wrote:\n> > \n> > This is to output logs in the GNU ChangeLog format.\n> \n> FWIW I am opposed to include that. After letting it sink in, Linus' \n> remarks convinced me that this format is not as useful as our other log \n> formats, and for those people who really want it, there is git2cl.\n\nSide note: I would hate to be the person who torpedoes anything that some \npeople actually find useful (my motto: \"actually useful is a lot better \nthan clean, but not as useful\")\n\nSo in that sense, if people actually find GNU changelog format to be \nuseful enough that they want a script for it, I don't think we should \nrelegate it to second-class citizenship just because _we_ don't think it's \na wonderful format.\n\nThe GNU code formatting guidelines are much much worse than the GNU \nchangelogs, yet we certainly allow people to check in their braindamage \ninto git if they want to. The GNU changelog format isn't horrid, and the \nfunction names can be even nice as a way of seeing \"what does this touch\".\n\nThe fact that GNU changelog is then mis-designed to do per-file changelogs \netc is more an effect of CVS misfeatures than anything else. But compared \nto all the other things CVS gets wrong, that's a very small detail ;)\n\n\t\tLinus\n"},{"id":"36266","messageId":"7vd53o4ngg.fsf@assigned-by-dhcp.cox.net","threadId":"6893","inReplyTo":"Pine.LNX.4.64.0703041401030.3953@woody.linux-foundation.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-04T23:07:43Z","receivedAt":"2007-03-04T23:07:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> On Sun, 4 Mar 2007, Johannes Schindelin wrote:\n>> > \n>> > This is to output logs in the GNU ChangeLog format.\n>> \n>> FWIW I am opposed to include that. After letting it sink in, Linus' \n>> remarks convinced me that this format is not as useful as our other log \n>> formats, and for those people who really want it, there is git2cl.\n>\n> Side note: I would hate to be the person who torpedoes anything that some \n> people actually find useful (my motto: \"actually useful is a lot better \n> than clean, but not as useful\")\n>\n> So in that sense, if people actually find GNU changelog format to be \n> useful enough that they want a script for it, I don't think we should \n> relegate it to second-class citizenship just because _we_ don't think it's \n> a wonderful format.\n\nOh, I certainly would not disagree.\n\nBut I do not think encouraging people to script is necessarily\nrelegating it to second-class citizenship, as it appears there\nare rooms for project and language specific heuristics to come\nin for summarizing the real log into a variant of GNU changelog\nthat is most useful for a particular project, I think it makes\nsense to implement it as a postprocessing filter to git-log -p\n(even \"git-log -p -U999\", if somebody want to do a language\nspecific function labels), just like Simon did with his git2cl\nto output a particular variant (i.e. the one that lacks the\nfunction names) of GNU changelog to suit his projects' needs.\n\nGiven time, Simon's script may be improved and prove to be\nflexible enough to accomodate the needs of all (or almost all)\nother projects that want to use GNU changelog format.  At that\npoint, we might even want to include it in contrib/ of git.git,\nif enough people are interested in it and if distributing with\nthe core helps the script gain wider exposure.\n\n> The fact that GNU changelog is then mis-designed to do per-file changelogs \n> etc is more an effect of CVS misfeatures than anything else. But compared \n> to all the other things CVS gets wrong, that's a very small detail ;)\n\nThat part I 100% agree ;-).\n"},{"id":"36987","messageId":"7vps7dle8j.fsf@assigned-by-dhcp.cox.net","threadId":"6893","inReplyTo":"7v7itx5mep.fsf@assigned-by-dhcp.cox.net","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-13T08:49:48Z","receivedAt":"2007-03-13T08:49:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'.  The topics list the commits in reverse chronological\norder.\n\n\n* sp/run-command (Mon Mar 12 19:00:29 2007 -0400) 9 commits\n + Use run_command within send-pack\n + Use run_command within receive-pack to invoke index-pack\n + Use run_command within merge-index\n + Use run_command for proxy connections\n + Use RUN_GIT_CMD to run push backends\n + Correct new compiler warnings in builtin-revert\n + Replace fork_with_pipe in bundle with run_command\n + Teach run-command to redirect stdout to /dev/null\n + Teach run-command about stdout redirection\n\nThis is really internal clean-up without behaviour change (but I\nsuspect the error messages from failure cases might be\ndifferent).  Good to flush these to 'master' before 1.5.1-rc1.\n\n* dz/mailinfo (Mon Mar 12 15:52:07 2007 -0400) 3 commits\n + Add a couple more test cases to the suite.\n + restrict the patch filtering\n + builtin-mailinfo.c infrastrcture changes\n\nThe mailinfo implementation in 'master' I punted to do\ncomplicated multi-part and Don Zickus rewrote much of the hacky\nparts.  The less hacky code of mine remains in the tree, the\nhappier I am.  Should be in 'master' before 1.5.1-rc1.\n\n* jc/repack (Fri Mar 9 03:52:12 2007 -0800) 1 commit\n + prepare_packed_git(): sort packs by age and localness.\n\nThis is to improve the access pattern when repository has many\nsmall packfiles, as recent push/fetch tend to keep packs\nunexploded.  The idea is to check younger packs and local packs\nbefore others when we iterate over .idx files to look for packed\nobjects from find_pack_entry().  I've repacked linux-2.6 kernel\nrepository so that it has one pack per one public tag (which is\na bit excessive -- it results in 70 or so small packs), and saw\n\"git log -r --raw v2.6.20..\" got some speed-up in hot cache case\n(4.4 seconds vs 5.3 seconds on average).\n\n* jc/fetch (Sun Mar 4 15:36:08 2007 -0800) 15 commits\n + .gitignore: add git-fetch--tool\n + builtin-fetch--tool: fix reflog notes.\n + git-fetch: retire update-local-ref which is not used anymore.\n + builtin-fetch--tool: make sure not to overstep ls-remote-result\n   buffer.\n + fetch--tool: fix uninitialized buffer when reading from stdin\n + builtin-fetch--tool: adjust to updated sha1_object_info().\n + git-fetch--tool takes flags before the subcommand.\n + Use stdin reflist passing in git-fetch.sh\n + Use stdin reflist passing in parse-remote\n + Allow fetch--tool to read from stdin\n + git-fetch: rewrite expand_ref_wildcard in C\n + git-fetch: rewrite another shell loop in C\n + git-fetch: move more code into C.\n + git-fetch--tool: start rewriting parts of git-fetch in C.\n + git-fetch: split fetch_main into fetch_dumb and fetch_native\n\nThis is a partial C rewrite of heaviest part of git-fetch to\nhelp fetching between repositories with hundreds of refs.  I do\nnot like the way it is split, but it may be a good idea to throw\nit in 'master' as it does not seem to regress anything and see\nif there are other interested people who want to finish the\nrewriting.\n\n* pb/branch-track (Thu Mar 8 13:59:54 2007 -0800) 2 commits\n + Fix broken create_branch() in builtin-branch.\n + git-branch, git-checkout: autosetup for remote branch tracking\n\nAs I personally do not use \"git branch --track\", all I can say\nis that this, with the fix-up patch already in, does not seem to\nregress anything.  Positive feedbacks requested before advancing\nto 'master'.\n\n* jb/per-user-exclude (Tue Feb 27 22:31:10 2007 -0500) 1 commit\n + add: Support specifying an excludes file with a configuration\n   variable\n\nSame as above.\n\n* ml/workdir (Sun Mar 11 22:29:06 2007 +0100) 3 commits\n - use $GIT_DIR/workdir as working directory with $GIT_DIR\n - introduce GIT_WORK_DIR environment variable\n - rev-parse: --is-bare-repository option\n\nNot in 'next' yet, but I think this one is ready to be tested.\nWe need testsuite for it before that happens, though.\n\n* js/fetch-progress (Sun Feb 25 13:13:17 2007 -0800) 1 commit\n + git-fetch: add --quiet\n\nThis does not break anything, but I am not sure how useful it\nwould be.\n\n* sb/fetch (Mon Mar 12 19:01:11 2007 -0700) 19 commits\n + git-fetch.sh:append_fetch_head() no longer has a remote_nick\n   argument\n + git-fetch: Split fetch and merge logic\n\nI have a soft spot to anything that claims to be a clean-up, but\nI suspect that the shell loop this series introduces may defeat\nthe git-fetch--tool optimization.  Also I think having to base\nthe patch on this made Paolo's \"dot is special token to mean\n'git pull' merges from a local branch\" needlessly complex (but I\nhaven't tried rewriting it myself without these two).  Although\nI merged these to 'next', I am considering to revert them.\n\n* jc/pathattr (Thu Mar 1 01:20:21 2007 -0800) 5 commits\n - pathattr: allow piping to external program.\n - pathattr: read from git_config().\n - git-show: use pathattr to run \"display\"\n - pathattr: path based configuration of various attributes.\n + convert: add scaffolding for path based selection of conversion\n   routines.\n\nStalled.\n\n* jc/merge-subtree (Thu Feb 15 16:32:45 2007 -0800) 1 commit\n - A new merge stragety 'subtree'.\n\nStalled.\n\n* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits\n - test-para: combined diff between HEAD, index and working tree.\n - para-walk: walk n trees, index and working tree in parallel\n\nJust a reference code.\n"},{"id":"37019","messageId":"20070313174304.GA2540@moooo.ath.cx","threadId":"6893","inReplyTo":"7vps7dle8j.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2007-03-13T17:43:04Z","receivedAt":"2007-03-13T17:43:04Z","isPatch":false,"sender":{"key":"matled@gmx.net","avatar":null},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> * ml/workdir (Sun Mar 11 22:29:06 2007 +0100) 3 commits\n>  - use $GIT_DIR/workdir as working directory with $GIT_DIR\n>  - introduce GIT_WORK_DIR environment variable\n>  - rev-parse: --is-bare-repository option\n> \n> Not in 'next' yet, but I think this one is ready to be tested.\n> We need testsuite for it before that happens, though.\n\nWill you apply the git-init patch too?\n\nI did not write any tests yet, but I can try.\n\nHere is what I thought about:\n\ncheck that --work-dir overrides $GIT_WORK_DIR and both override\n$GIT_DIR/workdir.\n\nuse a correct and an invalid path for:\n    $GIT_DIR/workdir:\n        file containing a relative and an absolute path\n        symlink pointing to an invalid path, a directory, a file\n        test a symlink to something else (e.g. device, fifo, ..) too?\n        directory\n    $GIT_WORK_DIR: relative and absolute path\n    and test what git does with git-rev-parse\n            --is-bare-repository\n            --show-prefix\n            --show-cdup\n\ntest git rev-parse --is-inside-git-dir\n\nA symlink pointing to an invalid path is currently handled as if there\nis no $GIT_DIR/workdir at all because stat returns ENOENT.  Is this ok\nor should git complain like it does for an invalid path when\n$GIT_DIR/workdir is a file?  We could also decide to ignore all\ninvalid workdir settings and handle this the same as being outside the\nworkdir.\n"},{"id":"37022","messageId":"Pine.LNX.4.64.0703131837280.18274@reaper.quantumfyre.co.uk","threadId":"6893","inReplyTo":"7vps7dle8j.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-03-13T18:49:18Z","receivedAt":"2007-03-13T18:49:18Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Tue, 13 Mar 2007, Junio C Hamano wrote:\n\n> * jc/fetch (Sun Mar 4 15:36:08 2007 -0800) 15 commits\n> + .gitignore: add git-fetch--tool\n> + builtin-fetch--tool: fix reflog notes.\n> + git-fetch: retire update-local-ref which is not used anymore.\n> + builtin-fetch--tool: make sure not to overstep ls-remote-result\n>   buffer.\n> + fetch--tool: fix uninitialized buffer when reading from stdin\n> + builtin-fetch--tool: adjust to updated sha1_object_info().\n> + git-fetch--tool takes flags before the subcommand.\n> + Use stdin reflist passing in git-fetch.sh\n> + Use stdin reflist passing in parse-remote\n> + Allow fetch--tool to read from stdin\n> + git-fetch: rewrite expand_ref_wildcard in C\n> + git-fetch: rewrite another shell loop in C\n> + git-fetch: move more code into C.\n> + git-fetch--tool: start rewriting parts of git-fetch in C.\n> + git-fetch: split fetch_main into fetch_dumb and fetch_native\n>\n> This is a partial C rewrite of heaviest part of git-fetch to\n> help fetching between repositories with hundreds of refs.  I do\n> not like the way it is split, but it may be a good idea to throw\n> it in 'master' as it does not seem to regress anything and see\n> if there are other interested people who want to finish the\n> rewriting.\n\nAs it happens I was planning to start looking at writing a builtin fetch \nwhen I got home this evening ... the fetch--tool improvements have whetted \nmy appetite for speed ... ;)\n\n> * sb/fetch (Mon Mar 12 19:01:11 2007 -0700) 19 commits\n> + git-fetch.sh:append_fetch_head() no longer has a remote_nick\n>   argument\n> + git-fetch: Split fetch and merge logic\n>\n> I have a soft spot to anything that claims to be a clean-up, but\n> I suspect that the shell loop this series introduces may defeat\n> the git-fetch--tool optimization.  Also I think having to base\n> the patch on this made Paolo's \"dot is special token to mean\n> 'git pull' merges from a local branch\" needlessly complex (but I\n> haven't tried rewriting it myself without these two).  Although\n> I merged these to 'next', I am considering to revert them.\n\nI found that this series did introduce a regression, but not a serious \none.  A null fetch went from ~30s to ~40s IIRC.  I moved \ncanon_refs_list_for_fetch from git-parse-remote.sh to git-fetch--tool in \nresponse, and was pretty much able to get back to where I was before - I \ncan send the patch if you want, I didn't think it that important.\n\n-- \nJulian\n\n  ---\nThe new Congressmen say they're going to turn the government around.  I\nhope I don't get run over again.\n"},{"id":"37024","messageId":"7vhcsphqtk.fsf@assigned-by-dhcp.cox.net","threadId":"6893","inReplyTo":"7vps7dle8j.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-13T19:43:51Z","receivedAt":"2007-03-13T19:43:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> Here are the topics that have been cooking.\n\n> * sb/fetch (Mon Mar 12 19:01:11 2007 -0700) 19 commits\n>  + git-fetch.sh:append_fetch_head() no longer has a remote_nick\n>    argument\n>  + git-fetch: Split fetch and merge logic\n>\n> I have a soft spot to anything that claims to be a clean-up, but\n> I suspect that the shell loop this series introduces may defeat\n> the git-fetch--tool optimization.  Also I think having to base\n> the patch on this made Paolo's \"dot is special token to mean\n> 'git pull' merges from a local branch\" needlessly complex (but I\n> haven't tried rewriting it myself without these two).  Although\n> I merged these to 'next', I am considering to revert them.\n\nI tried the \"NULL fetch between 1000-refs repositories\" test,\nwhich prompted the git-fetch--tool work that was done on\njc/fetch topic in 'next', with the following versions:\n\n (1) 1.5.0 (without any git-fetch--tool optimization)\n (2) master (ditto)\n (3) master with jc/fetch (but not sb/fetch topic)\n (4) next ((3) plus sb/fetch and others)\n\nThe test scripts are at the end of this message.  Both (1) and\n(2) take 3 minutes 7 seconds wallclock time.  (3) improves it\ndown to 15 seconds.  (4) makes the operation spend 24 seconds\n(the times are all on my primary machine x86-64 with 1GB, hot\ncache and average of three runs each).\n\nSo the \"Split fetch and merge\" series hurts the performance\nquite a bit.  If it had enough \"code clean-up\" merit to warrant\nthis, I would say it probably is a cost we should bear, but I\npersonally do not see it.\n\nPaolo recently worked on top of next to base the fake '.' remote\npatch.  This wants to allow:\n\n\t[branch \"foo\"]\n        \tremote = .\n                merge = refs/heads/master\n\nwith an implicit (meaning, you do not have to have this in your\nconfiguration):\n\n\t[remote \".\"]\n        \turl = .\n                fetch = refs/*\n\nso that you can say:\n\n\t$ git checkout foo\n        $ git pull\n\nto merge from the local 'master' branch.\n\nI haven't reimplemented Paolo's patch on top of (3) above for\ncomparison, but I have a feeling that it would not have been\nhelped by the alleged clean-up value of \"Split fetch and merge\"\npatch (iow, I do not think it would be the case that the code\ngot clearer to understand thanks to the clean-up).\n\nWhat Paolo's patch needs to do is to bypass the actual fetch and\ngenerate the following line in .git/FETCH_HEAD:\n\n\tsha1-of-our-master <TAB> <TAB> branch 'master' of .\n\nI even suspect that \"Split fetch and merge\", by introducing\nFETCH_FETCHED and making FETCH_HEAD generated from it, made\nPaolo's patch more difficult to do and the end result less\nefficient.\n\nSo unless there is a convincing counterexample otherwise, I'd\nlike to revert the \"Split fetch and merge\" series.\n\n\n-- >8 -- setting up test repositories -- >8 --\n#!/bin/sh\n\nrm -fr origin clone\n\nmkdir origin\ncd origin\ngit init\n: >hello\ngit add hello\ngit commit -a -m 'initial'\ni=0\nwhile test $i -lt 500\ndo\n\tgit tag t$i\n\tgit branch b$i\n\ti=$(($i+1))\ndone\n\n: >bye\ngit add bye\ngit commit -a -m 'second'\nwhile test $i -lt 1000\ndo\n\tgit tag t$i\n\tgit branch b$i\n\ti=$(($i+1))\ndone\n\ncd ..\n-- >8 -- NULL fetch test -- >8 --\n#!/bin/sh\n\ncd clone\necho '* fetching'\ntime git fetch origin\n"},{"id":"37025","messageId":"7vd53cj55n.fsf@assigned-by-dhcp.cox.net","threadId":"6893","inReplyTo":"20070313174304.GA2540@moooo.ath.cx","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-13T19:48:52Z","receivedAt":"2007-03-13T19:48:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthias Lederhofer <matled@gmx.net> writes:\n\n> Here is what I thought about:\n>\n> check that --work-dir overrides $GIT_WORK_DIR and both override\n> $GIT_DIR/workdir.\n>\n> use a correct and an invalid path for:\n>     $GIT_DIR/workdir:\n>         file containing a relative and an absolute path\n>         symlink pointing to an invalid path, a directory, a file\n>         test a symlink to something else (e.g. device, fifo, ..) too?\n>         directory\n>     $GIT_WORK_DIR: relative and absolute path\n>     and test what git does with git-rev-parse\n>             --is-bare-repository\n>             --show-prefix\n>             --show-cdup\n>\n> test git rev-parse --is-inside-git-dir\n\n... and do the rev-parse test with *and* *without* $GIT_WORK_DIR\nor $GIT_DIR/workdir to make sure there won't be any regressions.\n\n> A symlink pointing to an invalid path is currently handled as if there\n> is no $GIT_DIR/workdir at all because stat returns ENOENT.  Is this ok\n> or should git complain like it does for an invalid path when\n> $GIT_DIR/workdir is a file?  We could also decide to ignore all\n> invalid workdir settings and handle this the same as being outside the\n> workdir.\n\nSilently ignoring would leave the user who misconfigured it by\nmistake.\n\nBy the way, why should it be $GIT_DIR/workdir when it appears\neverybody is putting things in $GIT_DIR/config?  Shouldn't it be\nsomething like:\n\n\t[core]\n        \tworktree = \"/path/to/the/working/tree\"\n\nAnd more importantly, why nobody mentioned the above so far?\nMaybe it is a sign that nobody is interested in this new\nfeature?\n"},{"id":"37031","messageId":"20070313203054.GA6139@moooo.ath.cx","threadId":"6893","inReplyTo":"7vd53cj55n.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2007-03-13T20:30:54Z","receivedAt":"2007-03-13T20:30:54Z","isPatch":false,"sender":{"key":"matled@gmx.net","avatar":null},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> By the way, why should it be $GIT_DIR/workdir when it appears\n> everybody is putting things in $GIT_DIR/config?  Shouldn't it be\n> something like:\n> \n> \t[core]\n>         \tworktree = \"/path/to/the/working/tree\"\n\nThat's right.  When I wrote the code I first had only support for a\ndirectory in $GIT_DIR/workdir (using a symlink) and added a file after\nthat.  Using a symlink is still easily possible with core.worktree =\nworkdir.\n"},{"id":"37035","messageId":"8aa486160703131614i1b67e6c3vf7ccf395d63573b4@mail.gmail.com","threadId":"6893","inReplyTo":"7vhcsphqtk.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2007-03-13T23:14:50Z","receivedAt":"2007-03-13T23:14:50Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On 3/13/07, Junio C Hamano <junkio@cox.net> wrote:\n> Junio C Hamano <junkio@cox.net> writes:\n>\n> > Here are the topics that have been cooking.\n>\n> > * sb/fetch (Mon Mar 12 19:01:11 2007 -0700) 19 commits\n> >  + git-fetch.sh:append_fetch_head() no longer has a remote_nick\n> >    argument\n> >  + git-fetch: Split fetch and merge logic\n> >\n> > I have a soft spot to anything that claims to be a clean-up, but\n> > I suspect that the shell loop this series introduces may defeat\n> > the git-fetch--tool optimization.  Also I think having to base\n> > the patch on this made Paolo's \"dot is special token to mean\n> > 'git pull' merges from a local branch\" needlessly complex (but I\n> > haven't tried rewriting it myself without these two).  Although\n> > I merged these to 'next', I am considering to revert them.\n>\n> I tried the \"NULL fetch between 1000-refs repositories\" test,\n> which prompted the git-fetch--tool work that was done on\n> jc/fetch topic in 'next', with the following versions:\n>\n>  (1) 1.5.0 (without any git-fetch--tool optimization)\n>  (2) master (ditto)\n>  (3) master with jc/fetch (but not sb/fetch topic)\n>  (4) next ((3) plus sb/fetch and others)\n>\n> The test scripts are at the end of this message.  Both (1) and\n> (2) take 3 minutes 7 seconds wallclock time.  (3) improves it\n> down to 15 seconds.  (4) makes the operation spend 24 seconds\n> (the times are all on my primary machine x86-64 with 1GB, hot\n> cache and average of three runs each).\n\nI think it is not fair, I wonder what would be the time with the merge\nlogic in sb/fetch in C. I'll try to make the git-fetch--tool\noptimization.\n\n>\n> So the \"Split fetch and merge\" series hurts the performance\n> quite a bit.  If it had enough \"code clean-up\" merit to warrant\n> this, I would say it probably is a cost we should bear, but I\n> personally do not see it.\n>\n> Paolo recently worked on top of next to base the fake '.' remote\n> patch.  This wants to allow:\n>\n>         [branch \"foo\"]\n>                 remote = .\n>                 merge = refs/heads/master\n>\n> with an implicit (meaning, you do not have to have this in your\n> configuration):\n>\n>         [remote \".\"]\n>                 url = .\n>                 fetch = refs/*\n>\n> so that you can say:\n>\n>         $ git checkout foo\n>         $ git pull\n>\n> to merge from the local 'master' branch.\n>\n> I haven't reimplemented Paolo's patch on top of (3) above for\n> comparison, but I have a feeling that it would not have been\n> helped by the alleged clean-up value of \"Split fetch and merge\"\n> patch (iow, I do not think it would be the case that the code\n> got clearer to understand thanks to the clean-up).\n>\n> What Paolo's patch needs to do is to bypass the actual fetch and\n> generate the following line in .git/FETCH_HEAD:\n>\n>         sha1-of-our-master <TAB> <TAB> branch 'master' of .\n>\n> I even suspect that \"Split fetch and merge\", by introducing\n> FETCH_FETCHED and making FETCH_HEAD generated from it, made\n> Paolo's patch more difficult to do and the end result less\n> efficient.\n\nI think my patch to support this is independent of the \"Split fetch and merge\".\n\n>\n> So unless there is a convincing counterexample otherwise, I'd\n> like to revert the \"Split fetch and merge\" series.\n\nSanti\n"},{"id":"37078","messageId":"7vbqiwawva.fsf@assigned-by-dhcp.cox.net","threadId":"6893","inReplyTo":"8aa486160703131614i1b67e6c3vf7ccf395d63573b4@mail.gmail.com","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-14T11:27:21Z","receivedAt":"2007-03-14T11:27:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Santi Béjar\" <sbejar@gmail.com> writes:\n\n>> I tried the \"NULL fetch between 1000-refs repositories\" test,\n>> which prompted the git-fetch--tool work that was done on\n>> jc/fetch topic in 'next', with the following versions:\n>>\n>>  (1) 1.5.0 (without any git-fetch--tool optimization)\n>>  (2) master (ditto)\n>>  (3) master with jc/fetch (but not sb/fetch topic)\n>>  (4) next ((3) plus sb/fetch and others)\n>>\n>> The test scripts are at the end of this message.  Both (1) and\n>> (2) take 3 minutes 7 seconds wallclock time.  (3) improves it\n>> down to 15 seconds.  (4) makes the operation spend 24 seconds\n>> (the times are all on my primary machine x86-64 with 1GB, hot\n>> cache and average of three runs each).\n>\n> I think it is not fair,...\n\nThat's a very unexpected response.  I personally do not think\nthe separation of FETCH_FETCHED made improvements to the code,\nbut the above numbers do not have anything to do with such\nperhaps subjective ascetic judgement.\n\nThe comparison showed that the \"Split\" patch is a step backward\nfrom the existing optimization hack that was specifically made\nto solve an issue raised on the list, and you may not like the\nnumbers, but if you call that is \"not fair\", I do not know what\ncould be considered fair.\n\nYes, life is unfair, but I do not think that word applies to\nthis particular case.\n"},{"id":"37079","messageId":"8aa486160703140447g560e3b42j7a14f6c3032bb77a@mail.gmail.com","threadId":"6893","inReplyTo":"7vbqiwawva.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2007-03-14T11:47:03Z","receivedAt":"2007-03-14T11:47:03Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On 3/14/07, Junio C Hamano <junkio@cox.net> wrote:\n> \"Santi Béjar\" <sbejar@gmail.com> writes:\n>\n> >> I tried the \"NULL fetch between 1000-refs repositories\" test,\n> >> which prompted the git-fetch--tool work that was done on\n> >> jc/fetch topic in 'next', with the following versions:\n> >>\n> >>  (1) 1.5.0 (without any git-fetch--tool optimization)\n> >>  (2) master (ditto)\n> >>  (3) master with jc/fetch (but not sb/fetch topic)\n> >>  (4) next ((3) plus sb/fetch and others)\n> >>\n> >> The test scripts are at the end of this message.  Both (1) and\n> >> (2) take 3 minutes 7 seconds wallclock time.  (3) improves it\n> >> down to 15 seconds.  (4) makes the operation spend 24 seconds\n> >> (the times are all on my primary machine x86-64 with 1GB, hot\n> >> cache and average of three runs each).\n> >\n> > I think it is not fair,...\n\n[...]\n\n>, and you may not like the\n> numbers, but if you call that is \"not fair\", I do not know what\n> could be considered fair.\n\nI would consider fair the comparison you did not quote, a comparison\nwith the merge logic written in C. I know that (4) is a step backwards\nin performance as it is now, and I understand that with those numbers\nthe \"Split\" patch must be reverted.\n\nSanti\n"},{"id":"37920","messageId":"7vk5x54snc.fsf@assigned-by-dhcp.cox.net","threadId":"6893","inReplyTo":"7vps7dle8j.fsf@assigned-by-dhcp.cox.net","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-25T08:46:47Z","receivedAt":"2007-03-25T08:46:47Z","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\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'.  The topics list the commits in reverse chronological\norder.\n\n* jc/bisect (Fri Mar 23 17:54:03 2007 -0700) 6 commits\n + make the previous optimization work also on path-limited rev-list\n   --bisect\n + rev-list --bisect: Fix \"halfway\" optimization.\n + t6004: add a bit more path optimization test.\n + git-rev-list --bisect: optimization\n + git-rev-list: add --bisect-vars option.\n + t6002: minor spelling fix.\n\nThis improves \"rev-list --bisect\" performance, sometimes\nsignificantly, especially in a repository with long lines of\nsingle-parent commits.  This is only about performance, and as\nwe are already in -rc1, the topic will have to wait 1.5.1.\n\n* fl/cvsserver (Mon Mar 19 16:56:01 2007 +0100) 5 commits\n + cvsserver: Abort if connect to database fails\n + cvsserver: Make the database backend configurable\n + cvsserver: Allow to override the configuration per access method\n + cvsserver: Handle three part keys in git config correctly\n + cvsserver: Introduce new state variable 'method'\n\nThis is a beginning of supporting use of different database\nbackends, other than sqlite, with git-cvsserver.  Will not be in\n'master' until 1.5.1 is done.\n\n* js/remote-show-push (Sun Mar 18 21:34:46 2007 +0100) 1 commit\n + Teach git-remote to list pushed branches.\n\nThis is a new feature but of very little risk of breaking\nanything, so I'll merge it to 'master'.\n\n* ml/workdir (Sat Mar 17 02:58:55 2007 +0100) 6 commits\n . git-init: set core.workdir when GIT_WORK_DIR is specified\n . test GIT_WORK_DIR\n . test git-rev-parse\n . core.workdir config variable\n . introduce GIT_WORK_DIR environment variable\n . rev-parse: --is-bare-repository option\n\nWaiting for a resend without \"oops\", \"ah this is better\"\niterations, but in no hurry, as it won't be in 'master' until\n1.5.1 is done.\n\n* jc/fpl (Tue Mar 13 01:57:22 2007 -0700) 1 commit\n + git-log --first-parent: show only the first parent log\n\nThis makes viewing topic-heavy style of project history\npleasant, at least in my opinion.  With a bit of cheering up,\nI'd merge it to 'master', as it has been cooking in 'next'\nwithout causing problems, and is of low-impact kind.  But it can\nwait until 1.5.1 is done.\n\n* jc/read-tree-df (Thu Mar 15 23:25:22 2007 -0700) 1 commit\n . Fix switching to a branch with D/F when current branch has file D.\n\nThis is unfortunately way premature as it seems to expose other\nbreakages this too-strict safety measure prevents from\nhappening.  We need to rethink the whole unpack_trees() business\nafter 1.5.1.\n\n* jc/pathattr (Thu Mar 1 01:20:21 2007 -0800) 5 commits\n . pathattr: allow piping to external program.\n . pathattr: read from git_config().\n . git-show: use pathattr to run \"display\"\n . pathattr: path based configuration of various attributes.\n + convert: add scaffolding for path based selection of conversion\n   routines.\n\nStalled.  gitattributes support should be one of the focus in\nthe 1.5.2 cycle.\n\n* jc/merge-subtree (Thu Feb 15 16:32:45 2007 -0800) 1 commit\n - A new merge stragety 'subtree'.\n* js/fetch-progress (Sun Feb 25 13:13:17 2007 -0800) 1 commit\n + git-fetch: add --quiet\n* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits\n . test-para: combined diff between HEAD, index and working tree.\n . para-walk: walk n trees, index and working tree in parallel\n\nThe above are stalled.\n"},{"id":"37930","messageId":"Pine.LNX.4.63.0703251156530.4045@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6893","inReplyTo":"7vk5x54snc.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-25T09:59:01Z","receivedAt":"2007-03-25T09:59:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 25 Mar 2007, Junio C Hamano wrote:\n\n> * jc/fpl (Tue Mar 13 01:57:22 2007 -0700) 1 commit\n>  + git-log --first-parent: show only the first parent log\n> \n> This makes viewing topic-heavy style of project history pleasant, at \n> least in my opinion.  With a bit of cheering up, I'd merge it to \n> 'master', as it has been cooking in 'next' without causing problems, and \n> is of low-impact kind.  But it can wait until 1.5.1 is done.\n\n*lol* I just tried it on 'next'...\n\nBut I agree that it is ready to be merged, and that it is useful.\n\nCiao,\nDscho\n"},{"id":"37964","messageId":"7v648p2cef.fsf@assigned-by-dhcp.cox.net","threadId":"6893","inReplyTo":"Pine.LNX.4.63.0703251156530.4045@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-25T22:20:40Z","receivedAt":"2007-03-25T22:20:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> On Sun, 25 Mar 2007, Junio C Hamano wrote:\n>\n>> * jc/fpl (Tue Mar 13 01:57:22 2007 -0700) 1 commit\n>>  + git-log --first-parent: show only the first parent log\n>> \n>> This makes viewing topic-heavy style of project history pleasant, at \n>> least in my opinion.  With a bit of cheering up, I'd merge it to \n>> 'master', as it has been cooking in 'next' without causing problems, and \n>> is of low-impact kind.  But it can wait until 1.5.1 is done.\n>\n> *lol* I just tried it on 'next'...\n>\n> But I agree that it is ready to be merged, and that it is useful.\n\nHmph.  I am having hard time to decide what to make out of that\n\"*lol*\".  That branch is exactly where this is useful, as it is\na pure integration branch that never gets its own commits (there\nis one exception \"Revert\" that is directly on it, but that is an\nexception. And making an exception stand out is also a good\nthing). I do not see there is anything to laugh out loudly\nabout.\n\nOn the other hand, running \"git log -F master\" gives a mixed\npicture, as non-merge commits on 'master' are supposed to be\nobvious patches that do not need cooking period in 'next', but\nwithout the \"pee in the snow merges for fast-forwarding case\" we\ndo not use, commits on a topic that was born and cooked fully\nwhile 'master' was quiescent would also appear on the output,\nmaking it a less useful to tell which ones are \"obviously\ncorrect\" ones and which ones were cooked in their own topics.\n"},{"id":"37965","messageId":"Pine.LNX.4.63.0703260023260.4045@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6893","inReplyTo":"7v648p2cef.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-25T22:25:28Z","receivedAt":"2007-03-25T22:25:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 25 Mar 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > On Sun, 25 Mar 2007, Junio C Hamano wrote:\n> >\n> >> * jc/fpl (Tue Mar 13 01:57:22 2007 -0700) 1 commit\n> >>  + git-log --first-parent: show only the first parent log\n> >> \n> >> This makes viewing topic-heavy style of project history pleasant, at \n> >> least in my opinion.  With a bit of cheering up, I'd merge it to \n> >> 'master', as it has been cooking in 'next' without causing problems, and \n> >> is of low-impact kind.  But it can wait until 1.5.1 is done.\n> >\n> > *lol* I just tried it on 'next'...\n> >\n> > But I agree that it is ready to be merged, and that it is useful.\n> \n> Hmph.  I am having hard time to decide what to make out of that \"*lol*\".\n\nI was not sure what to expect, and thus was surprised by _that_ many \ndiagonal lines...\n\nBut this picture -- unexpected as it was -- makes tons of sense if you are \ninterested to see e.g. the history of a topic branch which was merged into \n'next'.\n\nSo, I'm all in favour of this feature.\n\nCiao,\nDscho\n"},{"id":"37996","messageId":"87zm60mrs4.fsf@mid.deneb.enyo.de","threadId":"6893","inReplyTo":"7vk5x54snc.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Florian Weimer","fromEmail":"fw@deneb.enyo.de","sentAt":"2007-03-26T06:40:27Z","receivedAt":"2007-03-26T06:40:27Z","isPatch":false,"sender":{"key":"fw@deneb.enyo.de","avatar":null},"body":"* Junio C. Hamano:\n\n> * jc/fpl (Tue Mar 13 01:57:22 2007 -0700) 1 commit\n>  + git-log --first-parent: show only the first parent log\n\nI think it's still missing documentation.\n"},{"id":"38005","messageId":"7vslbszaog.fsf@assigned-by-dhcp.cox.net","threadId":"6893","inReplyTo":"87zm60mrs4.fsf@mid.deneb.enyo.de","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-26T08:11:27Z","receivedAt":"2007-03-26T08:11:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Florian Weimer <fw@deneb.enyo.de> writes:\n\n> * Junio C. Hamano:\n>\n>> * jc/fpl (Tue Mar 13 01:57:22 2007 -0700) 1 commit\n>>  + git-log --first-parent: show only the first parent log\n>\n> I think it's still missing documentation.\n\nPatches welcome.\n"},{"id":"38178","messageId":"7v8xdio46t.fsf_-_@assigned-by-dhcp.cox.net","threadId":"6893","inReplyTo":"87zm60mrs4.fsf@mid.deneb.enyo.de","subject":"[PATCH] Document git-log --first-parent","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-27T19:51:38Z","receivedAt":"2007-03-27T19:51:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n Documentation/git-log.txt |    5 +++++\n 1 files changed, 5 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-log.txt b/Documentation/git-log.txt\nindex 361eaec..030edaf 100644\n--- a/Documentation/git-log.txt\n+++ b/Documentation/git-log.txt\n@@ -38,6 +38,11 @@ include::pretty-formats.txt[]\n \tand <until>, see \"SPECIFYING REVISIONS\" section in\n \tgitlink:git-rev-parse[1].\n \n+--first-parent::\n+\tFollow only the first parent commit upon seeing a merge\n+\tcommit.  This  option gives a better overview of the\n+\tevolution of a particular branch.\n+\n -p::\n \tShow the change the commit introduces in a patch form.\n \n-- \n1.5.1.rc2.618.g98453b\n"}]}