{"thread":{"id":"42915","subject":"[RFC] A Change to Commit IDs Too Ridiculous to Consider?","startedAt":"2016-07-24T18:12:36Z","lastAt":"2016-07-26T18:33:07Z","messageCount":10,"participants":["Jon Forrest","Jakub Narębski","Rodrigo Campos","Junio C Hamano","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"292064","messageId":"nn30dv$5sn$1@ger.gmane.org","threadId":"42915","inReplyTo":null,"subject":"[RFC] A Change to Commit IDs Too Ridiculous to Consider?","fromName":"Jon Forrest","fromEmail":"nobozo@gmail.com","sentAt":"2016-07-24T18:12:12Z","receivedAt":"2016-07-24T18:12:36Z","isPatch":false,"sender":{"key":"nobozo@gmail.com","avatar":"https://gravatar.com/avatar/37c6a7b57f29b3f35c6a9016537907c52f15bbf98575617dc046bcec6bf06372?d=mp&s=160"},"body":"\nThose of us who write instructional material about Git all face the same problem.\nThis is that we can't write step by step instructions that show the results of\nmaking a commit because users will always see different commit IDs.\nThis is fundamental to the design of Git.\n\nEven if the instructional material tells users to use standard author and committer\ninformation, (e.g. john.doe@example.com) and shows the text of the file being committed\nand the commit message to add, the resulting commit ID will differ from reader to reader\nsince the commit will presumably take place at different times.\n\nWhat if it were possible, for instructional purposes only, to somehow tell Git to relax\nthis requirement. By this I mean, the commit date would *not* be included when constructing\nthe commit ID. This would allow tutorials to show exactly what to expect to see when running commands.\n\nI realize that questions would remain such as how to turn on this behavior (e.g. command line flags,\nenvironment variables) and whether 'git log' (and maybe other commands) should somehow distinguish these\nmutant commits. There would probably be other issues to consider.\n\nAgain, this is for instructional purposes only, and only when the committer explicitly\nchooses to use this option. I'm *not* proposing a general change to Git's behavior.\n\nIs such a thing to ridiculous to even consider? Is there a better way to achieve the same result?\n\nJon Forrest\n\n\n"},{"id":"292068","messageId":"57950D12.2000607@gmail.com","threadId":"42915","inReplyTo":"nn30dv$5sn$1@ger.gmane.org","subject":"Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-07-24T18:46:42Z","receivedAt":"2016-07-24T18:46:59Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Please try to keep to the 80-character lines.\n\nW dniu 2016-07-24 o 20:12, Jon Forrest pisze:\n\n> Those of us who write instructional material about Git all face the\n> same problem. This is that we can't write step by step instructions\n> that show the results of making a commit because users will always\n> see different commit IDs. This is fundamental to the design of Git.\n> \n> Even if the instructional material tells users to use standard author\n> and committer information, (e.g. john.doe@example.com) and shows the\n> text of the file being committed and the commit message to add, the\n> resulting commit ID will differ from reader to reader since the\n> commit will presumably take place at different times.\n\nThere are two options: first, to tell the reader upfront that objects\nid would be different / would change.  This has the advantage that\nyou do not need to update those objects when you change instructions\nin the middle. Note that commit objects are not the only things that\nchange; for example the result of `ls -l` would also be slightly\ndifferent.\n\nAnother possibility is to set authordate and committerdate to some\nspecified time by the way of appropriate environment variables.\n\n> \n> What if it were possible, for instructional purposes only, to somehow\n> tell Git to relax this requirement. By this I mean, the commit date\n> would *not* be included when constructing the commit ID. This would\n> allow tutorials to show exactly what to expect to see when running\n> commands.\n\nWhat I think you don't realize is that \"commit\" objects are not\ntreated in any way special. Object identifiers of all objects are\nSHA-1 hash of uncompressed loose representation of said object\n(type + length + contents).\n\nWell, you could not record dates in commit object, but I think\nGit considers such objects broken.\n\n> \n> I realize that questions would remain such as how to turn on this\n> behavior (e.g. command line flags, environment variables) and whether\n> 'git log' (and maybe other commands) should somehow distinguish\n> these mutant commits. There would probably be other issues to\n> consider.\n> \n> Again, this is for instructional purposes only, and only when the\n> committer explicitly chooses to use this option. I'm *not* proposing\n> a general change to Git's behavior.\n> \n> Is such a thing to ridiculous to even consider? Is there a better way\n> to achieve the same result\n\nIMVHO it would require heavy surgery of Git for little benefit\n(see the beginning of reply for alternate solutions).\n \n-- \nJakub Narębski\n\n"},{"id":"292069","messageId":"20160724185132.GN25141@sdfg.com.ar","threadId":"42915","inReplyTo":"nn30dv$5sn$1@ger.gmane.org","subject":"Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?","fromName":"Rodrigo Campos","fromEmail":"rodrigo@sdfg.com.ar","sentAt":"2016-07-24T18:51:32Z","receivedAt":"2016-07-24T19:08:10Z","isPatch":false,"sender":{"key":"rodrigo@sdfg.com.ar","avatar":null},"body":"On Sun, Jul 24, 2016 at 11:12:12AM -0700, Jon Forrest wrote:\n> \n> Those of us who write instructional material about Git all face the same problem.\n> This is that we can't write step by step instructions that show the results of\n> making a commit because users will always see different commit IDs.\n> This is fundamental to the design of Git.\n> \n> Even if the instructional material tells users to use standard author and committer\n> information, (e.g. john.doe@example.com) and shows the text of the file being committed\n> and the commit message to add, the resulting commit ID will differ from reader to reader\n> since the commit will presumably take place at different times.\n\nAnd what is the problem with that, if you are doing it with instructional\npurposes? Let's assume that this helps and not confuses later when the commits\n*do* change. What is the problem you face?\n\nI mean, for some examples you can use HEAD, HEAD^, HEAD~4, etc. and that always\nworks, no matter the commit id. In which cases do you want/need the commit ids\nto be equal? Can you be more specific?\n\n\n\n\nThanks a lot,\nRodrigo\n"},{"id":"292071","messageId":"cfff11c9-e212-88a1-c00b-3e7a361e0db9@gmail.com","threadId":"42915","inReplyTo":"57950D12.2000607@gmail.com","subject":"Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?","fromName":"Jon Forrest","fromEmail":"nobozo@gmail.com","sentAt":"2016-07-24T19:20:35Z","receivedAt":"2016-07-24T19:20:42Z","isPatch":false,"sender":{"key":"nobozo@gmail.com","avatar":"https://gravatar.com/avatar/37c6a7b57f29b3f35c6a9016537907c52f15bbf98575617dc046bcec6bf06372?d=mp&s=160"},"body":"\n\nOn 7/24/2016 11:46 AM, Jakub Narębski wrote:\n> Please try to keep to the 80-character lines.\n\nSorry.\n\n> Another possibility is to set authordate and committerdate to some\n> specified time by the way of appropriate environment variables.\n\nThat sounds like a great idea. Assuming it\nworks the way I envision, this wouldn't require\nany changes to the source code.\n\n> What I think you don't realize is that \"commit\" objects are not\n> treated in any way special. Object identifiers of all objects are\n> SHA-1 hash of uncompressed loose representation of said object\n> (type + length + contents).\n\nI know this, but I thought that commit object IDs were the only\nones that included a date in what gets run through the SHA-1\nhash function. If there are others, then you're right - they'd\nneed to be included in this proposal.\n\n> Well, you could not record dates in commit object, but I think\n> Git considers such objects broken.\n\nYou mean that Git could, after the fact, detect commit IDs\nthat didn't include a date? If this is true, then your\nidea of using fixed dates from environment variables\nwould be the only way to do this.\n\n> IMVHO it would require heavy surgery of Git for little benefit\n> (see the beginning of reply for alternate solutions).\n\nEven using your environment variable solution that wouldn't\nrequire any code changes?\n\nJon\n\n"},{"id":"292072","messageId":"c0af7511-a5d5-29bb-d279-66b6c3e0519c@gmail.com","threadId":"42915","inReplyTo":"20160724185132.GN25141@sdfg.com.ar","subject":"Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?","fromName":"Jon Forrest","fromEmail":"nobozo@gmail.com","sentAt":"2016-07-24T19:57:50Z","receivedAt":"2016-07-24T19:57:58Z","isPatch":false,"sender":{"key":"nobozo@gmail.com","avatar":"https://gravatar.com/avatar/37c6a7b57f29b3f35c6a9016537907c52f15bbf98575617dc046bcec6bf06372?d=mp&s=160"},"body":"\n\nOn 7/24/2016 11:51 AM, Rodrigo Campos wrote:\n> And what is the problem with that, if you are doing it with instructional\n> purposes? Let's assume that this helps and not confuses later when the commits\n> *do* change. What is the problem you face?\n\nA lot of instructional material contains stuff like \"Do [xxx] and you'll\nsee [zzz]. If you don't then something went wrong so try to figure out\nwhat happened and do it again.\"\n\nGit, as it stands, for good reason doesn't allow this approach.\n\nI don't think a Git beginner, when using a version of Git that somehow\nworks the way I proposed, will be confused. The fact that performing the\nsame steps results in the same commit IDs won't be something that\nthey'll care about or even notice. The material can include a callout\nmentioning the difference between \"real\" Git and \"learners\" Git.\n\n> I mean, for some examples you can use HEAD, HEAD^, HEAD~4, etc. and that always\n> works, no matter the commit id.\n\nThis will work in some cases, but should come later in a Git book.\nBut, in many cases using relative commit IDs, rather than absolute,\nwill be less clear (I believe).\n\n> In which cases do you want/need the commit ids to be equal?\n> Can you be more specific?\n\nSure. Take a look at the 2nd or 3rd chapter of Pro Git Reedited, 2nd\nEdition (or just Pro Git 2nd Edition - it doesn't matter). You see\nlots of output showing 'git commit' commands and the commit IDs that\nresult. I suspect you'd see the same in almost any book about Git.\n\nJon\n"},{"id":"292075","messageId":"57952834.60706@gmail.com","threadId":"42915","inReplyTo":"cfff11c9-e212-88a1-c00b-3e7a361e0db9@gmail.com","subject":"Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-07-24T20:42:28Z","receivedAt":"2016-07-24T20:42:46Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W dniu 2016-07-24 o 21:20, Jon Forrest pisze:\n> On 7/24/2016 11:46 AM, Jakub Narębski wrote:\n>> \n>> Another possibility is to set authordate and committerdate to some\n>> specified time by the way of appropriate environment variables.\n> \n> That sounds like a great idea. Assuming it\n> works the way I envision, this wouldn't require\n> any changes to the source code.\n\nThis would however require for user to write more.\nThe environment variables are GIT_AUTHOR_DATE and GIT_COMMITTER_DATE;\ntheir format is described in the \"DATE FORMATS\" section in the\ngit-commit(1) manpage.\n\nAnd it is not something that the user would do when working\nwith Git themselves, for their own project.\n\n>> What I think you don't realize is that \"commit\" objects are not\n>> treated in any way special. Object identifiers of all objects are\n>> SHA-1 hash of uncompressed loose representation of said object\n>> (type + length + contents).\n> \n> I know this, but I thought that commit object IDs were the only\n> ones that included a date in what gets run through the SHA-1\n> hash function. If there are others, then you're right - they'd\n> need to be included in this proposal.\n\nThe problem is that many function in Git are object-type agnostic.\nChanging how 'commit' objects are treated would require heavy code\nsurgery... unless done as filter (see below), but even then extra\ncode would be needed, for small benefit and large maintenance\nburden.\n\nNow that I think about this, it could be done when displaying\nobject names (in `git log` and `git show`), replacing true commit\nobject with SHA-1 of those objects with dates stripped. Still\nneeds work.\n\n>> Well, you could not record dates in commit object, but I think\n>> Git considers such objects broken.\n> \n> You mean that Git could, after the fact, detect commit IDs\n> that didn't include a date? If this is true, then your\n> idea of using fixed dates from environment variables\n> would be the only way to do this.\n\nI think^H^H `git fsck` can check that objects are well formed,\nand warn if they are not.\n\n$ git fsck\nerror in commit 6deb0829fecdf1feab0cc7c66061a92a93cb19e7: \n  missingSpaceBeforeDate: invalid author/committer line - missing space before date\nerror in commit 762f28c2567c07d378d485c3e2a498947d49f406: \n  badDate: invalid author/committer line - bad date\n\n>> IMVHO it would require heavy surgery of Git for little benefit\n>> (see the beginning of reply for alternate solutions).\n> \n> Even using your environment variable solution that wouldn't\n> require any code changes?\n\nNo, this do not need no changes to git code, of course.\n\n-- \nJakub Narębski\n\n"},{"id":"292079","messageId":"a2910716-efda-51f1-da80-42f6b2d3adb0@gmail.com","threadId":"42915","inReplyTo":"57952834.60706@gmail.com","subject":"Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?","fromName":"Jon Forrest","fromEmail":"nobozo@gmail.com","sentAt":"2016-07-25T03:56:52Z","receivedAt":"2016-07-25T03:57:04Z","isPatch":false,"sender":{"key":"nobozo@gmail.com","avatar":"https://gravatar.com/avatar/37c6a7b57f29b3f35c6a9016537907c52f15bbf98575617dc046bcec6bf06372?d=mp&s=160"},"body":"\n>>> Another possibility is to set authordate and committerdate to some\n>>> specified time by the way of appropriate environment variables.\n\nTo follow up, Jakub's approach works great without\nrequiring any changes to Git.\n\nFor example, the following test script always\nproduces the same commit ID:\n\n----\nexport GIT_AUTHOR_DATE=2005-04-07T22:13:13\nexport GIT_COMMITTER_DATE=2005-04-07T22:13:13\nmkdir -p /tmp/test\ncd /tmp/test\nrm -rf .git\ngit init\necho \"Test\" > README\ngit add README\ngit commit -m \"test\"\ngit log\n----\n\nAs expected, commenting out the 2 export lines results in\ndifferent commit IDs each time.\n\nCase closed.\n\nThanks, Jakub!\n\nJon Forrest\n\n"},{"id":"292094","messageId":"xmqq1t2h92ul.fsf@gitster.mtv.corp.google.com","threadId":"42915","inReplyTo":"c0af7511-a5d5-29bb-d279-66b6c3e0519c@gmail.com","subject":"Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-25T15:03:46Z","receivedAt":"2016-07-25T15:03:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Forrest <nobozo@gmail.com> writes:\n\n> Sure. Take a look at the 2nd or 3rd chapter of Pro Git Reedited, 2nd\n> Edition (or just Pro Git 2nd Edition - it doesn't matter). You see\n> lots of output showing 'git commit' commands and the commit IDs that\n> result. I suspect you'd see the same in almost any book about Git.\n\nI would think that the early-stage learners are better served that\nit is the norm, not anything strange, that the commit object name\nwould be different when you do two identical sequence from scratch.\nForcing them to know GIT_*_DATE variables, just to give them an\nimpression as if setting of them is part of any normal workflow (or\nmore importantly, stable commit IDs made by different people at\ndifferent times is something expected), is doing them double\ndisservice, IMHO.\n"},{"id":"292106","messageId":"xmqq8twp7idk.fsf@gitster.mtv.corp.google.com","threadId":"42915","inReplyTo":"xmqq1t2h92ul.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-25T17:11:19Z","receivedAt":"2016-07-25T17:11:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Jon Forrest <nobozo@gmail.com> writes:\n>\n>> Sure. Take a look at the 2nd or 3rd chapter of Pro Git Reedited, 2nd\n>> Edition (or just Pro Git 2nd Edition - it doesn't matter). You see\n>> lots of output showing 'git commit' commands and the commit IDs that\n>> result. I suspect you'd see the same in almost any book about Git.\n>\n> I would think that the early-stage learners are better served that\n> it is the norm, not anything strange, that the commit object name\n> would be different when you do two identical sequence from scratch.\n\nEhh, sent without proofreading.  The above should say \"... are\nbetter served if the book taught that it is the norm, ...\".\n\n> Forcing them to know GIT_*_DATE variables, just to give them an\n> impression as if setting of them is part of any normal workflow (or\n> more importantly, stable commit IDs made by different people at\n> different times is something expected), is doing them double\n> disservice, IMHO.\n"},{"id":"292244","messageId":"EF592E1B359D4D8F87EC40A9465D3736@PhilipOakley","threadId":"42915","inReplyTo":"c0af7511-a5d5-29bb-d279-66b6c3e0519c@gmail.com","subject":"Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2016-07-26T14:26:32Z","receivedAt":"2016-07-26T18:33:07Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jon Forrest\" <nobozo@gmail.com>\n> On 7/24/2016 11:51 AM, Rodrigo Campos wrote:\n>> And what is the problem with that, if you are doing it with instructional\n>> purposes? Let's assume that this helps and not confuses later when the \n>> commits\n>> *do* change. What is the problem you face?\n>\n> A lot of instructional material contains stuff like \"Do [xxx] and you'll\n> see [zzz]. If you don't then something went wrong so try to figure out\n> what happened and do it again.\"\n>\n> Git, as it stands, for good reason doesn't allow this approach.\n\nYou may want to look at how the test suite handles the need for well defined \ncommit sequences.\n\nIt's not something I've really studied, but I am aware of the test_tick to \nincrement the time and similar helpers.\n\nThere is a big learning step that needs to be got over by many beginners who \nhave no concept of a DVCS, nor of multiple master copies (which to most is \nan oxymoron!), nor why the sha is a good solution and serial numbers are a \nbad solution!.\n\nBeing able to do a few \"Hello World\" commits starting at unix t=0, and then \nprogressing on to see how they differ when it's unix=now time, or they use \ntheir own user IDs could be a useful step for those that need it.\n\n>\n> I don't think a Git beginner, when using a version of Git that somehow\n> works the way I proposed, will be confused. The fact that performing the\n> same steps results in the same commit IDs won't be something that\n> they'll care about or even notice. The material can include a callout\n> mentioning the difference between \"real\" Git and \"learners\" Git.\n>\n>> I mean, for some examples you can use HEAD, HEAD^, HEAD~4, etc. and that \n>> always\n>> works, no matter the commit id.\n>\n> This will work in some cases, but should come later in a Git book.\n> But, in many cases using relative commit IDs, rather than absolute,\n> will be less clear (I believe).\n>\n>> In which cases do you want/need the commit ids to be equal?\n>> Can you be more specific?\n>\n> Sure. Take a look at the 2nd or 3rd chapter of Pro Git Reedited, 2nd\n> Edition (or just Pro Git 2nd Edition - it doesn't matter). You see\n> lots of output showing 'git commit' commands and the commit IDs that\n> result. I suspect you'd see the same in almost any book about Git.\n>\n> Jon\n> --\nPhilip \n\n"}]}