I'm using git-svn to handle and commit to a svn repository.
I also have created a local branch with commits that I don't want to be committed to the repository.
For safety, I want that branch to be able to do "git svn rebase" but "git svn dcommit" should fail (it doesn't have to be a pretty solution, I just want to make sure that the commits in that branch do not get committed by mistake).
Is there a way to setup the local branch like this ?
Related
I am attempting to convert a SVN repository into git. The SVN repository is being actively used, while we work out the details of converting.
I followed all the guides and created an author mapping file and cloned the SVN repository.
> git svn clone https://host/svn/Project --trunk=trunk -A svn-author-map.txt
Concurrently with this switch to git, I would also like to atone for some of the sins of the SVN past (stored passwords, etc). However as soon as I alter any of the history with git filter-branch or BFG, I seem to break the ability to incorporate any updates from SVN.
> git svn fetch --fetch-all
fatal: Invalid revision range [sha from clone]..refs/remotes/trunk
Is there a way to refresh the git-svn ids to the post filter-branch ids? Or is there no going back after changing any history?
If you edit the history after conversion, then maintaining the link can become tricky.
I guess the best options are either do one-time conversion (make svn source read-only, fully switch to edited git repo), or just keep the history as is and change the leaked passwords instead.
I've cloned an SVN repository into git using git-svn, but I'm having trouble rebasing and I thought to work around it by using svn to generate a patch between the old SVN revision I'd used to clone my git repo in the first place and the current version. That way I could just apply the patch and call it rebased.
Any idea how I can find the SVN revision number my current git-svn clone is based on?
git svn find-rev git-svn will print what you want.
If you do git log you should be able to see a history of all commits in your repository. The first of these will correspond to the SVN revision that your git repository was cloned from.
So, you might see something like this:
commit e3223a9f72fa80b16dbe1a471c73657a4cacee3d
Author: joe <joe#31875c6e-e9e7-0310-b337-c57ebf30f660>
Date: Tue Feb 22 14:30:26 2011 +0000
PO-310: Commit message here
git-svn-id: https://svn.myrepo.com/development/trunk#51174 31875c6e-e9e7-0310-b337-c57ebf30f660
In this instance, you can see that I have cloned from revision 51174 of the remote SVN repo (fake paths and names used here)
You can simplify the output from git log by using the --skip=<number> option (e.g. git log --skip=100, though this requires you to have some idea of the number of commits since you initially cloned the repository.
we have a central SVN repo in our company. I use git-svn on my laptop to be able to use a repo, when I'm not connected to the company network.
Now I was 3 weeks on a business trip and committed a lot to my local Git repo. There were also many commits to the SVN repo.
When I try "SVN Rebase" I have to edit conflicts in each of my Git changesets. What I would like to do is just to commit all of my local changes at once and then edit conflicts only once.
I'm fairly new to Git, so I don't know how this is done properly and if this is the best way.
I use TortoiseGit on Windows, so up to now I didn't really care about the command line.
Thanks for your help.
Once you go through conflict resolution in git-svn rebase once you are in a new tree with new commits that include your resolutions. A future git-svn rebase will not encounter the same problems (unlike repeated merges, which is where rerere comes in handy).
If by "commit all my local changes at once" you mean you want to fold all of your commits into a single commit in git (and later SVN) then you can use git rebase -i to "squash" all of your commits into a single commit. You should not include any revisions that have already been sent to SVN with dcommit in that rebase -i because you are rewriting history. You will still have to resolve conflicts when you git-svn rebase just like you would if you were using only SVN and did svn update.
Is it possible to check-out a Bzr repo via Svn externals using an Svn client?
If Bzr is being served over Web-DAV (it is in my case) it seems like it should be possible, unless Svn needs all the ".svn" folders.
You can use the bzr-svn plugin to push the bzr branch into you svn repository, then you can use that as an external.
No. Cause Bzr is working different than subversion and the SVN client does not know how to handle a bzr repository.
I have a number of locally committed patches in my git-svn repo which I haven't yet commited to our svn repo. A normal "git svn dcommit" will commit all of these patches to svn. I would like to commit only some of my patches (simple bug fixes), but not others (untested major changes). How can I do this with git svn?
I've been following the procedure here:
http://fredericiana.com/2009/12/31/partial-svn-dcommit-with-git/
If you're comfortable rebasing, it works pretty well.
Here's what I ended up doing. The starting point is the "master" branch synced with svn, with all of my local patches on top.
Create a new branch (wip = Work In Progress).
git branch wip
This makes a copy of the current branch, including all patches not yet committed to svn. The current branch will stay as "master" and will not be changed.
Remove the unwanted local patches from "master" with a rebase:
git rebase -i HEAD~10
Now the "master" branch has patches you can safely commit:
git svn dcommit
The "wip" branch now has the major changes which aren't yet ready for sharing. Actually, I want them to stay there and this is where I would stop. It's possible to do the svn dcommit from the "wip" branch once everything is finalized. But for completess' sake, and to answer the original question, there's a final step:
Pull the uncommitted changes back to the "master" branch using git cherry-pick and finally remove the useless branch with git branch -d wip.
With git, you're not actually supposed to operate on single changesets. The best approach I know is to create local branches for any non-trivial work. This way, your untested major changes will end up in different branches of your git repository, and you'll be able to differ them quite easily.
If this is the problem you have at the moment you can probably create create a new branch from the point you last updated from svn and then use git-cherry-pick to transfer your simple bug fixes to this new branch, from which you can then dcommit to svn.
From a more long-term point of view it's best to have your own "master" branch made from subversion trunk, and then either:
Rebase all your branches every time you update from svn, then merge those you want to get to svn to your master and dcommit from there.
Merge stuff from svn using regular git-merge, and then merge stuff to your master for dcommits by git diff ..my_branch | patch -p1, which will eliminate history that git-svn can't handle. This approach is more complicated for the final merging but allows you to merge stuff between branches (and possibly other people) in git itself.