{"thread":{"id":"4142","subject":"RE: how to display file history?","startedAt":"2006-05-15T06:13:30Z","lastAt":"2006-05-21T17:35:49Z","messageCount":12,"participants":["Brown, Len","Junio C Hamano","Eric W. Biederman","Linus Torvalds","Marco Costalba","J. Bruce Fields","Jonas Fonseca"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"19971","messageId":"CFF307C98FEABE47A452B27C06B85BB670F4FD@hdsmsx411.amr.corp.intel.com","threadId":"4142","inReplyTo":null,"subject":"RE: how to display file history?","fromName":"Brown, Len","fromEmail":"len.brown@intel.com","sentAt":"2006-05-15T06:13:30Z","receivedAt":"2006-05-15T06:13:30Z","isPatch":false,"sender":{"key":"len.brown@intel.com","avatar":"https://gravatar.com/avatar/a091f34f66caadb51d85a8a496800c6ccae73737e2f45762373e6b8c55fa5dd6?d=mp&s=160"},"body":" \n>\tgit whatchanged A\n\nthanks.  I've used this on entire repos before, but\nfor some reason didn't think of this command name\nwhen looking for individual file history.\n\nSearching git(7) for \"history\" didn't take me here.\nSearching for \"log\" would have, but I must have\nterminated that search when git-log and git-shortlog\nturned out to not be what I was looking for.\n\n-Len\n"},{"id":"19974","messageId":"7v64k7wzzf.fsf@assigned-by-dhcp.cox.net","threadId":"4142","inReplyTo":"CFF307C98FEABE47A452B27C06B85BB670F4FD@hdsmsx411.amr.corp.intel.com","subject":"Re: how to display file history?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-15T06:42:28Z","receivedAt":"2006-05-15T06:42:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Brown, Len\" <len.brown@intel.com> writes:\n\n>  \n>>\tgit whatchanged A\n>\n> thanks.  I've used this on entire repos before, but\n> for some reason didn't think of this command name\n> when looking for individual file history.\n\nProbably with recent enough git, one of\n\n\tgit log --stat -- A\n\tgit log -p -- A\n\tgit log -p --full-diff -- A\n\nmight be more pleasant, depending on what you are trying to look\nfor.\n\n\"A\" can be a single file, more than one files, a directory,...\n"},{"id":"20003","messageId":"m1ejyv7077.fsf@ebiederm.dsl.xmission.com","threadId":"4142","inReplyTo":"7v64k7wzzf.fsf@assigned-by-dhcp.cox.net","subject":"Re: how to display file history?","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2006-05-15T15:54:36Z","receivedAt":"2006-05-15T15:54:36Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> \"Brown, Len\" <len.brown@intel.com> writes:\n>\n>>  \n>>>\tgit whatchanged A\n>>\n>> thanks.  I've used this on entire repos before, but\n>> for some reason didn't think of this command name\n>> when looking for individual file history.\n>\n> Probably with recent enough git, one of\n>\n> \tgit log --stat -- A\n> \tgit log -p -- A\n> \tgit log -p --full-diff -- A\n>\n> might be more pleasant, depending on what you are trying to look\n> for.\n>\n> \"A\" can be a single file, more than one files, a directory,...\n\nSo that it has a chance of being remembered, and eventually fixed\nthe man pages of git-whatchanged and git-log only sort of tell you\nthat this is even possible.  git-whatchanged is certainly worse,\nbut I don't think if I didn't know to look for it I could see the\nfact that these commands take path names from looking at their\nman pages.\n\nEric\n"},{"id":"20007","messageId":"Pine.LNX.4.64.0605150900510.3866@g5.osdl.org","threadId":"4142","inReplyTo":"m1ejyv7077.fsf@ebiederm.dsl.xmission.com","subject":"Re: how to display file history?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-15T16:15:00Z","receivedAt":"2006-05-15T16:15:00Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 15 May 2006, Eric W. Biederman wrote:\n> \n> So that it has a chance of being remembered, and eventually fixed\n> the man pages of git-whatchanged and git-log only sort of tell you\n> that this is even possible.\n\nI don't think this is a man-page issue. I think this is a very basic \ntutorial issue. \n\nPeople still don't seem to realize how flexible (and powerful) the git \nrevision specifications are. It's not just limiting by path, all of these \nwork on _all_ of the \"history tools\" (whether they be gitk, qgit, \"git \nlog\", \"git whatchanged\" or your own home-cooked stuff):\n\n - \"revision based limiting\"\n\n\t\"a..b\", but also \"a ^b ^c ^d\" or \"a --not b c d\" for the more \n\tcomplex case where you're interested in one (or more) commit, but \n\tnot anything that flows from any of a number of other commits.\n\n\t\"--all\".\n\n - \"commit date based limiting\"\n\n\t\"--since=2.weeks.ago\" \"--since=aug.5th\"\n\n - \"limit by number of hits\"\n\n\t\"-15\"\n\n - \"limit by type or state\"\n\n\t\"--no-merges\" and \"--unpacked\"\n\nAnd finally\n\n - \"limit by pathname\"\n\nand you can combine all of these.\n\nSo\n\n\tgitk --all --since=1.month -15 -- t/\n\nwill show at most fifteen commits from _any_ branch that changed the \ntest subdirectory in the last month.\n\nAnd yeah, maybe that isn't a very interesting query, but it's easy to \nexplain and understand, so it's worth explaining early.\n\nAnd it should be equally obvious to everybody that if it works for \"gitk\", \nthat means that it works for \"qgit\", \"git log\" and \"git whatchanged\" too, \nie this is a very core concept, and not just some tacked-on thing for one \nspecial tool.\n\n\t\t\tLinus\n"},{"id":"20009","messageId":"m164k76ylb.fsf@ebiederm.dsl.xmission.com","threadId":"4142","inReplyTo":"Pine.LNX.4.64.0605150900510.3866@g5.osdl.org","subject":"Re: how to display file history?","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2006-05-15T16:29:20Z","receivedAt":"2006-05-15T16:29:20Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> On Mon, 15 May 2006, Eric W. Biederman wrote:\n>> \n>> So that it has a chance of being remembered, and eventually fixed\n>> the man pages of git-whatchanged and git-log only sort of tell you\n>> that this is even possible.\n>\n> I don't think this is a man-page issue. I think this is a very basic \n> tutorial issue. \n>\n> People still don't seem to realize how flexible (and powerful) the git \n> revision specifications are. It's not just limiting by path, all of these \n> work on _all_ of the \"history tools\" (whether they be gitk, qgit, \"git \n> log\", \"git whatchanged\" or your own home-cooked stuff):\n>\n>  - \"revision based limiting\"\n>\n> \t\"a..b\", but also \"a ^b ^c ^d\" or \"a --not b c d\" for the more \n> \tcomplex case where you're interested in one (or more) commit, but \n> \tnot anything that flows from any of a number of other commits.\n>\n> \t\"--all\".\n>\n>  - \"commit date based limiting\"\n>\n> \t\"--since=2.weeks.ago\" \"--since=aug.5th\"\n>\n>  - \"limit by number of hits\"\n>\n> \t\"-15\"\n>\n>  - \"limit by type or state\"\n>\n> \t\"--no-merges\" and \"--unpacked\"\n>\n> And finally\n>\n>  - \"limit by pathname\"\n>\n> and you can combine all of these.\n>\n> So\n>\n> \tgitk --all --since=1.month -15 -- t/\n>\n> will show at most fifteen commits from _any_ branch that changed the \n> test subdirectory in the last month.\n>\n> And yeah, maybe that isn't a very interesting query, but it's easy to \n> explain and understand, so it's worth explaining early.\n>\n> And it should be equally obvious to everybody that if it works for \"gitk\", \n> that means that it works for \"qgit\", \"git log\" and \"git whatchanged\" too, \n> ie this is a very core concept, and not just some tacked-on thing for one \n> special tool.\n\nSure.  If it gets included in a tutorial is great, but existing\nusers aren't likely to read through a tutorial if they think they\nknow what is going on.\n\nHaving it documented in the man pages (i.e. the reference\ndocumentation) which is where people look to check up on the fine\npoints of a command is more likely to matter.  Plus it doesn't\ntake any creativity to write a man page you just need to describe\nwhat is, which makes man-pages easier to write than documentation\nwhere you aren't certain of who your audience is.\n\nSince it isn't specific to one command we probably need to document\nthe query limiting in a single file like the diff options are\nand then just included it in all of the different man pages.\n\nBut regardless of where we put it, it needs to be documented someplace\nbesides in the email so you don't need to read the code to see that\nthe option is there. \n\nEric\n"},{"id":"20010","messageId":"Pine.LNX.4.64.0605150944200.3866@g5.osdl.org","threadId":"4142","inReplyTo":"m164k76ylb.fsf@ebiederm.dsl.xmission.com","subject":"Re: how to display file history?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-15T16:45:30Z","receivedAt":"2006-05-15T16:45:30Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 15 May 2006, Eric W. Biederman wrote:\n>\n> Having it documented in the man pages (i.e. the reference\n> documentation) which is where people look to check up on the fine\n> points of a command is more likely to matter.\n\nSomehow I really doubt that.\n\nCheck out the current man-page for \"git log\" or \"git whatchanged\".\n\nIn particular, check the \"examples\" section.\n\nYes, it's right there. And no, people apparently don't read the man-pages.\n\n\t\tLinus\n"},{"id":"20012","messageId":"e5bfff550605151022m7b9ddcd9y53cd745e16ff6b22@mail.gmail.com","threadId":"4142","inReplyTo":"Pine.LNX.4.64.0605150900510.3866@g5.osdl.org","subject":"Re: how to display file history?","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-05-15T17:22:01Z","receivedAt":"2006-05-15T17:22:01Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":">\n> So\n>\n>         gitk --all --since=1.month -15 -- t/\n>\n> will show at most fifteen commits from _any_ branch that changed the\n> test subdirectory in the last month.\n>\n> And yeah, maybe that isn't a very interesting query, but it's easy to\n> explain and understand, so it's worth explaining early.\n>\n> And it should be equally obvious to everybody that if it works for \"gitk\",\n> that means that it works for \"qgit\", \"git log\" and \"git whatchanged\" too,\n\nFor qgit it doesn't work :-)\n\nWell, it works but the nice boundary circles are not shown, and qgit\nalways adds  --boundary to command line args to feed git-rev-list, but\nin this case it seems the --boundary option didn't do his job.\n\n$git-rev-list --topo-order --boundary --parents --all --since=1.month -15 -- t/\nea892b27b15fbc46a3bb3ad2ddce737dc6590ae5\nb0121fb3f279a9cf13aff9da060e742aef3a83fa\n8d48ad62a902556b523ee892a3fbe4206d576d3f\n8d48ad62a902556b523ee892a3fbe4206d576d3f\n2c49009dbe98a26505891d3c680da73baf0b4f81\nd14f776402d9f7040cc71ff6e3b992b2e019526a\nb0121fb3f279a9cf13aff9da060e742aef3a83fa\n7f498065e9bf85f6f3e954ec57dedf56fec29e01\n6bd20358a9b831b3b545284188871bc844245c25\n6bd20358a9b831b3b545284188871bc844245c25\n9af0b8dbe2fb252262412a11254e2bcc6ffb87bb\n7f498065e9bf85f6f3e954ec57dedf56fec29e01\nc2b9e6994d044b218e59abf6d19f7751c4aa13e3\ndd05ea1799656024a45017238bbd4857b5256370\nc2b9e6994d044b218e59abf6d19f7751c4aa13e3\naadc81c13bbb103e7db759ba9a98a6f9509831f1\nbd886fd3ea49b726493255d4adf5d20b31681713\naadc81c13bbb103e7db759ba9a98a6f9509831f1\n42d0ee8302c361a0e3bde7bc59858eda94bc13a4\n22293b9c41778bb60f3b07355e1b8e421a503702\n2c49009dbe98a26505891d3c680da73baf0b4f81\n143f4d94c6e2188a6bedfdfa268e66b579e3fbf9\ndd05ea1799656024a45017238bbd4857b5256370\ndd05ea1799656024a45017238bbd4857b5256370\nfd60acaced6de16ebfb66959067e2b29f99a133e\n143f4d94c6e2188a6bedfdfa268e66b579e3fbf9\n2fc240a7b21c060529c1d2e19d6b483361f81f2a\n22293b9c41778bb60f3b07355e1b8e421a503702\n22293b9c41778bb60f3b07355e1b8e421a503702\n83e77a25dc194933c0fb7908ab6d9fb84a5045e2\n83e77a25dc194933c0fb7908ab6d9fb84a5045e2\n2fa9a0fb31cbf01e8318a02c3e222d7fd3fd0a83\n2fc240a7b21c060529c1d2e19d6b483361f81f2a\nfd60acaced6de16ebfb66959067e2b29f99a133e\n42d0ee8302c361a0e3bde7bc59858eda94bc13a4\n42d0ee8302c361a0e3bde7bc59858eda94bc13a4\n2fa9a0fb31cbf01e8318a02c3e222d7fd3fd0a83\nfd60acaced6de16ebfb66959067e2b29f99a133e\nbd886fd3ea49b726493255d4adf5d20b31681713\ncf9dc65368113caa28f2829e2ada5477fbb031ec\n\n\n       Marco\n"},{"id":"20017","messageId":"20060515175549.GD15165@fieldses.org","threadId":"4142","inReplyTo":"m164k76ylb.fsf@ebiederm.dsl.xmission.com","subject":"Re: how to display file history?","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2006-05-15T17:55:49Z","receivedAt":"2006-05-15T17:55:49Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Mon, May 15, 2006 at 10:29:20AM -0600, Eric W. Biederman wrote:\n> Sure.  If it gets included in a tutorial is great, but existing\n> users aren't likely to read through a tutorial if they think they\n> know what is going on.\n> \n> Having it documented in the man pages (i.e. the reference\n> documentation) which is where people look to check up on the fine\n> points of a command is more likely to matter.\n\nLooks like the current git-log man page refers you to the git-rev-list\npage for that, and the use of path names is documented there.\n\nI think that's a pretty reasonable approach for reference\ndocumentation, which should be concise.  Duplicating the git-rev-list\ndocumentation (even some of it) to every man page to which it's relevant\nwould add a lot of text.\n\nThe current git-log man page is misleading, though--it suggests that\ngit-log accepts (and git-rev-list documents) only options, which might\ndiscourage a reader from tracking down information about non-option\narguments.\n\nI also agree about the tutorial--the \"Keeping track of history\" section\nwould be a good place to introduce this and git-grep with some fun\nexamples.  It's on my todo list, but may take a while, so maybe someone\nelse can beat me to it....\n\n--b.\n"},{"id":"20018","messageId":"Pine.LNX.4.64.0605151055080.3866@g5.osdl.org","threadId":"4142","inReplyTo":"e5bfff550605151022m7b9ddcd9y53cd745e16ff6b22@mail.gmail.com","subject":"Re: how to display file history?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-15T18:03:51Z","receivedAt":"2006-05-15T18:03:51Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 15 May 2006, Marco Costalba wrote:\n> \n> Well, it works but the nice boundary circles are not shown, and qgit\n> always adds  --boundary to command line args to feed git-rev-list, but\n> in this case it seems the --boundary option didn't do his job.\n\nWell, it did do it's job, but you expected different counting priorities \nthan git-rev-list actually gives you.\n\nFor the \"limit by number\" case, the commit counting counts _both_ \n\"primary\" commits and \"boundary\" commits, and will limit the total output \nto the number specified.\n\nqgit would seem to prefer to have the commit counting only affect the \n\"primary\" commits, and not the \"boundary\" ones at all. Which might be \nsensible, but it's not the semantics it has now.\n\ngitk doesn't care, because it uses the boundary commits just as hints.\n\nI _think_ gitk is correct here, and qgit is being too strict in its \nsemantic understanding of what the boundary commits mean. But I think so \nmostly because it would actually be pretty hard to do otherwise (ie the \ngit-rev-list commit counting is largely defined by it's _implementation_, \nnot necessarily by what you want it to do ;)\n\n\t\tLinus\n"},{"id":"20020","messageId":"e5bfff550605151132s4605a241sd3132aaeb2de6a39@mail.gmail.com","threadId":"4142","inReplyTo":"Pine.LNX.4.64.0605151055080.3866@g5.osdl.org","subject":"Re: how to display file history?","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-05-15T18:32:39Z","receivedAt":"2006-05-15T18:32:39Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 5/15/06, Linus Torvalds <torvalds@osdl.org> wrote:\n>\n>\n> qgit would seem to prefer to have the commit counting only affect the\n> \"primary\" commits, and not the \"boundary\" ones at all. Which might be\n> sensible, but it's not the semantics it has now.\n>\n> gitk doesn't care, because it uses the boundary commits just as hints.\n>\n\n$ git-rev-list --topo-order --after=\"Apr 10\" --before=\"Apr 11\" HEAD |wc\n     14      14     574\n$ git-rev-list --topo-order --boundary --after=\"Apr 10\" --before=\"Apr\n11\" HEAD |wc\n     18      18     742\n\nBoundary revisions in this case are _not_ passed through search\nfiltering. Using --boundary option we get revisions ouside given\nfilter range.\n\nThis does not apply to our previous example. So at least --boundary\nbehaviour it's a little bit inconsistent at the moment.\n\n        Marco\n"},{"id":"20021","messageId":"Pine.LNX.4.64.0605151149460.3866@g5.osdl.org","threadId":"4142","inReplyTo":"e5bfff550605151132s4605a241sd3132aaeb2de6a39@mail.gmail.com","subject":"Re: how to display file history?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-15T18:51:53Z","receivedAt":"2006-05-15T18:51:53Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 15 May 2006, Marco Costalba wrote:\n> \n> $ git-rev-list --topo-order --after=\"Apr 10\" --before=\"Apr 11\" HEAD |wc\n>     14      14     574\n> $ git-rev-list --topo-order --boundary --after=\"Apr 10\" --before=\"Apr\n> 11\" HEAD |wc\n>     18      18     742\n> \n> Boundary revisions in this case are _not_ passed through search\n> filtering. Using --boundary option we get revisions ouside given\n> filter range.\n\nRight. And the commit counting is a special filter, and \"boundary\" is \nspecial in that it doesn't normally honor some other filters (it _does_ \nhonor path-based ones, though, I think).\n\nSo you really should see \"--boundary\" as a heuristic, and as a hack to \nhelp you close the loop on uninteresting commits _faster_. But if \nsomething else has closed it for other reasons, you shouldn't depend on \nit.\n\n\t\tLinus\n"},{"id":"20398","messageId":"20060521173549.GA23347@diku.dk","threadId":"4142","inReplyTo":"m164k76ylb.fsf@ebiederm.dsl.xmission.com","subject":"Re: how to display file history?","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2006-05-21T17:35:49Z","receivedAt":"2006-05-21T17:35:49Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"Eric W. Biederman <ebiederm@xmission.com> wrote Mon, May 15, 2006:\n> Linus Torvalds <torvalds@osdl.org> writes:\n> \n> > On Mon, 15 May 2006, Eric W. Biederman wrote:\n> > People still don't seem to realize how flexible (and powerful) the git \n> > revision specifications are. It's not just limiting by path, all of these \n> > work on _all_ of the \"history tools\" (whether they be gitk, qgit, \"git \n> > log\", \"git whatchanged\" or your own home-cooked stuff):\n> >\n> > [examples]\n> \n> But regardless of where we put it, it needs to be documented someplace\n> besides in the email so you don't need to read the code to see that\n> the option is there. \n\nI've put some of this on http://git.or.cz/gitwiki/RevisionSpecification\nthat for now may serve as an introduction ...\n\n-- \nJonas Fonseca\n"}]}