4

I have a local git repo that I cloned by using

git clone --depth 1 my_repo_url

so that I only have the latest commit and don't have to worry about keeping a large history around.

If I now do a git pull, I may now receive, let's say, two more commits from the remote repo. What I want to do is update my repo to again only maintain the latest commit and NOT the rest of the history. However, I do NOT want to use squashing/rebasing, since this will actually change my local history and result in conflicts when I try to pull again from the remote server.

Basically, if I have a commit history of:

commit1 --> commit2 --> commit3 --> commit4

I want to maintain only a snapshot of the repo at point commit4.

But I do not want to squash all these commits, because then I will be left with commit4* which will have a different hash from the original commit4, and hence will cause conflicts when I try to pull from origin again.

I also do not want to use git clone again, since this will not take advantage of the fact that I may only have to send a small diff over the network, if something very small changed in the latest commit on the remote server.

rmacqueen
  • 971
  • 2
  • 8
  • 22
  • 1
    And the reason for not wanting to keep more than one commit of upstream history is... the gigantic size of each commit? – Magnus Bäck Dec 31 '13 at 01:51
  • @Magnus Back : That's correct. Many of the files being tracked are large binary files. – rmacqueen Dec 31 '13 at 03:01
  • 1
    Then Git is not the right tool: http://stackoverflow.com/a/19494211/6309 – VonC Dec 31 '13 at 08:39
  • @VonC The particular solution you pointed to is GPL licensed, which may not be acceptable for this user. However, there are other solutions listed in that link, for which I thank you. – BlackVegetable Dec 31 '13 at 17:44
  • @BlackVegetable I wasn't really pointing out a particular solution (or I would have written an answer, not a comment). I was referring to a post where I explain why Git internals aren't a good fit for large files and large number of files. I agree that a GPL tool might not be the right tool either. – VonC Dec 31 '13 at 19:11

1 Answers1

0

You might be better off using git-annex instead.

http://git-annex.branchable.com/

Alec the Geek
  • 1,970
  • 14
  • 14