{"thread":{"id":"5500","subject":"file rename causes history to disappear","startedAt":"2006-09-06T14:52:43Z","lastAt":"2006-09-07T10:16:11Z","messageCount":16,"participants":["Jeff Garzik","Timo Hirvonen","Linus Torvalds","Jakub Narebski","Junio C Hamano","Randal L. Schwartz","Alex Riesen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"26416","messageId":"44FEE0BB.2060601@garzik.org","threadId":"5500","inReplyTo":null,"subject":"file rename causes history to disappear","fromName":"Jeff Garzik","fromEmail":"jeff@garzik.org","sentAt":"2006-09-06T14:52:43Z","receivedAt":"2006-09-06T14:52:43Z","isPatch":false,"sender":{"key":"jeff@garzik.org","avatar":null},"body":"I moved a bunch of SATA drivers in the Linux kernel from drivers/scsi to \ndrivers/ata.\n\nWhen I tried to look at the past history of a file using \ngit-whatchanged, post-rename, it only shows the history from HEAD to the \npoint of rename. Everything prior to the rename is lost.\n\nI also tried git-whatchanged on the old path, but that produces an error.\n\n[jgarzik@pretzel libata-dev]$ rpm -q git-core\ngit-core-1.4.1-1.fc5\n\nRepository (\"upstream\" branch):\ngit://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git\n"},{"id":"26417","messageId":"20060906180514.698c9cba.tihirvon@gmail.com","threadId":"5500","inReplyTo":"44FEE0BB.2060601@garzik.org","subject":"Re: file rename causes history to disappear","fromName":"Timo Hirvonen","fromEmail":"tihirvon@gmail.com","sentAt":"2006-09-06T15:05:14Z","receivedAt":"2006-09-06T15:05:14Z","isPatch":false,"sender":{"key":"tihirvon@gmail.com","avatar":null},"body":"Jeff Garzik wrote:\n\n> I moved a bunch of SATA drivers in the Linux kernel from drivers/scsi to \n> drivers/ata.\n> \n> When I tried to look at the past history of a file using \n> git-whatchanged, post-rename, it only shows the history from HEAD to the \n> point of rename. Everything prior to the rename is lost.\n> \n> I also tried git-whatchanged on the old path, but that produces an error.\n\nTry \"git log -- old/path/...\". Path limiting works without \"--\" only if\nthe path exists.\n\n-- \nhttp://onion.dynserv.net/~timo/\n"},{"id":"26419","messageId":"Pine.LNX.4.64.0609060834520.27779@g5.osdl.org","threadId":"5500","inReplyTo":"44FEE0BB.2060601@garzik.org","subject":"Re: file rename causes history to disappear","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-06T15:38:40Z","receivedAt":"2006-09-06T15:38:40Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 6 Sep 2006, Jeff Garzik wrote:\n>\n> I moved a bunch of SATA drivers in the Linux kernel from drivers/scsi to\n> drivers/ata.\n> \n> When I tried to look at the past history of a file using git-whatchanged,\n> post-rename, it only shows the history from HEAD to the point of rename.\n> Everything prior to the rename is lost.\n> \n> I also tried git-whatchanged on the old path, but that produces an error.\n\nFor filenames that don't exist right now, you need to clearly separate the \nrevision name from the filename (ie you need to use \"--\").\n\nThere were patches to do \"--follow-rename\" which I don't think got applied \nyet, but in the meantime, just do\n\n\tgit whatchanged -M -- drivers/ata/filename.c drivers/scsi/filename.c\n\nwhere the \"-M\" means \"show diffs as renames if possible\" (which is \ndifferent from having the history actually _follow_ them), and the \"--\" is \nthe filename separator to tell git that the nonexistent \n\"drivers/ata/filename.c\" file isn't a (currently) nonexistent revision \nname, it's a (currently) nonexistent _filename_.\n\n\t\tLinus\n"},{"id":"26420","messageId":"44FEED4B.30909@garzik.org","threadId":"5500","inReplyTo":"Pine.LNX.4.64.0609060834520.27779@g5.osdl.org","subject":"Re: file rename causes history to disappear","fromName":"Jeff Garzik","fromEmail":"jeff@garzik.org","sentAt":"2006-09-06T15:46:19Z","receivedAt":"2006-09-06T15:46:19Z","isPatch":false,"sender":{"key":"jeff@garzik.org","avatar":null},"body":"Linus Torvalds wrote:\n> \n> On Wed, 6 Sep 2006, Jeff Garzik wrote:\n>> I moved a bunch of SATA drivers in the Linux kernel from drivers/scsi to\n>> drivers/ata.\n>>\n>> When I tried to look at the past history of a file using git-whatchanged,\n>> post-rename, it only shows the history from HEAD to the point of rename.\n>> Everything prior to the rename is lost.\n>>\n>> I also tried git-whatchanged on the old path, but that produces an error.\n> \n> For filenames that don't exist right now, you need to clearly separate the \n> revision name from the filename (ie you need to use \"--\").\n> \n> There were patches to do \"--follow-rename\" which I don't think got applied \n> yet, but in the meantime, just do\n> \n> \tgit whatchanged -M -- drivers/ata/filename.c drivers/scsi/filename.c\n> \n> where the \"-M\" means \"show diffs as renames if possible\" (which is \n> different from having the history actually _follow_ them), and the \"--\" is \n> the filename separator to tell git that the nonexistent \n> \"drivers/ata/filename.c\" file isn't a (currently) nonexistent revision \n> name, it's a (currently) nonexistent _filename_.\n\nSince I'm just interested in the log (ATM), even the lack of \"-M\" seems \nto produce useful results. Thanks.\n\nIMO it is highly counter-intuitive that renames are -not- followed. I \ndon't see the point of a \"--follow-rename\", it should Just Work(tm).\n\n\tJeff\n"},{"id":"26423","messageId":"Pine.LNX.4.64.0609060858050.27779@g5.osdl.org","threadId":"5500","inReplyTo":"44FEED4B.30909@garzik.org","subject":"Re: file rename causes history to disappear","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-06T16:14:44Z","receivedAt":"2006-09-06T16:14:44Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 6 Sep 2006, Jeff Garzik wrote:\n> \n> Since I'm just interested in the log (ATM), even the lack of \"-M\" seems to\n> produce useful results. Thanks.\n\nSure, if you don't actually want the diff, the \"-M\" isn't worthwhile.\n\n> IMO it is highly counter-intuitive that renames are -not- followed. I don't\n> see the point of a \"--follow-rename\", it should Just Work(tm).\n\nNo, it should not. \n\nYou haven't thought it through, and I excuse you, because even people who \nshould know better (and design SCM's) often haven't thought it through.\n\nThere's a huge difference between \"pathname\" and \"inode\". And git operates \non _pathnames_, not on inodes. So when you give a pathname specifier, \nthat's _exactly_ what it is. It's a pathname specifier, _not_ an \"inode\" \nspecifier.\n\nAnd pathnames don't change. They're just names for paths to possibly \n_find_ a file/inode. They can't be \"renamed\". The data that is found \nbehind a pathname may be moved to _another_ pathname (and we call that a \nrename), but that doesn't change the original pathname in any way, shape, \nor form.\n\nNow, you can say \"git shouldn't work with pathnames, it should work with \ninodes, and use the pathnames to look them up\", but you'd be wrong. You'd \nbe wrong for many reasons, so let me explain:\n\n - pathnames are actually often a hell of a lot more interesting that \n \"inodes\". Doing thing by pathname means that you have sane and \n well-defined semantics for something like\n\n\tgit log -- drivers/scsi drivers/ata include/linux/ata.h\n\n even if (for example) some of those files or directories don't \n necessarily even exist at one particular point in time. Exactly \n _because_ a pathname is not actually affected by the contents of the \n repository.\n\n So taking a filename-based approach is actually more _powerful_. You \n can emulate the \"follow a single file\" behaviour on top of it, but you \n can't sanely go the other way.\n\n - following inodes/files instead of following pathnames happens to also \n be fundamentally ambiguous when you split or merge the file contents. \n What happens? You simply _cannot_ describe that in the form of \"files\". \n It's impossible. Really. Yet it's actually fairly common.\n\n In contrast, if you think of pathnames of _pathnames_ (rather than the \n contents they point to), that particular sticky wicket simply doesn't \n exist. It's a non-issue. File contents that get split? Big deal. We \n don't care. We care about a particular set of pathnames, and if the \n file content came from (or got split into) that set of pathnames, we \n show it.\n\nSo thinking in terms of pathnames is not only fundamentally more powerful, \nit also very fundamentally avoids a confusing situation that you cannot \navoid with a \"inode\" based model.\n\nYou just need to get used to the fact that the arguments you give to \"git \nlog\" and friends really have _nothing_ to do with any particular \"file\" or \n\"content at any particular time\". They are immutable path specifiers. When \nyou say\n\n\tgit log -- drivers/scsi/libata.c\n\nyou're asking git \"tell me what happened to this _pathname_\". Not file. \nNot content (although if you ask for diffs it will show you the diff, \nbut not for that \"file\", but simple AS IT PERTAINS TO THAT PATHNAME!)\n\nIt may take a bit of getting used to, but once you realize that git talks \nabout immutable pathnames, and once you do get used to it, it's a hell of \na powerful thing.\n\nAnd then we can have \"--follow-renames\" when we are lazy and we \n_understand_ that git talks about pathnames, but we want git to show us \nthe data _as_if_ it cared about how the inodes moved around.\n\n\t\t\tLinus\n"},{"id":"26424","messageId":"Pine.LNX.4.64.0609060922110.27779@g5.osdl.org","threadId":"5500","inReplyTo":"Pine.LNX.4.64.0609060858050.27779@g5.osdl.org","subject":"Re: file rename causes history to disappear","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-06T16:37:56Z","receivedAt":"2006-09-06T16:37:56Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 6 Sep 2006, Linus Torvalds wrote:\n> \n> \tgit log -- drivers/scsi drivers/ata include/linux/ata.h\n> \n> So taking a filename-based approach is actually more _powerful_. You \n> can emulate the \"follow a single file\" behaviour on top of it, but you \n> can't sanely go the other way.\n\nSide note: one thing that I wanted to do, but never got around to, is to \nallow wildcards in the tree-parsing code. It might be too expensive, but \nit's still occasionally something I'd like to do:\n\n\tgit log -- 'mm/*.c'\n\nto track every single C file in the VM (even if they don't exist right \n_now_).\n\nNotice the difference between\n\n\tgit log mm/*.c\n\nand the above idea - the latter does actually work, but it only tracks the \nC files that exist right now under mm/. But it should be possible (and is \npotentially useful) to let the wildcard act over the history, rather than \njust a single point in time.\n\nBecause one additional advantage of thinking in terms of pathnames is \nexactly the fact that wildcards make sense in a way that they do _not_ \nmake sense if you think of tracking \"inodes\". Exactly because \"pathnames \nare forever\", and a pathname has validity and exists regardless of whether \na repository contains a _file_ with that name at any particular point in \ntime.\n\nSo right now git does do the wildcard thing, but only for \"git ls-files\" \n(and through that, things like \"git add\", which used to be implemented in \nterms of ls-files). So you can do\n\n\tgit add '*.c'\n\nto add all C files (recursively - it's not the shell matcher).\n\n\t\t\tLinus\n"},{"id":"26426","messageId":"edmvfv$lt7$2@sea.gmane.org","threadId":"5500","inReplyTo":"Pine.LNX.4.64.0609060858050.27779@g5.osdl.org","subject":"Re: file rename causes history to disappear","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-06T17:11:48Z","receivedAt":"2006-09-06T17:11:48Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> There's a huge difference between \"pathname\" and \"inode\". And git operates \n> on _pathnames_, not on inodes. So when you give a pathname specifier, \n> that's _exactly_ what it is. It's a pathname specifier, _not_ an \"inode\" \n> specifier.\n> \n> And pathnames don't change. They're just names for paths to possibly \n> _find_ a file/inode. They can't be \"renamed\". The data that is found \n> behind a pathname may be moved to _another_ pathname (and we call that a \n> rename), but that doesn't change the original pathname in any way, shape, \n> or form.\n\nSo if/when git would have --follow option to git-log and git-diff-*, it\nwould be rather --follow=, rather than --follow -- ?\n\ngit-rev-list could then output hash with current set of , which\nwere given at the beginning, i.e.\n -- [...]\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"26432","messageId":"Pine.LNX.4.64.0609061131100.27779@g5.osdl.org","threadId":"5500","inReplyTo":"edmvfv$lt7$2@sea.gmane.org","subject":"Re: file rename causes history to disappear","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-06T18:34:37Z","receivedAt":"2006-09-06T18:34:37Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 6 Sep 2006, Jakub Narebski wrote:\n> \n> So if/when git would have --follow option to git-log and git-diff-*, it\n> would be rather --follow=, rather than --follow -- ?\n\nThat would probably be sensible, yes. Especially since \"--follow\" is \nfundamentally different from the \"\" thing in that you really should \nbe able to only follow a single file.\n\n(Following multiple files causes huge amounts of pain - it might be \npossible, but I don't think it's worth it).\n\n> git-rev-list could then output hash with current set of , which\n> were given at the beginning, i.e.\n> -- [...]\n\nI would argue that \"--follow\" would be incompatible with having other \n listed. But maybe there is some sensible rule for what the \ncombination means (show the listed paths _and_ the file we're following?) \nI dunno.\n\n\t\tLinus\n"},{"id":"26434","messageId":"edn5dd$c4s$2@sea.gmane.org","threadId":"5500","inReplyTo":"Pine.LNX.4.64.0609061131100.27779@g5.osdl.org","subject":"Re: file rename causes history to disappear","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-06T18:52:51Z","receivedAt":"2006-09-06T18:52:51Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n>> git-rev-list could then output hash with current set of , which\n>> were given at the beginning, i.e.\n>>   -- [...]\n> \n> I would argue that \"--follow\" would be incompatible with having other \n> listed. But maybe there is some sensible rule for what the \n> combination means (show the listed paths _and_ the file we're following?) \n> I dunno.\n\nI'm not that sure. The output could be changed to, for example\n SP [SP ...]\nalthough I'm not sure if git can detect that two files were joined into one\n(or, in reverse that one file was split into several; this doesn't matter\nfor following history of a file from top)\n\nBut --follow= with can be useful, e.g. when \nis a directory (or, perhaps in the future, glob), which would mean \"follow\nthe contents indicated in starting hash by , and stop following\nwhen it falls out outside given , in our case given directory\".\n\nAs pathspecs doesn't change, there is no need to output them.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"26436","messageId":"Pine.LNX.4.64.0609061205100.27779@g5.osdl.org","threadId":"5500","inReplyTo":"edn5dd$c4s$2@sea.gmane.org","subject":"Re: file rename causes history to disappear","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-06T19:06:06Z","receivedAt":"2006-09-06T19:06:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 6 Sep 2006, Jakub Narebski wrote:\n> \n> But --follow= with can be useful, e.g. when \n> is a directory (or, perhaps in the future, glob), which would mean \"follow\n> the contents indicated in starting hash by , and stop following\n> when it falls out outside given , in our case given directory\".\n\nYes, that would indeed make sense. The pathspec ends up being kept as a \n\"limiter\", and basically tells you what the \"context\" for following is \nallowed to be. \n\nColor me convinced.\n\n\t\tLinus\n"},{"id":"26439","messageId":"edn996$rfb$1@sea.gmane.org","threadId":"5500","inReplyTo":"edn5dd$c4s$2@sea.gmane.org","subject":"Re: file rename causes history to disappear","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-06T19:25:47Z","receivedAt":"2006-09-06T19:25:47Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n\n> Linus Torvalds wrote:\n> \n>>> git-rev-list could then output hash with current set of , which\n>>> were given at the beginning, i.e.\n>>>   -- [...]\n\n> I'm not that sure. The output could be changed to, for example\n> SP [SP ...]\n\nThe \" -- [...]\" was to allow the followed \n to be pathspec for other command, for example \n git-diff-tree --stdin\n(if git-diff-tree accepts pathspec limiting on stdin, and not only\nrevisions, or pairs of revisions; according to 1.4.2 documentation\n--stdin is for reading either one or a pair of \nseparated with a single space from its input -- no pathspecs).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"26438","messageId":"7vmz9c7pzm.fsf@assigned-by-dhcp.cox.net","threadId":"5500","inReplyTo":"Pine.LNX.4.64.0609060922110.27779@g5.osdl.org","subject":"Re: file rename causes history to disappear","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-06T19:29:49Z","receivedAt":"2006-09-06T19:29:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Side note: one thing that I wanted to do, but never got around to, is to \n> allow wildcards in the tree-parsing code. It might be too expensive, but \n> it's still occasionally something I'd like to do:\n>\n> \tgit log -- 'mm/*.c'\n>\n> to track every single C file in the VM (even if they don't exist right \n> _now_).\n\nI am happy to see we are in agreement. I touched this in the\nending note to\n\n\thttp://article.gmane.org/gmane.comp.version-control.git/26432\n\nThe only people who will get burnt by this change are the ones\nwith metacharacters in their pathnames, so it is relative safe\nchange.\n\nI think 'git grep' pathspec code is probably the best to reuse\nto convert diff-tree family. It knows how to match globs while\ntraversing a tree down without descending into a subtree that\nwould never match, which is what we need for them.\n"},{"id":"26447","messageId":"86bqpsvfd3.fsf@blue.stonehenge.com","threadId":"5500","inReplyTo":"7vmz9c7pzm.fsf@assigned-by-dhcp.cox.net","subject":"Re: file rename causes history to disappear","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-09-06T21:45:28Z","receivedAt":"2006-09-06T21:45:28Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Junio\" == Junio C Hamano writes:\n\nJunio> The only people who will get burnt by this change are the ones\nJunio> with metacharacters in their pathnames, so it is relative safe\nJunio> change.\n\nBut does that mean you'll provide the equivalent to \"fgrep\" for \"grep\",\nas in a switch that turns this off, or a seperate command?\n\nI can think of times when I might be trying to track a file with a square\nbracket in the name.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"26455","messageId":"7vpse85z5n.fsf@assigned-by-dhcp.cox.net","threadId":"5500","inReplyTo":"Pine.LNX.4.64.0609061205100.27779@g5.osdl.org","subject":"Re: file rename causes history to disappear","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-06T23:54:44Z","receivedAt":"2006-09-06T23:54:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Wed, 6 Sep 2006, Jakub Narebski wrote:\n>> \n>> But --follow= with can be useful, e.g. when \n>> is a directory (or, perhaps in the future, glob), which would mean \"follow\n>> the contents indicated in starting hash by , and stop following\n>> when it falls out outside given , in our case given directory\".\n>\n> Yes, that would indeed make sense. The pathspec ends up being kept as a \n> \"limiter\", and basically tells you what the \"context\" for following is \n> allowed to be. \n>\n> Color me convinced.\n\nLikewise.\n"},{"id":"26466","messageId":"7vbqps5wgp.fsf@assigned-by-dhcp.cox.net","threadId":"5500","inReplyTo":"86bqpsvfd3.fsf@blue.stonehenge.com","subject":"Re: file rename causes history to disappear","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-07T00:52:54Z","receivedAt":"2006-09-07T00:52:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n>>>>>> \"Junio\" == Junio C Hamano writes:\n>\n> Junio> The only people who will get burnt by this change are the ones\n> Junio> with metacharacters in their pathnames, so it is relative safe\n> Junio> change.\n>\n> But does that mean you'll provide the equivalent to \"fgrep\" for \"grep\",\n> as in a switch that turns this off, or a seperate command?\n>\n> I can think of times when I might be trying to track a file with a square\n> bracket in the name.\n\nIf your path is \"foo.c[1]\" then \"foo.c[1]\" as fnmatch() pattern\nwould not obviously match it, which is sad.\n\nHowever, we do try to match the path literally before falling\nback to fnmatch() so in practice I do not think it is so bad.\n\n$ git ls-files -s ;# everybody has \"hello world\".\n100644 3b18e512dba79e4c8300dd08aeb37f8e728b8dad 0\tfoo.c\n100644 3b18e512dba79e4c8300dd08aeb37f8e728b8dad 0\tfoo/bar[1]/baz/boa.c\n100644 3b18e512dba79e4c8300dd08aeb37f8e728b8dad 0\tfoo/bar[2].c\n$ git grep hello -- 'foo/bar[1]'\nfoo/bar[1]/baz/boa.c:hello world\n$ git grep hello -- 'foo/bar[[]*[]]*'\nfoo/bar[1]/baz/boa.c:hello world\nfoo/bar[2].c:hello world\n$ git grep hello -- 'fo*'\nfoo.c:hello world\nfoo/bar[1]/baz/boa.c:hello world\nfoo/bar[2].c:hello world\n$ exit\n"},{"id":"26509","messageId":"20060907101611.GA15981@steel.home","threadId":"5500","inReplyTo":"7vmz9c7pzm.fsf@assigned-by-dhcp.cox.net","subject":"Re: file rename causes history to disappear","fromName":"Alex Riesen","fromEmail":"fork0@t-online.de","sentAt":"2006-09-07T10:16:11Z","receivedAt":"2006-09-07T10:16:11Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Junio C Hamano, Wed, Sep 06, 2006 21:29:49 +0200:\n> The only people who will get burnt by this change are the ones\n> with metacharacters in their pathnames, so it is relative safe\n> change.\n\nMay be make metacharacters the default behaviour, but provide a\ncommand-line option to disable it? It'll be seldom used, but would\nprovide a way to disambiguate input for scripts and make possible\n(even if a bit harder) to use such filenames.\n"}]}