[git-users] Re: git - svn migration question
On Thursday, December 20, 2012 5:35:56 AM UTC+1, Daniel Pomerantz wrote: I have what is probably a silly question. They are not silly :) Short background: I hate SVN and finally got my boss to agree to move to git, if I can make him happy with it. I started looking at migrating today and ran the following command for our relatively small repo. It should be noted that I have the standard /trunk/branches/tags directories from the svn_url: git svn clone svn_url --authors-file=users.txt --no-metadata -s Git_Repo_Name The repo itself looks to have been created with all revisions, but the tags and branches are missing. When I CD into the directory and type git tag -l it comes up empty, and when I type in git show-branch I get one entry, which isn't really a branch at all. Just a revision where the comment had b as the first letter. Any reason why you are not using the --stdlayout argument? This is key for converting a standard layout SVN (trunk/branches/tags) into branches in Git. So lots of questions: Why do some of the branches and tags show up with an @pegrev and not others? Maybe it's something I don't need to worry about, but what is it? I think they're kind of timestamps for when something was branched out in SVN. You can just ignore them, and delete them later on when you're done with everything else. Since these are showing up as remote, does that mean that they are in the svn repo only? They're also in your Git repo. Remote branches are always in your own repository as well. You'll fix this when you push all branches into a bare Git repository as I explain further down. Big question I guess is what am I doing wrong? How do I import my svn repo into git, complete with branches and tags? Note that git-svn doesn't create Git tags from SVN tags. SVN tags are physically equal to branches, so that's why they are converted to Git branches. This however, is easy to fix. See the Changing tagging commits to tags section in this page: http://thomasrast.ch/git/git-svn-conversion.html As a bonus question, how do I do that into a bare git repo? The best method I've found so far is to clone it local and then git clone --bare Git_Repo_Name git_repo_name.git Will that even work? Is it the best way for a bare repo migrated from svn? After you have created a git-svn clone. you can create an empty bare repo, and push all branches from your git-svn clone into the bare repository. The gist of it is: First do the git-svn clone (you've probably already done this): cd ~/git-repos/ git svn clone -s foo-fetching Next up, initialize the bare repository cd ~/git-repos git init --bare ~/git-repos/foo.git In fetch repo: add the remote 'bare': cd foo-fetching git remote add bare ~/git-repos/foo.git Now edit foo-fetching/.git/config: #Set fetch to do remotes instead of heads: fetch = +refs/remotes/*:refs/remotes/bare/* #Add a push configuration, push all remotes to heads: push = refs/remotes/*:refs/heads/* Now, back on the command line, push all branches from git-svn clone into the bare repository: git push bare After this, you can start cleaning up, put the bare repository in some shared folder where others can access it, and profit. I've shown all this, plus a few other tricks in this presentation: http://www.tfnico.com/presentations/git-and-subversion --
[git-users] Re: git push origin :TRUNK-3814
On Thursday, December 20, 2012 7:48:08 AM UTC+1, k-joseph wrote: Hi, every one, i have just began using using git and do request for your assistance, i want to delete a remote branch, i have already deleted it locally, but am getting an error , and the branch still exisits on my github account: this is the error: $ git push origin :TRUNK-3814 Enter passphrase for key '/c/Users/kaweesi joseph/.ssh/id_rsa': remote: error: refusing to delete the current branch: refs/heads/TRUNK-3814 To g...@github.com:k-joseph/openmrs-core.git ! [remote rejected] TRUNK-3814 (deletion of the current branch prohibited) error: failed to push some refs to 'g...@github.com:k-joseph/openmrs-core.git' Maybe the branch is configured to be the default branch of the repository in Github? Have a look under https://github.com/k-joseph/openmrs-core/settings - and see if TRUNK-3814 is the default branch (hint: it is), and switch to something else, like master. --
[git-users] Re: Help:How to merge multiple commits to one?
On Thursday, December 20, 2012 7:25:19 AM UTC+1, Wei Alex wrote: Hi,All: I need to merge multiple special commits to one.Please help me. For example, I have some commits like this： A-B-C-D-E. Some of these were commited by me. I want to select them and merge them to one commit just like A-C-E.The new commit A include the commit A B and D. Now I knew one method to merge multiple commits to one. *git resest --soft HEAD^n* ***git commit --amend* BUT this method can just merge the TOP n commit not the special ones. Please tell me how can I finish this work.Thanks. Rebase interactive is your friend: http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages In essence: git rebase -i A # reorder the commits so that the ones you want to squash together are right after one another # squash up the commits Remember, if you have already shared or published this history you should NOT rewrite/rebase it any more. --
Re: [git-users] git.for solo developer
Then I must make the following question: Can Netbeans IDE be used together with git? Has anyone done it? I mean is it possible from a technical point of view? Netbeans is invaluable to me when it comes to development 2012/12/20 Les Nightingill codehac...@comcast.net Dmitris: all my work is solo and I love git. The git command line is (for me) non-intuitive and inconsistent, but the ease of making ad hoc branches to try some ideas, and then abandon or merge is unrivaled. Les On Dec 19, 2012, at 12:30 PM, Dimitris Papageorgiou wrote: Do you think git would be useful for a solo developer as I am right now? I am developing a web app alone-no other developers. VCS is always useful kind of aid for a developer. But I think Git is intended more for teams of developers that wotk on the same project so that they can take advantage of Git's distributed functionality. I am asking these things because I am complete beginner in Git and in general to version control systems -- -- --
[git-users] Re: git - svn migration question
On 12/20/12 02:22, Thomas Ferris Nicolaisen wrote: On Thursday, December 20, 2012 5:35:56 AM UTC+1, Daniel Pomerantz wrote: git svn clone svn_url --authors-file=users.txt --no-metadata -s Git_Repo_Name Any reason why you are not using the --stdlayout argument? This is key for converting a standard layout SVN (trunk/branches/tags) into branches in Git. Just for the record, Daniel *is* using -s to get the stdlayout as you yourself use: git svn clone -s foo-fetching :-) -tkc --
Re: [git-users] git.for solo developer
On Thursday, December 20, 2012 11:32:27 AM UTC+1, Dimitris Papageorgiou wrote: Then I must make the following question: Can Netbeans IDE be used together with git? Oh, why yes it can indeed: http://netbeans.org/kb/docs/ide/git.html --
[git-users] Re: git - svn migration question
On Thursday, December 20, 2012 12:42:45 PM UTC+1, Tim Chase wrote: Just for the record, Daniel *is* using -s to get the stdlayout as you yourself use: Oh yes, now I see it! Was a bit perplexed by that :) --
[git-users] Re: git - svn migration question
Thank You Thomas, As Tim pointed out, I did use the -s switch to indicate that I used the standard svn layout. I would have thought that using that switch and the meta-data in svn which indicates the source rev of each item in the tags directory, that git-svn would be able to apply a tag with the name of the directory to each item at its source rev, and then not create them as branches. Isn't that the point of that switch? Regardless, I'll take a look at the information you posted for how to clean this up and see if I can make it usable. Thank you. If I didn't say it earlier, this is a Proof of Concept to get a migration tested. I can always do it over if something is wrong with it. If there is any other info out there, please share, but in the mean time, I'll look through what you posted and write back with any questions. dmp On Thursday, December 20, 2012 2:22:50 AM UTC-6, Thomas Ferris Nicolaisen wrote: On Thursday, December 20, 2012 5:35:56 AM UTC+1, Daniel Pomerantz wrote: I have what is probably a silly question. They are not silly :) Short background: I hate SVN and finally got my boss to agree to move to git, if I can make him happy with it. I started looking at migrating today and ran the following command for our relatively small repo. It should be noted that I have the standard /trunk/branches/tags directories from the svn_url: git svn clone svn_url --authors-file=users.txt --no-metadata -s Git_Repo_Name The repo itself looks to have been created with all revisions, but the tags and branches are missing. When I CD into the directory and type git tag -l it comes up empty, and when I type in git show-branch I get one entry, which isn't really a branch at all. Just a revision where the comment had b as the first letter. Any reason why you are not using the --stdlayout argument? This is key for converting a standard layout SVN (trunk/branches/tags) into branches in Git. So lots of questions: Why do some of the branches and tags show up with an @pegrev and not others? Maybe it's something I don't need to worry about, but what is it? I think they're kind of timestamps for when something was branched out in SVN. You can just ignore them, and delete them later on when you're done with everything else. Since these are showing up as remote, does that mean that they are in the svn repo only? They're also in your Git repo. Remote branches are always in your own repository as well. You'll fix this when you push all branches into a bare Git repository as I explain further down. Big question I guess is what am I doing wrong? How do I import my svn repo into git, complete with branches and tags? Note that git-svn doesn't create Git tags from SVN tags. SVN tags are physically equal to branches, so that's why they are converted to Git branches. This however, is easy to fix. See the Changing tagging commits to tags section in this page: http://thomasrast.ch/git/git-svn-conversion.html As a bonus question, how do I do that into a bare git repo? The best method I've found so far is to clone it local and then git clone --bare Git_Repo_Name git_repo_name.git Will that even work? Is it the best way for a bare repo migrated from svn? After you have created a git-svn clone. you can create an empty bare repo, and push all branches from your git-svn clone into the bare repository. The gist of it is: First do the git-svn clone (you've probably already done this): cd ~/git-repos/ git svn clone -s foo-fetching Next up, initialize the bare repository cd ~/git-repos git init --bare ~/git-repos/foo.git In fetch repo: add the remote 'bare': cd foo-fetching git remote add bare ~/git-repos/foo.git Now edit foo-fetching/.git/config: #Set fetch to do remotes instead of heads: fetch = +refs/remotes/*:refs/remotes/bare/* #Add a push configuration, push all remotes to heads: push = refs/remotes/*:refs/heads/* Now, back on the command line, push all branches from git-svn clone into the bare repository: git push bare After this, you can start cleaning up, put the bare repository in some shared folder where others can access it, and profit. I've shown all this, plus a few other tricks in this presentation: http://www.tfnico.com/presentations/git-and-subversion --
[git-users] How to install git on CentOS5 without root access?
Hi, I'm trying to add git functionality to a production CentOS 5.5 system that has no development tools (since it is a production system). So I don't have access to make/gcc/etc. I basically want to install Git to be able to easily quickly synchronize a website dir with my Git repo, so I have no need for compiling any source files. I do not have root access, and for obvious reasons, root is does not want to install Git on a prod system, but is okay if I can set it up locally for my own use. I've tried to download and unpack a git-core.rpm into my home dir and although I am able run some functionality of git, none of git's dependencies are where it expects them and so it fails. My structure looks like the following: ~/git ~/git/usr ~/git/usr/bin ~/git/usr/share ~/git/usr/share/doc ~/git/usr/share/git-core ~/git/usr/share/locale ~/git/usr/share/man When I run something like git help clone, I get an error msg No manual entry for git-clone. This is confirmed by git --man-path (/usr/share/man). Other commands fail similarly. How can I tell git to use ~/git as the root instead of / as the root to all git dependencies without recompiling? I cannot seem to find any environment vars or git vars that I can set. Thanks! Eric --
Re: [git-users] Re: git - svn migration question
I have found the svn2git command quite helpful. It's a ruby wrapper that provides some easy to work with configuration options and sanity checks. https://github.com/nirvdrum/svn2git Here's the readme/quickstart documentation: https://github.com/nirvdrum/svn2git/blob/master/README.markdown The examples section shows what a source svn repo might look like and then what the newly created git repo will look like. The Usage - Initial Conversion section shows 9 examples of how this can be run for different scenarios. Matt --
[git-users] Re: git - svn migration question
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
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?
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?
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 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? 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? Just trying to figure things
out, so any information would be appreciated.
Thanks,
dmp
On Thursday, December 20, 2012 2:22:50 AM UTC-6, Thomas Ferris Nicolaisen
wrote:
On Thursday, December 20, 2012 5:35:56 AM UTC+1, Daniel Pomerantz wrote:
I have what is probably a silly question.
They are not silly :)
Short background: I hate SVN and finally got my boss to agree to move to
git, if I can make him happy with it. I started looking at migrating today
and ran the following command for our relatively small repo. It should be
noted that I have the standard /trunk/branches/tags directories from the
svn_url:
git svn clone svn_url --authors-file=users.txt --no-metadata -s
Git_Repo_Name
The repo itself looks to have been created with all revisions, but the
tags and branches are missing. When I CD into the directory and type git
tag -l it comes up empty, and when I type in git show-branch I get one
entry, which isn't really a branch at all. Just a revision where the
comment had b as the first letter.
Any reason why you are not using the --stdlayout argument? This is key for
converting a standard layout SVN (trunk/branches/tags) into branches in Git.
So lots of questions: Why do some of the branches and tags show up with
an @pegrev and not others? Maybe it's something I don't need to worry
about, but what is it?
I think they're kind of timestamps for when something was branched out in
SVN. You can just ignore them, and delete them later on when you're done
with everything else.
Since these are showing up as remote, does that mean that they are in the
svn repo only?
They're also in your Git repo. Remote branches are always in your own
repository as well. You'll fix this when you push all branches into a bare
Git repository as I explain further down.
Big question I guess is what am I doing wrong? How do I import my svn
repo into git, complete with branches and tags?
Note that git-svn doesn't create Git tags from SVN tags. SVN tags are
physically equal to branches, so that's why they are converted to Git
branches. This however, is easy to fix. See the Changing tagging commits
to tags section in this page:
http://thomasrast.ch/git/git-svn-conversion.html
As a bonus question, how do I do that into a bare git repo? The best
method I've found so far is to clone it local and then git clone --bare
Git_Repo_Name git_repo_name.git Will that even work? Is it the best
way for a bare repo migrated from svn?
After you have created a git-svn clone. you can create an empty bare repo,
and push all branches from your git-svn clone into the bare repository.
The gist of it is:
Re: [git-users] How to install git on CentOS5 without root access?
On Thu, 20 Dec 2012 08:25:12 -0800 (PST) ebenza...@gmail.com wrote: I'm trying to add git functionality to a production CentOS 5.5 system that has no development tools (since it is a production system). So I don't have access to make/gcc/etc. I do not have root access, and for obvious reasons, root is does not want to install Git on a prod system, but is okay if I can set it up locally for my own use. You could tell your root this position is outright stupid and the reasons to maintain it are not at all obvious: if you will have Git installed under your ~, these will be the same executable files, no different from those you'd get if Git was installed system-wide. Any harm which can potentially be inflicted to the system by running Git on it does not somehow change if Git is in ~joe/bin rather than in /usr/bin, really. Moreover, binaries installed by a Joe Random User are owned by him/her and hence are *writable* by any process running with the same credentials. This differs from a system-wide installation where such binaries are writable only by root, and it's beleived to be harder to get root on a typical system than to get that Joe Random User. Also note that while I am not familiar with Git package for CentOS I beleive that merely installing Git in a system is not supposed to automatically enable/run its daemon process or make it accessible via inetd or whatever. At least I hope the CentOS package's maintainers did not goof on a scale that big. Without any daemons configured and running a harm which could be inflicted using Git is not too much different from that which can be inflicted using `cat`. TL;DR Installing whatever piece of software in the system does indeed potentially widen its surface of attack, but installing it to the home directory of a regular user does not in any way alleviate this effect, but supposedly rather makes it worse. I've tried to download and unpack a git-core.rpm into my home dir and although I am able run some functionality of git, none of git's dependencies are where it expects them and so it fails. My structure looks like the following: ~/git ~/git/usr ~/git/usr/bin ~/git/usr/share ~/git/usr/share/doc ~/git/usr/share/git-core ~/git/usr/share/locale ~/git/usr/share/man When I run something like git help clone, I get an error msg No manual entry for git-clone. This is confirmed by git --man-path (/usr/share/man). Other commands fail similarly. This is not really interesting (see below). Are you able to run `git init`, `git clone` `git fetch`? If they fail, then how? (Please, cite the full error output). How can I tell git to use ~/git as the root instead of / as the root to all git dependencies without recompiling? I cannot seem to find any environment vars or git vars that I can set. I would install CentOS 5.5 somewhere (on a virtual machine for instance), install the necessary developer tools there and then built Git from the source configuring it to use /home/you/git as its PREFIX. Then install it (on the build machine, I mean) using something like $ mkdir /var/tmp/git $ make DESTDIR=/var/tmp/git install and then pack it using something like $ tar -C /var/tmp/git -c -f - . | gzip -c9 /var/tmp/git.tar.gz You will get a compressed tarball with relative pathnames in it. Then just transfer the resulting tarball to the target system (using `scp` for instance) and unroll it relative to your home directory: $ tar -C ~ -x /var/tmp/git.tar.gz to get your ~/git hierarchy back. Supposedly this should work (though I have not tested). --
Re: [git-users] How to install git on CentOS5 without root access?
On Thu, 20 Dec 2012 12:31:04 -0500 Eric B ebenza...@gmail.com wrote: Are you able to run `git init`, `git clone` `git fetch`? If they fail, then how? (Please, cite the full error output). Well, none of the man pages work (which is an annoyance, but not the end of the world). They were not expected to work: IIRC `git help whatever` just calls `man git-whaveter` internally, so you have to tinker with the MANPATH environment variable (rean the man(1) manual page). I've set up an env var for GIT_EXEC_PATH and GIT_TEMPLATE_PATH to point to the correct locations, but when I try `git clone`, I get the following: [eric git]$ git clone https://e...@git.assembla.com/myproj.git Cloning into 'myproj'... Password for 'https://e...@git.assembla.com': error: RPC failed; result=22, HTTP code = 401 fatal: The remote end hung up unexpectedly In all fairness, I do not know if that is due to my package being installed under my home dir vs standard dirs, or if there is a firewall issue/etc, but I can confirm that a clone to that repo works properly on another system. Similarly, I can confirm that I can d/l data from other https sites without issues. Try running that same command while having the GIT_TRACE variable in your environment: $ export GIT_TRACE=1 $ git clone https://... In this case higher-level Git tools will print out what lower-level tools they call. And you did not tell if `git init` works for you. It's a major command and it's not supposed to access any remote repository so being able to run it successfully would be a good sign. --
Re: [git-users] How to install git on CentOS5 without root access?
On Thu, Dec 20, 2012 at 12:08 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: Are you able to run `git init`, `git clone` `git fetch`? If they fail, then how? (Please, cite the full error output). Well, none of the man pages work (which is an annoyance, but not the end of the world). I've set up an env var for GIT_EXEC_PATH and GIT_TEMPLATE_PATH to point to the correct locations, but when I try `git clone`, I get the following: [eric git]$ git clone https://e...@git.assembla.com/myproj.git Cloning into 'myproj'... Password for 'https://e...@git.assembla.com': error: RPC failed; result=22, HTTP code = 401 fatal: The remote end hung up unexpectedly In all fairness, I do not know if that is due to my package being installed under my home dir vs standard dirs, or if there is a firewall issue/etc, but I can confirm that a clone to that repo works properly on another system. Similarly, I can confirm that I can d/l data from other https sites without issues. I would install CentOS 5.5 somewhere (on a virtual machine for instance), install the necessary developer tools there and then built Git from the source configuring it to use /home/you/git as its PREFIX. Then install it (on the build machine, I mean) using something like Sure - I was trying to avoid that effort, so was hoping that there would be some other way(s) to specify the required paths. Thanks, Eric --
Re: [git-users] How to install git on CentOS5 without root access?
On 20/12/2012 18:00, Eric B wrote: [eric git]$ git clone https://e...@git.assembla.com/myproj.git Cloning into 'myproj'... Password for 'https://e...@git.assembla.com https://e...@git.assembla.com/': error: RPC failed; result=22, HTTP code = 401 fatal: The remote end hung up unexpectedly HTTP 401 is an 'unauthorized' message, it sounds like user 'eric' doesn't have authority to clone https://git.assembla.com/myproj.git. Perhaps the wrong password or that user simply isn't allowed to access that repository? --
[git-users] Re: git - svn migration question
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
--
[git-users] Re: git - svn migration question
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
[git-users] Re: Help:How to merge multiple commits to one?
Hi Thomas: Thank you for your reply. I will try it. 在 2012年12月20日星期四UTC+8下午4时28分21秒，Thomas Ferris Nicolaisen写道： On Thursday, December 20, 2012 7:25:19 AM UTC+1, Wei Alex wrote: Hi,All: I need to merge multiple special commits to one.Please help me. For example, I have some commits like this： A-B-C-D-E. Some of these were commited by me. I want to select them and merge them to one commit just like A-C-E.The new commit A include the commit A B and D. Now I knew one method to merge multiple commits to one. *git resest --soft HEAD^n* ***git commit --amend* BUT this method can just merge the TOP n commit not the special ones. Please tell me how can I finish this work.Thanks. Rebase interactive is your friend: http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages In essence: git rebase -i A # reorder the commits so that the ones you want to squash together are right after one another # squash up the commits Remember, if you have already shared or published this history you should NOT rewrite/rebase it any more. --
Re: [git-users] display git notes for a specific sha
Hello Krishna, have you ever tried to use git notes show command? You can pass a SHA after the show to specify a commit: git notes show SHA William Seiti Mizuta @williammizuta Desenvolvedor da Caelum On Fri, Dec 21, 2012 at 3:33 AM, krishna chaitanya kurnala kkc...@gmail.com wrote: git log --notes=REF --format=%N --
[git-users] Pushing symbolic references to remote repositories?
Hi, I need to share a symbolic reference - essentially, a named pointer to another reference - among multiple repositories. As shown in the code below, I can successfully create a local symbolic-ref `foo_ptr` to branch `foo`, but can't push it to a remote, in this case `origin`: $ git branch foo; git symbolic-ref foo_ptr refs/heads/foo; git rev-parse foo_ptr fbfec27dc6d42d48ca5d5b178caa34c666a4c39b $ git push origin foo foo_ptr error: dst ref refs/heads/foo receives from more than one src. Is there a clean and reliable way to do that, or are symbolic references just not meant to be shared? Thanks, D. --
