Stephen Leake <[EMAIL PROTECTED]> writes:
> Ah. So the current xgit-dvc-log-edit-done code could be changed to
> something like:
>
> (if files-to-commit
> (dvc-run-dvc-sync
> 'xgit (append (list "commit" "-a"
> "-F" (dvc-log-edit-file-name)
> "--") files-to-commit))
> ;; commit all files
> (dvc-run-dvc-sync
> 'xgit (list "commit" "-a" "-F" (dvc-log-edit-file-name))))
>
>
> Then xgit would be similar to bzr with respect to cleaning up the
> status and diff buffers after a commit.
I think we need to have these two ways to commit in DVC, but I also
don't think this is sufficient: it doesn't allow one to use the
git-add/git-commit (without -a) flow, which is a very conveinient way
to deal with partial commits.
> But using xgit-add, instead of some other/new DVC front-end function,
> means the DVC user interface will not show the list of files to
> commit. That's a serious problem.
The status buffer should show them.
For example, here's what the command-line gives you:
/tmp/git$ echo foo > bar.txt
/tmp/git$ git add bar.txt
/tmp/git$ echo bar > foo.txt
/tmp/git$ git add foo.txt
/tmp/git$ echo foobar >> bar.txt
/tmp/git$ git status
# On branch bbb
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: bar.txt
# new file: foo.txt
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: bar.txt
#
/tmp/git$
> The goal of DVC is to have users _never_ invoke a back-end function
> directly.
This might be *your* goal, but that's not an acceptable one to me. DVC
is primarily a framework to make an Emacs interface for a distributed
version-control system. The first goal is to factor the code.
Indeed, I would see no problem letting the users call M-x
xgit-whatever RET or M-x xhg-whatever-else RET. I don't see much added
value allowing the user to type M-x dvc-diff RET where he could call
M-x bzr-diff RET. BUT, there are at least two places where the
unification layer (i.e. the dvc-* function dispatching to the
appropriate back-end) has an added value : menu-bar, and keyboard
shortcuts. Having a single keyboard shortcut for bzr-diff, xhg-diff,
xgit-diff, ... has a real added value. Having a common menu is also
more conveinient.
But for things that DVC _cannot_ unify, because it is a particularity
of only one or a few of its back-ends, then what's the problem letting
the user call a particular function to get a particular feature ?
This "staging area", called index for git and AAUI workspace manifest
for monotone. I don't want DVC to totally hide this features when it
exists, and I don't want to bother bzr, hg or darcs users with it.
It's not just a feature like the others, it really changes the flow,
the way you type commands. You CANNOT hide it from the user without
lack of feature.
> So there should be a "dvc-*" function that does what is needed here;
And what would you want it to do for bzr, hg and darcs?
What will bzr, hg, darcs users think about it?
> the user should _not_ be calling xgit-add.
Why?
> I don't see why the user interface style should be dictated by which
> back-end is used.
At the moment, I'm using git because I _like_ git. If I wanted to have
bzr's interface, I'd be using bzr. Why the hell should a git user
interface in Emacs be dictated by what bzr and hg do? Let the git
interface use the git features, and don't disturb other interface with
something irrelevant for them.
> Having "dvc-mark-files" call "xgit-add" makes sense to me; why do you
> think that should not be done?
That means you lose the "git commit ... -- file1 file2" feature.
Also, marking files is not only about commit. You can mark 5 files to
delete them, you can mark 5 files to run "git add" on them, whether or
not they're unknown.
> Hmm. I guess that could be wrong for unknown files; the user might be
> marking them to ignore them, not add them. So then "dvc-ignore-files"
> would have to call "xgit-unadd".
You have nothing to undo the effect of "git add", and you can't have
it without a totally bloated storage format.
"git add file1" means: "add file1, with its content, to the index. If
file1 is already there, replace its content with this one". If you run
$ echo foo > bar.txt
$ git add bar.txt
$ echo foo >> bar.txt
$ git add bar.txt
$ echo foo >> bar.txt
$ git add bar.txt
$ echo foo >> bar.txt
$ git add bar.txt
Then, you successively add "foo\n", "foo\nfoo\n",
"foo\nfoo\nfoo\n" ... as the content of bar.txt. What you can say is:
* git rm --cached bar.txt : remove the file from the index (untrack it)
* git checkout HEAD bar.txt : reset the content of file to the last
commited revision.
But you can't say "take me back to the place I was before git-add".
The old content has been overridden by the new one.
So, in addition to the above, with your approach, you have no way to
have a mark/unmark sequence be a no-op.
--
Matthieu
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
