From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kelvin White Newsgroups: gmane.emacs.devel Subject: Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed? Date: Wed, 27 May 2015 00:21:18 +0000 Message-ID: References: <20150526223928.GA4675@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c12c6ed319af051705380a X-Trace: ger.gmane.org 1432686099 4768 80.91.229.3 (27 May 2015 00:21:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 May 2015 00:21:39 +0000 (UTC) Cc: emacs-devel To: bruce.connor.am@gmail.com, Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 27 02:21:39 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 1YxP6I-0005RG-52 for ged-emacs-devel@m.gmane.org; Wed, 27 May 2015 02:21:38 +0200 Original-Received: from localhost ([::1]:50761 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxP6H-0003ms-AL for ged-emacs-devel@m.gmane.org; Tue, 26 May 2015 20:21:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41709) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxP63-0003mj-0W for emacs-devel@gnu.org; Tue, 26 May 2015 20:21:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YxP5z-0001wc-Ou for emacs-devel@gnu.org; Tue, 26 May 2015 20:21:22 -0400 Original-Received: from mail-qg0-f42.google.com ([209.85.192.42]:35178) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YxP5z-0001wW-Ku for emacs-devel@gnu.org; Tue, 26 May 2015 20:21:19 -0400 Original-Received: by qgg60 with SMTP id 60so19994411qgg.2 for ; Tue, 26 May 2015 17:21:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=jk/qivSUrlGiS9wGp8Xe2EpdBN4hT21aHy/FVhhTw/c=; b=UKNkBwgqGqFffeDRftTK3WWDqqy4xLNxd6E7gH7XKDMNAlTEbv6lI7JCdqZaQCGCrL STNtziThV7oIz5k3SldRaCNqJwvWhn3WDmwqcU4d4MCMAsS3WrcFD5HMcm+KAVLmQRb8 G9KAoSPXDcCjXci4cw31T3JWzxGGv+U80ejz1ACaErstaG5kuEohIgvp7jnkjEW+DBtS t4x/LBmbJrB07R4QMiAFMqw3z92JpsuFJaESqVus29/HnWkmFV8Je2tP06UmsyyB/xPk xloR1UD5rfcQ+j1AANGCpeCSpFQk7WXcc0/Kn8+LOZ3bms4vL3bxCOVEexvxeQDOMx1D P5xQ== X-Received: by 10.140.23.35 with SMTP id 32mr37005111qgo.106.1432686079185; Tue, 26 May 2015 17:21:19 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.192.42 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:186839 Archived-At: --001a11c12c6ed319af051705380a Content-Type: text/plain; charset=UTF-8 "Staged" files are files that have been changed and will be tracked in the future. If you create a new file in a directory under version control, it will be "unstaged". If you `git add ' it will then be "staged". (i.e. added to the commit, and tracked by git). At this point your .gitignore is staged, and future changes will be tracked by git. So, `git reset ' should do the trick, but in any case `git rm --cached ', certainly will. On Tue, May 26, 2015, 7:32 PM Artur Malabarba wrote: > > > git status returns the following obscure "information": > > > > On branch master > > Your branch is up-to-date with 'origin/master'. > > Unmerged paths: > > (use "git reset HEAD ..." to unstage) > > (use "git add ..." to mark resolution) > > > > both modified: .gitignore > > > > . I don't think I want to "unstage" anything (whatever that might > > mean) - IIUC, the suggested recipe would discard all my changes. I think > > I might want to "mark resolution" (assuming this gobbledegook means > > "mark as resolved"), > > Yes. Then you need to commit. > > > but the suggested recipe, as far as I am > > aware, doesn't "mark resolution", instead it moves a file into a list of > > files to be committed in the (?near) future. > > That's the same thing. You git add all the conflict-solved files, and then > commit to finish the merge. I may be missremembering things (been using > Magit for so long I'm slowly forgetting the details), but I'm pretty sure > that's it. :-) > --001a11c12c6ed319af051705380a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

"Staged" files are files that have been changed an= d will be tracked in the future. If you create a new file in a directory un= der version control, it will be "unstaged". If you `git add <f= ile>' it will then be "staged". (i.e. added to the commit,= and tracked by git). At this point your .gitignore is staged, and future c= hanges will be tracked by git. So, `git reset <file>' should do t= he trick, but in any case `git rm --cached <file>', certainly wil= l.


On Tue, May 26, 2015, 7:32 PM=C2=A0Artur Mal= abarba <bruce.connor.am@gma= il.com> wrote:


> git status returns the following obscure "information":
>
> =C2=A0 =C2=A0 On branch master
> =C2=A0 =C2=A0 Your branch is up-to-date with 'origin/master'.<= br> > =C2=A0 =C2=A0 Unmerged paths:
> =C2=A0 =C2=A0 =C2=A0 (use "git reset HEAD <file>..." t= o unstage)
> =C2=A0 =C2=A0 =C2=A0 (use "git add <file>..." to mark = resolution)
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 both modified:=C2=A0 =C2=A0.= gitignore
>
> .=C2=A0 I don't think I want to "unstage" anything (what= ever that might
> mean) - IIUC, the suggested recipe would discard all my changes.=C2=A0= I think
> I might want to "mark resolution" (assuming this gobbledegoo= k means
> "mark <file> as resolved"),

Yes. Then you need to commit.

> but the suggested recipe, as far as I am
> aware, doesn't "mark resolution", instead it moves a fil= e into a list of
> files to be committed in the (?near) future.

That's the same thing. You git add all the conflict-solv= ed files, and then commit to finish the merge. I may be missremembering thi= ngs (been using Magit for so long I'm slowly forgetting the details), b= ut I'm pretty sure that's it. :-)

--001a11c12c6ed319af051705380a--