[LyX/master] Simplify checking whether files are controlled by SVN and GIT.

[Richard Kimberly Heck]

On 1/8/21 10:45 PM, Scott Kostyshak wrote:
> On Mon, Dec 28, 2020 at 03:45:11PM +0200, Yuriy Skalko wrote:
>>>>> I am sorry not to have a time to follow this thoroughly, but is this
>>>>> cvs log / git log used only inh "register" case as initially discussed
>>>>> or you want to use it on every file load?
>>>>> Calling log could but pretty expensive operation for large archives.
>>>> The -n0 flag that Yuriy proposed should take care of that, too. So
>>>> another reason to go that way.
>>>
>>> I understood that. The minor concern was that it can still take seconds to get
>>> the first commit touching particular file in larger git repos if its buried
>>> down in the history.  But maybe it's not that different from git-ls.
>>>
>>> My main concern though were changes to CVS - I haven't seen -n0 equivalent and
>>> are you positive that cvs log does not actually try to connect to server (would
>>> make us fail if you are offline)? It's really long time ago I used cvs, but
>>> IIRC each tracked directory has the needed metadata locally at the place
>>> so do we actualy need these changes to fulfil the users-list request?
>>>
>>> Sorry for nitpicking, but given that this piece of code is executed at each
>>> document load we better be super careful here...
>>>
>>> Pavel
>> Committed "-n 0" for Git. CVS has "-Q" option (https://www.gnu.org/software/trans-coord/manual/cvs/html_node/Global-options.html#Global-options)
>> that may help too, but I have no CVS installed, so cannot test this.
> I'm not sure that "git log <filename" and "git log -n 0 <filename>" do
> what we want here. For me (git version 2.20.1) they do not exit with
> error if the file is not tracked.

Hmm. I was certain I had checked this, but it is not exiting with an
error now for me either.


> I can see why the implementation in the previous version of using git-ls
> was complex since we had to redirect output to a file and check it, but
> what about using "git ls-files --error-unmatch <file name>" ? The
> "--error-unmatch" seems to make it so we don't have to check a file.
> The only annoyance I see is that there is no "--quiet" option so we
> would need to redirect the output. I can look into adding a "quiet"
> argument to doVCCommandCall() that would quiet both STDOUT and STDERR if
> the attached patch is on the right track.

It looks right to me.

Enrico may have good ideas about how to do the redirection.

Riki