Connor Sheehan <sheehan@mozilla.com> [Sat, 31 Mar 2018 13:01:20 -0400] rev 37247
stringutil: edit comment to reflect actual data type name
In development the data type used to hold an email/name pair
was called a "mailmaptup" since it was implemented as a
namedtuple. The implementation has since been changed to use
an @attr.s decorated class named mailmapping. This commit
changes a comment to reflect this change.
Differential Revision: https://phab.mercurial-scm.org/D3004
Connor Sheehan <sheehan@mozilla.com> [Sat, 31 Mar 2018 11:36:55 -0400] rev 37246
stringutil: improve check for failed mailmap line parsing
The existing check for a bad mailmap file entry fails with inputs
like b'>@<'. This commit adds a function to check if a sufficient
amount of information has been parsed from a mailmap file entry.
At minimum, one email must be found (assumed to be the commit email).
If email is not empty and no names are found, then there must be
two emails. If there are at least one email and name, the mapping
is valid.
Differential Revision: https://phab.mercurial-scm.org/D3003
Connor Sheehan <sheehan@mozilla.com> [Sat, 31 Mar 2018 10:21:39 -0400] rev 37245
stringutil: rename local email/names variables to their plural forms
email and name variables are renamed to emails and names (respectively).
This is because the email variable name shadows the email function
within the stringutil module. Since we are renaming email, we also rename
name for consistency.
Differential Revision: https://phab.mercurial-scm.org/D3002
Connor Sheehan <sheehan@mozilla.com> [Sat, 31 Mar 2018 10:13:42 -0400] rev 37244
templatefuncs: remove redundant "or author" from mailmap return statement
Differential Revision: https://phab.mercurial-scm.org/D3001
Matt Harbison <matt_harbison@yahoo.com> [Sat, 24 Feb 2018 19:56:59 -0500] rev 37243
lfs: add the 'Content-Type' header called out in the file transfer spec
https://github.com/git-lfs/git-lfs/blob/master/docs/api/basic-transfers.md#uploads
Matt Harbison <matt_harbison@yahoo.com> [Sun, 25 Feb 2018 23:44:02 -0500] rev 37242
lfs: improve the client message when the server signals an object error
Two things here. First, the previous message included a snippet of JSON, which
tends to be long (and in the case of lfs-test-server, has no error message).
Instead, give a concise message where possible, and leave the JSON to a debug
output. Second, the server can signal issues other than a missing individual
file. This change shows a corrupt file, but I'm debating letting the corrupt
file get downloaded, because 1) the error code doesn't really fit, and 2) having
it locally makes forensics easier. Maybe need a config knob for that.