From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Stupid git! Date: Sat, 12 Sep 2015 23:14:03 +0300 Message-ID: <55F4878B.4010803@yandex.ru> References: <20150912101514.GA2322@acm.fritz.box> <55F40103.9080300@yandex.ru> <20150912122900.GC2322@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1442088882 13601 80.91.229.3 (12 Sep 2015 20:14:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Sep 2015 20:14:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 12 22:14:37 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 1ZarC1-0000Pk-DL for ged-emacs-devel@m.gmane.org; Sat, 12 Sep 2015 22:14:37 +0200 Original-Received: from localhost ([::1]:33592 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZarC0-00057P-Kw for ged-emacs-devel@m.gmane.org; Sat, 12 Sep 2015 16:14:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49090) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZarBo-00057C-A7 for emacs-devel@gnu.org; Sat, 12 Sep 2015 16:14:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZarBj-0006dY-0c for emacs-devel@gnu.org; Sat, 12 Sep 2015 16:14:24 -0400 Original-Received: from mail-la0-x22f.google.com ([2a00:1450:4010:c03::22f]:34057) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZarBi-0006dR-Os for emacs-devel@gnu.org; Sat, 12 Sep 2015 16:14:18 -0400 Original-Received: by lahg1 with SMTP id g1so35832568lah.1 for ; Sat, 12 Sep 2015 13:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=GzIPVjr+7TWwJf6hz3N42aN6tFF/NXN4KnZYvMHhYqU=; b=d9grHM6egEmOEoll9BW7voNRL8yc9piIppSSTNkY5sxuTu4WnmULivSrgPC9+IKzcz bwtNQD9cv2SEfe4AKR7AZjdR2ChdPIMuIyPQa3tNvVoKShbiMCIZ7M9gsWIvXT/TaS2b JZ3tNWWhDeMemfY2rz3FDokHK9kyLm710k1fA5jEDKUdHj1eDRZVqaaKZ08iSYBkt+UE 4+eutBJ3bVqOx9+3gdRrbNNyy+hhnFSEsBVU0jaLWCoq5rpH3FB8ljr7X8fWOs/qSjd1 knN+oKz4F3xR4PtM5qm1UqKwK+FfV5qDXxG1EXZy4iubfssi+C9cSHQIgv7cm6kZlQ1g 3dyg== X-Received: by 10.152.6.194 with SMTP id d2mr5083993laa.93.1442088857904; Sat, 12 Sep 2015 13:14:17 -0700 (PDT) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id o1sm1030223lag.22.2015.09.12.13.14.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Sep 2015 13:14:16 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 In-Reply-To: <20150912122900.GC2322@acm.fritz.box> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::22f 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:189873 Archived-At: On 09/12/2015 03:29 PM, Alan Mackenzie wrote: > Sorry, I got confused. I thought I'd only half-committed the change > (with `git add'), whereas I had in fact fully committed it. Then you were simply doing a merge, which is the second step of 'git pull' ('git fetch' + 'git merge'). > It's when first doing `git add', then `git pull' when I've lost changes > before. Is this about some other, older situation? >> The fact that git allows pulling after 'git add' sounds like a bug to >> me, but apparently it sort-of fine because you can do two-way merge, or >> even abort the merge and return to the previous state. > > I've always done a final `git pull' before committing in the past, so as > to avoid merges as far as possible. This is what has lost me changes. That's inadvisable: one is most likely to lose changed by not committing them. Committing before pull is the Git Way. 'git pull --rebase' can also be used if you want cleaner history, but judiciously: if you're absolutely sure that none of the new commits on the current branch have ever been published (pushed to the remote). So don't rebase if you've done any merges, just accept the default behavior of 'git pull'. >> Was there a conflict in this file, or not? If yes, you can see the >> diverging changes. If not, then you don't need to merge it at all, just >> resolve the conflicts. > > There were no conflicts, just the other contributer's changes that my > `git pull' had pulled. Then you didn't need to open it, just needed to resolve any remaining conflicts (in other files), then type 'git commit'. >> How were you even "dumped into an editing session"? What tool did that? > > git did, on my `git pull'. I'm pretty sure Git launches $EDITOR only when asking the user for the commit message. > I think I can see what happened now - when > there's a pending push already committed, git refuses to merge in even > unrelated changes. That's implausible. If you could write a sample scenario step by step using two local repos, one close of another, we'll discuss this further. > Instead it merged the file in my working directory, > leaving me to commit it. I'm not sure why. Maybe you have '--no-commit' somewhere in your .gitconfig. > It's not easy at all - I've got the collected edition of git man pages > in an info file. The one for git diff is 1036 lines long. Why don't you check out the original man page, too? Do you have it installed? > I tried > searching for "index" and "staging", to no avail - I think I stopped the > search after getting beyond the OPTIONS section. Now that I know that > "--cached" is the answer, that is specified in the EXAMPLES section. > "--staged" doesn't appear at all. In my git-diff man page (that comes with Git 2.1.0), the examples section is at the top (it's called DESCRIPTION). The third paragraph both includes the words "staged changes" and "--staged": git diff [--options] --cached [] [--] [...] This form is to view the changes you staged for the next commit relative to the named . Typically you would want comparison with the latest commit, so if you do not give , it defaults to HEAD. If HEAD does not exist (e.g. unborn branches) and is not given, it shows all staged changes. --staged is a synonym of --cached.