How to replace repo without deleting project on GitLab.com?

I have a project that doesn’t have a lot of development on it yet, but does have a lot of issues that I don’t want to lose. The git repo got messed up while trying to permanently remove some sensitive data. I want to just replace the actual git repo with a new and freshly created one, while retaining all of my issues, labels, etc. Is this possible? I can’t seem to find a way, granted I am git newbie, so maybe there is some kind of git push command that will overwrite the gitlab git repo completely with the new one that has no traces of the sensitive data?

Seems like this ought to be a simple feature to let us blow away and recreate the actual git repo for a gitlab project, but I don’t see anyway to do it, any advice welcome.

The git repo lives on your drive as a git bare repo. You can manipulate that without losing your project information/issues which are stored in the database I believe.

On GitLab.com

So basically I have tried to install gitlab locally and then I exported the project from gitlab.com and imported it into my local gitlab.

Then I could go to find the git repo…

However, I have not been able to successfully replace the repo with another one. I found the git repo dirs, but if I try to place the one in question with a freshly inited one using the same hashed name…then the web interface for my local gitlab comes up with error 404, project not found.

If I remove them, I get the same error, gitlab does not prompt to create a new repo or anything.

After trying various different things I am convinced this is not possible to replace the repo with a different one.

I ended up solving the problem by using the API to get all my issues, reconstructed a CSV file from that and then just started over a new project and imported the issues. Still some manual work involved since I lost all the labels and other things like that… But good enough for this time.

If you don’t care about your previous history (which is apparently the case, considering you want to erase all traces of sensitive data), you could do a bare clone of the repo locally (i.e. without any commit history), make your changes to remove the sensitive data, commit those changes, then force push everything (git push -f) on GitLab (provided you unprotected your master branch, of course).

That might be what @aram_mirzadeh was suggesting

If you already have a completely new repository locally, you can then add a remote pointing to your GitLab repo and force push on it.

I think that should do the trick.

Event though it appears I’m too late, if you need more info, don’t hesitate :wink:

1 Like

For future reference I would like to keep this discussion going and perhaps try some experiments on test projects using the suggestions given…

I don’t quite understand your instructions above. I thought a “bare” clone has all the history, but just doesn’t have a working dir? I don’t think that would work.

Perhaps using

git clone -depth 1

That would create a cloned repo without any history. I have tried unprotecting master and pushing back empty repos, etc…they all failed… But I did not yet try from a clone with depth=1, which would be interesting to try.

This is why I always let Gitlab/Github make the first commit automatically for me, which only contains the README file with one line in it.

That way, the first commit of the repo is always something clean, that I can revert back to, for example when using BFG, or when having OCD.

I thought a “bare” clone has all the history, but just doesn’t have a working dir?

You’re absolutely right, that’s my mistake ; it’s --depth that should be used to clone without history, as you pinpointed.

Alas, I don’t think my previous message’s instructions would actually work :frowning_face: Because even though the history would not be cloned, you’d end up with a repo that have one commit, the last of the history, that would reference a state of your project with the sensitive data.
Removing this sensitive data and committing would only add another commit on top of the truncated history. You’d then have two commits: one referencing a state with the sensitive data, the other referencing a state without them ; and all this would have been for nothing.

But I thought of something else that should work and involves deleting the .git folder entirely (as if your code wasn’t versionned in the first place). That will only remove all git related information without modifying the source code (be sure to have the latest version of it though).

You just have to clone your repo normally, then do a rm -rf .git at the root of it.

Once that’s done, you can:

  • Thoroughly remove the sensitive data from the source code
  • Do a git init to start anew
  • Add a remote to the repo that you want to override
    git remote add origin git@gitlab.com:your/project/path.git
  • Commit all your files (they should all be seen as new by Git)
  • Force push to your unprotected remote master branch (do not pull anything from this remote, of course)
    git push -f

I tried this in a test repository of mine, and I can confirm that it entirely replaces the old history with the new one.

That should do the trick, then :wink: