"git rm" is not a valid merge resolution?

[Piotr Krukowiecki-2]

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
#

 
--
Piotr Krukowiecki
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Matthieu Moy-2]

Piotr Krukowiecki <[hidden email]> writes:

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

--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Junio C Hamano]

Piotr Krukowiecki <[hidden email]> writes:

> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Piotr Krukowiecki-2]

W dniu 21.03.2011 19:35, Matthieu Moy pisze:

> Piotr Krukowiecki <[hidden email]> writes:
>
>> 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.

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.

--
Piotr Krukowiecki
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Piotr Krukowiecki-2]

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

> Piotr Krukowiecki <[hidden email]> writes:
>
>> 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.

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

--
Piotr Krukowiecki
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Junio C Hamano]

Piotr Krukowiecki <[hidden email]> writes:

> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html