tokkee.org

Typo "bogos" in format-patch error message.

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

builtin-clone: fix typo

Signed-off-by: Fabrizio Chiarello <ponch@autistici.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Bust the ghost of long-defunct diffcore-pathspec.

This concept was retired by 77882f6 (Retire diffcore-pathspec.,
2006-04-10), more than 2 years ago.

Signed-off-by: Yann Dirson <ydirson@altern.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

completion: git commit should list --interactive

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

Merge branch 'dp/maint-rebase-fix' into maint

* dp/maint-rebase-fix:
  git-rebase--interactive: auto amend only edited commit
  git-rebase-interactive: do not squash commits on abort

Merge branch 'jc/maint-checkout-keep-remove' into maint

* jc/maint-checkout-keep-remove:
  checkout: do not lose staged removal

Merge branch 'jc/maint-diff-quiet' into maint

* jc/maint-diff-quiet:
  diff --quiet: make it synonym to --exit-code >/dev/null
  diff Porcelain: do not disable auto index refreshing on -C -C

Merge branch 'jc/maint-name-hash-clear' into maint

* jc/maint-name-hash-clear:
  discard_cache: reset lazy name_hash bit

Merge branch 'jc/maint-template-permbits' into maint

* jc/maint-template-permbits:
  Fix permission bits on sources checked out with an overtight umask

Merge branch 'mh/maint-honor-no-ssl-verify' into maint

* mh/maint-honor-no-ssl-verify:
  Don't verify host name in SSL certs when GIT_SSL_NO_VERIFY is set

sha1_file: link() returns -1 on failure, not errno

5723fe7 (Avoid cross-directory renames and linking on object creation,
2008-06-14) changed the call to use link() directly instead of through a
custom wrapper, but forgot that it returns 0 or -1, not 0 or errno.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Make git archive respect core.autocrlf when creating zip format archives

There is currently no call to git_config at the start of cmd_archive.
When creating tar archives the core config is read as a side-effect of
reading the tar specific config, but this doesn't happen for zip
archives.

The consequence is that in a configuration with core.autocrlf set,
although files in a tar archive are created with crlf line endings,
files in a zip archive retain unix line endings.

Signed-off-by: Charles Bailey <charles@hashpling.org>
Acked-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Add new test to demonstrate git archive core.autocrlf inconsistency

Signed-off-by: Charles Bailey <charles@hashpling.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: avoid warnings for commits without body

In the unusual case when there is no commit message, gitweb would
output an uninitialized value warning.

Signed-off-by: Joey Hess <joey@kitenet.net>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Clarified gitattributes documentation regarding custom hunk header.

The only part of the hunk header that we can change is the "TEXT"
portion.  Additionally, a few grammatical errors have been corrected.

Signed-off-by: Garry Dolley <gdolley@ucla.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: fix handling of even funkier branch names

Apparently do_switch() tolerates the lack of escaping in less
funky branch names.  For the really strange and scary ones, we
need to escape them properly.  It strangely maintains compatible
with the existing handling of branch names with spaces and
exclamation marks.

Reported-by: m.skoric@web.de ($gmane/94677)
Signed-off-by: Eric Wong <normalperson@yhbt.net>

git-svn: Always create a new RA when calling do_switch for svn://

Not doing so caused the "Malformed network data" error when a directoy
was deleted and replaced with a copy from an older version.

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

git-svn: factor out svnserve test code for later use

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

diff/diff-files: do not use --cc too aggressively

Textual diff output for unmerged paths was too eager to give condensed
combined diff.  Even though "diff -c" (and "diff-files -c -p") is a
request to view combined diff without condensing (otherwise the user would
have explicitly asked for --cc, not -c), we showed "--cc" output anyway.

0fe7c1d (built-in diff: assorted updates, 2006-04-29) claimed to be
careful about doing this, but its breakage was hidden because back then
"git diff" was still a shell script that did not use the codepath it
introduced fully.

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

Cosmetical command name fix

