{"thread":{"id":"45976","subject":"How to force a pull to succeed?","startedAt":"2017-05-16T02:17:40Z","lastAt":"2017-05-16T06:59:48Z","messageCount":6,"participants":["Jeffrey Walton","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"319864","messageId":"CAH8yC8k8sTGDA=C8vLCE090Y1B4TK86bOnZMNjj13C-JXVEBHQ@mail.gmail.com","threadId":"45976","inReplyTo":null,"subject":"How to force a pull to succeed?","fromName":"Jeffrey Walton","fromEmail":"noloader@gmail.com","sentAt":"2017-05-16T02:17:33Z","receivedAt":"2017-05-16T02:17:40Z","isPatch":false,"sender":{"key":"noloader@gmail.com","avatar":null},"body":"I scp'd a file to another machine for testing. The change tested OK,\nso I checked it in on the original machine.\n\nI'm now on the remote machine, and I'm trying to pull the same exact\nfile that exists on both local and remote. Git won't allow me to do\nit, even with -f.\n\nI'd really like -f (or another switch) to work as expected. I don't\nlike issuing extra command or extra typing.\n\nHow do I force the pull to succeed?\n\nThanks in adavnce.\n\n**************\n\nqotom:cryptopp$ git pull\nUpdating 30ac06d..30ac53f\nerror: Your local changes to the following files would be overwritten by merge:\n datatest.cpp\nPlease commit your changes or stash them before you merge.\nAborting\nqotom:cryptopp$ git pull -f\nUpdating 30ac06d..30ac53f\nerror: Your local changes to the following files would be overwritten by merge:\n datatest.cpp\nPlease commit your changes or stash them before you merge.\n"},{"id":"319870","messageId":"xmqq8tlx4h1y.fsf@gitster.mtv.corp.google.com","threadId":"45976","inReplyTo":"CAH8yC8k8sTGDA=C8vLCE090Y1B4TK86bOnZMNjj13C-JXVEBHQ@mail.gmail.com","subject":"Re: How to force a pull to succeed?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-05-16T03:27:37Z","receivedAt":"2017-05-16T03:27:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeffrey Walton writes:\n\n> I scp'd a file to another machine for testing. The change tested OK,\n> so I checked it in on the original machine.\n> ...\n> How do I force the pull to succeed?\n\nGit doesn't know (or care) if you \"scp\"ed a file from a known to be\ngood place, or if you modified it in the editor. When it notices\nthat there are differences you may rather not to lose in these files\n(because they are different from HEAD), it refrains from touching\nthem.\n\nSo the way to go forward is for you to make sure that you do not\nhave such local changes in the repository that your \"pull\" is trying\nto touch. An easiest way would be to do\n\n\tgit checkout HEAD -- ..\n\nbefore doing a \"git pull\" to clear the damage you caused manually\nwith your \"scp\". \n"},{"id":"319871","messageId":"CAH8yC8mOc68A-0uM8b3AKAYo9VqYNUjHkGw0knbXL0suM25tfA@mail.gmail.com","threadId":"45976","inReplyTo":"xmqq8tlx4h1y.fsf@gitster.mtv.corp.google.com","subject":"Re: How to force a pull to succeed?","fromName":"Jeffrey Walton","fromEmail":"noloader@gmail.com","sentAt":"2017-05-16T03:32:33Z","receivedAt":"2017-05-16T03:32:40Z","isPatch":false,"sender":{"key":"noloader@gmail.com","avatar":null},"body":"On Mon, May 15, 2017 at 11:27 PM, Junio C Hamano wrote:\n> Jeffrey Walton writes:\n>\n>> I scp'd a file to another machine for testing. The change tested OK,\n>> so I checked it in on the original machine.\n>> ...\n>> How do I force the pull to succeed?\n>\n> Git doesn't know (or care) if you \"scp\"ed a file from a known to be\n> good place, or if you modified it in the editor. When it notices\n> that there are differences you may rather not to lose in these files\n> (because they are different from HEAD), it refrains from touching\n> them.\n>\n> So the way to go forward is for you to make sure that you do not\n> have such local changes in the repository that your \"pull\" is trying\n> to touch. An easiest way would be to do\n>\n> git checkout HEAD -- ..\n\nThanks. That's an extra command. Is there any way to roll it up into\none command?\n\n> before doing a \"git pull\" to clear the damage you caused manually\n> with your \"scp\".\n\nThere's no damage. Its expected.\n\nJeff\n"},{"id":"319874","messageId":"xmqqmvad31sr.fsf@gitster.mtv.corp.google.com","threadId":"45976","inReplyTo":"CAH8yC8mOc68A-0uM8b3AKAYo9VqYNUjHkGw0knbXL0suM25tfA@mail.gmail.com","subject":"Re: How to force a pull to succeed?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-05-16T03:42:28Z","receivedAt":"2017-05-16T03:42:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeffrey Walton writes:\n\n> On Mon, May 15, 2017 at 11:27 PM, Junio C Hamano wrote:\n>> Jeffrey Walton writes:\n>>\n>>> I scp'd a file to another machine for testing. The change tested OK,\n>>> so I checked it in on the original machine.\n>>> ...\n>>> How do I force the pull to succeed?\n>>\n>> Git doesn't know (or care) if you \"scp\"ed a file from a known to be\n>> good place, or if you modified it in the editor. When it notices\n>> that there are differences you may rather not to lose in these files\n>> (because they are different from HEAD), it refrains from touching\n>> them.\n>>\n>> So the way to go forward is for you to make sure that you do not\n>> have such local changes in the repository that your \"pull\" is trying\n>> to touch. An easiest way would be to do\n>>\n>> git checkout HEAD -- ..\n>\n> Thanks. That's an extra command. Is there any way to roll it up into\n> one command?\n\n git checkout HEAD -- .. && git pull\n\n;-)\n\n>> before doing a \"git pull\" to clear the damage you caused manually\n>> with your \"scp\".\n>\n> There's no damage. Its expected.\n\nThe fact that you think it is expected is immaterial. Git doesn't\nknow (or care) how you made the files different from HEAD, so it\nlooks like a damage to it.\n\n"},{"id":"319875","messageId":"CAH8yC8kVFGe9gnj8P+=Pp1ToDvMPXiViVM-HzhkZ6SAteoPZaQ@mail.gmail.com","threadId":"45976","inReplyTo":"xmqqmvad31sr.fsf@gitster.mtv.corp.google.com","subject":"Re: How to force a pull to succeed?","fromName":"Jeffrey Walton","fromEmail":"noloader@gmail.com","sentAt":"2017-05-16T03:47:14Z","receivedAt":"2017-05-16T03:47:20Z","isPatch":false,"sender":{"key":"noloader@gmail.com","avatar":null},"body":"On Mon, May 15, 2017 at 11:42 PM, Junio C Hamano wrote:\n> Jeffrey Walton writes:\n>\n>> On Mon, May 15, 2017 at 11:27 PM, Junio C Hamano wrote:\n>>> Jeffrey Walton writes:\n>>>\n>>>> I scp'd a file to another machine for testing. The change tested OK,\n>>>> so I checked it in on the original machine.\n>>>> ...\n>>>> How do I force the pull to succeed?\n>>>\n>>> Git doesn't know (or care) if you \"scp\"ed a file from a known to be\n>>> good place, or if you modified it in the editor. When it notices\n>>> that there are differences you may rather not to lose in these files\n>>> (because they are different from HEAD), it refrains from touching\n>>> them.\n>>>\n>>> So the way to go forward is for you to make sure that you do not\n>>> have such local changes in the repository that your \"pull\" is trying\n>>> to touch. An easiest way would be to do\n>>>\n>>> git checkout HEAD -- ..\n>>\n>> Thanks. That's an extra command. Is there any way to roll it up into\n>> one command?\n>\n> git checkout HEAD -- .. && git pull\n>\n> ;-)\n>\n>>> before doing a \"git pull\" to clear the damage you caused manually\n>>> with your \"scp\".\n>>\n>> There's no damage. Its expected.\n>\n> The fact that you think it is expected is immaterial. Git doesn't\n> know (or care) how you made the files different from HEAD, so it\n> looks like a damage to it.\n\n'git pull' fails and its expected, but 'git pull -f' is supposed to\nsucceed. That's what -f is supposed to do.\n\nIs there a way to add intelligence to Git so that it sees they are the\n_exact_ same file, and it stops bothering me with details of problems\nthat don't exist?\n\nIt seems like adding the intelligence is a good enhancement. A version\ncontrol tool has to do three things: check-out, check-in, and\ndetermine differences. Its not doing a good job of determining\ndifferences considering they are the exact same file.\n\nJeff\n"},{"id":"319896","messageId":"20170516065939.uy3ib7z2v6gkldox@sigill.intra.peff.net","threadId":"45976","inReplyTo":"CAH8yC8kVFGe9gnj8P+=Pp1ToDvMPXiViVM-HzhkZ6SAteoPZaQ@mail.gmail.com","subject":"Re: How to force a pull to succeed?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-05-16T06:59:40Z","receivedAt":"2017-05-16T06:59:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 15, 2017 at 11:47:14PM -0400, Jeffrey Walton wrote:\n\n> > The fact that you think it is expected is immaterial. Git doesn't\n> > know (or care) how you made the files different from HEAD, so it\n> > looks like a damage to it.\n> \n> 'git pull' fails and its expected, but 'git pull -f' is supposed to\n> succeed. That's what -f is supposed to do.\n\nWell, no. \"pull -f\" does something else, and is documented as such.\n\n> Is there a way to add intelligence to Git so that it sees they are the\n> _exact_ same file, and it stops bothering me with details of problems\n> that don't exist?\n> \n> It seems like adding the intelligence is a good enhancement. A version\n> control tool has to do three things: check-out, check-in, and\n> determine differences. Its not doing a good job of determining\n> differences considering they are the exact same file.\n\nAFAICT there are basically two changes we could consider here:\n\n 1. Some kind of --force option to git-merge and git-pull that just\n overwrites files, regardless of content. That's not much better\n than \"git reset --hard && git merge\", but I suppose it might save\n the state of files that wouldn't otherwise be affected by the\n merge. We already have something similar for \"checkout -f\".\n\n 2. Right now the verify_uptodate() check happens deep in unpack-trees,\n which doesn't actually know what the merge result is going to be\n for that file. In some cases (like yours) the threeway result is\n trivial, but in others it requires doing an actual content-level\n merge. But in theory we could get the entire merge result and only\n then decide whether to write it in place (after comparing to the\n on-disk contents).\n\n I suspect that covering the latter would take some major surgery to\n the way that the merge code works. The trivial cases could probably\n be handled inside unpack-trees.\n\nNeither seem totally unreasonable to me. But without working patches,\nthere's not much to discuss.\n\n-Peff\n"}]}