search for: dcommit

...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

...e 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 n...

...>> 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 confi...

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

...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...

..., 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

...ry 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

Folks, I'm now using the git mirror, but I'm not sure how to commit changes via git, if at all possible. So far, I'm diffing & applying it on an RW svn tree and committing, but that makes me test twice and it's error prone. I read the manual regarding git-svn setup and all it has is the connection to svn to keep svn's linearity, but nothing on commit strategy. With git,

...M, this won't > work. Is there a FAQ/doc/manual on how to do that or what are the best > practices when working with git? Basically, once you are set up with git-svn (see <http://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-git-svn>), all you have to do is `git svn dcommit`. My workflow when it comes time to commit is basically: 1. checkout master and pull from origin. 2. rebase stuff to be committed onto master. 3. `git svn dcommit --dry-run` to see what is going to be committed. 4. `git svn dcommit --interactive` to doublecheck that the right stuff is being commi...

...rified that branched development and rebasing to tip, r-w- > works on the mercurial-svn bridge (i.e. you can commit directly to svn > via hg and gain all of the benefits of using a dvcs) git-svn allows commits to svn directly from git. But you need to make sure the history in the branch you dcommit from is "linear." As you say, a rebase is always necessary while with "normal" git it is optional. The practical consequence of this is that the developer has to keep some sort of special "upstream" branch that only takes merges from other git branches and always doe...

...g a "From: <email>" field to commit messages instead of "Patch by <name>". If the original author is already in the git commit, you can generate the "From: <email>" field in the SVN commit message with: git svn --add-author-from --use-log-author dcommit >From the git-svn docs: --use-log-author When retrieving svn commits into Git (as part of fetch, rebase, or dcommit operations), look for the first From: or Signed-off-by: line in the log message and use that as the author string. --add-author-from When committing to svn from Git (as part...

...there is a mirroring for LLVM itself and clang. More can be added per requests. The mirrors are made via running of git-svn on llvm.org inside post-commit hook, so they should be in theory as fresh as possible. Also, one can recreate git-svn metadata and enable such nice features like "git svn dcommit". The mirrors track only trunk mostly due to not so git'ish way of doing branches / tags in LLVM repository. The URLs for clone are: http://llvm.org/git/llvm.git http://llvm.org/git/clang.git It's not yet decided whether we'll run e.g. gitweb for mirrors, most probably - there w...

...opped working for me. This happened roughly around the time when Anton added the other branches, but I'm not sure if that was the cause or not. The symptom is that the "git svn rebase -l" command does nothing except say that the master branch is already up to date, and "git svn dcommit" complains that files are out of date. In both cases, "git svn rebase" (without "-l") solves the problem, but without using the GIT mirror, so it's slow. I've tried re-creating my git repos from scratch but that did not fix the problem. Any ideas? On Feb 1, 2011...

...s/git-svn' $ git fetch $ git svn init https://llvm.org/svn/llvm-project/llvm/trunk $ git svn rebase -l This will quickly build the git-svn metadata by using the magical remotes/git-svn branch fetched from the origin. To update I run: $ git fetch $ git svn rebase -l And to commit: $ git svn dcommit $ git fetch $ git svn rebase -l I have sometimes seen git-svn refusing to dcommit, claiming that I have uncommitted files in my tree. I think this happens when I forget to resynchronize the metadata after committing. Anyway, the solution is to wipe away all of .git/svn and rebuild it with "gi...

On 1 January 2013 00:52, Sean Silva <silvas at purdue.edu> wrote: > Basically, once you are set up with git-svn (see > <http://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-git-svn>), > all you have to do is `git svn dcommit`. Oh, the docs do mention "dcommit" en passant, but nothing explicit. > 1. checkout master and pull from origin. > 2. rebase stuff to be committed onto master. Can you commit directly from branches? Or do you have to merge to master to commit? > 3. `git svn dcommit --dry-ru...

...manage my patches with "git rebase -i", which allows me to edit, > combine, reorder, discard my local commits relatively easily. See for > example: But none of this explains how to prevent false conflicts when updating your git workarea from the svn git mirror. The problem is that dcommit changes the hash from what's in your local repository to something different. When you then update from the git mirror, you get a conflict because two commits with different hashes have the same file contents. -Dave

On Wed, Jul 27, 2011 at 8:59 PM, Mark Lacey <641 at rudkx.com> wrote: > >> Besides, the git-svn readonly bridge is a great solution for those who >> want to use git >> > > It seems to be a reasonable solution for those individuals who want to use > git, but in my experience not for organizations that want to use git, e.g. > have a local server with local

...s to change it. Personally I think our current system is a very nice middle ground. We get nice sequential revision numbers from svn, and behind the scenes everyone can go crazy with git. It's a little awkward to set up a new repo that pulls from the git mirrors and also lets you use git-svn dcommit to push back, but that's a minor nuisance AFAICT.

...ove are all setup to live with git-svn. 5. Enjoy your life with git-pull and git-fetch. (please not forget to track origin/master) When you have commits, .... 6. git-checkout and git-pull --rebase on master. 7. cherry-pick your commits to master. 8. (Optional) Confirm with dry-run; git svn dcommit -n 9. Are you ready? "git svn dcommit"! Thanks to git guys, esp. Tobi! ...Takumi ps. I am planning to describe docs/Git.html, but I am not familiar to English!!! 誰か翻訳, 査読などお願いします。マジで!

> > > Besides, the git-svn readonly bridge is a great solution for those who want > to use git > It seems to be a reasonable solution for those individuals who want to use git, but in my experience not for organizations that want to use git, e.g. have a local server with local branches, with many people banging on that while at the same time continuously merging the LLVM mainline