emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C-x v u for added files in vc-git


From: Dan Nicolaescu
Subject: Re: C-x v u for added files in vc-git
Date: Thu, 3 Dec 2009 10:22:35 -0800 (PST)

address@hidden writes:

  > Zitat von Dan Nicolaescu <address@hidden>:
  > 
  > > address@hidden writes:
  > >
  > >   > Zitat von Dan Nicolaescu <address@hidden>:
  > >   >
  > >   > > In a git tree doing:
  > >   > >
  > >   > > C-x C-f BLAH_BLAH RET
  > >   > > RET
  > >   > > C-x v v
  > >   > >
  > >   > > will put the BLAH_BLAH in the 'added state
  > >   > >
  > >   > > Doing a C-x v u
  > >   > > after that should return it to the 'unregistered state, but that 
does
  > >   > > not happen the file stays in the 'added state.
  > >   > >
  > >   > > This is because vc-git-revert runs:
  > >   > > (vc-git-command nil 0 file "checkout" "HEAD")
  > >   > >
  > >   > > What should vc-git-revert do that it works in the above case too?
  > >   >
  > >   > git rm --cached <file>
  > >   >
  > >   > removes the file from the index,  i.e. reverts the 'add' command.
  > >
  > > Does it also restore the file contents in the case where the file is
  > > registered and it has been changed ? (that's another use for the
  > > function in question).
  > 
  > 'git add <file>' not only registers the file as 'cvs add <file>' does.
  > It  also adds the content of the file to the index.
  > 'git rm --cached <file>' removes the content from the index and doesn't
  > touch the file.
  > 
  > I think there are 3 cases here:
  > 
  > 1. If you have mistakenly added a new file with 'git add' that should not be
  >    under version control then 'git rm --cached <file<' is the right command
  >    to undo it.
  > 
  > 2. <file> is already in the repository. If you have changed it and added
  >    to the index but don't want to commit this change now, then again
  >     'git rm --cached <file<' is the right command. <file> will still be
  >    in your worktree in the modified state.
  > 
  > 3. <file> is already in the repository. If you have changed it and want 
revert
  >    this change. In this case 'git checkout HEAD <file>' restores the content
  >    to that of the last commit. 'git checkout' also updates the index.
  >    It didn't update the index in your case because the file wasn't in HEAD.
  > 
  > I think C-x v u should do 1. and 2. but not 3. because 3. deletes data.

3. is exactly the goal for the command, to get rid of unwanted changes!

So it seems that if we do the sequence:

git checkout HEAD <file>
git rm --cached <file>

that take care of all situations.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]