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