{"thread":{"id":"30224","subject":"GIT pull","startedAt":"2012-04-12T14:47:57Z","lastAt":"2012-04-12T17:29:03Z","messageCount":5,"participants":["cvalusek","Matthieu Moy","Michael Witten","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"189103","messageId":"1334242077960-7459655.post@n2.nabble.com","threadId":"30224","inReplyTo":null,"subject":"GIT pull","fromName":"cvalusek","fromEmail":"clintv2@gmail.com","sentAt":"2012-04-12T14:47:57Z","receivedAt":"2012-04-12T14:47:57Z","isPatch":false,"sender":{"key":"clintv2@gmail.com","avatar":null},"body":"My apologies if this isn't the appropriate place to post this. We are using\nthe windows port msysgit so I understand if I need to post over there first.\n\nI have also posted this on stackoverflow. Here is a link to the question\nthere:\n\nhttp://stackoverflow.com/questions/10110401/why-doesnt-git-clean-up-when-aborting-a-merge-triggered-from-pulling-in-changes\n\nMy team has had a lot of trouble with GIT lately because of aborted pull\ncommands.\n\nIf a user has local modifications not on the index and does a pull, I have\nseen git attempt to start applying the merge to master and abort. The whole\ncheckout is then left in a terrible state that is nearly unrecoverable. In\nthe past, I thought GIT would run some sort of check to identify these\nproblems before it attempts the merge.\n\nEven with a clean state (nothing to commit), I have seen the same thing\nrandomly happen at least once. I understand that without rebasing, you may\nbe forced to resolve merge conflicts when you pull, but this is not what is\nhappening though.\n\nWe are using gitolite. I am mainly using command line and have yet to run\ninto these issues. The rest of the team is using the git-gui or in 1 case\nTortoiseGit.\n\ngit-gui version 0.13.GITGUI\ngit version 1.7.8.msysgit.0\nTcl/Tk version 8.5.1\nTortoiseGit 1.7.6.0\n\nWe are not working with branches as much as we could, but feel like this\nshould be working.\nWhy does GIT allow you to try to pull when it is going to train-wreck?\nWhy does GIT not abort cleanly?\n\n--\nView this message in context: http://git.661346.n2.nabble.com/GIT-pull-tp7459655p7459655.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"189104","messageId":"vpqiph5m1pd.fsf@bauges.imag.fr","threadId":"30224","inReplyTo":"1334242077960-7459655.post@n2.nabble.com","subject":"Re: GIT pull","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-04-12T15:03:58Z","receivedAt":"2012-04-12T15:03:58Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"cvalusek writes:\n\n> If a user has local modifications not on the index and does a pull, I have\n> seen git attempt to start applying the merge to master and abort. The whole\n> checkout is then left in a terrible state that is nearly\n> unrecoverable.\n\nWhat do you mean by \"terrible state\"? What does \"git status\" say?\n\n> In the past, I thought GIT would run some sort of check to identify\n> these problems before it attempts the merge.\n\nGit does check uncommited changes before merging. It allows the merge if\nthe changes touch different files (i.e. if the merge is guaranteed not\nto touch the same files as the one for which you have uncommited\nchanges).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"189106","messageId":"CAMOZ1Bs+vvoNJ5jiKEkc-VBBR0Bj_ik9bu6TfKd-0r70Ss0mPg@mail.gmail.com","threadId":"30224","inReplyTo":"vpqiph5m1pd.fsf@bauges.imag.fr","subject":"Re: GIT pull","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2012-04-12T15:07:16Z","receivedAt":"2012-04-12T15:07:16Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Thu, Apr 12, 2012 at 15:03, Matthieu Moy\n wrote:\n> cvalusek writes:\n>\n>> If a user has local modifications not on the index and does a pull, I have\n>> seen git attempt to start applying the merge to master and abort. The whole\n>> checkout is then left in a terrible state that is nearly\n>> unrecoverable.\n>\n> What do you mean by \"terrible state\"? What does \"git status\" say?\n>\n>> In the past, I thought GIT would run some sort of check to identify\n>> these problems before it attempts the merge.\n>\n> Git does check uncommited changes before merging. It allows the merge if\n> the changes touch different files (i.e. if the merge is guaranteed not\n> to touch the same files as the one for which you have uncommited\n> changes).\n\nAlso, if there *are* conflicts, then you should get an error that\nlooks like the following:\n\n error: Your local changes to the following files would be\n overwritten by merge:\n \tsome-file.txt\n Please, commit your changes or stash them before you can merge.\n Aborting\n\nSincerely,\nMichael Witten\n"},{"id":"189119","messageId":"4F8709CA.6080102@kdbg.org","threadId":"30224","inReplyTo":"1334242077960-7459655.post@n2.nabble.com","subject":"Re: GIT pull","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2012-04-12T16:58:50Z","receivedAt":"2012-04-12T16:58:50Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 12.04.2012 16:47, schrieb cvalusek:\n> My team has had a lot of trouble with GIT lately because of aborted pull\n> commands.\n> \n> If a user has local modifications not on the index and does a pull, I have\n> seen git attempt to start applying the merge to master and abort. The whole\n> checkout is then left in a terrible state that is nearly unrecoverable. In\n> the past, I thought GIT would run some sort of check to identify these\n> problems before it attempts the merge.\n> \n> Even with a clean state (nothing to commit), I have seen the same thing\n> randomly happen at least once.\n\nAs others pointed out, this should not happen. That leaves one\npossibility: You are on Windows, and you very likely have one or more of\n\n- a virus scanner\n- an IDE\n\nrunning. It can happen that one of these programs happen to look at a\nfile at the same moment when git is trying to remove or rename the file.\nThis fails because on Windows a file that is open cannot be removed or\nrenamed. In this situation, the merge/checkout is aborted in the middle\nand leaves a mess behind.\n\nThere's not a lot that can be done about it. I thought we have some\ncounter measures in our compatibility layer (e.g., retry the removal if\nthe first attempt fails due to permissions), but I have seen this happen\nnevertheless. I haven't tried tracking it down because it happens so\nrarely for me, and it didn't hurt *too* much so far.\n\n-- Hannes\n"},{"id":"189121","messageId":"1334251743350-7460163.post@n2.nabble.com","threadId":"30224","inReplyTo":"1334242077960-7459655.post@n2.nabble.com","subject":"Re: GIT pull","fromName":"cvalusek","fromEmail":"clintv2@gmail.com","sentAt":"2012-04-12T17:29:03Z","receivedAt":"2012-04-12T17:29:03Z","isPatch":false,"sender":{"key":"clintv2@gmail.com","avatar":null},"body":"Looks like it's the virus scan. I had this e-mail that I accidentally sent to\nMichael directly instead of the list:\n\nI will see if I can build a script that reproduces the issue we are seeing. \n\nWe are starting to speculate about what is going on now. Maybe our virus\nscan is causing some git operation to fail in the middle of the merge.\n\nThe \"terrible state\" is a half-way applied merge.\n\n--\nView this message in context: http://git.661346.n2.nabble.com/GIT-pull-tp7459655p7460163.html\nSent from the git mailing list archive at Nabble.com.\n"}]}