git-svn: support for git-svn propset

This change allows git-svn to support setting subversion properties.

It is useful for manually setting properties when committing to a
subversion repo that *requires* properties to be set without requiring
moving your changeset to separate subversion checkout in order to
set props.

This change is initially from David Fraser, appearing at:

  http://mid.gmane.org/1927112650.1281253084529659.JavaMail.root@klofta.sjsoft.com>

They are now forward-ported to most recent git along with fixes to
deal with files in subdirectories.

Style and functional changes from Eric Wong have been taken
in their entirety from:

  http://mid.gmane.org/20141201094911.GA13931@dcvr.yhbt.net

There is a nit to point out: the code does not support
adding props unless there are also content changes to the files as
well.  This is demonstrated in the testcase.

[ew - simplify Git.pm usage for check-attr
    - improve shell portability for tests
    - minor phrasing changes in commit message]

Signed-off-by: David Fraser <davidf@sjsoft.com>
Signed-off-by: Alfred Perlstein <alfred@freebsd.org>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
pre-push.sample: remove unnecessary and misleading IFS=' '

The sample hook explicitly sets IFS to SP and nothing else so that
the "read" used in the per-ref while loop that iterates over
"<localref> SP <localsha1> SP <remoteref> SP <remotesha>" records,
where we know refs and sha1s will not have SPs, would split them
correctly.

While this is not wrong per-se, it is not necessary; because we know
these fields do not contain HT or LF, either, we can simply leave
IFS the default.

This will also prevent those who cut and paste from this sample from
getting bitten when they write things in the per-ref loop that need
splitting with the default $IFS (e.g. use $(git rev-list ...) to
produce one-record-per-line output).

Signed-off-by: Jim Hill <gjthill@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t0090: tweak awk statement for Solaris /usr/xpg4/bin/awk

The awk statements previously used in this test weren't compatible
with the native versions of awk on Solaris:

    echo "dir" | /bin/awk -v c=0 '$1 {++c} END {print c}'
    awk: syntax error near line 1
    awk: bailing out near line 1

    echo "dir" | /usr/xpg4/bin/awk -v c=0 '$1 {++c} END {print c}'
    0

Even though we do not cater to tools in /usr/bin on Solaris that
have and are overridden by corresponding ones in /usr/xpg?/bin,
in this case, even the XPG version does not work correctly.

With GNU awk for comparison:

    echo "dir" | /opt/csw/gnu/awk -v c=0 '$1 {++c} END {print c}'
    1

which is what this test expects (and is in line with POSIX; non-empty
string is true and an empty string is false).

Work this issue around by using $1 != "" to state more explicitly
that we are skipping empty lines.

Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ben Walton <bdwalton@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'mh/update-ref-verify'

"git update-ref --stdin"'s verify command did not work well when
<oldvalue>, which is documented as optional, was missing.

* mh/update-ref-verify:
  update-ref: fix "verify" command with missing <oldvalue>
  t1400: add some more tests of "update-ref --stdin"'s verify command
Merge branch 'jc/t9001-modernise'

* jc/t9001-modernise:
  t9001: style modernisation phase #5
  t9001: style modernisation phase #4
  t9001: style modernisation phase #3
  t9001: style modernisation phase #2
  t9001: style modernisation phase #1
Merge branch 'for-junio' of git://bogomips.org/git-svn

* 'for-junio' of git://bogomips.org/git-svn:
  git-svn: support for git-svn propset
Merge branch 'jh/pre-push-sample-no-custom-ifs' into next

The sample pre-push hook used customized IFS=' ' for no good reason.

* jh/pre-push-sample-no-custom-ifs:
  pre-push.sample: remove unnecessary and misleading IFS=' '
is_hfs_dotgit: loosen over-eager match of \u{..47}

Our is_hfs_dotgit function relies on the hackily-implemented
next_hfs_char to give us the next character that an HFS+
filename comparison would look at. It's hacky because it
doesn't implement the full case-folding table of HFS+; it
gives us just enough to see if the path matches ".git".

At the end of next_hfs_char, we use tolower() to convert our
32-bit code point to lowercase. Our tolower() implementation
only takes an 8-bit char, though; it throws away the upper
24 bits. This means we can't have any false negatives for
is_hfs_dotgit. We only care about matching 7-bit ASCII
characters in ".git", and we will correctly process 'G' or
'g'.

However, we _can_ have false positives. Because we throw
away the upper bits, code point \u{0147} (for example) will
look like 'G' and get downcased to 'g'. It's not known
whether a sequence of code points whose truncation ends up
as ".git" is meaningful in any language, but it does not
hurt to be more accurate here. We can just pass out the full
32-bit code point, and compare it manually to the upper and
lowercase characters we care about.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'dotgit-case-maint-1.8.5' into next

* dotgit-case-maint-1.8.5:
  is_hfs_dotgit: loosen over-eager match of \u{..47}
Merge branch 'bw/maint-0090-awk-tweak' into next

* bw/maint-0090-awk-tweak:
  t0090: tweak awk statement for Solaris /usr/xpg4/bin/awk
Sync with master

* master:
  git-svn: support for git-svn propset