4

I am using the gitlab repository for uploading my code files. I have made more than 500 commits. My repo size was upto 540 mb. I want to minimize the size of the repo by deleting unwanted files in the repo.

Somehow i managed and deleted the files in my local. Now my current file size is 10 mb in the local. I pushed it and it was good. Eventhough it shows 540mb. I came to know the previous commit files holds the storage. There is a zip file with a size of 400 mb which is in one of my older commit.

I found the commit by using the shell script. I want to delete the zip file in the commit. But it shows "You can only delete files when you are on the branch" in the gitlab webui. In the terminal, I found the command git rm <file_name> to remove the file. I got the file path from the commit. But I don't know how to use it on a particular commit. It holds some important files. I don't wanna play with it.

My question is: how do I remove a certain file in a particular commit in gitlab without affecting any other commits? I tried Stack Overflow and found some answers to delete the file in previous commit but not in the older commit. Help me with some solutions.

kowsky
  • 12,647
  • 2
  • 28
  • 41
Steven
  • 41
  • 3
  • 2
    What you want to achieve is not possible. As soon as you touch an older commit (by deleting a file in it), you will change any successor of that commit. Anyone working on the "old" version of the commits will get in trouble. – kowsky Aug 13 '19 at 08:17

3 Answers3

2

The short answer is grim : you can't.

That is, you could modify a commit in the past, but it would modify every commit down the line so it doesn't check the "without affecting anyother commits" part.

Take a look at git filter-branch to have an idea of what tools are at your disposal to change history, but be aware that's quite a heavy operation.

Romain Valeri
  • 19,645
  • 3
  • 36
  • 61
2

It's no possible to delete the file without affect commit history.

To delete the file in the history, you can use git built-in git-filter-branch or third party bfg-repo-cleaner

Refer to i-want-to-remove-a-large-file-from-ever-existing-in-repo-history of Github: git-flight-rules

recommended-technique-use-third-party-bfg

(master)$ git rm path/to/filetoremove
(master)$ git commit -m "Commit removing filetoremove"
(master)$ java -jar ~/Downloads/bfg.jar --delete-files filetoremove

built-in-technique-use-git-filter-branch

(master)$ git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch filepattern' --prune-empty --tag-name-filter cat -- --all
LF00
  • 27,015
  • 29
  • 156
  • 295
  • 1
    *without affecting any other commits in gitlab*? Really? – Romain Valeri Aug 13 '19 at 08:36
  • 1
    @Kris Roofe, It worked great. the cloning size becomes smaller after using this. but in the web ui, the size gets increased after pushing it. To check it, again i cloned the project but the cloning size doesn't changed which was previous smaller size and it was good to me. But why the size showing in gitlab web ui is not as same as the size in clone. i have removed the big file. Eventhough, the size showing in gitlab web ui doesn't change. – Steven Aug 14 '19 at 05:02
  • @Steven, glad it helps. – LF00 Aug 26 '19 at 12:51
1

There's a command-line utility called BFG Repo-Cleaner that will help you do just that.

For example, this command will go through a repo's history and delete a specific file in all commits reachable from any branch:

bfg --delete-files big-400-MB-file.zip path/to/your/repo

You can achieve the same thing using the git filter-branch command and some shell scripting, but this is way easier.

Now, about the second part of your question:

...without affecting any other commits

That's simply not possible. Deleting a file from an older commit will cause its SHA-1 to change, which in turn will change the SHA-1 of all descendant commits. In other words, you're rewriting a large chunk of history, which, depending on your particular scenario, may or may not be a problem:

The command is filter-branch, and it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite.

Enrico Campidoglio
  • 56,676
  • 12
  • 126
  • 154
  • I think you should lead with your second part... definitely do not want someone trying this without understanding that it's going to affect all that history. :-) – John Szakmeister Aug 13 '19 at 08:25
  • @JohnSzakmeister I see your point. Honestly, it's a bit unclear what OP means by "_without affecting any other commits_". I think it's good to know that it can be done _but_ they should be aware of the consequences, which, in some cases, might be perfectly acceptable. – Enrico Campidoglio Aug 13 '19 at 08:33