{"thread":{"id":"15408","subject":"A git problem with timestamps","startedAt":"2008-09-07T13:54:02Z","lastAt":"2008-09-07T20:03:26Z","messageCount":2,"participants":["Rod","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"89970","messageId":"200809070954.03394.armyofthepenguin@gmail.com","threadId":"15408","inReplyTo":null,"subject":"A git problem with timestamps","fromName":"Rod","fromEmail":"armyofthepenguin@gmail.com","sentAt":"2008-09-07T13:54:02Z","receivedAt":"2008-09-07T13:54:02Z","isPatch":false,"sender":{"key":"armyofthepenguin@gmail.com","avatar":null},"body":"I have a problem with a git repository that I'm hoping you folks can help me \nwith. \n\nIf you folks have the time here's my situation:\n============================\n2 persons developing together (Fred and Barney if you will). Fred's repository \nis the canonical repository, Barney cloned from Fred, and periodically has \nFred pull Barney's work, and if it passes muster, merge it into Fred's \nmaster. Barney is good about pulling Fred's master into his own master \nperiodically and basing his work off the master branch.\n\nFred starts with source code that is not his own (or under version control), \nbut that he needs to clean up with help from Barney.\n\nNow Fred is a conscientious Linux user and uses ntp to make sure his system \ndate is in sync within a couple of milliseconds of UTC. Barney (that would be \nme) is a slacker too lazy to run ntpclient, or ntpd to make sure he's also \nin sync with UTC. In point of fact, Barney's clock says he's 6 hours earlier \nthan Fred (i.e., when Fred's system clock say it's 6 p.m., Barney's clock say \nit's noon.).\n\nGit has no problem keeping track of the order in which commits occurs as gitk \nclearly shows. But git log has a problem since it's ordering by time stamps, \nso it shows Fred's initial commit occurring *After* some commits pulled from \nBarney's repository. \n\nWhat's really bugging Fred and Barney is that Fred has received a new updated \nversion of the original source code he was tasked to clean up. What Fred and \nBarney would like to do is to make a branch of the repository from the base \nof master, and then apply the history of master onto this branch. For \npersonal reasons, they don't want to simply rebase master off this branch.\n\nTo be a little more specific, what Fred and  Barney would like to do is to \nbranch master's base node (not HEAD), call it \"updated_original_source_code\", \nunroll the \"updated\" original source code in this branch, commit the diffs \nfrom the original source code to \"updated\" original source code, and then \napply the history of master by using git-format-patch and git-am to generate \na sequence of patches to apply onto updated_original_source_code branch. \n\nThe problem is that the patches generated by git-format-patch are generated by \ntimestamp, and since slacker Barney's timestamps are off by 6 hours, some of \nthe patches would be applied in the wrong order thus borking the operation. \nHave you any suggestions for how to get around this problem? I'm sure I can't \nbe the only person to have used the wrong system clock time.\n\nHere are the git commands Fred is attempting to use:\n# Branch the *base* of master\ngit checkout -b updated_original_source_code 345678\n\ncp ../updated_source_code.tar.gz .\ntar zxvf updated_source_code.tar.gz\n\n# Commit all changes from original_source_code\n# to updated_source_code\ngit -a -m \"Updated original source code\"\n\n# Now apply the history of master onto this branch:\n# This is where they get hosed because the timestamps\n# from Barney's commits are wrong, and hence the \n# generated patches are out of order.\ngit format-patch 345678..master | git am -k -3\n\n--Rod\n\nP.s. Would a diagram help?\n"},{"id":"90000","messageId":"7vvdx7lo4x.fsf@gitster.siamese.dyndns.org","threadId":"15408","inReplyTo":"200809070954.03394.armyofthepenguin@gmail.com","subject":"Re: A git problem with timestamps","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-07T20:03:26Z","receivedAt":"2008-09-07T20:03:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rod <armyofthepenguin@gmail.com> writes:\n\n> Here are the git commands Fred is attempting to use:\n> # Branch the *base* of master\n> git checkout -b updated_original_source_code 345678\n>\n> cp ../updated_source_code.tar.gz .\n> tar zxvf updated_source_code.tar.gz\n>\n> # Commit all changes from original_source_code\n> # to updated_source_code\n> git -a -m \"Updated original source code\"\n>\n> # Now apply the history of master onto this branch:\n> # This is where they get hosed because the timestamps\n> # from Barney's commits are wrong, and hence the \n> # generated patches are out of order.\n> git format-patch 345678..master | git am -k -3\n\nFirst of all, the branch name \"updated_original_source_code\" does not make\nmuch sense.  When you get another round of source tarball update, what\nwould you do?  Create \"updated_original_source_code_2\"?  The one after\nthat is \"updated_original_source_code_3\"?\n\nThat misses the whole point of revision control, doesn't it?\n\nYou instead keep an \"upstream\" branch, whose tip might be at 345678 before\naccepting the tarball update, and you advance its tip only with the\nupstream updates:\n\n      Barney               o---o---o       o---o\n                          /         \\     /     \\\n      Fred   o---o---o---o---o---o---o---o---o---o\n            /\n        ---o---------------------------------------o\n           ^                                       ^\n           upstream ===== (tarball update) ======> upstream\n\nYou can tag its tip after every time you accept the tarball update from\nyour upstream.\n\nA natural thing to do from there is to _merge_ upstream changes to your\nshared development, that results in:\n\n\n      Barney               o---o---o       o---o\n                          /         \\     /     \\\n      Fred   o---o---o---o---o---o---o---o---o---o---*\n            /                                       /\n        ---o---------------------------------------o\n           ^                                       ^\n           upstream ===== (tarball update) ======> upstream\n\nOf course you could rebase all history on top of updated upstream (buy why\nbother? -- you are not keeping a linear history by cross merging between\ntwo developers already, so there is no point doing a \"format-patch | am\"\nsequence to linearlize your history at this point), and --topo-order given\nto format-patch may help with broken timestamps one of you recorded.\n"}]}