How to clone seed/kick-start project without the whole history?
Asked Answered
F

3

100

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

Frigidaire answered 20/4, 2015 at 12:41 Comment(1)
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.Precentor
C
88

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.

Castello answered 20/4, 2015 at 13:6 Comment(6)
It will most likely remove all submodules.Molybdate
@AleksanderAlekseev what submodules are you talking about?Scherzo
If you don't need the history this is the easiest fix.Scherzo
@Scherzo can I still merge updates in the upstream project into my project if I take this route?Conduct
I am not sure I understand your question @FelipeAlmeida. In any case this way of doing things is as if you have created a completely new git project with existing source. Whatever you can do with a new project should be possible if you follow this way.Scherzo
this will remove other branches data also then only current branch data will come in this.Weismannism
Z
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.

Zaibatsu answered 20/4, 2015 at 14:1 Comment(5)
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.Quintinquintina
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.Mammalian
@Mammalian What I meant with removing the "backup" references, was to literally execute a rm -rf .git/refs/original. ;)Zaibatsu
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" for a more thorough explanation.Dixson
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/<repo info> my-repo 2. cd my-repo 3. git remote remove origin 4. git rev-parse --verify <commit hash of HEAD/master> >> .git/info/grafts 5. git filter-branch -- --all 6. git replace --convert-graft-file 7. git remote add origin https://github.com/<my private GH repo> 8. git push --set-upstream origin main (step 6 got rid of the warnings I was seeing)Athalie
M
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 [email protected]:username/new-repo.git

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

Molybdate answered 4/1, 2016 at 20:6 Comment(4)
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.Pteryla
` :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?Capacious
@ArnoldRoa This is a VIM command that replaces all "pick" with "squash" in the VIM file (from the 2nd line onwards).Pastime
Yes, this squashes everything into one commit. You can use fixup instead of squash to discard the commit messages.Yawl

© 2022 - 2024 — McMap. All rights reserved.