Quick update on the nonexistent reg issue. Removing the depth flag didn't
resolve the issue, just delayed it. The full output is this:

C:\git>git clone file:////server/git/Pushed.git Pushed
Cloning into 'Pushed'...
remote: Counting objects: 90813, done.
remote: Compressing objects: 100% (22899/22899), done.
Receiving objects: 100% (90813/90813), 474.65 MiB | 353 KiB/s, done.
emote: Total 90813 (delta 66440), reused 90813 (delta 66440)
Resolving deltas: 100% (66440/66440), done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.
It gets to be about the full compressed size (500MB) before it craps out.
I ran it verbosely and saw nothing new. My big question here is did it get
messed up (or not get something done) the way that I created it. I'll
certainly recreate the repo when this gets moved to production. This is
just a PoC.
Thanks!
dmp
On Thursday, December 20, 2012 3:37:47 PM UTC-6, dmprantz wrote:
>
> Sorry in advance if this is a duplicate post.
>
> Thanks for all the help. Is this something to be concerned about or can
> be explained?
>
> I've been trying to clone both new repositories locally using UNC paths,
> and both failed. sometimes after over an hour, and apparently there is no
> resume feature in git clone. I know one option is to clone, zip, and
> transfer, but I read another is to clone with a --depth=1, and then
> continually fetch to greater depths. I also had to switch from UNC naming
> to file:// urls as part of that process. Anyway, the "Cloned" bare repo
> cloned to my local system just fine. The "Pushed" bare repo had problems:
>
> warning: remote HEAD refers to nonexistent ref, unable to checkout.
>
> I took off the --depth=1, and it seems to be fine, so...is there something
> wrong with that repo? Is there something I need to do? Is this a reason
> to use the clone approach instead of the empty approach when creating the
> bare repo?
>
> Thanks so much for your help guys!
>
> dmp
>
> On Thursday, December 20, 2012 2:40:38 PM UTC-6, Thomas Ferris Nicolaisen
> wrote:
>>
>> On Thursday, December 20, 2012 5:52:49 PM UTC+1, dmprantz wrote:
>>
>>> Things look good, but I have a few questions/comments. What I've done
>>> so far since reading the responses and links:
>>>
>>> I removed "empty" commits with this command:
>>>
>>> git filter-branch --prune-empty --tag-name-filter cat -- --all
>>>
>>> I then created a shell script with the following and ran it to create my
>>> tags:
>>>
>>> git for-each-ref --format="%(refname)" refs/remotes/tags/ |
>>> while read tag; do
>>> GIT_COMMITTER_DATE="$(git log -1 --pretty=format:"%ad" "$tag")" \
>>> GIT_COMMITTER_EMAIL="$(git log -1 --pretty=format:"%ce" "$tag")" \
>>> GIT_COMMITTER_NAME="$(git log -1 --pretty=format:"%cn" "$tag")" \
>>> git tag -m "$(git for-each-ref --format="%(contents)" "$tag")" \
>>> ${tag#refs/remotes/tags/} "$tag"
>>> done
>>>
>>>
>> Very good. Have a look at what the history looks with tags like this:
>>
>> git log --all --decorate --graph --color --oneline
>>
>>
>> I then created a bare repository, connected to it as a remote, and made
>>> the following config changes for it in .git\config
>>>
>>> fetch = +refs/remotes/*:refs/remotes/bare/*
>>> push = refs/remotes/*:refs/heads/*
>>>
>>> Finally, ran the following command to get everything in the bare
>>> repository:
>>>
>>> git push barerepo
>>>
>>> From there I can cd into the bare repo and see all of my branches and
>>> tags. Looks good, but a few questions/comments:
>>>
>>> The branches still aren't visible "locally" on the SVN (fetched) repo.
>>> It doesn't matter too much since its only purpose was to create the bare
>>> repo, but it's odd. Is this normal?
>>>
>>
>> Yup. They're "remote" branches, which means they're kinda half-hidden
>> until you want to do some work on them, in which case you'll create local
>> tracking branches. This is a very normal thing in Git. When you clone a
>> repo, your clone will contain all the branches that exist in the remote
>> repository, but you'll only start off with one local branch, typically
>> master, which is a local tracking branch for the master branch in the
>> remote repo, typically called "origin/master". Don't worry if this seems a
>> bit confusing, it is for everyone in the start, and you'll get your
>> bearings soon.
>>
>> In a git-svn clone things are a bit warped, but it's basically the same
>> deal. Like you say, it doesn't matter much.
>>
>>
>> I created the bare repo in two ways, just tp play around.
>>>
>>> In one way I created a real bare repo with
>>>
>>> git init --bare bare.git
>>>
>>> and for the other I cloned the svn repo with
>>>
>>> git clone --bare fetched cloned.git
>>>
>>> Both of them allowed me to set a remote and push to it. Is there a
>>> functional difference? Any reason to use one over the other?
>>>
>>
>> The first one initiates a completely empty repository. The second one
>> gives it a head start by also cloning any local branches in the *fetched*
>> repository.
>> I prefer the first approach in this situation, feels cleaner.
>>
>>
>>> Final question (for now): the "fetched" repo weighs in at about 2 GB,
>>> and I made a couple of backups, which took about 4 minutes each. The
>>> "cloned" repo that I created and then pushed is about 650 MB, and took
>>> under a minute to push.
>>
>>
>> The fetching repo contains a work tree, that is all the files checked
>> out. For fair comparison, you have to look at the contents of the
>> fetched/.git/ directory.
>>
>>
>>> The "pushed" repo is only about 475 MB, and seemed to take longer to
>>> create than the "cloned" repo. Does this make sense? Why are the two
>>> repos so much smaller than the fetched svn repo? Why are they not the same
>>> size as each other?
>>
>>
>> The last question is that Git will occasionally re-organize and compress
>> its internal parts. Don't worry about this, what's important is that all
>> the right content is there and the history is correct.
>>
>>
>>> Is it because of compression used in the bare repos? The lack of a
>>> working copy? Does the cloned one have more uncompressed files because it
>>> was cloned?
>>
>>
>> Yeah, Git does some extra packing before sending things over the wire
>> (i.e. cloning).
>>
>> Have a look at the git book here, and you'll find a lot of answers:
>> http://git-scm.com/documentation
>>
>
--