If we came from git.c the first arg would be "archive".
"git-archive" isn't a bug because cmd_archive() doesn't check
the first arg.

Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Start conforming code to "git subcmd" style part 3

User notifications are presented as 'git cmd', and code comments
are presented as '"cmd"' or 'git's cmd', rather than 'git-cmd'.

Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t9700/test.pl: remove File::Temp requirement

The object oriented version of File::Temp is a rather new incarnation it
seems. The File::Temp man page for v5.8.0 says "(NOT YET IMPLEMENTED)" in
the 'Objects' section. Instead of creating a file with a unique name in
the system TMPDIR, we can create our own temporary file with a static
name and use that instead.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Tested-by: Tom G. Christensen <tgc@statsbiblioteket.dk> on RHEL 3, Perl 5.8.0
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t9700/test.pl: avoid bareword 'STDERR' in 3-argument open()

Some versions of perl complain when 'STDERR' is used as the third argument
in the 3-argument form of open(). Convert to the 2-argument form which is
described for duping STDERR in my second edition camel book.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Tested-by: Tom G. Christensen <tgc@statsbiblioteket.dk> on RHEL 3, Perl 5.8.0
Signed-off-by: Junio C Hamano <gitster@pobox.com>

GIT 1.6.0.2

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

Merge branch 'ho/maint-dashless' into maint

* ho/maint-dashless:
  Start conforming code to "git subcmd" style part 2

Fix some manual typos.

Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Use compatibility regex library also on FreeBSD

Commit 3632cfc24 makes the same change for Darwin; however, the problem
also exists on FreeBSD.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Use compatibility regex library also on AIX

This augments 3632cfc24 (Use compatibility regex library on Darwin,
2008-09-07), which already carries a "Tested-by" statement for AIX,
but that test was actually done with this patch included.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Tested-by: Mike Ralphson <mike@abacus.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Update draft release notes for 1.6.0.2

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

Use compatibility regex library for OSX/Darwin

The standard libc regex library on OSX does not support alternation
in POSIX Basic Regular Expression mode.  This breaks the diff.funcname
functionality on OSX.

To fix this, we use the GNU regex library which is already present in
the compat/ diretory for the MinGW port.  However, simply adding compat/
to the COMPAT_CFLAGS variable causes a conflict between the system
fnmatch.h and the one present in compat/.  To remedy this, move the
regex and fnmatch functionality to their own subdirectories in compat/
so they can be included seperately.

Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
Tested-by: Mike Ralphson <mike@abacus.co.uk> (AIX)
Tested-by: Johannes Sixt <johannes.sixt@telecom.at> (MinGW)
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: Fixes my() parameter list syntax error in pre-5.8 Perl

Signed-off-by: Marcus Griep <marcus@griep.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git.pm: Use File::Temp->tempfile instead of ->new

Perl 5.8.0 ships with File::Temp 0.13, which does not have the new()
interface introduced in 0.14, as pointed out by Tom G. Christensen.

This modifies Git.pm to use the more established tempfile() interface
and updates 'git svn' to match.

Signed-off-by: Marcus Griep <marcus@griep.us>
Acked-by: Eric Wong <normalperson@yhbt.net>
Tested-by: Tom G. Christensen <tgc@statsbiblioteket.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t7501: always use test_cmp instead of diff

This should make the output more readable (by default using diff -u)
when some tests fail.

Also changed the diff order from "current expected" to "expected
current".

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jc/maint-log-grep' into maint

* jc/maint-log-grep:
  log --author/--committer: really match only with name part

Merge branch 'jc/maint-hide-cr-in-diff-from-less' into maint

* jc/maint-hide-cr-in-diff-from-less:
  diff: Help "less" hide ^M from the output

Merge branch 'jc/maint-checkout-fix' into maint

* jc/maint-checkout-fix:
  checkout: do not check out unmerged higher stages randomly

Merge branch 'np/maint-safer-pack' into maint

