* maint:
  user-manual: introduce "branch" and "branch head" differently
  glossary: clean up cross-references
  glossary: stop generating automatically
  user-manual: Use def_ instead of ref_ for glossary references.
  user-manual.txt: fix a tiny typo.
  user-manual: run xsltproc without --nonet option

* 'maint' of git://linux-nfs.org/~bfields/git:
  user-manual: introduce "branch" and "branch head" differently
  glossary: clean up cross-references
  glossary: stop generating automatically
  user-manual: Use def_ instead of ref_ for glossary references.
  user-manual.txt: fix a tiny typo.
  user-manual: run xsltproc without --nonet option

* js/remote-show-push:
  Teach git-remote to list pushed branches.

* maint:
  gitweb: Add some installation notes in gitweb/INSTALL
  gitweb: Fix not marking signoff lines in "log" view
  gitweb: Don't escape attributes in CGI.pm HTML methods
  gitweb: Change to use explicitly function call cgi->escapHTML()

This simplifies the shell code, reduces its memory footprint, and
speeds things up. The performance improvements should be noticable
when git-rebase works on big commits.
Signed-off-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

... like it is done everywhere else.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When some operations are interrupted (or "die()'d" or crashed) then the
partial object/pack/index file may remain around.  Make it more obvious
in their name that those files are temporary stuff and can be cleaned up
if no operation is in progress.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The update hook's only job is to decide is a particular update
is allowed or not.  It was not the right place to send out
update notification e-mails from to begin with, as the final
stage of updating refs can fail after this hook runs.
Signed-off-by: NAndy Parkins <andyparkins@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Add some installation and configuration notes for gitweb in
gitweb/INSTALL. Make use of filling gitweb configuration by
Makefile.

It does not cover (yet?) all the configuration variables and
options.

Some of contents duplicates information in gitweb/README file
(it is referred from gitweb/INSTALL).
Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The CSS selector for signoff lines style was too strict: in the "log"
view the commit message is not encompassed in container "page_body"
div.
Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

There is no need to escape HTML tag's attributes in CGI.pm
HTML methods (like CGI::a()), because CGI.pm does attribute
escaping automatically.

  $cgi->a({ ... -attribute => atribute_value }, tag_contents)

is translated to

  <a ... attribute="attribute_value">tag_contents</a>

The rules for escaping attribute values (which are string contents) are
different. For example you have to take care about escaping embedded '"'
and "'" characters; CGI::a() does that for us automatically.

CGI::a() does not HTML escape tag_contents; we would need to write

  <a href="URL">some <b>bold</b> text</a>

for example. So we use esc_html (or esc_path) to escape tag_contents
as needed.
Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Change to use explicitly function call cgi->escapHTML().
This fix the problem on some systems that escapeHTML() is not
functioning, as default CGI is not setting 'escape' parameter.
Signed-off-by: NLi Yang <leoli@freescale.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

When converting from the shell script, based on a misreading of the
sed invocation, the builtin included the abbreviated commit name,
and did _not_ include the quotes around the oneline message.

This fixes it.

[jc: with a fix for the typo/thinko spotted by Linus, and also
 removing the unwanted abbrev at the beginning.]
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* maint:
  gitweb: Fix "next" link in commit view

Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

In a path-limited bisection, when the $bad commit is not
changing the limited path, and the number of suspects is 1, the
code miscounted and returned $bad from find_bisection(), which
is not marked with TREECHANGE.  This is of course filtered by
the output routine, resulting in an empty output, in turn
causing git-bisect driver to say "$bad was both good and bad".

Illustration.  Suppose you have these four commits, and only C
changes path P.  You know D is bad and A is good.

	A---B---C*--D

git-bisect driver runs this to find a bisection point:

	$ git rev-list --bisect A..D -- P

which calls find_bisection() with B, C and D.  The set of
commits that is given to this function is the same set of
commits as rev-list without --bisect option and pathspec
returns.  Among them, only C is marked with TREECHANGE.  Let's
call the set of commits given to find_bisection() that are
marked with TREECHANGE (or all of them if no path limiter is in
effect) "the bisect set".  In the above example, the size of the
bisect set is 1 (contains only "C").

For each commit in its input, find_bisection() computes the
number of commits it can reach in the bisect set.  For a commit
in the bisect set, this number includes itself, so the number is
1 or more.  This number is called "depth", and computed by
count_distance() function.

When you have a bisect set of N commits, and a commit has depth
D, how good is your bisection if you returned that commit?  How
good this bisection is can be measured by how many commits are
effectively tested "together" by testing one commit.

Currently you have (N-1) untested commits (the tip of the bisect
set, although it is included in the bisect set, is already known
to be bad).  If the commit with depth D turns out to be bad,
then your next bisect set will have D commits and you will have
(D-1) untested commits left, which means you tested (N-1)-(D-1)
= (N-D) commits with this bisection.  If it turns out to be good, then
your next bisect set will have (N-D) commits, and you will have
(N-D-1) untested commits left, which means you tested
(N-1)-(N-D-1) = D commits with this bisection.

