{"thread":{"id":"56583","subject":"pull failed - why should I receive this message.","startedAt":"2021-09-24T17:08:13Z","lastAt":"2021-09-24T20:49:55Z","messageCount":11,"participants":["Russell, Scott","Emily Shaffer","Randall S. Becker","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"436978","messageId":"BN6PR15MB1426A342CBA9D993C0C49E55CBA49@BN6PR15MB1426.namprd15.prod.outlook.com","threadId":"56583","inReplyTo":null,"subject":"pull failed - why should I receive this message.","fromName":"Russell, Scott","fromEmail":"scott.russell2@ncr.com","sentAt":"2021-09-24T14:48:59Z","receivedAt":"2021-09-24T17:08:13Z","isPatch":false,"sender":{"key":"scott.russell2@ncr.com","avatar":null},"body":"Files not previously in git were added to git. Why should I have to manually delete them? \nWhy can git put not replace them? They were untracked files that are now tracked and so the git copy is desired. \nWe can't always know ahead of time what files may have been added elsewhere. \nWe need the pull to work automatically. \n\nerror: The following untracked working tree files would be overwritten by merge:\n Staging/CADDApps/CADDUIHelper/Source/Release/CADDUIHelper.exe\n Staging/CADDApps/CADDUIHelper/Source/Release_Unicode/CADDUIHelper.exe\n Staging/CADDApps/InstallDriversPackage/Release/InstallDriversPackage.exe\n Staging/Common/NCRCommonCCLib/Source/Release/NCRCommonCCLibMsg.dll\n Staging/Devices/NFC/Elatec_RFIDReader/Bin/Director.exe\n Staging/Devices/NFC/Elatec_RFIDReader/Firmware/AppBlaster.exe\n Staging/Devices/NFC/Elatec_RFIDReader/Firmware/flash.exe\n Staging/Utilities64/SSPSWDriverInstaller/Bin/DIFxAPI.dll\n Staging/Utilities64/SSPSWDriverInstaller/Bin/DriverForge.v4.5.4.exe\n Staging/Utilities64/SSPSWDriverInstaller/Source/Release/SSPSWDriverInstaller.exe\n Staging/Utilities64/SSPSWDriverInstaller/Source/Release/SSPSWDriverInstallerMsg.dll\n Staging/Utilities64/SSPSWTaskMgr/Source/Release/SSPSWTaskMgr.exe\nPlease move or remove them before you merge.\nAborting\nUpdating e6f37b6878..02aa693031\n\n\nThanks, \n\nScott Russell\nScott.Russell2@ncr.com | ncr.com\n \n\n"},{"id":"436981","messageId":"CAJoAoZ=DuqHe2brN8Y2Ts0_afEhUNrdasRBb1O8HHomLKRJ4PA@mail.gmail.com","threadId":"56583","inReplyTo":"BN6PR15MB1426A342CBA9D993C0C49E55CBA49@BN6PR15MB1426.namprd15.prod.outlook.com","subject":"Re: pull failed - why should I receive this message.","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2021-09-24T17:28:34Z","receivedAt":"2021-09-24T17:28:50Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Fri, Sep 24, 2021 at 10:08 AM Russell, Scott wrote:\n>\n> Files not previously in git were added to git. Why should I have to manually delete them?\n> Why can git put not replace them? They were untracked files that are now tracked and so the git copy is desired.\n> We can't always know ahead of time what files may have been added elsewhere.\n\nTo turn it around on you, you can't always know ahead of time what\nfiles may have been added elsewhere, so you can't be sure that your\nnewly added untracked file locally will be safe from being overwritten\nduring a pull. How upsetting if you sink 30 hours into newlib.cpp and\nthen your teammate checks in their own newlib.cpp, and yours is\noverwritten without asking when you run 'git pull'.\n\nYou might have some luck with the '--autostash' option, which would at\nleast prompt you whether to get rid of things when trying to merge\nthem back together during the automatic 'git stash pop' at the end. Or\nyou could run 'git clean --force' to automatically delete any\nuntracked files you might have - you could even alias yourself a\ncommand like 'git dangerous-pull' which runs 'git clean -f && git\npull'.\n\n>\n>\n> We need the pull to work automatically.\n>\n> error: The following untracked working tree files would be overwritten by merge:\n> Staging/CADDApps/CADDUIHelper/Source/Release/CADDUIHelper.exe\n> Staging/CADDApps/CADDUIHelper/Source/Release_Unicode/CADDUIHelper.exe\n> Staging/CADDApps/InstallDriversPackage/Release/InstallDriversPackage.exe\n> Staging/Common/NCRCommonCCLib/Source/Release/NCRCommonCCLibMsg.dll\n> Staging/Devices/NFC/Elatec_RFIDReader/Bin/Director.exe\n> Staging/Devices/NFC/Elatec_RFIDReader/Firmware/AppBlaster.exe\n> Staging/Devices/NFC/Elatec_RFIDReader/Firmware/flash.exe\n> Staging/Utilities64/SSPSWDriverInstaller/Bin/DIFxAPI.dll\n> Staging/Utilities64/SSPSWDriverInstaller/Bin/DriverForge.v4.5.4.exe\n> Staging/Utilities64/SSPSWDriverInstaller/Source/Release/SSPSWDriverInstaller.exe\n> Staging/Utilities64/SSPSWDriverInstaller/Source/Release/SSPSWDriverInstallerMsg.dll\n> Staging/Utilities64/SSPSWTaskMgr/Source/Release/SSPSWTaskMgr.exe\n\nOr better yet, you could avoid checking in compiled binaries like\nthese and instead add them to your .gitignore, unless you really mean\nto update them every time someone makes some change. When checking in\nbinaries, you should be aware of the additional disk overhead needed\nto do so and take a look at some options Git has to mitigate that\noverhead, like partial clone. However, in many cases the easiest way\nto mitigate that overhead is to simply not check in binaries unless\nyou absolutely need them to be version controlled.\n\n- Emily\n"},{"id":"436982","messageId":"BN6PR15MB14261D1A350398C0C26793E1CBA49@BN6PR15MB1426.namprd15.prod.outlook.com","threadId":"56583","inReplyTo":"CAJoAoZ=DuqHe2brN8Y2Ts0_afEhUNrdasRBb1O8HHomLKRJ4PA@mail.gmail.com","subject":"RE: pull failed - why should I receive this message.","fromName":"Russell, Scott","fromEmail":"scott.russell2@ncr.com","sentAt":"2021-09-24T17:34:27Z","receivedAt":"2021-09-24T17:34:51Z","isPatch":false,"sender":{"key":"scott.russell2@ncr.com","avatar":null},"body":"Thanks for your answer. Is there not an option on the pull to have git to overwrite the existing files? \n\n\nThanks, \n\nScott Russell\nStaff SW Engineer \nNCR Corporation \nPhone: +17706237512\nScott.Russell2@ncr.com | ncr.com\n \n\n-----Original Message-----\nFrom: Emily Shaffer \nSent: Friday, September 24, 2021 1:29 PM\nTo: Russell, Scott \nCc: git@vger.kernel.org\nSubject: Re: pull failed - why should I receive this message.\n\n*External Message* - Use caution before opening links or attachments\n\nOn Fri, Sep 24, 2021 at 10:08 AM Russell, Scott wrote:\n>\n> Files not previously in git were added to git. Why should I have to manually delete them?\n> Why can git put not replace them? They were untracked files that are now tracked and so the git copy is desired.\n> We can't always know ahead of time what files may have been added elsewhere.\n\nTo turn it around on you, you can't always know ahead of time what files may have been added elsewhere, so you can't be sure that your newly added untracked file locally will be safe from being overwritten during a pull. How upsetting if you sink 30 hours into newlib.cpp and then your teammate checks in their own newlib.cpp, and yours is overwritten without asking when you run 'git pull'.\n\nYou might have some luck with the '--autostash' option, which would at least prompt you whether to get rid of things when trying to merge them back together during the automatic 'git stash pop' at the end. Or you could run 'git clean --force' to automatically delete any untracked files you might have - you could even alias yourself a command like 'git dangerous-pull' which runs 'git clean -f && git pull'.\n\n>\n>\n> We need the pull to work automatically.\n>\n> error: The following untracked working tree files would be overwritten by merge:\n> Staging/CADDApps/CADDUIHelper/Source/Release/CADDUIHelper.exe\n> Staging/CADDApps/CADDUIHelper/Source/Release_Unicode/CADDUIHelper.exe\n> Staging/CADDApps/InstallDriversPackage/Release/InstallDriversPackage.exe\n> Staging/Common/NCRCommonCCLib/Source/Release/NCRCommonCCLibMsg.dll\n> Staging/Devices/NFC/Elatec_RFIDReader/Bin/Director.exe\n> Staging/Devices/NFC/Elatec_RFIDReader/Firmware/AppBlaster.exe\n> Staging/Devices/NFC/Elatec_RFIDReader/Firmware/flash.exe\n> Staging/Utilities64/SSPSWDriverInstaller/Bin/DIFxAPI.dll\n> Staging/Utilities64/SSPSWDriverInstaller/Bin/DriverForge.v4.5.4.exe\n> Staging/Utilities64/SSPSWDriverInstaller/Source/Release/SSPSWDriverInstaller.exe\n> Staging/Utilities64/SSPSWDriverInstaller/Source/Release/SSPSWDriverInstallerMsg.dll\n> \n> Staging/Utilities64/SSPSWTaskMgr/Source/Release/SSPSWTaskMgr.exe\n\nOr better yet, you could avoid checking in compiled binaries like these and instead add them to your .gitignore, unless you really mean to update them every time someone makes some change. When checking in binaries, you should be aware of the additional disk overhead needed to do so and take a look at some options Git has to mitigate that overhead, like partial clone. However, in many cases the easiest way to mitigate that overhead is to simply not check in binaries unless you absolutely need them to be version controlled.\n\n- Emily\n"},{"id":"436991","messageId":"000401d7b16e$17ea02d0$47be0870$@nexbridge.com","threadId":"56583","inReplyTo":"BN6PR15MB14261D1A350398C0C26793E1CBA49@BN6PR15MB1426.namprd15.prod.outlook.com","subject":"RE: pull failed - why should I receive this message.","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-09-24T18:00:37Z","receivedAt":"2021-09-24T18:01:01Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On September 24, 2021 1:34 PM Scott Russell wrote:\n>\n>Thanks for your answer. Is there not an option on the pull to have git to overwrite the existing files?\n>\n>-----Original Message-----\n>From: Emily Shaffer \n>Sent: Friday, September 24, 2021 1:29 PM\n>To: Russell, Scott \n>Cc: git@vger.kernel.org\n>Subject: Re: pull failed - why should I receive this message.\n>\n>*External Message* - Use caution before opening links or attachments\n>\n>On Fri, Sep 24, 2021 at 10:08 AM Russell, Scott wrote:\n>>\n>> Files not previously in git were added to git. Why should I have to manually delete them?\n>> Why can git put not replace them? They were untracked files that are now tracked and so the git copy is desired.\n>> We can't always know ahead of time what files may have been added elsewhere.\n>\n>To turn it around on you, you can't always know ahead of time what files may have been added elsewhere, so you can't be sure that your\n>newly added untracked file locally will be safe from being overwritten during a pull. How upsetting if you sink 30 hours into newlib.cpp\n>and then your teammate checks in their own newlib.cpp, and yours is overwritten without asking when you run 'git pull'.\n>\n>You might have some luck with the '--autostash' option, which would at least prompt you whether to get rid of things when trying to\n>merge them back together during the automatic 'git stash pop' at the end. Or you could run 'git clean --force' to automatically delete any\n>untracked files you might have - you could even alias yourself a command like 'git dangerous-pull' which runs 'git clean -f && git pull'.\n>\n>>\n>>\n>> We need the pull to work automatically.\n>>\n>> error: The following untracked working tree files would be overwritten by merge:\n>> Staging/CADDApps/CADDUIHelper/Source/Release/CADDUIHelper.exe\n>> Staging/CADDApps/CADDUIHelper/Source/Release_Unicode/CADDUIHelper.exe\n>> Staging/CADDApps/InstallDriversPackage/Release/InstallDriversPackage.exe\n>> Staging/Common/NCRCommonCCLib/Source/Release/NCRCommonCCLibMsg.dll\n>> Staging/Devices/NFC/Elatec_RFIDReader/Bin/Director.exe\n>> Staging/Devices/NFC/Elatec_RFIDReader/Firmware/AppBlaster.exe\n>> Staging/Devices/NFC/Elatec_RFIDReader/Firmware/flash.exe\n>> Staging/Utilities64/SSPSWDriverInstaller/Bin/DIFxAPI.dll\n>> Staging/Utilities64/SSPSWDriverInstaller/Bin/DriverForge.v4.5.4.exe\n>> Staging/Utilities64/SSPSWDriverInstaller/Source/Release/SSPSWDriverInstaller.exe\n>> Staging/Utilities64/SSPSWDriverInstaller/Source/Release/SSPSWDriverInstallerMsg.dll\n>>\n>> Staging/Utilities64/SSPSWTaskMgr/Source/Release/SSPSWTaskMgr.exe\n>\n>Or better yet, you could avoid checking in compiled binaries like these and instead add them to your .gitignore, unless you really mean to\n>update them every time someone makes some change. When checking in binaries, you should be aware of the additional disk overhead\n>needed to do so and take a look at some options Git has to mitigate that overhead, like partial clone. However, in many cases the easiest\n>way to mitigate that overhead is to simply not check in binaries unless you absolutely need them to be version controlled.\n>\n>- Emily\n\nIf you are scripting this, try using git clean -dxf and git reset --hard before running the pull. That will clean the objects out of your working directory.\n\n-Randall\n\n"},{"id":"437005","messageId":"BN6PR15MB14262C7036B3C792CCE861D8CBA49@BN6PR15MB1426.namprd15.prod.outlook.com","threadId":"56583","inReplyTo":"000401d7b16e$17ea02d0$47be0870$@nexbridge.com","subject":"RE: pull failed - why should I receive this message.","fromName":"Russell, Scott","fromEmail":"scott.russell2@ncr.com","sentAt":"2021-09-24T18:36:51Z","receivedAt":"2021-09-24T18:36:59Z","isPatch":false,"sender":{"key":"scott.russell2@ncr.com","avatar":null},"body":"Randall, \n\nThanks for your answer. However, this is a build system. \nGit clean -dxf would delete all untracked files - not just the conflicted ones. \n\nWe must keep all untracked files that would not be conflicted by the pull. \nOtherwise, the result would be our build would need to do a fresh build of all objects and build targets - those are all untracked as well. \nInstead of the desired case of just building the changed files and their resultant targets. \n\nWe just need the pull to overwrite any untracked files that may exist in conflict with newly tracked files. \n\nI see git is troublesome in this situation. Every time a developer adds an untracked file to the repo - regardless of type, \nIt will result in failure of the pull. And a failure of the build. \n\n\nThanks, \n\nScott Russell\nNCR Corporation \n \n\n-----Original Message-----\nFrom: Randall S. Becker \nSent: Friday, September 24, 2021 2:01 PM\nTo: Russell, Scott ; 'Emily Shaffer' \nCc: git@vger.kernel.org\nSubject: RE: pull failed - why should I receive this message.\n\nOn September 24, 2021 1:34 PM Scott Russell wrote:\n>\n>Thanks for your answer. Is there not an option on the pull to have git to overwrite the existing files?\n>\n>-----Original Message-----\n>From: Emily Shaffer \n>Sent: Friday, September 24, 2021 1:29 PM\n>To: Russell, Scott \n>Cc: git@vger.kernel.org\n>Subject: Re: pull failed - why should I receive this message.\n>\n>*External Message* - Use caution before opening links or attachments\n>\n>On Fri, Sep 24, 2021 at 10:08 AM Russell, Scott wrote:\n>>\n>> Files not previously in git were added to git. Why should I have to manually delete them?\n>> Why can git put not replace them? They were untracked files that are now tracked and so the git copy is desired.\n>> We can't always know ahead of time what files may have been added elsewhere.\n>\n>To turn it around on you, you can't always know ahead of time what \n>files may have been added elsewhere, so you can't be sure that your \n>newly added untracked file locally will be safe from being overwritten during a pull. How upsetting if you sink 30 hours into newlib.cpp and then your teammate checks in their own newlib.cpp, and yours is overwritten without asking when you run 'git pull'.\n>\n>You might have some luck with the '--autostash' option, which would at \n>least prompt you whether to get rid of things when trying to merge them \n>back together during the automatic 'git stash pop' at the end. Or you could run 'git clean --force' to automatically delete any untracked files you might have - you could even alias yourself a command like 'git dangerous-pull' which runs 'git clean -f && git pull'.\n>\n>>\n>>\n>> We need the pull to work automatically.\n>>\n>> error: The following untracked working tree files would be overwritten by merge:\n>> Staging/CADDApps/CADDUIHelper/Source/Release/CADDUIHelper.exe\n>> Staging/CADDApps/CADDUIHelper/Source/Release_Unicode/CADDUIHelper.exe\n>> Staging/CADDApps/InstallDriversPackage/Release/InstallDriversPackage.exe\n>> Staging/Common/NCRCommonCCLib/Source/Release/NCRCommonCCLibMsg.dll\n>> Staging/Devices/NFC/Elatec_RFIDReader/Bin/Director.exe\n>> Staging/Devices/NFC/Elatec_RFIDReader/Firmware/AppBlaster.exe\n>> Staging/Devices/NFC/Elatec_RFIDReader/Firmware/flash.exe\n>> Staging/Utilities64/SSPSWDriverInstaller/Bin/DIFxAPI.dll\n>> Staging/Utilities64/SSPSWDriverInstaller/Bin/DriverForge.v4.5.4.exe\n>> Staging/Utilities64/SSPSWDriverInstaller/Source/Release/SSPSWDriverInstaller.exe\n>> \n>> Staging/Utilities64/SSPSWDriverInstaller/Source/Release/SSPSWDriverIn\n>> stallerMsg.dll\n>>\n>> Staging/Utilities64/SSPSWTaskMgr/Source/Release/SSPSWTaskMgr.exe\n>\n>Or better yet, you could avoid checking in compiled binaries like these \n>and instead add them to your .gitignore, unless you really mean to \n>update them every time someone makes some change. When checking in \n>binaries, you should be aware of the additional disk overhead needed to do so and take a look at some options Git has to mitigate that overhead, like partial clone. However, in many cases the easiest way to mitigate that overhead is to simply not check in binaries unless you absolutely need them to be version controlled.\n>\n>- Emily\n\nIf you are scripting this, try using git clean -dxf and git reset --hard before running the pull. That will clean the objects out of your working directory.\n\n-Randall\n\n"},{"id":"437009","messageId":"CAJoAoZnuTGoF5J9FiwFTxsrG5VZ78zwKXe9w7__8U6UrCVQmeQ@mail.gmail.com","threadId":"56583","inReplyTo":"BN6PR15MB14262C7036B3C792CCE861D8CBA49@BN6PR15MB1426.namprd15.prod.outlook.com","subject":"Re: pull failed - why should I receive this message.","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2021-09-24T18:39:35Z","receivedAt":"2021-09-24T18:39:50Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Fri, Sep 24, 2021 at 11:36 AM Russell, Scott wrote:\n>\n> Randall,\n>\n> Thanks for your answer. However, this is a build system.\n> Git clean -dxf would delete all untracked files - not just the conflicted ones.\n>\n> We must keep all untracked files that would not be conflicted by the pull.\n> Otherwise, the result would be our build would need to do a fresh build of all objects and build targets - those are all untracked as well.\n> Instead of the desired case of just building the changed files and their resultant targets.\n>\n> We just need the pull to overwrite any untracked files that may exist in conflict with newly tracked files.\n>\n> I see git is troublesome in this situation. Every time a developer adds an untracked file to the repo - regardless of type,\n> It will result in failure of the pull. And a failure of the build.\n\nIt sounds to me like the correct solution here is to add build\nartifacts to .gitignore, which will prevent committers from\naccidentally tracking them and breaking your buildbot's pull.\n\n>\n>\n> Thanks,\n>\n> Scott Russell\n> NCR Corporation\n>\n>\n> -----Original Message-----\n> From: Randall S. Becker \n> Sent: Friday, September 24, 2021 2:01 PM\n> To: Russell, Scott ; 'Emily Shaffer' \n> Cc: git@vger.kernel.org\n> Subject: RE: pull failed - why should I receive this message.\n>\n> On September 24, 2021 1:34 PM Scott Russell wrote:\n> >\n> >Thanks for your answer. Is there not an option on the pull to have git to overwrite the existing files?\n> >\n> >-----Original Message-----\n> >From: Emily Shaffer \n> >Sent: Friday, September 24, 2021 1:29 PM\n> >To: Russell, Scott \n> >Cc: git@vger.kernel.org\n> >Subject: Re: pull failed - why should I receive this message.\n> >\n> >*External Message* - Use caution before opening links or attachments\n> >\n> >On Fri, Sep 24, 2021 at 10:08 AM Russell, Scott wrote:\n> >>\n> >> Files not previously in git were added to git. Why should I have to manually delete them?\n> >> Why can git put not replace them? They were untracked files that are now tracked and so the git copy is desired.\n> >> We can't always know ahead of time what files may have been added elsewhere.\n> >\n> >To turn it around on you, you can't always know ahead of time what\n> >files may have been added elsewhere, so you can't be sure that your\n> >newly added untracked file locally will be safe from being overwritten during a pull. How upsetting if you sink 30 hours into newlib.cpp and then your teammate checks in their own newlib.cpp, and yours is overwritten without asking when you run 'git pull'.\n> >\n> >You might have some luck with the '--autostash' option, which would at\n> >least prompt you whether to get rid of things when trying to merge them\n> >back together during the automatic 'git stash pop' at the end. Or you could run 'git clean --force' to automatically delete any untracked files you might have - you could even alias yourself a command like 'git dangerous-pull' which runs 'git clean -f && git pull'.\n> >\n> >>\n> >>\n> >> We need the pull to work automatically.\n> >>\n> >> error: The following untracked working tree files would be overwritten by merge:\n> >> Staging/CADDApps/CADDUIHelper/Source/Release/CADDUIHelper.exe\n> >> Staging/CADDApps/CADDUIHelper/Source/Release_Unicode/CADDUIHelper.exe\n> >> Staging/CADDApps/InstallDriversPackage/Release/InstallDriversPackage.exe\n> >> Staging/Common/NCRCommonCCLib/Source/Release/NCRCommonCCLibMsg.dll\n> >> Staging/Devices/NFC/Elatec_RFIDReader/Bin/Director.exe\n> >> Staging/Devices/NFC/Elatec_RFIDReader/Firmware/AppBlaster.exe\n> >> Staging/Devices/NFC/Elatec_RFIDReader/Firmware/flash.exe\n> >> Staging/Utilities64/SSPSWDriverInstaller/Bin/DIFxAPI.dll\n> >> Staging/Utilities64/SSPSWDriverInstaller/Bin/DriverForge.v4.5.4.exe\n> >> Staging/Utilities64/SSPSWDriverInstaller/Source/Release/SSPSWDriverInstaller.exe\n> >>\n> >> Staging/Utilities64/SSPSWDriverInstaller/Source/Release/SSPSWDriverIn\n> >> stallerMsg.dll\n> >>\n> >> Staging/Utilities64/SSPSWTaskMgr/Source/Release/SSPSWTaskMgr.exe\n> >\n> >Or better yet, you could avoid checking in compiled binaries like these\n> >and instead add them to your .gitignore, unless you really mean to\n> >update them every time someone makes some change. When checking in\n> >binaries, you should be aware of the additional disk overhead needed to do so and take a look at some options Git has to mitigate that overhead, like partial clone. However, in many cases the easiest way to mitigate that overhead is to simply not check in binaries unless you absolutely need them to be version controlled.\n> >\n> >- Emily\n>\n> If you are scripting this, try using git clean -dxf and git reset --hard before running the pull. That will clean the objects out of your working directory.\n>\n> -Randall\n>\n"},{"id":"437024","messageId":"BN6PR15MB14267A97C763370316AA76B3CBA49@BN6PR15MB1426.namprd15.prod.outlook.com","threadId":"56583","inReplyTo":"CAJoAoZnuTGoF5J9FiwFTxsrG5VZ78zwKXe9w7__8U6UrCVQmeQ@mail.gmail.com","subject":"RE: pull failed - why should I receive this message.","fromName":"Russell, Scott","fromEmail":"scott.russell2@ncr.com","sentAt":"2021-09-24T18:52:30Z","receivedAt":"2021-09-24T19:53:20Z","isPatch":false,"sender":{"key":"scott.russell2@ncr.com","avatar":null},"body":"Emily, \n\nThanks for your response. We have all our anticipated build artifacts in .gitignore. \nHowever, those may not be perfect at this point. \n\nIt will happen - because files previously untracked will be added to the repo. \nAnd .gitignore can be overridden. Even changed. \n\nHowever, personally - if I would be a git product developer, I would provide the option to override this pull conflict. \nNot everyone desires to perform manual intervention. It causes large delays in production. \n\nWhat is tracked in git should always override what is untracked - in my world. \n\n\nThanks, \n\nScott Russell\nNCR Corporation \n \n\n-----Original Message-----\nFrom: Emily Shaffer \nSent: Friday, September 24, 2021 2:40 PM\nTo: Russell, Scott \nCc: Randall S. Becker ; git@vger.kernel.org\nSubject: Re: pull failed - why should I receive this message.\n\nOn Fri, Sep 24, 2021 at 11:36 AM Russell, Scott wrote:\n>\n> Randall,\n>\n> Thanks for your answer. However, this is a build system.\n> Git clean -dxf would delete all untracked files - not just the conflicted ones.\n>\n> We must keep all untracked files that would not be conflicted by the pull.\n> Otherwise, the result would be our build would need to do a fresh build of all objects and build targets - those are all untracked as well.\n> Instead of the desired case of just building the changed files and their resultant targets.\n>\n> We just need the pull to overwrite any untracked files that may exist in conflict with newly tracked files.\n>\n> I see git is troublesome in this situation. Every time a developer adds an untracked file to the repo - regardless of type,\n> It will result in failure of the pull. And a failure of the build.\n\nIt sounds to me like the correct solution here is to add build artifacts to .gitignore, which will prevent committers from accidentally tracking them and breaking your buildbot's pull.\n\n>\n>\n> Thanks,\n>\n> Scott Russell\n> NCR Corporation\n>\n>\n> -----Original Message-----\n> From: Randall S. Becker \n> Sent: Friday, September 24, 2021 2:01 PM\n> To: Russell, Scott ; 'Emily Shaffer' \n> \n> Cc: git@vger.kernel.org\n> Subject: RE: pull failed - why should I receive this message.\n>\n> On September 24, 2021 1:34 PM Scott Russell wrote:\n> >\n> >Thanks for your answer. Is there not an option on the pull to have git to overwrite the existing files?\n> >\n> >-----Original Message-----\n> >From: Emily Shaffer \n> >Sent: Friday, September 24, 2021 1:29 PM\n> >To: Russell, Scott \n> >Cc: git@vger.kernel.org\n> >Subject: Re: pull failed - why should I receive this message.\n> >\n> >*External Message* - Use caution before opening links or attachments\n> >\n> >On Fri, Sep 24, 2021 at 10:08 AM Russell, Scott wrote:\n> >>\n> >> Files not previously in git were added to git. Why should I have to manually delete them?\n> >> Why can git put not replace them? They were untracked files that are now tracked and so the git copy is desired.\n> >> We can't always know ahead of time what files may have been added elsewhere.\n> >\n> >To turn it around on you, you can't always know ahead of time what \n> >files may have been added elsewhere, so you can't be sure that your \n> >newly added untracked file locally will be safe from being overwritten during a pull. How upsetting if you sink 30 hours into newlib.cpp and then your teammate checks in their own newlib.cpp, and yours is overwritten without asking when you run 'git pull'.\n> >\n> >You might have some luck with the '--autostash' option, which would \n> >at least prompt you whether to get rid of things when trying to merge \n> >them back together during the automatic 'git stash pop' at the end. Or you could run 'git clean --force' to automatically delete any untracked files you might have - you could even alias yourself a command like 'git dangerous-pull' which runs 'git clean -f && git pull'.\n> >\n> >>\n> >>\n> >> We need the pull to work automatically.\n> >>\n> >> error: The following untracked working tree files would be overwritten by merge:\n> >> Staging/CADDApps/CADDUIHelper/Source/Release/CADDUIHelper.exe\n> >> Staging/CADDApps/CADDUIHelper/Source/Release_Unicode/CADDUIHelper.exe\n> >> Staging/CADDApps/InstallDriversPackage/Release/InstallDriversPackage.exe\n> >> Staging/Common/NCRCommonCCLib/Source/Release/NCRCommonCCLibMsg.dll\n> >> Staging/Devices/NFC/Elatec_RFIDReader/Bin/Director.exe\n> >> Staging/Devices/NFC/Elatec_RFIDReader/Firmware/AppBlaster.exe\n> >> Staging/Devices/NFC/Elatec_RFIDReader/Firmware/flash.exe\n> >> Staging/Utilities64/SSPSWDriverInstaller/Bin/DIFxAPI.dll\n> >> Staging/Utilities64/SSPSWDriverInstaller/Bin/DriverForge.v4.5.4.exe\n> >> \n> >> Staging/Utilities64/SSPSWDriverInstaller/Source/Release/SSPSWDriver\n> >> Installer.exe\n> >>\n> >> Staging/Utilities64/SSPSWDriverInstaller/Source/Release/SSPSWDriver\n> >> In\n> >> stallerMsg.dll\n> >>\n> >> Staging/Utilities64/SSPSWTaskMgr/Source/Release/SSPSWTaskMgr.exe\n> >\n> >Or better yet, you could avoid checking in compiled binaries like \n> >these and instead add them to your .gitignore, unless you really mean \n> >to update them every time someone makes some change. When checking in \n> >binaries, you should be aware of the additional disk overhead needed to do so and take a look at some options Git has to mitigate that overhead, like partial clone. However, in many cases the easiest way to mitigate that overhead is to simply not check in binaries unless you absolutely need them to be version controlled.\n> >\n> >- Emily\n>\n> If you are scripting this, try using git clean -dxf and git reset --hard before running the pull. That will clean the objects out of your working directory.\n>\n> -Randall\n>\n"},{"id":"437028","messageId":"YU4vG0TI+BkK6xiW@camp.crustytoothpaste.net","threadId":"56583","inReplyTo":"BN6PR15MB14262C7036B3C792CCE861D8CBA49@BN6PR15MB1426.namprd15.prod.outlook.com","subject":"Re: pull failed - why should I receive this message.","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-09-24T20:03:39Z","receivedAt":"2021-09-24T20:04:16Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-09-24 at 18:36:51, Russell, Scott wrote:\n> Randall,\n> \n> Thanks for your answer. However, this is a build system.\n> Git clean -dxf would delete all untracked files - not just the conflicted ones.\n> \n> We must keep all untracked files that would not be conflicted by the pull.\n> Otherwise, the result would be our build would need to do a fresh build of all objects and build targets - those are all untracked as well.\n> Instead of the desired case of just building the changed files and their resultant targets.\n\nNote that a \"git clean -dxf\" will clean even ignored files. If you just\nneed to clean untracked files, you can do \"git clean -df\" (without the\n-x) and then your ignored files will not be deleted.\n\n> We just need the pull to overwrite any untracked files that may exist in conflict with newly tracked files.\n> \n> I see git is troublesome in this situation. Every time a developer adds an untracked file to the repo - regardless of type,\n> It will result in failure of the pull. And a failure of the build.\n\nI do strongly agree with Emily that build artifacts should not be\ntracked in the repository and that the best way to solve it is to\naddress that problem.\n\nHowever, if your goal is to just update the working tree to a specific\nrevision, rather than to potentially merge that commit into the working\ndirectory, you can use \"git fetch origin\" to fetch the remote, and then\nuse \"git checkout -f REVISION\" to check out the branch and destroy local\nchanges. I suspect in your case, since this is a build server, that\nchecking out a specific revision is the intended behavior.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"437038","messageId":"BN6PR15MB1426EBF10C9E8634EF317DDBCBA49@BN6PR15MB1426.namprd15.prod.outlook.com","threadId":"56583","inReplyTo":"YU4vG0TI+BkK6xiW@camp.crustytoothpaste.net","subject":"RE: pull failed - why should I receive this message.","fromName":"Russell, Scott","fromEmail":"scott.russell2@ncr.com","sentAt":"2021-09-24T20:13:15Z","receivedAt":"2021-09-24T20:13:29Z","isPatch":false,"sender":{"key":"scott.russell2@ncr.com","avatar":null},"body":"Brian, \n\nYou are correct. This is a build system. And your responses are the most useful so far. \n\n\"git fetch origin\" - okay \n\nFor this one, is there a way to specify just the head? I just want the latest - and don't want to try to figure out what 'Revision' may be. \n\n\"git checkout -f REVISION\"\n\n\n\nThanks, \n\nScott Russell\nNCR Corporation \n \n\n-----Original Message-----\nFrom: brian m. carlson \nSent: Friday, September 24, 2021 4:04 PM\nTo: Russell, Scott \nCc: Randall S. Becker ; 'Emily Shaffer' ; git@vger.kernel.org\nSubject: Re: pull failed - why should I receive this message.\n\n*External Message* - Use caution before opening links or attachments\n\nOn 2021-09-24 at 18:36:51, Russell, Scott wrote:\n> Randall,\n> \n> Thanks for your answer. However, this is a build system.\n> Git clean -dxf would delete all untracked files - not just the conflicted ones.\n> \n> We must keep all untracked files that would not be conflicted by the pull.\n> Otherwise, the result would be our build would need to do a fresh build of all objects and build targets - those are all untracked as well.\n> Instead of the desired case of just building the changed files and their resultant targets.\n\nNote that a \"git clean -dxf\" will clean even ignored files. If you just need to clean untracked files, you can do \"git clean -df\" (without the\n-x) and then your ignored files will not be deleted.\n\n> We just need the pull to overwrite any untracked files that may exist in conflict with newly tracked files.\n> \n> I see git is troublesome in this situation. Every time a developer adds an untracked file to the repo - regardless of type,\n> It will result in failure of the pull. And a failure of the build.\n\nI do strongly agree with Emily that build artifacts should not be tracked in the repository and that the best way to solve it is to address that problem.\n\nHowever, if your goal is to just update the working tree to a specific revision, rather than to potentially merge that commit into the working directory, you can use \"git fetch origin\" to fetch the remote, and then use \"git checkout -f REVISION\" to check out the branch and destroy local changes. I suspect in your case, since this is a build server, that checking out a specific revision is the intended behavior.\n--\nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"437042","messageId":"YU4475ZbWfnvKomP@camp.crustytoothpaste.net","threadId":"56583","inReplyTo":"BN6PR15MB1426EBF10C9E8634EF317DDBCBA49@BN6PR15MB1426.namprd15.prod.outlook.com","subject":"Re: pull failed - why should I receive this message.","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-09-24T20:45:35Z","receivedAt":"2021-09-24T20:45:42Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-09-24 at 20:13:15, Russell, Scott wrote:\n> Brian,\n> \n> You are correct. This is a build system. And your responses are the most useful so far.\n> \n> \"git fetch origin\" - okay\n> \n> For this one, is there a way to specify just the head? I just want the latest - and don't want to try to figure out what 'Revision' may be.\n> \n> \"git checkout -f REVISION\"\n\nPretend the branch you want to operate on is called \"main\". Assuming\nthat your remote is origin, then you can write \"git checkout -f\norigin/main\", or, if you want to be more precise, \"git checkout -f\nrefs/remotes/origin/main\". That will check out whatever's at the tip of\nmain.\n\nNote that doing that will result in a detached HEAD, which probably\ndoesn't matter for you. In case it does, you can check out your local\nbranch to match it by doing \"git checkout -f -B main refs/remotes/origin/main\".\nThat will make sure you're on a branch called \"main\" and will reset it\nto whatever was on the tip of main when you did your fetch. If you\nwanted your local branch to be called \"dev\" instead, you could do this:\n\n git checkout -f -B dev refs/remotes/origin/main\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"437043","messageId":"BN6PR15MB14269C590D004F7E1B9BE448CBA49@BN6PR15MB1426.namprd15.prod.outlook.com","threadId":"56583","inReplyTo":"YU4475ZbWfnvKomP@camp.crustytoothpaste.net","subject":"RE: pull failed - why should I receive this message.","fromName":"Russell, Scott","fromEmail":"scott.russell2@ncr.com","sentAt":"2021-09-24T20:49:19Z","receivedAt":"2021-09-24T20:49:55Z","isPatch":false,"sender":{"key":"scott.russell2@ncr.com","avatar":null},"body":"Thanks Brian, \n\nI expect that may well solve the issue. I will try it. \n\n\nThanks, \n\nScott Russell\nNCR Corporation \n \n\n-----Original Message-----\nFrom: brian m. carlson \nSent: Friday, September 24, 2021 4:46 PM\nTo: Russell, Scott \nCc: Randall S. Becker ; 'Emily Shaffer' ; git@vger.kernel.org\nSubject: Re: pull failed - why should I receive this message.\n\n*External Message* - Use caution before opening links or attachments\n\nOn 2021-09-24 at 20:13:15, Russell, Scott wrote:\n> Brian,\n> \n> You are correct. This is a build system. And your responses are the most useful so far.\n> \n> \"git fetch origin\" - okay\n> \n> For this one, is there a way to specify just the head? I just want the latest - and don't want to try to figure out what 'Revision' may be.\n> \n> \"git checkout -f REVISION\"\n\nPretend the branch you want to operate on is called \"main\". Assuming that your remote is origin, then you can write \"git checkout -f origin/main\", or, if you want to be more precise, \"git checkout -f refs/remotes/origin/main\". That will check out whatever's at the tip of main.\n\nNote that doing that will result in a detached HEAD, which probably doesn't matter for you. In case it does, you can check out your local branch to match it by doing \"git checkout -f -B main refs/remotes/origin/main\".\nThat will make sure you're on a branch called \"main\" and will reset it to whatever was on the tip of main when you did your fetch. If you wanted your local branch to be called \"dev\" instead, you could do this:\n\n git checkout -f -B dev refs/remotes/origin/main\n--\nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"}]}