Uwe Kleine-König noticed that under certain circumstances, name-rev
picked a non-optimal tag.  Jeff King analyzed that name-rev only
takes into account the number of merge traversals, and then the
_last_ number in the description.

As an easy way to fix it, use a weighting factor for merge traversals:
A merge traversal is now made 65535 times more expensive than a
first-parent traversal.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: NUwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Options -d, -l, -v have already been explained in OPTIONS below.
Signed-off-by: NJari Aalto <jari.aalto@cante.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Everything is already fully quoted along the way so I believe this to be
unnecessary at this point. It would pose trouble for regexp searches.
Signed-off-by: NPetr Baudis <pasky@suse.cz>
Acked-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* 'master' of git://repo.or.cz/git-gui:
  git-gui: Correct 'git gui blame' in a subdirectory
  git-gui: Do not offer to stage three-way diff hunks into the index
  git-gui: Refactor diff pane popup support for future improvements
  git-gui: Fix "unoptimized loading" to not cause git-gui to crash
  git-gui: Paper bag fix "Stage Hunk For Commit" in diff context menu
  git-gui: Allow git-merge to use branch names in conflict markers
  git-gui: Fix window manager problems on ion3

Instead of disabling color all of the time during a git-commit, allow
the user's config preference in the situation where there is nothing
to commit.  In this situation, the status is printed to the terminal
and not sent to COMMIT_EDITMSG, so honoring the status color setting
is expected.
Signed-off-by: NBrian Hetro <whee@smaertness.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Currently, searchbox is CSS'd to have position: absolute, which has the
unfortunate consequence that if the viewport is too small and can't fit
into the page width together with the navbar, it gets overlapped and part
of the navbar gets obscured. This makes searchbox float: right instead,
thus the navbar simply gets wrapped.

Discovered and fix pointed out by Michael Olson <mwolson@gnu.org>.
Signed-off-by: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* 'master' of git://linux-nfs.org/~bfields/git:
  Documentation/user-manual.txt: fix a few omissions of gitlink commands.
  user-manual: fix incorrect header level
  user-manual: use pithier example commit
  user-manual: introduce the word "commit" earlier
  user-manual: minor editing for conciseness
  user-manual: edit "ignoring files" for conciseness
  Documentation/user-manual.txt: fix a few omissions of gitlink commands.

Conflicts:

	Documentation/user-manual.txt

Signed-off-by: NDavid Kastrup <dak@gnu.org>

This section is a subsection of the "Examples" section.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

Actually, we should have a competition for the favorite example commit.
Criteria:

	- length: one-line changes with one-line comments preferred,
	  and no long lines
	- significance/memorability
	- comic value
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

Use the word "commit" as a synonym for "version" from the start.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

Just cutting out a few unnecessary words.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

The immediate motivation for writing this section was to explain the
various places ignore patterns could be used.  However, I still think
.gitignore is the case most people will want to learn about first.  It
also makes it a bit more concrete to introduce ignore patterns in the
context of .gitignore first.  And the existance of gitignore(5) relieves
the pressure to explain it all here.

So, stick to the .gitignore example, with only a brief mention of the
others, explain the syntax only by example, and leave the rest to
gitignore(5).
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
Cc: Johan Herland <johan@herland.net>

Signed-off-by: NDavid Kastrup <dak@gnu.org>

The usage string for the executable was missing --refresh.  In
addition, the documentation referred to "file", but the usage string
referred to "filepattern".  Updated the documentation to
"filepattern", as git-add does handle patterns.
Signed-off-by: NBrian Hetro <whee@smaertness.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The usage information in git-am.sh now matches that of the
documentation.
Signed-off-by: NBrian Hetro <whee@smaertness.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Under some types of packfile corruption the zlib stream holding the
data for a delta within a packfile may fail to inflate, due to say
a CRC failure within the compressed data itself.  When this occurs
the unpack_compressed_entry function will return NULL as a signal to
the caller that the data is not available.  Unfortunately we then
tried to use that NULL as though it referenced a memory location
where a delta was stored and tried to apply it to the delta base.
Loading a byte from the NULL address typically causes a SIGSEGV.

cate on #git noticed this failure in `git fsck --full` where the
call to verify_pack() first noticed that the packfile was corrupt
by finding that the packfile's SHA-1 did not match the raw data of
the file.  After finding this fsck went ahead and tried to verify
every object within the packfile, even though the packfile was
already known to be bad.  If we are going to shovel bad data at
the delta unpacking code, we better handle it correctly.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

David Kastrup pointed out that the following sequence was not
working as we had intended:

  $ cd lib
  $ git gui blame console.tcl
  fatal: cannot stat path lib/console.tcl: No such file or directory

The problem here was we disabled the chdir to the root of the
working tree when we are running with a "bare allowed" feature
such as blame or browser, but we still kept the prefix we found via
`git rev-parse --show-prefix`.  This caused us to try and look for
the file "console.tcl" within the subdirectory but also include
the subdirectory's own path from the root of the working tree.
This is unlikely to succeed, unless the user just happened to have
a "lib/lib/console.tcl" file in the repository, in which case we
would produce the wrong result.

