Using git-svn (historical) - Revision history

TomYu at 23:24, 16 July 2012

2012-07-16T23:24:23Z

Ghudson at 21:00, 27 May 2012

2012-05-27T21:00:48Z

TomYu: Using git-svn moved to Using git-svn (historical)

2012-05-23T20:33:47Z

Using git-svn moved to Using git-svn (historical)

TomYu at 02:07, 13 May 2012

2012-05-13T02:07:04Z

Ghudson: /* Suggested workflow */

2011-06-03T10:36:20Z

‎Suggested workflow

Ghudson at 10:29, 3 June 2011

2011-06-03T10:29:37Z

TomYu: many updates based on some experiments

2011-05-18T18:44:05Z

many updates based on some experiments

TomYu: /* For committers */ describe GitHub cloning first

2011-05-17T21:41:20Z

‎For committers: describe GitHub cloning first

TomYu: starting by cloning from GitHub

2011-05-17T18:12:37Z

starting by cloning from GitHub

TomYu: /* Merge ticket incompatibility */ fix before/after 1.6.6 info

2011-05-17T16:26:06Z

‎Merge ticket incompatibility: fix before/after 1.6.6 info

← Older revision		Revision as of 23:24, 16 July 2012
Line 1:		Line 1:
−	~~This~~ information is ~~primarily~~ for historical ~~purposes~~. Developers who are researching portions of the source code history that the Git migration omitted may find this information useful.	+	See the [[Getting source code]] page for information about accessing the current source repository. The following information is for historical reference. Developers who are researching portions of the source code history that the Git migration omitted may find this information useful.

	== Creating a git-svn repository ==		== Creating a git-svn repository ==

← Older revision		Revision as of 21:00, 27 May 2012
Line 57:		Line 57:

	The <code>git filter-branch</code> command is very powerful and easy to misuse. Reasons why you might want to use it include modifying your existing git-svn repository to match the commit history of our public git-svn repository. You will probably prefer to recreate your patches on top of a fresh clone from our git-svn repository, unless you have a particularly complicated local revision history you want to preserve. Instructions on how to use <code>git filter-branch</code> for this and related operations may appear here later if there is enough demand.		The <code>git filter-branch</code> command is very powerful and easy to misuse. Reasons why you might want to use it include modifying your existing git-svn repository to match the commit history of our public git-svn repository. You will probably prefer to recreate your patches on top of a fresh clone from our git-svn repository, unless you have a particularly complicated local revision history you want to preserve. Instructions on how to use <code>git filter-branch</code> for this and related operations may appear here later if there is enough demand.
−
−	== Suggested workflow ==
−
−	Keep the trunk branch free of local commits. Make each change on a separate branch off of the trunk (<code>git checkout -b branchname</code>). When you have committed your work (with <code>git add</code> and <code>git commit</code>) and are ready to push changes to Subversion, first update your trunk branch and rebase with any local commits:
−
−	<pre>
−	git checkout trunk
−	git pull
−	git checkout branchname
−	git rebase trunk
−	</pre>
−
−	Then (ideally after re-testing your changes) run <code>git svn dcommit</code> to push your changes to Subversion from your branch. After a few minutes, these will propagate from Subversion to GitHub, and you can update your trunk branch to reflect them.

← Older revision		Revision as of 02:07, 13 May 2012
Line 1:		Line 1:
−	This guide is still incomplete.
		+	This information is primarily for historical purposes. Developers who are researching portions of the source code history that the Git migration omitted may find this information useful.

	== Creating a git-svn repository ==		== Creating a git-svn repository ==

← Older revision		Revision as of 10:36, 3 June 2011
Line 69:		Line 69:
	</pre>		</pre>

−	Then (ideally after re-testing your changes) run <code>git svn dcommit</code> to push your changes. After a few minutes, these will propagate from Subversion to GitHub, and you can update your trunk branch to reflect them.	+	Then (ideally after re-testing your changes) run <code>git svn dcommit</code> to push your changes to Subversion from your branch. After a few minutes, these will propagate from Subversion to GitHub, and you can update your trunk branch to reflect them.

← Older revision		Revision as of 10:29, 3 June 2011
Line 57:		Line 57:

	The <code>git filter-branch</code> command is very powerful and easy to misuse. Reasons why you might want to use it include modifying your existing git-svn repository to match the commit history of our public git-svn repository. You will probably prefer to recreate your patches on top of a fresh clone from our git-svn repository, unless you have a particularly complicated local revision history you want to preserve. Instructions on how to use <code>git filter-branch</code> for this and related operations may appear here later if there is enough demand.		The <code>git filter-branch</code> command is very powerful and easy to misuse. Reasons why you might want to use it include modifying your existing git-svn repository to match the commit history of our public git-svn repository. You will probably prefer to recreate your patches on top of a fresh clone from our git-svn repository, unless you have a particularly complicated local revision history you want to preserve. Instructions on how to use <code>git filter-branch</code> for this and related operations may appear here later if there is enough demand.
		+
		+	== Suggested workflow ==
		+
		+	Keep the trunk branch free of local commits. Make each change on a separate branch off of the trunk (<code>git checkout -b branchname</code>). When you have committed your work (with <code>git add</code> and <code>git commit</code>) and are ready to push changes to Subversion, first update your trunk branch and rebase with any local commits:
		+
		+	<pre>
		+	git checkout trunk
		+	git pull
		+	git checkout branchname
		+	git rebase trunk
		+	</pre>
		+
		+	Then (ideally after re-testing your changes) run <code>git svn dcommit</code> to push your changes. After a few minutes, these will propagate from Subversion to GitHub, and you can update your trunk branch to reflect them.

