{"thread":{"id":"11392","subject":"sane, stable renames; when a commit should commit twice","startedAt":"2007-12-23T02:03:10Z","lastAt":"2007-12-23T16:29:09Z","messageCount":4,"participants":["Zenaan Harkness","David Symonds","Junio C Hamano","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"64019","messageId":"20071223020310.GA22450@freedbms.net","threadId":"11392","inReplyTo":null,"subject":"sane, stable renames; when a commit should commit twice","fromName":"Zenaan Harkness","fromEmail":"zen@freedbms.net","sentAt":"2007-12-23T02:03:10Z","receivedAt":"2007-12-23T02:03:10Z","isPatch":false,"sender":{"key":"zen@freedbms.net","avatar":null},"body":"When should a commit, commit twice?\n\nWhen one or more git mv file renames/ moves are involved.\n\nIn such a case the commit ought to be split into two. Perhaps move the\nfiles in the first commit, then make the changes needed to support the\nmove in the build chain (including changes in the moved files) in the\nsecond commit.\n\nThis keeps a clean record of the move, making the move, and the\nassociated changes (as two commits) a clean cherry.\n\nDoes this make sense?\n\nI develop in the java world, and we use packages (directories, and\nsubdirectories, sub-sub... etc) a lot, and so it is not uncommon in my\n10 years development, to decide to reorganise some package/dir every now\nand then, and files, and whole dirs, get moved.\n\nI've only been using git for a few weeks, but finding it truly awesome!\nA little demanding in the initial learning curve - took me three days of\nreading and a little experiementation here and there, before I finally\nfelt comfortable with rebasing, branching, etc, to effect my work\npattern.\n\nHave used arch/tla, a little bzr, aegis for a couple of years long time\nago, some cvs, and bk for four months or so.\n\nI'm hoping that the above workflow, which has just crystallized for me\nin the last two days, makes sense.\n\nzen\n\n-- \nHomepage: www.SoulSound.net -- Free Australia: www.UPMART.org\nPlease respect the confidentiality of this email as sensibly warranted.\n"},{"id":"64021","messageId":"ee77f5c20712221826r5945a6d0x8a84eae98c85b25b@mail.gmail.com","threadId":"11392","inReplyTo":"20071223020310.GA22450@freedbms.net","subject":"Re: sane, stable renames; when a commit should commit twice","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2007-12-23T02:26:24Z","receivedAt":"2007-12-23T02:26:24Z","isPatch":false,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On Dec 23, 2007 1:03 PM, Zenaan Harkness <zen@freedbms.net> wrote:\n> When should a commit, commit twice?\n>\n> When one or more git mv file renames/ moves are involved.\n>\n> In such a case the commit ought to be split into two. Perhaps move the\n> files in the first commit, then make the changes needed to support the\n> move in the build chain (including changes in the moved files) in the\n> second commit.\n>\n> This keeps a clean record of the move, making the move, and the\n> associated changes (as two commits) a clean cherry.\n>\n> Does this make sense?\n\nNot particularly. Git commits are not (conceptually) changes or\ndeltas; they are snapshots of a tree of files at a particular time.\nHow does the tree state at your above first commit make any sense? It\nis broken. Git's rename/move detection is smart enough to notice that\na rename + small-changes is close enough to a rename, so just trust\nthat to get it right.\n\n\nDave.\n"},{"id":"64022","messageId":"7v4peaw2ct.fsf@gitster.siamese.dyndns.org","threadId":"11392","inReplyTo":"20071223020310.GA22450@freedbms.net","subject":"Re: sane, stable renames; when a commit should commit twice","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-23T02:50:58Z","receivedAt":"2007-12-23T02:50:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Zenaan Harkness <zen@freedbms.net> writes:\n\n> When should a commit, commit twice?\n>\n> When one or more git mv file renames/ moves are involved.\n> ...\n> Does this make sense?\n\nAnything that feels right to you is right for _your_ project, so\nasking that question does not add much value, but I would not\npersonally do that myself.  I may have pure rename commits that\nmove files around without changing any contents in my history,\nbut that is only because there happened to be no need to change\nthe contents in those commits, not because I followed an\nartificial \"a rename-only commit, followed by a commit that\nedits\" dogma you seem to be suggesting.\n\nIf I move file common.c to lib/common.c and common.h to\ninclude/common.h, I would definitely NOT record that as two\nevents, if common.c used to include common.h.  My commit that\nmoves these two files will definitely contain edit to common.c\n(now lib/common.c) that changes at least one line:\n\n\t-#include \"common.h\"\n        +#include \"../include/common.h\"\n\nin the same commit.  If you split this as two events, your first\n\"rename only\" commit would not even build.\n"},{"id":"64044","messageId":"fkm2ck$o8j$1@ger.gmane.org","threadId":"11392","inReplyTo":"ee77f5c20712221826r5945a6d0x8a84eae98c85b25b@mail.gmail.com","subject":"Re: sane, stable renames; when a commit should commit twice","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-23T16:29:09Z","receivedAt":"2007-12-23T16:29:09Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"David Symonds wrote:\n\n> On Dec 23, 2007 1:03 PM, Zenaan Harkness <zen@freedbms.net> wrote:\n>> When should a commit, commit twice?\n>>\n>> When one or more git mv file renames/ moves are involved.\n>>\n>> In such a case the commit ought to be split into two. Perhaps move the\n>> files in the first commit, then make the changes needed to support the\n>> move in the build chain (including changes in the moved files) in the\n>> second commit.\n>>\n>> This keeps a clean record of the move, making the move, and the\n>> associated changes (as two commits) a clean cherry.\n>>\n>> Does this make sense?\n> \n> Not particularly. Git commits are not (conceptually) changes or\n> deltas; they are snapshots of a tree of files at a particular time.\n> How does the tree state at your above first commit make any sense? It\n> is broken. Git's rename/move detection is smart enough to notice that\n> a rename + small-changes is close enough to a rename, so just trust\n> that to get it right.\n\nMoreover renames detection during merges is based on three states:\nours, theirs and ancestor, and it would not take into account\n\"pure rename\" commit it is there in the middle of one of chains.\n\nBesides broken (not compiling) commit makes it harder for bisect to find\ntrue bug later.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"}]}