Therefore, the goodness of this bisection is is min(N-D, D), and
find_bisection() function tries to find a commit that maximizes
this, by initializing "closest" variable to 0 and whenever a
commit with the goodness that is larger than the current
"closest" is found, that commit and its goodness are remembered
by updating "closest" variable.  The "the commit with the best
goodness so far" is kept in "best" variable, and is initialized
to a commit that happens to be at the beginning of the list of
commits given to this function (which may or may not be in the
bisect set when path-limit is in use).

However, when N is 1, then the sole tree-changing commit has
depth of 1, and min(N-D, D) evaluates to 0.  This is not larger
than the initial value of "closest", and the "so far the best
one" commit is never replaced in the loop.

When path-limit is not in use, this is not a problem, as any
commit in the input set is tree-changing.  But when path-limit
is in use, and when the starting "bad" commit does not change
the specified path, it is not correct to return it.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Fix copy'n'paste error in commit c9d193df which caused that "next"
link for merge commits in "commit" view
  (merge: _commit_ _commit_ ...)
was to "commitdiff" view instead of being to "commit" view.
Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Otherwise you would be in trouble if your GIT_DIR has IFS letters in it.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The branch you are on while bisecting is always "bisect", and
checking for "refs/heads/bisect*" is wrong.  Only check if it is
exactly "refs/heads/bisect".
Signed-off-by: NJunio C Hamano <junkio@cox.net>

After "git reset" moves the HEAD around, it reports which commit
you are on, which gives the user a warm fuzzy feeling of
assurance.  Give the same assurance from git-checkout when
moving the detached HEAD around.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This idea was suggested by Bill Lear
(Message-ID: <17920.38942.364466.642979@lisa.zopyra.com>)
and I think it is a very good one.

This patch adds a new test file for "git bisect run", but there
is currently only one basic test.
Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Without this the rev could be (e.g.) a tag and then the condition to end the
bisect might fail and you have to check the already known to be bad revision
once more.
Signed-off-by: NUwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Elias Pipping:
> I'm on a mac, hence /usr/bin/sed is not gnu sed, which makes
> t4118 fail.
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Ack'd-by: Elias Pipping <pipping@macports.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When we write out the result of patch application, we sometimes
need to munge the data (e.g. under core.autocrlf).  After doing
so, what we should free is the temporary buffer that holds the
converted data returned from convert_to_working_tree(), not the
original one.

This patch also moves the call to open() up in the function, as
the caller expects us to fail cheaply if leading directories
need to be created (and then the caller creates them and calls
us again).  For that calling pattern, attempting conversion
before opening the file adds unnecessary overhead.
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* git://git2.kernel.org/pub/scm/gitk/gitk:
  [PATCH] prefer "git COMMAND" over "git-COMMAND" in gitk

* maint:
  Documentation/pack-format.txt: Clear up description of types.
  fix typo in git-am manpage

Signed-off-by: NPeter Eriksen <s022018@student.dtu.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The HEAD reflog is updated as well as the reflog for the branch pointed
to by HEAD whenever it is referenced with "HEAD".

There are some cases where a specific branch may be modified directly.
In those cases, the HEAD reflog should be updated as well if it is a
symref to that branch in order to be consistent.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

It was annoying to always have the first email from a project be from
the "Unnamed repository; edit this file to name it for gitweb project";
just because it's so easy to forget to set it.

This patch checks to see if the description file is still default (or
empty) and aborts if so - allowing you to fix the problem before sending
out silly looking emails to every developer.
Signed-off-by: NAndy Parkins <andyparkins@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This makes git-fetch <URL> && git-merge FETCH_HEAD produce the
same merge message as git-pull <URL>.
Signed-off-by: NMichael S. Tsirkin <mst@dev.mellanox.co.il>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When you want to amend the commit message of 3 commits before
the tip of the current branch, say 'master',

	A--B--C--D--E(master)

it is sometimes handy to make your head detached at that commit
with:

	$ git checkout HEAD~3 ;# check out B
	$ git commit --amend ;# without modifying contents...

to create:

          .B'(HEAD)
         /
	A--B--C--D--E(master)

and then rebase 'master' branch onto HEAD with this:

	$ git rebase HEAD master

to result in:

          .B'-C'-D'-E(master=HEAD)
         /
	A--B--C--D--E

However, the current code interprets HEAD after it switches to
the branch 'master', which means the rebase will not do
anything.  You have to say something unwieldly like this
instead:

	$ git rebase $(git rev-parse HEAD) master

This fixes it by expanding the $onto commit name before
switching to the target branch.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

In addition to optimizing pathspecs that would never match,
which was done earlier, this optimizes pathspecs that would
always match (e.g. "arch/" while the traversal is already in
"arch/i386/" hierarchy).

This patch makes the worst case slightly more palatable, while
improving average case.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

If we already know that some of the pathspecs can match later
entries in the tree we are looking at, we do not have to do more
expensive strncmp() upfront before comparing the length of the
match pattern and the path, as a path longer than the match
pattern will not match it, and a path shorter than the match
pattern will match only if the path is a directory-component
wise prefix of the match pattern.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When we are looking at a tree entry with pathspecs, if all the
pathspecs sort strictly earlier than the entry we are currently
looking at, there is no way later entries in the same tree would
match our pathspecs, because the entries are sorted.
Signed-off-by: NJunio C Hamano <junkio@cox.net>