{"thread":{"id":"335","subject":"(unknown)","startedAt":"2005-04-26T19:14:34Z","lastAt":"2005-04-26T19:14:34Z","messageCount":1,"participants":["Bram Cohen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"1778","messageId":"Pine.LNX.4.44.0504261159180.4678-100000@wax.eds.org","threadId":"335","inReplyTo":null,"subject":"(unknown)","fromName":"Bram Cohen","fromEmail":"bram@bitconjurer.org","sentAt":"2005-04-26T19:14:34Z","receivedAt":"2005-04-26T19:14:34Z","isPatch":false,"sender":{"key":"bram@bitconjurer.org","avatar":null},"body":"Linus Torvalds wrote:\n> What you can do at an SCM level, is that if you want to track renames,\n> you track them as a separate commit altogether. Ie if you notice a\n> rename, you first commit the rename (and you can _see_ it's a rename,\n> since the object didn't change, and the sha1 stayed the same, which in\n> git-speak means that it is the same object, ie that _is_ a rename as far\n> as git is concerned), and then you create the \"this is the data that\n> changed\" as a _second_ commit.\n\nIf a rename and a modification happen at the same time, you'll now have a\npoint in the history which has the modification but not the rename, which\nwill probably be completely broken. If a file is deleted and two identical\ncopies of the file are made at the same time, no inference of renaming can\nbe made. And sometimes people really do delete one file and make a new\ndifferent file with initially identical contents, and this will break that\ncase.\n\n> But don't make it a new kind of commit. It's just a regular commit,\n> dammit. No new abstractions.\n\nYou did just introduce a new abstraction, it just happens to be of the 'if\nI say X I really mean Y' type, which is far more semantically weighty,\ntricky to implement, and on top of that is just plain a gross hack.\n\n> Some \"higher level\" thing can add its own rules _on_top_ of git rules.\n> The same way we have normal applications having their _own_ rules on top\n> of the kernel. You do abstraction in layers, but for this to work, the\n> base you build on top of had better be damn solid, and not have any ugly\n> special cases.\n\nWhat you're advocating is unclear here, but if you're advocating that the\nhigher-level system store extra meta-data, not included in git, then that\nmeans the higher-level tools won't be able to interoperate by pointing at\nthe same git store. And it won't get rid of the problems of storing\ninformation which git doesn't currently, it just makes them be handled by\ndifferent code. You can't make these problems go away by getting angry at\nthem.\n\nI for one am all in favor of blessing Cogito as the 'real' git interface,\nwith plans to write upgrade scripts which canonically change the current\ngit format into a new format when upgrades become necessary. There are\nalready several version control systems with appropriate back end systems\nwhich aren't literally weekend hacks. But you currently seem to be\ninsisting that such an upgrade will never be necessary, even while\ninsisting that git will support functionality which it can't.\n\n-Bram\n\n"}]}