{"thread":{"id":"17","subject":"Handling renames.","startedAt":"2005-04-14T17:54:20Z","lastAt":"2005-04-14T23:17:36Z","messageCount":20,"participants":["David Woodhouse","Linus Torvalds","Ingo Molnar","H. Peter Anvin","David Mansfield","Zach Welch","Andrew Timberlake-Newell","Steven Cole","Petr Baudis","Daniel Barkalow","Peter Williams"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"96","messageId":"1113501260.27227.26.camel@hades.cambridge.redhat.com","threadId":"17","inReplyTo":null,"subject":"Handling renames.","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2005-04-14T17:54:20Z","receivedAt":"2005-04-14T17:54:20Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"I've been looking at tracking file revisions. One proposed solution was\nto have a separate revision history for individual files, with a new\nkind of 'filecommit' object which parallels the existing 'commit',\nreferencing a blob instead of a tree. Then trees would reference such\nobjects instead of referencing blobs directly.\n\nI think that introduces a lot of redundancy though, because 99% of the\ntime, the revision history of the individual file is entirely\nreproducible from the revision history of the tree. It's only when files\nare renamed that we fall over -- and I think we can handle renames\nfairly well if we just log them in the commit object. \n\nMy 'gitfilelog.sh' script is already capable of tracking a given file\nback through multiple tree commits, listing those commits where the file\nin question was actually changed. It uses my patched version of diff-\ntree which supports 'diff-tree ' in order to\ndo this.\n\nBy storing rename information in the commit object, the script (or a\nreimplementation of a similar algorithm) could know when to change the\nfilename it's looking for, as it goes back through the tree. That ought\nto be perfectly sufficient.\n\nSo a commit involving a rename would look something like this...\n\n\ttree 82ba574c85e9a2e4652419c88244e9dd1bfa8baa\n\tparent bb95843a5a0f397270819462812735ee29796fb4\n\trename foo.c bar.c\n\tauthor David Woodhouse 1113499881 +0100\n\tcommitter David Woodhouse 1113499881 +0100\n\tRename foo.c to bar.c and s/foo_/bar_/g\n\nOpinions? Dissent? We'd probably need to escape the filenames in some\nway -- handwave over that for now.\n\n-- \ndwmw2\n\n"},{"id":"97","messageId":"Pine.LNX.4.58.0504141102430.7211@ppc970.osdl.org","threadId":"17","inReplyTo":"1113501260.27227.26.camel@hades.cambridge.redhat.com","subject":"Re: Handling renames.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-14T18:11:53Z","receivedAt":"2005-04-14T18:11:53Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 14 Apr 2005, David Woodhouse wrote:\n>\n> I've been looking at tracking file revisions. One proposed solution was\n> to have a separate revision history for individual files, with a new\n> kind of 'filecommit' object which parallels the existing 'commit',\n> referencing a blob instead of a tree. Then trees would reference such\n> objects instead of referencing blobs directly.\n\nPlease don't. It's fundamentally the git notion of \"content determines\nobjects\".\n\nIt also has no relevance. A \"rename\" really doesn't exist in the git \nmodel. The git model really is about tracking data, not about tracking \nwhat happened to _create_ that data.\n\nThe one exception is the commit log. That's where you put the explanations \nof _why_ the data changed. And git itself doesn't care what the format is, \napart from the git header.\n\nSo, you really need to think of git as a filesystem. You can then \nimplement an SCM _on_top_of_it_, which means that your second suggestion \nis not only acceptable, it really is the _only_ way to handle this in git:\n\n> So a commit involving a rename would look something like this...\n> \n> \ttree 82ba574c85e9a2e4652419c88244e9dd1bfa8baa\n> \tparent bb95843a5a0f397270819462812735ee29796fb4\n> \trename foo.c bar.c\n> \tauthor David Woodhouse 1113499881 +0100\n> \tcommitter David Woodhouse 1113499881 +0100\n> \tRename foo.c to bar.c and s/foo_/bar_/g\n\nExcept I want that empty line in there, and I want it in the \"free-form\" \nsection. The \"rename\" part really isn't part of the git header. It's not \nwhat git tracks, it was tracked by an SCM system on top of git.\n\nSo the git header is an \"inode\" in the git filesystem, and like an inode \nit has a ctime and an mtime, and pointers to the data. So as far as git is \nconcerned, this part:\n\n\ttree 82ba574c85e9a2e4652419c88244e9dd1bfa8baa\n\tparent bb95843a5a0f397270819462812735ee29796fb4\n\tauthor David Woodhouse 1113499881 +0100\n\tcommitter David Woodhouse 1113499881 +0100\n\nreally is the filesystem \"inode\". The rest is whatever the filesystem user\nputs into it, and git won't care.\n\n> Opinions? Dissent? We'd probably need to escape the filenames in some\n> way -- handwave over that for now.\n\nThe fact that git handles arbitrary filenames (stuff starting with \".\" \nexcepted) doesn't mean that the SCM above it needs to. Quite frankly, I \nthink an SCM that handles newlines in filenames is being silly. But a \n_filesystem_ needs to not care.\n\nThere are too many messy SCM's out there that do not hav ea \"philosophy\". \nDammit, I'm not interested in creating another one. This thing has a \nmental model, and we keep to that model.\n\nThe reason UNIX is beautiful is that it has a mental model of processes \nand files. Git has a mental model of objects and certain very very limited \nrelationships. The relationships git cares about are encoded in the C \nfiles, the \"extra crap\" (like rename info) is just that - stuff that \nrandom scripts wrote, and that is just informational and not central to \nthe model.\n\n\t\tLinus\n"},{"id":"99","messageId":"20050414181224.GA16126@elte.hu","threadId":"17","inReplyTo":"1113501260.27227.26.camel@hades.cambridge.redhat.com","subject":"Re: Handling renames.","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2005-04-14T18:12:24Z","receivedAt":"2005-04-14T18:12:24Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* David Woodhouse wrote:\n\n> I've been looking at tracking file revisions. One proposed solution \n> was to have a separate revision history for individual files, with a \n> new kind of 'filecommit' object which parallels the existing 'commit', \n> referencing a blob instead of a tree. Then trees would reference such \n> objects instead of referencing blobs directly.\n> \n> I think that introduces a lot of redundancy though, because 99% of the \n> time, the revision history of the individual file is entirely \n> reproducible from the revision history of the tree. It's only when \n> files are renamed that we fall over -- and I think we can handle \n> renames fairly well if we just log them in the commit object.\n\nhow about the following structure:\n\n - tree_new --->\n - tree_old ---> rename_commit -> blob\n\nthe rename_commit object just contains a pointer to the file content \nblob. If a rename happens then the old tree references the rename_commit \nobject (instead of the blob), and the new tree references it too. This \nway there's no need to list the rename via namespace means: if a tree \nentry points to a rename_commit object then a rename happened and the \nrename_commit object is looked up in the old tree to get the old name.\n\nthere's no redundancy caused by this method: only renames (which are \nrare) go through the rename_commit redirection. (to speed up the lookup \nthe rename_commit object could cache the offset of the two names within \ntheir tree objects.)\n\n\tIngo\n"},{"id":"100","messageId":"425EB4AE.4010700@zytor.com","threadId":"17","inReplyTo":"1113501260.27227.26.camel@hades.cambridge.redhat.com","subject":"Re: Handling renames.","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-04-14T18:21:34Z","receivedAt":"2005-04-14T18:21:34Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"David Woodhouse wrote:\n> \n> Opinions? Dissent? We'd probably need to escape the filenames in some\n> way -- handwave over that for now.\n> \n\nFor readability and simplicity I'd suggest using either URL-style %XX \nescapes or octal \\xxx escapes for anything bytes < 33, minus the escape \ncharacter.\n\nAlthough Linus is correct in that an SCM doesn't *have* to handle this, \nit really feels like shooting for mediocracy to me. We might as well \ndesign it right from the beginning.\n\n\t-hpa\n"},{"id":"102","messageId":"Pine.LNX.4.58.0504141124220.7211@ppc970.osdl.org","threadId":"17","inReplyTo":"20050414181224.GA16126@elte.hu","subject":"Re: Handling renames.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-14T18:32:34Z","receivedAt":"2005-04-14T18:32:34Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 14 Apr 2005, Ingo Molnar wrote:\n> \n> there's no redundancy caused by this method: only renames (which are \n> rare) go through the rename_commit redirection. (to speed up the lookup \n> the rename_commit object could cache the offset of the two names within \n> their tree objects.)\n\nBzzt. Wrong.\n\nANYTHING you do with games like this will cause the \"same directory \ncreates different object\" crap.\n\nGit doesn't do that. There fundamentally is no history in objects, \n_except_ for the commit object. Two objects with the same name are \nidentical, and that means that they are easy to share. \n\nAny time you break that model, you break the whole point of git. Don't do \nit. You'll be very very sorry if you ever do, because it breaks the clean \nseparation of \"time\" and \"space\". I guarantee you that your merges will \nbecome _harder_ rather than easier.\n\nWhat you can do at an SCM level, is that if you want to track renames, you\ntrack them as a separate commit altogether. Ie if you notice a rename, you\nfirst commit the rename (and you can _see_ it's a rename, since the object\ndidn't change, and the sha1 stayed the same, which in git-speak means that\nit is the same object, ie that _is_ a rename as far as git is concerned),\nand then you create the \"this is the data that changed\" as a _second_\ncommit.\n\nBut don't make it a new kind of commit. It's just a regular commit, \ndammit. No new abstractions. \n\nTrust me, it's worth it to follow the rules. You don't start making up new \nconcepts for every new thing you track. Next you'll want \"tag objects\". \nThat's a totally idiotic idea. What you do is you tag things at a higher \nlevel than git ever is, and git will _never_ have to know about tag \nobjects. \n\nSome \"higher level\" thing can add its own rules _on_top_ of git rules. The\nsame way we have normal applications having their _own_ rules on top of\nthe kernel. You do abstraction in layers, but for this to work, the base \nyou build on top of had better be damn solid, and not have any ugly \nspecial cases.\n\n\t\tLinus\n"},{"id":"104","messageId":"Pine.LNX.4.58.0504141145220.7211@ppc970.osdl.org","threadId":"17","inReplyTo":"425EB4AE.4010700@zytor.com","subject":"Re: Handling renames.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-14T18:48:44Z","receivedAt":"2005-04-14T18:48:44Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 14 Apr 2005, H. Peter Anvin wrote:\n> \n> Although Linus is correct in that an SCM doesn't *have* to handle this, \n> it really feels like shooting for mediocracy to me. We might as well \n> design it right from the beginning.\n\nNo. git is not an SCM. it's a filesystem designed to _host_ an SCM, and \nthat _is_ doing it right from the beginning.\n\nKeep the abstractions clean. Do _not_ get confused into thinking that git \nis an SCM. If you think of it that way, you'll end up with crap you can't \nthink about.\n\nAnd at a filesystem layer, \"rename\" already exists. It's moving an object \nto a new name in a tree. git already does that very well, thank you very \nmuch.\n\nBut a filesystem rename is _not_ the same thing as an SCM rename. An SCM \nrename is built on top of a filesystem rename, but it has its own issues \nthat may or may not make sense for the filesystem.\n\n\t\tLinus\n"},{"id":"105","messageId":"425EBB2D.3060508@zytor.com","threadId":"17","inReplyTo":"Pine.LNX.4.58.0504141145220.7211@ppc970.osdl.org","subject":"Re: Handling renames.","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-04-14T18:49:17Z","receivedAt":"2005-04-14T18:49:17Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Linus Torvalds wrote:\n> \n> On Thu, 14 Apr 2005, H. Peter Anvin wrote:\n> \n>>Although Linus is correct in that an SCM doesn't *have* to handle this, \n>>it really feels like shooting for mediocracy to me. We might as well \n>>design it right from the beginning.\n> \n> No. git is not an SCM. it's a filesystem designed to _host_ an SCM, and \n> that _is_ doing it right from the beginning.\n> \n> Keep the abstractions clean. Do _not_ get confused into thinking that git \n> is an SCM. If you think of it that way, you'll end up with crap you can't \n> think about.\n> \n> And at a filesystem layer, \"rename\" already exists. It's moving an object \n> to a new name in a tree. git already does that very well, thank you very \n> much.\n> \n> But a filesystem rename is _not_ the same thing as an SCM rename. An SCM \n> rename is built on top of a filesystem rename, but it has its own issues \n> that may or may not make sense for the filesystem.\n> \n\nI wasn't referring to git per se, I was referring to the hosted SCM.\n\n\t-hpa\n"},{"id":"106","messageId":"20050414185841.GA16865@elte.hu","threadId":"17","inReplyTo":"Pine.LNX.4.58.0504141124220.7211@ppc970.osdl.org","subject":"Re: Handling renames.","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2005-04-14T18:58:41Z","receivedAt":"2005-04-14T18:58:41Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Linus Torvalds wrote:\n\n> [...] Ie if you notice a rename, you first commit the rename (and you \n> can _see_ it's a rename, since the object didn't change, and the sha1 \n> stayed the same, which in git-speak means that it is the same object, \n> ie that _is_ a rename as far as git is concerned), and then you create \n> the \"this is the data that changed\" as a _second_ commit.\n\nok, i accept your point of not putting this into such a low level as the \nobject abstraction. Was a bad idea.\n\nbut i dont think the above would be enough: there can be renames of \nobjects that have the same sha1 hash as other objects in the same tree, \nand developers want to track individual objects, regardless of whether \nother files share the same content. So some formal operation would be \nneeded to signal renames - e.g. to embedd it in the commit object, per \nDavid's suggestion.\n\nThe thing i tried to avoid was to list long filenames in the commit \n(because of the tree hierarchy we'd need to do tree-absolute pathnames \nor something like that, and escape things, and do lookups - duplicating \na VFS which is quite bad) - it would be better to identify the rename \nsource and target via its tree object hash and its offset within that \ntree. Such information could be embedded in the commit object just fine. \nSomething like:\n\nme bb95843a5a0f397270819462812735ee29796fb4\ntree 1756b578489f93999ded68ae347bef7d6063101c\nparent 9f02d4d233223462d3f6217b5837b786e6286ba4\nauthor\ncommitter\nrename 39021759c903a943a33a28cfbd5070d36d851581 15234 9f02d4d233223462d3f6217b5837b786e6286ba4 16163\n\n?\n\n\tIngo\n"},{"id":"108","messageId":"1113505776.12012.210.camel@baythorne.infradead.org","threadId":"17","inReplyTo":"Pine.LNX.4.58.0504141102430.7211@ppc970.osdl.org","subject":"Re: Handling renames.","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2005-04-14T19:09:36Z","receivedAt":"2005-04-14T19:09:36Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Thu, 2005-04-14 at 11:11 -0700, Linus Torvalds wrote:\n> So, you really need to think of git as a filesystem. You can then \n> implement an SCM _on_top_of_it_, which means that your second suggestion \n> is not only acceptable, it really is the _only_ way to handle this in git:\n> \n> > So a commit involving a rename would look something like this...\n> > \n> > \ttree 82ba574c85e9a2e4652419c88244e9dd1bfa8baa\n> > \tparent bb95843a5a0f397270819462812735ee29796fb4\n> > \trename foo.c bar.c\n> > \tauthor David Woodhouse 1113499881 +0100\n> > \tcommitter David Woodhouse 1113499881 +0100\n> > \tRename foo.c to bar.c and s/foo_/bar_/g\n> \n> Except I want that empty line in there, and I want it in the \"free-form\" \n> section. The \"rename\" part really isn't part of the git header. It's not \n> what git tracks, it was tracked by an SCM system on top of git.\n\nNote that not only may you have a _set_ of renames, but you'll also have\na _different_ set of renames for each parent. Consider the\nrepresentation of a merge where a file was called 'foo' in one parent,\n'bar' in the other, and we called it 'foobar' in the resulting tree.\n\nThat's the main reason I wanted the renames in with the parent\ninformation -- so it's <...>...\n\nI see your point though and I can't be bothered to argue for the sake of\nthe slight efficiency benefit we might gain from doing it that way. The\nimplementation details really aren't that interesting right now.\n\nLet us assume, however, that we have this information somehow stored in\neach commit object. It's perfectly sufficient from the POV of the \n'git revtool' which I've been poking at; is it good enough for merges?\n\nConsider a simple case: A branch is taken, file foo.c is renamed to\nbar.c, and now we're trying to merge that branch back into the head,\nwhich has moved on. \n\nWe can't just take 'bar.c' as a new file -- we have to track it all the\nway back to its inception, and notice that it actually shares a common\nancestor with 'foo.c' in the other parent of the merge.\n\nHow feasible, and how computationally expensive, is that task going to\nbe? Especially given that there may be _many_ new files that we need to\nattempt to tie up with their partners, across many potential renames. \n\nOne option for optimising this, if we really need to, might be to track\nthe file back to its _first_ ancestor and use that as an identification.\nThe SCM could store that identifier in the blob itself, or we could\nconsider it an 'inode number' and store it in git's tree objects.\n\nIf we can avoid that, however, it would be nice. How feasible is the\nmerge going to be without it?\n\n-- \ndwmw2\n\n\n"},{"id":"111","messageId":"1113506402.12012.218.camel@baythorne.infradead.org","threadId":"17","inReplyTo":"20050414185841.GA16865@elte.hu","subject":"Re: Handling renames.","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2005-04-14T19:20:02Z","receivedAt":"2005-04-14T19:20:02Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Thu, 2005-04-14 at 20:58 +0200, Ingo Molnar wrote:\n> The thing i tried to avoid was to list long filenames in the commit \n> (because of the tree hierarchy we'd need to do tree-absolute pathnames \n> or something like that, and escape things, and do lookups - duplicating \n> a VFS which is quite bad) - it would be better to identify the rename \n> source and target via its tree object hash and its offset within that \n> tree. Such information could be embedded in the commit object just fine. \n> Something like:\n\nActually I'm not sure that's true. Let's consider the two main users of\nthis information.\n\nFirstly, because it's what I've been playing with: to list a given\nfile's revision history, I currently work with its filename -- walk the\ncommit objects, inspecting the tree and selecting those commits where\nthe file has changed. If my filename is 'fs/jffs2/inode.c' then I can\nimmediately skip over a commit where the 'fs' entry in the top-level\ntree is identical to that in the parent, or I can skip a commit where\nthe 'jffs2' entry in the 'fs' subtree is identical to the parent... it's\nall done on filename, and the {parent, entry} tuple wouldn't help much\nhere; I'd probably have to convert back to a filename anyway.\n\nSecondly, there's merges. I've paid less attention to these (see mail 5\nminutes ago) but I think they'd end up operating on the rename\ninformation in a very similar way. To find a common ancestor for a given\nfile,, we want to track its name as it changed during history; at that\npoint it's all string compares.\n\n-- \ndwmw2\n\n\n"},{"id":"112","messageId":"425EC2D0.2090904@cobite.com","threadId":"17","inReplyTo":"Pine.LNX.4.58.0504141124220.7211@ppc970.osdl.org","subject":"Re: Handling renames.","fromName":"David Mansfield","fromEmail":"david@cobite.com","sentAt":"2005-04-14T19:21:52Z","receivedAt":"2005-04-14T19:21:52Z","isPatch":false,"sender":{"key":"david@cobite.com","avatar":null},"body":"Linus Torvalds wrote:\n> \n> On Thu, 14 Apr 2005, Ingo Molnar wrote:\n> \n>>there's no redundancy caused by this method: only renames (which are \n>>rare) go through the rename_commit redirection. (to speed up the lookup \n>>the rename_commit object could cache the offset of the two names within \n>>their tree objects.)\n> \n> \n\n> \n> Some \"higher level\" thing can add its own rules _on_top_ of git rules. The\n> same way we have normal applications having their _own_ rules on top of\n> the kernel. You do abstraction in layers, but for this to work, the base \n> you build on top of had better be damn solid, and not have any ugly \n> special cases.\n> \n\nMaybe you (or the group) should standardize on a way to 'extend' the \ncommit 'object' in terms of:\n\nthe layer1 (git) header for commit object is defined as such-and-such\nthe layer2 (scm or other) header for commit object is defined as \nsuch-and-such\n\nMuch the way network protocols stack on top of each other. If a \nstandard way of stacking is defined, then it could be much cleaner for \nfuture implementors to understand a 'new' stacking protocol, and it will \nmake the scm-level extensions easier to discuss it terms of their own \n'layer'.\n\nDavid\n"},{"id":"113","messageId":"425EC2E8.3010703@superlucidity.net","threadId":"17","inReplyTo":"Pine.LNX.4.58.0504141145220.7211@ppc970.osdl.org","subject":"Re: Handling renames.","fromName":"Zach Welch","fromEmail":"zw@superlucidity.net","sentAt":"2005-04-14T19:22:16Z","receivedAt":"2005-04-14T19:22:16Z","isPatch":false,"sender":{"key":"zw@superlucidity.net","avatar":null},"body":"Linus Torvalds wrote:\n> \n> On Thu, 14 Apr 2005, H. Peter Anvin wrote:\n> \n>> Although Linus is correct in that an SCM doesn't *have* to handle \n>> this, it really feels like shooting for mediocracy to me. We might\n>> as well design it right from the beginning.\n> \n> \n> No. git is not an SCM. it's a filesystem designed to _host_ an SCM, \n> and that _is_ doing it right from the beginning.\n\nI imagine quite a few folks expect something not entirely unlike an SCM\nto emerge from these current efforts. Moreover, Petr's 'git' scripts\nwrap your \"filesystem\" plumbing to that very end.\n\nTo avoid confusion, I think it would be better to distinguish the two\nlayers, perhaps by calling the low-level plumbing... 'gitfs', of course.\n\nCheers,\n\nZach Welch\nSuperlucidity Services\n"},{"id":"117","messageId":"002701c54129$da2ffdd0$9b11a8c0@allianceoneinc.com","threadId":"17","inReplyTo":"425EC2E8.3010703@superlucidity.net","subject":"RE: Handling renames.","fromName":"Andrew Timberlake-Newell","fromEmail":"andrew.timberlake-newell@allianceoneinc.com","sentAt":"2005-04-14T19:40:44Z","receivedAt":"2005-04-14T19:40:44Z","isPatch":false,"sender":{"key":"andrew.timberlake-newell@allianceoneinc.com","avatar":null},"body":"Zach Welch pontificated:\n> I imagine quite a few folks expect something not entirely unlike an SCM\n> to emerge from these current efforts. Moreover, Petr's 'git' scripts\n> wrap your \"filesystem\" plumbing to that very end.\n> \n> To avoid confusion, I think it would be better to distinguish the two\n> layers, perhaps by calling the low-level plumbing... 'gitfs', of course.\n\nOr perhaps to come up with a name (or at least nickname) for the SCM.\n\nGitMaster?\n\n"},{"id":"125","messageId":"200504141442.17235.elenstev@mesatop.com","threadId":"17","inReplyTo":"002701c54129$da2ffdd0$9b11a8c0@allianceoneinc.com","subject":"Naming the SCM (was Re: Handling renames.)","fromName":"Steven Cole","fromEmail":"elenstev@mesatop.com","sentAt":"2005-04-14T20:42:16Z","receivedAt":"2005-04-14T20:42:16Z","isPatch":false,"sender":{"key":"elenstev@mesatop.com","avatar":null},"body":"On Thursday 14 April 2005 01:40 pm, Andrew Timberlake-Newell wrote:\n> Zach Welch pontificated:\n> > I imagine quite a few folks expect something not entirely unlike an SCM\n> > to emerge from these current efforts. Moreover, Petr's 'git' scripts\n> > wrap your \"filesystem\" plumbing to that very end.\n> > \n> > To avoid confusion, I think it would be better to distinguish the two\n> > layers, perhaps by calling the low-level plumbing... 'gitfs', of course.\n> \n> Or perhaps to come up with a name (or at least nickname) for the SCM.\n> \n> GitMaster?\n> \n\nCogito. \"Git inside\" can be the first slogan.\n\nDifferentiating the SCM built on top of git from git itself is probably worthwhile\nto avoid confusion. Other SCMs may be developed later, built on git, and these\ncan come up with their own clever names.\n\nSteven\n"},{"id":"126","messageId":"20050414205329.GF22699@pasky.ji.cz","threadId":"17","inReplyTo":"200504141442.17235.elenstev@mesatop.com","subject":"Re: Naming the SCM (was Re: Handling renames.)","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-14T20:53:29Z","receivedAt":"2005-04-14T20:53:29Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Apr 14, 2005 at 10:42:16PM CEST, I got a letter\nwhere Steven Cole told me that...\n> On Thursday 14 April 2005 01:40 pm, Andrew Timberlake-Newell wrote:\n> > Zach Welch pontificated:\n> > > I imagine quite a few folks expect something not entirely unlike an SCM\n> > > to emerge from these current efforts. Moreover, Petr's 'git' scripts\n> > > wrap your \"filesystem\" plumbing to that very end.\n> > > \n> > > To avoid confusion, I think it would be better to distinguish the two\n> > > layers, perhaps by calling the low-level plumbing... 'gitfs', of course.\n> > \n> > Or perhaps to come up with a name (or at least nickname) for the SCM.\n> > \n> > GitMaster?\n> > \n> \n> Cogito. \"Git inside\" can be the first slogan.\n\nWhat about tig?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"128","messageId":"425ED98C.9020101@zytor.com","threadId":"17","inReplyTo":"20050414205329.GF22699@pasky.ji.cz","subject":"Re: Naming the SCM (was Re: Handling renames.)","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-04-14T20:58:52Z","receivedAt":"2005-04-14T20:58:52Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Petr Baudis wrote:\n\n>>Cogito. \"Git inside\" can be the first slogan.\n> \n> What about tig?\n\nI like \"Cogito\"; it's a real name, plus it'd be a good use for the \notherwise-pretty-useless two-letter combination \"cg\".\n\n\t-hpa\n\n"},{"id":"130","messageId":"20050414210120.GG22699@pasky.ji.cz","threadId":"17","inReplyTo":"425ED98C.9020101@zytor.com","subject":"Re: Re: Naming the SCM (was Re: Handling renames.)","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-14T21:01:20Z","receivedAt":"2005-04-14T21:01:20Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Apr 14, 2005 at 10:58:52PM CEST, I got a letter\nwhere \"H. Peter Anvin\" told me that...\n> Petr Baudis wrote:\n> \n> >>Cogito. \"Git inside\" can be the first slogan.\n> >\n> >What about tig?\n> \n> I like \"Cogito\"; it's a real name, plus it'd be a good use for the \n> otherwise-pretty-useless two-letter combination \"cg\".\n\nDuh, believe me or not but I completely missed the \"Cogito\" part of\nSteven's mail. Of course, I like it too.\n\nI'll commit my poor man's git-merge-in-separate-tree and finally get\nsome sleep. I promise.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"136","messageId":"Pine.LNX.4.21.0504141758310.30848-100000@iabervon.org","threadId":"17","inReplyTo":"1113501260.27227.26.camel@hades.cambridge.redhat.com","subject":"Re: Handling renames.","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-14T22:23:26Z","receivedAt":"2005-04-14T22:23:26Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 14 Apr 2005, David Woodhouse wrote:\n\n> Opinions? Dissent? We'd probably need to escape the filenames in some\n> way -- handwave over that for now.\n\nI personally think renames are a minor thing that doesn't happen\nmuch. What actually happens, in my opinion, is that some chunk of a file\nis moved to a different, possibly new, file. If this is supported (as\nsomething that the SCM notices), then a rename is just a special case\nwhere the moved chunk is a whole file.\n\nI think that it should be possible to identify and tag \"big\nenough\" deletions and insertions, and compare them to find moves, where a\nfurther change may be applied in the middle if two chunks are \"very\nsimilar\" but not the same.\n\nOn the other hand, I think that the SCM will need to cache its\nunderstanding of what a commit did in order to give reasonable\nperformance for operations like \"annotate\", and it may be advantegous to\ndistribute things from this cache, since the committer might want to tell\nthe system something that it didn't guess.\n\nAt some point, I'm going to argue for core support for \"back pointers\",\nwhere a file can be created which is \"about\" some other file(s), and\nsomeone looking for files \"about\" a particular file can find them without\nsearching the entire database. I think this will turn out to be important\nfor a variety of cases where some later participant wants to say something\nabout an existing file without changing the content of the file.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"144","messageId":"1113518810.12012.256.camel@baythorne.infradead.org","threadId":"17","inReplyTo":"Pine.LNX.4.21.0504141758310.30848-100000@iabervon.org","subject":"Re: Handling renames.","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2005-04-14T22:46:50Z","receivedAt":"2005-04-14T22:46:50Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Thu, 2005-04-14 at 18:23 -0400, Daniel Barkalow wrote:\n> I personally think renames are a minor thing that doesn't happen\n> much. What actually happens, in my opinion, is that some chunk of a\n> file is moved to a different, possibly new, file. If this is supported\n> (as something that the SCM notices), then a rename is just a special\n> case where the moved chunk is a whole file.\n\nCertainly we'd discussed the possibility that the 'rename' field may\ncontain more than one destination, or more than one source filename.\nThis could happen when a file is split into two, or when two files are\nmerged into one, for example.\n\n-- \ndwmw2\n\n\n"},{"id":"159","messageId":"425EFA10.1020608@bigpond.net.au","threadId":"17","inReplyTo":"200504141442.17235.elenstev@mesatop.com","subject":"Re: Naming the SCM (was Re: Handling renames.)","fromName":"Peter Williams","fromEmail":"pwil3058@bigpond.net.au","sentAt":"2005-04-14T23:17:36Z","receivedAt":"2005-04-14T23:17:36Z","isPatch":false,"sender":{"key":"pwil3058@bigpond.net.au","avatar":"https://gravatar.com/avatar/fc711ad9d9890c01c6ede5a99a62a8b8ca82a3eef0def8ef98e0ec7da7f99367?d=mp&s=160"},"body":"Steven Cole wrote:\n> On Thursday 14 April 2005 01:40 pm, Andrew Timberlake-Newell wrote:\n> \n>>Zach Welch pontificated:\n>>\n>>>I imagine quite a few folks expect something not entirely unlike an SCM\n>>>to emerge from these current efforts. Moreover, Petr's 'git' scripts\n>>>wrap your \"filesystem\" plumbing to that very end.\n>>>\n>>>To avoid confusion, I think it would be better to distinguish the two\n>>>layers, perhaps by calling the low-level plumbing... 'gitfs', of course.\n>>\n>>Or perhaps to come up with a name (or at least nickname) for the SCM.\n>>\n>>GitMaster?\n>>\n> \n> \n> Cogito. \"Git inside\" can be the first slogan.\n> \n> Differentiating the SCM built on top of git from git itself is probably worthwhile\n> to avoid confusion. Other SCMs may be developed later, built on git, and these\n> can come up with their own clever names.\n\nAnd the logo could be a dove which, as everybody knows, coos.\n\nPeter\n-- \nPeter Williams pwil3058@bigpond.net.au\n\n\"Learning, n. The kind of ignorance distinguishing the studious.\"\n -- Ambrose Bierce\n"}]}