Commit Graph

32791 Commits

Author SHA1 Message Date
Johan Herland
fef0e991aa Refer to branch.<name>.remote/merge when documenting --track
Make it easier for readers to find the actual config variables that
implement the "upstream" relationship.

Suggested-by: Per Cederqvist <cederp@opera.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09 11:03:01 -07:00
Johan Herland
81f339dc3d t3200: Minor fix when preparing for tracking failure
We're testing that trying to --track a ref that is not covered by any remote
refspec should fail. For that, we want to have refs/remotes/local/master
present, but we also want the remote.local.fetch refspec to NOT match
refs/remotes/local/master (so that the tracking setup will fail, as intended).
However, when doing "git fetch local" to ensure the existence of
refs/remotes/local/master, we must not already have changed remote.local.fetch
so as to cause refs/remotes/local/master not to be fetched. Therefore, set
remote.local.fetch to refs/heads/*:refs/remotes/local/* BEFORE we fetch, and
then reset it to refs/heads/s:refs/remotes/local/s AFTER we have fetched
(but before we test --track).

Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09 11:02:52 -07:00
Johan Herland
5a517b1c4c t2024: Fix &&-chaining and a couple of typos
Improved-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09 11:02:29 -07:00
Johan Herland
229177aaea glossary: Update and rephrase the definition of a remote-tracking branch
The definition of a remote-tracking branch in the glossary have been
out-of-date for a while (by e.g. referring to "Pull:" from old-style
$GIT_DIR/remotes files).

Also, the preceding patches have formalized that a remote-tracking branch
must match a configured refspec in order to be usable as an upstream.

This patch rewrites the paragraph on remote-tracking branches accordingly.

Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21 15:14:42 -07:00
Johan Herland
41c21f22d0 branch.c: Validate tracking branches with refspecs instead of refs/remotes/*
The current code for validating tracking branches (e.g. the argument to
the -t/--track option) hardcodes refs/heads/* and refs/remotes/* as the
potential locations for tracking branches. This works with the refspecs
created by "git clone" or "git remote add", but is suboptimal in other
cases:

 - If "refs/remotes/foo/bar" exists without any association to a remote
   (i.e. there is no remote named "foo", or no remote with a refspec
   that matches "refs/remotes/foo/bar"), then it is impossible to set up
   a valid upstream config that tracks it. Currently, the code defaults
   to using "refs/remotes/foo/bar" from repo "." as the upstream, which
   works, but is probably not what the user had in mind when running
   "git branch baz --track foo/bar".

 - If the user has tweaked the fetch refspec for a remote to put its
   remote-tracking branches outside of refs/remotes/*, e.g. by running
       git config remote.foo.fetch "+refs/heads/*:refs/foo_stuff/*"
   then the current code will refuse to use its remote-tracking branches
   as --track arguments, since they do not match refs/remotes/*.

This patch removes the "refs/remotes/*" requirement for upstream branches,
and replaces it with explicit checking of the refspecs for each remote to
determine whether a given --track argument is a valid remote-tracking
branch. This solves both of the above problems, since the matching refspec
guarantees that there is a both a remote name and a remote branch name
that can be used for the upstream config.

However, this means that refs located within refs/remotes/* without a
corresponding remote/refspec will no longer be usable as upstreams.
The few existing tests which depended on this behavioral quirk has
already been fixed in the preceding patches.

This patch fixes the last remaining test failure in t2024-checkout-dwim.

Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21 15:14:42 -07:00
Johan Herland
983b17d4bb t9114.2: Don't use --track option against "svn-remote"-tracking branches
We are formalizing a requirement that any remote-tracking branch to be used
as an upstream (i.e. as an argument to --track), _must_ "belong" to a
configured remote by being matched by the "dst" side of a fetch refspec.

This test uses --track against a "remotes/trunk" ref which does not belong
to any configured (git) remotes, but is instead created by "git svn fetch"
operating on an svn-remote. It does not make sense to use an svn-remote as
an upstream for a local branch, as a regular "git pull" from (or "git push"
to) it would obviously fail (instead you would need to use "git svn" to
communicate with this remote). Furthermore, the usage of --track in this
case is unnecessary, since the upstreaming config that would be created is
never used.

Simply removing --track fixes the issue without changing the expected
behavior of the test.

Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21 15:14:41 -07:00
Johan Herland
88a9f72fe0 t7201.24: Add refspec to keep --track working
We are formalizing a requirement that any remote-tracking branch to be used
as an upstream (i.e. as an argument to --track), _must_ "belong" to a
configured remote by being matched by the "dst" side of a fetch refspec.

Without this patch, this test would start failing when the new behavior is
introduced.

Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21 15:14:41 -07:00
Johan Herland
9c9cd39a0c t3200.39: tracking setup should fail if there is no matching refspec.
We are formalizing a requirement that any remote-tracking branch to be used
as an upstream (i.e. as an argument to --track), _must_ "belong" to a
configured remote by being matched by the "dst" side of a fetch refspec.

This patch encodes the new expected behavior of this test, and marks the
test with "test_expect_failure" in anticipation of a following patch to
introduce the new behavior.

Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21 15:14:41 -07:00
Johan Herland
fa83a33b22 checkout: Use remote refspecs when DWIMming tracking branches
The DWIM mode of checkout allows you to run "git checkout foo" when there
is no existing local ref or path called "foo", and there is exactly _one_
remote with a remote-tracking branch called "foo". Git will automatically
create a new local branch called "foo" using the remote-tracking "foo" as
its starting point and configured upstream.

For example, consider the following unconventional (but perfectly valid)
remote setup:

	[remote "origin"]
		fetch = refs/heads/*:refs/remotes/origin/*
	[remote "frotz"]
		fetch = refs/heads/*:refs/remotes/frotz/nitfol/*

Case 1: Assume both "origin" and "frotz" have remote-tracking branches called
"foo", at "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo"
respectively. In this case "git checkout foo" should fail, because there is
more than one remote with a "foo" branch.

Case 2: Assume only "frotz" have a remote-tracking branch called "foo". In
this case "git checkout foo" should succeed, and create a local branch "foo"
from "refs/remotes/frotz/nitfol/foo", using remote branch "foo" from "frotz"
as its upstream.

The current code hardcodes the assumption that all remote-tracking branches
must match the "refs/remotes/$remote/*" pattern (which is true for remotes
with "conventional" refspecs, but not true for the "frotz" remote above).
When running "git checkout foo", the current code looks for exactly one ref
matching "refs/remotes/*/foo", hence in the above example, it fails to find
"refs/remotes/frotz/nitfol/foo", which causes it to fail both case #1 and #2.

The better way to handle the above example is to actually study the fetch
refspecs to deduce the candidate remote-tracking branches for "foo"; i.e.
assume "foo" is a remote branch being fetched, and then map "refs/heads/foo"
through the refspecs in order to get the corresponding remote-tracking
branches "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo".
Finally we check which of these happens to exist in the local repo, and
if there is exactly one, we have an unambiguous match for "git checkout foo",
and may proceed.

This fixes most of the failing tests introduced in the previous patch.

Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21 15:14:41 -07:00
Johan Herland
ec2764ee8f t2024: Show failure to use refspec when DWIMming remote branch names
When using "git checkout foo" to DWIM the creation of local "foo" from some
existing upstream "foo", we assume conventional refspecs as created by "git
clone" or "git remote add", and fail to work correctly if the current
refspecs do not follow the conventional "refs/remotes/$remote/*" pattern.

Improved-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21 15:14:40 -07:00
Johan Herland
399e4a1c56 t2024: Add tests verifying current DWIM behavior of 'git checkout <branch>'
The DWIM mode of checkout allows you to run "git checkout foo" when there is
no existing local ref or path called "foo", and there is exactly one remote
with a remote-tracking branch called "foo". Git will then automatically
create a new local branch called "foo" using the remote-tracking "foo" as
its starting point and configured upstream.

Improved-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-21 15:14:40 -07:00
Junio C Hamano
d2949c7b3c Update draft release notes to 1.8.3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-19 13:53:44 -07:00
Junio C Hamano
9526aa461f Merge branch 'jk/a-thread-only-dies-once'
A regression fix for the logic to detect die() handler triggering
itself recursively.

* jk/a-thread-only-dies-once:
  run-command: use thread-aware die_is_recursing routine
  usage: allow pluggable die-recursion checks
2013-04-19 13:45:05 -07:00
Junio C Hamano
6ae5d9863b Merge branch 'rt/commentchar-fmt-merge-msg'
A test fix for recent update.

* rt/commentchar-fmt-merge-msg:
  t6200: avoid path mangling issue on Windows
2013-04-19 13:45:01 -07:00
Junio C Hamano
4407ea49fe Merge branch 'mv/sequencer-pick-error-diag'
"git cherry-pick $blob $tree" is diagnosed as a nonsense.

* mv/sequencer-pick-error-diag:
  cherry-pick: make sure all input objects are commits
2013-04-19 13:40:23 -07:00
Junio C Hamano
8d41addacb Merge branch 'tr/copy-revisions-from-stdin'
A fix to a long-standing issue in the command line parser for
revisions, which was triggered by mv/sequence-pick-error-diag topic.

* tr/copy-revisions-from-stdin:
  read_revisions_from_stdin: make copies for handle_revision_arg
2013-04-19 13:40:13 -07:00
Junio C Hamano
de91daf5e6 Merge branch 'jn/add-2.0-u-A-sans-pathspec' (early part)
In Git 2.0, "git add -u" and "git add -A" without any pathspec will
update the index for all paths, including those outside the current
directory, making it more consistent with "commit -a".  To help the
migration pain, a warning is issued when the differences between the
current behaviour and the upcoming behaviour matters, i.e. when the
user has local changes outside the current directory.

* 'jn/add-2.0-u-A-sans-pathspec' (early part):
  add -A: only show pathless 'add -A' warning when changes exist outside cwd
  add -u: only show pathless 'add -u' warning when changes exist outside cwd
  add: make warn_pathless_add() a no-op after first call
  add: add a blank line at the end of pathless 'add [-u|-A]' warning
  add: make pathless 'add [-u|-A]' warning a file-global function
2013-04-19 13:37:36 -07:00
Junio C Hamano
d7bffe9fb6 Merge branch 'ap/strbuf-humanize'
Teach "--human-readable" aka "-H" option to "git count-objects" to
show various large numbers in Ki/Mi/GiB scaled as necessary.

* ap/strbuf-humanize:
  count-objects: add -H option to humanize sizes
  strbuf: create strbuf_humanise_bytes() to show byte sizes
2013-04-19 13:31:27 -07:00
Junio C Hamano
4059da3352 Merge branch 'fc/branch-upstream-color'
Add more colors to "git branch -vv" output.

* fc/branch-upstream-color:
  branch: colour upstream branches
2013-04-19 13:31:24 -07:00
Junio C Hamano
574d51b575 Merge branch 'mv/ssl-ftp-curl'
Does anybody really use commit walkers over (s)ftp?

* mv/ssl-ftp-curl:
  Support FTP-over-SSL/TLS for regular FTP
2013-04-19 13:31:08 -07:00
Junio C Hamano
1468a58393 Update draft release notes to 1.8.3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-18 12:03:09 -07:00
Junio C Hamano
c5926ac377 Merge branch 'maint'
* maint:
  remote-hg: fix commit messages
2013-04-18 12:03:01 -07:00
Junio C Hamano
ded56521bd Merge branch 'jk/test-trash'
Fix longstanding issues with the test harness when used with --root=<there>
option.

* jk/test-trash:
  t/test-lib.sh: drop "$test" variable
  t/test-lib.sh: fix TRASH_DIRECTORY handling
2013-04-18 11:49:45 -07:00
Junio C Hamano
da89885c6d Merge branch 'th/t9903-symlinked-workdir'
* th/t9903-symlinked-workdir:
  t9903: Don't fail when run from path accessed through symlink
2013-04-18 11:49:42 -07:00
Junio C Hamano
e7e656c09a Merge branch 'jk/merge-tree-added-identically'
The resolution of some corner cases by "git merge-tree" were
inconsistent between top-of-the-tree and in a subdirectory.

* jk/merge-tree-added-identically:
  merge-tree: don't print entries that match "local"
2013-04-18 11:49:31 -07:00
Junio C Hamano
77354d8cdc Merge branch 'jk/http-dumb-namespaces'
Allow smart-capable HTTP servers to be restricted via the
GIT_NAMESPACE mechanism when talking with commit-walker clients
(they already do so when talking with smart HTTP clients).

* jk/http-dumb-namespaces:
  http-backend: respect GIT_NAMESPACE with dumb clients
2013-04-18 11:49:21 -07:00
Junio C Hamano
1931f6d6ea Merge branch 'rs/empty-archive'
Implementations of "tar" of BSD descend have found to have trouble
with reading an otherwise empty tar archive with pax headers and
causes an unnecessary test failure.

* rs/empty-archive:
  t5004: fix issue with empty archive test and bsdtar
2013-04-18 11:49:17 -07:00
Junio C Hamano
288aa7534a Merge branch 'fc/send-email-annotate'
Allows format-patch --cover-letter to be configurable; the most
notable is the "auto" mode to create cover-letter only for multi
patch series.

* fc/send-email-annotate:
  rebase-am: explicitly disable cover-letter
  format-patch: trivial cleanups
  format-patch: add format.coverLetter configuration variable
  log: update to OPT_BOOL
  format-patch: refactor branch name calculation
  format-patch: improve head calculation for cover-letter
  send-email: make annotate configurable
2013-04-18 11:49:11 -07:00
Junio C Hamano
54a3c67375 Merge branch 'jc/push-2.0-default-to-simple' (early part)
Adjust our tests for upcoming migration of the default value for the
"push.default" configuration variable to "simple" from "mixed".

* 'jc/push-2.0-default-to-simple' (early part):
  t5570: do not assume the "matching" push is the default
  t5551: do not assume the "matching" push is the default
  t5550: do not assume the "matching" push is the default
  t9401: do not assume the "matching" push is the default
  t9400: do not assume the "matching" push is the default
  t7406: do not assume the "matching" push is the default
  t5531: do not assume the "matching" push is the default
  t5519: do not assume the "matching" push is the default
  t5517: do not assume the "matching" push is the default
  t5516: do not assume the "matching" push is the default
  t5505: do not assume the "matching" push is the default
  t5404: do not assume the "matching" push is the default
2013-04-18 11:47:59 -07:00
Junio C Hamano
8dd28584a5 Merge branch 'jk/daemon-user-doc'
Document where the configuration is read by the git-daemon when its --user
option is used.

* jk/daemon-user-doc:
  doc: clarify that "git daemon --user=<user>" option does not export HOME=~user
2013-04-18 11:47:23 -07:00
Junio C Hamano
5734fa4608 Merge branch 'fc/completion'
In addition to a user visible change to offer more options to cherry-pick,
generally cleans up and simplifies the code.

* fc/completion:
  completion: small optimization
  completion: inline __gitcomp_1 to its sole callsite
  completion: get rid of compgen
  completion: add __gitcomp_nl tests
  completion: add new __gitcompadd helper
  completion: get rid of empty COMPREPLY assignments
  completion: trivial test improvement
  completion: add more cherry-pick options
2013-04-18 11:46:42 -07:00
Junio C Hamano
bd1184c6de Merge branch 'kb/co-orphan-suggestion-short-sha1'
Update the informational message when "git checkout" leaves the
detached head state.

* kb/co-orphan-suggestion-short-sha1:
  checkout: abbreviate hash in suggest_reattach
2013-04-18 11:46:33 -07:00
Junio C Hamano
cd797c7e6b Merge branch 'jc/detached-head-doc'
* jc/detached-head-doc:
  glossary: extend "detached HEAD" description
2013-04-18 11:46:29 -07:00
Junio C Hamano
193e28f050 Merge branch 'tr/packed-object-info-wo-recursion'
Attempts to reduce the stack footprint of sha1_object_info()
and unpack_entry() codepaths.

* tr/packed-object-info-wo-recursion:
  sha1_file: remove recursion in unpack_entry
  Refactor parts of in_delta_base_cache/cache_or_unpack_entry
  sha1_file: remove recursion in packed_object_info
2013-04-18 11:46:23 -07:00
Junio C Hamano
80292f2104 Merge branch 'jk/http-error-messages'
A regression fix for the recently graduated topic.

* jk/http-error-messages:
  http: set curl FAILONERROR each time we select a handle
2013-04-18 11:42:08 -07:00
Johannes Sixt
16a794de88 t6200: avoid path mangling issue on Windows
MSYS bash interprets the slash in the argument core.commentchar="/"
as root directory and mangles it into a Windows style path. Use a
different core.commentchar to dodge the issue.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-18 09:56:37 -07:00
Felipe Contreras
845241d544 remote-hg: fix commit messages
git fast-import expects an extra newline after the commit message data,
but we are adding it only on hg-git compat mode, which is why the
bidirectionality tests pass.

We should add it unconditionally.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-17 23:41:25 -07:00
Junio C Hamano
dcd8c09e4d Merge branch 'maint'
* maint:
  help.c: add a compatibility comment to cmd_version()
2013-04-16 15:14:44 -07:00
Jeff King
1ece66bc9e run-command: use thread-aware die_is_recursing routine
If we die from an async thread, we do not actually exit the
program, but just kill the thread. This confuses the static
counter in usage.c's default die_is_recursing function; it
updates the counter once for the thread death, and then when
the main program calls die() itself, it erroneously thinks
we are recursing. The end result is that we print "recursion
detected in die handler" instead of the real error in such a
case (the easiest way to trigger this is having a remote
connection hang up while running a sideband demultiplexer).

This patch solves it by using a per-thread counter when the
async_die function is installed; we detect recursion in each
thread (including the main one), but they do not step on
each other's toes.

Other threaded code does not need to worry about this, as
they do not install specialized die handlers; they just let
a die() from a sub-thread take down the whole program.

Since we are overriding the default recursion-check
function, there is an interesting corner case that is not a
problem, but bears some explanation. Imagine the main thread
calls die(), and then in the die_routine starts an async
call. We will switch to using thread-local storage, which
starts at 0, for the main thread's counter, even though
the original counter was actually at 1. That's OK, though,
for two reasons:

  1. It would miss only the first level of recursion, and
     would still find recursive failures inside the async
     helper.

  2. We do not currently and are not likely to start doing
     anything as heavyweight as starting an async routine
     from within a die routine or helper function.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-16 15:02:48 -07:00
Jeff King
c19a490e37 usage: allow pluggable die-recursion checks
When any git code calls die or die_errno, we use a counter
to detect recursion into the die functions from any of the
helper functions. However, such a simple counter is not good
enough for threaded programs, which may call die from a
sub-thread, killing only the sub-thread (but incrementing
the counter for everyone).

Rather than try to deal with threads ourselves here, let's
just allow callers to plug in their own recursion-detection
function. This is similar to how we handle the die routine
(the caller plugs in a die routine which may kill only the
sub-thread).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-16 15:02:46 -07:00
David Aguilar
f2de0b9793 help.c: add a compatibility comment to cmd_version()
External projects have been known to parse the output of
"git version".  Help prevent future authors from changing
its format by adding a comment to its implementation.

Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-16 15:01:30 -07:00
Jonathan Nieder
95f31e9ab5 convert: The native line-ending is \r\n on MinGW
If you try this:

 1. Install Git for Windows (from the msysgit project)

 2. Put

	[core]
		autocrlf = false
		eol = native

    in your .gitconfig.

 3. Clone a project with

	*.txt text

    in its .gitattributes.

Then with current git, any text files checked out have LF line
endings, instead of the expected CRLF.

Cc: Johannes Schindelin <johannes.schindelin@gmx.de>
Cc: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-16 11:18:35 -07:00
Thomas Rast
70d26c6e76 read_revisions_from_stdin: make copies for handle_revision_arg
read_revisions_from_stdin() has passed pointers to its read buffer
down to handle_revision_arg() since its inception way back in 42cabc3
(Teach rev-list an option to read revs from the standard input.,
2006-09-05).  Even back then, this was a bug: through
add_pending_object, the argument was recorded in the object_array's
'name' field.

Fix it by making a copy whenever read_revisions_from_stdin() passes an
argument down the callchain.  The other caller runs handle_revision_arg()
on argv[], where it would be redundant to make a copy.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-16 11:17:48 -07:00
Jeff King
b793acf14c http: set curl FAILONERROR each time we select a handle
Because we reuse curl handles for multiple requests, the
setup of a handle happens in two stages: stable, global
setup and per-request setup. The lifecycle of a handle is
something like:

  1. get_curl_handle; do basic global setup that will last
     through the whole program (e.g., setting the user
     agent, ssl options, etc)

  2. get_active_slot; set up a per-request baseline (e.g.,
     clearing the read/write functions, making it a GET
     request, etc)

  3. perform the request with curl_*_perform functions

  4. goto step 2 to perform another request

Breaking it down this way means we can avoid doing global
setup from step (1) repeatedly, but we still finish step (2)
with a predictable baseline setup that callers can rely on.

Until commit 6d052d7 (http: add HTTP_KEEP_ERROR option,
2013-04-05), setting curl's FAILONERROR option was a global
setup; we never changed it. However, 6d052d7 introduced an
option where some requests might turn off FAILONERROR. Later
requests using the same handle would have the option
unexpectedly turned off, which meant they would not notice
http failures at all.

This could easily be seen in the test-suite for the
"half-auth" cases of t5541 and t5551. The initial requests
turned off FAILONERROR, which meant it was erroneously off
for the rpc POST. That worked fine for a successful request,
but meant that we failed to react properly to the HTTP 401
(instead, we treated whatever the server handed us as a
successful message body).

The solution is simple: now that FAILONERROR is a
per-request setting, we move it to get_active_slot to make
sure it is reset for each request.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-16 10:13:46 -07:00
Felipe Contreras
afad200558 remote-bzr: fix prefix of tags
In the current transport-helper code, refs without namespaced refspecs don't
work correctly, so let's always use them.

Some people reported issues with 'git clone --mirror', and this fixes them, as
well as possibly others.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-15 16:08:40 -07:00
Junio C Hamano
aec3f77941 Update draft release notes to 1.8.3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-15 12:45:15 -07:00
Junio C Hamano
f678d9b592 Merge branch 'jk/diff-graph-submodule-summary'
Make "git diff --graph" work better with submodule log output.

* jk/diff-graph-submodule-summary:
  submodule: print graph output next to submodule log
2013-04-15 12:41:01 -07:00
Junio C Hamano
825ccfc23c Merge branch 'jk/diff-algo-finishing-touches'
"git diff --diff-algorithm algo" is also understood as "git diff
--diff-algorithm=algo".

* jk/diff-algo-finishing-touches:
  diff: allow unstuck arguments with --diff-algorithm
  git-merge(1): document diff-algorithm option to merge-recursive
2013-04-15 12:40:58 -07:00
Junio C Hamano
948cf4f5e5 Merge branch 'rt/commentchar-fmt-merge-msg'
The new core.commentchar configuration was not applied to a few
places.

* rt/commentchar-fmt-merge-msg:
  fmt-merge-msg: use core.commentchar in tag signatures completely
  fmt-merge-msg: respect core.commentchar in people credits
2013-04-15 12:40:56 -07:00
Junio C Hamano
e1a3f17e9d Merge branch 'lf/bundle-with-tip-wo-message'
"git bundle" did not like a bundle created using a commit without
any message as its one of the prerequistes.

* lf/bundle-with-tip-wo-message:
  bundle: Accept prerequisites without commit messages
2013-04-15 12:40:51 -07:00