From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Stash Date: Mon, 06 Apr 2015 10:29:15 +0300 Message-ID: <83iod9lnp0.fsf@gnu.org> References: <86sice77h0.fsf@dod.no> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1428305375 17805 80.91.229.3 (6 Apr 2015 07:29:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Apr 2015 07:29:35 +0000 (UTC) Cc: sb@dod.no, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 06 09:29:25 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yf1TH-0000Ag-JC for ged-emacs-devel@m.gmane.org; Mon, 06 Apr 2015 09:29:23 +0200 Original-Received: from localhost ([::1]:38825 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yf1TG-0003EZ-OG for ged-emacs-devel@m.gmane.org; Mon, 06 Apr 2015 03:29:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40447) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yf1TC-0003EI-41 for emacs-devel@gnu.org; Mon, 06 Apr 2015 03:29:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yf1T7-0003oo-3x for emacs-devel@gnu.org; Mon, 06 Apr 2015 03:29:18 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:41258) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yf1T6-0003oe-SF; Mon, 06 Apr 2015 03:29:13 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NMD00000JCBYN00@a-mtaout22.012.net.il>; Mon, 06 Apr 2015 10:29:11 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMD000QJJGMVX10@a-mtaout22.012.net.il>; Mon, 06 Apr 2015 10:29:11 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:185006 Archived-At: > Date: Mon, 06 Apr 2015 01:51:06 -0400 > From: Richard Stallman > 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?