13

I am using VS Code, and I am constantly annoyed when I find a typo in a staged change just before a commit (usually in the read-only "(Index)" editor). Because resolving it involves opening the original file, finding the same location, making the change, saving the file, now opening the diff of the file, staging this change (and none of the others), then finalizing the commit. This seems unnecessary complicated to me.

I would just like to make edits to the index - a smart editor such as VS Code should be able to do what's necessary in the background. But it won't let me since the editor is read-only, and I "Cannot edit in read-only editor"

There is a GitHub issue#91065 (and #91274, #74149, #15785, #33681) on this, saying this works "as designed". But the explanation does not really explain it to me:

The title of the diff says (Index) - this means you have staged the changes, and you are diffing the staged changes against the head revision.

Correct, but that does not explain why VS Code should not be able to stage further changes.

This is not the same as the working file, because you can selectively stage some parts of the file, so the stage version may look different to the working file

Again: correct, but that does not explain why VS Code should not be able to stage further changes without going through the hassle of editing the "working file" first.

You cannot edit the right side because the changes are staged

That's not an explanation to me.

you need to edit the working file and stage those changes as well, or unstage and edit the file

And finally, again, I don't see why VS Code could not do that for me.

But maybe I am overlooking something. So my question is,

Why can I not directly stage changes? Should VS Code be able to?

