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>
git remote: allow adding remotes agreeing with url.<...>.insteadOf

When adding a remote, we make sure that the remote does not exist
already. However, this test was not quite correct: when the
url.<...>.insteadOf config variable was set to the remote name to be
added, the code would assume that the remote exists already.

Let's allow adding remotes when there is a url.<...>.insteadOf setting
when both the name and the URL agree with the remote to be added.

It might seem like a mistake to compare against remote->url[0] without
verifying that remote->url_nr >=1, but at this point a missing URL has
been filled by the name already, therefore url_nr cannot be zero.

Noticed by Anastas Dancha.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a regression test for 'git remote add <existing> <same-url>'

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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
commit-tree: simplify parsing of option -S using skip_prefix()

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge: release strbuf after use in suggest_conflicts()

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
transport: simplify duplicating a substring in transport_get() using xmemdupz()

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rev-list: add an option to mark fewer edges as uninteresting

In commit fbd4a70 (list-objects: mark more commits as edges in
mark_edges_uninteresting - 2013-08-16), we marked an increasing number
of edges uninteresting.  This change, and the subsequent change to make
this conditional on --objects-edge, are used by --thin to make much
smaller packs for shallow clones.

Unfortunately, they cause a significant performance regression when
pushing non-shallow clones with lots of refs (23.322 seconds vs.
4.785 seconds with 22400 refs).  Add an option to git rev-list,
--objects-edge-aggressive, that preserves this more aggressive behavior,
while leaving --objects-edge to provide more performant behavior.
Preserve the current behavior for the moment by using the aggressive
option.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pack-objects: use --objects-edge-aggressive for shallow repos

When fetching into or pushing from a shallow repository, we want to
aggressively mark edges as uninteresting, since this decreases the pack
size.  However, aggressively marking edges can negatively affect
performance on large non-shallow repositories with lots of refs.

Teach pack-objects a --shallow option to indicate that we're pushing
from or fetching into a shallow repository.  Use
--objects-edge-aggressive only for shallow repositories and otherwise
use --objects-edge, which performs better in the general case.  Update
the callers to pass the --shallow option when they are dealing with a
shallow repository.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
Documentation/SubmittingPatches: Explain the rationale of git notes

This adds more explanation of why you want to have the --notes option
given to git format-patch.

Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t2004: modernize style

In particular:

* indent test body
* place test description on same line as test_expect_*
* place closing quote on its own line
* name output file "actual" rather than "out"
* name setup test "setup" rather than "preparation"

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t2004: drop unnecessary write-tree/read-tree

Unlike earlier tests which reference several trees prepared by "setup",
no other tests utilize the tree from the "symlink" test, so there is no
need to write it (or read it back immediately).

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t2004: standardize file naming in symlink test

Update "symlink" test to use the common file naming scheme so that its
temporary files can be cleaned up by the "rm -f path*" idiom employed by
other tests in this script.

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t2004: demonstrate broken relative path printing

checkout-index --temp only properly prints relative paths which are
descendants of the current directory. Paths in ancestor or sibling
directories (or their children) are often printed in mangled form. For
example:

    mkdir a bbb &&
    >file &&
    >bbb/file &&
    git update-index --add file bbb/file &&
    cd a &&
    git checkout-index --temp ../file ../bbb/file

prints:

    .merge_file_ooblek  le
    .merge_file_igloo0  b/file

rather than the correct:

    .merge_file_ooblek  ../file
    .merge_file_igloo0  ../bbb/file

Unfortunately, testing is complicated slightly by relative paths
sometimes _appearing_ to be printed correctly, but this is an accident
of implementation in which a "correct" copy of the string exists in
memory beyond the end of the real string, and that "correct" copy gets
printed. This test takes care to avoid the accidentally "correct"
behavior by testing with a filename longer than the directory name in
which checkout-index is invoked.

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
checkout-index: fix --temp relative path mangling

checkout-index --temp only properly prints relative paths which are
descendants of the current directory. Paths in ancestor or sibling
directories (or their children) are often printed in mangled form. For
example:

    mkdir a bbb &&
    >file &&
    >bbb/file &&
    git update-index --add file bbb/file &&
    cd a &&
    git checkout-index --temp ../file ../bbb/file

prints:

    .merge_file_ooblek  le
    .merge_file_igloo0  b/file

rather than the correct:

    .merge_file_ooblek  ../file
    .merge_file_igloo0  ../bbb/file

Internally, given the above example, checkout-index prefixes each input
argument with the name of the current directory ("a/", in this case),
and then assumes that it can simply skip forward by strlen("a/") bytes
to recover the original name. This works for files in the current
directory or its descendants, but fails for files in ancestors or
siblings (or their children) due to path normalization.

For instance, given "../file", "a/" is prepended, giving "a/../file".
Path normalization folds out "a/../", resulting in "file". Attempting
to recover the original name by skipping strlen("a/") bytes gives the
incorrect "le" rather than the desired "../file".

Fix this by taking advantage of write_name_quoted_relative() to recover
the original name properly, rather than assuming that it can be
recovered by skipping strlen(prefix) bytes.

As a bonus, this also fixes a bug in which checkout-index --temp
accessed and printed memory beyond the end-of-string. For instance,
within a subdirectory named "subdirectory", and given argument
"../file", prefixing would give "subdirectory/../file", which would
become "file" after normalization. checkout-index would then attempt to
recover the original name by skipping strlen("subdirectory/") bytes of
"file", which placed it well beyond end-of-string. Despite this error,
it often appeared to give the correct result, but only due to an
accident of implementation which left an apparently correct copy of the
path in memory following the normalized value. In particular, handed
"subdirectory/../file", in-place processing by normalize_path_copy_len()
resulted in "file\0rectory/../file". When checkout-index skipped
strlen("subdirectory/") bytes, it ended up back at "../file" and thus
appeared to give the correct answer, despite being past end-of-string.

Reported-by: Russ Cox <rsc@golang.org>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
bisect: parse revs before passing them to check_expected_revs()

When running for example "git bisect bad HEAD" or
"git bisect good master", the parameter passed to
"git bisect (bad|good)" has to be parsed into a
commit hash before checking if it is the expected
commit or not.

We could do that in is_expected_rev() or in
check_expected_revs(), but it is already done in
bisect_state(). Let's just store the hash values
that result from this parsing, and then reuse
them after all the parsing is done.

This way we can also use a for loop over these
values to call bisect_write() on them, instead of
using eval.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
bisect: add test to check that revs are properly parsed

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>