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: VC mode and git Date: Tue, 07 Apr 2015 20:09:55 +0300 Message-ID: <837ftnj258.fsf@gnu.org> References: <83twx2xoc8.fsf@gnu.org> <551A3F17.6020903@math.ntnu.no> <20150331085055.GA2871@acm.fritz.box> <87zj6tiko1.fsf@uwakimon.sk.tsukuba.ac.jp> <20150331104935.GB2871@acm.fritz.box> <87y4mdi7tj.fsf@uwakimon.sk.tsukuba.ac.jp> <20150331214347.GH2871@acm.fritz.box> <20150401103225.GA2633@acm.fritz.box> <87h9t080gx.fsf@javad.com> <83384jsx3o.fsf@gnu.org> <83pp7nrfdn.fsf@gnu.org> <83a8yqr226.fsf@gnu.org> <831tk2qvz5.fsf@gnu.org> <87384ii26v.fsf@uwakimon.sk.tsukuba.ac.jp> <83wq1tptvp.fsf@gnu.org> <87pp7lhc9h.fsf@uwakimon.sk.tsukuba.ac.jp> <83sichpqe9.fsf@gnu.org> <87ioddglu6.fsf@uwakimon.sk.tsukuba.ac.jp> <83a8yoq56m.fsf@gnu.org> <87384ghm1a.fsf@uwakimon.sk.tsukuba.ac.jp> <837ftspcis.fsf@gnu.org> <551FA115.5090400@gmx.at> <834mowp7cj.fsf@gnu.org> <55200A71.9040902@gmx.at> <83oan3onki.fsf@gnu.org> <55229F01.6030002@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1428426606 12255 80.91.229.3 (7 Apr 2015 17:10:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Apr 2015 17:10:06 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 07 19:09:57 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 1YfX0e-0002N6-MY for ged-emacs-devel@m.gmane.org; Tue, 07 Apr 2015 19:09:56 +0200 Original-Received: from localhost ([::1]:47527 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfX0d-0001oB-U3 for ged-emacs-devel@m.gmane.org; Tue, 07 Apr 2015 13:09:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46158) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfX0a-0001o1-Ai for emacs-devel@gnu.org; Tue, 07 Apr 2015 13:09:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YfX0W-0005r8-3j for emacs-devel@gnu.org; Tue, 07 Apr 2015 13:09:52 -0400 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:53442) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfX0V-0005q0-Nv for emacs-devel@gnu.org; Tue, 07 Apr 2015 13:09:48 -0400 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NMG009004ETV200@mtaout25.012.net.il> for emacs-devel@gnu.org; Tue, 07 Apr 2015 20:05:09 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMG00BLG4SL1200@mtaout25.012.net.il>; Tue, 07 Apr 2015 20:05:09 +0300 (IDT) In-reply-to: <55229F01.6030002@gmx.at> 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.181 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:185094 Archived-At: > Date: Mon, 06 Apr 2015 16:58:09 +0200 > From: martin rudalics > CC: emacs-devel@gnu.org > > A few further comments on the last version of GitQuickStartForEmacsDevs: Thanks. > Optionally, before doing a commit, you can do git status and git diff to > view the changes which will be committed by git commit -a (with no > filename arguments). > > Couldn't we formulate this in a slightly more appealing way? I tried to do that, please take another look. > It is a good idea to examine what you are about to push, before > actually doing so, because fixing mistakes before pushing is much > easier (see the next section). To do that, use the command git diff > origin/master. If you want to show your unpushed commits with their > commit log messages, use git show origin/master.. instead. If you only > have one local commit you want to push, just git show is enough. > > And here I would try to tell that the outputs of plain 'git diff' and > 'git status' are different from their outputs before the commit. In the new version, "git diff" is no longer mentioned, and "git status" was never mentioned before, so do you still think we need to say something about that? > To re-do the commit from scratch, use git reset HEAD^, then fix > whatever needs fixing, and commit again. > > Maybe we should reassure readers here that their changes are not lost > when they do that. Done. > error: Your local changes to the following files would be overwritten by merge: > file1 > Please, commit your changes or stash them before you can merge. > Aborting > > To fix this, commit the offending files with > > Please tell readers here that git does not even try to check whether > their changes would conflict with changes in the upstream repository. > Otherwise, the cited section will confuse readers who expect conflicts > exclusively due to the earlier ... > > This merge could fail due to conflicts between your changes and > changes by others in the same portions of the same files. > > ... in particular the "in the same portions" part. At least I was > initially stupefied by this when it happened the first time. But the full text says this: This merge could fail due to conflicts between your changes and changes by others in the same portions of the same files. The conflicts could be in changes you have already committed locally, or in uncommitted changes. The second sentence refers to uncommitted changes. Is it really important to tell that in this case Git will not even start a merge? How will that help the reader/user when they are in this situation? > In addition, saving any file whose conflicts were completely resolved > (i.e., no conflict markers remain in it) invokes the git add command > on that file, which prepares the file for merging and committing. > > Are we really 100% sure that 'git add' gets executed with all reasonable > user customizations? As long as they didn't remove the Git back-end from the list, yes. > Shouldn't we tell here how our reader can check whether the 'git > add' was really performed? Sounds excessive to me. > (It is recommended to do a git status before a commit without > filename arguments to check for inadvertent changes that would be > committed.) > > Doesn't this come now a bit late in the text given you latest changes? Deleted. Thanks.