tokkee.org

Makefile: Add cache-tree.h to the headers list

The dependency was missing.

Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Don't allow contrib/workdir/git-new-workdir to trash existing dirs

Recently I found that doing a sequence like the following:

  git-new-workdir a b
  ...
  git-new-workdir a b

by accident will cause a (and now also b) to have an infinite cycle
in its refs directory.  This is caused by git-new-workdir trying
to create the "refs" symlink over again, only during the second
time it is being created within a's refs directory and is now also
pointing back at a's refs.

This causes confusion in git as suddenly branches are named things
like "refs/refs/refs/refs/refs/refs/refs/heads/foo" instead of the
more commonly accepted "refs/heads/foo".  Plenty of commands start
to see ambiguous ref names and others just take ages to compute.

git-clone has the same safety check, so git-new-workdir should
behave just like it.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-apply: do not read past the end of buffer

When the preimage we are patching is shorter than what the patch
text expects, we tried to match the buffer contents at the
"original" line with the fragment in full, without checking we
have enough data to match in the preimage.  This caused the size
of a later memmove() to wrap around and attempt to scribble
almost the entire address space.  Not good.

The code that follows the part this patch touches tries to match
the fragment with line offsets.  Curiously, that code does not
have the problem --- it guards against reading past the end of
the preimage.

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

GIT 1.5.3.1: obsolete git-p4 in RPM spec file.

HPA noticed that yum does not like the newer git RPM set; it turns out
that we do not ship git-p4 anymore but existing installations do not
realize the package is gone if we do not tell anything about it.

David Kastrup suggests using Obsoletes in the spec file of the new
RPM to replace the old package, so here is a try.

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

Typofix: 1.5.3 release notes

GIT 1.5.3

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

Merge branch 'jp/send-email-cc'

* jp/send-email-cc:
  git-send-email --cc-cmd

Mention -m as an abbreviation for --merge

Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Update my contact address as the maintainer.

Documentation: minor AsciiDoc mark-up fixes.

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

URL: allow port specification in ssh:// URLs

Allow port specification in ssh:// URLs in the
usual notation:

ssh://[user@]host.domain[:<port>]/<path>

This allows git to be used over ssh-tunneling
networks.

Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Avoid one-or-more (\+) non BRE in sed scripts.

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

rebase -m: Fix incorrect short-logs of already applied commits.

When a topic branch is rebased, some of whose commits are already
cherry-picked upstream:

    o--X--A--B--Y    <- master
     \
      A--B--Z        <- topic

then 'git rebase -m master' would report:

    Already applied: 0001 Y
    Already applied: 0002 Y

With this fix it reports the expected:

    Already applied: 0001 A
    Already applied: 0002 B

As an added bonus, this change also avoids 'echo' of a commit message,
which might contain escapements.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-diff: resurrect the traditional empty "diff --git" behaviour

The warning message to suggest "Consider running git-status" from
"git-diff" that we experimented with during the 1.5.3 cycle turns
out to be a bad idea.  It robbed cache-dirty information from people
who valued it, while still asking users to run "update-index --refresh".
It was hoped that the new behaviour would at least have some educational
value, but not showing the cache-dirty paths like before meant that the
user would not even know easily which paths were cache-dirty, and it
made the need to refresh the index look like even more unnecessary chore.

This commit reinstates the traditional behaviour, but with a twist.

By default, the empty "diff --git" output is totally squelched out
from "git diff" output.  At the end of the command, it automatically
runs "update-index --refresh" as needed, without even bothering the
user.  In other words, people who do not care about the cache-dirtyness
do not even have to see the warning.

The traditional behaviour to see the stat-dirty output and to bypassing
the overhead of content comparison can be specified by setting the
configuration variable diff.autorefreshindex to false.

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

git-tag: Fix -l option to use better shell style globs.

This patch removes certain behaviour of "git tag -l foo", currently
listing every tag name having "foo" as a substring.  The same
thing now could be achieved doing "git tag -l '*foo*'".

