{"thread":{"id":"10260","subject":"Imports without Tariffs","startedAt":"2007-10-12T20:36:29Z","lastAt":"2007-10-13T04:44:54Z","messageCount":3,"participants":["mfwitten@mit.edu","Jeff King","Michael Witten"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"55574","messageId":"1C0D32ED-59F7-43D4-88B1-D7A9E754D639@mit.edu","threadId":"10260","inReplyTo":null,"subject":"Imports without Tariffs","fromName":"","fromEmail":"mfwitten@mit.edu","sentAt":"2007-10-12T20:36:29Z","receivedAt":"2007-10-12T20:36:29Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"[INTRO]\n\n\tHello,\n\t\n\tI have come across a problem that could be easily addressed\n\tin order to improve interoperability between CVS and git.\n\t\n\t\n\tI'm new to using git (and a novice with SCMs in general),\n\tand I really enjoy the way that git allows me to think.\n\t\n\tUnfortunately, I am forced to deal with CVS (for one of\n\tmy classes), but I have been courageously trying to use\n\tgit behind the scenes, as I can already tell CVS is a\n\tnightmare.\n\t\n\n[SCENARIO]\n\t\n\tI would like to do the following sequence:\n\t\t\n\t\t(1) Checkout a CVS repository as a git working tree.\n\t\t\t\t\n\t\t\t=> git cvsimport -A /path -a -k -v -r cvs -C work module\n\t\t\t\n\t\t(2) Edit the git working tree and make commits there.\n\t\t\t\t\n\t\t\t=> cd work\n\t\t\t=> vim ... # emacs can go live with CVS ;-P\n\t\t\t=> git commit -a -m ...\n\t\t\t\t\n\t\t(3) Export my git working tree commits back to CVS.\n\t\t\t\n\t\t\t=> cd ..; cvs co modules; cd modules\n\t\t\t\n\t\t\t=> for each pertinent git commit hash, HASH:\n\t\t\t\tGIT_DIR=../work/.git git-cvsexportcommit -vc HASH\n\t\t\t\t\n\t\t(4) Update my git working tree from CVS (at some later time).\n\t\t\t\n\t\t\t=> cd ../work\n\t\t\t=> git cvsimport -a -k -v -r cvs -C . module\n\t\t\n[PROBLEM]\n\t\n\tgit-cvsimport creates new hash IDs for the same ol' commits.\n\t\n\t\n\tRunning git-cvsimport does indeed do an incremental update of\n\tthe 'cvs' remote in the 'work' git repository.\n\t\n\tHowever, the updates are brought in as brand new git commits\n\twith the CVS dates in the log (though changed to UTC +0000!!).\n\t\n\tTherefore, when the updated 'cvs' remote branches are merged into\n\tmy local branches, git treats the commits I made with cvsexportcommit\n\tas separate history; thus, history is duplicated and merge commits\n\tappear where they shouldn't.\n\n[PARTIAL SOLUTION]\n\t\n\tThe trick is to populate the 'cvs' remote branches with commits that\n\thave the right hash IDs.\n\t\n\tI thought I could do this by hand.\n\t\n\tI updated the cvsexportcommit/cvsimport sequence by pushing\n\tmy local branches into their respective 'cvs' remote branches,\n\tbefore running that last cvsimport:\n\t\t\n\t\t=> for each pertinent git commit hash, HASH:\n\t\t\tGIT_DIR=../work/.git git-cvsexportcommit -vc HASH\n\t\t\n\t\t=>=>=> git push . refs/heads/master:refs/remotes/cvs/master\n\t\t\n\t\t=> git cvsimport -a -k -v -r cvs -C . module\n\t\n\tOf course, git-cvsimport still adds the commits to the 'cvs'\n\tremote branches, duplicating (log) histories.\n\t\n\tThe difference is that the 'cvs' remote branches become descendants\n\tof the local branches, causing a fast-forward merge with the local\n\tbranches; this removes the split histories, but still duplicates\n\tinformation in an even dumber way, as changes are undone and then\n\tredone.\n\n[SOLUTION]\n\t\n\tThe trick is to make both git-cvsimport and the user smarter\n\t\t---- A TALL ORDER!\n\t\n\t\n\tTo make things simple, I think all of the necessary machinery\n\tshould be put into git-cvsimport.\n\t\n\tThe user should first git-cvsexportcommit as necessary.\n\t\n\tThen the user should tell git-cvsimport to push from the pertinent git\n\tbranches into the pertinent cvsimport branch. To make things even  \nsimpler,\n\tI think that git-cvsimport should make the -r option mandatory; then\n\tgit-cvsimport would simply do the pushing as I did:\n\t\t\n\t\tgit push . refs/heads/<branch1>:refs/remotes/<remote>/<branch2>\n\t\n\tThen git-cvsimport would mark for each pushed-into branch the timestamp\n\tfor when the push occurred. These marks could be put in some special  \nfile,\n\tsay .git/CVSIMPORT.\n\t\n\tThe next time git-cvsimport is used as normal, it can consult this  \nfile for\n\ttimestamps, rather than relying on git log timestamps, to determine  \nif creat-\n\ting a new commit is necessary.\n\n[CONCLUSION]\n\t\n\tI feel that not much is being put into converting between git and  \nCVS, which\n\tis unfortunate, because a lot of stuff is in CVS out there; here at  \nMIT,\n\t*all* CS students have to use CVS for at least one semester of  \ngrueling programming\n\tlabs.\n\t\n\tIf conversion between git and CVS is hard, many students will just  \nlearn\n\twhat seems easiest---CVS---and they'll decide to use CVS for their  \nprojects\n\tlater on (I've already seen this happen); that's not a future I want  \nto have!\n\t\n\tSincerely,\n\tMichael Witten\n\t\n[OTHER PROBLEMS]\n\t\n\t(1) git-cvsimport creates log entries with UTC times; maybe that's  \ncorrect.\n\t(2) git-cvsimport's -A argument must be a full path.\n\t(3) git-cvsexportcommit should automatically handle contiguous commits.\n\t(4) git-cvsimport is written in the most unmaintainable perl ever!\n"},{"id":"55582","messageId":"20071013024910.GA26386@coredump.intra.peff.net","threadId":"10260","inReplyTo":"1C0D32ED-59F7-43D4-88B1-D7A9E754D639@mit.edu","subject":"Re: Imports without Tariffs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-13T02:49:10Z","receivedAt":"2007-10-13T02:49:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 12, 2007 at 04:36:29PM -0400, mfwitten@MIT.EDU wrote:\n\n> \t\t(4) Update my git working tree from CVS (at some later time).\n> \t\t\t\n> \t\t\t=> cd ../work\n> \t\t\t=> git cvsimport -a -k -v -r cvs -C . module\n> \t\t\n> [PROBLEM]\n> \t\n> \tgit-cvsimport creates new hash IDs for the same ol' commits.\n>\n> [...]\n> \tTherefore, when the updated 'cvs' remote branches are merged into\n> \tmy local branches, git treats the commits I made with cvsexportcommit\n> \tas separate history; thus, history is duplicated and merge commits\n> \tappear where they shouldn't.\n\nYou are presumably doing a 'git-pull' on the cvsimport-ed commits. Try\ndoing a git-rebase, which will filter out commits which make the same\nchanges. Yes, it means throwing away your original commits, but the new\nones should be morally equivalent (and are now the \"official\" upstream\nof the CVS repository).\n\n-Peff\n"},{"id":"55592","messageId":"C30A314A-C258-4585-86FD-C1158ACA85C2@mit.edu","threadId":"10260","inReplyTo":"3B7796D6-5901-40B0-B3FC-70642AC50B08@mit.edu","subject":"Re: Imports without Tariffs","fromName":"Michael Witten","fromEmail":"mfwitten@mit.edu","sentAt":"2007-10-13T04:44:54Z","receivedAt":"2007-10-13T04:44:54Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On 12 Oct 2007, at 4:36:29 PM, mfwitten@MIT.EDU wrote:\n\n> To make things simple, I think all of the necessary machinery\n> should be put into git-cvsimport.\n>\n> The user should first git-cvsexportcommit as necessary.\n\n\nNow that I have considered, it makes more sense to put the\nmachinery in git-cvsexportcommit.\n\nThe user could use a -b flag to specify the git branch to push\ninto after the cvs commit occurs, and git-cvsexportcommit would\nupdate the .git/SCM_IMPORT file (changed from CVS_IMPORT).\n\nOf course, this introduces other troubles.\n\nSometimes I run cvsexportcommit using a git repo on another server.\nSo perhaps one should also be able to use cvsexportcommit for just\npushing and editing the .git/SCM_IMPORT file.\n\nThat way it's possible to update CVS and then notify any other git\nrepo by hand.\n\nMichael\n"}]}