Hi,
I am converting my team's SVN server to GIT but they aren't ready to
transition yet. People are still working out of SVN, so I need to keep
the git-svn clone around to do 'git svn fetch' to continue to keep it
synchronized with SVN.
Once everyone is ready to switch, and after converting all of the
tag-branches to real GIT tags, I plan to push all branches & tags to
the new central git repository.
However, before pushing to the central GIT repo, I want to remove some
giant directories from the repository history. Specifically some third
party library directories. I have found a way to do this here:
http://stackoverflow.com/questions/10067848/remove-folder-and-its-contents-from-git-githubs-history
Is it safe to do this while still using git svn fetch? Will it
properly continue to convert SVN commits on top of my rewritten
history? If not, what changes can I make after I run the commands
linked by the URL above so that git svn continues to work normally?
Note that I plan to delete the third party libraries from SVN side and
then pull down the changes to git through git-svn, then at that point
clean it up (hopefully the git filter-branch command ignores the
commit that deleted the files and only hunts down the commits where
they were added or modified).
Any guidance on this would be much appreciated.
On Mon, Mar 3, 2014 at 7:38 PM, Robert Dailey [off-list ref] wrote:
Is it safe to do this while still using git svn fetch? Will it
properly continue to convert SVN commits on top of my rewritten
history? If not, what changes can I make after I run the commands
linked by the URL above so that git svn continues to work normally?
I think it's OK. git-svn doesn't continuously verify the integrity of
history already converted, I believe.
Just try it out, it worked fine in a little demo setup I made
(although I used rebase -i instead of filter-branch):
git svn clone .. #maybe clone a little test repository to speed up the testing
git filter-branch ... #remove unwanted files
git svn fetch #this should work
On a related note, maybe you'll enjoy my git-svn demos & ideas here:
http://www.tfnico.com/presentations/git-and-subversion
On Tue, Mar 4, 2014 at 4:56 AM, Thomas Ferris Nicolaisen
[off-list ref] wrote:
On Mon, Mar 3, 2014 at 7:38 PM, Robert Dailey [off-list ref] wrote:
quoted
Is it safe to do this while still using git svn fetch? Will it
properly continue to convert SVN commits on top of my rewritten
history? If not, what changes can I make after I run the commands
linked by the URL above so that git svn continues to work normally?
I think it's OK. git-svn doesn't continuously verify the integrity of
history already converted, I believe.
Just try it out, it worked fine in a little demo setup I made
(although I used rebase -i instead of filter-branch):
git svn clone .. #maybe clone a little test repository to speed up the testing
git filter-branch ... #remove unwanted files
git svn fetch #this should work
On a related note, maybe you'll enjoy my git-svn demos & ideas here:
http://www.tfnico.com/presentations/git-and-subversion
So I did try this out. I did a 'fitler-branch', and afterwards I am
unable to do a `git svn fetch`:
$ git svn fetch
fatal: Invalid revision range cf641cf687fc41b769f296af6e4345dd6a8a6d7d
rev-list --pretty=raw --reverse
cf641cf687fc41b769f296af6e4345dd6a8a6d7d..refs/remotes/svn/trunk --:
command returned error: 128
I have a TON of branches, so I need some small command or script that
is able to go through each branch and update the metadata to tell it
what the new (rewritten) HEAD commit on each branch is. I'm assuming
that's the problem (git svn data is referring to old SHA of each
remote tracking branch).
If there is more to it than this please let me know. Thanks so far for
everyone's help.