I've got a project on git, assume it has the following files:
HelloWorld.java
README.md
pom.xml
I edit/commit README.md using Github's editor; no problem. Then, in eclipse using eGit, I edit HelloWorld.java, but when I attempt to commit and push that file, I get an error: non-fast-forward. Unless I do Pull first I can't commit the java file. Why is this the case? Using SVN I never had such a problem. Why does Git not allow me to commit a file when some other, unrelated file in the project is changed? I read up on this but I still don't understand the rationale behind the issue.
BTW, I'm making all changes on master for now.
That is because git is making sure your repository is up to date with the master before you commit changes. The problem is with pushing not committing. You can't push to a repository that you haven't got all the changes for. What you can do is create a new branch with your changes and merge that with the master later if you want, that is the system git uses for what you want to do.
An SVN server will do some types of merges itself, particularly when the changes are to different files as in your case. Since SVN represents branches and tags as different parts of a single tree and a single repository can contain multiple, unrelated projects this is necessary.
But git will never do a merge on the server. And since a commit represents the entire tree, your situation is a merge even though no single file was modified by both sides that need to be merged.
Even though changes being restricted to different files guarantees that there won't be any textual conflicts between them, there can still be semantic conflicts. Imagine if you're working on a change to a library function which requires all callers to be modified, and before you push that change out another developer adds a new file which contains a new call to that function. If that new file is the only change the other developer made, SVN would allow you to commit your changes and handle the merge on the server even though that will cause the code to be broken. By requiring that all merges happen under developer control, git at least gives the opportunity for this type of conflict to be caught; even though in many cases a developer may just do an automatic merge and push the results without any checking.
Related
Keeps track of files in eclipse, who made changes on which branch
Hello Guys, I am using BitBucket for project management, and i Create different branches as per features. Multiple teams works on their own branches and some time multiple teams make changes in same file.
So at the time of release I have to merge all the created branches in one major branch, but at time of merge i get a lot of merge conflicts,
So basically what i want, when developer going to make changes in any file, dev will get to know all submitted changes in another branches for this same file, (where dev going to make changes), So he or she will know the possible scenarios.
An alternative is to ask for a developer to rebase his/her own branch on top of the main branch first.
Then you can merge that branch easily enough.
That way:
if there are any conflicts, they are detected and resolve by the developer (who knows best how to resolve it)
each merge is a trivial one.
I am using the git plugin for eclipse and I have noticed a problem with it and hoping this is a simple configuration change. Can anyone help?
When switching branches, the uncommitted changes are being merged across onto the newly checked out branch (only in certain circumstances). It seems as if this happens every time when it is "safe" to do so. The way to recreate is:
Create feature branch "branch1" from remote repository
Create feature branch "branch2" from same remote repository
Make changes on "branch2" and don't commit changes.
Switch to "branch1"
a. No confirmation message is shown.
b. The uncommitted changes from "branch2" are merged onto "branch1"
I want to be able to force the commit message to appear (just like it does using git-bash). Is this possible?
To my understanding, this behavior is intended by EGit: a checkout is performed as long as the files to be checked out do not collide with the working directory. And uncommitted changes are left as they are.
If you think EGit should offer a different strategy of handling uncommitted changes I suggest to open an enhancement request: https://eclipse.org/egit/support/
In the meanwhile, you may want to (manually) stash uncommitted changes prior to switching branches. That's what I see most people do in this situation.
I've created a feature branch to work in parallel with the trunk.
In the brach I've done a big amount of structure (folder) changes. For example, I've moved folders that before were on:
application/views/scripts/users/*
to:
application/modules/user/views/scripts/users/*
Now, I'm trying to do a merge from the trunk to this feature branch and I'm founding a million of tree conflicts! And the issue is that since this tree conflicts appear, no file inside that tree is merged against anything.
I mean, I find a tree conflict on:
application/views/scripts/users (SVN message: "The last merge operation tried to modify the directory 'users', but it was deleted, moved or renamed locally")
and none of the files and other folders that were inside that path have been merged.
Is there a way to recover the "link" between the original location of a folder and the current one?
Can I do something to deal with this issue?
More than a solution, I can give a workaround, that is the one that I've used, becuase it seems that there's not really a solution for this.
After a little research I'm close to sure that SVN doesn't support this kind of feature for merging. In the documentation of TortoiseSVN it is said that:
Local missing, incoming edit upon merge
Developer A working on trunk modifies Foo.c and commits it to the
repository
Developer B working on a branch moves Foo.c to Bar.c and commits it to
the repository
A merge of developer A's trunk changes to developer B's branch working
copy results in a tree conflict:
Bar.c is already in the working copy with status 'normal'.
Foo.c is marked as missing with a tree conflict.
To resolve this conflict, Developer B has to mark the file as resolved
in the conflict editor dialog, which will remove it from the conflict
list. She then has to decide whether to copy the missing file Foo.c
from the repository to the working copy, whether to merge Developer
A's changes to Foo.c into the renamed Bar.c or whether to ignore the
changes by marking the conflict as resolved and doing nothing else.
This means that you have to decide, one tree conflict at a time, what to do. And this is not the worst part. What is really unacceptable in my case is that every time I do a new merge from the trunk to this branch I'll be forced to deal with this conflicts again.
The workaround
Replicate the structural changes made on the branch into the trunk (with its required changes on code) and make it work with them.
After commiting this changes both structures of files, the trunk and the branch will match, so later merge operation won't complain anymore.
What i understand from your issue is that you have done a lot of folder structural changes in your branch and since these changes are not there in your trunk and when you are trying to merge you are getting the error.
As per your statement, "Now, I'm trying to do a merge from the trunk to this feature branch"
At the first place when you have taken a branch out from your trunk and did the structural changes in your branch then you should merge these changes from "branch to trunk" or if you simply want to get the original structure ("recover the original location of folders")back then just revert the changes you have done in the branch.
Hope this helps.
There are certain files in my repository that I want to be able to edit locally. But I never want to push any changes to those files to the server. Is it possible for me to set that up?
EDIT: to clarify, I do want to pull changes that others have made. But I don't want to push my changes.
It's not easily possible. Mercurial doesn't push and pull files it pushes and pulls changesets. Your only route would be to never commit those files. Ignoring them isn't an option because they're already tracked (added) and tracked always overrides ignored.
You could explicitly exclude them on commits like.
hg commit -X a-file-I-changed -X another-file
And since you'll eventually forget to do that you could set up an alias in your hgrc:
[alias]
mycommit = -X a-file-I-changed -X another-file
However, I'm going to go out on a limb and guess you're talking about a configuration file like a database settings file. The best way to handle that is to commit not database.conf (or whatever it's called) but instead database.conf.sample and then have your launch script copy database.conf.sample to database.conf if it doesn't already exist. That's the normal practice.
If your change is substantial consider making it a patch in a Mercurial Queue. You can pop your change, pull their changes, and then push your change back on to the working dir. If it's a change you couldn't bear to lose you can make make the queue a repository of its own, and then clone that repository elsewhere.
A Ry4an writes, you can exclude the file when you commit. A colleague of mine has made a simple extension that will automate this in simple cases:
https://www.mercurial-scm.org/wiki/ExcludeExtension
https://bitbucket.org/aragost/exclude/
The non-simple case is a merge -- Mercurial wont let you exclude files when you commit a merge. For now, you'll have to move the modified file aside, revert it, and then move it back after the merge. Patches are welcome to handle this case!
I am looking forward to merge my code which I developed in a branch of SVN to the trunk. I am using Eclipse and I have been using Team->Commit to commit my updates to the SVN. But I haven't done a merge before. Please help me with this.
First of all make sure you are up to date. Update your working copy of the target branch, ie. where you are merging into. In this example we're working on the trunk of "core" and we want to grab the changes that have happened in the maintenance branch and merge them.
Resolve any conflicts. There should be no conflicts at this stage between the working copy and the repository.
Select the SVN merge option on the working copy. In Eclipse this is going to be found under the "Team" menu and called "Merge Branch".
SVN: Merging in Eclipse
Change the From URL to the specific branch you want to be merged into your working copy. In this example we're looking for the p400 maintenance branch (./core/branches/p400).
Change the From Revision to the last revision that was merged into the target branch. Essentially you don't want to keep merging the whole branch history, you just want to include those changes since the last time you merged. There is no easy way to determine the last merge point at this time in Subversion. You have to review your message log and look for the last commit that talks about merging. If you are disciplined about the commit messages you use for merging this should be easy (see below). Make a note of what that revision is -- you'll need this later when you commit your changes.
SVN: Merge with Eclipse
Change the To Revision to the latest (i.e. head). Make a note of what that revision is -- you'll need this later when you commit your changes.
Click Merge and wait. Depending on how big the differences are this may be quick or Eclipse my just fall over. If you have such an enormous change that you can't get it done in Eclipse you may need to make the range of revisions you are merging smaller. Or you may even have to skip certain revisions and do them manually if they are massive. We've had this problem from time to time when updating large third-party libraries. The vast majority of the time you will be fine.
Review changes and resolve conflicts. Once the merge is complete, look through the changes made to your working copy and make sure you address any conflicts you find.
Once all the changes have been resolved in the target working copy, check them in with a single commit. The reason you're not doing lots of commits is that these are changes that should have been documented in the branch from which you merged. The commit message needs to be in a specific format that details the merge and is easy to find in the future. We use the following format, but you can use anything that works for you -- as long as you stick to it.
Merging [source] to [target]; [repository]. Merge rev [start]:[end]
Enjoy!
In eclipse we have an option to merge. Right click the project , you will see "Team" option and on clicking it you will see merge option. There are three different options you can see in the merge.
To successfully merge the changes from the branch to the trunk, we need to switch the local workspace to the trunk (but make sure all the changes are committed to the branch before that). Once we do that we can use merge option and select "2 URLs" option. I put url for trunk as url 1 and the branch I wanted to merge as url 2. I could see all the incoming changes I selected "OK". All the changes are in my local now (at this point my workspace is linked to the trunk). Then I committed my changes to the trunk and hence merge from branch to the trunk was successful.
I would like to add for Point 8 .Review changes and resolve conflicts. ---
When working on conflicts manually- when you do copy from right to left on chunks of code - Be careful
Sometimes chunk of code gets added, sometimes it properly replaces the chunk.
Make sure there is no duplicate chunk of code.
Also, this is helpful-- What is the proper way to do a Subversion merge in Eclipse?