git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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