FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 27 Mar 2017 09:44:36 +0900] rev 31658
largefiles: use strip() instead of slicing to get rid of EOL of standin
This slicing prevents from replacing SHA-1 by another (= longer hash
value) in the future.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 27 Mar 2017 09:44:36 +0900] rev 31657
largefiles: rename local variable appropriately
repo['.'] is called not as "working context" but as "parent context".
In this code path, hash value of current content of file should be
compared against hash value recorded in "parent context".
Therefore, "wctx" may cause misunderstanding in this case.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 27 Mar 2017 09:44:35 +0900] rev 31656
largefiles: avoid redundant loop to eliminate None from list
Before this patch, this code path contains two loops for m._files: one
for replacement with standin, and another for elimination of None,
which comes from previous replacement ("standin in wctx or
lfdirstate[f] == 'r'" case in tostandin()).
These two loops can be unified into simple one "for" loop.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 27 Mar 2017 09:44:35 +0900] rev 31655
largefiles: avoid meaningless changectx looking up
Logically, "repo[ctx.node()]" should be equal to "ctx".
In addition to it, this redundant code path is repeated
"len(match.m_files)" times.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 27 Mar 2017 09:44:35 +0900] rev 31654
largefiles: avoid redundant changectx looking up at each repetitions
These code paths look up changectx at each repetitions, even though
the changectx key isn't changed while loop.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 27 Mar 2017 09:44:34 +0900] rev 31653
largefiles: omit updating newly added standin at linear merging
Updating standin for newly added largefile is needed, only if same
name largefile exists in destination context at linear merging. In
such case, updated standin is used to detect divergence of largefile
at overridefilemerge().
Otherwise, standin doesn't have any responsibility for its content
(usually, it is empty).
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 27 Mar 2017 09:44:34 +0900] rev 31652
largefiles: reuse hexsha1() to centralize hash calculation logic into it
This patch also renames argument of hexsha1(), not only for
readability ("data" isn't good name for file-like object), but also
for reviewability (including hexsha1() code helps reviewers to confirm
how these functions are similar).
BTW, copyandhash() has also similar logic, but it can't reuse
hexsha1(), because it writes read-in data into specified fileobj
simultaneously.