{"thread":{"id":"3656","subject":"git-cvsimport \"you may need to merge manually\"","startedAt":"2006-03-17T02:37:39Z","lastAt":"2006-03-18T23:21:15Z","messageCount":13,"participants":["Randal L. Schwartz","Junio C Hamano","smurf@smurf.noris.de"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"17604","messageId":"86veud23v0.fsf@blue.stonehenge.com","threadId":"3656","inReplyTo":null,"subject":"git-cvsimport \"you may need to merge manually\"","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-03-17T02:37:39Z","receivedAt":"2006-03-17T02:37:39Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":"\nStarting recently, git-cvsimport has always ended with \"you\nmay need to merge manually\". Why? It worked before. What\nis it doing now?\n\n $ cd /home/merlyn/Git/stonehenge.git || exit 1\n $ git-cvsimport -v -k -o master -d /web/cvs stonehenge\n .\n .\n .\n skip patchset 323: 1142297290 before 1142351976\n Fetching htdocs/courses.html v 1.4\n Update htdocs/courses.html: 8767 bytes\n Fetching htdocs/rates.html v 1.2\n Update htdocs/rates.html: 2043 bytes\n Tree ID 38280334da5eaa4fd80fe1011e63db4b527f1d13\n Parent ID e93de754181fe963b8623423f509540021caead0\n Committed patch 324 (master 2006-03-16 18:14:31)\n Commit ID 985ca72d4e8a07d4189794231f035bac63c9e91d\n DONE; you may need to merge manually.\n $ git-status\n #\n # Updated but not checked in:\n # (will commit)\n #\n # modified: htdocs/courses.html\n # modified: htdocs/rates.html\n #\n\nRight... why didn't it commit those? I'm having to issue \"fake\"\ncommits now, so I've lost the cvs-log comments that were formerly\nvery complete and cool.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"17605","messageId":"7vu09x7puo.fsf@assigned-by-dhcp.cox.net","threadId":"3656","inReplyTo":"86veud23v0.fsf@blue.stonehenge.com","subject":"Re: git-cvsimport \"you may need to merge manually\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-17T02:43:43Z","receivedAt":"2006-03-17T02:43:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n> Starting recently, git-cvsimport has always ended with \"you\n> may need to merge manually\". Why? It worked before. What\n> is it doing now?\n>\n> $ cd /home/merlyn/Git/stonehenge.git || exit 1\n> $ git-cvsimport -v -k -o master -d /web/cvs stonehenge\n> .\n> .\n> .\n> skip patchset 323: 1142297290 before 1142351976\n> Fetching htdocs/courses.html v 1.4\n> Update htdocs/courses.html: 8767 bytes\n> Fetching htdocs/rates.html v 1.2\n> Update htdocs/rates.html: 2043 bytes\n> Tree ID 38280334da5eaa4fd80fe1011e63db4b527f1d13\n> Parent ID e93de754181fe963b8623423f509540021caead0\n> Committed patch 324 (master 2006-03-16 18:14:31)\n> Commit ID 985ca72d4e8a07d4189794231f035bac63c9e91d\n> DONE; you may need to merge manually.\n> $ git-status\n> #\n> # Updated but not checked in:\n> # (will commit)\n> #\n> # modified: htdocs/courses.html\n> # modified: htdocs/rates.html\n> #\n>\n> Right... why didn't it commit those? I'm having to issue \"fake\"\n> commits now, so I've lost the cvs-log comments that were formerly\n> very complete and cool.\n\nI do not use cvsimport but I wonder what Commit ID 985ca7\ncontains. Can you try \"git show 985ca7\" and see if that is the\ncommit you want?\n\nAlso, which branch are you on when you run git-cvsimport, and\nwhich branch did the commit 985ca7 go? I suspect it is storing\nthe tip commit 985ca7 to a branch that you are _not_ on\ncurrently, but refraining from merging that to your current\nbranch, or something like that.\n"},{"id":"17606","messageId":"86r75122yj.fsf@blue.stonehenge.com","threadId":"3656","inReplyTo":"7vu09x7puo.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-cvsimport \"you may need to merge manually\"","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-03-17T02:57:08Z","receivedAt":"2006-03-17T02:57:08Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Junio\" == Junio C Hamano writes:\n\n>> Right... why didn't it commit those? I'm having to issue \"fake\"\n>> commits now, so I've lost the cvs-log comments that were formerly\n>> very complete and cool.\n\nJunio> I do not use cvsimport but I wonder what Commit ID 985ca7\nJunio> contains. Can you try \"git show 985ca7\" and see if that is the\nJunio> commit you want?\n\nTo bring the tree clean, I issued \"git commit -a -m 'cvs sync'\", and\n\"git-whatchanged -p\" shows the most recent commit with the diff actually\n*backed out* the most recent change in CVS, and the next change down was\nactually the good one. Weird. Do I need to start all over again?\n\nJunio> Also, which branch are you on when you run git-cvsimport, and\nJunio> which branch did the commit 985ca7 go? I suspect it is storing\nJunio> the tip commit 985ca7 to a branch that you are _not_ on\nJunio> currently, but refraining from merging that to your current\nJunio> branch, or something like that.\n\nNope. I'm on \"master\", and it should be writing \"master\".\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"17607","messageId":"86k6at22mi.fsf@blue.stonehenge.com","threadId":"3656","inReplyTo":"86r75122yj.fsf@blue.stonehenge.com","subject":"Re: git-cvsimport \"you may need to merge manually\"","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-03-17T03:04:21Z","receivedAt":"2006-03-17T03:04:21Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Randal\" == Randal L Schwartz writes:\n\nRandal> To bring the tree clean, I issued \"git commit -a -m 'cvs sync'\", and\nRandal> \"git-whatchanged -p\" shows the most recent commit with the diff actually\nRandal> *backed out* the most recent change in CVS, and the next change down was\nRandal> actually the good one. Weird. Do I need to start all over again?\n\nJunio> Also, which branch are you on when you run git-cvsimport, and\nJunio> which branch did the commit 985ca7 go? I suspect it is storing\nJunio> the tip commit 985ca7 to a branch that you are _not_ on\nJunio> currently, but refraining from merging that to your current\nJunio> branch, or something like that.\n\nRandal> Nope. I'm on \"master\", and it should be writing \"master\".\n\nAnd now for grins, I did \"git-reset --hard 'HEAD^^^^^^^'\", verified\nthat the data was in a sensible state from a few weeks back, then\ndid the git-cvsimport, and it replayed the CVS changes to bring it current.\ngit-status showed that seven files were dirty, and \"git-reset --hard\"\ncleared that, and the files were in the right state.\n\nHuh?\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"17608","messageId":"7vk6at7o06.fsf@assigned-by-dhcp.cox.net","threadId":"3656","inReplyTo":"86r75122yj.fsf@blue.stonehenge.com","subject":"Re: git-cvsimport \"you may need to merge manually\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-17T03:23:37Z","receivedAt":"2006-03-17T03:23:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n> Junio> I do not use cvsimport but I wonder what Commit ID 985ca7\n> Junio> contains. Can you try \"git show 985ca7\" and see if that is the\n> Junio> commit you want?\n>\n> To bring the tree clean, I issued \"git commit -a -m 'cvs sync'\", and\n> \"git-whatchanged -p\" shows the most recent commit with the diff actually\n> *backed out* the most recent change in CVS, and the next change down was\n> actually the good one. Weird. Do I need to start all over again?\n\nSo the commit ID reported before the command says Done. was\nactually what you wanted, but that latest tree was not checked\nout cvsimport, so \"git status\" reported \"you have these changes\"\n(it should have said \"you have these backed-out\", but there is\nno way for it to know), and obviously your commit on top of that\nis to back it out.\n\nI just tried it on a copy of my day-job CVS repository. Indeed\nwhat it does seem quite strange.\n\n ...\n skip patchset 1019: 1142562992 before 1142562992\n skip patchset 1020: 1142563093 before 1142563093\n Fetching Makefile v 1.10\n Update Makefile: 871 bytes\n Tree ID 4c51717e01fb08b6d15bc6e35d48142d2d5b94e7\n Parent ID 98d49aa57b93552cea82ce20c880bad4bcc5ebfc\n Committed patch 1021 (master 2006-03-17 03:04:31)\n Commit ID ad6c4fb908df7057d5564bf22cf9e0f9f3e743f2\n DONE\n\n\nIt updated the 'master' branch head, it reported the tip commit\nID before saying DONE, and that commit ID is stored in\nrefs/heads/master. However, it does not seem to touch index nor\nworking tree files (I did not get \"you may need to do merge\"\nmessage, by the way).\n\nSince I know I was just trying things out, I do not care what is\nin my index nor in the working tree files, so I could at this\npoint say:\n\n\t$ git reset --hard\n\nto sync the master tree, but in general you may be running\ncvsimport into a dirty tree, in which case you are screwed.\n\nI think reverting this commit would help, but I do not remember\noffhand what the breakage this patch was trying to fix.\n\n commit a541211ef4136eb7464c4466d20b60b8580efc44\n Author: Matthias Urlichs \n Date: Tue Mar 7 10:08:34 2006 +0100\n\n cvsimport: Remove master-updating code\n\n The code which tried to update the master branch was somewhat broken.\n => People should do that manually, with \"git merge\".\n\n Signed-off-by: Matthias Urlichs \n Signed-off-by: Junio C Hamano \n\n... Ugh, and after I wrote all of the above, the version of git\nI have at work predates that commit X-<. So maybe this was\nfixed with that commit, and you are expected to say:\n\n\t$ git pull . origin\n\nassuming that you are on \"master\" branch and cvsimoprt tracks\nCVS head with \"origin\" branch, that is.\n\nSmurf, help?\n"},{"id":"17609","messageId":"86fylh20x6.fsf@blue.stonehenge.com","threadId":"3656","inReplyTo":"7vk6at7o06.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-cvsimport \"you may need to merge manually\"","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-03-17T03:41:09Z","receivedAt":"2006-03-17T03:41:09Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Junio\" == Junio C Hamano writes:\n\nJunio> Since I know I was just trying things out, I do not care what is\nJunio> in my index nor in the working tree files, so I could at this\nJunio> point say:\n\nJunio> \t$ git reset --hard\n\nJunio> to sync the master tree, but in general you may be running\nJunio> cvsimport into a dirty tree, in which case you are screwed.\n\nYeah, this doesn't make sense. It used to \"Just Work\". I can\ncertainly add \"git reset --hard\" to my workflow, if that's the real\nwork around. And if so, the manpage should document that.\n\nJunio> ... Ugh, and after I wrote all of the above, the version of git\nJunio> I have at work predates that commit X-<. So maybe this was\nJunio> fixed with that commit, and you are expected to say:\n\nJunio> \t$ git pull . origin\n\nJunio> assuming that you are on \"master\" branch and cvsimoprt tracks\nJunio> CVS head with \"origin\" branch, that is.\n\nAgain, if that's the case, the manpage should say what's really\nhappening, so as not to confuse dumb people like me. :)\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"17610","messageId":"7vfylh7lkh.fsf@assigned-by-dhcp.cox.net","threadId":"3656","inReplyTo":"86fylh20x6.fsf@blue.stonehenge.com","subject":"Re: git-cvsimport \"you may need to merge manually\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-17T04:16:14Z","receivedAt":"2006-03-17T04:16:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n> Yeah, this doesn't make sense. It used to \"Just Work\". I can\n> certainly add \"git reset --hard\" to my workflow, if that's the real\n> work around. And if so, the manpage should document that.\n\nThat should _not_ be the solution.\n\nI think the behaviour we are seeing does not make much sense.\nI'll take a deeper look at it tonight (or tomorrow if I am\nunlucky), if nobody beats me to it.\n\nSorry about the breakage.\n"},{"id":"17611","messageId":"86bqw51z5q.fsf@blue.stonehenge.com","threadId":"3656","inReplyTo":"7vfylh7lkh.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-cvsimport \"you may need to merge manually\"","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-03-17T04:19:13Z","receivedAt":"2006-03-17T04:19:13Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Junio\" == Junio C Hamano writes:\n\nJunio> I think the behaviour we are seeing does not make much sense.\nJunio> I'll take a deeper look at it tonight (or tomorrow if I am\nJunio> unlucky), if nobody beats me to it.\n\nJunio> Sorry about the breakage.\n\nNo, *thanks* for looking at it. Your tireless contributions\nare well appreciated.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"17614","messageId":"20060317064618.GG14562@smurf.noris.de","threadId":"3656","inReplyTo":"7vk6at7o06.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-cvsimport \"you may need to merge manually\"","fromName":"","fromEmail":"smurf@smurf.noris.de","sentAt":"2006-03-17T06:46:18Z","receivedAt":"2006-03-17T06:46:18Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi,\n\nJunio C Hamano:\n> ... Ugh, and after I wrote all of the above, the version of git\n> I have at work predates that commit X-<. So maybe this was\n> fixed with that commit, and you are expected to say:\n> \n> \t$ git pull . origin\n> \nExactly.\n\n> assuming that you are on \"master\" branch and cvsimoprt tracks\n> CVS head with \"origin\" branch, that is.\n> \n> Smurf, help?\n> \nWhat for? You got it, after all. *g*\n\n-- \nMatthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nSally sued for support; she was claimin'\nPhil had fathered her baby (named Damon).\n She said, \"I ought to know,\"\n As she pointed below.\n\"'Cause this is the box that he came in.\"\n"},{"id":"17615","messageId":"20060317072602.GH14562@smurf.noris.de","threadId":"3656","inReplyTo":"86fylh20x6.fsf@blue.stonehenge.com","subject":"Re: git-cvsimport \"you may need to merge manually\"","fromName":"","fromEmail":"smurf@smurf.noris.de","sentAt":"2006-03-17T07:26:02Z","receivedAt":"2006-03-17T07:26:02Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi,\n\nRandal L. Schwartz:\n> Yeah, this doesn't make sense. It used to \"Just Work\". I can\n> certainly add \"git reset --hard\" to my workflow, if that's the real\n> work around. And if so, the manpage should document that.\n> \nThe real workaround is not to import into live branches,\nwhich is not a git-cvs-specific problem, so I didn't add that\nto its manpage.\n\nI'm not opposed to an appropriate patch if you think its necessary.\nIf you do, keep in mind that there are other git-*import scripts out\nthere which presumably have the same problem. ;-)\n\n-- \nMatthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nThat which is good to be done, cannot be done too soon; and if it is\nneglected to be done early, it will frequently happen that it will not be done\nat all.\n\t\t\t\t\t-- Bishop Mant\n"},{"id":"17616","messageId":"7vk6at1on6.fsf@assigned-by-dhcp.cox.net","threadId":"3656","inReplyTo":"20060317064618.GG14562@smurf.noris.de","subject":"Re: git-cvsimport \"you may need to merge manually\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-17T08:06:21Z","receivedAt":"2006-03-17T08:06:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"smurf@smurf.noris.de writes:\n\n> Junio C Hamano:\n>> ..., and you are expected to say:\n>> \n>> \t$ git pull . origin\n>> \n> Exactly.\n\nI think the second and subsequent run of \"git cvsimport\"\ncurrently is similar to \"git fetch\", but earlier one that tried\nto do checkout was probably similar to \"git pull\". I think most\npeople would expect it to behave more like \"git pull\",\ni.e. fetch from the upstream (that happens to be CVS) and merge\nthat into your branch. It may not be operated that way\ncorrectly and that might have been the reason we removed the\n\"master updates\" code, but if that is the case I'd rather fix it\nproperly.\n\n>> assuming that you are on \"master\" branch and cvsimoprt tracks\n>> CVS head with \"origin\" branch, that is.\n>> \n>> Smurf, help?\n>> \n> What for? You got it, after all. *g*\n\nNot really, I am afraid. There is one snag _if_ you use the\ncurrent branch as the tracking branch. Merlyn's setup is\nexactly that -- he has \"master\" which is given to the command\nwith -o flag. The branch head commit is already updated, but\nthe index and working tree is not.\n\nNow, unlike git-fetch, git-cvsimport _requires_ you to have a\npristine tracking branch (otherwise we cannot discard already\nseen patchsets from what we read from CVSPS), and leaving that\ntracking branch checked out is calling for trouble because you\nmight be tempted to make your own commit on top of it. So we\ncould argue that one solution would be to forbid importing into\nthe current branch.\n\nBut that breaks well behaving people who are used to leave a\ntracking branch checked out _and_ promises not to touch that\nbranch head from the git side.\n\nSo what I would suggest is to do something like this:\n\n - Before starting to interpret CVSPS output, keep the commit\n object name of the current branch tip.\n\n - After we are done, read the current branch tip. If they are\n different, we updated the current branch tip without matching\n the index and working tree, so we match them just like\n git-pull does. Otherwise, we run 'git-merge' to merge the\n $opt_o branch into the current branch.\n\nThat is, perhaps, like this untested patch. What do you think?\n\n-- >8 --\ncvsimport: act more like pull, not fetch\n\nAfter updating tracking branches with upstream CVS changes, if\nthe current branch is one of the tracking branches, match the\nindex and working tree just like \"git-pull\" that was started\nwith one of the tracking branches checked out. Otherwise, merge\nthe trunk ($opt_o) branch into the current branch. This would\nmatch users' expectation more closely.\n\nSigned-off-by: Junio C Hamano \n---\n\ndiff --git a/git-cvsimport.perl b/git-cvsimport.perl\nindex 02d1928..b9cebaf 100755\n--- a/git-cvsimport.perl\n+++ b/git-cvsimport.perl\n@@ -453,6 +453,7 @@ chdir($git_tree);\n my $last_branch = \"\";\n my $orig_branch = \"\";\n my %branch_date;\n+my $tip_at_start = undef;\n \n my $git_dir = $ENV{\"GIT_DIR\"} || \".git\";\n $git_dir = getwd().\"/\".$git_dir unless $git_dir =~ m#^/#;\n@@ -487,6 +488,7 @@ unless(-d $git_dir) {\n \t\t$last_branch = \"master\";\n \t}\n \t$orig_branch = $last_branch;\n+\t$tip_at_start = `git-rev-parse --verify HEAD`;\n \n \t# populate index\n \tsystem('git-read-tree', $last_branch);\n@@ -873,7 +875,18 @@ if (defined $orig_git_index) {\n \n # Now switch back to the branch we were in before all of this happened\n if($orig_branch) {\n-\tprint \"DONE; you may need to merge manually.\\n\" if $opt_v;\n+\tprint \"DONE.\\n\" if $opt_v;\n+\tmy $tip_at_end = `git-rev-parse --verify HEAD`;\n+\tif ($tip_at_start ne $tip_at_end) {\n+\t\tprint \"Fetched into the current branch.\\n\" if $opt_v;\n+\t\tsystem(qw(git-read-tree -u -m),\n+\t\t $tip_at_start, $tip_at_end);\n+\t\tdie \"Fast-forward update failed: $?\\n\" if $?;\n+\t}\n+\telse {\n+\t\tsystem(qw(git-merge cvsimport HEAD), \"refs/heads/$opt_o\");\n+\t\tdie \"Could not merge $opt_o into the current branch.\\n\" if $?;\n+\t}\n } else {\n \t$orig_branch = \"master\";\n \tprint \"DONE; creating $orig_branch branch\\n\" if $opt_v;\n"},{"id":"17617","messageId":"7vfylh1ojv.fsf@assigned-by-dhcp.cox.net","threadId":"3656","inReplyTo":"20060317072602.GH14562@smurf.noris.de","subject":"Re: git-cvsimport \"you may need to merge manually\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-17T08:08:20Z","receivedAt":"2006-03-17T08:08:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"smurf@smurf.noris.de writes:\n\n> The real workaround is not to import into live branches,\n> which is not a git-cvs-specific problem, so I didn't add that\n> to its manpage.\n\nYes. I sufferred the same problem when I did git-fetch/git-pull,\nand there is a clever/ugly workaround for that.\n"},{"id":"17658","messageId":"7vveubqqz8.fsf@assigned-by-dhcp.cox.net","threadId":"3656","inReplyTo":"86bqw51z5q.fsf@blue.stonehenge.com","subject":"Re: git-cvsimport \"you may need to merge manually\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-18T23:21:15Z","receivedAt":"2006-03-18T23:21:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I tested the version in today's \"next\" branch, and it fixes the\nproblem for me in my tests that use my day-job CVS repository as\na guinea pig.\n\nIn case you are not brave enough to switch to \"next\" wholesale,\nbut are kind enough to try out the relevant cvsimport change for\nus, here is a patch that applies on top of \"master\". It is a\nroll-up of two commits on my jc/cvsimport branch.\n\n-- >8 --\ncvsimport: honor -i and non -i upon subsequent imports\n\nDocumentation says -i is \"import only\", so without it,\nsubsequent import should update the current branch and working\ntree files in a sensible way.\n\n\"A sensible way\" defined by this commit is \"act as if it is a\ngit pull from foreign repository which happens to be CVS not\ngit\". So:\n\n - If importing into the current branch (note that cvsimport\n requires the tracking branch is pristine -- you checked out\n the tracking branch but it is your responsibility not to make\n your own commits there), fast forward the branch head and\n match the index and working tree using two-way merge, just\n like \"git pull\" does.\n\n - If importing into a separate tracking branch, update that\n branch head, and merge it into your current branch, again,\n just like \"git pull\" does.\n\nInitial round of the updated code read the tip of the current\nbranch before and after the import runs, but forgot to chomp\nwhat we read from the command. The read-tree command did not\nthem with the trailing LF. This has been fixed.\n\n---\n\ndiff --git a/git-cvsimport.perl b/git-cvsimport.perl\nindex 02d1928..3728294 100755\n--- a/git-cvsimport.perl\n+++ b/git-cvsimport.perl\n@@ -453,6 +453,7 @@ chdir($git_tree);\n my $last_branch = \"\";\n my $orig_branch = \"\";\n my %branch_date;\n+my $tip_at_start = undef;\n \n my $git_dir = $ENV{\"GIT_DIR\"} || \".git\";\n $git_dir = getwd().\"/\".$git_dir unless $git_dir =~ m#^/#;\n@@ -487,6 +488,7 @@ unless(-d $git_dir) {\n \t\t$last_branch = \"master\";\n \t}\n \t$orig_branch = $last_branch;\n+\t$tip_at_start = `git-rev-parse --verify HEAD`;\n \n \t# populate index\n \tsystem('git-read-tree', $last_branch);\n@@ -873,7 +875,22 @@ if (defined $orig_git_index) {\n \n # Now switch back to the branch we were in before all of this happened\n if($orig_branch) {\n-\tprint \"DONE; you may need to merge manually.\\n\" if $opt_v;\n+\tprint \"DONE.\\n\" if $opt_v;\n+\tif ($opt_i) {\n+\t\texit 0;\n+\t}\n+\tmy $tip_at_end = `git-rev-parse --verify HEAD`;\n+\tif ($tip_at_start ne $tip_at_end) {\n+\t\tfor ($tip_at_start, $tip_at_end) { chomp; }\n+\t\tprint \"Fetched into the current branch.\\n\" if $opt_v;\n+\t\tsystem(qw(git-read-tree -u -m),\n+\t\t $tip_at_start, $tip_at_end);\n+\t\tdie \"Fast-forward update failed: $?\\n\" if $?;\n+\t}\n+\telse {\n+\t\tsystem(qw(git-merge cvsimport HEAD), \"refs/heads/$opt_o\");\n+\t\tdie \"Could not merge $opt_o into the current branch.\\n\" if $?;\n+\t}\n } else {\n \t$orig_branch = \"master\";\n \tprint \"DONE; creating $orig_branch branch\\n\" if $opt_v;\n"}]}