(beginner) git rm

(beginner) git rm

[Zabre]

Hi,

I am learning git and there is something I don't get : why a file deleted in
a branch gets also deleted in my master?
(For the moment I'm only working locally, no remote repository)

I have a master branch containing 4 text files called a.txt , b.txt , c.txt
, d.txt . (in HEAD)

I create a new branch from there (masters HEAD) and go to this new branch.
$ git branch new
$ git checkout new

I delete one file in the new branch
$ git rm d.txt
$ ls
a.txt b.txt c.txt

Then I go back to the master branch and list the files there
$ git checkout master
$ls
a.txt b.txt c.txt

I have not modified the master branch, why is d.txt deleted there also?

There must be something I did not understand in git behaviour (something to
do with the index?)
Thank you for your help.
-- 
View this message in context: http://n2.nabble.com/%28beginner%29-git-rm-tp2231416p2231416.html
Sent from the git mailing list archive at Nabble.com.

Re: (beginner) git rm

[Peter Krefting]

Zabre:

> I delete one file in the new branch
> $ git rm d.txt
> $ ls
> a.txt b.txt c.txt

Here you have not yet committed the change, so the change is only in
the staging area. You need to

  git commit

to create a commit on your branch.

> Then I go back to the master branch and list the files there
> $ git checkout master

Since you have not yet made any commits to your branch, master and new
both point to the same commit, meaning that this is does nothing but
changes which branch you are committing to.

> $ls
> a.txt b.txt c.txt

You are in the same place as you were a moment ago, but you have told
Git that you want to commit the removal to master instead of new.

-- 
\\// Peter - http://www.softwolves.pp.se/

Re: (beginner) git rm

[Zabre]

Peter Krefting wrote:
> 
> Here you have not yet committed the change, so the change is only in
> the staging area. You need to
> 
>   git commit
> 
> to create a commit on your branch.
> 

Thank you Peter.
I've just done a hard reset and redid it the right way. It worked as
expected.

$ git checkout new
$ rm d.txt
$ git rm d.txt
$ git commit

I am a little bit confused regarding rm : first I did a simple "rm" but git
would not commit, so I had to "git rm" for the index to be modified and have
something to commit. Is this the right way to do things?

Another question would be : instead of doing a hard reset (I might have
other changes in the index that I don't want to loose) is it possible to
remove only one "delete action" from the index?
-- 
View this message in context: http://n2.nabble.com/%28beginner%29-git-rm-tp2231416p2231622.html
Sent from the git mailing list archive at Nabble.com.

Re: (beginner) git rm

[Tomas Carnecky]

On 01/28/2009 12:05 PM, Zabre wrote:
> Another question would be : instead of doing a hard reset (I might have
> other changes in the index that I don't want to loose) is it possible to
> remove only one "delete action" from the index?

Do you mean 'undelete' a file? git checkout d.txt - That restores the 
file in the working tree and resets the index just for that file.

tom

Re: (beginner) git rm

[Zabre]

Tomas Carnecky wrote:
> 
> Do you mean 'undelete' a file? git checkout d.txt - That restores the 
> file in the working tree and resets the index just for that file.
> 

Hi Tom,
(thank you for your interest in my newbie problems)

yes that's what I mean : 'undelete' a file, after a "git rm d.txt".
But I did not manage to apply your solution succesfully :
$ git rm d.txt
$ ls
a.txt b.txt c.txt
$ git status
# On branch new
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	deleted:    d.txt
#
$ git checkout d.txt
error: pathspec 'mamma.txt' did not match any file(s) known to git.
Did you forget to 'git add'?

So it did not work but I've just noticed that unstage tip given by the
status command, and I did the following (which worked)

$ git reset HEAD d.txt
d.txt: needs update
$ ls
a.txt b.txt c.txt
$ git checkout d.txt
$ ls
a.txt b.txt c.txt d.txt

Reading the git reset help file gives me the feeling I should use this with
caution... It looks like you can somehow modify the change history.
Anyway these two commands helped me change the index the way I wanted.
Please tell me if this might somehow go wrong in another situation.
-- 
View this message in context: http://n2.nabble.com/%28beginner%29-git-rm-tp2231416p2231849.html
Sent from the git mailing list archive at Nabble.com.

Re: (beginner) git rm

[Tomas Carnecky]

On 01/28/2009 01:00 PM, Zabre wrote:
>
> Tomas Carnecky wrote:
>> Do you mean 'undelete' a file? git checkout d.txt - That restores the
>> file in the working tree and resets the index just for that file.
>>
>
> Hi Tom,
> (thank you for your interest in my newbie problems)
>
> yes that's what I mean : 'undelete' a file, after a "git rm d.txt".
> But I did not manage to apply your solution succesfully :
> $ git rm d.txt
> $ ls
> a.txt b.txt c.txt
> $ git status
> # On branch new
> # Changes to be committed:
> #   (use "git reset HEAD<file>..." to unstage)
> #
> #	deleted:    d.txt
> #
> $ git checkout d.txt
> error: pathspec 'mamma.txt' did not match any file(s) known to git.
> Did you forget to 'git add'?

Oops, sorry. git checkout HEAD -- d.txt
You have to tell which version of d.txt you want. In your case the 
version in HEAD.

tom

Re: (beginner) git rm

[Theodore Tso]

On Wed, Jan 28, 2009 at 01:19:13PM +0100, Tomas Carnecky wrote:
>
> Oops, sorry. git checkout HEAD -- d.txt
> You have to tell which version of d.txt you want. In your case the  
> version in HEAD.
>

I use this command enough that I have this defined as an alias in my
~/.gitconfig file.  Try running this command:

	git config --global alias.revert-file "checkout HEAD --"

Now you will be able to do this:

	git revert-file d.txt

This is also useful when I've edited d.txt, and decided that I didn't
go about it the right away, and so I want to revert my edits.

						- Ted

Re: (beginner) git rm

[Zabre]

Theodore Tso wrote:
> 
> I use this command enough that I have this defined as an alias in my
> ~/.gitconfig file.  Try running this command:
> 
> 	git config --global alias.revert-file "checkout HEAD --"
> 
> Now you will be able to do this:
> 
> 	git revert-file d.txt
> 
> This is also useful when I've edited d.txt, and decided that I didn't
> go about it the right away, and so I want to revert my edits.
> 

Very good, I'll try that. (Plus it shows me how to customize git, thanks!)
(Sorry for my late answer I've been unable to check my computer for a few
hours)
-- 
View this message in context: http://n2.nabble.com/%28beginner%29-git-rm-tp2231416p2233899.html
Sent from the git mailing list archive at Nabble.com.

Re: (beginner) git rm

[Zabre]

Tomas Carnecky wrote:
> 
> Oops, sorry. git checkout HEAD -- d.txt
> You have to tell which version of d.txt you want. In your case the 
> version in HEAD.
> 

Thank you for this precision, it makes me understand this command better.
(Sorry for my late answer I've been unable to check my computer for a few
hours)
-- 
View this message in context: http://n2.nabble.com/%28beginner%29-git-rm-tp2231416p2233892.html
Sent from the git mailing list archive at Nabble.com.

Re: (beginner) git rm

[Björn Steinbrink]

On 2009.01.28 10:23:12 -0800, Zabre wrote:
> Tomas Carnecky wrote:
> > 
> > Oops, sorry. git checkout HEAD -- d.txt
> > You have to tell which version of d.txt you want. In your case the 
> > version in HEAD.
> 
> Thank you for this precision, it makes me understand this command better.
> (Sorry for my late answer I've been unable to check my computer for a few
> hours)

The "git checkout -- d.txt" is also a valid command, but that restores
the file from the index.

git checkout -- paths
	==> Copy "paths" from the index to the working tree

git checkout <tree-ish> -- paths
	==> Copy "paths" from the tree-ish to the index and working tree

So, for "rm d.txt", a plain "git checkout -- d.txt" would also do the
trick, as d.txt is still in the index. But your "git rm d.txt" also
removed the file from the index, and thus that checkout does nothing.
But "git checkout HEAD -- d.txt" works, as it gets the file from HEAD
and puts it into the index and working tree.

Björn

Re: (beginner) git rm

[Zabre]

Björn Steinbrink wrote:
> 
> The "git checkout -- d.txt" is also a valid command, but that restores
> the file from the index.
> 
> git checkout -- paths
> 	==> Copy "paths" from the index to the working tree
> 
> git checkout <tree-ish> -- paths
> 	==> Copy "paths" from the tree-ish to the index and working tree
> 
> So, for "rm d.txt", a plain "git checkout -- d.txt" would also do the
> trick, as d.txt is still in the index. But your "git rm d.txt" also
> removed the file from the index, and thus that checkout does nothing.
> But "git checkout HEAD -- d.txt" works, as it gets the file from HEAD
> and puts it into the index and working tree.
> 

This is enlightening, thank you very much!
(I knew I would love git more and more)

Oh just one (probably stupid) thing : <tree-ish> does represent a directory
being the root of a tree of folders (which has been added to the index),
does it?
This is the way I understand it at the moment. It must be a convention I
don't know just yet. (I need to investigate on this)
-- 
View this message in context: http://n2.nabble.com/%28beginner%29-git-rm-tp2231416p2234796.html
Sent from the git mailing list archive at Nabble.com.

Re: (beginner) git rm

[Zabre]

Zabre wrote:
> 
> Oh just one (probably stupid) thing : <tree-ish> does represent a
> directory being the root of a tree of folders (which has been added to the
> index), does it?
> This is the way I understand it at the moment. It must be a convention I
> don't know just yet. (I need to investigate on this)
> 

Ok I found in the doc (in the "The Object Database" section) what trees are
about, seems a little bit more obscure, so I guess I'm not ready for this
right now. (I'm a beginner trying to use git for a simple regular workflow,
managing code and other documents)
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#the-object-database
I guess <tree-ish> refers to such an object, and you use it in order to
revert it from the Object Database.
I'll keep this idea in mind for when I'll try to restore data from tricky
last-chance "stores", there is a section about such things in the doc :
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#fixing-mistakes
I think that in a normal everyday use, the small index modification I can do
using the previous advices can do the job (or am I wrong?)
-- 
View this message in context: http://n2.nabble.com/%28beginner%29-git-rm-tp2231416p2234918.html
Sent from the git mailing list archive at Nabble.com.

Re: (beginner) git rm

[Junio C Hamano]

Zabre <427@free.fr> writes:

> Björn Steinbrink wrote:
>> 
>> The "git checkout -- d.txt" is also a valid command, but that restores
>> the file from the index.
>> 
>> git checkout -- paths
>> 	==> Copy "paths" from the index to the working tree
>> 
>> git checkout <tree-ish> -- paths
>> 	==> Copy "paths" from the tree-ish to the index and working tree
>> 
>> So, for "rm d.txt", a plain "git checkout -- d.txt" would also do the
>> trick, as d.txt is still in the index. But your "git rm d.txt" also
>> removed the file from the index, and thus that checkout does nothing.
>> But "git checkout HEAD -- d.txt" works, as it gets the file from HEAD
>> and puts it into the index and working tree.
>
> This is enlightening, thank you very much!
> (I knew I would love git more and more)
>
> Oh just one (probably stupid) thing : <tree-ish> does represent a directory
> being the root of a tree of folders (which has been added to the index),
> does it?

Yeah, it typically is a commit object.

Björn said "Copy", but the operation really is like checking out a book
from a library and "checkout" is a good word for it.  "I do not like what
I have in my work tree, and I'd like to replace it with a fresh one taken
out of the index (or, out of that commit)".

Re: (beginner) git rm

[Björn Steinbrink]

[Zabre, please keep the Cc: list when replying]

On 2009.01.28 13:29:36 -0800, Junio C Hamano wrote:
> Zabre <427@free.fr> writes:
> > Björn Steinbrink wrote:
> >> 
> >> The "git checkout -- d.txt" is also a valid command, but that restores
> >> the file from the index.
> >> 
> >> git checkout -- paths
> >> 	==> Copy "paths" from the index to the working tree
> >> 
> >> git checkout <tree-ish> -- paths
> >> 	==> Copy "paths" from the tree-ish to the index and working tree
> >> 
> >> So, for "rm d.txt", a plain "git checkout -- d.txt" would also do the
> >> trick, as d.txt is still in the index. But your "git rm d.txt" also
> >> removed the file from the index, and thus that checkout does nothing.
> >> But "git checkout HEAD -- d.txt" works, as it gets the file from HEAD
> >> and puts it into the index and working tree.
> >
> > This is enlightening, thank you very much!
> > (I knew I would love git more and more)
> >
> > Oh just one (probably stupid) thing : <tree-ish> does represent a directory
> > being the root of a tree of folders (which has been added to the index),
> > does it?
> 
> Yeah, it typically is a commit object.
> 
> Björn said "Copy", but the operation really is like checking out a book
> from a library and "checkout" is a good word for it.  "I do not like what
> I have in my work tree, and I'd like to replace it with a fresh one taken
> out of the index (or, out of that commit)".

With "checkout", I'm still a bit unsure about which term to use, because
of the behaviour you get with, for example, "git checkout HEAD --
directory". It always just adds or replaces files, but never removes
them. So it's not really like taking the old directory out of the repo
and using that instead. For example:

git rm dir/old_file
echo 123 > dir/new_file
git add dir/new_file
git checkout HEAD -- dir

That won't remove dir/new_file from the index (and of course it won't
drop it from the working tree). That's the one thing where "git checkout
HEAD -- dir" differs from "git reset HEAD -- dir && git checkout --
dir". IIRC we've talked about that on #git a few months ago, but I don't
recall what conclusions we came up with.

It would probably be better to say that checkout only works with the
blobs (because the index doesn't have entries for trees, right?) that
exist in the given tree-ish. And thus it doesn't remove entries from the
index. But that feels a bit convoluted. :-/

Björn

Re: (beginner) git rm

[Junio C Hamano]

Björn Steinbrink <B.Steinbrink@gmx.de> writes:

> With "checkout", I'm still a bit unsure about which term to use, because
> of the behaviour you get with, for example, "git checkout HEAD --
> directory".
> ...
> It would probably be better to say that checkout only works with the
> blobs (because the index doesn't have entries for trees, right?).

True, it is not just "checkout".  There is no such thing as "directory" in
git UI, in that sense.

When you say:

	git checkout [<tree-ish>] -- pathspec

you may be using the same string as the name of an existing directory, but
that does not change the fact that you are giving a pathspec pattern to
specify the set of paths in the index (or in the <tree-ish>) that matches
the pathspec.

Re: (beginner) git rm

[Björn Steinbrink]

On 2009.01.28 17:11:07 -0800, Jonathan Wills wrote:
> This seems like an appropriate thread to ask something I came across today.
> Either I am unclear about the precise semantics of git checkout <branch>
> <path>, or there is a bug in said command.  I noticed this when I wanted to
> get a directory to match the same directory in another branch, so I did rm
> -rf dir, followed by git checkout master dir.  Afterwards I noticed that
> files in that directory that had previously been in my branch but were not
> in the master branch had returned.  Earlier in this thread it was mentioned
> that git checkout will not remove files, but in this case I had already
> removed those files and git checkout actually replaced them (and not from
> the master branch like I asked, but from the current branch).

This is exactly what I meant. Your "rm -rf dir" only removed the
directory from the working tree, but _not_ from the index. And what
"git checkout master -- dir" then does is that it puts all the stuff
that is in master's "dir" into the index, in _addition_ to the stuff
already in the index. And then it puts everything from the index's "dir"
into the working tree. This is really a two step process and in each
step the pathspec is matched separately.

So the working tree doesn't have "dir" at all.

In the index you still have:
whatever
dir/file (index version)
dir/other_file

In master you have:
whatever_2
dir/file (master version)
dir/yet_another_file

Then you do "git checkout master -- dir".

In the first step, that "dir" pathspec matches these files from master:
dir/file
dir/yet_another_file

So those are added to the index, and the index will have:
whatever
dir/file (master version)
dir/other_file
dir/yet_another_file

So "dir/file" was replaced, and "dir/yet_another_file" was added. But
"dir/other_file" is still around.

And then comes the index -> working tree step. The pathspec matches all
three files in "dir" in the index, and so they appear in the working
tree.


To get what you expected, you have several options:
a)
rm -rf dir
git add -u dir (drops it from the index)
git checkout master -- dir

b)
git rm -rf dir
git checkout master -- dir

Just saves the "git add -u" step.

c)
rm -rf dir
git reset master -- dir
git checkout -- dir

The reset makes "dir" in the index equal to master's "dir" (ok,
technically that's wrong, as the index doesn't even know about "dir" on
its own, but my brain fails to produce a correct description).

Björn