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 -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
