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: Tue, 07 Apr 2015 19:48:55 +0300 Message-ID: <83a8yjj348.fsf@gnu.org> References: <86sice77h0.fsf@dod.no> <83iod9lnp0.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1428425370 23263 80.91.229.3 (7 Apr 2015 16:49:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Apr 2015 16:49:30 +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 Tue Apr 07 18:49:21 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 1YfWgi-0001Dp-TX for ged-emacs-devel@m.gmane.org; Tue, 07 Apr 2015 18:49:21 +0200 Original-Received: from localhost ([::1]:46996 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfWgi-0002Fh-9g for ged-emacs-devel@m.gmane.org; Tue, 07 Apr 2015 12:49:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35870) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfWgL-000225-6b for emacs-devel@gnu.org; Tue, 07 Apr 2015 12:48:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YfWgH-0004vN-VM for emacs-devel@gnu.org; Tue, 07 Apr 2015 12:48:57 -0400 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:58285) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfWgH-0004qK-EF; Tue, 07 Apr 2015 12:48:53 -0400 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NMG00A003K5GE00@mtaout24.012.net.il>; Tue, 07 Apr 2015 19:40:17 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMG007OQ3N5LJ20@mtaout24.012.net.il>; Tue, 07 Apr 2015 19:40:17 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.180 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:185088 Archived-At: > Date: Tue, 07 Apr 2015 12:13:53 -0400 > From: Richard Stallman > CC: sb@dod.no, emacs-devel@gnu.org > > > 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.