* np/maint-safer-pack:
  fixup_pack_header_footer(): use nicely aligned buffer sizes
  index-pack: use fixup_pack_header_footer()'s validation mode
  pack-objects: use fixup_pack_header_footer()'s validation mode
  improve reliability of fixup_pack_header_footer()
  pack-objects: improve returned information from write_one()

checkout: do not lose staged removal

The logic to checkout a different commit implements the safety to never
lose user's local changes.  For example, switching from a commit to
another commit, when you have changed a path that is different between
them, need to merge your changes to the version from the switched-to
commit, which you may not necessarily be able to resolve easily.  By
default, "git checkout" refused to switch branches, to give you a chance
to stash your local changes (or use "-m" to merge, accepting the risks of
getting conflicts).

This safety, however, had one deliberate hole since early June 2005.  When
your local change was to remove a path (and optionally to stage that
removal), the command checked out the path from the switched-to commit
nevertheless.

This was to allow an initial checkout to happen smoothly (e.g. an initial
checkout is done by starting with an empty index and switching from the
commit at the HEAD to the same commit).  We can tighten the rule slightly
to allow this special case to pass, without losing sight of removal
explicitly done by the user, by noticing if the index is truly empty when
the operation begins.

For historical background, see:

    http://thread.gmane.org/gmane.comp.version-control.git/4641/focus=4646

This case is marked as *0* in the message, which both Linus and I said "it
feels somewhat wrong but otherwise we cannot start from an empty index".

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

Fix permission bits on sources checked out with an overtight umask

Two patches 9907721 (templates/Makefile: don't depend on local umask
setting, 2008-02-28) and 96cda0b (templates/Makefile: install is
unnecessary, just use mkdir -p, 2008-08-21) tried to prevent an overtight
umask the builder/installer might have from screwing over the installation
procedure, but we forgot there was another source of trouble.  If the
person who checked out the source tree had an overtight umask, it will
leak out to the built products, which is propagated to the installation
destination.

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

git-rebase--interactive: auto amend only edited commit

"git rebase --continue" issued after git rebase being stop by "edit"
command is trying to amend the last commit using stage changes. However,
if the last commit is not the commit that was marked as "edit" then it
can produce unexpected results.

For instance, after being stop by "edit", I have made some changes to
commit message using "git commit --amend". After that I realized that
I forgot to add some changes to some file. So, I said "git add file"
and the "git rebase --continue". Unfortunately, it caused that the new
commit message was lost.

Another problem is that after being stopped at "edit", the user adds new
commits. In this case, automatic amend behavior of git rebase triggered
by some stage changes causes that not only that the log message of the
last commit is lost but that it will contain also wrong Author and Date
information.

Therefore, this patch restrict automatic amend only to the situation
where HEAD is the commit at which git rebase stop by "edit" command.

Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Start conforming code to "git subcmd" style part 2

User notifications are presented as 'git cmd', and code comments
are presented as '"cmd"' or 'git's cmd', rather than 'git-cmd'.

Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-rebase-interactive: do not squash commits on abort

If git rebase interactive is stopped by "edit" command and then the user
said "git rebase --continue" while having some stage changes, git rebase
interactive is trying to amend the last commit by doing:
  git --soft reset && git commit

However, the user can abort commit for some reason by providing an empty
log message, and that would leave the last commit undone, while the user
being completely unaware about what happened. Now if the user tries to
continue, by issuing "git rebase --continue" that squashes two previous
commits.

Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Don't verify host name in SSL certs when GIT_SSL_NO_VERIFY is set

Originally from Mike Hommey; earlier we were disabling SSL_VERIFYPEER
but SSL_VERIFYHOST was in effect even when the user asked not to with
the environment variable.

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

diff --quiet: make it synonym to --exit-code >/dev/null

The point of --quiet was to return the status as early as possible without
doing any extra processing.  Well behaved scripts, when they expect to run
many diff operations inside, are supposed to run "update-index --refresh"
upfront; we do not want them to pay the price of iterating over the index
and comparing the contents to fix the stat dirtiness, and we avoided most
of the processing in diffcore_std() when --quiet is in effect.

