34

I wish to get rid of a lot of my repo's old history, so I did a shallow clone to get the last 50 commits only:

git clone --depth=50 https://my.repo

That worked OK, but when I create a new Gitlab repo and try to push it I get an error:

git remote remove origin git remote add origin https://my.repo git push -u origin --all [...] ! [remote rejected] master -> master (shallow update not allowed)

But I only want these 50 commits to be in my new repo's history. How can I tell git that it should just treat these 50 commits as the only commits in the new repo?

Improve this question
1

2 Answers 2

Reset to default
69

Here's what I ended up doing - it worked perfectly. Note that I was moving from my old host (Bitbucket) to my new one (Gitlab). My comments are above the commands:

# First, shallow-clone the old repo to the depth we want to keep git clone --depth=50 https://[email protected]/....git # Go into the directory of the clone cd clonedrepo # Once in the clone's repo directory, remove the old origin git remote remove origin # Store the hash of the oldest commit (ie. in this case, the 50th) in a var START_COMMIT=$(git rev-list master|tail -n 1) # Checkout the oldest commit; detached HEAD git checkout $START_COMMIT # Create a new orphaned branch, which will be temporary git checkout --orphan temp_branch # Commit the initial commit for our new truncated history; it will be the state of the tree at the time of the oldest commit (the 50th) git commit -m "Initial commit" # Now that we have that initial commit, we're ready to replay all the other commits on top of it, in order, so rebase master onto it, except for the oldest commit whose parents don't exist in the shallow clone... it has been replaced by our 'initial commit' git rebase --onto temp_branch $START_COMMIT master # We're now ready to push this to the new remote repo... add the remote... git remote add origin https://gitlab.com/....git # ... and push. We don't need to push the temp branch, only master, the beginning of whose commit chain will be our 'initial commit' git push -u origin master

After that, I did a fresh clone of the new repo and I got just the master branch with the 50 most recent commits - exactly what I wanted! :-) Commit history has gone from 250MB to 50MB. Woot.

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

Excellent solution. For the new “initial commit” that you create, you may want to overwrite GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL and GIT_AUTHOR_DATE and set them to the original values of the commit that you’re about to replace.
Works great, however it seems that all existing tags on these rebased commits are lost - any idea how to fix that?
Interesting idea. I don't know if this will work for multiple branches where a subset of those branches depend on each other's history. In this "multiple branch dependency graph" scenario, doing a transplant (--onto) rebase on each would create duplicate commits I think, almost like cherry-picks.
actually, you could pull something off for the "multiple branch dependency graph" scenario, but it'd just be really tedious transplanting with rebase --onto...
@solstice333: yes, that's exactly what happens. To use the procedure without a lot of pain (i.e., merge conflicts), you need to cut the graph at a commit with no other active branches. I found my cut point using git log --graph, then had to be careful about the --depth value so it ended at exactly that commit.
12

You can't push a shallow clone into a new remote. You have to unshallow your clone first. Do a fetch from the old remote with the --unshallow parameter:

git fetch --unshallow old

and you should be able to push to your new remote. Note that you will need to add back your old remote first to fetch from it.

BUT...

That isn't what you want though. To remove the history from a full clone you would need to use git rebase to effectively remove the old history. There are other methods but since you only want the last 50 commits, this will be the easiest solution. Assuming the master branch:

git rebase --onto master~y master~x master

where x is the number of the first commit to be kept, and y is the number of the first commit you want to remove. At this point you can push to your new remote with only the history you want to keep. Note you will need to enumerate the commit numbers in git log yourself, as it wants an index (starting at 1) and not a commit hash.

Take care, as rewriting history can be a dangerous thing in Git, and has other implications you will need to consider. Also make sure not to push the changes to the old remote unless you want to remove the old history there as well.

Source: https://www.clock.co.uk/insight/deleting-a-git-commit

Improve this answer

3 Comments

With my shallow repo, could I use git checkout --orphan new_master, then START_COMMIT=$(git rev-list master|tail -n 1), then git checkout $START_COMMIT -- . and git commit -m "Initial commit" to make new_master initial commit the same as the repo state at the beginning of the shallow master, and then rebase master onto new_master? Would that work?
I'm not sure to be honest, but it looks like you already confirmed in your answer. I rarely rewrite repo history but there are cases when I've wanted to do the same thing you are, keep X number of recent commits and remove anything older. Personally I like running one command but as I indicated, and you discovered, there is more than one solution to this problem :)
This has worked for me straight away, thank you ----$> git fetch --unshallow old

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.