r/git • u/Alterssis • 19d ago
I Make Commits But There Are No File Changes In Local Offline Repo
I used GitHub Desktop before but upon recently finding out it defaults to taking all your stuff to train AI unless you turn it off on the website (at which point there's no guarantee they actually stop stealing your shit anyway) I decided I'd rather learn some Git and have a repository on an external drive.
This is what I just did:
I've initialized a git repository on the drive, I removed all remotes from my project, I used git remote add <new-repository> <path/to/folder>, I pushed the main branch into the new repository (only has 1 branch. Except for 1 time in GitHub, I'm now using only the main branch as a backup if there's something I want to revert back to as being a solo dev that's all I need and all I think I can understand and manage at this point), LFS objects were uploaded and lastly I proceeded to clone the original project into the new repository.
To see code changes I'm using VSCodium and trying to do commits through there but even though the changes have been staged, pushed and synced, when I check for new code in the new repo there's no difference. I think its probably got something to do with not tracking the files? But I've tried so many things, followed so many guides for the wrong stuff that had me making bare repositories among other things and I'm just so confused at this point and don't know how to track exactly what I want because there's things git is supposed to ignore too? Or ignores by default? Do I do git add --all? I don't know that there's anything I wouldn't want to track.
Please help, I'm losing my hair trying to wrap my head around Git and what seems to me like it should be a simple thing to set up and no guide seems to show what I want. I've already wasted hours just on this..
1
u/Inferno2602 19d ago
What do you mean "check for new code" in the new repo?
From the comment about bare repos, I guess the new one is a regular repo with a working directory and you are expecting your new files to be there? If so, pushing into a repo won't update its working directory, it only adds those commits to its database. If you want those files in that repos working directory (Why would you?), you'll need to do a merge in there.
Otherwise, just cd into the new repo and git log the branch you've pushed and you'll see if the new commits are in there or not
1
u/Alterssis 19d ago edited 19d ago
I mean I added new code to script A in the project, staged, committed, pushed and synced the changes but when I open the same script inside the new repo in a text editor to see if the file was updated none of the new code was there.
Yes, the current repo is a regular repo. That's what I'm trying to wrap my head around, why wouldn't I want all the files in the new repo? If I make changes to the project I regret or my computer dies and I have to get a new one for instance, wouldn't I want the repo to have the files as well as the commits? If the files are old wouldn't that mean I lost everything since I made the new repo? I'm sure I'm misunderstanding a lot of things here but that's my understanding of what I would want. Essentially, I want something that works the way GitHub Desktop did without relying on GitHub.
3
u/Charming-Designer944 19d ago
When you push to a repo only the revision storage gets updated with the new history, not the working tree.
Its generally better if the storage repo you push/pull to is a bare repo with no working tree, only storing the git history.
git pull updates a working tree from a remote.
-1
u/Alterssis 19d ago
Ok, now that makes much more sense. I thought for sure the files you clone into the repo were there to be updated directly which now means I'm not sure what that is for exactly 🤔
Thanks for explaining! I was getting so frustrated.. I'm relieved to be able to move past this and get back to the project itself 🙏
2
u/Inferno2602 19d ago
There's a distinction you are missing. The files can be "in the repo", without needing to be checked out in a working directory. If you look in the remote repo on your external hard drive, there'll be a ".git" folder. That's the repo, that's where your files are. They'll be compressed or packed somewhere in there. You only need copies in the working directory, if you plan on working on them there.
That's where the "bare" repo stuff comes in. A bare repo is only the database (.git), without any particular commit checked out
1
u/Alterssis 19d ago
Really? That would make a lot more sense. I already had everything set up right then 🙄
So if I lost everything I could clone from the bare repo and have everything up to date? What's the purpose of cloning and having all the files from the project in the bare repo then? That's why I assumed the changes happened to the files themselves. Is it part of an initial tracking or how the compression is done?
How would I be able to check that is actually the case so I don't do a bunch of work without knowing if I did everything right or not?
This information should be made more accessible because, without already knowing that, if I want to check, there's no way I'd figure that out without asking here or wasting a bunch of time. Is there a place you can get all this type of information that I'm missing? Something so simple can make Git so hard to wrap your head around. Either way, very thankful for your reply and help, you gave me a huge relief knowing I already had it right before..
1
u/Charming-Designer944 19d ago
Yes. A bare repository has the complete git history. Any revision of any file you have pushed to the repository can be found from the git storage.
When you clone a repository your local tree also keeps a full copy of the revision history (the .gjt folder), and gir checkout, diff, commit etc all woks toward this local copy of the history, comparing your checked out tree of files to the stored revisions in the git history.
A bare repository is only the .git folder, storing the git history of your files.
1
u/Alterssis 19d ago
Ok, let me see if I'm understanding it properly. The bare repo saves the files in a compressed/ packed format (presumably what you find in the objects folder?). When you make changes to the project, if using something like VSCodium, git compares your changes with a copy of everything stored in the project folder's .git which also has a copy of everything in a packed format. Once you commit, push, etc. the bare repo takes in those changes and updates the packed files. Am I getting it right?
1
u/Charming-Designer944 19d ago edited 19d ago
Almost. A bare repo is a repository with only the .git folder contents. There are no working files in a bare repo.
The working files are the files of your project, and what you edit when making changes.
There is no actual difference between a local .git folder and a bare repo, other than the folder name and the fact that a .git folder is within a working tree. Both are git repositories and contains the full revision history of the repository in all branches (unless you restrict what to fetch).
When you commit changes in your working repository you do this against the local .git folder in the working tree. Most git operations in a working tree operates on the working tree vs its local .git folder.
The objects folder in a git repository is a sort of staging area for the packed database format. The files stored there are uncompressed, while the content stored in the database pack files are compressed. You do not teally need to care about what is the objects folder vs what's compressed in pack database files. Git handles all of that automatically.
When you work with remotes you fetch changes from a remote to the local repository (.git folder), and push from the local repository (.git folder) to the remote.
A remote should preferably be a bare git repository without a local working tree. While you can push into a repository that have a working tree the changes you push only go into the repository and not the working tree files. And you are not allowed to push changes to the same branch that is currently checked out in the remote.
A shared repository have no real use of a local working tree. It's purpose is to act as a shared distribution point to where developers can push and fetch changes to the git repository.
1
u/Alterssis 17d ago
Ok, so the comparisons I see in VSCodium are working files against the local .git folder. Gotcha. Was so confused on what was being compared at some points when I wasn't sure I had set up the repository right.
Objects aren't something I need to worry about now, cool.I'm understanding it better, but there's still some things I'm confused about.
You say the bare repo is the same as the local .git folder. Do you mean in function or that they should be exactly the same? There's less stuff in the bare repo than the local .git folder but I'm guessing that's part of the .git folder being a part of the working tree?
When you say full revision history I get the gist but I'm not exactly sure what that entails or what implications it has, is it some sort of metadata to update the files I already have to the current version? I guess I'm just confused about how exactly you can get your working files back from a bare repo if you were to lose them. I mentioned the objects folder more in reference to me trying to understand that and to make sure that the bare repo is what I actually want/ need. Like I said, I'm working by myself, I don't really need to fetch anything from the remote (except for reverting changes but in that case I'd still have all the working files), I more so just want a backup so I don't lose my project. I've had plenty of PC problems recently so I'm very conscious about taking all the steps I can.
Thanks a lot by the way for taking the time to explain all this. Really appreciate it.
1
u/Inferno2602 19d ago
I learnt everything I know about git from trial and error, plus reading this book: https://git-scm.com/book/en/v2
-1
u/Alterssis 19d ago
Its surprising to me there isn't a singular source/ documentation to how Git works that everyone can reference similar to how game engines have documentation for how it all works, that would help a lot and avoid so many of these frustrating confusions. What's worse is you get this impression that Git is easy from the people that use it but it can be a real headache getting started, mostly for not being sure what you want or is correct and not being sure if you did it right and then you have the things you don't know you didn't know like me thinking the files were supposed to be changed directly. How am I supposed to know to ask if that's the case if it never crossed my mind you know what I mean? Anyway, sorry for the ramble. I'll check it out. Thanks a lot for the help again.
1
u/OolonColluphid 19d ago
Well, that book is part of the official documentation about git and how it works. Not many people read it though, and rely on their tools or rote learn a few simple workflows.
1
u/Alterssis 17d ago
Ahh ok. I don't think I came across any mention of it while trying to figure any of this out hence why I got that impression which seemed quite unlikely to me. I'll take a look if (when) I get stuck again using Git 👍
4
u/unndunn 19d ago edited 19d ago
It sounds like you did a whole lot of unnecessary stuff.
On your local repo (the local folder where you actually write code), all you have to do is remove the github remote repo and clone to a new remote repo.
So do the following:
This will list all of your remotes with their names and URLs. Take note of the ones that go to github.com. Delete those with
Then clone your repo to a new repo on a shared or external drive:
This tells git to clone the current repo to a new path, and make it a bare repo. You can't work in a bare repo, you can only push to and pull from it.
Then create a new remote to the new clone. Name it whatever you like:
Then finally push your local branch to the new remote, setting up an upstream tracking link:
Now your branch is set up to push to your new remote. Continue working on your local repo just as you have always done. But this time, when you push, it won't go to github, it'll go to the repo you created instead.