Re: [PATCH 2/3] git-svn: documentation updates
- From
- Eric Wong <normalperson@yhbt.net>
- Date
- Dec 3, 2006, 02:12 UTC
- Message-ID
- <20061203021244.GA30316@hand.yhbt.net>
- In-Reply-To
- <7vd571yccv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
Show 12 quoted lines
> Eric Wong <normalperson@yhbt.net> writes: > > > Both push and pull are git/bk/hg(?)-specific terms; most SVN users are > > not accustomed to them. Using 'pull' with git-svn has already been > > discouraged for a while (since the introduction of dcommit); and > > having a 'push' without a 'pull' would be very confusing. > > I am not sure how 'push' side should be integrated, but I wish > people could simply update a branch that is managed by foreign > SCM interfaces such as git-svn and git-cvsimport with 'git fetch' > by saying that the remote URL points at a non-git "repository" > in remotes/ (or corresponding config).
Ack on being able to use 'git fetch'.
Show 8 quoted lines
> git-cvsimport builds the git objects from the changeset without > using the working tree, and it would be very natural and simple > to integrate it into 'git fetch', pretending as if it is just a > funny transport. > > If the interface uses the working tree to update the state from > foreign SCM, then integrating with git-fetch would be > inpractical. I guess git-svn works that way?
git-svn only needs a working tree (hidden away in .git/svn/ and the user should never see it) when it uses the command-line svn client. If the SVN:: libraries are available, then git-svn just uses an alternative index like cvsimport.