But scripts that adhere to the good practice won't have to pay any more
price than the necessary lstat(2) that will report stat cleanliness, as
long as only -q is given without any fancier diff options.

More importantly, users who do ask for "--quiet -M --filter=D" (in order
to notice only the deletion, not paths that disappeared only because they
have been renamed away) deserve to get the result they asked for, even it
means they have to pay the extra price; the alternative is to get a cheap
early return that gives a result they did not ask for, which is much
worse.

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

diff Porcelain: do not disable auto index refreshing on -C -C

When we enabled the automatic refreshing of the index to "diff" Porcelain,
we disabled it when --find-copies-harder was asked, but there is no good
reason to do so.  In the following command sequence, the first "diff"
shows an "empty" diff exposing stat dirtyness, while the second one does
not.

    $ >foo
    $ git add foo
    $ touch foo
    $ git diff -C -C
    $ git diff -C

This fixes the inconsistency.

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

Update draft release notes for 1.6.0.2

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

stash: refresh the index before deciding if the work tree is dirty

Unlike the case where the user does have a real change in the work tree,
refusing to work because of unclean stat information is not very helpful.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Nanako Shiraishi <nanako3@lavabit.com>

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

* 'maint' of git://repo.or.cz/git-gui:
  git-gui: Fix diff parsing for lines starting with "--" or "++"
  git-gui: Fix string escaping in po2msg.sh
  git gui: show diffs with a minimum of 1 context line
  git-gui: update all remaining translations to French.
  git-gui: Update french translation

Mention the fact that 'git annotate' is only for backward compatibility.

When somebody is reading git-blame.txt (or git-annotate.txt) for the first
time, the message we would like to send is:

 (1) Here is why you would want to use this command, what it can do
     (perhaps more than what you would have expected from "$scm blame"),
     and how you tell it to do what it does.

     This is obvious.

 (2) You might have heard of the command with the other name.  There is no
     difference between the two, except they differ in their default
     output formats.

     This is essential to answer: "git has both?  how are they different?"

 (3) We tend to encourage blame over annotate for new scripts and new
     people, but there is no reason to choose one over the other.

     This is not as important as (2), but would be useful to avoid
     repeated questions about "when will we start deprecating this?"

As long as we describe (2) on git-annotate page clearly enough, people who
read git-blame page first and get curious can refer to git-annotate page.
While at it, subtly hint (3) without being overly explicit.

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

"blame -c" should be compatible with "annotate"

There is no reason to have a separate variable cmd_is_annotate;
OUTPUT_ANNOTATE_COMPAT option is supposed to produce the compatibility
output, and we should produce the same output even when the command was
not invoked as "annotate" but as "blame -c".

Noticed by Pasky.

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

log --author/--committer: really match only with name part

When we tried to find commits done by AUTHOR, the first implementation
tried to pattern match a line with "^author .*AUTHOR", which later was
enhanced to strip leading caret and look for "^author AUTHOR" when the
search pattern was anchored at the left end (i.e. --author="^AUTHOR").

This had a few problems:

 * When looking for fixed strings (e.g. "git log -F --author=x --grep=y"),
   the regexp internally used "^author .*x" would never match anything;

 * To match at the end (e.g. "git log --author='google.com>$'"), the
   generated regexp has to also match the trailing timestamp part the
   commit header lines have.  Also, in order to determine if the '$' at
   the end means "match at the end of the line" or just a literal dollar
   sign (probably backslash-quoted), we would need to parse the regexp
   ourselves.

An earlier alternative tried to make sure that a line matches "^author "
(to limit by field name) and the user supplied pattern at the same time.
While it solved the -F problem by introducing a special override for
matching the "^author ", it did not solve the trailing timestamp nor tail
match problem.  It also would have matched every commit if --author=author
was asked for, not because the author's email part had this string, but
because every commit header line that talks about the author begins with
that field name, regardleses of who wrote it.

