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
>>
>

-- 


Reply via email to