pull failed - why should I receive this message.

pull failed - why should I receive this message.

[Russell, Scott]

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.  
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
Please move or remove them before you merge.
Aborting
Updating e6f37b6878..02aa693031


Thanks, 

Scott Russell
Scott.Russell2@ncr.com  |  ncr.com
       

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

[Emily Shaffer]

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

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

[Russell, Scott]

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@ncr.com  |  ncr.com
       

-----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

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

[Randall S. Becker]

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

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

[Russell, Scott]

Randall,  

Thanks for your answer.   However, this is a build system.   
Git clean -dxf would delete all untracked files - not just the conflicted ones. 

We must keep all untracked files that would not be conflicted by the pull.  
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.  
Instead of the desired case of just building the changed files and their resultant targets. 

We just need the pull to overwrite any untracked files that may exist in conflict with newly tracked files.  

I see git is troublesome in this situation.   Every time a developer adds an untracked file to the repo - regardless of type, 
It will result in failure of the pull.   And a failure of the build.  


Thanks, 

Scott Russell
NCR Corporation 
    

-----Original Message-----
From: Randall S. Becker <rsbecker@nexbridge.com> 
Sent: Friday, September 24, 2021 2:01 PM
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.

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/SSPSWDriverIn
>> stallerMsg.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

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

[Emily Shaffer]

On Fri, Sep 24, 2021 at 11:36 AM Russell, Scott <Scott.Russell2@ncr.com> wrote:
>
> Randall,
>
> Thanks for your answer.   However, this is a build system.
> Git clean -dxf would delete all untracked files - not just the conflicted ones.
>
> We must keep all untracked files that would not be conflicted by the pull.
> 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.
> Instead of the desired case of just building the changed files and their resultant targets.
>
> We just need the pull to overwrite any untracked files that may exist in conflict with newly tracked files.
>
> I see git is troublesome in this situation.   Every time a developer adds an untracked file to the repo - regardless of type,
> It will result in failure of the pull.   And a failure of the build.

It 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.

>
>
> Thanks,
>
> Scott Russell
> NCR Corporation
>
>
> -----Original Message-----
> From: Randall S. Becker <rsbecker@nexbridge.com>
> Sent: Friday, September 24, 2021 2:01 PM
> 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.
>
> 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/SSPSWDriverIn
> >> stallerMsg.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
>

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

[Russell, Scott]

Emily,  

Thanks for your response.   We have all our anticipated build artifacts in .gitignore.   
However, those may not be perfect at this point.   

It will happen - because files previously untracked will be added to the repo.  
And .gitignore can be overridden.    Even changed.    

However, personally - if I would be a git product developer, I would provide the option to override this pull conflict. 
Not everyone desires to perform manual intervention.   It causes large delays in production. 

What is tracked in git should always override what is untracked - in my world.  


Thanks, 

Scott Russell
NCR Corporation 
       

-----Original Message-----
From: Emily Shaffer <emilyshaffer@google.com> 
Sent: Friday, September 24, 2021 2:40 PM
To: Russell, Scott <Scott.Russell2@ncr.com>
Cc: Randall S. Becker <rsbecker@nexbridge.com>; git@vger.kernel.org
Subject: Re: pull failed - why should I receive this message.

On Fri, Sep 24, 2021 at 11:36 AM Russell, Scott <Scott.Russell2@ncr.com> wrote:
>
> Randall,
>
> Thanks for your answer.   However, this is a build system.
> Git clean -dxf would delete all untracked files - not just the conflicted ones.
>
> We must keep all untracked files that would not be conflicted by the pull.
> 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.
> Instead of the desired case of just building the changed files and their resultant targets.
>
> We just need the pull to overwrite any untracked files that may exist in conflict with newly tracked files.
>
> I see git is troublesome in this situation.   Every time a developer adds an untracked file to the repo - regardless of type,
> It will result in failure of the pull.   And a failure of the build.

It 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.

