From: Piotr Krukowiecki <piotr.krukowiecki@gmail.com>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: "git rm" is not a valid merge resolution?
Date: Mon, 21 Mar 2011 20:56:41 +0100 [thread overview]
Message-ID: <4D87AD79.5000806@gmail.com> (raw)
In-Reply-To: <vpqpqpk724l.fsf@bauges.imag.fr>
W dniu 21.03.2011 19:35, Matthieu Moy pisze:
> Piotr Krukowiecki <piotr.krukowiecki@gmail.com> 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
next prev parent reply other threads:[~2011-03-21 19:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-21 18:27 "git rm" is not a valid merge resolution? Piotr Krukowiecki
2011-03-21 18:35 ` Matthieu Moy
2011-03-21 19:56 ` Piotr Krukowiecki [this message]
2011-03-21 19:32 ` Junio C Hamano
2011-03-21 20:01 ` Piotr Krukowiecki
2011-03-21 20:24 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D87AD79.5000806@gmail.com \
--to=piotr.krukowiecki@gmail.com \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).