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

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

[Dan Nicolaescu]

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?

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

[mathias]

Zitat von Dan Nicolaescu <dann@ics.uci.edu>:

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

Mathias

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

[Dan Nicolaescu]

mathias@mnet-mail.de writes:

  > Zitat von Dan Nicolaescu <dann@ics.uci.edu>:
  > 
  > > 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).

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

[mathias]

Zitat von Dan Nicolaescu <dann@ics.uci.edu>:

> mathias@mnet-mail.de writes:
>
>   > Zitat von Dan Nicolaescu <dann@ics.uci.edu>:
>   >
>   > > 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.

Mathias

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

[Dan Nicolaescu]

mathias@mnet-mail.de writes:

  > Zitat von Dan Nicolaescu <dann@ics.uci.edu>:
  > 
  > > mathias@mnet-mail.de writes:
  > >
  > >   > Zitat von Dan Nicolaescu <dann@ics.uci.edu>:
  > >   >
  > >   > > 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.

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

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
> 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.

I don't know _what_ people expect "C-x v u" to do for files that were
never committed, .... but the above sequence (specifically, the "git co")
seems to reset the file's contents to the contents it had at the time it
was added with "git add", in addition to removing it from the list of
added files.

[What happens with CVS?]

-Miles

-- 
Everywhere is walking distance if you have the time.  -- Steven Wright

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

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > > 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.
  > 
  > I don't know _what_ people expect "C-x v u" to do for files that were
  > never committed, .... but the above sequence (specifically, the "git co")
  > seems to reset the file's contents to the contents it had at the time it
  > was added with "git add", in addition to removing it from the list of
  > added files.

That's not good, we need something that just removes it from the index
and keeps the current contents.

  > [What happens with CVS?]

With CVS you are stuck with a file in the "add" state.

With svn, bzr, hg you can use C-x v u to transition from the "add" VC
state to "unregistered".

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

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > > git checkout HEAD <file>
>   > > git rm --cached <file>
>   > >
>   > > that take care of all situations.
>   > 
>   > I don't know _what_ people expect "C-x v u" to do for files that were
>   > never committed, .... but the above sequence (specifically, the "git co")
>   > seems to reset the file's contents to the contents it had at the time it
>   > was added with "git add", in addition to removing it from the list of
>   > added files.
>
> That's not good, we need something that just removes it from the index
> and keeps the current contents.

Hmm, that sequence also seems wrong in that the "git rm --cached" will
make previously committed files become "deleted" in the tree.

It seems like it's necessary to test whether a file has already been
committed, and use "git co" if so, and otherwise use "git rm --cached".

Since VC already appears to know whether the file's in the repo or just
"added" (in the mode-line, it shows "@" for newly added files, but ":"
or "-" for already-in-the-repo files), that should be possible, right?

-Miles

-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

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

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > >   > > git checkout HEAD <file>
  > >   > > git rm --cached <file>
  > >   > >
  > >   > > that take care of all situations.
  > >   > 
  > >   > I don't know _what_ people expect "C-x v u" to do for files that were
  > >   > never committed, .... but the above sequence (specifically, the "git co")
  > >   > seems to reset the file's contents to the contents it had at the time it
  > >   > was added with "git add", in addition to removing it from the list of
  > >   > added files.
  > >
  > > That's not good, we need something that just removes it from the index
  > > and keeps the current contents.
  > 
  > Hmm, that sequence also seems wrong in that the "git rm --cached" will
  > make previously committed files become "deleted" in the tree.
  > 
  > It seems like it's necessary to test whether a file has already been
  > committed, and use "git co" if so, and otherwise use "git rm --cached".
  > 
  > Since VC already appears to know whether the file's in the repo or just
  > "added" (in the mode-line, it shows "@" for newly added files, but ":"
  > or "-" for already-in-the-repo files), that should be possible, right?

It should be.
BTW, can't
git reset FILE 
be used here?

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

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > Since VC already appears to know whether the file's in the repo or just
>   > "added" (in the mode-line, it shows "@" for newly added files, but ":"
>   > or "-" for already-in-the-repo files), that should be possible, right?
>
> It should be.  BTW, can't git reset FILE be used here?

Hmm, maybe the sequence:

   git reset -q FILE; git checkout -q FILE 2>/dev/null

could be used.

The "reset" removes any newly added files from the index (without
changing their contents), but seems to be ignored for files already in
the repo.

The "checkout" will revert the contents of files already in the repo,
but will be ignored (with an error message) for unknown files -- and any
newly added files should be unknown at this point because of the
previous "reset".

-Miles

-- 
Philosophy, n. A route of many roads leading from nowhere to nothing.

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

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > >   > Since VC already appears to know whether the file's in the repo or just
  > >   > "added" (in the mode-line, it shows "@" for newly added files, but ":"
  > >   > or "-" for already-in-the-repo files), that should be possible, right?
  > >
  > > It should be.  BTW, can't git reset FILE be used here?
  > 
  > Hmm, maybe the sequence:
  > 
  >    git reset -q FILE; git checkout -q FILE 2>/dev/null
  > could be used.

Currently the checkout command used is:
git checkout HEAD FILE

Any difference between that and your proposal (WRT the checkout
command)?  Keep the old one, or use your version?

  > The "reset" removes any newly added files from the index (without
  > changing their contents), but seems to be ignored for files already in
  > the repo.
  > 
  > The "checkout" will revert the contents of files already in the repo,
  > but will be ignored (with an error message) for unknown files -- and any
  > newly added files should be unknown at this point because of the
  > previous "reset".

vc-do-command/vc-git-command deals with that without any problem.

Here's what I tested and seems to work fine for files with changes,
files just added and remove files:

(defun vc-git-revert (file &optional contents-done)
  "Revert FILE to the version stored in the git repository."
  (if contents-done
      (vc-git-command nil 0 file "update-index" "--")
    (vc-git-command nil 0 file "reset" "-q" "--")
    (vc-git-command nil nil file "checkout" "-q" "--")))