Sat, 01 Apr 2017 16:50:11 +0900 revsetlang: avoid string concatenation in formatspec()
Yuya Nishihara <yuya@tcha.org> [Sat, 01 Apr 2017 16:50:11 +0900] rev 35557
revsetlang: avoid string concatenation in formatspec()
Thu, 04 Jan 2018 12:30:55 +0900 test-glog: hook cmdutil.getlogrevs() so -frREV is rewritten accordingly
Yuya Nishihara <yuya@tcha.org> [Thu, 04 Jan 2018 12:30:55 +0900] rev 35556
test-glog: hook cmdutil.getlogrevs() so -frREV is rewritten accordingly Before, these tests didn't match the real behavior of "log -frREV".
Wed, 03 Jan 2018 17:12:30 +0900 test-glog: dump computed set
Yuya Nishihara <yuya@tcha.org> [Wed, 03 Jan 2018 17:12:30 +0900] rev 35555
test-glog: dump computed set It's more important than the revset expression built from command options.
Wed, 03 Jan 2018 17:09:16 +0900 test-glog: drop uninteresting nodes from AST output
Yuya Nishihara <yuya@tcha.org> [Wed, 03 Jan 2018 17:09:16 +0900] rev 35554
test-glog: drop uninteresting nodes from AST output This makes future test changes more readable.
Sun, 07 Jan 2018 01:14:52 -0500 lfs: remove the verification option when writing to the local store
Matt Harbison <matt_harbison@yahoo.com> [Sun, 07 Jan 2018 01:14:52 -0500] rev 35553
lfs: remove the verification option when writing to the local store This partially reverts 417e8e040102 and bb6a80fc969a. But since there's now a dedicated download function, there's no functional change. The last sentence in the commit message of the latter is wrong- write() didn't need the one time hash check if verification wasn't requested. I suspect I missed 'read()' in there ("... but _read()_ also needs to do a one time check..."), because that did fail without the hash check before linking to the usercache. The write() method simply took the same check for consistency. While here, clarify that the write() method is *only* for storing content directly from filelog, which has already checked the hash. If someone can come up with a way to bridge the differences between writing to a file and sending a urlreq.request across the wire, we can create an upload() function and cleanup read() in a similar way. About the only common thread I see is an open() that verifies the content before returning a file descriptor.
Thu, 21 Dec 2017 21:20:00 -0500 lfs: use the localstore download method to transfer from remote stores
Matt Harbison <matt_harbison@yahoo.com> [Thu, 21 Dec 2017 21:20:00 -0500] rev 35552
lfs: use the localstore download method to transfer from remote stores Both gitlfsremote and file based remotes benefit from not requiring the whole file in memory (though the whole file is still loaded when passing through the revlog interface). With a method specific to downloading from a remote store, the misleading 'use hg verify' hint is removed. The behavior is otherwise unchanged, in that a download from both remote store types will yield a copy of the blob via util.atomictempfile. There's no response payload defined for the non 'download' actions, but the previous code attempted to read the payload in this case anyway. This refactored code made that more obvious, so any payload is printed as a debug message, just in case.
Thu, 21 Dec 2017 18:56:04 -0500 lfs: introduce a localstore method for downloading from remote stores
Matt Harbison <matt_harbison@yahoo.com> [Thu, 21 Dec 2017 18:56:04 -0500] rev 35551
lfs: introduce a localstore method for downloading from remote stores The current local.write() method requires the full data, which means concatenating file chunks in memory when downloading from a git server. The dedicated method downloads in chunks, verifies the content on the fly, and creates the usercache hardlink if successful. It can also be used for the file system based remotestore. An explicit division of labor between downloading from a remote store (which should be verified) and writing to the store because of a commit or similar (which doesn't need verification), seems clearer. I can't figure out how to make a similar function for upload, because for a file remote store, it's a simple open/read/write operation. For a gitremote store, it's open the file and a urlreq.request(), and process that.
Tue, 02 Jan 2018 12:14:08 +0900 win32: do not call GetVolumePathName() with the minimum buffer length
Yuya Nishihara <yuya@tcha.org> [Tue, 02 Jan 2018 12:14:08 +0900] rev 35550
win32: do not call GetVolumePathName() with the minimum buffer length It fails on Windows XP even though the doc says "a safer but slower way to set the size of the return buffer is to call the GetFullPathName function, and then make sure that the buffer size is at least the same size as the full path that GetFullPathName returns." https://msdn.microsoft.com/en-us/library/windows/desktop/aa364996(v=vs.85).aspx Well, more "safe" way would be to simply rely on MAX_PATH for common scenarios.
Tue, 02 Jan 2018 12:02:25 +0900 win32: allocate buffer of maximum length for GetVolumeInformation()
Yuya Nishihara <yuya@tcha.org> [Tue, 02 Jan 2018 12:02:25 +0900] rev 35549
win32: allocate buffer of maximum length for GetVolumeInformation() It's documented that "the maximum buffer size is MAX_PATH+1", which is slightly larger than 256. https://msdn.microsoft.com/en-us/library/windows/desktop/aa364993(v=vs.85).aspx
Sun, 22 Oct 2017 22:49:11 +0900 log: drop unused expr from return value of getlogrevs()
Yuya Nishihara <yuya@tcha.org> [Sun, 22 Oct 2017 22:49:11 +0900] rev 35548
log: drop unused expr from return value of getlogrevs() Future patches will move some processing of the --follow option out of _makelogrevset(), where the returned 'expr' value will be less consistent with the 'revs'. So let's remove it from the public interface.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip