First let me clarify that a git pull
cannot cause a merge conflict in files that were not touched by a local commit. So a user will only ever have to deal with files he actually touched.
If these merge commits are a problem to you, you should consider switching your work flow. The way to interact with git is not set into stone and there are large differences in established work flows. For instance the PostgreSQL project works with git entirely without any merge commits. On the other hand there is a workflow that uses merge commits in a meaningful way. To obtain a behaviour that resembles the SVN workflow a bit, pass --rebase
to git pull
, but before doing so, read man git-rebase
carefully to understand the implications. Alternatively you can use git stash
to pull remote changes before committing, but any of these options just places the conflict resolution step in a different spot.
To examine your last question: Git treats a working tree as a snapshot of your project. If it were mixing newer files with older files, different files would have different versions, a concept that is foreign to git. If you want such a feature, you need to look for e.g. CVS (no joke). There is a tradeoff being made here: Any version control system has to make the decision of either being able to track file moves or being able to track different files in different versions. Git chose the former.