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

Here you have not yet committed the change, so the change is only in

the staging area. You need to
  git commit
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
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/

--

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

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

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

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

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

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

--

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

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

[Zabre, please keep the Cc: list when replying]
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

--

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.

--

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

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

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

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

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