{"thread":{"id":"34720","subject":"Does Git now have any C struct version history tracking mechanism?","startedAt":"2013-08-18T10:33:12Z","lastAt":"2013-08-20T03:55:17Z","messageCount":4,"participants":["Zhan Jianyu","Nazri Ramliy","Thomas Rast"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"225387","messageId":"CAHz2CGW_xR4Q193h2itCELdXEpoAxetj324ATstALHM03cSvFg@mail.gmail.com","threadId":"34720","inReplyTo":null,"subject":"Does Git now have any C struct version history tracking mechanism?","fromName":"Zhan Jianyu","fromEmail":"nasa4836@gmail.com","sentAt":"2013-08-18T10:33:12Z","receivedAt":"2013-08-18T10:33:12Z","isPatch":false,"sender":{"key":"nasa4836@gmail.com","avatar":"https://gravatar.com/avatar/f80b0399c04c6ca4b482c60a910f81c921a5aee6100120b1f6cee1da591fa181?d=mp&s=160"},"body":"Hi, all.\n\n* Background\n\n  Such a requirement came into my mind when I am tracking a gloomy C\nstruct , with lengthy list of elements which are either elaborated or\nopaque. So I use git blame to track it down and found that its\noriginal version is quite simple and intuitive. So I think I could\njust slice out every snapshot of this struct, reading every changelog\n, to get a better knowledge of what it is and why it should be like\nthis.\n\nIt seems quite helpful but the process is quite cumbersome. So I\nwonder if there is already some mechanism fulfilling my requirement in\nGit.  If it doesn't,  would it be worthy adding one ?\n\nThanks\n\n\n\n\n--\n\nRegards,\nZhan Jianyu\n"},{"id":"225442","messageId":"CAEY4ZpO3x-B7SKQa+Djtt_AfQ7y=nNBZ1sR9Gvv8d3FvQLK1PA@mail.gmail.com","threadId":"34720","inReplyTo":"CAHz2CGW_xR4Q193h2itCELdXEpoAxetj324ATstALHM03cSvFg@mail.gmail.com","subject":"Re: Does Git now have any C struct version history tracking mechanism?","fromName":"Nazri Ramliy","fromEmail":"ayiehere@gmail.com","sentAt":"2013-08-19T05:54:08Z","receivedAt":"2013-08-19T05:54:08Z","isPatch":false,"sender":{"key":"ayiehere@gmail.com","avatar":"https://avatars.githubusercontent.com/u/164756?v=4"},"body":"On Sun, Aug 18, 2013 at 6:33 PM, Zhan Jianyu <nasa4836@gmail.com> wrote:\n>   Such a requirement came into my mind when I am tracking a gloomy C\n> struct , with lengthy list of elements which are either elaborated or\n> opaque. So I use git blame to track it down and found that its\n> original version is quite simple and intuitive. So I think I could\n> just slice out every snapshot of this struct, reading every changelog\n> , to get a better knowledge of what it is and why it should be like\n> this.\n>\n> It seems quite helpful but the process is quite cumbersome. So I\n> wonder if there is already some mechanism fulfilling my requirement in\n> Git.  If it doesn't,  would it be worthy adding one ?\n\nIt's already merged to git.git's master quite recently in\ned73fe56428eecd2b635473f6a517a183c4713a3 (back in June).\n\nYou'd invoke git log like this:\n\n    $ git log -L :struct_or_function_name:filename.c\n\nand it will show you the commits and the specific hunks that affect\nthe struct or function name.\n\nIt's still a bit rough on the edges, for example, doing the following\nin git.git:\n\n    $ git log -L :rev_cmdline_info:revision.h\n\nShows three commits (a765499, ca92e59 and 281eee4) where the second\none does not touch the struct at all (if you do \"git show ca92e59\" you\nmight gain an insight as to how -L works).\n\nBut that is not to say that it's not good. The gain really shadows the\nroughness.\n\nnazri\n"},{"id":"225454","messageId":"87y57y84a1.fsf@linux-k42r.v.cablecom.net","threadId":"34720","inReplyTo":"CAEY4ZpO3x-B7SKQa+Djtt_AfQ7y=nNBZ1sR9Gvv8d3FvQLK1PA@mail.gmail.com","subject":"Re: Does Git now have any C struct version history tracking mechanism?","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-08-19T08:37:42Z","receivedAt":"2013-08-19T08:37:42Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Nazri Ramliy <ayiehere@gmail.com> writes:\n\n> On Sun, Aug 18, 2013 at 6:33 PM, Zhan Jianyu <nasa4836@gmail.com> wrote:\n>>   Such a requirement came into my mind when I am tracking a gloomy C\n>> struct , with lengthy list of elements which are either elaborated or\n>> opaque. So I use git blame to track it down and found that its\n>> original version is quite simple and intuitive. So I think I could\n>> just slice out every snapshot of this struct, reading every changelog\n>> , to get a better knowledge of what it is and why it should be like\n>> this.\n>>\n>> It seems quite helpful but the process is quite cumbersome. So I\n>> wonder if there is already some mechanism fulfilling my requirement in\n>> Git.  If it doesn't,  would it be worthy adding one ?\n>\n> It's already merged to git.git's master quite recently in\n> ed73fe56428eecd2b635473f6a517a183c4713a3 (back in June).\n>\n> You'd invoke git log like this:\n>\n>     $ git log -L :struct_or_function_name:filename.c\n>\n> and it will show you the commits and the specific hunks that affect\n> the struct or function name.\n>\n> It's still a bit rough on the edges, for example, doing the following\n> in git.git:\n>\n>     $ git log -L :rev_cmdline_info:revision.h\n>\n> Shows three commits (a765499, ca92e59 and 281eee4) where the second\n> one does not touch the struct at all (if you do \"git show ca92e59\" you\n> might gain an insight as to how -L works).\n\nHmm, IIUC that's actually not a bug or even a roughness; it's an\nartifact of how the :pattern:file syntax is defined.  It takes the first\n_funcname line_ matching 'pattern', up to (but excluding) the next\nfuncname line.\n\nThe default funcname rule (in the absence of any patterns) does not\nmatch '#define...' on account of the '#'.  The default funcname pattern\nfor 'cpp' (if you manually configured your git.git repo to set this\nattribute; it doesn't by default) never matches a leading '#´ either.\nSo it's no surprise that the tracked range extends a few more lines\nafter the struct.\n\nOr is there an issue that I'm missing?\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"225493","messageId":"CAEY4ZpM6U38piim_uY5KgaZX=1KkYF4WaMxR9HeywAp4AO9igw@mail.gmail.com","threadId":"34720","inReplyTo":"87y57y84a1.fsf@linux-k42r.v.cablecom.net","subject":"Re: Does Git now have any C struct version history tracking mechanism?","fromName":"Nazri Ramliy","fromEmail":"ayiehere@gmail.com","sentAt":"2013-08-20T03:55:17Z","receivedAt":"2013-08-20T03:55:17Z","isPatch":false,"sender":{"key":"ayiehere@gmail.com","avatar":"https://avatars.githubusercontent.com/u/164756?v=4"},"body":"On Mon, Aug 19, 2013 at 4:37 PM, Thomas Rast <trast@inf.ethz.ch> wrote:\n> Hmm, IIUC that's actually not a bug or even a roughness; it's an\n> artifact of how the :pattern:file syntax is defined.  It takes the first\n> _funcname line_ matching 'pattern', up to (but excluding) the next\n> funcname line.\n>\n...\n> Or is there an issue that I'm missing?\n\nNo you're correct. I should have used the following instead for the demo:\n\n    $ git log -L /struct\\ rev_cmdline_info/,/^}/:revision.h\n\nMoral: You'd hit your target better if you work on your aim.\n\nnazri\n"}]}