Junio C Hamano [Wed, 15 Jan 2014 20:26:13 +0000 (12:26 -0800)]
revision: propagate flag bits from tags to pointees
With the previous fix 895c5ba3 (revision: do not peel tags used in
range notation, 2013-09-19), handle_revision_arg() that processes
command line arguments for the "git log" family of commands no
longer directly places the object pointed by the tag in the pending
object array when it sees a tag object. We used to place pointee
there after copying the flag bits like UNINTERESTING and
SYMMETRIC_LEFT.
This change meant that any flag that is relevant to later history
traversal must now be propagated to the pointed objects (most often
these are commits) while starting the traversal, which is partly
done by handle_commit() that is called from prepare_revision_walk().
We did propagate UNINTERESTING, but did not do so for others, most
notably SYMMETRIC_LEFT. This caused "git log --left-right v1.0..."
(where "v1.0" is a tag) to start losing the "leftness" from the
commit the tag points at.
Junio C Hamano [Wed, 15 Jan 2014 23:38:01 +0000 (15:38 -0800)]
revision: mark contents of an uninteresting tree uninteresting
"git rev-list --objects ^A^{tree} B^{tree}" ought to mean "I want a
list of objects inside B's tree, but please exclude the objects that
appear inside A's tree".
we see the top-level tree marked as uninteresting (i.e. ^A^{tree} in
the above example) and call mark_tree_uninteresting() on it; this
unfortunately prevents us from recursing into the tree and marking
the objects in the tree as uninteresting.
The reason why "git log ^A A" yields an empty set of commits,
i.e. we do not have a similar issue for commits, is because we call
mark_parents_uninteresting() after seeing an uninteresting commit.
The uninteresting-ness of the commit itself does not prevent its
parents from being marked as uninteresting.
Introduce mark_tree_contents_uninteresting() and structure the code
in handle_commit() in such a way that it makes it the responsibility
of the callchain leading to this function to mark commits, trees and
blobs as uninteresting, and also make it the responsibility of the
helpers called from this function to mark objects that are reachable
from them.
Note that this is a very old bug that probably dates back to the day
when "rev-list --objects" was introduced. The line to clear
tree->object.parsed at the end of mark_tree_contents_uninteresting()
can be removed when this fix is merged to the codebase after 6e454b9a (clear parsed flag when we free tree buffers, 2013-06-05).
Junio C Hamano [Thu, 19 Sep 2013 21:20:34 +0000 (14:20 -0700)]
revision: do not peel tags used in range notation
A range notation "A..B" means exactly the same thing as what "^A B"
means, i.e. the set of commits that are reachable from B but not
from A. But the internal representation after the revision parser
parsed these two notations are subtly different.
- "rev-list ^A B" leaves A and B in the revs->pending.objects[]
array, with the former marked as UNINTERESTING and the revision
traversal machinery propagates the mark to underlying commit
objects A^0 and B^0.
- "rev-list A..B" peels tags and leaves A^0 (marked as
UNINTERESTING) and B^0 in revs->pending.objects[] array before
the traversal machinery kicks in.
This difference usually does not matter, but starts to matter when
the --objects option is used. For example, we see this:
With the former invocation, the revision traversal machinery never
hears about the tag v1.8.4 (it only sees the result of peeling it,
i.e. the commit v1.8.4^0), and the tag itself does not appear in the
output. The latter does send the tag object itself to the output.
Make the range notation keep the unpeeled objects and feed them to
the traversal machinery to fix this inconsistency.
Junio C Hamano [Thu, 27 Dec 2012 23:38:34 +0000 (15:38 -0800)]
Merge branch 'sl/maint-git-svn-docs' into maint
* sl/maint-git-svn-docs:
git-svn: Note about tags.
git-svn: Expand documentation for --follow-parent
git-svn: Recommend use of structure options.
git-svn: Document branches with at-sign(@).
Sebastian Leske [Fri, 23 Nov 2012 07:29:38 +0000 (08:29 +0100)]
git-svn: Note about tags.
Document that 'git svn' will import SVN tags as branches.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sebastian Leske [Fri, 30 Nov 2012 07:16:30 +0000 (08:16 +0100)]
git-svn: Expand documentation for --follow-parent
Describe what the option --follow-parent does, and what happens if it is
set or unset.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sebastian Leske [Fri, 30 Nov 2012 07:16:30 +0000 (08:16 +0100)]
git-svn: Recommend use of structure options.
Document that when using git svn, one should usually either use the
directory structure options to import branches as branches, or only
import one subdirectory. The default behaviour of cloning all branches
and tags as subdirectories in the working copy is usually not what the
user wants.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sebastian Leske [Fri, 30 Nov 2012 07:16:30 +0000 (08:16 +0100)]
git-svn: Document branches with at-sign(@).
git svn sometimes creates branches with an at-sign in the name
(branchname@revision). These branches confuse many users and it is a FAQ
why they are created. Document when git svn creates them.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Max Horn [Tue, 27 Nov 2012 23:03:21 +0000 (00:03 +0100)]
git-remote-helpers.txt: document invocation before input format
In the distant past, the order things were documented was
'Invocation', 'Commands', 'Capabilities', ...
Then it was decided that before giving a list of Commands, there
should be an overall description of the 'Input format', which was
a wise decision. However, this description was put as the very
first thing, with the rationale that any implementor would want
to know that first.
However, it seems an implementor would actually first need to
know how the remote helper will be invoked, so moving
'Invocation' to the front again seems logical. Moreover, we now
don't switch from discussing the input format to the invocation
style and then back to input related stuff.
Signed-off-by: Max Horn <max@quendi.de> Acked-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: move diff.wordRegex from config.txt to diff-config.txt
19299a8 (Documentation: Move diff.<driver>.* from config.txt to
diff-config.txt, 2011-04-07) moved the diff configuration options to
diff-config.txt, but forgot about diff.wordRegex, which was left
behind in config.txt. Fix this.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sun, 23 Dec 2012 04:36:42 +0000 (20:36 -0800)]
Merge branch 'jk/mailmap-cleanup' into maint
* jk/mailmap-cleanup:
contrib: update stats/mailmap script
.mailmap: normalize emails for Linus Torvalds
.mailmap: normalize emails for Jeff King
.mailmap: fix broken entry for Martin Langhoff
.mailmap: match up some obvious names/emails
Junio C Hamano [Sun, 23 Dec 2012 04:35:34 +0000 (20:35 -0800)]
Merge branch 'ta/doc-cleanup' into maint
* ta/doc-cleanup:
Documentation: build html for all files in technical and howto
Documentation/howto: convert plain text files to asciidoc
Documentation/technical: convert plain text files to asciidoc
Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt
Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1
Split over-long synopsis in git-fetch-pack.txt into several lines
As it was not a common operation, it was described as if it is a
side note for the more common two-commit variant, but this mode
behaves very differently, e.g. it does not make any sense to ask
recursive behaviour, or give the command a pathspec.
Junio C Hamano [Tue, 18 Dec 2012 19:26:24 +0000 (11:26 -0800)]
t7004: do not create unneeded gpghome/gpg.conf when GPG is not used
These tests themselves are properly protected by the GPG
prerequisite, but one of the set-up steps outside the
test_expect_success block unconditionally assumed that there is a
gpghome/ directory, which is not true if GPG is not being used.
It may be a good idea to move the whole set-up steps in the test but
that is a follow-up topic.
Chris Rorvick [Mon, 17 Dec 2012 06:45:01 +0000 (00:45 -0600)]
Documentation/git-checkout.txt: clarify usage
The forms of checkout that do not take a path are lumped together in
the DESCRIPTION section, but the description for this group is
dominated by explanation of the -b|-B form.
Split these apart for more clarity.
Signed-off-by: Chris Rorvick <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Tue, 18 Dec 2012 18:50:07 +0000 (10:50 -0800)]
Merge branch 'jk/pickaxe-textconv' into maint
"git log -p -S<string>" now looks for the <string> after applying
the textconv filter (if defined); earlier it inspected the contents
of the blobs without filtering.
Adam Spiers [Sun, 16 Dec 2012 19:35:59 +0000 (19:35 +0000)]
SubmittingPatches: add convention of prefixing commit messages
Conscientious newcomers to git development will read SubmittingPatches
and CodingGuidelines, but could easily miss the convention of
prefixing commit messages with a single word identifying the file
or area the commit touches.
Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
John Keeping [Sun, 16 Dec 2012 14:00:29 +0000 (14:00 +0000)]
Documentation: don't link to example mail addresses
Email addresses in documentation are converted into mailto: hyperlinks
in the HTML output and footnotes in man pages. This isn't desirable for
cases where the address is used as an example and is not valid.
Particularly annoying is the example "jane@laptop.(none)" which appears
in git-shortlog(1) as "jane@laptop[1].(none)", with note 1 saying:
1. jane@laptop
mailto:jane@laptop
Fix this by escaping these email addresses with a leading backslash, to
prevent Asciidoc expanding them as inline macros.
In the case of mailmap.txt, render the address monospaced so that it
matches the block examples surrounding that paragraph.
Helped-by: Jeff King <peff@peff.net> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sun, 16 Dec 2012 06:24:10 +0000 (22:24 -0800)]
README: it does not matter who the current maintainer is
The audience of this introductory document does not have to know nor
interact with the maintainer, so drop the mention of him. Other
documents such as SubmittingPatches may be a more suitable place to
have it.
Junio C Hamano [Fri, 14 Dec 2012 00:19:45 +0000 (16:19 -0800)]
fetch --tags: clarify documentation
Explain that --tags is just like another explicit refspec on the
command line and as such overrides the default refspecs configured
via the remote.$name.fetch variable.
Manlio Perillo [Thu, 13 Dec 2012 17:57:19 +0000 (18:57 +0100)]
git.txt: add missing info about --git-dir command-line option
Unlike other environment variables (e.g. GIT_WORK_TREE, GIT_NAMESPACE),
the Documentation/git.txt file did not mention that the GIT_DIR
environment variable can also be set using the --git-dir command line
option.
Signed-off-by: Manlio Perillo <manlio.perillo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
A cache-tree entry with a negative entry count is considered invalid
by the current Git; it records that we do not know the object name
of a tree that would result by writing the directory covered by the
cache-tree as a tree object.
Clarify that any entry with a negative entry count is invalid, but
the implementations must write -1 there. This way, we can later
decide to allow writers to use negative values other than -1 to
encode optional information on such invalidated entries without
harming interoperability; we do not know what will be encoded and
how, so we keep these other negative values as reserved for now.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Wed, 12 Dec 2012 11:41:41 +0000 (06:41 -0500)]
contrib: update stats/mailmap script
This version changes quite a few things:
1. The original parsed the mailmap file itself, and it did
it wrong (it did not understand entries with an extra
email key).
Instead, this version uses git's "%aE" and "%aN"
formats to have git perform the mapping, meaning we do
not have to read .mailmap at all, but still operate on
the current state that git sees (and it also works
properly from subdirs).
2. The original would find multiple names for an email,
but not the other way around.
This version can do either or both. If we find multiple
emails for a name, the resolution is less obvious than
the other way around. However, it can still be a
starting point for a human to investigate.
3. The original would order only by count, not by recency.
This version can do either. Combined with showing the
counts, it can be easier to decide how to resolve.
4. This version shows similar entries in a blank-delimited
stanza, which makes it more clear which options you are
picking from.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Wed, 12 Dec 2012 11:41:04 +0000 (06:41 -0500)]
.mailmap: normalize emails for Linus Torvalds
Linus used a lot of different per-machine email addresses in
the early days. This means that "git shortlog -nse" does not
aggregate his counts, and he is listed well below where he
should be (8th instead of 3rd).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Wed, 12 Dec 2012 11:38:06 +0000 (06:38 -0500)]
.mailmap: fix broken entry for Martin Langhoff
Commit adc3192 (Martin Langhoff has a new e-mail address,
2010-10-05) added a mailmap entry, but forgot that both the
old and new email addresses need to appear for one to be
mapped to the other (i.e., we do not key mailmap emails by
name).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Wed, 12 Dec 2012 11:36:35 +0000 (06:36 -0500)]
.mailmap: match up some obvious names/emails
This patch updates git's .mailmap in cases where multiple
names are matched to a single email. The "master" name for
each email was chosen by:
1. If the only difference is in the presence or absence
of accented characters, the accented form is chosen
(under the assumption that it is the natural spelling,
and accents are sometimes stripped in email).
2. Otherwise, the most commonly used name is chosen.
3. If all names are equally common, the most recently used name is
chosen.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Fri, 7 Dec 2012 17:54:50 +0000 (09:54 -0800)]
git(1): remove a defunct link to "list of authors"
The linked page has not been showing the promised "more complete
list" for more than 6 months by now, and nobody has resurrected
the list there nor elsewhere since then.
Junio C Hamano [Fri, 7 Dec 2012 22:10:56 +0000 (14:10 -0800)]
Merge branch 'jc/same-encoding' into maint
Various codepaths checked if two encoding names are the same using
ad-hoc code and some of them ended up asking iconv() to convert
between "utf8" and "UTF-8". The former is not a valid way to spell
the encoding name, but often people use it by mistake, and we
equated them in some but not all codepaths. Introduce a new helper
function to make these codepaths consistent.
* jc/same-encoding:
reencode_string(): introduce and use same_encoding()
Junio C Hamano [Fri, 7 Dec 2012 22:10:17 +0000 (14:10 -0800)]
Merge branch 'lt/diff-stat-show-0-lines' into maint
"git diff --stat" miscounted the total number of changed lines when
binary files were involved and hidden beyond --stat-count. It also
miscounted the total number of changed files when there were
unmerged paths.
* lt/diff-stat-show-0-lines:
t4049: refocus tests
diff --shortstat: do not count "unmerged" entries
diff --stat: do not count "unmerged" entries
diff --stat: move the "total count" logic to the last loop
diff --stat: use "file" temporary variable to refer to data->files[i]
diff --stat: status of unmodified pair in diff-q is not zero
test: add failing tests for "diff --stat" to t4049
Fix "git diff --stat" for interesting - but empty - file changes
Matthieu Moy [Thu, 29 Nov 2012 19:11:32 +0000 (20:11 +0100)]
git-fast-import.txt: improve documentation for quoted paths
The documentation mentioned only newlines and double quotes as
characters needing escaping, but the backslash also needs it. Also, the
documentation was not clearly saying that double quotes around the file
name were required (double quotes in the examples could be interpreted as
part of the sentence, not part of the actual string).
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Matthieu Moy [Thu, 29 Nov 2012 17:00:55 +0000 (18:00 +0100)]
git-remote-mediawiki: escape ", \, and LF in file names
A mediawiki page can contain, and even start with a " character, we have
to escape it when generating the fast-export stream, as well as \
character. While we're there, also escape newlines, but I don't think we
can get them from MediaWiki pages.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Thu, 29 Nov 2012 17:46:30 +0000 (09:46 -0800)]
t4049: refocus tests
The primary thing Linus's patch wanted to change was to make sure
that 0-line change appears for a mode-only change. Update the
first test to chmod a file that we can see in the output (limited
by --stat-count) to demonstrate it. Also make sure to use test_chmod
and compare the index and the tree, so that we can run this test
even on a filesystem without permission bits.
Later two tests are about fixes to separate issues that were
introduced and/or uncovered by Linus's patch as a side effect, but
the issues are not related to mode-only changes. Remove chmod from
the tests.
Junio C Hamano [Tue, 27 Nov 2012 23:52:27 +0000 (15:52 -0800)]
Documentation/git-push.txt: clarify the "push from satellite" workflow
The context of the example to push into refs/remotes/satellite/
hierarchy of the other repository needs to be spelled out explicitly
for the value of this example to be fully appreciated. Make it so.
Junio C Hamano [Tue, 27 Nov 2012 21:28:45 +0000 (13:28 -0800)]
Merge branch 'jh/update-ref-d-through-symref' into maint
* jh/update-ref-d-through-symref:
Fix failure to delete a packed ref through a symref
t1400-update-ref: Add test verifying bug with symrefs in delete_ref()
Junio C Hamano [Tue, 27 Nov 2012 20:05:10 +0000 (12:05 -0800)]
diff --stat: do not count "unmerged" entries
Even though we show a separate *UNMERGED* entry in the patch and
diffstat output (or in the --raw format, for that matter) in
addition to and separately from the diff against the specified stage
(defaulting to #2) for unmerged paths, they should not be counted in
the total number of files affected---that would lead to counting the
same path twice.
The separation done by the previous step makes this fix simple and
straightforward. Among the filepairs in diff_queue, paths that
weren't modified, and the extra "unmerged" entries do not count as
total number of files.
Junio C Hamano [Tue, 27 Nov 2012 19:47:46 +0000 (11:47 -0800)]
diff --stat: move the "total count" logic to the last loop
The diffstat generation logic, with --stat-count limit, is
implemented as three loops.
- The first counts the width necessary to show stats up to
specified number of entries, and notes up to how many entries in
the data we need to iterate to show the graph;
- The second iterates that many times to draw the graph, adjusts
the number of "total modified files", and counts the total
added/deleted lines for the part that was shown in the graph;
- The third iterates over the remainder and only does the part to
count "total added/deleted lines" and to adjust "total modified
files" without drawing anything.
Move the logic to count added/deleted lines and modified files from
the second loop to the third loop.
This incidentally fixes a bug. The third loop was not filtering
binary changes (counted in bytes) from the total added/deleted as it
should. The second loop implemented this correctly, so if a binary
change appeared earlier than the --stat-count cutoff, the code
counted number of added/deleted lines correctly, but if it appeared
beyond the cutoff, the number of lines would have mixed with the
byte count in the buggy third loop.
Junio C Hamano [Tue, 27 Nov 2012 20:55:00 +0000 (12:55 -0800)]
test: add failing tests for "diff --stat" to t4049
There are a few problems in diff.c around --stat area, partially
caused by the recent 74faaa1 (Fix "git diff --stat" for interesting
- but empty - file changes, 2012-10-17), and largely caused by the
earlier change that introduced when --stat-count was added.
Add a few test pieces to t4049 to expose the issues.
Mark Szepieniec [Tue, 27 Nov 2012 01:37:34 +0000 (01:37 +0000)]
Documentation: improve phrasing in git-push.txt
The current version contains the sentence:
Further suppose that the other person already pushed changes leading to
A back to the original repository you two obtained the original commit
X.
which doesn't parse for me; I've changed it to
Further suppose that the other person already pushed changes leading to
A back to the original repository from which you two obtained the
original commit X.
Signed-off-by: Mark Szepieniec <mszepien@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Paul Gortmaker [Thu, 22 Nov 2012 03:19:57 +0000 (22:19 -0500)]
Makefile: hide stderr of curl-config test
You will get
$ make distclean 2>&1 | grep curl
/bin/sh: curl-config: not found
/bin/sh: curl-config: not found
/bin/sh: curl-config: not found
/bin/sh: curl-config: not found
/bin/sh: curl-config: not found
$
if you don't have a curl development package installed.
The intent is not to alarm the user, but just to test if there is
a new enough curl installed. However, if you look at search engine
suggested completions, the above "error" messages are confusing
people into thinking curl is a hard requirement.
Redirect this error output to /dev/null as it is not necessary to be
shown to the end users.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Marc Khouzam [Fri, 23 Nov 2012 14:02:22 +0000 (09:02 -0500)]
Completion must sort before using uniq
The user can be presented with invalid completion results
when trying to complete a 'git checkout' command. This can happen
when using a branch name prefix that matches multiple remote branches.
For example, if available branches are:
master
remotes/GitHub/maint
remotes/GitHub/master
remotes/origin/maint
remotes/origin/master
When performing completion on 'git checkout ma' the user will be
given the choices:
maint
master
However, 'git checkout maint' will fail in this case, although
completion previously said 'maint' was valid. Furthermore, when
performing completion on 'git checkout mai', no choices will be
suggested. So, the user is first told that the branch name
'maint' is valid, but when trying to complete 'mai' into 'maint',
that completion is no longer valid.
The completion results should never propose 'maint' as a valid
branch name, since 'git checkout' will refuse it.
The reason for this bug is that the uniq program only
works with sorted input. The man page states
"uniq prints the unique lines in a sorted file".
When __git_refs uses the guess heuristic employed by checkout for
tracking branches it wants to consider remote branches but only if
the branch name is unique. To do that, it calls 'uniq -u'. However
the input given to 'uniq -u' is not sorted.
Therefore, in the above example, when dealing with 'git checkout ma',
"__git_refs '' 1" will find the following list:
master
maint
master
maint
master
which, when passed to 'uniq -u' will remain the same. Therefore
'maint' will be wrongly suggested as a valid option.
When dealing with 'git checkout mai', the list will be:
maint
maint
which happens to be sorted and will be emptied by 'uniq -u',
properly ignoring 'maint'.
A solution for preventing the completion script from suggesting
such invalid branch names is to first call 'sort' and then 'uniq -u'.
Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com> Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
compat/fnmatch: fix off-by-one character class's length check
Character class "xdigit" is the only one that hits 6 character limit
defined by CHAR_CLASS_MAX_LENGTH. All other character classes are 5
character long and therefore never caught by this.
This should make xdigit tests in t3070 pass on Windows.
Reported-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Tue, 20 Nov 2012 17:57:44 +0000 (09:57 -0800)]
Merge branch 'js/format-2047' into maint
Various rfc2047 quoting issues around a non-ASCII name on the From:
line in the output from format-patch have been corrected.
* js/format-2047:
format-patch tests: check quoting/encoding in To: and Cc: headers
format-patch: fix rfc2047 address encoding with respect to rfc822 specials
format-patch: make rfc2047 encoding more strict
format-patch: introduce helper function last_line_length()
format-patch: do not wrap rfc2047 encoded headers too late
format-patch: do not wrap non-rfc2047 headers too early
utf8: fix off-by-one wrapping of text
Junio C Hamano [Mon, 19 Nov 2012 03:44:36 +0000 (19:44 -0800)]
Merge branch 'sz/maint-curl-multi-timeout' into maint
Sometimes curl_multi_timeout() function suggested a wrong timeout
value when there is no file descriptors to wait on and the http
transport ended up sleeping for minutes in select(2) system call. A
workaround has been added for this.
* sz/maint-curl-multi-timeout:
Fix potential hang in https handshake
Junio C Hamano [Mon, 19 Nov 2012 03:33:45 +0000 (19:33 -0800)]
Merge branch 'ph/pull-rebase-detached' into maint
"git pull --rebase" run while the HEAD is detached tried to find
the upstream branch of the detached HEAD (which by definition
does not exist) and emitted unnecessary error messages.
* ph/pull-rebase-detached:
git-pull: Avoid merge-base on detached head
Junio C Hamano [Mon, 19 Nov 2012 03:32:58 +0000 (19:32 -0800)]
Merge branch 'rs/branch-del-symref' into maint
A symbolic ref refs/heads/SYM was not correctly removed with "git
branch -d SYM"; the command removed the ref pointed by SYM instead.
* rs/branch-del-symref:
branch: show targets of deleted symrefs, not sha1s
branch: skip commit checks when deleting symref branches
branch: delete symref branch, not its target
branch: factor out delete_branch_config()
branch: factor out check_branch_commit()
Junio C Hamano [Mon, 19 Nov 2012 03:32:11 +0000 (19:32 -0800)]
Merge branch 'jc/grep-pcre-loose-ends' (early part) into maint
"git log -F -E --grep='<ere>'" failed to use the given <ere>
pattern as extended regular expression, and instead looked for the
string literally.
* 'jc/grep-pcre-loose-ends' (early part):
log --grep: use the same helper to set -E/-F options as "git grep"
revisions: initialize revs->grep_filter using grep_init()
grep: move pattern-type bits support to top-level grep.[ch]
grep: move the configuration parsing logic to grep.[ch]
builtin/grep.c: make configuration callback more reusable
Junio C Hamano [Mon, 19 Nov 2012 03:31:40 +0000 (19:31 -0800)]
Merge branch 'da/mergetools-p4' into maint
"git mergetool" feeds /dev/null as a common ancestor when dealing
with an add/add conflict, but p4merge backend cannot handle it. Work
it around by passing a temporary empty file.
projects / thirdparty / git.git / log
