From: "Randall S. Becker" <rsbecker@nexbridge.com>
To: "'Russell, Scott'" <Scott.Russell2@ncr.com>,
"'Emily Shaffer'" <emilyshaffer@google.com>
Cc: <git@vger.kernel.org>
Subject: RE: pull failed - why should I receive this message.
Date: Fri, 24 Sep 2021 14:00:37 -0400 [thread overview]
Message-ID: <000401d7b16e$17ea02d0$47be0870$@nexbridge.com> (raw)
In-Reply-To: <BN6PR15MB14261D1A350398C0C26793E1CBA49@BN6PR15MB1426.namprd15.prod.outlook.com>
On September 24, 2021 1:34 PM Scott Russell wrote:
>
>Thanks for your answer. Is there not an option on the pull to have git to overwrite the existing files?
>
>-----Original Message-----
>From: Emily Shaffer <emilyshaffer@google.com>
>Sent: Friday, September 24, 2021 1:29 PM
>To: Russell, Scott <Scott.Russell2@ncr.com>
>Cc: git@vger.kernel.org
>Subject: Re: pull failed - why should I receive this message.
>
>*External Message* - Use caution before opening links or attachments
>
>On Fri, Sep 24, 2021 at 10:08 AM Russell, Scott <Scott.Russell2@ncr.com> wrote:
>>
>> Files not previously in git were added to git. Why should I have to manually delete them?
>> Why can git put not replace them? They were untracked files that are now tracked and so the git copy is desired.
>> We can't always know ahead of time what files may have been added elsewhere.
>
>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
>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'.
>
>You 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'.
>
>>
>>
>> We need the pull to work automatically.
>>
>> error: The following untracked working tree files would be overwritten by merge:
>> Staging/CADDApps/CADDUIHelper/Source/Release/CADDUIHelper.exe
>> Staging/CADDApps/CADDUIHelper/Source/Release_Unicode/CADDUIHelper.exe
>> Staging/CADDApps/InstallDriversPackage/Release/InstallDriversPackage.exe
>> Staging/Common/NCRCommonCCLib/Source/Release/NCRCommonCCLibMsg.dll
>> Staging/Devices/NFC/Elatec_RFIDReader/Bin/Director.exe
>> Staging/Devices/NFC/Elatec_RFIDReader/Firmware/AppBlaster.exe
>> Staging/Devices/NFC/Elatec_RFIDReader/Firmware/flash.exe
>> Staging/Utilities64/SSPSWDriverInstaller/Bin/DIFxAPI.dll
>> Staging/Utilities64/SSPSWDriverInstaller/Bin/DriverForge.v4.5.4.exe
>> Staging/Utilities64/SSPSWDriverInstaller/Source/Release/SSPSWDriverInstaller.exe
>> Staging/Utilities64/SSPSWDriverInstaller/Source/Release/SSPSWDriverInstallerMsg.dll
>>
>> Staging/Utilities64/SSPSWTaskMgr/Source/Release/SSPSWTaskMgr.exe
>
>Or 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.
>
>- Emily
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.
-Randall
next prev parent reply other threads:[~2021-09-24 18:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-24 14:48 pull failed - why should I receive this message Russell, Scott
2021-09-24 17:28 ` Emily Shaffer
2021-09-24 17:34 ` Russell, Scott
2021-09-24 18:00 ` Randall S. Becker [this message]
2021-09-24 18:36 ` Russell, Scott
2021-09-24 18:39 ` Emily Shaffer
2021-09-24 18:52 ` Russell, Scott
2021-09-24 20:03 ` brian m. carlson
2021-09-24 20:13 ` Russell, Scott
2021-09-24 20:45 ` brian m. carlson
2021-09-24 20:49 ` Russell, Scott
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000401d7b16e$17ea02d0$47be0870$@nexbridge.com' \
--to=rsbecker@nexbridge.com \
--cc=Scott.Russell2@ncr.com \
--cc=emilyshaffer@google.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox