1

I'm using a git bare repo on a usb storage as a transport mechanism for work between different locations. I initiated the usb storage by doing:

git clone --bare /path/to/clone

The question is how to refresh the clone (i.e. the get the equivalent result of a new clone) without erasing the old clone and doing a new one.

Just doing git-fetch isn't enough for the following reasons:

  1. git-fetch doesn't fetch new branches
  2. If the source did a rebase or commit -amend then the usb-clone will still contain the old commits.

The first issue may be solved by the following script:

git fetch --prune origin -- \
  `git ls-remote -h origin | while read sha ref; do echo "+$ref:$ref"; done`

(See: http://git.661346.n2.nabble.com/How-to-fetch-all-remote-branches-from-remote-td3380849.html)

But how can the second issue be solved? How can I erase commits that no longer exist on the remote?

Dov Grobgeld
  • 4,783
  • 1
  • 25
  • 36

3 Answers3

1

Instead of using --bare switch for cloning use the --mirror one.
Then git fetch will do the job.

Discussed here

Community
  • 1
  • 1
Vertigo
  • 1,847
  • 22
  • 19
1

git gc will clean up any unreachable commits.

It looks like you're running commands inside the usb-mounted directory. If this is the case, then I'd suggest that you take a different approach. Use git push from your working directory to update the usb repository, and git pull when you move it to the other machine. This will take care of ensuring that everything is up to date on the usb repository. Don't run anything from inside the usb-mounted directory.

By the way, git fetch should pull in new branches. If it isn't then there is something else wrong.

Cameron Skinner
  • 51,692
  • 2
  • 65
  • 86
  • I'll check the fetch issue again. Regarding the second issue, if I understand you correctly you're basically saying that it would be enough to do "git fetch; git gc" to get rid of commits that remain because the source did rebase or "commit -a"? I have to test that. – Dov Grobgeld Sep 18 '11 at 08:10
  • `git gc` on its own won't remove those commits since they will still be pointed to by the reflog for 30 days (by default). You can still do this, of course, (see other S.O. answers) but the real question is why the OP needs to... – Mark Longair Sep 18 '11 at 09:14
  • After a more thorough reading of the man page, I see the @Mark is correct: `git gc` by itself will not clean up unreachable objects unless they are older than (by default) 90 days. You can tune the parameters to make it more aggressively delete unreachable objects. However, unless you rebase a **lot** (like thousands of times), or your USB storage is extremely small, then it's probably not going to be a problem. Git repositories are pretty space-efficient. – Cameron Skinner Sep 18 '11 at 19:54
  • By the way, running `git rebase` does not necessarily mean the rebased commits no longer exist in the source repository. They will be subject to the same garbage collection rules as any other commit so might still be referenced in the reflog or other places. – Cameron Skinner Sep 18 '11 at 19:56
  • Interestingly, if I understand this correctly, this means that if you are 100% that nobody has done a git pull since your latest push, there is no harm in doing a push of a amended (or rebased) commit. The old commits will evently be garbage collected as they are not referenced. – Dov Grobgeld Sep 19 '11 at 09:01
0

git fetch does fetch new branches.

Do a git push to the bare repo from your working / main repo as an alternative.

manojlds
  • 290,304
  • 63
  • 469
  • 417