Search Results

Search found 24 results on 1 pages for 'dcommit'.

Page 1/1 | 1 

  • git: correct way to merge/rebase with respect to svn dcommit

    - by Albert
    I have the following situation (mostly because I didn't really thought it through in the beginning -- or more exactly, I thought it shouldn't be a problem the way I did this but now I am stumbled): ... --- A --- B1 --- ... --- Bn ... --- git-svn Whereby A and git-svn are at the same state (exactly the same files and file content) but they don't have any common point in history. And I want: ... --- git-svn --- B1 --- ... --- Bn Or at least, when I do the svn dcommit, I want exactly to get the commits B1 to Bn and nothing else. I am not exactly sure how dcommit works. So if I would get something like this: ... ------------ A --- B1 --- ... --- Bn \ \ ... --- git-svn -- A' ----------------- B' would the dcommit behave in the way I want? Because if so, that would be easy to get (merging A into git-svn does work just fine because they are content-wise the same). Or should I do some sort of rebase? But I don't want to rebase A on git-svn, just B1 to Bn.

    Read the article

  • dcommit to SVN in 1 commit after cherry-picking in git

    - by DJ
    I would like to know if there is a clean way to do git-svn dcommit of multiple local commits as 1 commit into subversion. The situation that I have is I am cherry picking some bug fixes changes from our trunk into the maintenance branch. The project preference is to have the bug fixes to be committed as 1 commit in subversion, but I would like to keep the history of changes that I had cherry-picked on my local git for references. Currently what I do is to do all cherry-picking on branch X and then do a squash merge into new branch Y. The dcommit will then be done from branch Y. Is there a better way to do it without using an intermediary branch?

    Read the article

  • Git Svn dcommit error - restart the commit

    - by Rob Wilkerson
    Last week, I made a number of changes to my local branch before leaving town for the weekend. This morning I wanted to dcommit all of those changes to the company's Svn repository, but I get a merge conflict in one file: Merge conflict during commit: Your file or directory 'build.properties.sample' is probably out-of-date: The version resource does not correspond to the resource within the transaction. Either the requested version resource is out of date (needs to be updated), or the requested version resource is newer than the transaction root (restart the commit). I'm not sure exactly why I'm getting this, but before attempting to dcommit, I did a git svn rebase. That "overwrote" my commits. To recover from that, I did a git reset --hard HEAD@{1}. Now my working copy seems to be where I expect it to be, but I have no idea how to get past the merge conflict; there's not actually any conflict to resolve that I can find. Any thoughts would be appreciated. EDIT: Just wanted to specify that I am working locally. I have a local branch for the trunk that references svn/trunk (the remote branch). All of my work was done on the local trunk: $ git branch maint-1.0.x master * trunk $ git branch -r svn/maintenance/my-project-1.0.0 svn/trunk Similarly, git log currently shows 10 commits on my local trunk since the last commit with a Svn ID. Hopefully that answers a few questions. Thanks again.

    Read the article

  • Git-svn branch hoses dcommit when using an odd branch structure

    - by Chuck Vose
    I had a boss, past-tense, who decided to put svn branches in the same folder as trunk. Normally, this wouldn't affect me that much but since I'm using git-svn things are going so well. After I did a fetch it created a folder for each branch in my root folder so I have three folders, drupal, trunk, and client. The drupal folder is git's master branch, client and trunk are the svn branches. Merging and committing works great, in fact everything git related is working superb. However dcommit is totally hosed, it's trying to commit a folder called client and one called trunk. I can't even imagine what havoc this would cause for svn later on. So my question is, what have I done wrong in my .git/config and is there anything I can do to fix this or am I going to have to suffer and go back to using svn? Please don't make me go back. I don't think I can take it anymore. Bastard boss knows how to leave a legacy. [svn-remote "svn"] url = https://svn.mydomain.com/svn/project_name fetch = trunk:refs/remotes/trunk branches = *:refs/remotes/* tags = tags/*:refs/remotes/tags/* Normally the branches line would look like this (when using --stdlayout): branches = branches/*:refs/remotes/branches/* ls output is thus: $ ls client/ docs/ drupal/ sql/ trunk/

    Read the article

  • Is git svn rebase required before git svn dcommit?

    - by allyourcode
    I'm reading about using git as an svn client here: http://learn.github.com/p/git-svn.html That page suggests that you do git svn rebase before git svn dcommit, which makes perfect sense; it's like doing svn update before doing svn commit. Then, I started looking at the documentation for git svn dcommit (I was wondering what the 'd' is about): http://www.kernel.org/pub/software/scm/git/docs/git-svn.html You have to scroll down a bit to see the documentation on dcommit, which says this: Commit each diff from a specified head directly to the SVN repository, and then rebase or reset (depending on whether or not there is a diff between SVN and head). This confuses me, because if you do as the first page says, there will be no changes to pull down from svn once the first part of dcommit finishes. I'm also confused by the part that talks about reset; isn't git reset for removing changes from the staging area? Why would rebase or reset follow (the first part of) a dcommit?

    Read the article

  • Can I recover lost commits in a SVN repository using a local tracking git-svn branch?

    - by Ian Stevens
    A SVN repo I use git-svn to track was recently corrupted and a backup was recovered. However, a week's worth of commits were lost in the recovery. Is it possible to recover those lost commits using git-svn dcommit on my local git repo? Is it sufficient to run git-svn dcommit with the SHA1 of the last recovered commit in SVN? eg. > svn info http://tracked-svn/trunk | sed -n "s/Revision: //p" 252 > git log --grep="git-svn-id:.*@252" --format=oneline | cut -f1 -d" " 55bb5c9cbb5fe11a90ec2e9e1e0c7c502908cf9a > git svn dcommit 55bb5c9cbb5fe11a90ec2e9e1e0c7c502908cf9a Or will the git-svn-id need to be stripped from the intended commits? I tried this using --dry-run but couldn't tell whether it would try to submit all commits: > git svn dcommit --verbose --dry-run 55bb5c9cbb5fe11a90ec2e9e1e0c7c502908cf9a Committing to http://tracked-svn/trunk ... dcommitted on a detached HEAD because you gave a revision argument. The rewritten commit is: 55bb5c9cbb5fe11a90ec2e9e1e0c7c502908cf9a Thanks for your help.

    Read the article

  • git-svn guestion about creating local branches

    - by leeed25d
    Is there a way to create a local branch, or modify an existing local branch, in such a way that it cannot be dcommit'ed to the svn repo? Here's a description of the scenario. git checkout -b local.farBranch remotes/farBranch git checkout -b patched.local.farBranch git merge local.patches <work on patched branch && test> <do not commit onto patched.local.farBranch> git checkout local.farBranch git commit -am "some changes" git rebase local.farBranch patched.local.farBranch <another work test cycle> git checkout local.farBranch git commit -am "last changes" git svn dcommit Now, I never want to dcommit patched.local.farBranch (which is tracking remotes/farBranch) because that would put my local patches into the SVN repository. This is not a fatal problem but it is a pain in the keester because the patch has to be removed when the SVN farBranch is eventally (SVN) merged onto the trunk. So what I am looking for is a way to prevent this git checkout patched.local.farBranch git svn dcommit <<== ERROR git checkout local.farBranch git svn dcommit <<== OK

    Read the article

  • Recover history from foolish git-svn merge

    - by Gregg Lind
    the players: master: the svn branch (actual, not local trackign) mybranch: a local branch My mistake: [master] git svn rebase [master] git merge mybranch [master] git svn dcommit I did this twice. Is there a way I can remedy all this? I was thinking something like: git checkout --hard [commit before the merging] git dcommit # that to the svn? git rebase mybranch git dcommit But this doesn't seem to work. (I know I should a. working from a local tracking branch and b. have rebased rather than merged) I'm in the frantic / willing to send beer to respondents stage :)

    Read the article

  • Git SVN - Invalid revision range

    - by Shervin
    I am using git together with SVN. I am trying to perform git svn dcommit but it gives me this error: $ git svn dcommit fatal: Invalid revision range 20edee48314fb1d070d84c1641abd5489d9a1479..refs/rem otes/git-svn rev-list --pretty=raw --reverse 20edee48314fb1d070d84c1641abd5489d9a1479..refs/r emotes/git-svn --: command returned error: 128 I can't seem to understand whats wrong. I can't even do a git svn info. It gives me the same error

    Read the article

  • git-svn: reset tracking for master

    - by digitala
    I'm using git-svn to work with an SVN repository. My working copies have been created using git svn clone -s http://foo.bar/myproject so that my working copy follows the default directory scheme for SVN (trunk, tags, branches). Recently I've been working on a branch which was created using git-svn branch myremotebranch and checked-out using git checkout --track -b mybranch myremotebranch. I needed to work from multiple locations, so from the branch I git-svn dcommit-ed files to the SVN repository quite regularly. After finishing my changes, I switched back to the master and executed a merge, committed the merge, and tried to dcommit the successful merge to the remote trunk. It seems as though after the merge the remote tracking for the master has switched to the branch I was working on: # git checkout master # git merge mybranch ... (successful) # git add . # git commit -m '...' # git svn dcommit Committing to http://foo.bar/myproject/branches/myremotebranch ... # Is there a way I can update the master so that it's following remotes/trunk as before the merge? I'm using git 1.7.0.5, if that's any help.

    Read the article

  • View a git diff-tree in a reasonable format

    - by Josh
    Howdy, I'm about to do a git svn dcommit to our svn repo -- and as is recommended in a number of places, I wanted to figure out exactly what I was going to be committing with a dry run. As such I ran: git svn dcommit -n This produced output: Committing to http://somerepo/svn/branches/somebranch diff-tree 1b937dacb302908602caedf1798171fb1b7afc81~1 1b937dacb302908602caedf1798171fb1b7afc81 How do I view this in a format that I can consume as a human? A list of modified files comes to mind. This is probably easy, but running git diff-tree on those hashes gives me a reference to a directory and a some other hashes, as well as some numbers. Not quite sure what to make of it. Thanks very much, Josh

    Read the article

  • Using git submodules in a git-svn project

    - by Matthias
    In our git-svn managed project, we have 3 upstream projects that are all kept in native git repositories on GitHub. Since the source code of those upstream projects is under our control and changes frequently, our current solution, namely re-deploying the build artifacts to the super-project everytime we change something is quite cumbersome. What I'd like to have is this: parent project (git-svn): --> submodule 1 (git) --> submodule 2 (git) --> submodule 3 (git) That way, the source code for submodules 1-3 is compiled along with the sources for the super project, but I can push changes to submodules separately. The question is: what happens when I git svn dcommit on the parent project? Does this even work? UPDATE Hm, I just set up a simple project structure, trying to resemble this scenario, and I receive this error message when trying to dcommit on the superproject: a0301b11f3544a1e71067ff270eded65e4c8afbd doesn't exist in the repository at /opt/local/libexec/git-core/git-svn line 4775 Failed to read object a0301b11f3544a1e71067ff270eded65e4c8afbd at /opt/local/libexec/git-core/git-svn line 574 Any ideas/suggestions?

    Read the article

  • Shared Git repo syncing to svn causing git svn rebase to pollute repo with a log of no-op merge prob

    - by John K
    This wasn't so bad at the beginning, but now I have hundreds of no-op merge problems (solved by git rebase --skip). I have setup a shared git repo for my group because it is easier to deal with. But the company uses SVN so I have to keep SVN in sync with GIT. Worked like a dream at first, but after weeks of doing this GIT is giving me a lot of the following errors. Applying: * making all config actions work Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging app/controllers/vulnerabilities_controller.rb CONFLICT (content): Merge conflict in app/controllers/vulnerabilities_controller.rb Auto-merging public/javascripts/network_analysis_vulnerability_config.js CONFLICT (content): Merge conflict in public/javascripts/network_analysis_vulnerability_config.js Failed to merge in the changes. Patch failed at 0046 * making all config actions work My workflow: git co master git pull origin git svn rebase ... deal with no-op merge problems ... git svn dcommit git pull origin git push origin The problem is that what is in SVN is the correct so I use git rebase --skip, but I have to do that hundreds of times before I can dcommit. How do I clear these merge problems permanently?

    Read the article

  • msysgit git-am can't apply it's own git format-patch sequence

    - by Andrian Nord
    I'm using msysgit git on windows to operate on central svn repository. I'm using git as I want to have it's awesome little local branches for everything and rebasing on each other. I also need to update from central repo often, so using separate svn/git is not an option. Problem is - git svn --help (man page) says that it is not a good idea to use git merge into master branch (which is set to track from svn's trunk) from local branches, as this will ruin the party and git svn dcommit would not work anymore. I know that it's not exactly true and you may use git merge if you are merging from branch which was properly rebased on master prior merge, but I'm trying to make it safer and actually use git format-patch and git am. We are using code review, so I'm making patches anyway. I also knew about git cherry-pick, but I want to just git am /reviewed/patches/dir/* without actually recalling what commits was corresponding to this patches (without reading patches, that is). So, what's wrong with git svn and git am? It's simple - git am for a few very hard points is doing CRLF into LF conversion for patches supplied (git-mailsplit is doing this, to be precise), if not rebasing. git format-patch is also producing proper (LF-ended) patches. As my repo is mostly CRLF (and it should remain so), patches are, obviously, failing due to wrong EOL. Converting diffs to CRLF and somehow hacking git am to prevent it from conversion is not working, too. It will fail if any file was removed or deleted - git apply will complain about expected /dev/null (but he got /dev/null^M). And if I'm applying it with git am --ignore-space-change --ignore-whitespace that it will commit LF endings straight to the index, which is also weird. I don't know if it will preserve over commiting into svn (via git svn dcommit) and checking it out and I don't want to try out. Of course, it's still possible to try hacking around patches to convert only actual diffs, but this is too much hacks for simple task. So, I wonder, is there really no established way to produce patches and apply them to the same repo on the same system? It just feels weird that msysgit can't apply it's own patches.

    Read the article

  • Will git-svn send file permission changes to a SVN repository?

    - by theForce
    I'm using git-svn in a svn environment. When i check out .sh files they do not get the +x flag. So i change that manually, but now git tells me the file has been modified. My question is: If i'd stage + commit those +x changes, will git push them to the svn server when i "git svn dcommit"? This is not what i want, i just want git to 'memorize' the +x changes locally but not to try to send file permission changes to the svn repository.

    Read the article

  • git svn on multiple machines

    - by stgtscc
    My repo is SVN and I'm using git-svn to interface with it which has been working out well. I'm working on the code base from a few different machines and appreciate some insight as to what the best setup might be for me going forward. I'd like to use git primarily but I need to commit to svn (via git svn dcommit) and pull from svn (git svn rebase) periodically from potentially any of the machines. Is it possible to perhaps have git svn setup on all but somehow push and pull changes between the instances? Or should I setup a bare repo and use that as the central git repo? How would that tie in to git svn? Any insight is appreciated.

    Read the article

  • Maintain set of local commits working with git-svn

    - by benizi
    I am using git to develop against a project hosted in subversion, using git-svn: git svn clone svn://project/ My general workflow has been to repeatedly edit-and-commit on the master branch, then commit to the svn repository via: git stash git svn dcommit git stash apply One of the local modifications that 'stash' command is preserving, that I don't want to commit to the svn repository, is a changed database connection string. What's the most convenient way to keep this local change without the extra 'stash' steps? I suspect that something like 'stash' or 'quilt' is what I'm looking for, but I'm still new enough to git that I think I'm missing some terminology that would lead to the exact incantation. Update: The only solution I found that seems to avoid the git stash + git-svn action + git stash apply series was to update the git-svn ref manually: (check in local-only change to 'master', then...) $ cat .git/refs/master > .git/refs/remote/git-svn $ git svn fetch (with at least one new SVN revision) And that leaves the local-only commit as a weird (probably unsafe) commit between two svn revisions.

    Read the article

  • Git to SVN trouble

    - by Kevin
    My boss has a Perforce repository for which he wants to make a read-only copy available on Sourceforge via subversion. He had a perl script which would do this but it's no longer functioning (we don't want to try debugging it yet) and it's really not that great anyway. So an alternate solution is to pull the perforce repo into git as a remote ref, which I have already done successfully (including all the proper commit details and authors), now the trouble I'm having is pushing it out to a separate SVN repository. I can make it start the commit process with "git svn dcommit --add-author-from", but the problem is even though the correct author appears at the end of the commit message the "real" author committing is my machine's user. I want to preserve the real author with the commit, and I'd also like to preserve the original timestamps as well. Is anyone familiar with how I could accomplish this?

    Read the article

  • GIT Clones on Multiple Machines

    - by Adam
    Here's my setup... Laptop (Mac) - git clone of svn repository Thumb drive - git clone of laptop git repository Server (Win Server 08) - git clone of thumb drive repository I'm having trouble keeping them in sync for some reason... If I make a change on the server, I'll do a "git pull " on the thumb drive to get the changes. Take the thumb drive to the laptop and do "git pull " on the laptop. From there, I can do "git svn dcommit" and everything goes up to the SVN repo with no problem. If I pull changes from SVN with "git svn rebase" and then do a pull onto the thumb drive and do a "git status" it says that I'm ## revisions ahead of the master/origin and I can't figure out why.

    Read the article

  • Instructions on using TortoiseGit to interact with an SVN repository?

    - by markerikson
    I've been using TortoiseSVN on Windows for years with local filesystem repositories for my own projects. I'm planning to start collaborating with a friend on one of the projects, and will be shifting the repository to my own website. I've read a lot of "git beats SVN!" posts over the last couple years, and figured I ought to at least see what the fuss was about. Some research turned up the "git svn" command, and that TortoiseGit claims to have some level of git-svn support. I like the idea of keeping the SVN repository, and doing some local commits or branches with git before committing them to the repository. The "shelve" command also sounds useful. Unfortunately, while there's a number of CLI git-svn tutorials, there's nothing for TortoiseGit (which admittedly seems to be still in early development). As a result, I'm having problems trying to figure out what workflow I need to get these pieces to cooperate. I have an SVN repository in D:\Projects\repositories\MyProject. I created D:\Projects\temp\gittest, and tried to do a TortoiseGit "Git Clone" of the repository. From there, I've had issues trying to indicate the location of the trunk/branches/tags folders (which are just the standard layout in my repository). I was only able to get useful results when I left those unchecked. When I did seem to get the git repository started correctly, I was able to make some changes and do a couple git commits, but then had problems doing an SVN DCommit. So, I'm hoping someone out there can provide a reasonably detailed set of instructions on how to correctly use TortoiseGit with an existing SVN repository (with the repository on either the local filesystem or on a remote server). No "don't use SVN!" responses, please - I'm interested in learning how to get these two pieces to work together. If you feel TortoiseGit's SVN support isn't mature enough to make this work, that would also be useful information. Thanks!

    Read the article

  • Git force complete sync to master

    - by Jesse
    My workplace uses Subversion for source control so I have been playing around with git-svn for the advantages of my own branches, commit as often as I want without touching the main repo, etc. Since my git svn checkout is local, I have cloned it to a network share as well to act as a backup. My thinking is that if my desktop takes a dump I will at least have the repo on the network share to get changes that I have not had a chance to dcommit yet. My workflow is to work from the desktop, make changes, commit, etc. At the end of the day I want to update the repo on the network share with all of my current changes. I had setup the repo on the network share using git clone repo_on_my_desktop and then updating the repo on the network share with git pull origin master. The problem that I am running into is when I used do a git rebase to squish multiple commits prior to dcommitting to the main svn repository. When I do this, I get merge conflicts on the repo on the network share when I try to backup at night. Is there a way to simply sync entirely with the repository on my desktop without doing a new git clone each night?

    Read the article

  • How to Make a DVCS Completely Interoperable with Subversion?

    - by David M
    What architectural changes would a DVCS need to be completely interoperable with Subversion? Many DVCSs have some kind of bidirectional interface with Subversion, but there are limitations and caveats. For instance, git-svn can create a repository that mirrors Subversion, and changes to that repo can be sent back to Subversion via 'dcommit'. But the git-svn manpage explicitly cautions against making clones of that repository, so essentially, it's a Subversion working copy that you can use git commands on. Bazaar has a bidirectional Subversion capability too, but its documentation notes that Subversion properties aren't supported at all. Here's the end that I'm pursuing. I want a Subversion repository and a DVCS repository that, in the steady state, have identical content. When something is changed on one, it's automatically mirrored to the other. Subversion users interact with the Subversion repository normally. DVCS users clone the DVCS repository, pull changes from it, and push changes back to it. Most importantly, they don't need to know that this special DVCS repository is associated with a Subversion repository. It would probably be nifty if any clone of the special repository is itself a special repository and could commit directly to Subversion, but it might be sufficient if only the special repository directly interacts with Subversion. I think that's what mostly needed is to improve the bidirectional capability so that changes to Subversion properties are translated to changes in the DVCS repository. Some changes in the DVCS repository would be translated to changes to Subversion properties. Or is the answer to create a new capability in Subversion that interacts with a DVCS repository, using the DVCS repository as just a special storage layer such as fsfs or bdb? If there's not a direct mapping between the things that Subversion and a DVCS regard as having versions, does that imply that there's always going to be some activity that cannot be recorded properly on one or the other?

    Read the article

  • Publish Git repository to SVN

    - by Ken Williams
    I and my small team work in Git, and the larger group uses Subversion. I'd like to schedule a cron job to publish our repositories current HEADs every hour into a certain directory in the SVN repo. I thought I had this figured out, but the recipe I wrote down previously doesn't seem to be working now: git clone ssh://me@gitserver/git-repo/Projects/ProjX px2 cd px2 svn mkdir --parents http://me@svnserver/svn/repo/play/me/fromgit/ProjX git svn init -s http://me@svnserver/svn/repo/play/me/fromgit/ProjX git svn fetch git rebase trunk master git svn dcommit Here's what happens when I attempt: % git clone ssh://me@gitserver/git-repo/Projects/ProjX px2 Cloning into 'ProjX'... ... % cd px2 % svn mkdir --parents http://me@svnserver/svn/repo/play/me/fromgit/ProjX Committed revision 123. % git svn init -s http://me@svnserver/svn/repo/play/me/fromgit/ProjX Using higher level of URL: http://me@svnserver/svn/repo/play/me/fromgit/ProjX => http://me@svnserver/svn/repo % git svn fetch W: Ignoring error from SVN, path probably does not exist: (160013): Filesystem has no item: File not found: revision 100, path '/play/me/fromgit/ProjX' W: Do not be alarmed at the above message git-svn is just searching aggressively for old history. This may take a while on large repositories % git rebase trunk master fatal: Needed a single revision invalid upstream trunk I could have sworn this worked previously, anyone have any suggestions? Thanks.

    Read the article

  • Using git svn with some awkward permissions

    - by Migs
    Due to some funky permissions on our client's side that we can't change, we have a project whose hierarchy looks something like: projectname/trunk: foo/, bar/, baz/ projectname/branches: branch1/, branch2/ (where branch1 and branch2 each contain foo, bar, and baz.) The thing is, I have no permission to access trunk, so I can't just do a clone of project/trunk. I do have permission to access branches. What I am currently doing is checking out each subdirectory individually via git svn clone, so that each one has their own git repo. I use a script to update/commit them all, but what I would prefer to do is to check them all out under a single repo, and be able to commit changes with a single call to git svn dcommit. Is this possible? I mentioned the branches hierarchy because if possible, I'd also like to be able to track the branches the way I could if the permissions were more sane. I've tried permuting a lot of options that sounded useful, but I haven't found one that gives me exactly what I want. I sense that the solution may have something to do with --no-minimize-url, but I'm not even sure about that, as it didn't help me when I tried it.

    Read the article

1