We handled the case of removing and re-inserting cache entries badly,
which is something that merging commonly needs to do (removing the
different stages, and then re-inserting one of them as the merged
state).
We even had a rather ugly special case for this failure case, where
replace_index_entry() basically turned itself into a no-op if the new
and the old entries were the same, exactly because the hash routines
didn't handle it on their own.
So what this patch does is to not just have the UNHASHED bit, but a
HASHED bit too, and when you insert an entry into the name hash, that
involves:
- clear the UNHASHED bit, because now it's valid again for lookup
(which is really all that UNHASHED meant)
- if we're being lazy, we're done here (but we still want to clear the
UNHASHED bit regardless of lazy mode, since we can become unlazy
later, and so we need the UNHASHED bit to always be set correctly,
even if we never actually insert the entry into the hash list)
- if it was already hashed, we just leave it on the list
- otherwise mark it HASHED and insert it into the list
this all means that unhashing and rehashing a name all just works
automatically. Obviously, you cannot change the name of an entry (that
would be a serious bug), but nothing can validly do that anyway (you'd
have to allocate a new struct cache_entry anyway since the name length
could change), so that's not a new limitation.
The code actually gets simpler in many ways, although the lazy hashing
does mean that there are a few odd cases (ie something can be marked
unhashed even though it was never on the hash in the first place, and
isn't actually marked hashed!).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This change removes all obvious useless if-before-free tests.
E.g., it replaces code like this:
if (some_expression)
free (some_expression);
with the now-equivalent:
free (some_expression);
It is equivalent not just because POSIX has required free(NULL)
to work for a long time, but simply because it has worked for
so long that no reasonable porting target fails the test.
Here's some evidence from nearly 1.5 years ago:
Note however, that it doesn't handle brace-enclosed blocks like
"if (x) { free (x); }". But that's ok, since there were none like
that in git sources.
Beware: if you do use the above snippet, note that it can
produce syntactically invalid C code. That happens when the
affected "if"-statement has a matching "else".
E.g., it would transform this
if (x)
free (x);
else
foo ();
into this:
free (x);
else
foo ();
There were none of those here, either.
If you're interested in automating detection of the useless
tests, you might like the useless-if-before-free script in gnulib:
[it *does* detect brace-enclosed free statements, and has a --name=S
option to make it detect free-like functions with different names]
We were returning the _address of_ the stored item (or NULL)
instead of the item itself. While this sort of indirection
is useful for insertion (since you can lookup and then
modify), it is unnecessary for read-only lookup. Since the
hash code splits these functions between the internal
lookup_hash_entry function and the public lookup_hash
function, it makes sense for the latter to provide what
users of the library expect.
The result of this was that the index caching returned bogus
results on lookup. We unfortunately didn't catch this
because we were returning a "struct cache_entry **" as a
"void *", and accidentally assigning it to a "struct
cache_entry *".
As it happens, this actually _worked_ most of the time,
because the entries were defined as:
meaning that interpreting a "struct cache_entry **" as a
"struct cache_entry *" would yield an entry where all fields
were totally bogus _except_ for the next pointer, which
pointed to the actual cache entry. When walking the list, we
would look at the bogus "name" field, which was unlikely to
match our lookup, and then proceed to the "real" entry.
The reading of bogus data was silently ignored most of the
time, but could cause a segfault for some data (which seems
to be more common on OS X).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When searching commit messages (commit search), if matched string is
too long, the generated HTML was munged leading to an ill-formed XHTML
document.
Now gitweb chop leading, trailing and matched parts, HTML escapes
those parts, then composes and marks up match info. HTML output is
never chopped. Limiting matched info to 80 columns (with slop) is now
done by dividing remaining characters after chopping match equally to
leading and trailing part, not by chopping composed and HTML marked
output.
Noticed-by: Jean-Baptiste Quenot <jbq@caraldi.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
hash-object: cleanup handling of command line options
git hash-object used to process the --stdin command line argument
before reading subsequent arguments. This caused 'git hash-object
--stdin -w' to fail to actually write the object into the
database, while '-w --stdin' properly did. Now git hash-object
first reads all arguments, and then processes them.
This regresses one insane use case. git hash-object used to allow
multiple --stdin arguments on the command line:
$ git hash-object --stdin --stdin
foo
^D
bar
^D
Now git hash-object errors out if --stdin is given more than once.
Reported by Josh Triplett through
http://bugs.debian.org/464432
Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
After changing builtin-tag.c to use strbuf in fd17f5b (Replace all
read_fd use with strbuf_read, and get rid of it.), the last condition
in do_sign() will always be false, as it's checked already right
above. So let's remove the cruft.
Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-gui: Focus insertion point at end of strings in repository chooser
When selecting a local working directory for a new repository or a
location to clone an existing repository into we now set the insert
point at the end of the selected path, allowing the user to type in
any additional parts of the path if they so desire.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Avoid hardcoded Windows paths in Cygwin package files
When we are being built by the Cygwin package maintainers we need to
embed the POSIX path to our library files and not the Windows path.
Embedding the Windows path means all end-users who install our Cygwin
package would be required to install Cygwin at the same Windows path
as the package maintainer had Cygwin installed to. This requirement
is simply not user-friendly and may be infeasible for a large number
of our users.
We now try to auto-detect if the Tcl/Tk binary we will use at runtime
is capable of translating POSIX paths into Windows paths the same way
that cygpath does the translations. If the Tcl/Tk binary gives us the
same results then it understands the Cygwin path translation process
and should be able to read our library files from a POSIX path name.
If it does not give us the same answer as cygpath then the Tcl/Tk
binary might actually be a native Win32 build (one that is not
linked against Cygwin) and thus requires the native Windows path
to our library files. We can assume this is not a Cygwin package
as the Cygwin maintainers do not currently ship a pure Win32 build
of Tcl/Tk.
Reported on the git mailing list by Jurko Gospodnetić.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Default TCL_PATH to same location as TCLTK_PATH
Most users set TCLTK_PATH to tell git-gui where to find wish, but they
fail to set TCL_PATH to the same Tcl installation. We use the non-GUI
tclsh during builds so headless systems are still able to create an
index file and create message files without GNU msgfmt. So it matters
to us that we find a working TCL_PATH at build time.
If TCL_PATH hasn't been set yet we can take a better guess about what
tclsh executable to use by replacing 'wish' in the executable path with
'tclsh'. We only do this replacement on the filename part of the path,
just in case the string "wish" appears in the directory paths. Most of
the time the tclsh will be installed alongside wish so this replacement
is a sensible and safe default.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Paper bag fix error dialogs opening over the main window
If the main window is the only toplevel we have open then we
don't have a valid grab right now, so we need to assume the
best toplevel to use for the parent is ".".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
1ca3d6e (send-email: squelch warning due to comparing undefined $_ to "")
where if the user was prompted for an initial In-Reply-To and didn't
provide one, messages would be sent out with an invalid In-Reply-To of
"<>"
Also add test cases for the regression and the fix. A small modification
was needed to allow send-email to take its replies from stdin if the
environment variable GIT_SEND_EMAIL_NOTTY is set.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ask branch_get() for the new branch explicitly instead of
letting it return a potentially stale information.
Tighten the logic to find the tracking branch to deal better
with misconfigured repositories (i.e. branch.*.merge can exist
but it may not have a refspec that fetches to .it)
Also fixes grammar in a message, as pointed out by Jeff King.
The function is about reporting and not automatically
fast-forwarding to the upstream, so stop calling it
"adjust-to".
Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Daniel Barkalow <barkalow@iabervon.org>
builtin-checkout.c: Remove unused prefix arguments in switch_branches path
This path doesn't actually care where in the tree you started out,
since it must change the whole thing anyway. With the gratuitous bug
removed, the argument is unused.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-reset --hard and git-read-tree --reset: fix read_cache_unmerged()
When invalidating unmerged entries in the index, we used to set
their ce_mode to 0 to note the fact that they do not matter
anymore which also made sure that later unpack_trees() call
would not reuse them. Instead just remove them from the index.
Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-gui: Ensure error dialogs always appear over all other windows
If we are opening an error dialog we want it to appear above all of
the other windows, even those that we may have opened with a grab
to make the window modal. Failure to do so may allow an error
dialog to open up (and grab focus!) under an existing toplevel,
making the user think git-gui has frozen up and is unresponsive,
as they cannot get to the dialog.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I expected git grep --name-only to give me only the file names,
much as git diff --name-only only generates filenames. Alas the
option is -l, which matches common external greps but doesn't match
other parts of the git UI.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The fake-editor shell script invoked /bin/sh; normally this
is fine, unless the /bin/sh doesn't meet our compatibility
requirements, as is the case with Solaris. Specifically, the
$() syntax used by fake-editor is not understood.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git_config_*: don't assume we are parsing a config file
These functions get called by other code, including parsing
config options from the command line. In that case,
config_file_name is NULL, leading to an ugly message or even
a segfault on some implementations of printf.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-clean simply ignored errors if removing a file or directory failed. This
patch makes it raise a warning and the exit code also greater than zero if
there are remaining files.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/setup:
builtin-mv: minimum fix to avoid losing files
git-add: adjust to the get_pathspec() changes.
Make blame accept absolute paths
setup: sanitize absolute and funny paths in get_pathspec()
* maint:
Clarified the meaning of git-add -u in the documentation
git-clone.sh: properly configure remote even if remote's head is dangling
Documentation/git-stash: document options for git stash list
send-email: squelch warning due to comparing undefined $_ to ""
Clarified the meaning of git-add -u in the documentation
The git-add documentation did not state clearly that the -u switch
updates only the tracked files that are in the current directory and
its subdirectories.
Signed-off-by: Pekka Kaitaniemi <kaitanie@cc.helsinki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
checkout: tone down the "forked status" diagnostic messages
When checking out a branch that is behind or forked from a
branch you are building on top of, we used to show full
left-right log but if you already _know_ you have long history
since you forked, it is a bit too much.
This tones down the message quite a bit, by only showing the
number of commits each side has since they diverged. Also the
message is not shown at all under --quiet.
git-clone.sh: properly configure remote even if remote's head is dangling
When cloning a remote repository which's HEAD refers to a nonexistent
ref, git-clone cloned all existing refs, but failed to write the
configuration for 'remote'. Now it detects the dangling remote HEAD,
refuses to checkout any local branch since HEAD refers to nowhere, but
properly writes the configuration for 'remote', so that subsequent
'git fetch's don't fail.
The problem was reported by Daniel Jacobowitz through
http://bugs.debian.org/466581
Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git.el: Set process-environment instead of invoking env
This will make it a little less posix-dependent, and more efficient.
Included is also a minor doc improvement.
Signed-off-by: David Kågedal <davidk@lysator.liu.se> Acked-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When pushing a refspec like "HEAD", we used to treat it as
"HEAD:HEAD", which didn't work without rewriting. Instead, we should
resolve the ref. If it's a symref, further require it to point to a
branch, to avoid doing anything especially unexpected. Also remove the
rewriting previously added in builtin-push.
Since the code for "HEAD" uses the regular refspec parsing, it
automatically handles "+HEAD" without anything special.
[jc: added a further test to make sure that "remote.*.push = HEAD" works]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
send-email: squelch warning due to comparing undefined $_ to ""
The check to see if initial_reply_to is defined was also comparing $_ to
"" for a reason I cannot ascertain (looking at the commit which made the
change didn't provide enlightenment), but if $_ is undefined, perl
generates a warning.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Rename git-core rpm to just git and rename the meta-pacakge to git-all.
push: document the status output
Documentation/push: clarify matching refspec behavior
push: indicate partialness of error message
cvsexportcommit: be graceful when "cvs status" reorders the arguments
In my use cases, "cvs status" sometimes reordered the passed filenames,
which often led to a misdetection of a dirty state (when it was in
reality a clean state).
I finally tracked it down to two filenames having the same basename.
So no longer trust the order of the results blindly, but actually check
the file name.
Since "cvs status" only returns the basename (and the complete path on the
server which is useless for our purposes), run "cvs status" several times
with lists consisting of files with unique (chomped) basenames.
Be a bit clever about new files: these are reported as "no file <blabla>",
so in order to discern it from existing files, prepend "no file " to the
basename.
In other words, one call to "cvs status" will not ask for two files
"blabla" (which does not yet exist) and "no file blabla" (which exists).
This patch makes cvsexportcommit slightly slower, when the list of changed
files has non-unique basenames, but at least it is accurate now.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Rename git-core rpm to just git and rename the meta-pacakge to git-all.
This fixes my favorite annoyance with the git rpm packaging: don't pull
in tla when I say yum install git! You wouldn't expect yum install gcc
to pull in gcc-gfortran, right?
With this change, and blanket 'yum update' will automatically pull in the
new 'git' package and push out the old 'git-core', and if the old 'git'
package was installed 'git-all' will be pulled in instead. A couple of
things do break though: 'yum update git-core', because yum behaves
differently when given a specific package name - it doesn't follow obsoletes.
Instead, 'yum install git' will pull in the new git rpm, which will then
push out the old 'git-core'. Similarly, to get the newest version of
the meta package, 'yum install git-all' will install git-all, which then
pushes out the old 'git' meta package.
Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you have particular reviewers you want to sent particular series
to, it's nice to be able to generate the whole series with them as
additional recipients, without configuring them into your general
headers or adding them by hand afterwards.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
RFC 2822 only permits a single To: header and a single Cc: header, so
we need to turn multiple values of each of these into a list. This
will be particularly significant with a command-line option to add Cc:
headers, where the user can't make sure to configure valid header sets
in any easy way.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Fix bug in href(..., -replay=>1) when using 'pathinfo' form
URLs generated by href(..., -replay=>1) (which includes 'next page'
links and alternate view links) didn't set project info correctly
when current page URL is in pathinfo form.
This was caused by the fact that href() always replays params in the
arrayref form, were they multivalued or singlevalued, and the code
dealing with 'pathinfo' feature couldn't deal with $params{'project'}
being arrayref.
Setting $params{'project'} is moved before replaying params; this
ensures that 'project' parameter is processed correctly.
Noticed-by: Peter Oberndorfer <kumbayo84@arcor.de> Noticed-by: Wincent Colaiuta <win@wincent.com> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
branch: optionally setup branch.*.merge from upstream local branches
"git branch" and "git checkout -b" now honor --track option even when
the upstream branch is local. Previously --track was silently ignored
when forking from a local branch. Also the command did not error out
when --track was explicitly asked for but the forked point specified
was not an existing branch (i.e. when there is no way to set up the
tracking configuration), but now it correctly does.
The configuration setting branch.autosetupmerge can now be set to
"always", which is equivalent to using --track from the command line.
Setting branch.autosetupmerge to "true" will retain the former behavior
of only setting up branch.*.merge for remote upstream branches.
Includes test cases for the new functionality.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The output was meant to be a balance of self-explanatory and
terse. In case we have erred too far on the terse side, it
doesn't hurt to explain in more detail what each line means.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous text was correct, but it was easy to miss the
fact that we are talking about "matching" refs. That is, the
text can be parsed as "we push the union of the sets
of remote and local heads" and not "we push the intersection
of the sets of remote and local heads". (The former actually
doesn't make sense if you think about it, since we don't
even _have_ some of those heads). A careful reading would
reveal the correct meaning, but it makes sense to be as
explicit as possible in documentation.
We also explicitly use and introduce the term "matching";
this is a term discussed on the list, and it seems useful
to for users to be able to refer to this behavior by name.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The existing message indicates that an error occured during
push, but it is unclear whether _any_ refs were actually
pushed (even though the status table above shows which were
pushed successfully and which were not, the message "failed
to push" implies a total failure). By indicating that "some
refs" failed, we hopefully indicate to the user that the
table above contains the details.
We could also put in an explicit "see above for details"
message, but it seemed to clutter the output quite a bit
(both on a line of its own, or at the end of the error line,
which inevitably wraps).
This could also be made more fancy if the transport
mechanism passed back more details on how many refs
succeeded and failed:
error: failed to push %d out of %d refs to '%s'
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git gui" would complain at launch if the local version of Git was
"1.5.4.2.dirty". Loosen the regular expression to look for either
"-dirty" or ".dirty", thus eliminating spurious warnings.
Signed-off-by: Wincent Colaiuta <win@wincent.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
will give the same information without changing branches. This is good
for finding out if the fetch you did recently had anything to say
about the branch you've been on, whose name you don't remember at the
moment.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mk/maint-parse-careful:
peel_onion: handle NULL
check return value from parse_commit() in various functions
parse_commit: don't fail, if object is NULL
revision.c: handle tag->tagged == NULL
reachable.c::process_tree/blob: check for NULL
process_tag: handle tag->tagged == NULL
check results of parse_commit in merge_bases
list-objects.c::process_tree/blob: check for NULL
reachable.c::add_one_tree: handle NULL from lookup_tree
mark_blob/tree_uninteresting: check for NULL
get_sha1_oneline: check return value of parse_object
read_object_with_reference: don't read beyond the buffer
xdl_merge(): make XDL_MERGE_ZEALOUS output simpler
When a merge conflicts, there are often less than three common lines
between two conflicting regions.
Since a conflict takes up as many lines as are conflicting, plus three
lines for the commit markers, the output will be shorter (and thus,
simpler) in this case, if the common lines will be merged into the
conflicting regions.
This patch merges up to three common lines into the conflicts.
For example, what looked like this before this patch:
<<<<<<<
if (a == 1)
=======
if (a != 0)
>>>>>>>
{
int i;
<<<<<<<
a = 0;
=======
a = !a;
>>>>>>>
will now look like this:
<<<<<<<
if (a == 1)
{
int i;
a = 0;
=======
if (a != 0)
{
int i;
a = !a;
>>>>>>>
Suggested Linus (based on ideas by "Voltage Spike" -- if that name is
real, it is mighty cool).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Add new option -nohtml to quot_xxx subroutines
Add support for new option -nohtml to quot_cec and quot_upr
subroutines, to have output not wrapped in HTML tags. This makes
those subroutines suitable to quoting attributes values, and for plain
text output quoting. Currently this API is not used yet.
While at it fix whitespace, and use ';' as delimiter, not separator.
The option to not wrap quot_cec output in HTML tag were proposed
originally in patch:
"Don't open a XML tag while another one is already open"
Message-ID: <20080216191628.GK30676@schiele.dyndns.org>
by Robert Schiele. Originally the parameter was named '-notag', was
also supportted by esc_html (but not esc_path) which passed it down to
quot_cec. Mentioned patch was meant to fix the bug Martin Koegler
reported in his mail
"Invalid html output repo.or.cz (alt-git.git)"
Message-ID: <20080216130037.GA14571@auto.tuwien.ac.at>
which was fixed in different way (do not use esc_html to escape and
quote HTML attributes).
Signed-off-by: Robert Schiele <rschiele@gmail.com> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Fix displaying unchopped argument in chop_and_escape_str
Do not use esc_html to escape [title] _attribute_ of a HTML element,
and quote unprintable characters. Replace unprintable characters by
'?' and use CGI method to generate HTML element and do the escaping.
This caused bug noticed by Martin Koegler,
Message-ID: <20080216130037.GA14571@auto.tuwien.ac.at>
that for bad commit encoding in author name, the title attribute (here
to show full, not shortened name) had embedded HTML code in it, result
of quoting unprintable characters the gitweb/HTML way. This of course
broke the HTML, causing page being not displayed in XML validating web
browsers.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
bisect view: check for MinGW32 and MacOSX in addition to X11
When deciding if gitk or git-log should be used to visualize the current
state, the environment variable DISPLAY was checked. Now, we check
MSYSTEM (for MinGW32/MSys) and SECURITYSESSIONID (for MacOSX) in addition.
Note that there is currently no way to ssh into MinGW32, and that
SECURITYSESSIONID is not set automatically on MacOSX when ssh'ing into it.
So this patch should be safe.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
you do not get any indication of error. If you are careful, you
would notice that no contents from the tagged object is
displayed, but that is about it. If you run the "show" command
without pager, however, you will see the error:
$ git --no-pager show foo-tag
tag foo-tag
Tagger: Junio C Hamano <gitster@pobox.com>
Date: Sat Feb 16 10:43:23 2008 -0800
Because we spawn the pager as the foreground process and feed
its input via pipe from the real command, we cannot affect the
exit status the shell sees from git command when the pager is in
use (I think there is not much gain we can have by working it
around, though). But at least it may make sense to show the
error message to the user sitting in front of the pager.
[jc: Edgar Toernig suggested a much nicer implementation than
what I originally posted, which I took.]
* cc/browser:
Documentation: add 'git-web--browse.txt' and simplify other docs.
git-web--browse: fix misplaced quote in init_browser_path()
web--browse: Add a few quotes in 'init_browser_path'.
Documentation: instaweb: add 'git-web--browse' information.
Adjust .gitignore for 5884f1(Rename 'git-help--browse.sh'...)
git-web--browse: do not start the browser with nohup
instaweb: use 'git-web--browse' to launch browser.
Rename 'git-help--browse.sh' to 'git-web--browse.sh'.
help--browse: add '--config' option to check a config option for a browser.
help: make 'git-help--browse' usable outside 'git-help'.
* pb/prepare-commit-msg:
git-commit: add a prepare-commit-msg hook
git-commit: Refactor creation of log message.
git-commit: set GIT_EDITOR=: if editor will not be launched
git-commit: support variable number of hook arguments
* jc/submittingpatches:
Documentation/SubmittingPatches - a suggested patch flow
Documentation/SubmittingPatches: What's Acked-by and Tested-by?
Documentation/SubmittingPatches: discuss first then submit
Documentation/SubmittingPatches: Instruct how to use [PATCH] Subject header