This feature was added recently when git-tag.sh got the -n option
for showing tag annotations, because that commit also replaced the
old "grep pattern" behaviour with a more preferable "shell pattern"
behaviour (although slightly modified as you can see).
Thus, the following builtin-tag.c implemented it in order to
ensure that tests were passing unchanged with both programs.

Since common "shell patterns" match names with a given substring
_only_ when * is inserted before and after (as in "*substring*"), and
the "plain" behaviour cannot be achieved easily with the current
implementation, this is mostly the right thing to do, in order to
make it more flexible and consistent.

Tests for "git tag" were also changed to reflect this.

Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: fix dcommit clobbering upstream when committing multiple changes

Although dcommit could detect if the first commit in the series
would conflict with the HEAD revision in SVN, it could not
detect conflicts in further commits it made.

Now we rebase each uncommitted change after each revision is
committed to SVN to ensure that we are up-to-date.  git-rebase
will bail out on conflict errors if our next change cannot be
applied and committed to SVN cleanly, preventing accidental
clobbering of changes on the SVN-side.

--no-rebase users will have trouble with this, and are thus
warned if they are committing more than one commit.  Fixing this
for (hopefully uncommon) --no-rebase users would be more complex
and will probably happen at a later date.

Thanks to David Watson for finding this and the original test.

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

git-svn: Protect against "diff.color = true".

If the configuration of the user has "diff.color = true", the
output from "log" we invoke internally added color codes, which
broke the parser.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Acked-by: Eric Wong <normalperson@yhbt.net>

filter-branch: introduce convenience function "skip_commit"

With this function, a commit filter can leave out unwanted commits
(such as temporary commits).  It does _not_ undo the changeset
corresponding to that commit, but it _skips_ the revision.  IOW
no tree object is changed by this.

If you like to commit early and often, but want to filter out all
intermediate commits, marked by "@@@" in the commit message, you can
now do this with

git filter-branch --commit-filter '
if git cat-file commit $GIT_COMMIT | grep '@@@' > /dev/null;
then
skip_commit "$@";
else
git commit-tree "$@";
fi' newbranch

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

filter-branch: provide the convenience functions also for commit filters

Move the convenience functions to the top of git-filter-branch.sh, and
return from the script when the environment variable SOURCE_FUNCTIONS is
set.

By sourcing git-filter-branch with that variable set automatically, all
commit filters may access the convenience functions like "map".

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

rebase -i: mention the option to split commits in the man page

The interactive mode of rebase can be used to split commits.  Tell the
interested parties about it, with a dedicated section in the man page.

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

filter-branch: fix remnants of old syntax in documentation

Some time ago, filter-branch's syntax changed so that more than one
ref can be rewritten at the same time.  This involved the removal of
the ref name for the result; instead, the refs are rewritten in-place.

This updates the last leftovers in the documentation to reflect the
new behavior.

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

Teach bash about completing arguments for git-tag

Lately I have been doing a lot of calls to `git tag -d` and also to
`git tag -v`.  In both such cases being able to complete the names
of existing tags saves the fingers some typing effort.  We now look
for the -d or -v option to git-tag in the bash completion support
and offer up existing tag names as possible choices for these.

When creating a new tag we now also offer bash completion support
for the second argument to git-tag (the object to be tagged) as this
can often be a specific existing branch name and is not necessarily
the current HEAD.

If the -f option is being used to recreate an existing tag we now
also offer completion support on the existing tag names for the
first argument of git-tag, helping to the user to reselect the
prior tag name that they are trying to replace.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Hopefully the final update to draft release notes for 1.5.3.

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

Make "git-log --" without paths behave the same as "git-log" without --

"git log" family of commands, even when run from a subdirectory,
do not limit the revision range with the current directory as
the path limiter, but with double-dash without any paths after
it, i.e. "git log --" do so.  It was a mistake to have a
difference between "git log --" and "git log" introduced in
commit ae563542bf10fa8c33abd2a354e4b28aca4264d7 (First cut at
libifying revlist generation).

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

git-init: autodetect core.symlinks

We already autodetect if filemode is reliable on the filesystem
to deal with VFAT and friends.  Do the same for symbolic link
support.

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

Make git-archimport log entries more consistent

When appending the "git-archimport-id:" line to the end of log entries,
git-archimport would use two blank lines as a separator when there was no
body in the arch log (only a Summary: line), and zero blank lines when there
was a body (making it hard to see the break between the actual log message
and the git-archimport-id: line).

This patch makes git-archimport generate one blank line as a separator in all
cases.

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

fix same sized delta logic

The code favoring shallower deltas when size is equal was triggered
only when previous delta was also cached.  There should be no relation
between cached deltas and same sized deltas.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

filter-branch: make sure orig_namespace ends with a single slash.

Later in a loop any existing ref whose path begins with it is
removed.  It would be a disaster if you allowed it to say refs/head
for example.

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

git-filter-branch: document --original option

Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-filter-branch: more detailed USAGE

Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: do not allow gnu make to remove test-*.o files

It appears parallel build (-j) gets confused.

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

Temporary fix for stack smashing in mailinfo

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fixing comment in merge strategies

Comments in both these strategies refer to the wrong number
of remotes

Signed-off-by: Tom Clarke <tom@u2i.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

ls-files --error-unmatch: do not barf if the same pattern is given twice.

This is most visible when you do "git commit Makefile Makefile"; it
may be a stupid request, but that is not a reason to fail the command.

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

Merge branch 'master' of git://git./gitk/gitk

* 'master' of git://git.kernel.org/pub/scm/gitk/gitk:
  gitk: Fix bug causing undefined variable error when cherry-picking

completion: also complete git-log's --left-right and --cherry-pick option

Both --left-right and --cherry-pick are particularly long to type, so
help the user there.

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

gitk: Fix bug causing undefined variable error when cherry-picking

When "Show nearby tags" is turned off and the user did a cherry-pick,
we were trying to access variables relating to the descendent/ancestor
tag & head computations in addnewchild though they hadn't been set.
This makes sure we don't do that.  Reported by Johannes Sixt.

Signed-off-by: Paul Mackerras <paulus@samba.org>

git-daemon(1): assorted improvements.

Jari Aalto noticed a handful places in git-daemon documentation
that need to be improved.

 * --inetd makes --pid-file to be ignored, in addition to --user
   and --group

 * receive-pack service was not described at all.  We should, if
   only to warn about the security implications of it.

 * There was no example of per repository configuration.

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

GIT 1.5.3-rc7

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

git-svn.txt: fix an obvious misspelling.

Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git.el: Added colors for dark background

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

format-patch documentation: reword to hint "--root <one-commit>" more clearly

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

Merge branch 'jc/logsemantics'

* jc/logsemantics:
  "format-patch --root rev" is the way to show everything.
  Porcelain level "log" family should recurse when diffing.

Documentation/git-diff: A..B and A...B cannot take tree-ishes

As pointed out by Linus, these notations require the endpoints
given by the end user to be commits.  Clarify.

Also, three-dots in AsciiDoc are turned into ellipses unless
quoted with bq.  Be careful.

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

git-add: Make the filename globbing note a bit clearer

I think the trick with Git-side filename globbing is important and perhaps
not that well known.  Clarify a bit in git-add documentation what it means.

Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-add: Make the "tried to add ignored file" error message less confusing

Currently the error message seems to imply (at least to me) that only
the listed files were withheld and the rest of the files was added to the
index, even though that's obviously not the case.

Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: Fix escaping HTML of project owner in 'projects_list' and
'summary' views

This for example allows to put email address in the project owner
field in the projects index file (when $projects_list points to
a file, and not to a directory), in the form of:

path/to/repo.git Random+J+Developer+<random@developer.example.org>

Noticed-by: Jon Smirl <jonsmirl@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

"format-patch --root rev" is the way to show everything.

We used to trigger the special case "things not in origin"
semantics only when one and only one positive ref is given, and
no number (e.g. "git format-patch -4 origin") was specified, and
used the general revision range semantics for everything else.

This narrows the special case a bit more, by making:

git format-patch --root this_version

to show everything that leads to the named commit.

More importantly, document the two different semantics better.
The generic revision range semantics came later and bolted on
without being clearly documented.

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

Porcelain level "log" family should recurse when diffing.

Most notably, "git log --name-status" stopped at top level
directory changes without "-r" option.

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

git-merge: do up-to-date check also for all strategies

This clarifies the logic to omit fast-forward check and omit
trivial merge before running the specified strategy.

The "index_merge" variable started out as a flag to say "do not
do anything clever", but when recursive was changed to skip the
trivial merge, the semantics were changed and the variable alone
does not make sense anymore.

This splits the variable into two, allow_fast_forward (which is
almost always true, and avoids making a merge commit when the
other commit is a descendant of our branch, but is set to false
for ours and subtree) and allow_trivial_merge (which is false
for ours, recursive and subtree).

Unlike the earlier implementation, the "ours" strategy allows an
up-to-date condition.  When we are up-to-date, the result will
be our commit, and by definition, we will have our tree as the
result.

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

git --bare cmd: do not unconditionally nuke GIT_DIR

"GIT_DIR=some.where git --bare cmd" and worse yet
"git --git-dir=some.where --bare cmd" were very confusing.  They
both ignored git-dir specified, and instead made $cwd as GIT_DIR.

This changes --bare not to override existing GIT_DIR.

This has been like this for a long time.  Let's hope nobody sane
relied on this insane behaviour.

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

Fix initialization of a bare repository

Here is my attempt to fix this with a minimally intrusive patch.

 * As "git --bare init" cannot tell if it was called with --bare or
   just "GIT_DIR=. git init", I added an explicit assignment of
   is_bare_repository_cfg on the codepath for "git --bare".

 * GIT_WORK_TREE alone without GIT_DIR does not make any sense,
   nor GIT_WORK_TREE with an explicit "git --bare".  Catch that
   mistake.  It might make sense to move this check to "git.c"
   side as well, but I tried to shoot for the minimum change for
   now.

 * Some scripts, especially from the olden days, rely on
   traditional GIT_DIR behaviour in "git init".  Namely, these
   are some notable patterns:

   (create a bare repository)
   - mkdir some.git && cd some.git && GIT_DIR=. git init
   - mkdir some.git && cd some.git && git --bare init

   (create a non-bare repository)
   - mkdir .git && GIT_DIR=.git git init
   - mkdir .git && GIT_DIR=`pwd`/.git git init

This comes with a new test script and also passes the existing
test suite, but there may be cases that are still broken with
the current tip of master and this patch does not yet fix.  I'd
appreciate help in straightening this mess out.

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

name-rev: Fix non-shortest description

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: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Describe two-dot and three-dot notation for diff endpoints.

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

git-tag(1): Remove duplicate text

Options -d, -l, -v have already been explained in OPTIONS below.

Signed-off-by: Jari Aalto <jari.aalto@cante.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: Lift any characters restriction on searched strings

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: Petr Baudis <pasky@suse.cz>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

RelNotes draft for 1.5.3 update.

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

Merge branch 'master' of git://repo.or.cz/git-gui

* '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

When nothing to git-commit, honor the git-status color setting.

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: Brian Hetro <whee@smaertness.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: Fix searchbox positioning

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: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'master' of git://linux-nfs.org/~bfields/git

* '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.

Merge branch 'maint'

Conflicts:

Documentation/user-manual.txt

Documentation/user-manual.txt: fix a few omissions of gitlink commands.

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

user-manual: fix incorrect header level

This section is a subsection of the "Examples" section.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>

user-manual: use pithier example commit

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: J. Bruce Fields <bfields@citi.umich.edu>

user-manual: introduce the word "commit" earlier

Use the word "commit" as a synonym for "version" from the start.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>

user-manual: minor editing for conciseness

Just cutting out a few unnecessary words.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>

user-manual: edit "ignoring files" for conciseness

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: J. Bruce Fields <bfields@citi.umich.edu>
Cc: Johan Herland <johan@herland.net>

Documentation/user-manual.txt: fix a few omissions of gitlink commands.

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

Make usage documentation for git-add consistent.

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: Brian Hetro <whee@smaertness.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Make usage documentation for git-am consistent.

The usage information in git-am.sh now matches that of the
documentation.

Signed-off-by: Brian Hetro <whee@smaertness.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Don't segfault if we failed to inflate a packed delta

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: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pack-objects: check return value from read_sha1_file()

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

blame: check return value from read_sha1_file()

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

git-gui: Correct 'git gui blame' in a subdirectory

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: Shawn 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: Simon Hausmann <simon@lst.de>
Signed-off-by: Junio 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: Simon Hausmann <simon@lst.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: Correct various misspellings and typos.

Fix minor typos throughout the documentation.

Signed-off-by: Brian Hetro <whee@smaertness.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: For consistency, use CVS instead of cvs.

When not referring to the cvs command, CVS makes more sense.

Signed-off-by: Brian Hetro <whee@smaertness.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix racy-git handling in git-write-tree.

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: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rebase -i: fix squashing corner case

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: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Install man3 manpages to $PREFIX/share/man/man3 even for site installs

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: martin f. krafft <madduck@madduck.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn init/clone --stdlayout option to default-init trunk/tags/branches

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: martin f. krafft <madduck@madduck.net>
Signed-off-by: Eric Wong <normalperson@yhbt.net>

diff-delta.c: Fix broken skip calculation.

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: David Kastrup <dak@gnu.org>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-gui: Do not offer to stage three-way diff hunks into the index

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: Shawn O. Pearce <spearce@spearce.org>

Merge branch 'master' of git://repo.or.cz/git/fastimport

* '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

git-svn: dcommit prints out the URL to be committed to

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: Eric Wong <normalperson@yhbt.net>

git-gui: Refactor diff pane popup support for future improvements

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: Shawn O. Pearce <spearce@spearce.org>

Teach bash about git-submodule and its subcommands

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: Shawn O. Pearce <spearce@spearce.org>

Teach bash to complete ref arguments to git-describe

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: Shawn O. Pearce <spearce@spearce.org>

Update bash completion with new 1.5.3 command line options

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: Shawn O. Pearce <spearce@spearce.org>

git-svn: update documentation with CAVEATS section

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

Reset terminal attributes when terminating git send-email

If you break out of the prompts presented to you by git send-email
your terminal can be left in an inconsistent state.  Here we trap
the interrupt signal and reset the terminal before exiting.

Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Document -u option in git-svnimport man page

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

Fix breakage in git-rev-list.txt

Also fix some innocent missing of quotes.

Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git.el: Avoid a lisp error when there's no current branch (detached HEAD).

Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix git-remote for ActiveState Perl

For reason unknown a package in ActiveState Perl 5.8.7 must implement
READLINE method differently for scalar and array context. The code
tested to work for more sane and recent version of perl (5.8.8 shipped
with Ubuntu), so maybe it was always a requirement.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: update tar.umask default

As noted by Mike Hommey, the documentation for the config setting tar.umask
is not up-to-date.  Commit f08b3b0e2e9ad87767d80ff03b013c686e08ba4b changed
the default from 0 to 2; this patch finally documents it.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Suggest unsetting core.bare when using new-workdir on a bare repository

If core.bare is set to true in the config file of a repository that
the user is trying to create a working directory from we should
abort and suggest to the user that they remove the option first.

If we leave the core.bare=true setting in the config file then
working tree operations will get confused when they attempt to
execute in the new workdir, as it shares its config file with the
bare repository.  The working tree operations will assume that the
workdir is bare and abort, which is not what the user wants.

If we changed core.bare to be false then working tree operations
will function in the workdir but other operations may fail in the
bare repository, as it claims to not be bare.

If we remove core.bare from the config then Git can fallback on
the legacy guessing behavior.  This allows operations in the bare
repository to work as though it were bare, while operations in the
workdirs to act as though they are not bare.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix new-workdir (again) to work on bare repositories

My day-job workflow involves using multiple workdirs attached to a
bunch of bare repositories.  Such repositories are stored inside of
a directory called "foo.git", which means `git rev-parse --git-dir`
will return "." and not ".git".  Under such conditions new-workdir
was getting confused about where the Git repository it was supplied
is actually located.

If we get "." for the result of --git-dir query it means we should
use the user supplied path as-is, and not attempt to perform any
magic on it, as the path is directly to the repository.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>