bers
  • 4,817
  • 2
  • 40
  • 59
  • use the `diff` **before** you stage a file, stage is to be handled like a commit, it only has no hash yet – rioV8 Jul 09 '20 at 09:49
  • 1
    @RonvanderHeijden I am not "committing blindly": I usually stage by cherry-picking, line by line, from the diff. And when doing so, I feel it's best practice to take a final look at the index once I have staged everything that I think I need for a commit. There is no other way for me to get this view outside of the staging area. And well, sometimes you do spot typos you didn't spot before. – bers Jul 09 '20 at 10:00
  • 1
    then un-cherry-pick that part and edit and cherry pick back – rioV8 Jul 09 '20 at 10:06
  • 1
    `I am constantly annoyed` doesn't suggest you are very precise. – Ron van der Heijden Jul 09 '20 at 10:07
  • 1
    @rioV8 this is exactly what I mean by `unnecessary complicated`. Hence my question: is there a (technical?) reason why I need to take this extra-long route? – bers Jul 09 '20 at 10:11
  • 1
    @RonvanderHeijden I am glad I have exhausted your factual arguments against my question - thanks for getting us back to the real issue. – bers Jul 09 '20 at 10:12
  • edit the typo in the workspace file, commit your staged files, cherry pick the typo edit, use `git commit --amend` to include the typo in the last commit, it uses the same commit message, or lets you modify the message – rioV8 Jul 09 '20 at 10:19
  • 2
    @RonvanderHeijden the question is not whether there is "a valid reason to do something". The question is whether it can be done, and if not, why. – bers Jul 09 '20 at 11:43
  • 1
    @rioV8 you do acknowledge that your latest proposal is slightly more involved than simply correcting the typo in the diff view that is already open and pressing `Ctrl+S`, right? Thank you :) – bers Jul 09 '20 at 11:44
  • you can edit the VSC diff while you cherry pick the staged sections, so correct the typo's then, staged files are read only by design, if this staged typos happens often you have a problem typing and proof reading during cherry picking, **Read Twice Stage Once** – rioV8 Jul 09 '20 at 12:28
  • 2
    Thank you both for your opinions. Rest assured that I am not attacking the way git works, or the way you use git. Nonetheless, please accept the point of view of a user who has never used git from the command line and was introduced to it only through use of a GUI. Naturally, a GUI can lead to different use cases than were envisaged by the git designers, so while it may be true that "staged files are read only by design", my point of view is that this design does not properly reflect the extended range of possibilities offered by GUI use. Hence my question. – bers Jul 10 '20 at 09:47
  • 1
    I have yet to come across an argument why what I propose is not feasible or should not be done, except "design" (which is equivalent, for me, to "the designers did not consider this use case"). I agree there are different ways to do what I want to do, but while you may find these more intuitive, I don't. And they are undoubtedly longer. – bers Jul 10 '20 at 09:52
  • 4
    _Finally_, I will not answer any more comments of the sort "there is no valid reason to want to do what you want to do". Typos happen, and no matter how hard you look, you will spot some as close as is even possible to the final stage. Only loosely related, but well: http://phdcomics.com/comics/archive.php?comicid=1531 – bers Jul 10 '20 at 09:57
  • 11
    I have been using git (in the CLI also) for the last +10 years, and i still agree with what @bers is asking. Maybe it has to do that i came from Eclipse, where this feature was readily available from the early days of git integration. Telling people that "this is not the official way" is not gonna work for the discussion. – ankostis Jul 16 '20 at 15:06
  • There are plenty of other GIT clients out there, use one of them instead if you don't like the VS code one. If you don't like the git flow you can write your own extension to do what you want. Basically this "question" is just a rant VTC – Liam Jul 16 '20 at 15:22
  • One argument against such a functionality that crossed my mind is potential conflicts: If I change a line in the working copy; stage it to the index; then edit it again in the working copy; then edit it in the index - what is git/VS Code supposed to do? I wonder what Eclipse will be doing then. – bers Sep 08 '21 at 15:09
  • @bers, to your last comment - the working copy & the version in index are treated independently. So for example when you change just the index version and make a commit, Git will report that you have a modified working copy. But that should be perfectly fine, you may simply revert your working copy changes afterwards. For me, this is still 100% easier workflow than what VS Code forces you to do, as you very correctly describe. BTW This is not just about fixing typos but also about cases when you need to commit just 2 lines from 3 new consecutive lines, for example. – Petr Bodnár Feb 03 '22 at 21:46
  • @PetrBodnár thanks, I get your point. It may be unexpected behavior for some, though. For example, as a naive user, I might expect that when I fix a typo in the index, that fix is propagated to the working copy as well. (One might restrict editing the index to cases where the change can be propagated in such a way without a conflict - anyway.) I think it is plausible that a GUI functionality may not be implemented if it is only 50:50 clear what the user expects to happen when using this functionality. After all, the implementation will be perceived as "wrong" in 50% of cases. – bers Feb 03 '22 at 22:25
  • 1
    @bers, good points. :) So it is really possibly just about avoiding confusion among users. Then I can imagine the GUI could give some clear warning when user decides to freely edit a file in index, so even an inexperienced Git user won't get lost. – Petr Bodnár Feb 04 '22 at 16:50
  • 1
    João Moreno who works on vscode claimed already in 2017 that it should be possible to do this in an extension but I have not been able to find any that does this. Any idea on what part of the vscode API should be used to achieve this? – morotspaj Dec 06 '22 at 21:06
  • those vscode developers just don't want to deal with this. they expect us to replace the diffing/staging views with custom stuff. they won't even entertain this as a feature suggestion. -- to my knowledge, git itself doesn't expose this operation either. it can be done by preparing the state of the file to be staged, then reaching into the internals and putting that file into the index. https://stackoverflow.com/questions/14410733/git-modify-contents-of-index-directly-for-pre-commit-formatting-hook – Christoph Rackwitz Jul 11 '23 at 15:10

1 Answers1

1

The only answer here is, find a VS Code plugin as good as the ones written for vim (fugitive) or emacs (magit). Both of those treat the index as just another directory on a different filesystem. I don't know magit but fugitive lets you edit :path/to/file directly, and with :Gdiff you can nab diff hunks from that or from arbitrary revs, basically that's the power-tools version of add --patch and reset --patch and checkout --patch. I'd be shocked if it turns out magit can't do that.

Christoph Rackwitz
  • 11,317
  • 4
  • 27
  • 36
jthill
  • 55,082
  • 5
  • 77
  • 137
  • 1
    I wasn't able to find any such extension as of now. Let me know if there is any update please. – gagarwa Feb 14 '23 at 18:23