After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Alan Mackenzie]

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).

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Dmitry Gutov]

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?

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Kelvin White]

[-- 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 --]

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Kelvin White]

[-- 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 --]

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Alan Mackenzie]

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).

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Dmitry Gutov]

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.

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Kelvin White]

[-- 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 --]

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Kelvin White]

[-- 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 --]

After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Kelvin White]

[-- 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 --]

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Artur Malabarba]

[-- 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 --]

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Tom Jakubowski]

[-- 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 --]

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Kelvin White]

[-- 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 --]

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Dmitry Gutov]

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.

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Kelvin White]

[-- 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 --]

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Dmitry Gutov]

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.

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Kelvin White]

[-- 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 --]

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Kelvin White]

[-- 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 --]

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Dmitry Gutov]

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?

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Dmitry Gutov]

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.

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Stefan Monnier]

>     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.

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Kelvin White]

[-- 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 --]

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Kelvin White]

[-- 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 --]

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Kelvin White]

[-- 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 --]

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Dmitry Gutov]

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.
"""

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Kelvin White]

[-- 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 --]

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Eli Zaretskii]

> 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".

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Eli Zaretskii]

> 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.

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Stefan Monnier]

>  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

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Kelvin White]

[-- 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 --]

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Kelvin White]

[-- 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 --]

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Kelvin White]

[-- 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 --]

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Andreas Schwab]

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."

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Dmitry Gutov]

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.

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Kelvin White]

[-- 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 --]

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Dmitry Gutov]

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.

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Kelvin White]

[-- 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 --]

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Dmitry Gutov]

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.

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Alan Mackenzie]

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).

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Steinar Bang]

>>>>> 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

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Steinar Bang]

>>>>> 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)

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Yuri Khan]

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.

Re: After a git merge and manual correction of a conflict, how do I tell git the conflict is fixed?

[Steinar Bang]

>>>>> 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)