Matthieu Moy, 2007-07-08: > Christian Ohler <[EMAIL PROTECTED]> writes: > >> Committing from the diff buffer has questionable utility since you >> can just as easily use the status buffer to commit. And it creates >> the problems I described. It's a good candidate for removal. > > I'd like to have the feedback of other DVC users and developers, but > to me, the "diff/edit-log/commit" cycle *is* the most meaningfull. > So, you're indeed proposing to remove what is the most usefull thing > to me in DVC.
Yes, I'd also like to hear more opinions. I also used to commit from the diff buffer all the time when xmtn didn't have a proper status mode. It always struck me as awkward to jump back and forth between the "status" part of the diff buffer and the actual diff while preparing a commit. To me it seems more natural to keep separate things in separate buffers in this case. Assuming an equivalent of the "j" command, I don't see any advantage at all to committing from the diff buffer. And the status buffer is the superior commit interface anyway because it shows unknown files. > You could have one buffer with the complete diff plus the status > buffer. If you manage to resize the buffers to avoid status taking > half the screen even if it's to show <5 files, C-x - >> Why can't you use a status buffer, perhaps with a diff buffer >> visible in a separate window? What other solutions to the problems >> of meaningless keybindings and committing from the wrong diff do >> you see? > > Avoiding committing to the wrong diff is relatively trivial, since > you have two variables giving you the base revision, you can easily > check that the base revision is the HEAD. (Base revision being HEAD is not sufficient; the other revision for the diff command (I don't think we have a good name for it) needs to be the workspace, too.) > Even easier, you can just mark the buffer as OK to commit from after > creating it, that's one local variable. One local variable, but N commands times M back-ends that need to check it. The problem affects all workspace operations, not just commit, and workspace operations are currently mostly defined as "unified" commands that don't run any shared code before the back-end-specific code, so there is nowhere to place a common check. This would definitely be an added maintenance burden. We could also restructure the command definitions to have shared code handle the check of this variable, but that would be a nontrivial refactoring. Not harder than the changes I suggested, but not exactly easy either; and overall, this approach increases the complexity quite a bit. > BTW, commiting from a diff buffer which isn't against the head can be > meaningfull too. For example, "git commit --amend" commits against > the ancestor of the head, and discards the current head (I don't > think we have a good interface for this in DVC). Whether the user wants --amend is unrelated to which diff he's looking at. It's probably relatively common to look at the diff relative to the HEAD while still wanting --amend. Christian. _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