In the case of a bare repository we shouldn't get back a value from
`rev-parse --show-prefix`, so really $_prefix should only be set
to the non-empty string if we are in a working tree and we are in a
subdirectory of that working tree.  If this is true we really want
to always be at the top level of the working tree, as all paths are
accessed as though they were relative to the top of the working tree.
Converting $_prefix to a ../ sequence is a fairly simple approach
to moving up the requisite levels.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

git-p4: Fix warnings about non-existant refs/remotes/p4/HEAD ref when running git-p4 sync the first time after a git clone.

Don't create the p4/HEAD symbolic ref if p4/master doesn't exist yet.
Signed-off-by: NSimon Hausmann <simon@lst.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git-p4: Make 'git-p4 branches' work after an initial clone with git clone from an origin-updated repository.

After a clone with "git clone" of a repository the p4 branches are only in remotes/origin/p4/* and not in remotes/p4/*.
Separate the code for detection and creation out of the P4Sync command class into standalone methods and use them
from the P4Branches command.
Signed-off-by: NSimon Hausmann <simon@lst.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Fix minor typos throughout the documentation.
Signed-off-by: NBrian Hetro <whee@smaertness.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When not referring to the cvs command, CVS makes more sense.
Signed-off-by: NBrian Hetro <whee@smaertness.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

After git-write-tree finishes computing the tree, it updates the
index so that later operations can take advantage of fully
populated cache tree.

However, anybody writing the index file has to mark the entries
that are racily clean.  For each entry whose cached lstat(3)
data in the index exactly matches what is obtained from the
filesystem, if the timestamp on the index file was the same or
older than the modification timestamp of the file, the blob
contents and the work tree file, after convert_to_git(), need to
be compared, and if they are different, its index entry needs to
be marked not to match the lstat(3) data from the filesystem.

In order for this to work, convert_to_git() needs to work
correctly, which in turn means you need to read the config file
to get the settings of core.crlf and friends.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When squashing, rebase -i did not prevent fast forwards.  This could
happen when picking some other commit than the first one, and then
squashing the first commit.  So do not allow fast forwards when
squashing.

Noticed by Johannes Sixt.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

MakeMaker supports three installation modes: perl, site, and vendor. The first
and third install manpages to $PREFIX/share/man, only site installs to
$PREFIX/man. For consistency with the rest of git, which does not make the
distinction and writes all manpages to $PREFIX/share/man, this change makes
sure that perl does too, even when it's installed in site mode.
Signed-off-by: Nmartin f. krafft <madduck@madduck.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The --stdlayout option to git-svn init/clone initialises the default
Subversion values of trunk,tags,branches: -T trunk -b branches -t tags.
If any of the -T/-t/-b options are given in addition, they are given
preference.

[ew: fixed whitespace and added "-s" shortcut]
Signed-off-by: Nmartin f. krafft <madduck@madduck.net>
Signed-off-by: NEric Wong <normalperson@yhbt.net>

A particularly bad case was HASH_LIMIT <= hash_count[i] < 2*HASH_LIMIT:
in that case, only a single hash survived.  For larger cases,
2*HASH_LIMIT was the actual limiting value after pruning.
Signed-off-by: NDavid Kastrup <dak@gnu.org>
Acked-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git-apply does not accept a patch that was generated as a three-way
combined diff format such as we see during merge conflicts.  If we
get such a diff in our diff viewer and try to send it to git-apply
it just errors out and the user is left confused wondering why they
cannot stage that hunk.

Instead of feeding a known to be unacceptable hunk to git-apply we
now just disable the stage/unstage context menu option if the hunk
came from a three way diff.  The user may still be confused about
why they cannot work with a combined diff, but at least they are
only confused as to why git-gui is not offering them the action.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

* 'master' of git://repo.or.cz/git/fastimport:
  Teach bash about git-submodule and its subcommands
  Teach bash to complete ref arguments to git-describe
  Update bash completion with new 1.5.3 command line options

This will print out the URL that dcommit will operate on.
If used with --dry-run this will print out the URL without
making changes to the repository.
Signed-off-by: NEric Wong <normalperson@yhbt.net>

The current popup_diff_menu procedure is somewhat messy as it has a
few duplications of the same logic in each of the different legs of
the routine.  We can simplify these by setting a few state variables
in the different legs.

No functional change, just a cleanup to make it easier to implement
future functional changes within this block.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

The git-submodule command is new in 1.5.3 and contains a number
of useful subcommands for working on submodules.  We usually try
to offer the subcommands of a git command in the bash completion,
so here they are for git-submodule.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

I'm often finding that I need to run git-describe on very long
remote tracking branch names, to find out what tagged revision
the remote tracking branch is now at (or not at).  Typing out
the ref names is painful, so bash completion on them is a very
useful feature.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

A number of commands have learned new tricks as part of git 1.5.3.
If these are long options (--foo) we tend to support them in the
bash completion, as it makes the user's task of using the option
slightly easier.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>