Re: Stash

[Eli Zaretskii]

> Date: Tue, 07 Apr 2015 12:13:53 -0400
> From: Richard Stallman <address@hidden>
> CC: address@hidden, address@hidden
> 
>   > This is the main part that describes the "merge" step of "git pull":
>   > it says it performed a "fast-forward" (see below), and then shows one
>   > line for each updated file with "diffstat" form of statistics of
>   > changes in each file.  The last line is a summary of the changes.
> 
>   > As you see, this is not very different from what CVS and bzr displayed
>   > in these circumstances.
> 
> Here are some important differences:
> 
> * cvs up indicates in a very visible way which files I have local changes in.

You mean, the "C" conflict marker?  Or do you mean something else?

>   What's more, if it mentions many other files, I can do cvs up again
>   immediately and see ONLY the files I have local changes in.

As I said, you need to use "git status" for that.  It will show the
same output if invoked repeatedly.

> * cvs up will not "fail".  The worst that can happen is that some
>   file has a conflict, and if I don't bother with it immediately,
>   I will get reminded of it later.

Right, but this is unrelated to the display during "pull".

> * git pull outputs lots of unhelpful detail when nothing is wrong.

Not sure what you allude to here.  Is that the diffstat display of the
amount of changes in each file?  You can turn that off, if you want;
try "git pull --no-stat" (if you like that, it can be made the default
in your .gitconfig).

>                             between "git pull" and "cvs/bzr update" is
>   > that the latter didn't expose the "fetch" and the "merge" parts to the
>   > user (CVS couldn't expose it because everything was done on the
>   > server).
> 
> People said that git merge can fail for another reason (I forget
> what), not only because of conflicts.

I'm not aware of any, unless they meant uncommitted changes in the
same files that were changed upstream (which is covered on the Wiki
under "conflicts").

> It looked like that might be what happened to me, which led me to
> edit an old lisp/ChangeLog file even though I had just done a git
> pull.

Sorry for asking the obvious: did you revert lisp/ChangeLog's buffer
after pulling?

But anyway, let's not worry about unexplained things in the past that
we cannot explain.