Re: Stash

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 06 Apr 2015 01:51:06 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> One superiority of CVS is 'cvs up' reports its actions in a clear and
> concise way.  Once you know what the letters mean, it is all
> straightforward.
> 
> If it updates a lot of files, I often do 'cvs up' a second time,
> knowing it will show me only the files I have changed and might want
> to install.

There's no alternative here but to learn to use a different command
for showing that:

  git status --short

It should produce approximately the same display as you are used to
with CVS:

   M modified-file1
   M modified-file2
  ?? unregistered-file1

etc.  You can see the entire set of two-letter status markers in the
man page of "git status".

> I have forgotten what Bzr's output looked like, but I recall that it
> was easy for me to see what conflicts there were.

Bzr would state the conflicted files at the end of the "status"
command.  It also had an explicit "bzr conflicts" command.

Git shows conflicts with two-letter codes; e.g., a file that was
modified both upstream and by you locally will be marked with "UU",
which means that both you and "them" Updated the file.

> Git outputs a mass of information.  As a Git beginner I don't
> understand what part of it might indicate a problem.  This is a
> serious concrete failing of Git.

Do you mean the information presented by "git pull", or do you mean
some other command?

"git pull" outputs roughly the same amount of information as CVS and
bzr would, just in slightly different format.  Here's an example:

  $ git pull
  remote: Counting objects: 215, done.
  remote: Compressing objects: 100% (98/98), done.
  remote: Total 98 (delta 88), reused 0 (delta 0)
  Unpacking objects: 100% (98/98), done.

This part is just status messages during "fetching" (i.e. bringing the
new stuff) from upstream.  It has no direct CVS equivalent; bzr had
something similar.

  From git.savannah.gnu.org:/srv/git/emacs
     ba0a6e9..b884ff3  master     -> origin/master
     21d4bf6..8272c1d  emacs-24   -> origin/emacs-24
   * [new tag]         emacs-24.5-rc3 -> emacs-24.5-rc3

This part describes repository-global events, like new branches, new
tags, etc.

  Updating ba0a6e9..b884ff3
  Fast-forward
   ChangeLog                      |   4 +-
   doc/misc/htmlfontify.texi      |  10 +--
   etc/NEWS                       |   6 ++
   lisp/ChangeLog                 |  17 ++++
   lisp/ChangeLog.16              |   2 +-
   lisp/gnus/ChangeLog            |   8 +-
   lisp/gnus/rtree.el             |   7 +-
   lisp/htmlfontify.el            |  11 +--
   lisp/org/ox-odt.el             |   7 +-
   lisp/progmodes/python.el       |  97 ++++++++++++++++-------
   test/ChangeLog                 |   9 +++
   test/automated/python-tests.el | 173 +++++++++++++++++++++++++++++++++++++++++
   12 files changed, 305 insertions(+), 46 deletions(-)

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.

("Fast-forward" means the stuff fetched from upstream was pure
additions to what you had locally, i.e. your local branch did not
diverge from upstream since the last pull.  If you have local changes
that you committed, but didn't yet push upstream, you will generally
not see the fast-forward part.)

> I think Git ought to have an 'update' facility, for simple usage
> scenarios, that would be just as easy to use as cvs update.

The only major difference 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).  Git does expose that, so when pull fails due to conflicts,
it tells you about the failed merge.  You need to realize that the
merge in question is an integral part of pull, and simply deal with
the conflicts much in the same way as you'd do for CVS and bzr.

What other parts of "git pull" are "not simple", which you think need
to be simplified?