git-svn dcommit Question

My git-svn fu is not very strong.

In the course of preparing a set of AVX patches, I've committed several
changes to my local LLVM git clone. I don't want to send all of those
changes upstream right away. What's the best way to send just the first
of those changes us using git-svn? dcommit appears to send all pending
changes. Is there a way of branching/cherry-picking that will
accomplish what I want?

Thanks!

                             -Dave

My git-svn fu is not very strong.

In the course of preparing a set of AVX patches, I've committed several
changes to my local LLVM git clone. I don't want to send all of those
changes upstream right away. What's the best way to send just the first
of those changes us using git-svn? dcommit appears to send all pending
changes. Is there a way of branching/cherry-picking that will
accomplish what I want?

Create a cmt branch from master and add just the patches you want to commit to it.

Thanks!

Cheers,
Rafael

Rafael Ávila de Espíndola <rafael.espindola@gmail.com> writes:

Rafael Ávila de Espíndola<rafael.espindola@gmail.com> writes:

My git-svn fu is not very strong.

In the course of preparing a set of AVX patches, I've committed several
changes to my local LLVM git clone. I don't want to send all of those
changes upstream right away. What's the best way to send just the first
of those changes us using git-svn? dcommit appears to send all pending
changes. Is there a way of branching/cherry-picking that will
accomplish what I want?

Create a cmt branch from master and add just the patches you want to
commit to it.

Ok, that's what I thought I should do. I just needed to confirm that.

So git-svn dcommit only commits things on the current branch. Cool, I
think I can make this work.

Will git-cherrypick work or is the merging process going to confuse
git-svn?

To use git-svn you should always have a history without any git merges. Just commit after commit after commit. I do not know what kind of history git-cherrypick produces.

I would do the cherrypicking like this:

git checkout -b toCommit
git rebase -i HEAD~30

> Remove all the unneeded commits in the upcoming window

git svn -n dcommit // Check what would be committed
git svn dcommit // Commit

Cheers
Tobi

Tobias Grosser <tobias@grosser.es> writes:

Will git-cherrypick work or is the merging process going to confuse
git-svn?

To use git-svn you should always have a history without any git
merges. Just commit after commit after commit. I do not know what kind
of history git-cherrypick produces.

To clarify, I just need to create the branch at the point just before
the first commit to go to upstream. Are merges in the history before
that point going to be a problem?

I would do the cherrypicking like this:

git checkout -b toCommit
git rebase -i HEAD~30

Ok, I'll try something like that.

Remove all the unneeded commits in the upcoming window

git svn -n dcommit // Check what would be committed
git svn dcommit // Commit

Ok, thanks. git-svn is a bit awkward, so thanks everyone for your help!

                           -Dave

Tobias Grosser<tobias@grosser.es> writes:

Will git-cherrypick work or is the merging process going to confuse
git-svn?

To use git-svn you should always have a history without any git
merges. Just commit after commit after commit. I do not know what kind
of history git-cherrypick produces.

To clarify, I just need to create the branch at the point just before
the first commit to go to upstream.

You need to create a branch that has all commits already in svn + a linear chain of new commits.

s1 -- s2 -- s3 -- n4 -- n5 -- n6

s* being the existing commits already in svn
n* being the new commits that you want to dcommit

> Are merges in the history before

that point going to be a problem?

From the git-svn man page (without any context):

"Do NOT use git merge or your history will not be compatible with a future dcommit!"

As these warnings exist, I never tried to commit anything that has a non-linear history.

To your question. How would you have a merge in the history, that is before the commits you want to dcommit? This part of the history should already be in svn, as you dcommit your new commits always on the current status of svn. As the history of the s* commits is basically a mirror of the svn repo and svn only allows linear history, I do not see at all how a merge should exist in between the s* commits.

In general I would just try. As long as you check with 'git svn -n dcommit' before the actual dcommit, you should be good.

git svn -n dcommit // Check what would be committed
git svn dcommit // Commit

Ok, thanks. git-svn is a bit awkward, so thanks everyone for your help!