← Older revision	Revision as of 20:33, 23 May 2012
(No difference)

@@ Line 1: / Line 1: @@
 This guide is still incomplete.
 If you have commit access to the master SVN repository, you may wish to configure a git-svn repository that allows you to review and commit pull requests from contributors who do not have commit access. To make it easier for non-committers to interact with both Git and SVN, use the <code>svn://anonsvn.mit.edu/krb5</code> URL as the SVN root that git-svn writes into the commit objects.
 <pre>
@@ Line 18: / Line 22: @@
 </pre>
-The <code>git update-ref</code> commands are to delete some spurious branches that are caused by the existence of a SVN branch named "HEAD" (don't ask) in our SVN repository.
+Be aware that the <code>git svn fetch</code> command (which builds your local copy of the git-svn metadata) could take about two hours to run. The <code>git update-ref</code> commands are to delete some spurious branches that are caused by the existence of a SVN branch named "HEAD" (don't ask) in our SVN repository.
 The git-svn repository created using the above commands may be updated using either <code>git svn fetch</code> (updates from the master SVN repository) or <code>git fetch</code> (updates from GitHub).
@@ Line 28: / Line 32: @@
 </pre>
 <pre>
@@ Line 36: / Line 42: @@
 This has the advantage of fetching the commits from SVN using a secure transport.

@@ Line 5: / Line 5: @@
 If you have commit access to the master SVN repository, you may wish to configure a git-svn repository that allows you to review and commit pull requests from contributors who do not have commit access. To make it easier for non-committers to interact with both Git and SVN, use the <code>svn://anonsvn.mit.edu/krb5</code> URL as the SVN root that git-svn writes into the commit objects.
 <pre>
-cd krb5-gitsvn
+cd krb5-github
-git svn init -s --rewrite-root=svn://anonsvn.mit.edu/krb5 svn+ssh://svn.mit.edu/krb5
+git svn init -s --rewrite-root=svn://anonsvn.mit.edu/krb5 --prefix=origin/ svn+ssh://svn.mit.edu/krb5
 git svn fetch
 </pre>
 <pre>
 </pre>
 === Merge ticket incompatibility ===

← Older revision		Revision as of 18:12, 17 May 2011
Line 17:		Line 17:

	Fetching all those revisions from <code>svn.mit.edu</code> might take a really long time (many hours), so alternatives that begin with cloning the existing git-svn mirror might be preferable. If you have an existing git-svn repository whose SVN root is the master SVN repository, you could use <code>git filter-branch</code> to rewrite the URLs, or start over by cloning the published git-svn mirror.		Fetching all those revisions from <code>svn.mit.edu</code> might take a really long time (many hours), so alternatives that begin with cloning the existing git-svn mirror might be preferable. If you have an existing git-svn repository whose SVN root is the master SVN repository, you could use <code>git filter-branch</code> to rewrite the URLs, or start over by cloning the published git-svn mirror.
		+
		+	To start from the GitHub repository and end up with a git-svn repository that you can use to commit to the master SVN repository: [XXXX needs testing]
		+
		+	<pre>
		+	git clone git://github.com/krb5/krb5-anonsvn krb5-github
		+	cd krb5-github
		+	git svn init -s --rewrite-root=svn://anonsvn.mit.edu/krb5 --prefix=origin/ svn+ssh://svn.mit.edu/krb5
		+	git svn fetch
		+	</pre>

	=== Merge ticket incompatibility ===		=== Merge ticket incompatibility ===

← Older revision		Revision as of 16:26, 17 May 2011
Line 22:		Line 22:
	The git-svn mirror of our master SVN repository has some quirks.		The git-svn mirror of our master SVN repository has some quirks.

−	Since release 1.6.6 of Git, <code>git-svn</code> can read merge tickets generated by SVK and SVN, and uses these merge tickets to create merge commits in Git. Some developers created git-svn repositories prior to this change in the behavior of git-svn, and these repositories have incompatible commit histories for otherwise identical tree histories. The commits that are most problematic in this way are XXXXX. The git-svn mirror that we host on <code>krbdev.mit.edu</code> and GitHub does not contain any merges that would be created by Git releases ~~prior to~~ 1.6.6. If you have an existing git-svn repository that you would like to make compatible with the published git-svn mirror, you will probably need to use <code>git filter-branch</code> with some graft points that delete the extra parent commits of the merge commits. You will need to rerun <code>git svn fetch</code> afterward (which should operate locally without contacting the SVN repository if nothing has changed in SVN) to rebuild the git-svn metadata. [XXXX more details later]	+	Since release 1.6.6 of Git, <code>git-svn</code> can read merge tickets generated by SVK and SVN, and uses these merge tickets to create merge commits in Git. Some developers created git-svn repositories prior to this change in the behavior of git-svn, and these repositories have incompatible commit histories for otherwise identical tree histories. The commits that are most problematic in this way are XXXXX. The git-svn mirror that we host on <code>krbdev.mit.edu</code> and GitHub does not contain any merges that would be created by Git releases after 1.6.6. If you have an existing git-svn repository that you would like to make compatible with the published git-svn mirror, you will probably need to use <code>git filter-branch</code> with some graft points that delete the extra parent commits of the merge commits. You will need to rerun <code>git svn fetch</code> afterward (which should operate locally without contacting the SVN repository if nothing has changed in SVN) to rebuild the git-svn metadata. [XXXX more details later]