Hello,
When using git-svn to access a SVN repo, the commit policy may vary.
While git makes you commit small patches often, svn users tend to prefer
bigger patches that implement a functionnality at once.
So at the end you have a SVN commit which corresponds to several git ones.
What you can do in this case is :
git-svn commit-diff --edit -r$REV remotes/git-svn HEAD
Which effect is that it commits (at once) all the commits between the
latest svn fetch and HEAD.
What I'm proposing here is this:
- use the latest fetched rev the default for the -r argument.
- use remotes/git-svn and HEAD the defaults for the treeish objects.
A smarter way to take these defaults would be to take the last revision
in the current branch (which can be something else than git-svn if it
wasn't rebased/merged recently) and the relevant commit in the current
branch.
Additionnaly, --edit could be enabled by default if -m is not set and it
is used interactively, eventually using an option in repo-config.
Any comment ?
On Tue, Jan 02, 2007 at 07:23:26PM +0100, Steve Frécinaux wrote:
Hello,
When using git-svn to access a SVN repo, the commit policy may vary.
While git makes you commit small patches often, svn users tend to prefer
bigger patches that implement a functionnality at once.
So at the end you have a SVN commit which corresponds to several git
ones.
What you can do in this case is :
git-svn commit-diff --edit -r$REV remotes/git-svn HEAD
Which effect is that it commits (at once) all the commits between the
latest svn fetch and HEAD.
What I'm proposing here is this:
- use the latest fetched rev the default for the -r argument.
- use remotes/git-svn and HEAD the defaults for the treeish objects.
A smarter way to take these defaults would be to take the last revision
in the current branch (which can be something else than git-svn if it
wasn't rebased/merged recently) and the relevant commit in the current
branch.
Additionnaly, --edit could be enabled by default if -m is not set and it
is used interactively, eventually using an option in repo-config.
Any comment ?
of course a git svn subcommand that in fact allow you to cherry pick
patches from `git rev-list remotes/git-svn` would be *really* good, but
here is what I do:
1. be up2date:
$ git svn fetch
$ git rebase remotes/git-svn
2. create a local branch to cherry pick the hunk you want to combine:
$ git branch -f svn-tmp remotes/git-svn
# cherry pick the commits you want using any method you like, eg:
$ git cherry-pick <....>
or
$ git am [some previously built mailbox of changes]
I happen to prefer the later since I do git format-patch
remotes/git-svn from my master branch, and use my MUA as a
poor-man's interactive way to select patches I want. Though
sometimes you miss some dependant patches, and I suppose git
cherry-pick would be better at that game, YMMV.
3. git svn commit HEAD (not dcommit) to force merging of all your
local patches in one svn changeset.
note that you may need a step (1) update if anything changed since,
if you don't want to see git-svn undo the commits other user may
have done since your last (1) update, commit your change, and
commit the previously undone commits back. I did that once when I
was a beginner with git-svn, and it generated a huge pile of
globally indempotend commits, and flooded the commit mail list,
that was kind of funny ;)
4. go back to your branch as usual, and resync to the new svn state:
git checkout master
git svn fetch
git rebase remotes/git-svn # should merge things happily
you can then go back to (2) and iterate until your
`git rev-list remotes/git-svn` is empty.
This is highly unpretty, and relies in the fact that nobody commited
into the svn between your set 2 and 3. I suppose you can achieve the
same by creating combined changeset from git, instead of a cherry
picking, in some kind of "combining" branch, and then just use
`git svn dcommit` from there, but I've found no convenient (I mean no
way *I* find convenient) way to do that. Maybe someone here has a better
idea :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Steve Fr?cinaux [off-list ref] wrote:
Hello,
When using git-svn to access a SVN repo, the commit policy may vary.
While git makes you commit small patches often, svn users tend to prefer
bigger patches that implement a functionnality at once.
So at the end you have a SVN commit which corresponds to several git ones.
What you can do in this case is :
git-svn commit-diff --edit -r$REV remotes/git-svn HEAD
Which effect is that it commits (at once) all the commits between the
latest svn fetch and HEAD.
What I'm proposing here is this:
- use the latest fetched rev the default for the -r argument.
Yes, this is very important.
- use remotes/git-svn and HEAD the defaults for the treeish objects.
A smarter way to take these defaults would be to take the last revision
in the current branch (which can be something else than git-svn if it
wasn't rebased/merged recently) and the relevant commit in the current
branch.
Additionnaly, --edit could be enabled by default if -m is not set and it
is used interactively, eventually using an option in repo-config.
This sounds useful. This is basically what 'set-tree' (the command
formerly known as 'commit') was meant to do originally. Unlike
set-tree (or perhaps with modifying set-tree), this should
rebase or reset afterwards to linearize history like 'dcommit'.
--
Eric Wong