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.
Related
I am performing salesforce deployments. The current setup is:
Dev org is pushed from develop1 branch.
UAT org is pushed from UAT1 branch.
Every 2 weeks we do a Mergeback of UAT1 into develop1. Which is later deployed onto the dev org.
This has been working for me until now. Currently I have been continuously seeing below error while merging in eclipse:
**"Multiple common ancestors were found and merging them resulted in a
conflict"**
I tried using Eclipse Neon/Mars with Egit 4.*. I am unable to carry out the merge activity and resolve the conflicts.
Based on the answers in the below question:
How to work around "multiple merge bases" error in EGit Eclipse plugin?
I do not want to go about the cherry picking of the merge activity since It will be a very cumbersome task.
Is there another tool which can handle this? I have installed sourcetree, but I am not sure if this would help.
I was able to get this working by doing the following:
Used source tree to merge the local copies of the remote branches develop1 and UAT1---> Source tree was able to handle the multiple ancestor problem and gave me a list of conflicts.
Since I was not very comfortable with using Source tree for conflict resolution, I eclipse to open the code and resolve the conflicts in the Git staging window.(I'd like to know if there is a similar external editor that allows you to accept the changes and reject like eclipse).
Staged and committed the files using eclipse.
This is a long workaround, and I wonder if I will see the Multiple ancestor issue when I perform the mergeback again after 2 weeks.
TortoiseGit on Windows was also successful in merging such a situation.
My team is supporting a small Java development team that had been working on a development branch with Eclipse and Subclipse. We've been periodically merging their changes associated with appropriate tasks and defects from this development branch to a release branch which eventually gets merged into a trunk that represents production. Based on best practices advice from CollabNet, we recently created a new development branch from the trunk and moved the old development branch to an archive directory. (The motivation for this is that eventually changes would accumulate in the development branch that never get merged anywhere else, and the development branch would become impractically different from the release branches and the trunk.)
Our java team was disappointed to discover that once they'd created their new Eclipse workspaces with the new development branch, file histories in Subclipse did not show all of their individual changes. Only the merge operations are listed. This makes sense since the new development branch was copied from trunk, which only ever had these merges performed on it.
But our Java team would like to easily reference the histories in the old development branch. What is the easiest way for them to do this? Some options I can think of are:
Navigate to the old branch in the SVN Repository Exploring perspective and examine file histories there. This involves lots of clicking through the repository hierarchy, especially to an individual source file. Is there a way to enter a path in this perspective and jump to it? Or is the only way to click through the hierarchy?
Maintain a separate Eclipse workspace with the old development branch. This means switching workspaces to see the individual developer histories. And it's easy to forget which workspace you're in.
Use Team -> Switch to temporarily switch the file or project to the old branch in your same workspace. Then view the history of the switched file(s). It's easy to forget what you've switched, which can lead to committing to the wrong branch.
Also, none of these options make it easy to compare what's in the new branch to what's in the old branch.
Are there any easier ways I'm missing? Thanks a bunch!
If you really want to follow best practices then you should look at trunk-based development. https://trunkbaseddevelopment.com
There is an option with svn log to show the original commits for a merge. This is the -g option when using the command line. In Subclipse, it is a checkbox on the History view. "Include Merged revisions". This will then expand the merges to show what was merged. Same option exists on Blame. It will make these operations take considerably longer to run in many cases.
The only way to fix this is to use a better process.
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.
We have been using mercurial for over two years for our flex/as3 projects. Over the time, we came up with several projects and a common library which is used/referenced by the projects. In order to maintain the versioning properly, each time a new version is tagged on a project repo, the same tag is applied to library repo, as well.
This is done manually. I am not sure whether what we do which was described above is the correct way but I wonder if there is any (other) way to relate project repos to library repo, so that whenever i want to pull a specific version of a project, i will know exactly what version of library should be pulled.
Any thoughts? Thanks.
Have you ever tried subrepo? By using subrepo, hg will maintain the whole project with the subrepo.
For example, if you have HG_DIR/lib as the library and it is a subrepo to the HG_DIR, then when committing in HG_DIR, hg will remember which rev of HG_DIR/lib you are using with, which means a commit in HG_DIR links with a commit in HG_DIR/lib.
hg subrepo supports multiple VCS subrepos, too.
Update:
As #alexis suggested, use recommendation from the official documentation, lib should be treated as siblings of project:
HG_DIR/
lib1/
lib2/
project/
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