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