0

I have local repository (managed with Git) which contains all the older versions of my project and now I want to upload it to GitLab (GL) and SourceTree (ST). I created my project in the GL with link like https://gitlab.com/myusername/myproject.

I used ST to push all my branches and tags to the origin i.e. GL repo https://gitlab.com/myusername/myproject.git.

To verify, I cloned the repo in a demo local repo and compared the sizes and number of files of original loacal repo & demo repo and found out that there is huge difference between the two.

I doubt that files of only latest commit or checked out branch and history of revisions are uploaded to GL (and not local files related to older revisions/commits which are present in hidden folder in the local repo because I can't see them on the server in my remote repo).

How can I sync/upload all files of all commits to the remote so that I can backup of my repo in case anything happens to my local repo.

Thanks in advance.

Best Regards

Improve this question
9
  • Git does not push files. Git pushes commits. Every commit has a full snapshot of every file, and a commit drags its history (previous commits) along with it. So if you push your new commits—the ones you made since you got all the existing commits from the GitLab repository—they now have all their original commits (which you also have) plus all your new commits (which you also have). Everyone has everything; that's how Git works.
    – torek
    Commented May 4, 2022 at 10:06
  • Whenever you select a commit to check out, Git will remove from your working area, all the files that were copied out of the old commit, and plug in instead all the files that go with the commit you've just selected. When you switch to another commit, Git removes those files and puts in the other commit's files. But every commit holds every file (that was put in it when it was made), frozen for all time.
    – torek
    Commented May 4, 2022 at 10:07
  • Note that the files in your working tree are not in Git. They may have just come out of Git (out of a commit), but as you make changes to them, Git is entirely unaware of what you're doing. Eventually you must tell Git to re-scan your updated files and prepare and then make a new commit, and only then does Git store a new snapshot (of all files, not just the ones you changed). The snapshots are in a frozen-for-all-time format with files compressed and de-duplicated so they don't waste disk space.
    – torek
    Commented May 4, 2022 at 10:09
  • 1
    Yes: if you clone the repository, you get all the commits (and no branches, and then your Git software creates one branch in your new clone—so don't go by branches, go by commits). The repository is a big database of commits, which get shared across clones (plus a smaller database of names that help you find commits; the names don't get shared the same way).
    – torek
    Commented May 4, 2022 at 11:16
  • 1
    I'm not sure how you're measuring the size, but the size of the database is in a count of objects, which can be either "loose" (one per file) or "packed" (many in one file) (and in some cases some objects are unused, eventually to be deleted). Cloning results in a single pack file, which will generally take a lot less disk space than many loose objects, but will still contain the same set of objects. Packs accumulate, which will consume more disk space, until they are "repacked" and then the disk space drops. Databases are hard to characterize.
    – torek
    Commented May 4, 2022 at 14:50
Related questions
1
Push files to remote git repository
2
pull a remote repo and pushing those files
0
How to push working tree files to remote location on commit?
Load 7 more related questions Show fewer related questions

0

Reset to default