{"thread":{"id":"11606","subject":"Re: Adding Git to Better SCM Initiative : Comparison","startedAt":"2008-01-13T15:05:41Z","lastAt":"2008-01-13T19:20:25Z","messageCount":5,"participants":["linux@horizon.com","Matthieu Moy","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"65245","messageId":"20080113150541.21883.qmail@science.horizon.com","threadId":"11606","inReplyTo":null,"subject":"Re: Adding Git to Better SCM Initiative : Comparison","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2008-01-13T15:05:41Z","receivedAt":"2008-01-13T15:05:41Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"> What does \"Renames Support\" mean? Does it mean that when browsing history\n> we [can] show file / directory renames? Does it mean that log of file or\n> directory history [can] follow renames? Does it mean that line-wise file\n> history [can] follow renames? Renames support in merges is as TODO, so\n> I don't think that this one matters in this question. Because the answer,\n> especially in the case of git which is a bit different in that it does\n> rename detection and not rename tracking (using inodes / file-ids),\n> depends on that...\n\nLet me make a bolder statement: a person asking for \"rename support\"\nhas been mentally damaged by using CVS too much.\n\nCVS's fundamental problem is that it's a tree of versioned files.  So a\nfile has to have a well-defined identity across versions, so CVS uses\nthe name, and that leads to problems if you rename the file.\n\nAnd this is fundamentally broken.  Both git and subversion do it right:\na repository is a versioned tree of files.  Files don't have versions, but\nrather versions have files.  With this model, the problem Just Goes Away.\nIt doesn't exist any more.  There's nothing to solve, nothing to do.\n\n\"Rename support\" is a kludge to make a fundamentally broken model\nless painful.  Git doesn't have the problem, and so doesn't need,\ndoesn't have, and doesn't want the kludge.  Indeed, as your questions\nabove show, it's hard to even define what it would be if it existed.\nIt's like asking if an electric light has a thoriated mantle, or inquiring\nabout the filament supply voltage of my mp3 player.\n\nIn all honesty, the correct answer is \"no\", git doesn't have that feature,\njust like my laptop doesn't have a cooling water pressure sensor and\nmy solar-powered pocket calculator doesn't have a user-serviceable\nmains fuse.\n\nWhat's broken is the feature checklist.  Someone has to go and re-think\nthe issue in a less CVS-centric way.\n\n\nJust in case I was not clear enough above:\n\n\tThe need for a source file to have an identity\n\tthat persists across multiple revisions is an\n\tartifact of CVS's implementation.  Anyone asking\n\tif a different version control system can preserve\n\tthat identity across renames needs to learn that\n\twe now have ways of making light without fire.\n"},{"id":"65247","messageId":"vpqd4s5ycvv.fsf@bauges.imag.fr","threadId":"11606","inReplyTo":"20080113150541.21883.qmail@science.horizon.com","subject":"Re: Adding Git to Better SCM Initiative : Comparison","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2008-01-13T15:16:20Z","receivedAt":"2008-01-13T15:16:20Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"linux@horizon.com writes:\n\n> \"Rename support\" is a kludge to make a fundamentally broken model\n> less painful.\n\nIt's not.\n\nGit _has_ rename support. Look into the code, you'll find some code\nwhose purpose is to manage renames. And _no_, rename support is not\njust a direct consequence of commits being atomic.\n\nAtomic commit help, but if you do nothing else, moving a file and then\ntrying to merge will fail for example. So, in addition to atomic\ncommits, you have at least 3 options : explicit file ID (bzr),\nrecording renames (hg), or detecting renames after-the-fact (git).\n\n-- \nMatthieu\n"},{"id":"65249","messageId":"200801131725.09301.jnareb@gmail.com","threadId":"11606","inReplyTo":"vpqd4s5ycvv.fsf@bauges.imag.fr","subject":"Re: Adding Git to Better SCM Initiative : Comparison","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-01-13T16:25:07Z","receivedAt":"2008-01-13T16:25:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 13 January 2008, Matthieu Moy wrote:\n> linux@horizon.com writes:\n\nCan't you use a name or nick, by the way?\n \n> > \"Rename support\" is a kludge to make a fundamentally broken model\n> > less painful.\n> \n> It's not.\n> \n> Git _has_ rename support. Look into the code, you'll find some code\n> whose purpose is to manage renames. And _no_, rename support is not\n> just a direct consequence of commits being atomic.\n> \n> Atomic commit help, but if you do nothing else, moving a file and then\n> trying to merge will fail for example. So, in addition to atomic\n> commits, you have at least 3 options : explicit file ID (bzr),\n> recording renames (hg), or detecting renames after-the-fact (git).\n\nRename detection / dealing with renames in SCMs is needed for:\n0. Recovering previous state\n1. Merging correct files\n2. Forensic (log, blame) across renames / code movement\n\nWhile the fact that Git is snapshot based and has whole-tree atomic\ncommits (Subversion does too) make it automatically obey 0., some\nkind of rename support is needed for merges (Better SCM has it in TODO),\nand for examining history, for example if the file was renamed in\none of the branches.\n\nFor example \"git log --follow=gitweb/gitweb.perl\" follows history of\nspecified file (IIRC this does not work for directory; but then Git\ndoes not per se tracks directories), even if it was called gitweb.cgi\nat the very beginning. \"git blame -M\" assign commit to a line denoting\nwhen line was created, and not when it was moved (perhaps across file\nboundaries) in the current place.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"65263","messageId":"20080113184206.22452.qmail@science.horizon.com","threadId":"11606","inReplyTo":"vpqd4s5ycvv.fsf@bauges.imag.fr","subject":"Re: Adding Git to Better SCM Initiative : Comparison","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2008-01-13T18:42:06Z","receivedAt":"2008-01-13T18:42:06Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"Matthieu Moy <Matthieu.Moy@imag.fr> wrote:\n> linux@horizon.com writes:\n>> \"Rename support\" is a kludge to make a fundamentally broken model\n>> less painful.\n>\n> It's not.\n>\n> Git _has_ rename support. Look into the code, you'll find some code\n> whose purpose is to manage renames. And _no_, rename support is not\n> just a direct consequence of commits being atomic.\n>\n> Atomic commit help, but if you do nothing else, moving a file and then\n> trying to merge will fail for example. So, in addition to atomic\n> commits, you have at least 3 options : explicit file ID (bzr),\n> recording renames (hg), or detecting renames after-the-fact (git).\n\nPlease forgive me for not mentioning that part.  Yes, there are\ninteresting things to do with renames, and git is doing them, but I\nskipped over them because they don't have much to do with the better-scm\ndefinition of the feature:\n\n\"Does the system support moving a file or directory to a different\nlocation while still retaining the history of the file?\"\n\nYou can try to interpret it so it makes sense, but the question is\nbasically assuming that the history is attached to the file rather than\nthat the file is attached to the history.\n\nWith the latter model, the question is almost silly.  Even with the very\nprimitive version of git that Linus used to make v2.6.12-rc2 with none\nof that fancy code, you can rename a file and git retains the history.\nPeriod.  The qualification \"of the file\" doesn't even make sense.\n\nAs Linus has observed in the past, git does lots of fancy stuff to follow\nthe history of the code that's *in* the file, but the idea is that a file,\nper se, doesn't have a history or even an identity.\n\nYou can ask about the history of a file *name*, or of a file's *contents*,\nbut if not that, what exactly is this \"file\" thing you want the history of?\n\nOnce you've answered that, you can then figure out if the answer to\nthe question based on whether the file has a history to retain in the\nfirst place.\n\n\nThere are interesting questions about renames that you could ask, but\nbetter-scm isn't asking questions like \"can you resolve merges properly\nafter renaming a file on one branch?\"  Maybe I'm being uncharitable, but I\ncan't help but read the question as asking if the system has a workaround\nfor a well-known CVS problem.  And one honest answer is \"no, there's no\nworkaround; git doesn't suffer from the problem in the first place.\"\n"},{"id":"65267","messageId":"20080113192025.17717.qmail@science.horizon.com","threadId":"11606","inReplyTo":"20080113184206.22452.qmail@science.horizon.com","subject":"Re: Adding Git to Better SCM Initiative : Comparison","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2008-01-13T19:20:25Z","receivedAt":"2008-01-13T19:20:25Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"I just had another look at the better-scm.org list, and noticed that\nsomeone else has already given an equivalent answer:\n\nVesta\tYes. The unit of checkout/checkin is a directory tree. Files and\n\tdirectories can be added, deleted, and renamed between versions.\n"}]}