Matthieu Moy <[EMAIL PROTECTED]> writes: >> But if you are using DVC, surely marked files in the ewoc are even >> more convenient? > > First, it's also conveinient if you're using both Emacs and the > command-line (that's my case. Saint Ignucius will probably forgive me > since I run the command line inside Emacs). > > But more important, the index stuff in git is much more general than > just marking files. There are several things you can hardly do with > just marking files, like > > * git add -i : allows you to add patch hunks to the index, not just > whole files. DVC doesn't expose this, but could very easily have an > xgit-add-interactive function that would do i.e. (ansi-term > "git add -i").
So a command to add a hunk displayed in a diff buffer would be useful. > * git diff Vs git diff --cached : git diff shows you what you didn't > add to the index yet, and git diff --cached what you're about to > commit. You can use that to do intermediate validations of your code > while writting a long patch : do something, check with "git diff" > that it's OK, git add, and continue. I use that when I have several > steps and when the intermediate steps do not deserve to be commited > (regression or uncompilable code). Sounds like the index is almost a "lite local branch". > * Interaction with other git tools. I mentionned Emacs Vs > command-line, but one may also want to use git-gui or so. Right. >>> For example, here's what the command-line gives you: >>> >>> <snip> >> >> Ok. >> >> How should this information be displayed in DVC? > > IMO, it should just be displayed in a way similar to what the command > line does. The ewoc structure used for status allows "messages", so we > can have > > '(message "On branch ...") > '(message "Changes to be committed:") > '(file "file1" ....) > '(file "another-file" ....) > '(message "Changed but not updated") > ... That makes sense, but since it is now possible for one file to be in two places, it complicates managing the ewoc. I think I prefer Michael's approach of adding a marker of some sort to a single file line. That will be simpler for the front-end to handle, especially if I ever get dvc-fileinfo going (more structured ewoc info). >> And if the user calls xgit-add after dvc-status, how should the >> display be updated? > > In that proposal, files should move from the bottom section to the top > one. That also makes sense. I'm trying to move as much ewoc management as possible into the front-end, both so that each back-end does not have to re-implement it, and so that the DVC user interface to different back-ends is more common. This would be a case where there needs to be a hook or something to let there still be back-end specific behavior. Sounds like the general approach for xgit is to make the unified DVC interface work, while also making the extra git features available in a reasonable way. Th -- -- Stephe _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