Instead of piling more hacks on top of hacks, this rethinks the grep
machinery that is used to look for strings in the commit header, and makes
sure that (1) field name matches literally at the beginning of the line,
followed by a SP, and (2) the user supplied pattern is matched against the
remainder of the line, excluding the trailing timestamp data.

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

git-gui: Fix diff parsing for lines starting with "--" or "++"

Languages like Lua and SQL use "--" to mark a line as commented out.
If this appears at column 0 and is part of the pre-image we may see
"--- foo" in the diff, indicating that the line whose content is
 "-- foo" has been removed from the new version.

git-gui was incorrectly parsing "--- foo" as the old file name
in the file header, causing it to generate a bad patch file when
the user tried to stage or unstage a hunk or the selected line.
We need to keep track of where we are in the parsing so that we do
not misread a deletion or addition record as part of the header.

Reported-by: Alexander Gladysh <agladysh@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

diff --cumulative is a sub-option of --dirstat

The option used to be implemented as if it is a totally independent one,
but "git diff --cumulative" would not mean anything without "--dirstat".

This makes --cumulative imply --dirstat.

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

bash completion: Hide more plumbing commands

git <tab><tab> still shows way too many commands, some of them
are clearly plumbing. This patch hides the plumbing commands
liberally (that is, in special cases, users still might want to
call one of the hidden commands, a *normal* workflow should never
involve these, though - and if it does, we have a UI problem anyway).

Signed-off-by: Petr Baudis <pasky@suse.cz>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Start 1.6.0.2 maintenance cycle

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

Merge branch 'nd/worktree' into maint

* nd/worktree:
  setup_git_directory(): fix move to worktree toplevel directory
  update-index: fix worktree setup
  read-tree: setup worktree if merge is required
  grep: fix worktree setup
  diff*: fix worktree setup

Merge branch 'ho/dashless' into maint

* ho/dashless:
  tests: use "git xyzzy" form (t7200 - t9001)
  tests: use "git xyzzy" form (t7000 - t7199)
  tests: use "git xyzzy" form (t3600 - t6999)
  tests: use "git xyzzy" form (t0000 - t3599)
  'git foo' program identifies itself without dash in die() messages
  Start conforming code to "git subcmd" style

tests: use "git xyzzy" form (t7200 - t9001)

Converts tests between t7201-t9001.

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tests: use "git xyzzy" form (t7000 - t7199)

Converts tests between t7001-t7103.

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix passwd(5) ref and reflect that commit doens't use commit-tree

Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

improve handling of sideband message display

Currently the code looks for line break characters in order to prepend
"remote: " to every line received as many lines can be sent in a single
chunk.  However the opposite might happen too, i.e. a single message
line split amongst multiple chunks.  This patch adds support for the
later case to avoid displays like:

remote: Compressing objeremote: cts: 100% (313/313), done.

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

tests: use "git xyzzy" form (t3600 - t6999)

Converts tests between t3600-t6300.

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tests: use "git xyzzy" form (t0000 - t3599)

Converts tests between t0050-t3903.

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

checkout: fix message when leaving detached HEAD

The shell version of git checkout would print:

  Previous HEAD position was 1234abcd... commit subject line

when leaving a detached HEAD for another commit. Ths C
version attempted to implement this, but got the condition
wrong such that the behavior never triggered.

This patch simplifies the conditions for showing the message
to the ones used by the shell version: any time we are
leaving a detached HEAD and the new and old commits are not
the same (this suppresses it for the "git checkout -b new"
case recommended when you enter the detached state).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

clone: fix creation of explicitly named target directory

'git clone <repo> path/' (note the trailing slash) fails, because the
entire path is interpreted as leading directories. So when mkdir tries to
create the actual path, it already exists.

This makes sure trailing slashes are removed.

Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: add merge_recursive.h to LIB_H

