Re: VC mode and git

[Steinar Bang <sb@dod.no>]

>>>>> Richard Stallman <rms@gnu.org>:

> Reportedly pull includes merge, so this implies that git pull is also
> dangerous when you have made changes.

Dangerous in which way?

If you have committed your changes locally, and do a pull, and there are
no conflicts, will be a new commit on your master (the merge commit),
but no harm done otherwise.

If you get a conflict in the merge, git will not complete the commit
until the conflict is handled (much as any version control system).

If you have uncommitted changes and the merge in the pull command
doesn't touch any of the files with uncommitted changes, and there is no
conflict, there may be a new commit (the pull could also be a
fast-forward, in which case there is no commit), and your changes will
still be in the working directory.

If there is a conflict, the merged files with no conflict will be staged
for commit, both your local changes and the files will be seen as
unstaged modified files (but the conflicted files are shown as such, at
least in magit).

If the pull merge affects any of the files you have uncommitted changes
in, then git refuses to merge (refuses to overwrite your local changes).

You need to either stash your local changes, or put them on a local
commit before git will do the merge.

> It usually takes weeks from when I write a change to when I check it
> in to Savannah.  To check them in, I must first get the latest changes
> from Savannah.  If I can't do a pull in that state, how can I ever
> check them in?

You can do a pull.  The simplest way to avoid most of the possible
conflicts would be to
 git stash
 git pull
 git stash pop
before you commit.

But note that "git stash pop" can have conflicts, and git pull may have
conflicts (if you don't have any other local changes except your
uncommitted changes, ie. no local commits, then pull will never have
conflicts).