emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kelvin White
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

"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 <address@hidden> 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. :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]