You are welcome.

Tobi

Dave, bty, don't you work on your branches, but master?
I think it would be not "the right git way".

...Takumi

ps. for me, to commit much commits;

$ git checkout master
$ git rebase -i mybranch
(pick up commits interactive on master as cherry)
$ make -C builddir check-all -j4
$ git svn dcommit -n

NAKAMURA Takumi <geek4civic@gmail.com> writes:

Dave, bty, don't you work on your branches, but master?
I think it would be not "the right git way".

...Takumi

ps. for me, to commit much commits;

$ git checkout master
$ git rebase -i mybranch
(pick up commits interactive on master as cherry)
$ make -C builddir check-all -j4
$ git svn dcommit -n

I work on branches. That was the main question I had: how to handle
merges, etc. between branches.

I finally hit upon a sequence that works for me. I use git-subtree to
keep a repository of the LLVM/Clang world around. To commit to LLVM:

(previously I had done git remote add llvm-upstream
https://greened@llvm.org/git/llvm.git)

git subtree split -P llvm -b upstream
git checkout upstream
git svn init https://greened@llvm.org/svn/llvm-project/llvm/trunk
git config svn-remote.svn.fetch ‘:refs/remotes/llvm-upstream/master’
git config svn-remote.svn.url ‘https://greened@llvm.org/svn/llvm-project/llvm/trunk
git svn fetch
git svn rebase -l
git svn dcommit -dry-run -n

Spits out a bunch of things like:

diff-tree 6ac658fc756cd78d75c58b77e2994830ce50300f~1 6ac658fc756cd78d75c58b77e2994830ce50300f
diff-tree 0f2bb78415654038ad914f3e937c372505320b04~1 0f2bb78415654038ad914f3e937c372505320b04
diff-tree b59e257caa9311048915b0a93c417987177a47f4~1 b59e257caa9311048915b0a93c417987177a47f4
diff-tree e71fe076e5e6cac03dab04bf961961633f3b0f2a~1 e71fe076e5e6cac03dab04bf961961633f3b0f2a
diff-tree 3dd36498cc2d0d12b58664b13b3bfb6b4a42b5d1~1 3dd36498cc2d0d12b58664b13b3bfb6b4a42b5d1
diff-tree 04bf58415302e738394db762408ba5de208c520a~1 04bf58415302e738394db762408ba5de208c520a

Then it's a matter of doing "git diff" on the above to find the next
commit I want to send. I run "git log" to find the commit just before
all of the above commits (that get rebased). After that:

git checkout c7a3e2945bf15c99d8267cb2c4434021355fe008
git checkout -b commit # Split off a branch starting just before the
                        # rebased commits.
git cherry-pick 0f2bb78415654038ad914f3e937c372505320b04 # Next commit
                                                          # to send
git svn dcommit --dry-run -n

Gives one output:

diff-tree 5a6ab4ff0e0be9ba0737984c670ee71d0cccc5d1~1 5a6ab4ff0e0be9ba0737984c670ee71d0cccc5d1 > init.diff

A quick "git diff" and "git log" confirms this is the one I want. Then
I do:

git svn dcommit

Or, at least I will after the patch gets some review. :slight_smile:

So it's a little more involved but seems to let me be a little more
flexible with how I use git. Maybe I'll write something up for the web
documentation. Do we have a git usage section somewhere?

Thanks for your help!
                              -Dave

Tobias Grosser <tobias@grosser.es> writes:

From the git-svn man page (without any context):

"Do NOT use git merge or your history will not be compatible with a
future dcommit!"

As these warnings exist, I never tried to commit anything that has a
non-linear history.

Well, I've been merging my brains out. What I did was create a branch
specifically to do dcommits from and then svn rebased in there. The
merges showed up in the linear history but it was easy enough to create
_another_ branch and then just cherry-pick the commits I actually want
to send. It's a little more involved but allows one to use the full
power of git.

In general I would just try. As long as you check with 'git svn -n
dcommit' before the actual dcommit, you should be good.

Yep.

                               -Dave