Skip to contentSkip to conversation

"git rm" is not a valid merge resolution?

DISCUSSION Piotr Krukowiecki 3 participants 6 messages Jun 15, 2016

lore
Share & tools
lore
#0 lore raw

Hi,

git-status shows a hint that says
use "git add/rm <file>..." as appropriate to mark resolution

But if I "git rm file" the file gets deleted. Is this really the appropriate merge resolution?

I would expect "git rm" to maybe reset all the merge changes but it seems to just delete the file.

I doubt that when you get merge conflicts you would like to delete the file. That might be the case when in one of merge parents the file was deleted, but not if both files existed.

When deleting the file it shows a message "needs merge", perhaps the intention was to not delete the file in such case?

So maybe:
- don't list "rm" as appropriate to mark resolution, or
- list it only if the files was deleted on one parent

Example:

$ git init
$ echo a > a 
$ git add a
$ git commit -a -m a
$ echo b > a
$ git commit -a -m b
$ git checkout  -b topic HEAD^
$ echo c > a
$ git commit -a -m c
$ git merge master
Auto-merging a
CONFLICT (content): Merge conflict in a
Automatic merge failed; fix conflicts and then commit the result.
$ git status
# On branch topic
# Unmerged paths:
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#	both modified:      a
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git rm a
a: needs merge
rm 'a'
$ git status
# On branch topic
# Changes to be committed:
#
#	deleted:    a
#
Signature · 1 line
Piotr Krukowiecki
#1 lore raw
Quoted 8 lines · Piotr Krukowiecki

git-status shows a hint that says
use "git add/rm <file>..." as appropriate to mark resolution

But if I "git rm file" the file gets deleted. Is this really the appropriate merge resolution?

I would expect "git rm" to maybe reset all the merge changes but it seems to just delete the file.

Yes, if your side has a commit that updates a path since branches forked (e.g. fixing a minor bug in an implementation of a function defined there), and the other branch you are merging removed the path (e.g. fixing a higher level callers and made that buggy function no longer necessary), taking their removal can be a valid conflict resolution.

#2 lore raw

W dniu 21.03.2011 20:32, Junio C Hamano pisze:

Quoted 8 lines
Quoted 6 lines · Piotr Krukowiecki

git-status shows a hint that says
use "git add/rm <file>..." as appropriate to mark resolution

But if I "git rm file" the file gets deleted. Is this really the appropriate merge resolution?

Quoted 8 lines
Quoted 2 lines

I would expect "git rm" to maybe reset all the merge changes but it seems to just delete the file.

Yes, if your side has a commit that updates a path since branches forked (e.g. fixing a minor bug in an implementation of a function defined there), and the other branch you are merging removed the path (e.g. fixing a higher level callers and made that buggy function no longer necessary), taking their removal can be a valid conflict resolution.

Please see my other mail - file deletion can also be done by "git add". I feel that suggesting something that is wrong in most cases is wrong :)

Signature · 1 line
Piotr Krukowiecki
#3 lore raw
Quoted 1 line · Piotr Krukowiecki

Please see my other mail - file deletion can also be done by "git add".

So what?

While it technically is correct that "git add" can be asked to do so (and no, forbidding "add -u" from noticing deletion or renaming the command to stage to spread the confusion even more is out of the question), people found that it is more natural to remove things with "rm", wished to have that separate command, and the wish was granted. We suggest its use when it is appropriate.

What is your problem?

#4 lore raw
In reply to Piotr Krukowiecki
Quoted 7 lines · Piotr Krukowiecki

Hi,

git-status shows a hint that says
use "git add/rm <file>..." as appropriate to mark resolution

But if I "git rm file" the file gets deleted. Is this really the appropriate merge resolution?

In most cases, no, but when you have a modify/delete conflict for example, "git rm" is one of the candidates to resolve the conflict. The hint gives the general case.

Signature · 2 lines
Matthieu Moy
http://www-verimag.imag.fr/~moy/
#5 lore raw

W dniu 21.03.2011 19:35, Matthieu Moy pisze:

Quoted 7 lines
Quoted 5 lines · Piotr Krukowiecki

Hi,

git-status shows a hint that says
use "git add/rm <file>..." as appropriate to mark resolution

Quoted 6 lines
Quoted 2 lines

But if I "git rm file" the file gets deleted. Is this really the appropriate merge resolution?

In most cases, no, but when you have a modify/delete conflict for example, "git rm" is one of the candidates to resolve the conflict. The hint gives the general case.

I think this is not completely true. You can stage removal of a file with git add, but it's harder than use of git rm.

This is something I don't understand. Why is there a difference between removing files and (adding files or removing content)?

You must use special flags to "git add" to remove files, while you don't need such flags to add file or remove content.

All changes are tracked. You won't loose your data if you remove the file by mistake. It is the same as remove some content by mistake.

Is it caused by the name of the command ("add")? Some people would be surprised if "git add" marked removed file for removal. But I think some would be already surprised that you have to "add" your changes.

Or maybe it is caused by the fact that "git tracks content" (if I remember correctly)? I don't see a problem here. The command just tells git what content it should track. "git add" does not say "track this change (file path addition/file deletion)" but "track this file path content", so if the file got deleted there is nothing to track.

Maybe the command should be named "stage". You should stage your changes. Add the file deletion is the same change as file addition.

You would do

git stage addedfile
git stage deletedfile
git stage changedfile

This would be consistent.

(For me it doesn't need to be "stage" name. It could be handled by "add").

Currently it works like this:

git add untracked # Adds untracked file
git add . # Adds all untracked files

rm tracked
git add tracked # Does not stage the delete
git add . # Does not stage the delete
git add -A tracked # This works - stages deletion of tracked file

git add -u # Stages all tracked changes, also new/deleted tracked files git add -A # Stages all changes, also new/deleted untracked files

# No way to do following (without listing files explicitly):

# 1. Added several new files, but has also several tracked files changed
# and want to only add new files

# 2. Removed several tracked files, but has also several other tracked
# files changed and want to only remove deleted files.

Signature · 1 line
Piotr Krukowiecki