>
>
> Thanks,
>
> Scott Russell
> NCR Corporation
>
>
> -----Original Message-----
> From: Randall S. Becker <rsbecker@nexbridge.com>
> Sent: Friday, September 24, 2021 2:01 PM
> 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.
>
> 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/SSPSWDriver
> >> Installer.exe
> >>
> >> Staging/Utilities64/SSPSWDriverInstaller/Source/Release/SSPSWDriver
> >> In
> >> stallerMsg.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
>

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]

On 2021-09-24 at 18:36:51, Russell, Scott wrote:
> Randall,
> 
> Thanks for your answer.   However, this is a build system.
> Git clean -dxf would delete all untracked files - not just the conflicted ones.
> 
> We must keep all untracked files that would not be conflicted by the pull.
> 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.
> Instead of the desired case of just building the changed files and their resultant targets.

Note 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
-x) and then your ignored files will not be deleted.

> We just need the pull to overwrite any untracked files that may exist in conflict with newly tracked files.
> 
> I see git is troublesome in this situation.   Every time a developer adds an untracked file to the repo - regardless of type,
> It will result in failure of the pull.   And a failure of the build.

I 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.

However, 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.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

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

[Russell, Scott]

Brian,  

You are correct.  This is a build system.  And your responses are the most useful so far.  

"git fetch origin" - okay 

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. 

"git checkout -f REVISION"



Thanks, 

Scott Russell
NCR Corporation 
       

-----Original Message-----
From: brian m. carlson <sandals@crustytoothpaste.net> 
Sent: Friday, September 24, 2021 4:04 PM
To: Russell, Scott <Scott.Russell2@ncr.com>
Cc: Randall S. Becker <rsbecker@nexbridge.com>; 'Emily Shaffer' <emilyshaffer@google.com>; git@vger.kernel.org
Subject: Re: pull failed - why should I receive this message.

*External Message* - Use caution before opening links or attachments

On 2021-09-24 at 18:36:51, Russell, Scott wrote:
> Randall,
> 
> Thanks for your answer.   However, this is a build system.
> Git clean -dxf would delete all untracked files - not just the conflicted ones.
> 
> We must keep all untracked files that would not be conflicted by the pull.
> 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.
> Instead of the desired case of just building the changed files and their resultant targets.

Note 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
-x) and then your ignored files will not be deleted.

> We just need the pull to overwrite any untracked files that may exist in conflict with newly tracked files.
> 
> I see git is troublesome in this situation.   Every time a developer adds an untracked file to the repo - regardless of type,
> It will result in failure of the pull.   And a failure of the build.

I 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.

However, 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.
--
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

On 2021-09-24 at 20:13:15, Russell, Scott wrote:
> Brian,
> 
> You are correct.  This is a build system.  And your responses are the most useful so far.
> 
> "git fetch origin" - okay
> 
> 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.
> 
> "git checkout -f REVISION"

Pretend 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.

Note 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".
That 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:

  git checkout -f -B dev refs/remotes/origin/main
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

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

[Russell, Scott]

Thanks Brian,  

I expect that may well solve the issue.  I will try it. 


Thanks, 

Scott Russell
NCR Corporation 
      

-----Original Message-----
From: brian m. carlson <sandals@crustytoothpaste.net> 
Sent: Friday, September 24, 2021 4:46 PM
To: Russell, Scott <Scott.Russell2@ncr.com>
Cc: Randall S. Becker <rsbecker@nexbridge.com>; 'Emily Shaffer' <emilyshaffer@google.com>; git@vger.kernel.org
Subject: Re: pull failed - why should I receive this message.

*External Message* - Use caution before opening links or attachments

On 2021-09-24 at 20:13:15, Russell, Scott wrote:
> Brian,
> 
> You are correct.  This is a build system.  And your responses are the most useful so far.
> 
> "git fetch origin" - okay
> 
> 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.
> 
> "git checkout -f REVISION"

Pretend 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.

Note 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".
That 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:

  git checkout -f -B dev refs/remotes/origin/main
--
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA