Commit Graph

6719 Commits

Author SHA1 Message Date
Junio C Hamano
52938b113b Merge branch 'jc/maint-mailinfo-mime-attr' into maint
* jc/maint-mailinfo-mime-attr:
  mailinfo: do not concatenate charset= attribute values from mime headers
2012-09-29 22:30:48 -07:00
Junio C Hamano
140011d8f2 Merge branch 'jc/maint-blame-no-such-path' into maint
Even during a conflicted merge, "git blame $path" always meant to
blame uncommitted changes to the "working tree" version; make it
more useful by showing cleanly merged parts as coming from the other
branch that is being merged.

This incidentally fixes an unrelated problem on a case insensitive
filesystem, where "git blame MAKEFILE" run in a history that has
"Makefile" but not "MAKEFILE" did not say "No such file MAKEFILE in
HEAD" but pretended as if "MAKEFILE" was a newly added file.

* jc/maint-blame-no-such-path:
  blame: allow "blame file" in the middle of a conflicted merge
  blame $path: avoid getting fooled by case insensitive filesystems
2012-09-24 12:40:02 -07:00
Junio C Hamano
8144049d79 Merge branch 'dj/fetch-all-tags' into maint
"git fetch --all", when passed "--no-tags", did not honor the
"--no-tags" option while fetching from individual remotes (the same
issue existed with "--tags", but combination "--all --tags" makes
much less sense than "--all --no-tags").

* dj/fetch-all-tags:
  fetch --all: pass --tags/--no-tags through to each remote
  submodule: use argv_array instead of hand-building arrays
  fetch: use argv_array instead of hand-building arrays
  argv-array: fix bogus cast when freeing array
  argv-array: add pop function
2012-09-24 12:39:21 -07:00
Junio C Hamano
f9c2d2b14e Merge branch 'nd/maint-remote-remove' into maint
* nd/maint-remote-remove:
  remote: prefer subcommand name 'remove' to 'rm'
2012-09-20 15:53:31 -07:00
Junio C Hamano
176943b965 mailinfo: do not concatenate charset= attribute values from mime headers
"Content-type: text/plain; charset=UTF-8" header should not appear
twice in the input, but it is always better to gracefully deal with
such a case.  The current code concatenates the value to the values
we have seen previously, producing nonsense such as "utf8UTF-8".

Instead of concatenating, forget the previous value and use the last
value we see.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-17 15:24:52 -07:00
Ramkumar Ramachandra
5805853f22 t/perf: add "trash directory" to .gitignore
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-17 14:27:55 -07:00
Junio C Hamano
78ed88d80a Merge branch 'mz/cherry-pick-cmdline-order' into maint
* mz/cherry-pick-cmdline-order:
  cherry-pick/revert: respect order of revisions to pick
  demonstrate broken 'git cherry-pick three one two'
  teach log --no-walk=unsorted, which avoids sorting
2012-09-14 21:24:18 -07:00
Junio C Hamano
c336bc104c Sync with 1.7.11.7 2012-09-14 21:20:40 -07:00
Junio C Hamano
19ece726e1 Merge branch 'jk/maint-quiet-is-synonym-to-s-in-log' into maint-1.7.11
* jk/maint-quiet-is-synonym-to-s-in-log:
  log: fix --quiet synonym for -s
2012-09-14 20:48:31 -07:00
Junio C Hamano
dabdc0178e Merge branch 'rj/test-regex' into maint-1.7.11
* rj/test-regex:
  test-regex: Add a test to check for a bug in the regex routines
2012-09-14 20:46:39 -07:00
Junio C Hamano
3503e9ab32 Merge branch 'maint-1.7.11' into maint 2012-09-12 14:08:05 -07:00
Junio C Hamano
1403db49b8 Merge branch 'jc/apply-binary-p0' into maint-1.7.11
"git apply -p0" did not parse pathnames on "diff --git" line
correctly.  This caused patches that had pathnames in no other
places to be mistakenly rejected (most notably, binary patch that
does not rename nor change mode).  Textual patches, renames or mode
changes have preimage and postimage pathnames in different places in
a form that can be parsed unambiguously and did not suffer from this
problem.

* jc/apply-binary-p0:
  apply: compute patch->def_name correctly under -p0
2012-09-12 14:00:53 -07:00
Junio C Hamano
eaff724bbc Merge branch 'jc/dotdot-is-parent-directory' into maint-1.7.11
"git log .." errored out saying it is both rev range and a path when
there is no disambiguating "--" is on the command line.  Update the
command line parser to interpret ".." as a path in such a case.

* jc/dotdot-is-parent-directory:
  specifying ranges: we did not mean to make ".." an empty set
2012-09-12 14:00:34 -07:00
Junio C Hamano
7d9483c299 Merge branch 'jk/maint-http-half-auth-push' into maint-1.7.11
Pushing to smart HTTP server with recent Git fails without having
the username in the URL to force authentication, if the server is
configured to allow GET anonymously, while requiring authentication
for POST.

* jk/maint-http-half-auth-push:
  http: prompt for credentials on failed POST
  http: factor out http error code handling
  t: test http access to "half-auth" repositories
  t: test basic smart-http authentication
  t/lib-httpd: recognize */smart/* repos as smart-http
  t/lib-httpd: only route auth/dumb to dumb repos
  t5550: factor out http auth setup
  t5550: put auth-required repo in auth/dumb
2012-09-12 13:58:23 -07:00
Junio C Hamano
92c830dd35 Merge branch 'kk/maint-for-each-ref-multi-sort' into maint-1.7.11
"git for-each-ref" did not honor multiple "--sort=<key>" arguments
correctly.

* kk/maint-for-each-ref-multi-sort:
  for-each-ref: Fix sort with multiple keys
  t6300: test sort with multiple keys
2012-09-12 13:57:43 -07:00
Junio C Hamano
9aeaab6811 blame: allow "blame file" in the middle of a conflicted merge
"git blame file" has always meant "find the origin of each line of
the file in the history leading to HEAD, oh by the way, blame the
lines that are modified locally to the working tree".

This teaches "git blame" that during a conflicted merge, some
uncommitted changes may have come from the other history that is
being merged.

The verify_working_tree_path() function introduced in the previous
patch to notice a typo in the filename (primarily on case insensitive
filesystems) has been updated to allow a filename that does not exist
in HEAD (i.e. the tip of our history) as long as it exists one of the
commits being merged, so that a "we deleted, the other side modified"
case tracks the history of the file in the history of the other side.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-11 14:30:03 -07:00
Junio C Hamano
1c88a6d174 Sync with 1.7.11.6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-11 11:23:54 -07:00
Junio C Hamano
ee7a83f631 Merge branch 'sz/submodule-force-update' into maint-1.7.11
* sz/submodule-force-update:
  Make 'git submodule update --force' always check out submodules.
2012-09-11 11:10:17 -07:00
Junio C Hamano
ef92392b6c Merge branch 'ph/stash-rerere' into maint-1.7.11
* ph/stash-rerere:
  stash: invoke rerere in case of conflict
  test: git-stash conflict sets up rerere
2012-09-11 11:10:12 -07:00
Junio C Hamano
fe31b2afac Merge branch 'hv/submodule-path-unmatch' into maint-1.7.11
* hv/submodule-path-unmatch:
  Let submodule command exit with error status if path does not exist
2012-09-11 11:08:55 -07:00
Junio C Hamano
ef66ac3ead Merge branch 'mz/empty-rebase-test' into maint-1.7.11
* mz/empty-rebase-test:
  add tests for 'git rebase --keep-empty'
2012-09-11 11:08:48 -07:00
Junio C Hamano
d9b983fc26 Merge branch 'ab/diff-write-incomplete-line' into maint-1.7.11
* ab/diff-write-incomplete-line:
  Fix '\ No newline...' annotation in rewrite diffs
2012-09-11 11:08:30 -07:00
Junio C Hamano
ffb13460cd Merge branch 'jc/maint-t7406-rev-parse-max-count-huh' into maint-1.7.11
* jc/maint-t7406-rev-parse-max-count-huh:
  t7406: fix misleading "rev-parse --max-count=1 HEAD"
2012-09-11 11:08:18 -07:00
Junio C Hamano
6508d0358d Merge branch 'jc/test-prereq' into maint
* jc/test-prereq:
  t3910: use the UTF8_NFD_TO_NFC test prereq
  test-lib: provide UTF8 behaviour as a prerequisite
  t0050: use the SYMLINKS test prereq
  t0050: use the CASE_INSENSITIVE_FS test prereq
  test-lib: provide case insensitivity as a prerequisite
  test: allow prerequisite to be evaluated lazily
  test: rename $satisfied to $satisfied_prereq
2012-09-11 10:51:58 -07:00
Junio C Hamano
ffcabccf5d blame $path: avoid getting fooled by case insensitive filesystems
"git blame MAKEFILE" run in a history that has "Makefile" but not
MAKEFILE can get confused on a case insensitive filesystem, because
the check we run to see if there is a corresponding file in the
working tree with lstat("MAKEFILE") succeeds.  In addition to that
check, we have to make sure that the given path also exists in the
commit we start digging history from (i.e. "HEAD").

Note that this reveals the breakage in a test added in cd8ae20
(git-blame shouldn't crash if run in an unmerged tree, 2007-10-18),
which expects the entire merge-in-progress path to be blamed to the
working tree when it did not exist in our tree.  As it is clear in
the log message of that commit, the old breakage was that it was
causing an internal error and the fix was about avoiding it.

Just check that the command does not die an uncontrolled death.  For
this particular case, the blame should fail, as the history for the
file in that contents has not been committed yet at the point in the
test.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-10 18:42:30 -07:00
Junio C Hamano
e3f26752b5 Merge branch 'maint-1.7.11' into maint
* maint-1.7.11:
  Almost 1.7.11.6
  gitweb: URL-decode $my_url/$my_uri when stripping PATH_INFO
  rebase -i: use full onto sha1 in reflog
  sh-setup: protect from exported IFS
  receive-pack: do not leak output from auto-gc to standard output
  t/t5400: demonstrate breakage caused by informational message from prune
  setup: clarify error messages for file/revisions ambiguity
  send-email: improve RFC2047 quote parsing
  fsck: detect null sha1 in tree entries
  do not write null sha1s to on-disk index
  diff: do not use null sha1 as a sentinel value
2012-09-10 15:31:06 -07:00
Junio C Hamano
3f664638e5 Merge branch 'bc/receive-pack-stdout-protection' into maint-1.7.11
When "git push" triggered the automatic gc on the receiving end, a
message from "git prune" that said it was removing cruft leaked to
the standard output, breaking the communication protocol.

* bc/receive-pack-stdout-protection:
  receive-pack: do not leak output from auto-gc to standard output
  t/t5400: demonstrate breakage caused by informational message from prune
2012-09-10 15:25:09 -07:00
Junio C Hamano
03adeeaad6 Merge branch 'jk/maint-null-in-trees' into maint-1.7.11
"git diff" had a confusion between taking data from a path in the
working tree and taking data from an object that happens to have
name 0{40} recorded in a tree.

* jk/maint-null-in-trees:
  fsck: detect null sha1 in tree entries
  do not write null sha1s to on-disk index
  diff: do not use null sha1 as a sentinel value
2012-09-10 15:24:54 -07:00
Junio C Hamano
423a9e28fc Merge branch 'tr/maint-send-email-2047' into maint-1.7.11
"git send-email" did not unquote encoded words that appear on the
header correctly, and lost "_" from strings.

* tr/maint-send-email-2047:
  send-email: improve RFC2047 quote parsing
2012-09-10 15:24:41 -07:00
Dan Johnson
8556646089 fetch --all: pass --tags/--no-tags through to each remote
When fetch is invoked with --all, we need to pass the tag-following
preference to each individual fetch; without this, we will always
auto-follow tags, preventing us from fetching the remote tags into a
remote-specific namespace, for example.

Reported-by: Oswald Buddenhagen <ossi@kde.org>
Signed-off-by: Dan Johnson <ComputerDruid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-07 10:01:35 -07:00
Nguyễn Thái Ngọc Duy
e17dba8fe1 remote: prefer subcommand name 'remove' to 'rm'
All remote subcommands are spelled out words except 'rm'. 'rm', being a
popular UNIX command name, may mislead users that there are also 'ls' or
'mv'. Use 'remove' to fit with the rest of subcommands.

'rm' is still supported and used in the test suite. It's just not
widely advertised.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-06 13:23:22 -07:00
Ramsay Jones
c91841594c test-regex: Add a test to check for a bug in the regex routines
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-02 18:57:21 -07:00
Martin von Zweigbergk
a73e22e963 cherry-pick/revert: respect order of revisions to pick
When giving multiple individual revisions to cherry-pick or revert, as
in 'git cherry-pick A B' or 'git revert B A', one would expect them to
be picked/reverted in the order given on the command line. They are
instead ordered by their commit timestamp -- in chronological order
for "cherry-pick" and in reverse chronological order for
"revert". This matches the order in which one would usually give them
on the command line, making this bug somewhat hard to notice. Still,
it has been reported at least once before [1].

It seems like the chronological sorting happened by accident because
the revision walker has traditionally always sorted commits in reverse
chronological order when rev_info.no_walk was enabled. In the case of
'git revert B A' where B is newer than A, this sorting is a no-op. For
'git cherry-pick A B', the sorting would reverse the arguments, but
because the sequencer also flips the rev_info.reverse flag when
picking (as opposed to reverting), the end result is a chronological
order. The rev_info.reverse flag was probably flipped so that the
revision walker emits B before C in 'git cherry-pick A..C'; that it
happened to effectively undo the unexpected sorting done when not
walking, was probably a coincidence that allowed this bug to happen at
all.

Fix the bug by telling the revision walker not to sort the commits
when not walking. The only case we want to reverse the order is now
when cherry-picking and walking revisions (rev_info.no_walk = 0).

 [1] http://thread.gmane.org/gmane.comp.version-control.git/164794

Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-30 14:00:23 -07:00
Martin von Zweigbergk
d023c248a3 demonstrate broken 'git cherry-pick three one two'
Cherry-picking commits out of order (w.r.t. commit time stamp) doesn't
currently work. Add a test case to demonstrate it.

Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-30 14:00:18 -07:00
Martin von Zweigbergk
ca92e59e30 teach log --no-walk=unsorted, which avoids sorting
When 'git log' is passed the --no-walk option, no revision walk takes
place, naturally. Perhaps somewhat surprisingly, however, the provided
revisions still get sorted by commit date. So e.g 'git log --no-walk
HEAD HEAD~1' and 'git log --no-walk HEAD~1 HEAD' give the same result
(unless the two revisions share the commit date, in which case they
will retain the order given on the command line). As the commit that
introduced --no-walk (8e64006 (Teach revision machinery about
--no-walk, 2007-07-24)) points out, the sorting is intentional, to
allow things like

 git log --abbrev-commit --pretty=oneline --decorate --all --no-walk

to show all refs in order by commit date.

But there are also other cases where the sorting is not wanted, such
as

 <command producing revisions in order> |
       git log --oneline --no-walk --stdin

To accomodate both cases, leave the decision of whether or not to sort
up to the caller, by allowing --no-walk={sorted,unsorted}, defaulting
to 'sorted' for backward-compatibility reasons.

Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-30 12:26:50 -07:00
Jeff King
f9c75d858d log: fix --quiet synonym for -s
Originally the "--quiet" option was parsed by the
diff-option parser into the internal QUICK option. This had
the effect of silencing diff output from the log (which was
not intended, but happened to work and people started to
use it). But it also had other odd side effects at the diff
level (for example, it would suppress the second commit in
"git show A B").

To fix this, commit 1c40c36 converted log to parse-options
and handled the "quiet" option separately, not passing it
on to the diff code. However, it simply ignored the option,
which was a regression for people using it as a synonym for
"-s". Commit 01771a8 then fixed that by interpreting the
option to add DIFF_FORMAT_NO_OUTPUT to the list of output
formats.

However, that commit did not fix it in all cases. It sets
the flag after setup_revisions is called. Naively, this
makes sense because you would expect the setup_revisions
parser to overwrite our output format flag if "-p" or
another output format flag is seen.

However, that is not how the NO_OUTPUT flag works. We
actually store it in the bit-field as just another format.
At the end of setup_revisions, we call diff_setup_done,
which post-processes the bitfield and clears any other
formats if we have set NO_OUTPUT. By setting the flag after
setup_revisions is done, diff_setup_done does not have a
chance to make this tweak, and we end up with other format
options still set.

As a result, the flag would have no effect in "git log -p
--quiet" or "git show --quiet".  Fix it by setting the
format flag before the call to setup_revisions.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-28 15:37:29 -07:00
Jeff King
b81401c1de http: prompt for credentials on failed POST
All of the smart-http GET requests go through the http_get_*
functions, which will prompt for credentials and retry if we
see an HTTP 401.

POST requests, however, do not go through any central point.
Moreover, it is difficult to retry in the general case; we
cannot assume the request body fits in memory or is even
seekable, and we don't know how much of it was consumed
during the attempt.

Most of the time, this is not a big deal; for both fetching
and pushing, we make a GET request before doing any POSTs,
so typically we figure out the credentials during the first
request, then reuse them during the POST. However, some
servers may allow a client to get the list of refs from
receive-pack without authentication, and then require
authentication when the client actually tries to POST the
pack.

This is not ideal, as the client may do a non-trivial amount
of work to generate the pack (e.g., delta-compressing
objects). However, for a long time it has been the
recommended example configuration in git-http-backend(1) for
setting up a repository with anonymous fetch and
authenticated push. This setup has always been broken
without putting a username into the URL. Prior to commit
986bbc0, it did work with a username in the URL, because git
would prompt for credentials before making any requests at
all. However, post-986bbc0, it is totally broken. Since it
has been advertised in the manpage for some time, we should
make sure it works.

Unfortunately, it is not as easy as simply calling post_rpc
again when it fails, due to the input issue mentioned above.
However, we can still make this specific case work by
retrying in two specific instances:

  1. If the request is large (bigger than LARGE_PACKET_MAX),
     we will first send a probe request with a single flush
     packet. Since this request is static, we can freely
     retry it.

  2. If the request is small and we are not using gzip, then
     we have the whole thing in-core, and we can freely
     retry.

That means we will not retry in some instances, including:

  1. If we are using gzip. However, we only do so when
     calling git-upload-pack, so it does not apply to
     pushes.

  2. If we have a large request, the probe succeeds, but
     then the real POST wants authentication. This is an
     extremely unlikely configuration and not worth worrying
     about.

While it might be nice to cover those instances, doing so
would be significantly more complex for very little
real-world gain. In the long run, we will be much better off
when curl learns to internally handle authentication as a
callback, and we can cleanly handle all cases that way.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27 10:49:09 -07:00
Jeff King
4c71009da6 t: test http access to "half-auth" repositories
Some sites set up http access to repositories such that
fetching is anonymous and unauthenticated, but pushing is
authenticated. While there are multiple ways to do this, the
technique advertised in the git-http-backend manpage is to
block access to locations matching "/git-receive-pack$".

Let's emulate that advice in our test setup, which makes it
clear that this advice does not actually work.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27 10:49:09 -07:00
Jeff King
6ac2b3aeb9 t: test basic smart-http authentication
We do not currently test authentication over smart-http at
all. In theory, it should work exactly as it does for dumb
http (which we do test). It does indeed work for these
simple tests, but this patch lays the groundwork for more
complex tests in future patches.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27 10:49:09 -07:00
Jeff King
666aae9aed t/lib-httpd: recognize */smart/* repos as smart-http
We do not currently test authentication for smart-http repos
at all. Part of the infrastructure to do this is recognizing
that auth/smart is indeed a smart-http repo.

The current apache config recognizes only "^/smart/*" as
smart-http. Let's instead treat anything with /smart/ in the
URL as smart-http. This is obviously a stupid thing to do
for a real production site, but for our test suite we know
that our repositories will not have this magic string in the
name.

Note that we will route /foo/smart/bar.git directly to
git-http-backend/bar.git; in other words, everything before
the "/smart/" is irrelevant to finding the repo on disk (but
may impact apache config, for example by triggering auth
checks).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27 10:49:09 -07:00
Jeff King
05b577107d t/lib-httpd: only route auth/dumb to dumb repos
Our test apache config points all of auth/ directly to the
on-disk repositories via an Alias directive. This works fine
because everything authenticated is currently in auth/dumb,
which is a subset.  However, this would conflict with a
ScriptAlias for auth/smart (which will come in future
patches), so let's narrow the Alias.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27 10:49:08 -07:00
Jeff King
e837936c7c t5550: factor out http auth setup
The t5550 script sets up a nice askpass helper for
simulating user input and checking what git prompted for.
Let's make it available to other http scripts by migrating
it to lib-httpd.

We can use this immediately in t5540 to make our tests more
robust (previously, we did not check at all that hitting the
password-protected repo actually involved a password).
Unfortunately, we end up failing the test because the
current code erroneously prompts twice (once for
git-remote-http, and then again when the former spawns
git-http-push).

More importantly, though, it will let us easily add
smart-http authentication tests in t5541 and t5551; we
currently do not test smart-http authentication at all.

As part of making it generic, let's always look for and
store auxiliary askpass files at the top-level trash
directory; this makes it compatible with t5540, which runs
some tests from sub-repositories. We can abstract away the
ugliness with a short helper function.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27 10:49:04 -07:00
Jeff King
726800a8b3 t5550: put auth-required repo in auth/dumb
In most of our tests, we put repos to be accessed by dumb
protocols in /dumb, and repos to be accessed by smart
protocols in /smart.  In our test apache setup, the whole
/auth hierarchy requires authentication. However, we don't
bother to split it by smart and dumb here because we are not
currently testing smart-http authentication at all.

That will change in future patches, so let's be explicit
that we are interested in testing dumb access here. This
also happens to match what t5540 does for the push tests.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27 10:49:04 -07:00
Junio C Hamano
6a2abdc125 apply: compute patch->def_name correctly under -p0
Back when "git apply" was written, we made sure that the user can
skip more than the default number of path components (i.e. 1) by
giving "-p<n>", but the logic for doing so was built around the
notion of "we skip N slashes and stop".  This obviously does not
work well when running under -p0 where we do not want to skip any,
but still want to skip SP/HT that separates the pathnames of
preimage and postimage and want to reject absolute pathnames.

Stop using "stop_at_slash()", and instead introduce a new helper
"skip_tree_prefix()" with similar logic but works correctly even for
the -p0 case.

This is an ancient bug, but has been masked for a long time because
most of the patches are text and have other clues to tell us the
name of the preimage and the postimage.

Noticed by Colin McCabe.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-24 23:11:05 -07:00
Junio C Hamano
871e293c9a Merge branch 'maint-1.7.11' into maint
* maint-1.7.11:
  Prepare for 1.7.11.6
  Make the ciabot scripts completely self-configuring in the normal case.
  Improved documentation for the ciabot scripts.
  man: git pull -r is a short for --rebase
  gitcli: describe abbreviation of long options
  rev-list docs: clarify --topo-order description
  Documentation/CodingGuidelines: spell out more shell guidelines
  Documentation: do not mention .git/refs/* directories
  tests: Introduce test_seq
2012-08-24 12:34:19 -07:00
Junio C Hamano
c247d76c54 Merge branch 'mk/test-seq' into maint-1.7.11
Add a compatibility/utility function to the test framework.

* mk/test-seq:
  tests: Introduce test_seq
2012-08-24 12:05:24 -07:00
Stefan Zager
01d4721565 Make 'git submodule update --force' always check out submodules.
Currently, it will only do a checkout if the sha1 registered in the containing
repository doesn't match the HEAD of the submodule, regardless of whether the
submodule is dirty.  As discussed on the mailing list, the '--force' flag is a
strong indicator that the state of the submodule is suspect, and should be reset
to HEAD.

Signed-off-by: Stefan Zager <szager@google.com>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-24 09:00:43 -07:00
Junio C Hamano
003c84f6d2 specifying ranges: we did not mean to make ".." an empty set
Either end of revision range operator can be omitted to default to HEAD,
as in "origin.." (what did I do since I forked) or "..origin" (what did
they do since I forked).  But the current parser interprets ".."  as an
empty range "HEAD..HEAD", and worse yet, because ".." does exist on the
filesystem, we get this annoying output:

  $ cd Documentation/howto
  $ git log .. ;# give me recent commits that touch Documentation/ area.
  fatal: ambiguous argument '..': both revision and filename
  Use '--' to separate filenames from revisions

Surely we could say "git log ../" or even "git log -- .." to disambiguate,
but we shouldn't have to.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-23 14:37:49 -07:00
Michael J Gruber
308566eb8b t3910: use the UTF8_NFD_TO_NFC test prereq
Besides reusing the new test prerequisite, this fixes also the issue
that the current output is not TAP compliant and produces the output "no
reason given" [for skipping].

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-22 11:50:50 -07:00
Kacper Kornet
3b51222cec for-each-ref: Fix sort with multiple keys
The linked list describing sort options was not correctly set up in
opt_parse_sort. In the result, contrary to the documentation, only the
last of multiple --sort options to git-for-each-ref was taken into
account. This commit fixes it.

Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-21 14:42:12 -07:00