From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Steinar Bang Newsgroups: gmane.emacs.devel Subject: Re: VC mode and git Date: Tue, 31 Mar 2015 20:31:49 +0200 Organization: Probably a good idea Message-ID: <86y4mdaui2.fsf@dod.no> References: <838ueezgyk.fsf@gnu.org> <878ueejnjz.fsf@uwakimon.sk.tsukuba.ac.jp> <83twx2xoc8.fsf@gnu.org> <87619hke3u.fsf@uwakimon.sk.tsukuba.ac.jp> <551A3F17.6020903@math.ntnu.no> <20150331085055.GA2871@acm.fritz.box> <87zj6tiko1.fsf@uwakimon.sk.tsukuba.ac.jp> <20150331104935.GB2871@acm.fritz.box> <86ego5cp95.fsf@dod.no> <20150331154839.GE2871@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1427826808 18959 80.91.229.3 (31 Mar 2015 18:33:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 31 Mar 2015 18:33:28 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 31 20:33:14 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 1Yd0y4-0007GC-Ae for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 20:32:52 +0200 Original-Received: from localhost ([::1]:40090 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yd0y3-0007ZC-LO for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 14:32:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yd0xx-0007Uy-F8 for emacs-devel@gnu.org; Tue, 31 Mar 2015 14:32:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yd0xu-0007ri-8A for emacs-devel@gnu.org; Tue, 31 Mar 2015 14:32:45 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:41211) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yd0xt-0007rR-T7 for emacs-devel@gnu.org; Tue, 31 Mar 2015 14:32:42 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Yd0x4-0006eC-Nn for emacs-devel@gnu.org; Tue, 31 Mar 2015 20:31:50 +0200 Original-Received: from cm-84.208.248.210.getinternet.no ([84.208.248.210]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Mar 2015 20:31:50 +0200 Original-Received: from sb by cm-84.208.248.210.getinternet.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Mar 2015 20:31:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 151 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: cm-84.208.248.210.getinternet.no Mail-Copies-To: never User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (windows-nt) Cancel-Lock: sha1:cxUd2XkCEHhHJSLK8qYVWddVzWM= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:184667 Archived-At: >>>>> Alan Mackenzie : > I've never used git reset or a git --force argument. I did lose some > changes, however. I agree with Stephen's assesments here. >> Their fix is to ask you to commit (or stash) before you pull (which is >> fetch followed by merge). > That's a fix? So every time I want to do a pull I have to stash, pull, > unstash. If you want to work with uncommitted changes on a tracking branch, yes. Note: you can always just try a pull first, it will stop if it needs to merge some of the files you have changes in. Ie. with no conflicts betwen pull and your modified files: git pull git commit git push and with conflicts between pull and your modified files: git pull git stash git pull git stash pop git commit git push Or you can just do the stash anyway, even if it's needed or not: git stash git pull git stash pop git commit git push Or: git commit git pull --rebase git push (forgive me, Eli, I said the "r" word...) > Yuck! A proper fix would be for merge to actually merge the new > changes into the working directory. Um... no. I agree with Stephen here also. > Not me. In my normal workflow, I commit at the last minute, then push. > Just before committing, I get the latest changes from savannah, do any > necessary merging, then commit and push as quickly as possible. This is > to minimise the hassle which invariably occurs when other people's > commits get mixed up with my own. Is it really too much to expect that > git merge should merge these new fetched changes into my working > directory? Then either always do this: Or you can just do the stash anyway, even if it's needed or not: git stash git pull git stash pop git commit git push Or, this: git commit git pull --rebase git push >> In short: it can be difficult to know what changes belongs to the merge >> and what were local uncommitted changes prior to the merge. > I don't know what you mean by "the" merge. The merge part of "pull". "git pull" is actually: git fetch git merge origin/master > When one mixes up committing with staging with fetching with pushing, > inevitably there will sometimes be merge operations required all over > the place. Not sure what you mean here. >> One heuristic could be that the unconflicted uncommitted changes don't >> belong to the merge, ... > Sorry, this is ceasing to make sense to me. I can't visualise what > you're trying to say. You have the following modified files in the workspace: ChangeLog a.c b.c c.c d.c and then you modify a.c and c.c and in magit you will see: Unstaged changes: Modified a.c Modified c.c and then you pull, and that results in d.c being succsessfully merged, but ChangeLog failing with a conflict, and in magit it looks like this: Unstaged changes: C Modified ChangeLog Modified a.c Modified c.c Staged changes: Modified d.c (since there was a conflict the merge wasn't completed commit, and there are now many changes unrelated to the merge that could become part of the merge commit) > When there are uncommitted changes and some merge takes place at a > place where these changes are, the changes can't avoid being part of > that merge. Actually, that's what git tries to encourage, either by having you commit your changes before pulling or alternatively, stashing the changes before you pull, and then unstashing them and creating a new commit separate to the merge commit. >> This chapter of "Pro Git", is quite good: >> http://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell > It may be quite good, but it's information density is very low. It's > written for beginners in VCS. Um... it may not be the book for you, but it's not written for beginners in VCS. In fact it requires quite a bit in understanding of data structures. > Every time I read, yet again, that VCSs have the concept of a branch > and what it's used for, my eyes glaze over, and I start subconsciously > skimming the text in the hope of coming across something solid and > useful. To read it you need to read it like you read code examples and think about and visualize what the datastructures look like. It was when I read this (after having used git for a year or so), that git started making sense to me. > The information density in the git-merge man page is low in a > different way: being so vague and imprecise it makes little sense on > its own, because you've got to keep searching externally for > information needed to get meaning out of it. FWIW you're in good company here. I just use them to get the exact command line arguments when I can't remember them.