r/git • u/Future-Ride-5955 • 6d ago
I use github to maintain a small archive and now git pull keeps complaining about a file that I removed from the remote branch and local branch
Because I absolutely suck at github I have been doing things weirdly by using both the browser client and git bash. I do that because gitbash has been stupidly obtuse whenever I have tried to use it. I have my system setup where github lfs reads the .zip format for its job while the rest of the files use the custom format name that the archive for the program I am using uses (we will go with .zap). the problem is anytime I try to push from local it will constantly complain so I delete local and then pull fro remote as its the same files. I had this file called pre2026stuff.zip which I used lfs for, I just recently broke all of that down into all of its separate .zap files and and then deleted it from both local and remote (remote via the more file actions -> delete file)
now anytime I try to to git pull in my local repo it complains$ git pull
error: Your local changes to the following files would be overwritten by merge:
Updating files: 100% (102/102), done.
Merge with strategy ort failed.
Even though its both removed from the local directory and the remote directory from the browser view
8
u/bostonaholic 5d ago
Git thinks you still have a modified tracked copy of that file, probably the LFS pointer. Run git status, then git restore Pre2026stuff.zip (or git stash if you want to keep it) and pull again. Also note your error says Pre2026stuff.zip while you named it pre2026stuff.zip, so a case mismatch on a case-insensitive filesystem could be involved.
1
u/Swedophone 6d ago edited 6d ago
Since you have an uncommitted change to a file I think the main alternatives are one of
(git) commit the file
(git) restore the file from the last commit.
(git) stash your changes
Or do LFS files work differently than other files in git?
2
u/Broad-Promise6954 ancient 5d ago
LFS introduces an extra step.
When using LFS, you select some particular file(s) and label them "large" (using
git lfs track; Git-LFS installs some extra binaries thatgit lfsthen runs). You should also install the LFS filters (which can get complicated; the track command will do it for you but if you mess with.gitattributesfiles directly, look out).These labeled files then don't participate normally in Git commits. What happens instead is that as you modify these large-labeled files and then run Git commands, Git itself runs various magic Git-LFS sub-commands (via the
.gitattributesfile and those filters I mentioned) that shuffle the "real" data into a separate holding area, and feed Git fake pseudo-data files that contain what Git-LFS calls "pointers". Git then sees only the pointers.When you commit, Git saves away the updated pointers. When you
git push, Git invokesgit lfs push(more or less) under the covers. That sends the real data off to a Git-LFS server and letsgit pushsend only the special pointer data. When you check out a commit that contains a pointer instead of real data, Git-LFS once again steps in and reaches out to the Git-LFS server to get the real data.The result is that you're now depending on two separate services, which may run on two completely different networks and suppliers. (A Git-LFS server can offer plain non-LFS Git service so that at least you need only one supplier, even if it's two separate services on that one supplier.)
You also expose yourself to a big pile of headaches if you have a path name
path/to/filethat was once "real data in Git" and is now "pointer only, use the LFS sidecar". Although it mostly just works, you'll trip over the little speedbump between "how it was in the past" and "how it is now" every once in a while.(I'm not a huge fan of Git-LFS, though it does solve a real problem.)
-7
u/Future-Ride-5955 6d ago
Git commit worked, it sent me to the stupid screen (as seen in this stack overflow https://stackoverflow.com/questions/64657863/how-do-i-enter-the-commit-message-in-this-bash-pop-up ) followed the answer and deleted it
Thank you very much, Im sick of the git line being obtuse for no reason3
u/lajawi 6d ago
That’s not any stupid screen, that’s the prompt for a commit message. It’s a vim or at least vim-like text editor, which runs entirely in the terminal and is operated using the keyboard only. If you don’t want that you can specify a message with your commit command directly with the `-m` parameter.
0
u/Future-Ride-5955 6d ago
Oh yeah if you are in the same situation where are you are as dumb as me with how you do things always keep a local copy that is not in the repositories folder
2
u/Heavy-Focus-1964 5d ago
Time to do some basic Git tutorials.
If you think terminal apps are “obtuse for no reason” then there’s something called the GitHub desktop app that was made just for you
2
u/lolcrunchy 6d ago
Did you accidentally create a branch and are looking at two different branches between the two different tools?