Re: VC mode and git

[Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>]

Alan Mackenzie wrote:
> On Tue, Mar 31, 2015 at 06:24:46PM +0900, Stephen J. Turnbull wrote:
>> Alan Mackenzie writes:
>
>>> Why can't git simply merge changes properly into the workspace, thus
>>> saving users the unwelcome hassle of, e.g., git stash followed by
>>> git merge followed by git stash pop?
>
>> It does, the same way that bzr or Mercurial does.[1] I don't see why
>> you would think otherwise.
>
> Partly due to the following bug report which is near the start of the
> git-merge man page: "Warning: Running git merge with non-trivial
> uncommitted changes is discouraged: while possible, it may leave you
> in a state that is hard to back out of in the case of a conflict.".
> I can't imagine why the git maintainers don't fix this.
>
> With git pull, if there are changes in the working directory, the
> merge (i.e. merge from remote/master into master) part of the
> operation is aborted before it starts, giving a message describing its
> refusal.  It does this even when there are no conflicts to deal with.

What are we supposed to do in that case, if we're not yet ready to
commit our files?

Something like:

--8<---------------cut here---------------start------------->8---
git stash
git pull
git stash apply
--8<---------------cut here---------------end--------------->8---

or putting our work into a new branch, like:

--8<---------------cut here---------------start------------->8---
git checkout -b new-branch-name
git commit -a -m "Edited"
git checkout master
git pull
...
--8<---------------cut here---------------end--------------->8---

Are there other (more elegant, or more clever) ways to deal with that
situation (fetching something someone has fixed without committing we're
not yet ready to commit and push on master)?

Best regards,
  Seb

-- 
Sebastien Vauban