On Wed, Apr 10, 2013 at 8:22 PM, Tommaso Cucinotta <[email protected]> wrote: > On 10/04/13 00:26, Nico Williams wrote: >>> But again, git ls-files seems WAY EASIER. >> >> This will tell you if a file is tracked, not whether it has unstaged >> or uncommitted changes. > > Ok, let me be sure of one thing: the usage scenario I got into, is one in > which > one opens a file-name with LyX: > > lyx /path/to/name.lyx > > then, in case the file-name does not exist on the local FS, LyX makes the > following (LyXVC.cpp) > > call *::findFile(), to understand whether a file can be checked out > > if (foundRCS || foundCVS || foundSVN || foundGIT) {
One never checks out a file in git [*]. Or in Mercurial. Or Fossil. Other VCSes also work this way: the state of the entire workspace is the state of the repo at one specific commit + whatever changes are extant in the workspace. Therefore one checks out commits (a point in time), not files. Checking out a commit == checking out all the files as they existed at that commit's time (and space). Even in CVS I'd never checkout a file. I'd checkout a branch, a version, but not a file. I care about the state of the whole workspace, and that means *all* files are always "checked out". Standalone RCS and SCCS are different: with those you must checkout a file. You can still leave them always checked out, but not locked, say, but then you still have to lock them. Some systems built on RCS or SCCS are actually changeset-/commit-oriented, like PRCS and Teamware, in which case you once more only checkout commits/versions, never files. But standalone RCS or SCCS is (should be!) a rarity now -- so early 90s! no, so 70s! :) I'd encourage you to encourage your users to switch to a modern VCS and drop the RCS code. > So, this is very simple, seems VC-independent, and prevents the user from > creating new files that can already be checked out. Very simple, and very, very wrong :) (please take no offense, I mean none) > AFAICS, Nico's request might imply a preference option for not even having > the question bothering the user. Equivalently, enhancing the question dialog > with a checkbox (assume always this answer from now on). More than that: this must not ever happen in git. You might ask whether to add the file to the index (git add /path/to/name.lyx), but not whether to check it out. And you might want to show the VCS status of the file: whether it's tracked by a VCS, whether it's in the index (that's git-only), whether it has uncommitted changes. I'm making very strong assertions here. I will not take offense if you want to run this past some other git power-user. Indeed, I recommend it. I also strongly recommend git in general. Nico [*] To be more precise, git users do sometimes "checkout" files, as in: get the contents of the given file as it was in the given commit, and put that in the workspace as if the user had merely edited that file such that it has the same contents as it did in that commit. For example: % git checkout master % # Create a new branch "foo" with same contents as "master" % git checkout -b foo [make changes to several files] % # Commit those changes % git commit -a % # Oops! I wanted to leave file xyz the same as it was in master! % # So replace just xyz's contents with the contents it has in master: % git checkout master -- xyz % # Check that everything is OK: % git status -bsuno ## foo M xyz % # Commit that: % git commit -a % # Check that xyz really is the same as in master: % git diff master..foo -- xyz % git diff master..foo [review the other changes] [...] In this example we end up staying on branch foo with the file xyz having the contents it has in master.
