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@xxxxxxxxxx>
Sent: Friday, September 24, 2021 2:40 PM
To: Russell, Scott <Scott.Russell2@xxxxxxx>
Cc: Randall S. Becker <rsbecker@xxxxxxxxxxxxx>; git@xxxxxxxxxxxxxxx
Subject: Re: pull failed - why should I receive this message.
On Fri, Sep 24, 2021 at 11:36 AM Russell, Scott <Scott.Russell2@xxxxxxx> 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@xxxxxxxxxxxxx>
> Sent: Friday, September 24, 2021 2:01 PM
> To: Russell, Scott <Scott.Russell2@xxxxxxx>; 'Emily Shaffer'
> <emilyshaffer@xxxxxxxxxx>
> Cc: git@xxxxxxxxxxxxxxx
> 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@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/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
>