When modifying merge-recursive.h, for example builtin-merge-recursive.c
have to be recompiled which was not true till now, causing various
runtime errors using an incremental build.

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Improve documentation for --dirstat diff option

Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Bring local clone's origin URL in line with that of a remote clone

On a local clone, "git clone" would use the fully DWIMmed path as the origin
URL in the resulting repo. This was slightly inconsistent with the case of a
remote clone where the _given_ URL was used as the origin URL (because the
DWIMming was done remotely, and was therefore not available to "git clone").

This behaviour caused problems when cloning a local non-bare repo with
relative submodule URLs, because these submodule URLs would then be resolved
against the DWIMmed URL (e.g. "/repo/.git") instead of the given URL (e.g.
"/repo").

This patch teaches "git clone" to use the _given_ URL - instead of the
DWIMmed path - as the origin URL. This causes relative submodule URLs to be
resolved correctly, as long the _given_ URL indicates the correct directory
against which the submodule URLs should be resolved.

The patch also updates a testcase that contained the old-style origin URLs.

Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: minor cleanup in a use case in 'git stash' manual

There is no need to explicitly pass the file to be committed to 'git
commit', because it's contents is already in the index.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: fix disappeared lines in 'git stash' manpage

Asciidoc removes lines starting with a dot when creating manpages.
Since those lines were comments in use case examples showing shell
commands, preceed those lines with a hash sign.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: fix reference to a for-each-ref option

... to match the synopsis section

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-gui: Fix string escaping in po2msg.sh

Escape '$', because otherwise git-gui crashes while
trying to load malformed Japanese localization strings.

Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git gui: show diffs with a minimum of 1 context line

Staging hunks without context does not work, because line number
information would have to be recomputed for individual hunks.

Since it is already possible to stage individual lines using
'Stage Line for Commit', zero context diffs are not really
necessary for git gui.

Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Document sendemail.envelopesender configuration

Signed-off-by: Ask Bjørn Hansen <ask@develooper.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Document clarification: gitmodules, gitattributes

The SYNOPSIS section of gitattibutes and gitmodule fail to clearly
specify the name of the in tree files used.  This patch brings in the
initial `.' and the fact that the `.gitmodules' file should reside at
the top-level of the working tree.

Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

'git foo' program identifies itself without dash in die() messages

This is a mechanical conversion of all '*.c' files with:

