99

Note that using --depth=1 parameter prevents you from pushing the project to a new repository.

itamar
  • 1,800
  • 4
  • 17
  • 30
  • Yes, what about `--depth=N` instead of 1? "Shallow update" is still rejected, and just doing `rm -r .git` and `git init` won't cut it. I will try out the whole "ungrafting" magic, and if it works for the general case (depth N), it should be the accepted (and most upvoted ;) ) answer. – Tomasz Gandor Aug 05 '19 at 04:56

3 Answers3

87

You can do a 

git clone <git_url>

delete the .git repository from your folder. Which will delete all your history.

The you can do a

git init

which will create an entirely new git project for you.

This may not be the best way. But this will work . Hope it helps.

Ajay
  • 2,976
  • 2
  • 28
  • 35
48

As long as you consider full loss of history to be no issue, the approach suggested by Ajay is perfectly valid. But in case you want to maintain the history of your shallow clone I have a different suggestion.

A shallow clone pretends to have the full history by using a so called graft point to fake the parent of the "first" commit. If we assume that we have the full history available, we could rephrase the question: How can I throw away the history before a specific revision?

This means we can use a combination of a graft point and git filter-branch (as suggested in the linked question). However you have to note that this will rewrite your full history, making the new one incompatible with the remote we initially cloned from. Due to this, we should remove the old remote from our repository.

git remote remove <old-remote-name>

Now we can start our rewrite. Let's assume that we want to make the current master commit the new root for the repository.

git rev-parse --verify master >> .git/info/grafts
git filter-branch -- --all

This will rewrite the full history of our repository, with the current master commit as the new root. You can finalize the rewrite by removing the "backup" references in refs/original. Furthermore you can now delete the .git/shallow file.

After you've done this, you should be able to push the now ungrafted history in your new remote.

Sascha Wolf
  • 18,810
  • 4
  • 51
  • 73
  • 4
    Git version >1.9.0 allows to push from a shallow clone. And it's quite convenient if you want to keep the full history on a server but only require last year's history for a different machine. The only thing is, I think you need to have git >1.9.0 on both the client and server in order to utilize this feature. – jtorca Jun 08 '15 at 18:30
  • Instead of `git rev-parse --verify master >> .git/info/grafts`, I first checked out the new graft point then used the commit reference: `git rev-parse --verify 9133eece0 >> .git/info/grafts`. I then did the `git filter-branch -- --all`. I didn't need to remove the `.git/shallow` file as it was already gone. Didn't quite understand how to remove the "backup" references in `refs/original`", and I'm guessing this is why the grafted repo was still 68M in size. However after pushing to the new upstream repo I then re-cloned locally and the result was a 112K clone which is what I expected. – JinnKo Jul 10 '15 at 13:41
  • 1
    @JinnKo What I meant with *removing the "backup" references*, was to literally execute a `rm -rf .git/refs/original`. ;) – Sascha Wolf Jul 16 '15 at 13:26
  • 2
    Refs can exist in various forms. The safe way to remove a reference is e.g. `git update-ref -d refs/original/master` (actually I usually `git push . :refs/blah` because I once didn't know about update-ref). See [this answer to "How to delete the old history"](http://stackoverflow.com/a/5985276/260122) for a more thorough explanation. – clacke Oct 31 '15 at 14:25
  • This worked for me, at least in broad strokes. `.git/info/grafts` is apparently deprecated now (I'm using git 2.24). My complete workflow was: 1. `git clone --depth 1 https://github.com/ my-repo` 2. `cd my-repo` 3. `git remote remove origin` 4. `git rev-parse --verify >> .git/info/grafts` 5. `git filter-branch -- --all` 6. `git replace --convert-graft-file` 7. `git remote add origin https://github.com/` 8. `git push --set-upstream origin main` (step 6 got rid of the warnings I was seeing) – raner Oct 08 '22 at 00:36
1

Try something like this:

mkdir -p /tmp/git-copy
cd /tmp/git-copy

# create another copy of your repository
git clone file:///path/to/cloned/repo

cd repo
git rebase -i (first-commit)

# in vim:
# :2,$s/^pick/squash
# :w

# Now wait, it will take a while...

git push --mirror git@github.com:username/new-repo.git

I tried it just now on this repository. Seems to work - no history and all submodules are intact.

Aleksander Alekseev
  • 1,854
  • 4
  • 25
  • 57
  • 1
    Just rebasing didn't worked for me as using `depth` argument always makes the clone shallow, and that is what OP is asking for, and my use case too. The right answer needs `filter-branch` as Zeeker says. – Jesús Franco Jan 17 '18 at 16:53
  • ` :2,$s/^pick/squash` this is a vim command or is the text that we should add at top? can you please explain what this does? – Arnold Roa Jun 24 '18 at 01:53
  • @ArnoldRoa This is a VIM command that replaces all "pick" with "squash" in the VIM file (from the 2nd line onwards). – user2528260 Jan 24 '19 at 00:23