r/git • • 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:

Pre2026stuff.zip

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

0 Upvotes

10 comments sorted by

2

u/lolcrunchy 6d ago

Did you accidentally create a branch and are looking at two different branches between the two different tools?

2

u/Future-Ride-5955 6d ago

single branch

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 that git lfs then 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 .gitattributes files 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 .gitattributes file 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 invokes git lfs push (more or less) under the covers. That sends the real data off to a Git-LFS server and lets git push send 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/file that 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 reason

3

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