Open omar-polo opened 3 years ago
Quickly tested staging a commit.
At least for me, I've got lot of changes so going through like 20 hunks just to select one is pretty tiresome. So I would be in favor of having a better method of selecting hunks. The y-or-no-p could be extended to at least provide 'N to all following, Y to all following' options if I know rest of changes are not relevant.
After staging single file, the vc-dir buffer needed manual refresh command before it showed I had staged edit. It would be nice if it was done after end of staging automatically.
When commiting staged changes it showes the commit message and files staged in the commit but not the actual diff. I'd really want to see the diff here as well.
But I'd say I would like it better to do it from diff buffer, It would be nice and fast to move with n/p to next/prev hunk and for example stage given hunk with s. This would seem a better method, not sure how it would be implemented, probably by using the response-script method.
Thanks for testing!
At least for me, I've got lot of changes so going through like 20 hunks just to select one is pretty tiresome. So I would be in favor of having a better method of selecting hunks. The y-or-no-p could be extended to at least provide 'N to all following, Y to all following' options if I know rest of changes are not relevant.
I completely agree on this. It's in my todo list; for the time being,
you can type C-g to reject all the following hunks. Got itself doesn't
provide a way to "stage all the following" (I suspect the idea is to
stage the whole file and than got unstage -p
the relevant parts --
something that we can't do at the moment), but I don't see why we can't
support that. (Actually, the plan is to support both Y/N to all and
unstage -p)
After staging single file, the vc-dir buffer needed manual refresh command before it showed I had staged edit. It would be nice if it was done after end of staging automatically.
Yup, I suppose there is a hook for this, but I couldn't find. It's something that I definitely want to fix.
When commiting staged changes it showes the commit message and files staged in the commit but not the actual diff. I'd really want to see the diff here as well.
This is a limitation of vc. When you're about to commit, it only shows
the fileset (or, in this case, the staged files) and that's it. I also
want something like that, but I guess (as a users) we have to implement
it by ourselves. I'm playing with display-buffer-alist and a function
to pop up a diff buffer on C-x v v
, but it's not complete. I'll
probably add something to the readme, but it's not really tied to
vc-got.
FWIW: I usually first look at the diff with C-x v =
or C-x v D
and
from the diff buffer I commit with C-x v v
so you have the diff and
the buffer for the commit message on the same window, but this doesn't
currently work with the diff buffer by vc-got-stage-diff
(command to
show the staged diff). It's something that needs to be fixed.
Also, please keep in mind that at the moment I'm not exactly sure what
happens when you have staged something and then you try to commit some
files with C-x v v
.
But I'd say I would like it better to do it from diff buffer, It would be nice and fast to move with n/p to next/prev hunk and for example stage given hunk with s. This would seem a better method, not sure how it would be implemented, probably by using the response-script method.
This is akin to my old attempt0 (link to the old vc-got-stage.el). There was a minor-mode in diff buffers where you could stage individual changes, and it used the response-script method under the hood.
The problem was that it's quite fragile. got stage -p
doesn't really
ask about hunks, but "sequential lines that were changed", so in the
same hunk you can have multiple stage-able changes. For this I added
vc-got-stage-prev/next-change functions etc. And it isn't easy to
detect afterwards what changes were staged and what weren't (you have to
"diff" got diff
and got diff -s
, or to unstage everything and retry)
Perhaps we can do something similar to magit, where you have two "sections", one with the unstaged changes and the other with the staged changes? What do you think?
This issues is to track the status of this feature.
The Emacs VC mode handles only filesets, it cannot mark for commit individual changes (hunks). Of course, one can
got add -p
, but then there's no point in vc-got, right?So, I tried a first approach with a minor mode for the
*vc-diff*
buffer, but I really dislike the result. It's magit-esque (that's a pro), in the sense that while reviewing a diff you can mark chunks and stage only the marked ones. The drawback is that it's fragile and fundamentally a hack around the vc limitations. I'll drop that code soon.The second option, which should follow more the style of other vc commands, is to add some specific functions:
vc-got-stage
,vc-got-reset
and some sort ofvc-got-diff-staged
(the names are not definitive). We can bind these in the*vc-dir*
buffer, add 'em to the vc menu and also possibly bind them under theC-x v
prefix.The ideal UI for something like this IMHO is a buffer in the side-window at the bottom that displays the current hunks and something like
y-or-no-p
to read the user action, but also a simpler approach with comint should be good enough (for starters, at least).There is also the possibility that we can try to get these API added to the official vc-interface, so also vc-git and other can benefit.