{"thread":{"id":"2273","subject":"GIT 0.99.9","startedAt":"2005-10-30T01:29:12Z","lastAt":"2005-11-03T07:40:21Z","messageCount":26,"participants":["Junio C Hamano","A Large Angry SCM","Linus Torvalds","Johannes Schindelin","Wolfgang Denk","Ryan Anderson","H. Peter Anvin","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"10803","messageId":"7vd5lnztav.fsf@assigned-by-dhcp.cox.net","threadId":"2273","inReplyTo":null,"subject":"GIT 0.99.9","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-30T01:29:12Z","receivedAt":"2005-10-30T01:29:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"GIT 0.99.9 is found at usual places.\n\nAs I said in the 0.99.8 announcement, git already does\neverything I want it to do, and from here on I'd like to see us\nconcentrate on fixes (both correctness and performance) until we\nhit 1.0 which should happen shortly.\n\nMany thanks to everybody who contributed the comments, extra set\nof eyeballs, and code.\n\n\nDone in 0.99.9\n==============\n\nPorts\n~~~~~\n\n* Cygwin port [HPA].\n\n* OpenBSD build [Merlyn and others].\n\n\nFixes\n~~~~~\n\n* clone request over git native protocol from a repository with\n  too many refs did not work; this has been fixed.\n\n* git-daemon got safer for kernel.org use [HPA].\n\n* Extended SHA1 parser was not enforcing uniqueness for\n  abbreviated SHA1; this has been fixed.\n\n* http transport does not barf on funny characters in URL.\n\n* The ref naming restrictions have been formalized and the\n  coreish refuses to create funny refs; we still need to audit\n  importers.  See git-check-ref-format(1).\n\n\nNew Features and Commands\n~~~~~~~~~~~~~~~~~~~~~~~~~\n\n* .git/config file as a per-repository configuration mechanism,\n  and some commands understand it [Linus].  See\n  git(7).\n\n* The core.filemode configuration item can be used to make us a\n  bit more FAT friendly.  See git(7).\n\n* The extended SHA1 notation acquired Peel-the-onion operator\n  ^{type} and ^{}.  See git-rev-parse(1).\n\n* SVN importer [Matthias].  See git-svnimport(1).\n\n* .git/objects/[0-9a-f]{2} directories are created on demand,\n  and removed when becomes empty after prune-packed [Linus].\n\n* Filenames output from various commands without -z option are\n  quoted when they embed funny characters (TAB and LF) using\n  C-style quoting within double-quotes, to match the proposed\n  GNU diff/patch notation [me, but many people contributed in\n  the discussion].\n\n* git-mv is expected to be a better replacement for git-rename.\n  While the latter has two parameter restriction, it acts more\n  like the regular 'mv' that can move multiple things to one\n  destinatino directory [Josef Weidendorfer].\n\n* git-checkout can take filenames to revert the changes to\n  them.  See git-checkout(1)\n\n* The new program git-am is a replacement for git-applymbox that\n  has saner command line options and a bit easier to use when a\n  patch does not apply cleanly.\n\n* git-ls-remote can show unwrapped onions using ^{} notation, to\n  help Cogito to track tags.\n\n* git-merge-recursive backend can merge unrelated projects.\n\n* git-clone over native transport leaves the result packed.\n\n* git-http-fetch issues multiple requests in parallel when\n  underlying cURL library supports it [Nick and Daniel].\n\n* git-fetch-pack and git-upload-pack try harder to figure out\n  better common commits [Johannes].\n\n* git-read-tree -u removes a directory when it makes it empty.\n\n* git-diff-* records abbreviated SHA1 names of original and\n  resulting blob; this sometimes helps to apply otherwise an\n  unapplicable patch by falling back to 3-way merge.\n\n* git-format-patch now takes series of from..to rev ranges and\n  with '-m --stdout', writes them out to the standard output.\n  This can be piped to 'git-am' to implement cheaper\n  cherry-picking.\n\n* git-tag takes '-u' to specify the tag signer identity [Linus].\n\n* git-rev-list can take optional pathspecs to skip commits that\n  do not touch them (--dense) [Linus].\n\n* Comes with new and improved gitk [Paulus and Linus].\n"},{"id":"10804","messageId":"43643AF8.9090001@gmail.com","threadId":"2273","inReplyTo":"7vd5lnztav.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT 0.99.9","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2005-10-30T03:16:08Z","receivedAt":"2005-10-30T03:16:08Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> GIT 0.99.9 is found at usual places.\n> \n> As I said in the 0.99.8 announcement, git already does\n> everything I want it to do, and from here on I'd like to see us\n> concentrate on fixes (both correctness and performance) until we\n> hit 1.0 which should happen shortly.\n> \n> Many thanks to everybody who contributed the comments, extra set\n> of eyeballs, and code.\n> \n> \n> Done in 0.99.9\n> ==============\n[Lots of text deleted]\n\nIt's nice to see the TODO list get shorter for a change! Especially \nsince the removed TODO items are not on the HAVEDONE list.\n\nSo, with 0.99.9 being the (non) \"scary\" release of Git, are you \ntargeting the Git 1.0 to be the (non) \"turkey\" release or the \"fruit \ncake\" release? ;-)\n"},{"id":"10805","messageId":"7vslujy8or.fsf@assigned-by-dhcp.cox.net","threadId":"2273","inReplyTo":"43643AF8.9090001@gmail.com","subject":"Re: GIT 0.99.9","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-30T03:39:48Z","receivedAt":"2005-10-30T03:39:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"A Large Angry SCM <gitzilla@gmail.com> writes:\n\n> It's nice to see the TODO list get shorter for a change! Especially \n> since the removed TODO items are not on the HAVEDONE list.\n\nHuh?  What are you talking about?\n\nMost of the items that were on the TODO list and marked [DONE]\nare on the HAVEDONE list, although I rephrased many of them to\nbe more appropriate for the release notes.  The only thing that\nI did not list on HAVEDONE list was 'whatchanged -m'\ndocumentation.  There are many documentation contributions from\nthe list I do not mention in HAVEDONE.\n\nI dropped from the TODO list was the \"Perhaps show ^{commit},\n^{tree} instead of ^{} from ls-remote\", whose benefit was\ndubious.\n"},{"id":"10806","messageId":"43644608.90608@gmail.com","threadId":"2273","inReplyTo":"7vslujy8or.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT 0.99.9","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2005-10-30T04:03:20Z","receivedAt":"2005-10-30T04:03:20Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> A Large Angry SCM <gitzilla@gmail.com> writes:\n> \n>>It's nice to see the TODO list get shorter for a change! Especially \n>>since the removed TODO items are not on the HAVEDONE list.\n                                    ^^^\nOops! The ``not'' wasn't supposed to be there!!!!\n\n> \n> Huh?  What are you talking about?\n\nMy typing was in error. The ``not'' should not have been there.\n\n> Most of the items that were on the TODO list and marked [DONE]\n> are on the HAVEDONE list, although I rephrased many of them to\n> be more appropriate for the release notes.  The only thing that\n> I did not list on HAVEDONE list was 'whatchanged -m'\n> documentation.  There are many documentation contributions from\n> the list I do not mention in HAVEDONE.\n> \n> I dropped from the TODO list was the \"Perhaps show ^{commit},\n> ^{tree} instead of ^{} from ls-remote\", whose benefit was\n> dubious.\n> \n> \n\nJunio, I think you're doing an great job with Git. Particularly, since \nI'm thinking that it may be mature enough to replace another SCM with a \nvery large code base that I deal with.\n"},{"id":"10807","messageId":"Pine.LNX.4.64.0510292204520.3348@g5.osdl.org","threadId":"2273","inReplyTo":"7vd5lnztav.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT 0.99.9","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-30T05:05:46Z","receivedAt":"2005-10-30T05:05:46Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 29 Oct 2005, Junio C Hamano wrote:\n>\n> GIT 0.99.9 is found at usual places.\n\nCongrats. I personally think this is very much worthy of a 1.0 after just \ngiving it some time to shake out any possible last-minute bugs.\n\n\t\tLinus\n"},{"id":"10808","messageId":"7v64rfxuwl.fsf_-_@assigned-by-dhcp.cox.net","threadId":"2273","inReplyTo":"Pine.LNX.4.64.0510292204520.3348@g5.osdl.org","subject":"rev-list --sparse?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-30T08:37:30Z","receivedAt":"2005-10-30T08:37:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I was reviewing the rev-list documentation and it struck me that\ndense/sparse command line flag do not make much sense.\n\nSince dense is by default in effect, --dense is a no-op.  One\npossible use of it would be to hardcode --dense on a rev-list\ncommand line in a script, like:\n\n\tgit-rev-list $some_opts --dense $some_paths\n\nto defeat user-supplied --sparse that can be in $some_opts, but\nfor this to work the script needs to have parsed out user input\ninto some_opts and some_paths in the first place anyway, so it\ncan just detect and remove --sparse just as easily.\n\nThe --sparse flag does not seem to have much use either; not\ngiving pathspec has the same effect.\n"},{"id":"10811","messageId":"Pine.LNX.4.63.0510301418110.25610@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2273","inReplyTo":"43644608.90608@gmail.com","subject":"Re: GIT 0.99.9","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-10-30T13:21:02Z","receivedAt":"2005-10-30T13:21:02Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 29 Oct 2005, A Large Angry SCM wrote:\n\n> Junio, I think you're doing an great job with Git.\n\nConcur!\n\n> Particularly, since I'm thinking that it may be mature enough to replace \n> another SCM with a very large code base that I deal with.\n\nAdd to that the fact that most, if not all, changes are made backwards \ncompatible, i.e. git has stable for a *long* time now.\n\nCiao,\nDscho\n"},{"id":"10816","messageId":"20051030172018.520BD353416@atlas.denx.de","threadId":"2273","inReplyTo":"7vd5lnztav.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT 0.99.9","fromName":"Wolfgang Denk","fromEmail":"wd@denx.de","sentAt":"2005-10-30T17:20:18Z","receivedAt":"2005-10-30T17:20:18Z","isPatch":false,"sender":{"key":"wd@denx.de","avatar":null},"body":"In message <7vd5lnztav.fsf@assigned-by-dhcp.cox.net> you wrote:\n> GIT 0.99.9 is found at usual places.\n\n\"make rpm\" does not work for me:\n\n...\nmake -C templates install\nmake[2]: Entering directory `/usr/local/BUILD/git-core-0.99.9/templates'\n: no custom templates yet\nfind blt\nblt\nblt/branches\nblt/hooks\nblt/hooks/post-commit\nblt/hooks/applypatch-msg\nblt/hooks/commit-msg\nblt/hooks/post-update\nblt/hooks/update\nblt/hooks/pre-applypatch\nblt/hooks/pre-commit\nblt/info\nblt/info/exclude\nblt/description\nblt/remotes\ninstall -d -m755 '/var/tmp/git-core-0.99.9-1-root-wd/usr/share/git-core/templates/'\n(cd blt && tar cf - .) | \\\n(cd '/var/tmp/git-core-0.99.9-1-root-wd/usr/share/git-core/templates/' && tar xf -)\ntar: This does not look like a tar archive\ntar: Skipping to next header\ntar: Error exit delayed from previous errors\nmake[2]: *** [install] Error 2\nmake[2]: Leaving directory `/usr/local/BUILD/git-core-0.99.9/templates'\nmake[1]: *** [install] Error 2\nmake[1]: Leaving directory `/usr/local/BUILD/git-core-0.99.9'\nerror: Bad exit status from /var/tmp/rpm-tmp.96513 (%install)\n\n\nRPM build errors:\n    Bad exit status from /var/tmp/rpm-tmp.96513 (%install)\nmake: *** [rpm] Error 1\n\n\nBest regards,\n\nWolfgang Denk\n\n-- \nSoftware Engineering:  Embedded and Realtime Systems,  Embedded Linux\nPhone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de\n\"The computer programmer is a creator of universes for which he alone\nis responsible. Universes of virtually unlimited  complexity  can  be\ncreated  in  the  form  of  computer  programs.\" - Joseph Weizenbaum,\n_Computer Power and Human Reason_\n"},{"id":"10817","messageId":"7vvezesyhi.fsf@assigned-by-dhcp.cox.net","threadId":"2273","inReplyTo":"20051030172018.520BD353416@atlas.denx.de","subject":"Re: GIT 0.99.9","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-30T17:31:21Z","receivedAt":"2005-10-30T17:31:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Wolfgang Denk <wd@denx.de> writes:\n\n> In message <7vd5lnztav.fsf@assigned-by-dhcp.cox.net> you wrote:\n>> GIT 0.99.9 is found at usual places.\n>\n> \"make rpm\" does not work for me:\n\nI hate it when somebody tells me \"it works for me\", but I cannot\nhelp you here, sorry.  I'm no rpm expert and the \"make rpm\" rule\nseems to work for me.\n"},{"id":"10820","messageId":"20051030202322.A65D2353CD1@atlas.denx.de","threadId":"2273","inReplyTo":"7vvezesyhi.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT 0.99.9","fromName":"Wolfgang Denk","fromEmail":"wd@denx.de","sentAt":"2005-10-30T20:23:22Z","receivedAt":"2005-10-30T20:23:22Z","isPatch":false,"sender":{"key":"wd@denx.de","avatar":null},"body":"In message <7vvezesyhi.fsf@assigned-by-dhcp.cox.net> you wrote:\n> \n> I hate it when somebody tells me \"it works for me\", but I cannot\n> help you here, sorry.  I'm no rpm expert and the \"make rpm\" rule\n> seems to work for me.\n\nWhich environment (Linux distribution) did you test this on? I  tried\nFedora  Core  2  and  4,  both  with  the same result. I get the same\nproblem when building from the git source  tree  or  when  using  the\nsource RPM.\n\nBest regards,\n\nWolfgang Denk\n\n-- \nSoftware Engineering:  Embedded and Realtime Systems,  Embedded Linux\nPhone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de\nA person with one watch knows what time it  is;  a  person  with  two\nwatches is never sure.                                       Proverb\n"},{"id":"10821","messageId":"20051030203808.A535B353E3E@atlas.denx.de","threadId":"2273","inReplyTo":"7vvezesyhi.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT 0.99.9","fromName":"Wolfgang Denk","fromEmail":"wd@denx.de","sentAt":"2005-10-30T20:38:08Z","receivedAt":"2005-10-30T20:38:08Z","isPatch":false,"sender":{"key":"wd@denx.de","avatar":null},"body":"In message <7vvezesyhi.fsf@assigned-by-dhcp.cox.net> you wrote:\n>\n> > \"make rpm\" does not work for me:\n> \n> I hate it when somebody tells me \"it works for me\", but I cannot\n> help you here, sorry.  I'm no rpm expert and the \"make rpm\" rule\n> seems to work for me.\n\nOK, I found the problem. The key part is this:\n\n[current directory: .../usr/share/git-core/templates/]\n    (cd blt && tar cf - .) | \\\n    (cd '/var/tmp/git-core-0.99.9-1-root-wd/usr/share/git-core/templates/' && tar xf -)\n    tar: This does not look like a tar archive\n    tar: Skipping to next header\n    tar: Error exit delayed from previous errors\n\nI have CDPATH set in my  shell  environment,  and  bash  outputs  the\npathname  of  the  new  working  directory on stdout; this gets piped\ntogether with the tarball to the \"tar  xf  -\",  and  the  second  tar\ncomplains that the directory name comes unexpected. Test:\n\n-> cd /usr/local/BUILD/git-core-0.99.9/templates\n-> cd blt\n/usr/local/BUILD/git-core-0.99.9/templates/blt\n-> \n\nAs a workaround I can simply unset CDPATH, and the build works  fine.\nA more robust build script woul make sure that CDPATH is not set.\n\nBest regards,\n\nWolfgang Denk\n\n-- \nSoftware Engineering:  Embedded and Realtime Systems,  Embedded Linux\nPhone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de\nTesting can show the presense of bugs, but not their absence.\n                                                   -- Edsger Dijkstra\n"},{"id":"10823","messageId":"7v7jbuohqw.fsf@assigned-by-dhcp.cox.net","threadId":"2273","inReplyTo":"20051030202322.A65D2353CD1@atlas.denx.de","subject":"Re: GIT 0.99.9","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-30T20:46:31Z","receivedAt":"2005-10-30T20:46:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Wolfgang Denk <wd@denx.de> writes:\n\n> In message <7vvezesyhi.fsf@assigned-by-dhcp.cox.net> you wrote:\n>> \n>> I hate it when somebody tells me \"it works for me\", but I cannot\n>> help you here, sorry.  I'm no rpm expert and the \"make rpm\" rule\n>> seems to work for me.\n>\n> Which environment (Linux distribution) did you test this on? I  tried\n> Fedora  Core  2  and  4,  both  with  the same result. I get the same\n> problem when building from the git source  tree  or  when  using  the\n> source RPM.\n\nWhatever is running on kernel.org.  I think I was once told they\nrun RH-EL but I do not have that e-mail now.\n"},{"id":"10826","messageId":"Pine.LNX.4.64.0510301337500.27915@g5.osdl.org","threadId":"2273","inReplyTo":"7v64rfxuwl.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: rev-list --sparse?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-30T21:42:43Z","receivedAt":"2005-10-30T21:42:43Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 30 Oct 2005, Junio C Hamano wrote:\n> \n> The --sparse flag does not seem to have much use either; not\n> giving pathspec has the same effect.\n\nNo.\n\n--sparse _does_ have effect, but it's subtler.\n\nTry \"--sparse\" together with a pathspec. It will only do the merge \nfollow optimization.\n\nNow, how useful is that? It's potentially useful as a way to \"linearize \nthe history\". For example, let's say that you wanted to simplify the \ncommit history for a project, and you only cared about the history of \ncertain files - but you do want all the other files to _exist_ in that \nhistory.\n\nSo then you could do \"git-rev-list --sparse HEAD -- filelist\" and you'd \nget the minimal history that is still relevant in those files. Any merges \nthat touch anything else than those files will becomes just regular diffs: \nthey'll have been linearized away.\n\nUseful? Quite possibly not. But I felt that simplifying merges was \nconceptually a very different operation from then compressing a linear \nhistory.\n\n\t\tLinus\n"},{"id":"10829","messageId":"436549C5.3000204@michonline.com","threadId":"2273","inReplyTo":"20051030203808.A535B353E3E@atlas.denx.de","subject":"Re: GIT 0.99.9","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2005-10-30T22:31:33Z","receivedAt":"2005-10-30T22:31:33Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"Wolfgang Denk wrote:\n> As a workaround I can simply unset CDPATH, and the build works  fine.\n> A more robust build script woul make sure that CDPATH is not set.\n\nTry setting CDPATH, but not exporting it in your shell startup\nconfiguration.\n\n"},{"id":"10831","messageId":"7v4q6ymx9w.fsf@assigned-by-dhcp.cox.net","threadId":"2273","inReplyTo":"20051030203808.A535B353E3E@atlas.denx.de","subject":"Re: GIT 0.99.9","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-30T22:54:03Z","receivedAt":"2005-10-30T22:54:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Wolfgang Denk <wd@denx.de> writes:\n\n> I have CDPATH set in my  shell  environment,...\n\nI understand some people like CDPATH in their interactive\nshells, but I do not see a good reason to export that to random\nshell scripts you run from your interactive shell session.\n\nWe already have a workaround for this exact silliness in\ngit-sh-setup. Probably we also need to do this to our build\nprocedure, I guess.  Sigh...\n"},{"id":"10833","messageId":"43655138.2000400@zytor.com","threadId":"2273","inReplyTo":"7v4q6ymx9w.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT 0.99.9","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-30T23:03:20Z","receivedAt":"2005-10-30T23:03:20Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \n> I understand some people like CDPATH in their interactive\n> shells, but I do not see a good reason to export that to random\n> shell scripts you run from your interactive shell session.\n> \n\nNo kidding.  Having 'cd' output stuff to stdout is asking for a million \nshell scripts to be broken.\n\n\t-hpa\n"},{"id":"10834","messageId":"7vll0algz6.fsf@assigned-by-dhcp.cox.net","threadId":"2273","inReplyTo":"Pine.LNX.4.64.0510301337500.27915@g5.osdl.org","subject":"Re: rev-list --sparse?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-30T23:31:25Z","receivedAt":"2005-10-30T23:31:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> Try \"--sparse\" together with a pathspec. It will only do the merge \n> follow optimization.\n\nAh, I saw (paths && dense) everywhere but there indeed is one\nthat only checks paths to call merge simplification -- I missed\nthat part.\n"},{"id":"10840","messageId":"Pine.LNX.4.64.0510301838110.27915@g5.osdl.org","threadId":"2273","inReplyTo":"7vd5lnztav.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT 0.99.9","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-31T02:52:11Z","receivedAt":"2005-10-31T02:52:11Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nBtw, \n one thing I'd like to see (maybe it already exists and I just have \noverlooked it) is some kind of simple readme or something about the \ndifferent ways to limit the output of the various git commands.\n\nI've several times been surprised to see people not realize that\n\"git-whatchanged\" takes a file list to limit the files it is interested \nin. I also suspect people don't realize that you can limit it by time and \nversion and file list, all at the same time.\n\nIOW, \n\n\tgit-whatchanged -p --pretty=short --since=\"2 weeks ago\" v0.99.8..v0.99.9 Makefile\n\nis a valid query: it basically asks for any change to the Makefile in \nbetween versions v0.99.8..v0.99.9, _and_ within the last two weeks, and \nasks to show it as a patch, with the shortened commit message.\n\nIs it useful? The above exact line almost certainly isn't, but variations \non the above definitely are. And I suspect a lot of people never even \nrealized you could do something like that.\n\n(The danger with date-based things is that something may be 4 months old, \nbut it only got _merged_ yesterday, so it may be new to _you_. And the \n--since=\"2 weeks ago\" will not show it, which can be surprising to people \nwho expect things that are new to _them_ to be shown).\n\nThe above limiters now work with \"git log\" and \"gitk\" too (they've worked \nfor a long time with \"git-whatchanged\", but only with the new git-rev-list \nfunctionality does the name-limiting work for the other commands).\n\nIt would be good to make this more well-known, because a lot of people \nprobably end up using git not as developers, but just to follow what is \ngoing on. And then the different limiters are some of the most important \nparts (the date-one is likely the least important one, but limiting by \nversion and name is _very_ important).\n\n\t\tLinus\n"},{"id":"10841","messageId":"7v4q6yl6wv.fsf@assigned-by-dhcp.cox.net","threadId":"2273","inReplyTo":"Pine.LNX.4.64.0510301838110.27915@g5.osdl.org","subject":"Re: GIT 0.99.9","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-31T03:08:48Z","receivedAt":"2005-10-31T03:08:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> I've several times been surprised to see people not realize that\n> \"git-whatchanged\" takes a file list to limit the files it is interested \n> in. I also suspect people don't realize that you can limit it by time and \n> version and file list, all at the same time.\n\n> It would be good to make this more well-known, because a lot of people \n> probably end up using git not as developers, but just to follow what is \n> going on. And then the different limiters are some of the most important \n> parts (the date-one is likely the least important one, but limiting by \n> version and name is _very_ important).\n\nI've somewhat updated git-rev-list documentation and tried to\ncategorize the options into commit selectors and presentation\nmodifiers.  The documentation for commands you mentioned in your\nmessage all talk about them describing only frequently used\noptions, and refer the user to rev-list documentation.  I am not\nsure this would be enough.\n\nOne good thing to have would be to add a section to Tutorial.\nCurrently we cover building a small project from scratch and\nhave the readers graduate when they learn basic commit swapping,\nbut we do not talk much about archaeology tools.\n"},{"id":"10842","messageId":"Pine.LNX.4.64.0510302000310.27915@g5.osdl.org","threadId":"2273","inReplyTo":"7v4q6yl6wv.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT 0.99.9","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-31T04:05:32Z","receivedAt":"2005-10-31T04:05:32Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 30 Oct 2005, Junio C Hamano wrote:\n> \n> I've somewhat updated git-rev-list documentation and tried to\n> categorize the options into commit selectors and presentation\n> modifiers.  The documentation for commands you mentioned in your\n> message all talk about them describing only frequently used\n> options, and refer the user to rev-list documentation.  I am not\n> sure this would be enough.\n\nI don't think people really follow the links or think very abstractly at \nall in the first place.\n\nSo I was thinking more of some explicit examples. I actually think every \ncommand should have an example in the man-page, and hey, here's a patch to \nstart things off.\n\nOf course, I'm not exactly \"Mr Documentation\", and I don't know that this \nis the prettiest way to do this, but I checked that the resulting html and \nman-page seems at least reasonable.\n\nAnd hey, if the examples look like each other, that's just because I'm \nalso not \"Mr Imagination\".\n\nSigned-off-by: Linus Torvalds <torvalds@osdl.org>\n---\n\nI think most people understand a lot better from practice than from \ntheory, and that an example of real usage is much more likely to make \npeople udnerstand a command than just listing what it can do.\n\ndiff --git a/Documentation/git-log.txt b/Documentation/git-log.txt\nindex 13a3998..9cac088 100644\n--- a/Documentation/git-log.txt\n+++ b/Documentation/git-log.txt\n@@ -30,6 +30,24 @@ OPTIONS\n \tShow only commits between the named two commits.\n \n \n+Examples\n+--------\n+git log --no-merges::\n+\n+\tShow the whole commit history, but skip any merges\n+\n+git log v2.6.12.. include/scsi drivers/scsi::\n+\n+\tShow all commits since version 'v2.6.12' that changed any file\n+\tin the include/scsi or drivers/scsi subdirectories\n+\n+git log --since=\"2 weeks ago\" -- gitk::\n+\n+\tShow the changes during the last two weeks to the file 'gitk'.\n+\tThe \"--\" is necessary to avoid confusion with the *branch* named\n+\t'gitk'\n+\n+\n Author\n ------\n Written by Linus Torvalds <torvalds@osdl.org>\ndiff --git a/Documentation/git-whatchanged.txt b/Documentation/git-whatchanged.txt\nindex e6f57d9..6c150b0 100644\n--- a/Documentation/git-whatchanged.txt\n+++ b/Documentation/git-whatchanged.txt\n@@ -51,6 +51,20 @@ OPTIONS\n \tHowever, it is not very useful in general, although it\n \t*is* useful on a file-by-file basis.\n \n+Examples\n+--------\n+git-whatchanged -p v2.6.12.. include/scsi drivers/scsi::\n+\n+\tShow as patches the commits since version 'v2.6.12' that changed\n+\tany file in the include/scsi or drivers/scsi subdirectories\n+\n+git-whatchanged --since=\"2 weeks ago\" -- gitk::\n+\n+\tShow the changes during the last two weeks to the file 'gitk'.\n+\tThe \"--\" is necessary to avoid confusion with the *branch* named\n+\t'gitk'\n+\n+\n Author\n ------\n Written by Linus Torvalds <torvalds@osdl.org> and\ndiff --git a/Documentation/gitk.txt b/Documentation/gitk.txt\nindex e5ef6d6..eb126d7 100644\n--- a/Documentation/gitk.txt\n+++ b/Documentation/gitk.txt\n@@ -24,6 +24,19 @@ OPTIONS\n \tSome argument not yet documented.\n \n \n+Examples\n+--------\n+gitk v2.6.12.. include/scsi drivers/scsi::\n+\n+\tShow as the changes since version 'v2.6.12' that changed any\n+\tfile in the include/scsi or drivers/scsi subdirectories\n+\n+gitk --since=\"2 weeks ago\" -- gitk::\n+\n+\tShow the changes during the last two weeks to the file 'gitk'.\n+\tThe \"--\" is necessary to avoid confusion with the *branch* named\n+\t'gitk'\n+\n Author\n ------\n Written by Paul Mackerras <paulus@samba.org>\n"},{"id":"10894","messageId":"Pine.LNX.4.64.0510311820060.25300@iabervon.org","threadId":"2273","inReplyTo":"Pine.LNX.4.64.0510301838110.27915@g5.osdl.org","subject":"Date-based limits (Was Re: GIT 0.99.9)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-10-31T23:47:03Z","receivedAt":"2005-10-31T23:47:03Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 30 Oct 2005, Linus Torvalds wrote:\n\n> (The danger with date-based things is that something may be 4 months old, \n> but it only got _merged_ yesterday, so it may be new to _you_. And the \n> --since=\"2 weeks ago\" will not show it, which can be surprising to people \n> who expect things that are new to _them_ to be shown).\n\nAt some point, we might want to have a series of refs tracking changes to \nthe user's heads over time. Then the right set of arguments could actually \nhandle \"what would I have seen on Thursday, when I hadn't pulled since \nTuesday, and upstream got some changes on Wednesday that I got on Friday, \nand it's Saturday now.\" (That is, Wednesday's commits hadn't hit the local \nrepository yet; the commit that we got to is dated Friday for local \npurposes, and the latest as of Thursday is dated Tuesday, which is the \nlast time the ref file was modified.)\n\nAnd we probably don't want to fetch or clone this stuff; I doubt most \npeople want to know the history from somebody else's point of view. At \nleast, I can't think of a use for it that wouldn't be better served by \nasking whoever for the hash out of their history.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"10902","messageId":"7v1x21b3v6.fsf@assigned-by-dhcp.cox.net","threadId":"2273","inReplyTo":"Pine.LNX.4.64.0510311820060.25300@iabervon.org","subject":"Re: Date-based limits","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-01T00:37:01Z","receivedAt":"2005-11-01T00:37:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> At some point, we might want to have a series of refs tracking changes to \n> the user's heads over time.\n\nHmph.  If you really want something like that, I think you could\nadd a hook support for git-fetch to implement this as\nautomatically created lightweight tags, stashed in\n$GIT_DIR/fetch-history/, deriving their names from the time of\nthe fetch; clone would grab everything below refs/ but this is\ndeliberately placed outside that hierarchy and won't get copied.\nBy definition, these point at commits reachable from some of\nyour heads (unless the remote repository maintainer is stupid\nenough to rewind public trees ;-), so fsck-object would not see\nthem but it should not be a problem.\n"},{"id":"10904","messageId":"Pine.LNX.4.64.0510311940120.25300@iabervon.org","threadId":"2273","inReplyTo":"7v1x21b3v6.fsf@assigned-by-dhcp.cox.net","subject":"Re: Date-based limits","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-11-01T00:43:55Z","receivedAt":"2005-11-01T00:43:55Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 31 Oct 2005, Junio C Hamano wrote:\n\n> Daniel Barkalow <barkalow@iabervon.org> writes:\n> \n> > At some point, we might want to have a series of refs tracking changes to \n> > the user's heads over time.\n> \n> Hmph.  If you really want something like that, I think you could\n> add a hook support for git-fetch to implement this as\n> automatically created lightweight tags...\n\nProbably; I think this should also trigger on commits and such, and it \nwould need a way for rev-list (or rev-parse?) to find the last one before \na user-specified date, so that you don't have to figure out when the last \nchange was that contributed to you seeing a particular tree on a given \ndate.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"11019","messageId":"7vbr12swj3.fsf_-_@assigned-by-dhcp.cox.net","threadId":"2273","inReplyTo":"Pine.LNX.4.64.0510301838110.27915@g5.osdl.org","subject":"[PATCH] rev-list: make --max- and --min-age a bit more usable.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-02T19:02:40Z","receivedAt":"2005-11-02T19:02:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> I've several times been surprised to see people not realize that\n> \"git-whatchanged\" takes a file list to limit the files it is interested \n> in. I also suspect people don't realize that you can limit it by time and \n> version and file list, all at the same time.\n\nThe current \"time based limiting\" is not very user friendly, so\npeople not knowing the limit-by-time is not a surprise.\n\n> \tgit-whatchanged -p --pretty=short --since=\"2 weeks ago\" v0.99.8..v0.99.9 Makefile\n>\n> is a valid query\n\nWell, it is not a valid query ;-) Nobody implemented --since\nyet, but you could spell it --max-age.  It would not grok \"2\nweeks ago\" though.\n\nWith the attached patch, you could at least do:\n\n\tgit log --max-age='2005-10-25' v0.99.8..v0.99.9 Makefile\n\nThere are still a couple of things that bothers me.\n\n(1) The underlying workhorse, rev-list, takes max-age and\n    min-age.  While these names are logically correct, it feels\n    a bit hard and counterintuitive when deciding which one to\n    use in order to ask \"what are the ones that happened after\n    Wednesday last week?\".  The query talks about the commits\n    being young, so --max-age=2005-10-26 is the right query\n    (i.e. \"I want to discard things that are older than that\n    time\"), but as soon as I type \"max\", my mind starts\n    comparing date strings, and surely 2005-10-21 is smaller\n    than 2005-10-26 and I am saying 2005-10-26 is the max, which\n    confuses me to think that 2005-10-21 would be included in\n    the result (it would not be -- we are talking about age, so\n    2005-10-21 one is older, which means its age is greater than\n    specified). It takes some mental effort to do this, at least\n    for me.\n\n    I *hate* to suggest this change at this late stage of the\n    game, but maybe they should be renamed or at least acquire \n    less confusing synonyms, perhaps?\n\n\t--max-age\t= --min-timestamp, --since\n        --min-age\t= --max-timestamp, --until\n\n(2) If I run the above --max-age query, the last commit\n    displayed is this one:\n\n        commit f3123c4ab3d3698262e59561ac084de45b10365a\n        Author: Junio C Hamano <junkio@cox.net>\n        Date:   Sat Oct 22 01:28:13 2005 -0700\n\n    This is because the age limit uses commit date (which is a\n    sensible thing to do) while the display shows author date.\n    To an uninitiated, this takes some explanation and\n    justification (i.e. counterintuitive again).\n\n    Incidenally, I have not found a way to prettyprint the\n    commit date; --pretty=raw gives that information, but in\n    really raw format.  --pretty=full does not even give any\n    timestamp.\n\n    Again I *hate* to suggest this, but maybe --pretty=full\n    should show both author and commit timestamp as well, like\n    this?\n\n        commit f3123c4ab3d3698262e59561ac084de45b10365a\n        Author: Junio C Hamano <junkio@cox.net>\n        A-Date: Sat Oct 22 01:28:13 2005 -0700\n        Commit: Junio C Hamano <junkio@cox.net>\n        C-Date: Wed Oct 26 12:37:49 2005 -0700\n\n\n-- >8 -- cut here -- >8 --\n\nEarlier we just did atoi to accept these parameters, which meant\nthat the user needed to specify the raw UNIX time format to use\nthem.\n\nThis still does not make it accept '2 weeks ago', but at least\nit now can take --max-age='2005-10-15', which is a start.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\n\n rev-list.c |   19 +++++++++++++++++--\n 1 files changed, 17 insertions(+), 2 deletions(-)\n\napplies-to: 0c9683fe37dbc43713faaa15fcce14bfe5621bba\n9dc13af3f916803d270d3387032eb0e91b940417\ndiff --git a/rev-list.c b/rev-list.c\nindex 6e6ffde..7a73703 100644\n--- a/rev-list.c\n+++ b/rev-list.c\n@@ -712,6 +712,21 @@ static void handle_all(struct commit_lis\n \tglobal_lst = NULL;\n }\n \n+static unsigned long getdate(const char *arg, const char *label)\n+{\n+\tchar text[80];\n+\tunsigned long date;\n+\n+\tif (parse_date(arg, text, sizeof(text)) < 0) {\n+\t\t/* Maybe handle \"4 days ago\" and the like here... */\n+\t\tdie(\"bad time specification for %s: %s\", label, arg);\n+\t}\n+\tdate = strtoul(text, NULL, 10);\n+\tif (date == ULONG_MAX)\n+\t\tdie(\"unparsable time specification for %s: %s\", label, arg);\n+\treturn date;\n+}\n+\n int main(int argc, const char **argv)\n {\n \tconst char *prefix = setup_git_directory();\n@@ -730,12 +745,12 @@ int main(int argc, const char **argv)\n \t\t\tcontinue;\n \t\t}\n \t\tif (!strncmp(arg, \"--max-age=\", 10)) {\n-\t\t\tmax_age = atoi(arg + 10);\n+\t\t\tmax_age = getdate(arg + 10, \"max-age\");\n \t\t\tlimited = 1;\n \t\t\tcontinue;\n \t\t}\n \t\tif (!strncmp(arg, \"--min-age=\", 10)) {\n-\t\t\tmin_age = atoi(arg + 10);\n+\t\t\tmin_age = getdate(arg + 10, \"min-age\");\n \t\t\tlimited = 1;\n \t\t\tcontinue;\n \t\t}\n---\n0.99.9.GIT\n"},{"id":"11055","messageId":"Pine.LNX.4.64.0511021908220.27915@g5.osdl.org","threadId":"2273","inReplyTo":"7vbr12swj3.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] rev-list: make --max- and --min-age a bit more usable.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-03T03:11:00Z","receivedAt":"2005-11-03T03:11:00Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 2 Nov 2005, Junio C Hamano wrote:\n> \n> > \tgit-whatchanged -p --pretty=short --since=\"2 weeks ago\" v0.99.8..v0.99.9 Makefile\n> >\n> > is a valid query\n> \n> Well, it is not a valid query ;-) Nobody implemented --since\n> yet, but you could spell it --max-age.  It would not grok \"2\n> weeks ago\" though.\n\nHave you tried it? \n\n\"--since\" _works_.\n\nAll the magic is in \"git-rev-parse\". Try it.\n\n> With the attached patch, you could at least do:\n> \n> \tgit log --max-age='2005-10-25' v0.99.8..v0.99.9 Makefile\n\nNo. Really. _try_ it. You can do\n\n\tgit log --since=\"September 25\"\n\nAnd ItJustWorks(tm).\n\nNo patches needed. Anywhere. It's worked for quite a long time too. Since \ncommit c1babb1d65e034a058c14379eabec8eb374757ca, to be exact.\n\n    [PATCH] Teach \"git-rev-parse\" about date-based cut-offs\n\nJust use it.\n\n\t\tLinus\n"},{"id":"11057","messageId":"7v64ranpqy.fsf@assigned-by-dhcp.cox.net","threadId":"2273","inReplyTo":"Pine.LNX.4.64.0511021908220.27915@g5.osdl.org","subject":"Re: [PATCH] rev-list: make --max- and --min-age a bit more usable.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-03T07:40:21Z","receivedAt":"2005-11-03T07:40:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> All the magic is in \"git-rev-parse\". Try it.\n\nAhhhh.  I missed that.  Thanks.\n\n-- >8 -- cut here -- >8 --\nDocument --since and --until options to rev-parse.\n\nThe usability magic were hidden in the source code without being\ndocumented, and even the maintainer did not know about them ;-).\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\ndiff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt\nindex 099db29..8b8068c 100644\n--- a/Documentation/git-rev-parse.txt\n+++ b/Documentation/git-rev-parse.txt\n@@ -72,6 +72,14 @@ OPTIONS\n \tpath of the current directory relative to the top-level\n \tdirectory.\n \n+--since=datestring, --after=datestring::\n+\tParses the date string, and outputs corresponding\n+\t--max-age= parameter for git-rev-list command.\n+\n+--until=datestring, --before=datestring::\n+\tParses the date string, and outputs corresponding\n+\t--min-age= parameter for git-rev-list command.\n+\n <args>...::\n \tFlags and parameters to be parsed.\n \n"}]}