We have a git-svn repository.
I had no troubles to update the trunk with my local changes (commit + push or commit + merge), however sometimes my colleagues make some fixes in the code and update the git-svn and i want to take his changes without committing mine, since the code is not yet ready for commit (even locally, i might want to revert some of it). I can;t find a way to get his code and merge conflicting changes (i work with 'tower' git client on mac os x).
Any way to do the same action an svn 'update' command will do ?
10x.
You could stash your current work in order to get a pristine working tree, allowing you to do your git-svn update.
You can see a similar technique in "How to handle IDE project files with git-svn".
Another alternative is through Stacked Git.
See "How do I track local-only changes/change sets with git-svn?".
StGit is a Python application providing similar functionality to Quilt (i.e. pushing/popping patches to/from a stack) on top of Git. *
These operations are performed using Git commands and the patches are stored as Git commit objects, allowing easy merging of the StGit patches into other repositories using standard Git functionality.
Related
I'm transitioning from using Subversion in Eclipse for code management to GitHub in RStudio. It's starting to make sense, but I can't seem to figure out how to pull effectively.
Specifically, if I use the Pull arrow in RStudio, every file change in the repository automatically updates my local files without warning. I can see how many files were updated, but not what changed!
Here are the questions I'm hoping to get help with:
1) Can I preview the repository file changes in RStudio before I pull them locally? With SVN in Eclipse, there was an indicator showing files with a difference, and the option to view side by side.
2) If multiple files have been changed on the repository, is it possible to pull just 1 locally?
3) How can I revert a local file to a previous version?
Right now I've been trying to do this all within RStudio for simplicity. I haven't used things like the GitHub desktop client.
I appreciate the help!
I would suggest you better get used to the git's own tools to stay informed about your repository.
For example you could do following.
Before you pull, check your current commit logs
git log
This should show you how your current commits stack up. Note the latest commit id (first 4-5 letters would usually do)
Now after pulling you can see the difference using following command
git diff --color your_previous_commit_id..HEAD
If you don't like the changes and want to go back,
you can just reset to your favorite commit with following command. BTW run "git stash save" to keep a copy of your uncommitted changes.
git reset --hard you_favorite_commit_id
Note: that this will delete all your uncommitted changes unless you stashed them and put your local branch behind the remote repo branch you are tracking again.
Wondering where to put these commands? Check https://git-scm.com/downloads.
What's good about using these git tools is that if you switch between IDEs you don't need to search for same functionalities you had in your earlier IDEs.
I'm working on a project in Eclipse that was cloned from a GIT remote repository. The Eclipse eGit plug-in allows you to get going without really understanding anything about GIT, which is where I was. I've eventually realized that when I do a "compare with HEAD revision" I'm not as I first thought comparing with the remote repository, but with my local repository. I understand now that I need to pull updates from the remote repository, but it's not clear what will happen to my local changes. I've not committed these changes, partly because I thought I might be updating the remote repository (I realize now that I won't) but partly because I find the Package Explorer file decoration (">") is useful in identifying the files I've modified. If I commit then I assume these indications will disappear.
My questions:
How do I update my local repository without losing my changes?
Can I do this without losing my modified file indicators?
Update: I thought I understood how some of this worked, but I'm really lost now, particularly by the relationship between workspace and (local) repository.
I used Team->Pull to update my repository. Since I've not committed any changes, I expected this to work without conflict, but it flagged up all the changes between the workspace and repo as conflicts (confusion #1).
I assumed I needed to use Team->Synchronize to bring changes into the workspace, as I would with other VCSs. When I do, I see the changes, but not even the non-conflict updates have been applied to the workspace and there is no "Update" operation to do this, so I don't know how to apply them (confusion #2).
For the conflicting updates, I manually merged the changes into the workspace copy and used "Mark as merged", but this seems to do nothing. The conflict is not cleared. I would expect at this point the change would just be an uncommitted change in the workspace (confusion #3).
I read elsewhere that to remove conflicts I should use Team->Add and Team->Commit, but I don't want to commit my changes as I explained originally (confusion #4).
You can see I'm confused! Any help will be much appreciated.
If git pull does not work, you can use this:
git stash
git pull
git stash apply
not sure eclipse supports stash, so you may have to use the command line.
I've just discovered, a surprising for me behavior of cvs.
I change file1 localy
During this time people change other unrelated parts of the same file, and commit to the repository
I update my local copy from repository
At this point I expect my local copy of file1 to contain all changes made by others to this file, unless the update above reported a conflict. However, when I do now diff with head, I discover lot's of differences coming from changes made by others in parts of the file that I did not touch at all.
Any ideas? Is this just the limited abilities of cvs to merge? Any wrong setting? Something in my workflow?
CVS has very limited merge facilities. Switch to a modern system such as Git (perhaps via git-cvsimport if the repo maintainer is uncooperative) if you want a better merge experience. See also Best practices for using git with CVS
The final solution is :
1. Save your local code to another place manually
2. Revert the files which may has conflict to the HEAD (most latest) version on CVS server.
3. Add back your change to the Reverted file.
The concept for above solution is to CLEAR UP all the possible issue by REVERT and get a 100% clean version from repository then add back our changes.
It can resolve below issues which caused by code out of date / code base messed up.
CVS commit had a conflict and has not been modified
CVS update failed
CVS not sync
I am working on an enormous project ("the project") which is open-source, and I am changing the project but don't have a permission to commit. I'm looking for strategies for maintaining my own branch of the project. Some issues I am contemplating:
How to put my own work in a version control system, given that I'm altering the project's source code, adding new files and so on.
How to keep in sync with the project without having to manually merge my own changes over and over again.
I've never been in this situation - I've always maintained my complete project in some version control system. My plan right now is something like that:
Creating a directory tree in my SVN, similar to the one in the project.
Keeping all the changed files (and only them) in my svn.
Every time I decide to sync with the new baseline of the project, I'll do a checkout, merge my svn tree into the new version, test, then commit my changes to my svn and distribute them along with the latest project baseline.
The problems here are ENDLESS. Way too many manual steps, more and more work over time, and so on. The correct way to go would be, of course, to be a part of the original project, but this seems to be quite irrelevant right now for various reasons and is out of the question.
Ideas?
I'd use git or mercurial for this; simply import the project into git or mercurial, and merge the upstream changes into a branch in your project for easy merging into your trunk.
If the upstream project has a repository of their own, the import is even easier. Both git and mercurial have support for directly importing other version control systems. I did this recently to adapt an existing project that lives in SVN: https://github.com/mjpieters/rod.recipe.rabbitmq
Note that that project has an 'upstream' branch. That particular project has now accepted my proposed changes after reviewing the changes in github.com.
There are a few questions here on SO on the subject:
Fork and synchronize Google Code Subversion repository into GitHub
Tracking upstream svn changes with git-svn and github?
Best way to fork SVN project with Git
It should be trivial to create a similar setup with mercurial.
You can use git to maintain your source control on your local system. In fact Git can be used to maintain just about any directory under version control. There is no need to sync to anything, git maintains all changes locally.
If you need to commit to SVN check out the documentation http://git-scm.com/docs/git-svn
The question
An open source program uses CVS for version control. I would like to make a number of bug-fixes and submit patch bombs to the developers with commit access. I would also like to maintain my own semi-private fork that mainly tracks the main code-base but that includes my own features (these features, right now, should not be incorporated into the main code-base.)
I prefer to use mercurial for my own version control needs, but I am open to other version control systems if necessary.
I'd like to:
Be able to easily create patch-bombs against the current CVS source with my own bug-fixes
Keep track of history on my own features
Have fixes and improvements from the main tree easily incorporated in my new-feature fork
Easily apply my own bug-fixes to my new-feature fork
Be able to work and track change history without an Internet connection.
What suggestions do you have for doing this?
My current idea
My own best guess is below, to give you a better idea of what I am thinking about.
I will have 3 mercurial repositories.
The first two repos are managed as specified at (https://wiki.mozilla.org/Using_Mercurial_locally_with_CVS). One just mirrors the latest changes from the CVS upstream. I do "cvs update" then "hg commit" in this repo. The second repo holds my bug-fixes as patches using the mq extension and I pull from the the first repo and re-base my patches every so often. When my patches are incorporated into the main tree, I remove the patches from the patch queue/make them permanent commits.
The third repo is my local fork. It will start out as a clone of the first repo. Then each time I do an update of the first repo, I'll pull from it into repo 3. My own features will be directly present as commits in this repo. When I fix a bug, I'll export a patch from repo 2 and apply it to the appropriate pull from repo 1.
I have used Git to manage changes on top of a CVS repository in a similar way. My solution in Git uses local branches instead of multiple repositories, but it sounds essentially similar to your proposed idea.
I found that this arrangement works best if you commit all the CVS metadata (in the CVS/) subdirectories) to your mirrored repository. This means that the CVS metadata gets replicated in the other repositories, but it doesn't cause any harm (and lets you run commands like cvs diff if you need to).