GNU bug report logs -
#52507
[PATCH] Option for vc-delete-file to keep file on disk
Previous Next
Full log
Message #49 received at 52507 <at> debbugs.gnu.org (full text, mbox):
> Or alternatively, if we consider the potential feature which we've been
> talking about (committing a subset of hunks from a file selectively), its
> implementation should have a step which either uses a staging area, or adds
> stuff to it first.
>
> And that step could be the place to enact a change like presently discussed
> (add a deletion to the staging area, and then commit it). That deletion
> would either already be in the staging area (meaning we pick up any staged
> changes for commit, which might be weird), or we would store the "intent to
> remove with --cached" in some buffer-local variable, which would be picked
> up by the new code.
>
> The latter solution would be the "cleaner" one, but the former is one that
> we could have _right now_.
>
> On the plus side, the former also doesn't seem like it's going to require
> changes in the VC API after all.
The feature of committing a subset of hunks will be performed by one command
'log-edit-done' ('C-c C-c') from the *vc-log* buffer that will run git commands
`git apply --cached` followed by `git commit`.
Doing something similar could mean for example that 'C-u M-x vc-delete-file'
could immediately pop up the *vc-log* buffer waiting for a commit message,
and on 'C-c C-c' will commit only the deleted file.
I doubt that anyone might want to commit the file deletion immediately,
because file deletions usually are committed together with other changes.
But maybe git has a way to mark a file as deleted without actually deleting it?
So `git status --porcelain -z --untracked-files` could return "D" for such file
that still exists, this would be the simplest solution.
This bug report was last modified 166 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.