RE: pull failed - why should I receive this message.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks for your answer.   Is there not an option on the pull to have git to overwrite the existing files? 


Thanks, 

Scott Russell
Staff SW Engineer 
NCR Corporation 
Phone: +17706237512
Scott.Russell2@xxxxxxx  |  ncr.com
       

-----Original Message-----
From: Emily Shaffer <emilyshaffer@xxxxxxxxxx> 
Sent: Friday, September 24, 2021 1:29 PM
To: Russell, Scott <Scott.Russell2@xxxxxxx>
Cc: git@xxxxxxxxxxxxxxx
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@xxxxxxx> 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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux