all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
@ 2015-05-26 22:39 Alan Mackenzie
  2015-05-26 22:43 ` Dmitry Gutov
                   ` (7 more replies)
  0 siblings, 8 replies; 42+ messages in thread
From: Alan Mackenzie @ 2015-05-26 22:39 UTC (permalink / raw)
  To: emacs-devel

Hello, Emacs

It's git misery time again.  :-(

I did a git stash, followed by git merge, followed by git stash pop.
This caused a conflict in .gitignore, which I repaired by editing
that file.

I think (but I'm not sure), I need somehow to tell git that the file has
been fixed.  The git equivalent of 'bzr resolve'.  I can't find any
documentation telling me how to do this, or alternatively that it's not
needed.

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 <file>..." to unstage)
      (use "git add <file>..." 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 <file> as resolved"), 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.

Do I actually need to tell git that the merge conflicts in .gitignore
have been fixed?  If so, how do I do this?  There doesn't appear to be a
'git resolve' command.

Where is this 'bzr resolve' equivalent documented?  I now have git
2.3.6, and it now comes with an info manual, and all its man pages
stuffed into another info document, which is a great improvement.  I
still can't find what I need, though.

Thanks in advance for the help.

-- 
Alan Mackenzie (Nuremberg, Germany).



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-26 22:39 After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed? Alan Mackenzie
@ 2015-05-26 22:43 ` Dmitry Gutov
  2015-05-26 22:48   ` Kelvin White
  2015-05-26 22:44 ` Kelvin White
                   ` (6 subsequent siblings)
  7 siblings, 1 reply; 42+ messages in thread
From: Dmitry Gutov @ 2015-05-26 22:43 UTC (permalink / raw)
  To: Alan Mackenzie, emacs-devel

Hi Alan,

On 05/27/2015 01:39 AM, Alan Mackenzie wrote:
> 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.

It does both.

> Do I actually need to tell git that the merge conflicts in .gitignore
> have been fixed?

Need for what?



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-26 22:39 After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed? Alan Mackenzie
  2015-05-26 22:43 ` Dmitry Gutov
@ 2015-05-26 22:44 ` Kelvin White
  2015-05-26 23:31 ` Artur Malabarba
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 42+ messages in thread
From: Kelvin White @ 2015-05-26 22:44 UTC (permalink / raw)
  To: Alan Mackenzie, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1810 bytes --]

Fix the file then git add it && git commit it to show git it is resolved

On Tue, May 26, 2015, 6:39 PM Alan Mackenzie <acm@muc.de> wrote:

> Hello, Emacs
>
> It's git misery time again.  :-(
>
> I did a git stash, followed by git merge, followed by git stash pop.
> This caused a conflict in .gitignore, which I repaired by editing
> that file.
>
> I think (but I'm not sure), I need somehow to tell git that the file has
> been fixed.  The git equivalent of 'bzr resolve'.  I can't find any
> documentation telling me how to do this, or alternatively that it's not
> needed.
>
> 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 <file>..." to unstage)
>       (use "git add <file>..." 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 <file> as resolved"), 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.
>
> Do I actually need to tell git that the merge conflicts in .gitignore
> have been fixed?  If so, how do I do this?  There doesn't appear to be a
> 'git resolve' command.
>
> Where is this 'bzr resolve' equivalent documented?  I now have git
> 2.3.6, and it now comes with an info manual, and all its man pages
> stuffed into another info document, which is a great improvement.  I
> still can't find what I need, though.
>
> Thanks in advance for the help.
>
> --
> Alan Mackenzie (Nuremberg, Germany).
>
>
>

[-- Attachment #2: Type: text/html, Size: 2355 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-26 22:43 ` Dmitry Gutov
@ 2015-05-26 22:48   ` Kelvin White
  2015-05-26 22:56     ` Alan Mackenzie
  0 siblings, 1 reply; 42+ messages in thread
From: Kelvin White @ 2015-05-26 22:48 UTC (permalink / raw)
  To: Dmitry Gutov, Alan Mackenzie, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 123 bytes --]

Alan,

I missed part of your message, if you've already fixed it in the file, just
git add $FILE && git commit to resolve.

[-- Attachment #2: Type: text/html, Size: 294 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-26 22:48   ` Kelvin White
@ 2015-05-26 22:56     ` Alan Mackenzie
  2015-05-26 23:05       ` Dmitry Gutov
                         ` (4 more replies)
  0 siblings, 5 replies; 42+ messages in thread
From: Alan Mackenzie @ 2015-05-26 22:56 UTC (permalink / raw)
  To: Kelvin White; +Cc: emacs-devel, Dmitry Gutov

Hello, Kelvin.

On Tue, May 26, 2015 at 10:48:43PM +0000, Kelvin White wrote:
> Alan,

> I missed part of your message, if you've already fixed it in the file, just
> git add $FILE && git commit to resolve.

No.  The file is not to be committed.  It is my own personal copy of
.gitignore with my idiosyncratic filenames in it, something I will not
impose upon fellow Emacs hackers.

How do I tell git the conflict has been fixed - not as a part of doing
something else (which must not be done), but as a primitive operation?
This surely must be possible in such a sophisticated SCM tool.

-- 
Alan Mackenzie (Nuremberg, Germany).



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-26 22:56     ` Alan Mackenzie
@ 2015-05-26 23:05       ` Dmitry Gutov
  2015-05-26 23:11         ` Kelvin White
  2015-05-27  0:18       ` Tom Jakubowski
                         ` (3 subsequent siblings)
  4 siblings, 1 reply; 42+ messages in thread
From: Dmitry Gutov @ 2015-05-26 23:05 UTC (permalink / raw)
  To: Alan Mackenzie, Kelvin White; +Cc: emacs-devel

On 05/27/2015 01:56 AM, Alan Mackenzie wrote:

> How do I tell git the conflict has been fixed - not as a part of doing
> something else (which must not be done), but as a primitive operation?
> This surely must be possible in such a sophisticated SCM tool.

'git reset' will also do the trick.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-26 23:05       ` Dmitry Gutov
@ 2015-05-26 23:11         ` Kelvin White
  2015-05-26 23:14           ` Kelvin White
  0 siblings, 1 reply; 42+ messages in thread
From: Kelvin White @ 2015-05-26 23:11 UTC (permalink / raw)
  To: Dmitry Gutov, Alan Mackenzie; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

oh sorry I guess I'm doing too many things at once... git reset file should
do what your looking for.

On Tue, May 26, 2015, 7:06 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 05/27/2015 01:56 AM, Alan Mackenzie wrote:
>
> > How do I tell git the conflict has been fixed - not as a part of doing
> > something else (which must not be done), but as a primitive operation?
> > This surely must be possible in such a sophisticated SCM tool.
>
> 'git reset' will also do the trick.
>
>

[-- Attachment #2: Type: text/html, Size: 746 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-26 23:11         ` Kelvin White
@ 2015-05-26 23:14           ` Kelvin White
       [not found]             ` <CAG-q9=aSF+6AcR1SHRgCTQLUrKXB5OEzPcbuV8M5+VEacxZc0g@mail.gmail.com>
  0 siblings, 1 reply; 42+ messages in thread
From: Kelvin White @ 2015-05-26 23:14 UTC (permalink / raw)
  To: Dmitry Gutov, Alan Mackenzie; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 121 bytes --]

Alan,

also look at this...

http://stackoverflow.com/questions/936249/stop-tracking-and-ignore-changes-to-a-file-in-git

[-- Attachment #2: Type: text/html, Size: 346 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
       [not found]             ` <CAG-q9=aSF+6AcR1SHRgCTQLUrKXB5OEzPcbuV8M5+VEacxZc0g@mail.gmail.com>
@ 2015-05-26 23:19               ` Kelvin White
  0 siblings, 0 replies; 42+ messages in thread
From: Kelvin White @ 2015-05-26 23:19 UTC (permalink / raw)
  To: Emacs development discussions

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

Apologies, I'm using gmail on my mobile and it's not cutting me any slack
at the moment

---------- Forwarded message ---------
From: Kelvin White <kwhite@gnu.org>
Date: Tue, May 26, 2015, 7:17 PM
Subject: Re: After a git merge and manual correction of a conflict, how do
I tell git the conflict is fixed?
To: Dmitry Gutov <dgutov@yandex.ru>, Alan Mackenzie <acm@muc.de>


This tidbit here I think is the part you want I think...

"git rm --cached <file>" would remove <file> from version control, while
keeping it in the working repository.

On Tue, May 26, 2015, 7:14 PM Kelvin White <kwhite@gnu.org> wrote:

> Alan,
>
> also look at this...
>
>
> http://stackoverflow.com/questions/936249/stop-tracking-and-ignore-changes-to-a-file-in-git
>
>

[-- Attachment #2: Type: text/html, Size: 1459 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-26 22:39 After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed? Alan Mackenzie
  2015-05-26 22:43 ` Dmitry Gutov
  2015-05-26 22:44 ` Kelvin White
@ 2015-05-26 23:31 ` Artur Malabarba
  2015-05-27  0:21   ` Kelvin White
  2015-05-27  0:56 ` Kelvin White
                   ` (4 subsequent siblings)
  7 siblings, 1 reply; 42+ messages in thread
From: Artur Malabarba @ 2015-05-26 23:31 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

> 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 <file>..." to unstage)
>       (use "git add <file>..." 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 <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 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. :-)

[-- Attachment #2: Type: text/html, Size: 1332 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-26 22:56     ` Alan Mackenzie
  2015-05-26 23:05       ` Dmitry Gutov
@ 2015-05-27  0:18       ` Tom Jakubowski
  2015-05-27  2:38       ` Eli Zaretskii
                         ` (2 subsequent siblings)
  4 siblings, 0 replies; 42+ messages in thread
From: Tom Jakubowski @ 2015-05-27  0:18 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

Alan,






On Tuesday, May 26, 2015 at 15:56, Alan Mackenzie <acm@muc.de>, wrote:

No.  The file is not to be committed.  It is my own personal copy of

.gitignore with my idiosyncratic filenames in it, something I will not

impose upon fellow Emacs hackers.




​

​You might like to know about the git "exclude" file. It is a local, per-clone file that lives in .git/info from the root of the repository's directory tree. The syntax of the file are the same as .gitignore, and it has the same effect with regards to making files unknown to git, but since it's a per-clone file you don't have to worry about accidentally committing your own private changes and pushing them to someone else.

​

​See https://help.github.com/articles/ignoring-files/ for more information. The "global gitignore" section of that page is also a very nice tip. 

​

​Regards,

​

​Tom Jakubowski




​P.S. I've sent this from a mobile email client which does not seem to like the idea of bottom posting. I hope this message didn't come out terribly mangled.

[-- Attachment #2: Type: text/html, Size: 2399 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-26 23:31 ` Artur Malabarba
@ 2015-05-27  0:21   ` Kelvin White
  2015-05-27  0:29     ` Dmitry Gutov
  0 siblings, 1 reply; 42+ messages in thread
From: Kelvin White @ 2015-05-27  0:21 UTC (permalink / raw)
  To: bruce.connor.am, Alan Mackenzie; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]

"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 <file>' 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 <file>'
should do the trick, but in any case `git rm --cached <file>', certainly
will.

On Tue, May 26, 2015, 7:32 PM Artur Malabarba <bruce.connor.am@gmail.com>
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 <file>..." to unstage)
> >       (use "git add <file>..." 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 <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 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. :-)
>

[-- Attachment #2: Type: text/html, Size: 2153 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27  0:21   ` Kelvin White
@ 2015-05-27  0:29     ` Dmitry Gutov
  2015-05-27  0:36       ` Kelvin White
  0 siblings, 1 reply; 42+ messages in thread
From: Dmitry Gutov @ 2015-05-27  0:29 UTC (permalink / raw)
  To: Kelvin White, bruce.connor.am, Alan Mackenzie; +Cc: emacs-devel

On 05/27/2015 03:21 AM, Kelvin White wrote:
> but in any case `git rm --cached <file>', certainly will.

Have you tried it?

That will stage the file for removal, which is almost certainly not what 
one would want.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27  0:29     ` Dmitry Gutov
@ 2015-05-27  0:36       ` Kelvin White
  2015-05-27  0:38         ` Dmitry Gutov
  0 siblings, 1 reply; 42+ messages in thread
From: Kelvin White @ 2015-05-27  0:36 UTC (permalink / raw)
  To: Dmitry Gutov, bruce.connor.am, Alan Mackenzie; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

On Tue, May 26, 2015, 8:30 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

On 05/27/2015 03:21 AM, Kelvin White wrote:
> but in any case `git rm --cached <file>', certainly will.

Have you tried it?

 Yes actually, I did try it.


That will stage the file for removal, which is almost certainly not what
one would want.

 I created a new file in a directory under git version control, staged it
with `git add <file>', them unstaged it with `git rm --cached <file>'. This
is the same behavior you'd expect in this situation.

[-- Attachment #2: Type: text/html, Size: 921 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27  0:36       ` Kelvin White
@ 2015-05-27  0:38         ` Dmitry Gutov
  2015-05-27  0:45           ` Kelvin White
  0 siblings, 1 reply; 42+ messages in thread
From: Dmitry Gutov @ 2015-05-27  0:38 UTC (permalink / raw)
  To: Kelvin White, bruce.connor.am, Alan Mackenzie; +Cc: emacs-devel

On 05/27/2015 03:36 AM, Kelvin White wrote:

> I created a new file in a directory under git version control, staged it
> with `git add <file>', them unstaged it with `git rm --cached <file>'.
> This is the same behavior you'd expect in this situation.

Well, it's not the same situation as what Alan has with .gitignore.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27  0:38         ` Dmitry Gutov
@ 2015-05-27  0:45           ` Kelvin White
  2015-05-27  0:56             ` Dmitry Gutov
  0 siblings, 1 reply; 42+ messages in thread
From: Kelvin White @ 2015-05-27  0:45 UTC (permalink / raw)
  To: Dmitry Gutov, bruce.connor.am, Alan Mackenzie; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

 On Tue, May 26, 2015, 8:39 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

On 05/27/2015 03:36 AM, Kelvin White wrote:

> I created a new file in a directory under git version control, staged it
> with `git add <file>', them unstaged it with `git rm --cached <file>'.
> This is the same behavior you'd expect in this situation.

Well, it's not the same situation as what Alan has with .gitignore.


Indeed it is. Unstage the file, commit and move on...
If I'm missing something, I apologize in advance, but please explain.

[-- Attachment #2: Type: text/html, Size: 815 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-26 22:39 After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed? Alan Mackenzie
                   ` (2 preceding siblings ...)
  2015-05-26 23:31 ` Artur Malabarba
@ 2015-05-27  0:56 ` Kelvin White
  2015-05-27  1:02 ` Dmitry Gutov
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 42+ messages in thread
From: Kelvin White @ 2015-05-27  0:56 UTC (permalink / raw)
  To: Alan Mackenzie, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

 On Tue, May 26, 2015, 6:39 PM Alan Mackenzie <acm@muc.de> wrote:


    On branch master
    Your branch is up-to-date with 'origin/master'.
    Unmerged paths:
      (use "git reset HEAD <file>..." to unstage)
      (use "git add <file>..." to mark resolution)

            both modified:   .gitignore


I don't think I want to "unstage" anything ...
Yes you do, unless you want the future changes to this file tracked by git
in future

[-- Attachment #2: Type: text/html, Size: 830 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27  0:45           ` Kelvin White
@ 2015-05-27  0:56             ` Dmitry Gutov
  2015-05-27  1:55               ` Kelvin White
  0 siblings, 1 reply; 42+ messages in thread
From: Dmitry Gutov @ 2015-05-27  0:56 UTC (permalink / raw)
  To: Kelvin White, bruce.connor.am, Alan Mackenzie; +Cc: emacs-devel

On 05/27/2015 03:45 AM, Kelvin White wrote:

> If I'm missing something, I apologize in advance, but please explain.

.gitignore is already registered in the repository. 'git rm --cached && 
git commit' would commit its deletion (even though the file would remain 
on disk because of '--cached').

The 'git rm' part should be self-evident, isn't it?



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-26 22:39 After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed? Alan Mackenzie
                   ` (3 preceding siblings ...)
  2015-05-27  0:56 ` Kelvin White
@ 2015-05-27  1:02 ` Dmitry Gutov
  2015-05-27  1:40 ` Stefan Monnier
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 42+ messages in thread
From: Dmitry Gutov @ 2015-05-27  1:02 UTC (permalink / raw)
  To: Alan Mackenzie, emacs-devel

On 05/27/2015 01:39 AM, Alan Mackenzie wrote:
> I don't think I want to "unstage" anything (whatever that might
> mean) - IIUC, the suggested recipe would discard all my changes.

No, it won't. It will just remove them from the staging area.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-26 22:39 After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed? Alan Mackenzie
                   ` (4 preceding siblings ...)
  2015-05-27  1:02 ` Dmitry Gutov
@ 2015-05-27  1:40 ` Stefan Monnier
  2015-05-27  1:52   ` Kelvin White
  2015-05-27  2:37 ` Eli Zaretskii
  2015-05-27 19:46 ` Steinar Bang
  7 siblings, 1 reply; 42+ messages in thread
From: Stefan Monnier @ 2015-05-27  1:40 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

>     On branch master
>     Your branch is up-to-date with 'origin/master'.
>     Unmerged paths:
>       (use "git reset HEAD <file>..." to unstage)
>       (use "git add <file>..." to mark resolution)

>             both modified:   .gitignore

You want:

    git reset .gitignore

This will not change the file itself, but it will mark the conflict as
resolved, and it will not record the changes in the staging area
(i.e. it will keep it as a local change that you don't intend to commit
soon).


        Stefan "who has the same kind of situation"


PS: Instead of modifying the .gitignore file, you might like to add your
own idiosyncratic glob patterns to either .git/info/exclude or to
~/.config/git/ignore.  See "git ignore --help".  In my case I change
.gitignore to remove the "*.rej" pattern in it, which I can't do via
~/.config/git/ignore or .git/info/exclude, but it sounds like in your
case it should work.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27  1:40 ` Stefan Monnier
@ 2015-05-27  1:52   ` Kelvin White
  2015-05-27  2:40     ` Stefan Monnier
  0 siblings, 1 reply; 42+ messages in thread
From: Kelvin White @ 2015-05-27  1:52 UTC (permalink / raw)
  To: Stefan Monnier, Alan Mackenzie; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

 On Tue, May 26, 2015, 9:41 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

>     On branch master
>     Your branch is up-to-date with 'origin/master'.
>     Unmerged paths:
>       (use "git reset HEAD <file>..." to unstage)
>       (use "git add <file>..." to mark resolution)

>             both modified:   .gitignore

You want:

    git reset .gitignore

This will not change the file itself, but it will mark the conflict as
resolved, and it will not record the changes in the staging area
(i.e. it will keep it as a local change that you don't intend to commit
soon).

        Stefan "who has the same kind of situation"

PS: Instead of modifying the .gitignore file, you might like to add your
own idiosyncratic glob patterns to either .git/info/exclude or to
~/.config/git/ignore.  See "git ignore --help".  In my case I change
.gitignore to remove the "*.rej" pattern in it, which I can't do via
~/.config/git/ignore or .git/info/exclude, but it sounds like in your
case it should work.

 Which will have the exact same effects as `git rm --cached <file>' no?

[-- Attachment #2: Type: text/html, Size: 1586 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27  0:56             ` Dmitry Gutov
@ 2015-05-27  1:55               ` Kelvin White
  2015-05-27  1:57                 ` Kelvin White
  0 siblings, 1 reply; 42+ messages in thread
From: Kelvin White @ 2015-05-27  1:55 UTC (permalink / raw)
  To: Dmitry Gutov, bruce.connor.am, Alan Mackenzie; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

 On Tue, May 26, 2015, 8:58 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

On 05/27/2015 03:45 AM, Kelvin White wrote:

> If I'm missing something, I apologize in advance, but please explain.

.gitignore is already registered in the repository. 'git rm --cached &&
git commit' would commit its deletion (even though the file would remain
on disk because of '--cached').

The 'git rm' part should be self-evident, isn't it?


No, not with " --cached ". It only removes the file from the git "cache"
(i.e. staging area)

[-- Attachment #2: Type: text/html, Size: 841 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27  1:55               ` Kelvin White
@ 2015-05-27  1:57                 ` Kelvin White
  2015-05-27  2:02                   ` Dmitry Gutov
  0 siblings, 1 reply; 42+ messages in thread
From: Kelvin White @ 2015-05-27  1:57 UTC (permalink / raw)
  To: Dmitry Gutov, bruce.connor.am, Alan Mackenzie
  Cc: Emacs development discussions

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

 On Tue, May 26, 2015, 9:55 PM Kelvin White <kwhite@gnu.org> wrote:


On Tue, May 26, 2015, 8:58 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

On 05/27/2015 03:45 AM, Kelvin White wrote:

> If I'm missing something, I apologize in advance, but please explain.

.gitignore is already registered in the repository. 'git rm --cached &&
git commit' would commit its deletion (even though the file would remain
on disk because of '--cached').

The 'git rm' part should be self-evident, isn't it?

 No, not with " --cached ". It only removes the file from the git "cache"
(i.e. staging area)


 Maybe this can clarify my point better.

http://stackoverflow.com/questions/5798930/git-rm-cached-x-vs-git-reset-head-x

[-- Attachment #2: Type: text/html, Size: 1317 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27  1:57                 ` Kelvin White
@ 2015-05-27  2:02                   ` Dmitry Gutov
  2015-05-27  2:23                     ` Kelvin White
  0 siblings, 1 reply; 42+ messages in thread
From: Dmitry Gutov @ 2015-05-27  2:02 UTC (permalink / raw)
  To: Kelvin White, bruce.connor.am, Alan Mackenzie
  Cc: Emacs development discussions

On 05/27/2015 04:57 AM, Kelvin White wrote:

> Maybe this can clarify my point better.
>
> http://stackoverflow.com/questions/5798930/git-rm-cached-x-vs-git-reset-head-x

This is the last sentence in the top answer:

"""
A commit now will sync the index and tree and the file will be removed.
"""



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27  2:02                   ` Dmitry Gutov
@ 2015-05-27  2:23                     ` Kelvin White
  0 siblings, 0 replies; 42+ messages in thread
From: Kelvin White @ 2015-05-27  2:23 UTC (permalink / raw)
  To: Dmitry Gutov, bruce.connor.am, Alan Mackenzie
  Cc: Emacs development discussions

[-- Attachment #1: Type: text/plain, Size: 439 bytes --]

Yes, from version control but not locally.

On Tue, May 26, 2015 at 10:03 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 05/27/2015 04:57 AM, Kelvin White wrote:
>
> > Maybe this can clarify my point better.
> >
> >
> http://stackoverflow.com/questions/5798930/git-rm-cached-x-vs-git-reset-head-x
>
> This is the last sentence in the top answer:
>
> """
> A commit now will sync the index and tree and the file will be removed.
> """
>
>

[-- Attachment #2: Type: text/html, Size: 844 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-26 22:39 After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed? Alan Mackenzie
                   ` (5 preceding siblings ...)
  2015-05-27  1:40 ` Stefan Monnier
@ 2015-05-27  2:37 ` Eli Zaretskii
  2015-05-27 15:47   ` Alan Mackenzie
  2015-05-27 19:46 ` Steinar Bang
  7 siblings, 1 reply; 42+ messages in thread
From: Eli Zaretskii @ 2015-05-27  2:37 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

> Date: Tue, 26 May 2015 22:39:28 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> Where is this 'bzr resolve' equivalent documented?

In your situation, the equivalent is "git reset .gitignore".



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-26 22:56     ` Alan Mackenzie
  2015-05-26 23:05       ` Dmitry Gutov
  2015-05-27  0:18       ` Tom Jakubowski
@ 2015-05-27  2:38       ` Eli Zaretskii
  2015-05-27  8:17       ` Andreas Schwab
  2015-05-27 19:53       ` Steinar Bang
  4 siblings, 0 replies; 42+ messages in thread
From: Eli Zaretskii @ 2015-05-27  2:38 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: dgutov, kwhite, emacs-devel

> Date: Tue, 26 May 2015 22:56:41 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org, Dmitry Gutov <dgutov@yandex.ru>
> 
> How do I tell git the conflict has been fixed - not as a part of doing
> something else (which must not be done), but as a primitive operation?
> This surely must be possible in such a sophisticated SCM tool.

Either "git add FILE" or "git reset FILE".  In your case, the latter,
because you don't want to commit your local changes yet.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27  1:52   ` Kelvin White
@ 2015-05-27  2:40     ` Stefan Monnier
  2015-05-27  2:55       ` Kelvin White
  0 siblings, 1 reply; 42+ messages in thread
From: Stefan Monnier @ 2015-05-27  2:40 UTC (permalink / raw)
  To: Kelvin White; +Cc: Alan Mackenzie, emacs-devel

>  Which will have the exact same effects as `git rm --cached <file>' no?

Not at all.  "git rm ..." will remove the file from the repository,
i.e. it will have an effect for *everyone else*.


        Stefan



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27  2:40     ` Stefan Monnier
@ 2015-05-27  2:55       ` Kelvin White
  2015-05-27  3:14         ` Kelvin White
  2015-05-28  6:30         ` Steinar Bang
  0 siblings, 2 replies; 42+ messages in thread
From: Kelvin White @ 2015-05-27  2:55 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Alan Mackenzie, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

On Tue, May 26, 2015 at 10:40 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> >  Which will have the exact same effects as `git rm --cached <file>' no?
>
> Not at all.  "git rm ..." will remove the file from the repository,
> i.e. it will have an effect for *everyone else*.
>
>
>         Stefan
>
>
Forgive me, but I think the confusion here is due to the fact that `git
reset <file>' will remove it from the curennt index, while `git rm --cache
<file>' will remove it from the repository completely, while leaving the
current local copy in tact.

[-- Attachment #2: Type: text/html, Size: 884 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27  2:55       ` Kelvin White
@ 2015-05-27  3:14         ` Kelvin White
  2015-05-27  3:16           ` Kelvin White
  2015-05-27 10:12           ` Dmitry Gutov
  2015-05-28  6:30         ` Steinar Bang
  1 sibling, 2 replies; 42+ messages in thread
From: Kelvin White @ 2015-05-27  3:14 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Alan Mackenzie, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 2519 bytes --]

On Tue, May 26, 2015 at 10:55 PM Kelvin White <kwhite@gnu.org> wrote:

> On Tue, May 26, 2015 at 10:40 PM Stefan Monnier <monnier@iro.umontreal.ca>
> wrote:
>
>> >  Which will have the exact same effects as `git rm --cached <file>' no?
>>
>> Not at all.  "git rm ..." will remove the file from the repository,
>> i.e. it will have an effect for *everyone else*.
>>
>>
>>         Stefan
>>
>>
> Forgive me, but I think the confusion here is due to the fact that `git
> reset <file>' will remove it from the curennt index, while `git rm --cache
> <file>' will remove it from the repository completely, while leaving the
> current local copy in tact.
>

In this case, this is exactly what you would want. Why would you want to
keep this file in version control for everyone else? Consider this...

l3thal@dev ~/src/emacs-dev $ git checkout -b test
Switched to a new branch 'test'
l3thal@dev ~/src/emacs-dev $ echo "moo" >> test_file
l3thal@dev ~/src/emacs-dev $ git status
# On branch test
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
# test_file
nothing added to commit but untracked files present (use "git add" to track)
l3thal@dev ~/src/emacs-dev $ git add test_file
l3thal@dev ~/src/emacs-dev $ git status
# On branch test
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# new file:   test_file
#
l3thal@dev ~/src/emacs-dev $ git commit -m "adding test file"
[test dde69ae] adding test file
 1 file changed, 2 insertions(+)
 create mode 100644 test_file
l3thal@dev ~/src/emacs-dev $ git status
# On branch test
nothing to commit, working directory clean
l3thal@dev ~/src/emacs-dev $ git rm --cached test_file
rm 'test_file'
l3thal@dev ~/src/emacs-dev $ git status
# On branch test
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# deleted:    test_file
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
# test_file
l3thal@dev ~/src/emacs-dev $ git commit -am "removing test file"
[test 46f7f53] removing test file
 1 file changed, 2 deletions(-)
 delete mode 100644 new_file
l3thal@dev ~/src/emacs-dev $ git status
# On branch test
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
# new_file
nothing added to commit but untracked files present (use "git add" to track)

This is the same situation as a merge conflict in a file that you dont want
to keep in the remote git repo.. You need to remove it from the index and
keep it locally.

[-- Attachment #2: Type: text/html, Size: 4130 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27  3:14         ` Kelvin White
@ 2015-05-27  3:16           ` Kelvin White
  2015-05-27 10:12           ` Dmitry Gutov
  1 sibling, 0 replies; 42+ messages in thread
From: Kelvin White @ 2015-05-27  3:16 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Alan Mackenzie, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 2722 bytes --]

On Tue, May 26, 2015 at 11:14 PM Kelvin White <kwhite@gnu.org> wrote:

> On Tue, May 26, 2015 at 10:55 PM Kelvin White <kwhite@gnu.org> wrote:
>
>> On Tue, May 26, 2015 at 10:40 PM Stefan Monnier <monnier@iro.umontreal.ca>
>> wrote:
>>
>>> >  Which will have the exact same effects as `git rm --cached <file>' no?
>>>
>>> Not at all.  "git rm ..." will remove the file from the repository,
>>> i.e. it will have an effect for *everyone else*.
>>>
>>>
>>>         Stefan
>>>
>>>
>> Forgive me, but I think the confusion here is due to the fact that `git
>> reset <file>' will remove it from the curennt index, while `git rm --cache
>> <file>' will remove it from the repository completely, while leaving the
>> current local copy in tact.
>>
>
> In this case, this is exactly what you would want. Why would you want to
> keep this file in version control for everyone else? Consider this...
>
> l3thal@dev ~/src/emacs-dev $ git checkout -b test
> Switched to a new branch 'test'
> l3thal@dev ~/src/emacs-dev $ echo "moo" >> test_file
> l3thal@dev ~/src/emacs-dev $ git status
> # On branch test
> # Untracked files:
> #   (use "git add <file>..." to include in what will be committed)
> #
> # test_file
> nothing added to commit but untracked files present (use "git add" to
> track)
> l3thal@dev ~/src/emacs-dev $ git add test_file
> l3thal@dev ~/src/emacs-dev $ git status
> # On branch test
> # Changes to be committed:
> #   (use "git reset HEAD <file>..." to unstage)
> #
> # new file:   test_file
> #
> l3thal@dev ~/src/emacs-dev $ git commit -m "adding test file"
> [test dde69ae] adding test file
>  1 file changed, 2 insertions(+)
>  create mode 100644 test_file
> l3thal@dev ~/src/emacs-dev $ git status
> # On branch test
> nothing to commit, working directory clean
> l3thal@dev ~/src/emacs-dev $ git rm --cached test_file
> rm 'test_file'
> l3thal@dev ~/src/emacs-dev $ git status
> # On branch test
> # Changes to be committed:
> #   (use "git reset HEAD <file>..." to unstage)
> #
> # deleted:    test_file
> #
> # Untracked files:
> #   (use "git add <file>..." to include in what will be committed)
> #
> # test_file
> l3thal@dev ~/src/emacs-dev $ git commit -am "removing test file"
> [test 46f7f53] removing test file
>  1 file changed, 2 deletions(-)
>  delete mode 100644 test_file
> l3thal@dev ~/src/emacs-dev $ git status
> # On branch test
> # Untracked files:
> #   (use "git add <file>..." to include in what will be committed)
> #
> # test_file
> nothing added to commit but untracked files present (use "git add" to
> track)
>

This is the same situation as a merge conflict in a file that you dont want
to keep in the remote git repo.. You need to remove it from the index and
keep it locally.

[-- Attachment #2: Type: text/html, Size: 4556 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-26 22:56     ` Alan Mackenzie
                         ` (2 preceding siblings ...)
  2015-05-27  2:38       ` Eli Zaretskii
@ 2015-05-27  8:17       ` Andreas Schwab
  2015-05-27 19:53       ` Steinar Bang
  4 siblings, 0 replies; 42+ messages in thread
From: Andreas Schwab @ 2015-05-27  8:17 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: Dmitry Gutov, Kelvin White, emacs-devel

Alan Mackenzie <acm@muc.de> writes:

> It is my own personal copy of .gitignore

Don't.  Use .git/info/exclude.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27  3:14         ` Kelvin White
  2015-05-27  3:16           ` Kelvin White
@ 2015-05-27 10:12           ` Dmitry Gutov
  2015-05-27 11:26             ` Kelvin White
  1 sibling, 1 reply; 42+ messages in thread
From: Dmitry Gutov @ 2015-05-27 10:12 UTC (permalink / raw)
  To: Kelvin White, Stefan Monnier; +Cc: Alan Mackenzie, emacs-devel

On 05/27/2015 06:14 AM, Kelvin White wrote:

> In this case, this is exactly what you would want. Why would you want to
> keep this file in version control for everyone else?

Because the contents of .gitignore are valuable, and we don't want 
everyone to bother with recreating it.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27 10:12           ` Dmitry Gutov
@ 2015-05-27 11:26             ` Kelvin White
  2015-05-27 11:34               ` Dmitry Gutov
  0 siblings, 1 reply; 42+ messages in thread
From: Kelvin White @ 2015-05-27 11:26 UTC (permalink / raw)
  To: Dmitry Gutov, Stefan Monnier; +Cc: Alan Mackenzie, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 455 bytes --]

On Wed, May 27, 2015, 6:13 AM Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 05/27/2015 06:14 AM, Kelvin White wrote:
>
> > In this case, this is exactly what you would want. Why would you want to
> > keep this file in version control for everyone else?
>
> Because the contents of .gitignore are valuable, and we don't want
> everyone to bother with recreating it.
>
> This should not remove it from someone's local working copy, only from the
repository.

[-- Attachment #2: Type: text/html, Size: 735 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27 11:26             ` Kelvin White
@ 2015-05-27 11:34               ` Dmitry Gutov
  2015-05-27 12:36                 ` Kelvin White
  0 siblings, 1 reply; 42+ messages in thread
From: Dmitry Gutov @ 2015-05-27 11:34 UTC (permalink / raw)
  To: Kelvin White, Stefan Monnier; +Cc: Alan Mackenzie, emacs-devel

On 05/27/2015 02:26 PM, Kelvin White wrote:

> This should not remove it from someone's local working copy, only from
> the repository.

It'll be removed from everyone else's working directories next time they 
do a pull.

Why are we still discussing this? 'git rm --cached' is obviously not the 
right solution.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27 11:34               ` Dmitry Gutov
@ 2015-05-27 12:36                 ` Kelvin White
  2015-05-27 12:48                   ` Dmitry Gutov
  0 siblings, 1 reply; 42+ messages in thread
From: Kelvin White @ 2015-05-27 12:36 UTC (permalink / raw)
  To: Dmitry Gutov, Stefan Monnier; +Cc: Alan Mackenzie, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

On Wed, May 27, 2015 at 7:34 AM Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 05/27/2015 02:26 PM, Kelvin White wrote:
>
> > This should not remove it from someone's local working copy, only from
> > the repository.
>
> It'll be removed from everyone else's working directories next time they
> do a pull.
>
> Why are we still discussing this? 'git rm --cached' is obviously not the
> right solution.


>
Because I think you are misunderstanding that the file will only be removed
locally, from another persons working directory had that file been tracked
before. If this is a new file, that hasn't been tracked and you don't want
it tracked, Then this _is_ the obvious solution.

[-- Attachment #2: Type: text/html, Size: 1095 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27 12:36                 ` Kelvin White
@ 2015-05-27 12:48                   ` Dmitry Gutov
  0 siblings, 0 replies; 42+ messages in thread
From: Dmitry Gutov @ 2015-05-27 12:48 UTC (permalink / raw)
  To: Kelvin White, Stefan Monnier; +Cc: Alan Mackenzie, emacs-devel

On 05/27/2015 03:36 PM, Kelvin White wrote:

> Because I think you are misunderstanding that the file will only be
> removed locally, from another persons working directory had that file
> been tracked before.

No misunderstanding from me here. Note, however, that 'git reset' would 
work just as well for a previously-untracked file.

> If this is a new file, that hasn't been tracked and
> you don't want it tracked, Then this _is_ the obvious solution.

Like already mentioned, the file in question, .gitignore, is already 
tracked in the Emacs repository.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27  2:37 ` Eli Zaretskii
@ 2015-05-27 15:47   ` Alan Mackenzie
  0 siblings, 0 replies; 42+ messages in thread
From: Alan Mackenzie @ 2015-05-27 15:47 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

Hello, Eli.

On Wed, May 27, 2015 at 05:37:15AM +0300, Eli Zaretskii wrote:
> > Date: Tue, 26 May 2015 22:39:28 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > Where is this 'bzr resolve' equivalent documented?

> In your situation, the equivalent is "git reset .gitignore".

Thanks.  That's exactly what I've done, and it worked fine.

-- 
Alan Mackenzie (Nuremberg, Germany).



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-26 22:39 After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed? Alan Mackenzie
                   ` (6 preceding siblings ...)
  2015-05-27  2:37 ` Eli Zaretskii
@ 2015-05-27 19:46 ` Steinar Bang
  7 siblings, 0 replies; 42+ messages in thread
From: Steinar Bang @ 2015-05-27 19:46 UTC (permalink / raw)
  To: emacs-devel

>>>>> Alan Mackenzie <acm@muc.de>:

> I did a git stash, followed by git merge, followed by git stash pop.
> This caused a conflict in .gitignore, which I repaired by editing
> that file.

> I think (but I'm not sure), I need somehow to tell git that the file has
> been fixed.

 git add .gitignore

If that was the only conflict, then
 git commit
(just use the default message that will pop up in the editor you've set
 in the EDITOR environment variable)

After that, if you wish to immediately publish your merge:
 git push




^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-26 22:56     ` Alan Mackenzie
                         ` (3 preceding siblings ...)
  2015-05-27  8:17       ` Andreas Schwab
@ 2015-05-27 19:53       ` Steinar Bang
  2015-05-28  5:27         ` Yuri Khan
  4 siblings, 1 reply; 42+ messages in thread
From: Steinar Bang @ 2015-05-27 19:53 UTC (permalink / raw)
  To: emacs-devel

>>>>> Alan Mackenzie <acm@muc.de>:

> No.  The file is not to be committed.  It is my own personal copy of
> .gitignore with my idiosyncratic filenames in it, something I will not
> impose upon fellow Emacs hackers.

Not an answer to your question, but git has a different mechanism for
ignoring files, that is kept local only, and not shared with anyone
else.

I ignore files that way with 'I' in magit (as opposed to 'i' which puts
it in .gitignore), so I don't actually know the git command to do so,
but the ignores end up in
 .git/info/exclude
(which is a text file that can be opened and edited in emacs)




^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27 19:53       ` Steinar Bang
@ 2015-05-28  5:27         ` Yuri Khan
  0 siblings, 0 replies; 42+ messages in thread
From: Yuri Khan @ 2015-05-28  5:27 UTC (permalink / raw)
  To: Emacs developers

On Thu, May 28, 2015 at 1:53 AM, Steinar Bang <sb@dod.no> wrote:

> I ignore files that way with 'I' in magit (as opposed to 'i' which puts
> it in .gitignore), so I don't actually know the git command to do so,
> but the ignores end up in
>  .git/info/exclude
> (which is a text file that can be opened and edited in emacs)

As far as I can tell, Git doesn’t have a dedicated command to
manipulate gitignore files. The user is supposed to edit them
directly.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?
  2015-05-27  2:55       ` Kelvin White
  2015-05-27  3:14         ` Kelvin White
@ 2015-05-28  6:30         ` Steinar Bang
  1 sibling, 0 replies; 42+ messages in thread
From: Steinar Bang @ 2015-05-28  6:30 UTC (permalink / raw)
  To: emacs-devel

>>>>> Kelvin White <kwhite@gnu.org>:

> Forgive me, but I think the confusion here is due to the fact that
> `git reset <file>' will remove it from the curennt index,

(I think it is less confusing to say: unstage it from commit)




^ permalink raw reply	[flat|nested] 42+ messages in thread

end of thread, other threads:[~2015-05-28  6:30 UTC | newest]

Thread overview: 42+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-05-26 22:39 After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed? Alan Mackenzie
2015-05-26 22:43 ` Dmitry Gutov
2015-05-26 22:48   ` Kelvin White
2015-05-26 22:56     ` Alan Mackenzie
2015-05-26 23:05       ` Dmitry Gutov
2015-05-26 23:11         ` Kelvin White
2015-05-26 23:14           ` Kelvin White
     [not found]             ` <CAG-q9=aSF+6AcR1SHRgCTQLUrKXB5OEzPcbuV8M5+VEacxZc0g@mail.gmail.com>
2015-05-26 23:19               ` Kelvin White
2015-05-27  0:18       ` Tom Jakubowski
2015-05-27  2:38       ` Eli Zaretskii
2015-05-27  8:17       ` Andreas Schwab
2015-05-27 19:53       ` Steinar Bang
2015-05-28  5:27         ` Yuri Khan
2015-05-26 22:44 ` Kelvin White
2015-05-26 23:31 ` Artur Malabarba
2015-05-27  0:21   ` Kelvin White
2015-05-27  0:29     ` Dmitry Gutov
2015-05-27  0:36       ` Kelvin White
2015-05-27  0:38         ` Dmitry Gutov
2015-05-27  0:45           ` Kelvin White
2015-05-27  0:56             ` Dmitry Gutov
2015-05-27  1:55               ` Kelvin White
2015-05-27  1:57                 ` Kelvin White
2015-05-27  2:02                   ` Dmitry Gutov
2015-05-27  2:23                     ` Kelvin White
2015-05-27  0:56 ` Kelvin White
2015-05-27  1:02 ` Dmitry Gutov
2015-05-27  1:40 ` Stefan Monnier
2015-05-27  1:52   ` Kelvin White
2015-05-27  2:40     ` Stefan Monnier
2015-05-27  2:55       ` Kelvin White
2015-05-27  3:14         ` Kelvin White
2015-05-27  3:16           ` Kelvin White
2015-05-27 10:12           ` Dmitry Gutov
2015-05-27 11:26             ` Kelvin White
2015-05-27 11:34               ` Dmitry Gutov
2015-05-27 12:36                 ` Kelvin White
2015-05-27 12:48                   ` Dmitry Gutov
2015-05-28  6:30         ` Steinar Bang
2015-05-27  2:37 ` Eli Zaretskii
2015-05-27 15:47   ` Alan Mackenzie
2015-05-27 19:46 ` Steinar Bang

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.