Currently, the tla and bzr backends call dvc-diff-clear-buffers when a
commit is finished. That removes the status summary and the diff from
the buffer, and leaves a message "just committed". xmtn doesn't do
this. I haven't checked other backends.

That's ok if you have just committed from a diff buffer, and the diff
was against the revision that is the immediate ancestor of the
revision just committed.

bzr-delta specifies the diff buffer type as `revision-diff'. That
prevents the buffer from being cleared when a commit finishes, since
dvc-diff-clear-buffers is called with `diff' as the buffer type.
`revision-diff' isn't used by any other backend; perhaps it should be.

However, it doesn't cover the case where the commit was against some
other revision. That would require having dvc-diff-clear-buffers check
`dvc-diff-base' and `dvc-diff-modified'. I'm not proposing to do this
now, just pointing it out. The current behavior is safe, just
annoying. If it gets to be annoying enough for someone, they can fix
it :).

In addition, any existing status buffers are cleared, since they are
created with type `diff'. But instead of simply clearing the status
buffer, it would be more useful to only delete the files that were
committed. That would leave any unknown files, for example; very
useful when adding a large existing project to a new DVC backend. It
would also better support partial commits. The point is to avoid
running the backend whenever possible, since it can be slow. This is
also what pcvs does, for the same reason.

As part of fixing this, I'd like to move the UI stuff for log-edit and
commit out of the backends, to get more uniform behavior and reduce
duplicated code.

The issue then is how to distinguish status buffers from diff buffers,
and what the backend API should be for this.

One way to distinguish the status and diff buffers is to
use type `status' for status buffers, and define a new function
dvc-status-clear-buffers. Then the (new) common log-edit post-commit
handler will call dvc-status-clear-buffers and dvc-diff-clear-buffers.

Another choice would be to define a buffer-local `dvc-fileinfo-clear'
function, that dvc-diff-clear-buffers calls if non-nil. That would
more easily support other types of UI buffers in the future.

Partially clearing the status buffer is only worth pursuing if it is
easy to get the list of files committed from the backends. Parsing the
output of the commit command should provide this

The backend API would consist of three functions and a hook:

--
-- Stephe


_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev

Reply via email to