(no commit message)
authorblipvert <blipvert@web>
Mon, 13 Sep 2010 01:45:13 +0000 (01:45 +0000)
committerJoey Hess <joey@kitenet.net>
Mon, 13 Sep 2010 01:45:13 +0000 (01:45 +0000)
doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn

index 5b7be1187576a6d6d14950bc04580ce1e85b1ca5..4c1e461e320b58d2129fbca205ae2892731feaa5 100644 (file)
@@ -8,4 +8,4 @@ Pruning remote branches can be done automatically with the --prune option to "gi
 > work to the current git commands it uses. I don't see any errors here
 > from obsolete remote branches. --[[Joey]] 
 
-Suppose a remote repository contains a branch named "foo", and you fetch from it.  Then, someone renames that branch to "foo/bar".  The next time you fetch from that repository, you will get an error because the obsolete branch "foo" is blocking the branch "foo/bar" from being created (due to the way git stores refs for branches).  Pruning gets around the problem.  It doesn't really add much overhead to the fetch, and in fact it can *save* overhead since obsolete branches do consume resource (any commits they point to cannot be garbage collected).
+Suppose a remote repository contains a branch named "foo", and you fetch from it.  Then, someone renames that branch to "foo/bar".  The next time you fetch from that repository, you will get an error because the obsolete branch "foo" is blocking the branch "foo/bar" from being created (due to the way git stores refs for branches).  Pruning gets around the problem.  It doesn't really add much overhead to the fetch, and in fact it can *save* overhead since obsolete branches do consume resource (any commits they point to cannot be garbage collected).  --[[blipvert]]