s/((?:die|error|warning)\("git)-(\S+:)/$1 $2/;

The result was manually inspected and no false positive was found.

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

setup_git_directory(): fix move to worktree toplevel directory

When setup_git_directory() returns successfully, it is supposed to move
current working directory to worktree toplevel directory.

However, the code recomputing prefix inside setup_git_directory() has
to move cwd back to original working directory, in order to get new
prefix.  After that, it should move cwd back to worktree toplevel
directory as expected.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

update-index: fix worktree setup

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

config.txt: Add missing colons after option name

gitcvs.usecrlfattr --> gitcvs.usecrlfattr::

This fixes an asciidoc markup issue.

Signed-off-by: Teemu Likonen <tlikonen@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff: Help "less" hide ^M from the output

When the tracked contents have CRLF line endings, colored diff output
shows "^M" at the end of output lines, which is distracting, even though
the pager we use by default ("less") knows to hide them.

The problem is that "less" hides a carriage-return only at the end of the
line, immediately before a line feed.  The colored diff output does not
take this into account, and emits four element sequence for each line:

   - force this color;
   - the line up to but not including the terminating line feed;
   - reset color
   - line feed.

By including the carriage return at the end of the line in the second
item, we are breaking the smart our pager has in order not to show "^M".
This can be fixed by changing the sequence to:

   - force this color;
   - the line up to but not including the terminating end-of-line;
   - reset color
   - end-of-line.

where end-of-line is either a single linefeed or a CRLF pair.  When the
output is not colored, "force this color" and "reset color" sequences are
both empty, so we won't have this problem with or without this patch.

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

gitattributes: -crlf is not binary

The description of crlf attribute incorrectly said that "-crlf" means
binary.  It is true that for binary files you would want "-crlf", but
that is not the same thing.

We also have supported attribute macros and via that mechanism a handy
"binary" to specify "-crlf -diff" at the same time.  It was not documented
anywhere as far as I can tell, even though the support was there from
the very beginning.

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

checkout: do not check out unmerged higher stages randomly

During a conflicted merge when you have unmerged stages for a
path F in the index, if you said:

    $ git checkout F

we rewrote F as many times as we have stages for it, and the
last one (typically "theirs") was left in the work tree, without
resolving the conflict.

This fixes it by noticing that a specified pathspec pattern
matches an unmerged path, and by erroring out.

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

Start conforming code to "git subcmd" style

User notifications are presented as 'git cmd', and code comments
are presented as '"cmd"' or 'git's cmd', rather than 'git-cmd'.

Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-apply: Loosen "match_beginning" logic

Even after a handfle attempts, match_beginning logic still has corner
cases:

    1bf1a85 (apply: treat EOF as proper context., 2006-05-23)
    65aadb9 (apply: force matching at the beginning., 2006-05-24)
    4be6096 (apply --unidiff-zero: loosen sanity checks ..., 2006-09-17)
    ee5a317 (Fix "git apply" to correctly enforce "match ..., 2008-04-06)

This is a tricky piece of code.

We still incorrectly enforce "match_beginning" for -U0 matches.
I noticed this while trying out an example sequence from Clemens Buchacher:

    $ echo a >victim
    $ git add victim
    $ echo b >>victim
    $ git diff -U0 >patch
    $ cat patch
    diff --git i/victim w/victim
    index 7898192..422c2b7 100644
    --- i/victim
    +++ w/victim
    @@ -1,0 +2 @@ a
    +b
    $ git apply --cached --unidiff-zero <patch
    $ git show :victim
    b
    a

The change inserts a new line before the second line, but we insist it to
be applied at the beginning.  As the result, the code refuses to apply it
at the original offset, and we end up adding the line at the beginning.

Updates to the test script are by Clemens Buchacher.

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

Fix example in git-name-rev documentation

Since 59d3f54 (name-rev: avoid "^0" when unneeded, 2007-02-20), name-rev
stopped showing an unnecessary "^0" to dereference a tag down to a commit.
The patch should have made a matching update to the documentation, but we
forgot.

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

Merge branch 'sp/missing-thin-base' into maint

* sp/missing-thin-base:
  pack-objects: Allow missing base objects when creating thin packs

Merge branch 'af/maint-install-no-handlink' into maint

* af/maint-install-no-handlink:
  Fix use of hardlinks in "make install"
  Makefile: always provide a fallback when hardlinks fail

shell: do not play duplicated definition games to shrink the executable

Playing with linker games to shrink git-shell did not go well with various
other platforms and compilers.

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

Fix use of hardlinks in "make install"

The code failed to filter-out git-add properly on platforms were $X is
not empty (ATM there is only one such a platform).

Than it tried to create a hardlink to the file ($execdir/git-add) it just
removed (because git-add is first in the BUILT_INS), so ln failed (but
because stderr was redirected into /dev/null the error was never seen), and
the whole install ended up using "ln -s" instead.

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

fixup_pack_header_footer(): use nicely aligned buffer sizes

It should be more efficient to use nicely aligned buffer sizes, either
for filesystem operations or SHA1 checksums.  Also, using a relatively
small nominal size might allow for the data to remain in L1 cache
between both SHA1_Update() calls.

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

index-pack: use fixup_pack_header_footer()'s validation mode

When completing a thin pack, a new header has to be written to
the pack and a new SHA1 computed.  Make sure that the SHA1 of what
is being read back matches the SHA1 of what was written for both:
the original pack and the appended objects.

To do so, a couple write_or_die() calls were converted to sha1write()
which has the advantage of doing some buffering as well as handling
SHA1 and CRC32 checksum already.

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

pack-objects: use fixup_pack_header_footer()'s validation mode

When limiting the pack size, a new header has to be written to the
pack and a new SHA1 computed.  Make sure that the SHA1 of what is being
read back matches the SHA1 of what was written.

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

improve reliability of fixup_pack_header_footer()

Currently, this function has the potential to read corrupted pack data
from disk and give it a valid SHA1 checksum.  Let's add the ability to
validate SHA1 checksum of existing data along the way, including before
and after any arbitrary point in the pack.

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

pack-objects: improve returned information from write_one()

This function returns 0 when the current object couldn't be written
due to the pack size limit, otherwise the current offset in the pack.
There is a problem with this approach however, since current object
could be a delta and its delta base might just have been written in
the same write_one() call, but those successfully written objects are
not accounted in the offset variable tracked by the caller. Currently
this is not an issue but a subsequent patch will need this.

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

Merge branch 'np/verify-pack' into maint

* np/verify-pack:
  discard revindex data when pack list changes

tutorial: gentler illustration of Alice/Bob workflow using gitk

Update to gitutorial as discussedin the git mailing list:

http://marc.info/?t=121969390900002&r=1&w=2

Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pretty=format: respect date format options

When running a command like:

  git log --pretty=format:%ad --date=short

the date option was ignored. This patch causes it to use whatever
format was specified by --date (or by --relative-date, etc), just
as the non-user formats would do.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

make git-shell paranoid about closed stdin/stdout/stderr

It is in general unsafe to start a program with one or more of file
descriptors 0/1/2 closed.  Karl Chen for example noticed that stat_command
does this in order to rename a pipe file descriptor to 0:

    dup2(from, 0);
    close(from);

... but if stdin was closed (for example) from == 0, so that

    dup2(0, 0);
    close(0);

just ends up closing the pipe.  Another extremely rare but nasty problem
would occur if an "important" file ends up in file descriptor 2, and is
corrupted by a call to die().

Fixing this in git was considered to be overkill, so this patch works
around it only for git-shell.  The fix is simply to open all the "low"
descriptors to /dev/null in main.

Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Acked-by: Stephen R. van den Berg <srb@cuci.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Document gitk --argscmd flag.

This was part of my original patch, but appears to have been lost.

Signed-off-by: Yann Dirson <ydirson@altern.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix '--dirstat' with cross-directory renaming

The dirstat code depends on the fact that we always generate diffs with
the names sorted, since it then just does a single-pass walk-over of the
sorted list of names and how many changes there were. The sorting means
that all files are nicely grouped by directory.

That all works fine.

Except when we have rename detection, and suddenly the nicely sorted list
of pathnames isn't all that sorted at all. And now the single-pass dirstat
walk gets all confused, and you can get results like this:

  [torvalds@nehalem linux]$ git diff --dirstat=2 -M v2.6.27-rc4..v2.6.27-rc5
     3.0% arch/powerpc/configs/
     6.8% arch/arm/configs/
     2.7% arch/powerpc/configs/
     4.2% arch/arm/configs/
     5.6% arch/powerpc/configs/
     8.4% arch/arm/configs/
     5.5% arch/powerpc/configs/
    23.3% arch/arm/configs/
     8.6% arch/powerpc/configs/
     4.0% arch/
     4.4% drivers/usb/musb/
     4.0% drivers/watchdog/
     7.6% drivers/
     3.5% fs/

The trivial fix is to add a sorting pass, fixing it to:

  [torvalds@nehalem linux]$ git diff --dirstat=2 -M v2.6.27-rc4..v2.6.27-rc5
    43.0% arch/arm/configs/
    25.5% arch/powerpc/configs/
     5.3% arch/
     4.4% drivers/usb/musb/
     4.0% drivers/watchdog/
     7.6% drivers/
     3.5% fs/

Spot the difference. In case anybody wonders: it's because of a ton of
renames from {include/asm-blackfin => arch/blackfin/include/asm} that just
totally messed up the file ordering in between arch/arm and arch/powerpc.

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