I have two different projects, but some feature are same for both project. Both projects are commit to server as Master. I want to make configuration so that i can pull the selected changes of project 1 to project 2 but I want to keep remote of both projects different.
Note: I am new to git and I am using Eclipse.
You can make patchs of the changes you want.
But, Why do you need to keep two git projects? You can keep one git project with two branchs.
Related
I'v tried to merge a hotfix of my current deployed release branch into my develope branch.
Intellij found only the changes that were in the hotfix.
eclipse on the other hand found additionally some changes between the release and the develope and put them on the unstaged files.
Why is there a difference between the 2 IDEs? Do they use different git merge or diff? Do they choose different common ancestors?
Thank you!
No, IDEs don't have anything to do with GIT internal commands.
I think it was a mistake from your own side. I suppose you have two local repos for two IDEs, right?
May be you accidentally merged with different branch.
You said eclipse put some files to upstaged change, may be there's a conflict to that merge. Resolve it.
I am looking for a way to work with different GIT branches and have the Eclipse workspace in sync. with the directory structure of the GIT branches. In this case the branches will differ as projects have moved around from subdirectoris. To illustrate:
master
plugins
plugin1
plugin2
feature1
topic_organize
plugins
plugin1
plugin2
features
feature1
I think the current Egit solution is not workable. What it does it close projects which are not in the new branch. (When I switch branches in the cmd line, is even more horrific, Egit actually recreates the missing projects! in this case, when I switch to branch "topic_organize", the project feature1 in plugins will be recreated by EGit, my repo is automatically not clean which I sincerely despise, when switching to a branch).
What it doesn't do (and should do) is to start with a clean workspace, and import all the projects and organize them in working sets and on top load the appropriate target platform.
The consequence of not doing what is should is, that I have to 1) manually import missing projects,
2) remove projects created by EGit which are in my repo, but not imported in the workspace. 3) Create working sets if these differ between branches. (In my case the working sets, are equal to the sub-dirs in the repository). 4) Clean my GIT repo.
As a best-practise towards a full solution is to create a team project set. The working steps would be.
Import your projects from GIT and add them to working sets corresponding to the directories in the GIT repo.
Export a Team Project set to a special project. (Make sure the location of this project never moves in GIT).
Commit this "team" project, so your GIT branch is clean.
Clean your workspace. (I mean start with a clean workspace by removing all working sets and projects).
Switch branch on the command line (You won't be able to switch with a clean workspace).
Select file import, import Team Project Set (.psf) file. (Assuming you did step 1,2,3 for the other branch as well).
tada your workspace is back with working sets and all projects open.
Change your target platform if needed.
NOW MY QUESTION :P
Do I miss something? Is this there a way to clean the workspace in one go? Now I have to remove the working sets first, then the projects by selecting them one by one! (Perhaps I should switch the workspace as well?).
Considering the way Eclipse work, it has only one version of a project available in an Eclipse workspace at any time (because the id of a project is its... name)
When one needs to "switch branch", I always prefer having:!
multiple clones of the repo (one per branch, I rarely need more than 2)
multiple Eclipse workspaces
Switching branch means switching workspace and updating the branch you are in, in that workspace.
As the OP user2736833 comments below (using git remote):
git clone repo br_dir
cd br_dir
git checkout br
cd repo
git remote add -t br_dir br_repo ../br_dir
Then:
git fetch br_repo
git checkout br
git merge br_repo/br
I already have a CVS and that cvs is used to share the source among other developers. But I need to keep a track of my source code changes separately. Moving the project from cvs to git is not practicable here.. and you may think that why 2 versioning controls. Any way I need to have a separate repository. I have tried git with eclipse. It is ok. I want to know how I can use both my personal git repository and cvs together in eclipse. (For example, when I commit my changes in eclipse, Team -> commit .. How can I separately commit to both cvs and git..and whenever I need to see the history in eclipse, separately git and cvs.. .Also when CVS server is not supporting, I can work with my local git repo as well. ) I need to handle all in eclipse IDE. Any one give any tutorial or links for my solution, it is highly appreciated.
You can have a git repo directly within your sources, but Eclipse would still be set on using CVS (and cannot show you both git and cvs commands at the same time).
That means you go on committing with CVS and Eclipse, but would need to commit (locally) in Git with an external tool (either a simple command-line session, or any GUI you want, like GitHub for Windows or SourceTree)
It actually is possible, if you create a dummy Eclipse project and designate the git repository at the workspace root (.git directory at same level as all projects in the workspace). This way when you make commits from this project, all projects in the workspace are its members and you can keep the members themselves connected to cvs.
You can create such repository by first creating the dummy project, and (Team->Share) sharing it via git using the Configure Git Repository dialog. Select “Use or create repository in parent folder” and explicitly remove the project folder from the "Create Repository" line after checking (checkbox) the project from the list of available projects.
After pressing "Create Repository" the project directory suffix will reappear, but remove it again before pressing Finish. In my version of Eclipse pressing Finish will hang, and I must terminate Eclipse to restart it.
After restarting the dummy project can be used to Commit files in all the other projects while the other projects remain connected to cvs.
Screenshot of “Use or create repository in parent folder” view when pathname has been entered by pressing "Create Repository" and then (corrected again before pressing) Finish.
Question:
How do you commit a single project (of many) in pydev (eclipse Indigo 3.7.2) using egit?
Problem Specifics:
I have many independent projects that currently all go to the same repository. I work on them all sporadically and need to commit them individually (not all at once) since sometimes only 1 project is ready. Unfortunately, when I right click on a single project folder, select Team, then Commit, git tries to commit all of my projects (not just the one I selected).
Conjectures:
Do I need to have the projects in separate local repositories? If that is the case, what is the best practice for segregating projects that eventually end up in the same bit bucket repository? Or, should I just have multiple bit bucket repositories?
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