0

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.

Community
  • 1
  • 1
raffian
  • 31,267
  • 26
  • 103
  • 174

2 Answers2

1

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.

stmfunk
  • 663
  • 5
  • 20
  • So the general workflow is to make changes on a branch and merge with `master` when required? – raffian Aug 27 '13 at 17:45
  • Yeah that is the idea but for small projects I would usually just make a pull request before I push to the main repo, it is simpler. – stmfunk Aug 27 '13 at 17:50
0

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.

qqx
  • 18,947
  • 4
  • 64
  • 68