GIT 1.5.4.7

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

gitweb: do not run "git diff" that is Porcelain

Jakub says that legacy-style URI to view two blob differences are never
generated since 1.4.3.  This codepath runs "git diff" Porcelain from the
gitweb, which is a no-no.  It can trigger diff.external command that is
specified in the configuration file of the repository being viewed.

This patch applies to v1.5.4 and later.

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

GIT 1.5.4.6

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

git-shell: accept "git foo" form

This is a backport of 0a47dc110e042b5bcc63dc94c8d517e67efe9306
to 'maint' to be included in 1.5.6.2 so that older server side
can accept dashless form of request when clients are updated.

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

builtin-fast-export: Only output a single parent per line

According to the git-fast-import man-page, you can only put a single
committish per merge: line, like this:

  merge :10
  merge :11

However, git-fast-export puts all parents on a single line, like this:

  merge :10 :11

This changes fast-export to output a single parent per line.  Otherwise
neither git-fast-import nor bzr-fast-import can read its output.

[jc: fix-up to remove excess LF in the output that makes fast-import barf]

Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rev-parse --symbolic-full-name: don't print '^' if SHA1 is not a ref

The intention of --symbolic-full-name is to not print anything if a
revision is not an exact ref. But this command:

    $ git-rev-parse --symbolic-full-name --not master~1

still emitted a sole '^' to stdout (provided that there's no other ref at
master~1). This fixes it.

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

git-am: fix typo in usage message

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

doc/git-daemon: s/uploadarchive/uploadarch/

The git-daemon upload-archive feature has always used the
config directive 'daemon.uploadarch'; the documentation
which came later seems to have just mistakenly used the
wrong name.

Noticed by lionel@over-blog.com.

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

Documentation/git-describe.txt: make description more readable

Signed-off-by: Ian Hilt <ian.hilt@gmail.com>
Credit-to: Kevin Ballard <kevin@sb.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

wt-status.h: declare global variables as extern

There are linkers out there that complain if a global non-static variable
is defined multiple times.

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

builtin-commit.c: add -u as short name for --untracked-files

This makes the C code consistent with the documentation and the old shell
code.

Signed-off-by: Sitaram Chamarty <sitaramc@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-repack: re-enable parsing of -n command line option

In commit 5715d0b (Migrate git-repack.sh to use git-rev-parse --parseopt,
2007-11-04), parsing of the '-n' command line option was accidentally lost
when git-repack.sh was migrated to use git-rev-parse --parseopt. This adds
it back.

Signed-off-by: A Large Angry SCM <gitzilla@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation/config.txt: Mention branch.<name>.rebase applies to "git pull"

Signed-off-by: Dustin Sallings <dustin@spy.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc: clarify definition of "update" for git-add -u

The "-u" option is described only in terms of "updating"
files, which in turn is described only as "similar to what
git commit -a does". Let's be a little more specific about
what updating entails.

Suggested by Geoffrey Irving.

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

filter-branch: Documentation fix.

It's --msg-filter, not --message-filter.

Signed-off-by: Florian Ragwitz <rafl@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

cvsimport: always pass user data to "system" as a list

This avoids invoking the shell. Not only is it faster, but
it prevents the possibility of interpreting our arguments in
the shell.

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

fix reflog approxidate parsing bug

In get_sha1_basic, we parse a string like

  HEAD@{10 seconds ago}:path/to/file

into its constituent ref, reflog date, and path components.
We never actually munge the string itself, but instead keep
offsets into the string with their associated lengths.

When we call approxidate on the contents inside braces,
however, we pass just a string without a length. This means
that approxidate could sometimes look past the closing brace
and (erroneously) interpret the rest of the string as part
of the date.

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

Remove 'header' from --signoff option description

Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t5516: remove ambiguity test (1)

This test tried to push into a remote with ambiguous refs in
remotes/$x/master and remotes/$y/master. However, the remote
never actually tells us about the refs/remotes hierarchy, so
we don't even see this ambiguity.

The test happened to pass because we were simply looking for
failure, and the test fails for another reason: the dst
refspec does not exist and does not begin with refs/, making
it invalid.

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

Linked glossary from cvs-migration page

Coming from CVS, I found the git glossary vital to learning git and learning
how terms in git correlate to the cvs terminology with which I am familiar.

This patch links the glossary from the cvs-migration page so cvs users will
be able to fine the glossary as soon as they start looking at git documents.

Signed-off-by: Matt Graham <mdg149@gmail.com>
Acked-by: J. Bruce Fields <bfields@fieldses.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

write-tree: properly detect failure to write tree objects

Tomasz Fortuna reported that "git commit" does not error out properly when
it cannot write tree objects out.  "git write-tree" shares the same issue,
as the failure to notice the error is deep in the logic to write tree
objects out recursively.

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

svn-git: Use binmode for reading/writing binary rev maps

Otherwise, there is a possible interaction with UTF-8 locales in
combination with PERL_UNICODE, resulting in "inconsistent size: 40" or
"read:"-type errors.

See also:
    perldoc -f binmode
    <http://perldoc.perl.org/perl581delta.html#UTF-8-no-longer-default-under-UTF-8-locales>

Signed-off-by: Michael Weber <michaelw@foldr.org>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff options documentation: refer to --diff-filter in --name-status

git diff --name-status outputs letters, but the meaning of those letters
is documented elsewhere. Add a note to make the manpage more intuitive.

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

git-svn bug with blank commits and author file

When trying to import from svn using an author file, git-svn bails out
if it encounters a blank author. The attached patch changes this
behavior and allow using the author file with blanks authors.

I came across this bug while importing from a cvs2svn repo where the
initial revision (1) has a blank author. This doesn't break the behavior
of bailing out when an unknown author is encountered.

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

archive.c: format_subst - fixed bogus argument to memchr

Also removed a superfluous test.

Signed-off-by: Ariel Badichi <abadichi@bezeqint.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

copy.c: copy_fd - correctly report write errors

Previously, the errno could have been lost due to an intervening
close() call.

This patch also contains minor cosmetic changes.

Signed-off-by: Ariel Badichi <abadichi@bezeqint.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitattributes: Fix subdirectory attributes specified from root directory

Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

am: POSIX portability fix

POSIX allows echo without flag to interpret specials such as \n, and we
tried to make things portable by using printf instead where it matters.
Recently added code to "git am" had unprotected "echo", which was caught
by t4014 and Rémi Vanicat.

This should fix it.

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

git-am: minor cleanup

This moves the assignment to FIRSTLINE down so that we do not have
to have multiple copies.

Suggested by Linus.

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

Clarify and fix English in "git-rm" documentation

Do some verb-noun agreement changes.
Clarify some file globbing cases.
Fixed a wrong statement in an example.

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

git-bisect: make "start", "good" and "skip" succeed or fail atomically

Before this patch, when "git bisect start", "git bisect good" or
"git bisect skip" were called with many revisions, they could fail
after having already marked some revisions as "good", "bad" or
"skip".

This could be especilally bad for "git bisect start" because as
the file ".git/BISECT_NAMES" would not have been written, there
would have been no attempt to clear the marked revisions on a
"git bisect reset". That's because if there is no
".git/BISECT_NAMES" file, nothing is done to clean things up, as
the bisect session is not supposed to have started.

While at it, let's also create the ".git/BISECT_START" file, only
after ".git/BISECT_NAMES" as been created.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-am: cope better with an empty Subject: line

When the Subject: line is empty for whatever reason, git-am was fooled by
it and left an empty line at the beginning of the resulting commit log
message.

This moves the logic around so that we do not keep $SUBJECT in a separate
variable.  Instead, $dotest/msg-clean, which used to be the log message
body extracted from the message and then trailing whitespaces cleansed
out, now contains the subject line followed by a blank line at the
beginning for normal messages, and we use the first line from the file as
the summary line throughout the program.

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

Ignore leading empty lines while summarizing merges

"git log" and friends normally skip the initial empty lines when showing
one-line summary of a commit, but merge summary didn't.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
----
 builtin-fmt-merge-msg.c |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

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

bisect: squelch "fatal: ref HEAD not a symref" misleading message

To get the current HEAD when we start bisecting using for example
"git bisect start", we first try "git symbolic-ref HEAD" to get a
nice name, and if it fails, we fall back to "git rev-parse
--verify HEAD".

The problem is that when "git symbolic-ref HEAD" fails, it
displays "fatal: ref HEAD not a symref", so it looks like "git
bisect start" failed and does not accept detached HEAD, even if
in fact it worked fine.

This patch adds "-q" option to the "git symbolic-ref" call to
get rid of the misleading error message.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin-apply: Show a more descriptive error on failure when opening a patch

When a patch can't be opened (it doesn't exist, there are permission
problems, etc.) we get the usage text, which is not a proper indication of
failure.

Signed-off-by: Alberto Bertogli <albertito@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Clarify documentation of git-cvsserver, particularly in relation to git-shell

For SSH clients restricted to git-shell, CVS_SERVER does not have to be
specified, because git-shell understands the default value of 'cvs' to
mean git-cvsserver'. This makes it totally transparent to CVS users, but
the instruction to set up CVS access for people with real shell access
does not apply.

Previous wording mentioning GIT_AUTHOR, GIT_COMMITTER variables was
unclear that we really meant GIT_AUTHOR_(NAME|EMAIL), etc.

Note that the .ssh/environment file is a good place to set these, and that
the .bashrc is shell-specific. Add a bit of text to differentiate cvs -d
(setting CVSROOT) from cvs co -d (setting the name of the newly checked
out directory).  Removed an extra 'Example:' string.

Signed-off-by: Scott Collins <scc@ScottCollins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Docs gitk: Explicitly mention the files that gitk uses (~/.gitk)

gitk creates and uses ~/.gitk

Signed-off-by: Clifford Caoile <piyo@users.sourceforge.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Document -w option to shortlog

Noticed by Fredrik Noring.

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

bisect: report bad rev better

The previous one overwrote the variable used to report the bad input
when the input is actually bad, and we did not give a useful enough
information.  This corrects it.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bisect: fix bad rev checking in "git bisect good"

It seems that "git bisect good" and "git bisect skip" have never
properly checked arguments that have been passed to them. As soon
as one of them can be parsed as a SHA1, no error or warning would
be given.

This is because 'git rev-parse --revs-only --no-flags "$@"' always
"exit 0" and outputs all the SHA1 it can found from parsing "$@".

This patch fix this by using, for each "bisect good" argument, the
same logic as for the "bisect bad" argument.

While at it, this patch teaches "bisect bad" to give a meaningfull
error message when it is passed more than one argument.

Note that if "git bisect good" or "git bisect skip" is given some
proper revs and then something that is not a proper rev, then the
first proper revs will still have been marked as "good" or "skip".

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

revision.c: make --date-order overriddable

Jan Engelhardt noticed that while --topo-order can be overridden by a
subsequent --date-order, the reverse was not possible. That's because
setup_revisions() failed to set revs->lifo properly.

Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix section about backdating tags in the git-tag docs

The tagger is equal to the committer, not the author, so
GIT_COMMITTER_DATE is the right environment variable to use, not
GIT_AUTHOR_DATE.

Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Document option --only of git commit

Its documentation was removed by 6c96753 (Documentation/git-commit: rewrite
to make it more end-user friendly, 2006-12-08), even though it is referenced
from a few places, including builtin-commit.c (as part of the commentary in
the commit message template).

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

Documentation/git-request-pull: Fixed a typo ("send" -> "end")

Signed-off-by: Dirk Suesserott <newsletter@dirk.my1.cc>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

core-tutorial.txt: Fix showing the current behaviour.

The --root option from "git diff-tree" won't do nothing
when is given to commands like git-whatchanged or git-log,
because those always print the initial commit by default.

This fixes the tutorial explaining the function of the
log.showroot configuration variable.

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

git-archive: ignore prefix when checking file attribute

Ulrik Sverdrup noticed that git-archive doesn't correctly apply the attribute
export-subst when the option --prefix is given, too.

When it checked if a file has the attribute turned on, git-archive would try
to look up the full path -- including the prefix -- in .gitattributes.  That's
wrong, as the prefix doesn't need to have any relation to any existing
directories, tracked or not.

This patch makes git-archive ignore the prefix when looking up if value of the
attribute export-subst for a file.

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

Fix documentation syntax of optional arguments in short options.

When an argument for an option is optional, like in -n from git-tag,
puting a space between the option and the argument is interpreted
as a missing argument for the option plus an isolated argument.
Documentation now reflects the need to write the parameter following
the option -n, as in "git tag -nARG", for instance.

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

Fix "git apply" to correctly enforce "match at the beginning"

An earlier commit 4be6096 (apply --unidiff-zero: loosen sanity checks for
--unidiff=0 patches, 2006-09-17) made match_beginning and match_end
computed incorrectly.  If a hunk inserts at the beginning, old position
recorded at the hunk is line 0, and if a hunk changes at the beginning, it
is line 1.  The new test added to t4104 exposes that the old code did not
insist on matching at the beginning for a patch to add a line to an empty
file.

An even older 65aadb9 (apply: force matching at the beginning.,
2006-05-24) was equally wrong in that it tried to take hints from the
number of leading context lines, to decide if the hunk must match at the
beginning, but we can just look at the line number in the hunk to decide.

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

GIT 1.5.4.5

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

Update draft release notes for 1.5.4.5

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

Merge branch 'jc/maint-fetch-regression-1.5.4' into maint

* jc/maint-fetch-regression-1.5.4:
  git-fetch test: test tracking fetch results, not just FETCH_HEAD
  Fix branches file configuration
  Tighten refspec processing

Documentation: clarify use of .git{ignore,attributes} versus .git/info/*

gitignore patterns can be read from three different
files, while gitattributes can come from two files. Let's
provide some hints to the user about the differences and how
they are typically used.

Suggested by Toby Corkindale, but gratuitously reworded by Jeff King.

Signed-off-by: Toby Corkindale <toby.corkindale@rea-group.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t/t3800-mktag.sh: use test_must_fail rather than '!'

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

git-fetch test: test tracking fetch results, not just FETCH_HEAD

We really should have done this long time ago.  Existing t5515 test
was written for the specific purpose of catching regression to the
contents of generated FETCH_HEAD file, but it also is a good place
to make sure various fetch configurations do fetch what they intend
to fetch (and nothing else).

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

Fix branches file configuration

Fetched remote branch from .git/branches/foo should fetch into
refs/heads/foo.  Also when partial URL is given, the fetched head should
always be remote HEAD, and the result should not be stored anywhere.

Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Tighten refspec processing

This changes the pattern matching code to not store the required final
/ before the *, and then to require each side to be a valid ref (or
empty). In particular, any refspec that looks like it should be a
pattern but doesn't quite meet the requirements will be found to be
invalid as a fallback non-pattern.

This was cherry picked from commit ef00d15 (Tighten refspec processing,
2008-03-17), and two fix-up commits 46220ca (remote.c: Fix overtight
refspec validation, 2008-03-20) and 7d19da4 (refspec: allow colon-less
wildcard "refs/category/*", 2008-03-25) squashed in.

Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix the wrong output of `git-show v1.3.0~155^2~4` in documentation.

Texts between ~ and ~ will be subscripted during the asciidoc translation.

Signed-off-by: Guanqun Lu <Guanqun.Lu@Gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
(cherry picked from commit 0c829391cfcdc57172765322575804a7ad5f3116)

Start draft ReleaseNotes for 1.5.4.5

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

rebase -m: do not trigger pre-commit verification

When rebasing changes that contain issues that the pre-commit hook flags
as problematic, the rebase cannot be continued.  However, rebase is about
transplanting commits that are already made with as little distortion as
possible, and pre-commit check should not interfere.

Earlier, c5b09fe (Avoid update hook during git-rebase --interactive,
2007-12-19) fixed "rebase -i", but "rebase -m" shared the same issue.

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

format-patch: generate MIME header as needed even when there is format.header

Earlier, the callchain from pretty_print_commit() down to pp_title_line()
had an unwarranted assumption that the presense of "after_subject"
parameter, means the caller has already output MIME headers for
attachments.  The parameter's primary purpose is to give extra header
lines the caller wants to place after pp_title_line() generates the
"Subject: " line.

This assumption does not hold when the user used the format.header
configuration variable to pass extra headers, and caused a message with
non-ASCII character to lack proper MIME headers (e.g.  8-bit CTE header).
The earlier logic also failed to suppress duplicated MIME headers when
"format-patch -s --attach" is asked for and the signer's name demanded
8-bit clean transport.

This patch fixes the logic by introducing a separate need_8bit_cte
parameter passed down the callchain.  This can have one of these values:

 -1 : we've already done MIME crap and we do not want to add extra header
      to say this is 8bit in pp_title_line();

  0 : we haven't done MIME and we have not seen anything that is 8bit yet;

  1 : we haven't done MIME and we have seen something that is 8bit;
      pp_title_line() must add MIME header.

It adds two tests by Jeff King who independently diagnosed this issue.

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

Make man page building quiet when DOCBOOK_XSL_172 is defined

Tell xmlto to repress printing of the lines:

Note: meta date   : No date. Using generated date       git-xyx
Note: Writing git-xyz.1

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

git-new-workdir: Share SVN meta data between work dirs and the repository

Multiple work dirs with git svn caused each work dir to have its own
stale copy of the SVN meta data in .git/svn

git svn rebase updates commits with git-svn-id: in the repository and
stores the SVN meta data information only in that work dir.  Attempting to
git svn rebase in other work dirs for the same branch would fail because
the last revision fetched according to the git-svn-id is greater than the
revision in the SVN meta data for that work directory.

Signed-off-by: Bernt Hansen <bernt@norang.ca>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rev-parse: fix meaning of rev~ vs rev~0.

I think it would make more sense for rev~ to have the same guarantees that
rev^ has, namely to always return a commit. I would also suggest that not
giving a number would have the same effect of defaulting to 1, not 0.

Right now it's a bit illogical, but at least it's an _undocumented_
illogical behaviour.

This patch makes '^' and '~' act the same for the default count (i.e. both
default to 1), and also have the same behaviour for a count of zero.

Before (no discernible pattern):

[torvalds@woody git]$ git rev-parse v1.5.1 v1.5.1^0 v1.5.1~0 v1.5.1^ v1.5.1~
45354a57ee7e3e42c7137db6c94fa968c6babe8d
89815cab95268e8f0f58142b848ac4cd5e9cbdcb
45354a57ee7e3e42c7137db6c94fa968c6babe8d
045f5759c97746589a067461e50fad16f60711ac
45354a57ee7e3e42c7137db6c94fa968c6babe8d

After (fairly logical):

[torvalds@woody git]$ git rev-parse v1.5.1 v1.5.1^0 v1.5.1~0 v1.5.1^ v1.5.1~
45354a57ee7e3e42c7137db6c94fa968c6babe8d
89815cab95268e8f0f58142b848ac4cd5e9cbdcb
89815cab95268e8f0f58142b848ac4cd5e9cbdcb
045f5759c97746589a067461e50fad16f60711ac
045f5759c97746589a067461e50fad16f60711ac

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

git-svn: don't blindly append '*' to branch/tags config

Previously, git-svn would blindly append '*' even if it was specified by
the user during initialization (for certain SVN setups, it is
necessary).

Now, the following command will work correctly:

  git svn init -T trunk/docutils \
               -t 'tags/*/docutils' \
               -b 'branches/*/docutils' \
               svn://svn.berlios.de/docutils

Thanks to martin f krafft for the bug report:
> My git-svn target configuration is
>
>   [svn-remote "svn"]
>     url = svn://svn.berlios.de/docutils
>     fetch = trunk/docutils:refs/remotes/trunk
>     branches = branches/*/docutils:refs/remotes/*
>     tags = tags/*/docutils:refs/remotes/tags/*
>
> Unfortunately, when I run
>
>   git-svn init -T trunk/docutils -t 'tags/*/docutils'
>    -b 'branches/*/docutils'
>
> then I get (note the two asterisks on the left hand side):
>
>     branches = branches/*/docutils/*:refs/remotes/*
>     tags = tags/*/docutils/*:refs/remotes/tags/*
>
> I took a brief stab at the code but I can't even figure out where
> the /* is appended, so I defer to you.
>
> It should be trivial to keep git-svn from appending /* if the left
> side already contains an asterisk.

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

Merge branch 'ph/maint-quiltimport' into maint

* ph/maint-quiltimport:
  quiltimport: fix misquoting of parsed -p<num> parameter
  git-quiltimport: better parser to grok "enhanced" series files.

merge-file: handle empty files gracefully

Earlier, it would error out while trying to read and/or writing them.
Now, calling merge-file with empty files is neither interesting nor
useful, but it is a bug that needed fixing.

Noticed by Clemens Buchacher.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

merge-recursive: handle file mode changes

File mode changes should be handled similarly to changes of content.
That is, if the file mode changed in only one branch, keep the changed
version, and if both branch changed to different mode, mark it as a
conflict.

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

Minor wording changes in the keyboard descriptions in git-add --interactive.

The wording of the interactive help text from git-add--interactive.perl is
clearer.  Just duplicate that text here.

Signed-off-by: Vineet Kumar <vineet@doorstop.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git fetch: Take '-n' to mean '--no-tags'

Prior to commit 8320199 (Rewrite builtin-fetch option parsing to use
parse_options().), we understood '-n' as a short option to mean "don't
fetch tags from the remote". This patch reinstates behaviour similar,
but not identical to the pre commit 8320199 times.

Back then, -n always overrode --tags, so if both --tags and -n was
given on command-line, no tags were fetched regardless of argument
ordering. Now we use a "last entry wins" strategy, so '-n --tags'
means "fetch tags".

Since it's patently absurd to say both --tags and --no-tags, this
shouldn't matter in practice.

Spotted-by: Artem Zolochevskiy <azol@altlinux.org>
Reported-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Tested-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

quiltimport: fix misquoting of parsed -p<num> parameter

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

git-cvsimport: fix merging with remote parent branch

commit-tree fails when specifying a remote name (via -r option) and
one of the parent branch has a name. Prefixing with "$remote/" fix it.

Signed-off-by: Marc-Andre Lureau <marcandre.lureau@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: Fix bug in href(..., -replay=>1) when using 'pathinfo' form

URLs generated by href(..., -replay=>1) (which includes 'next page'
links and alternate view links) didn't set project info correctly
when current page URL is in pathinfo form.

This resulted in broken links such like:

  http://www.example.com/w/ARRAY(0x85a5318)?a=shortlog;pg=1

if the 'pathinfo' feature was used, or

  http://www.example.com/w/?a=shortlog;pg=1

if it wasn't, instead of correct:

  http://www.example.com/w/project.git?a=shortlog;pg=1

This was caused by the fact that href() always replays params in the
arrayref form, were they multivalued or singlevalued, and the code
dealing with 'pathinfo' feature couldn't deal with $params{'project'}
being arrayref.

Setting $params{'project'} is moved before replaying params; this
ensures that 'project' parameter is processed correctly.

Noticed-by: Peter Oberndorfer <kumbayo84@arcor.de>
Noticed-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: fix find-rev error message when missing arg

Just let the user know that a revision argument is missing instead of
a perl error. This error message mimic the "init" error message, but
could be improved.

Signed-off-by: Marc-Andre Lureau <marcandre.lureau@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t0021: tr portability fix for Solaris

Solaris' /usr/bin/tr doesn't seem to like multiple character
ranges in brackets (it simply prints "Bad string").

Instead, let's just enumerate the transformation we want.

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

launch_editor(): allow spaces in the filename

The construct

sh -c "$0 \"$@\"" <editor> <file>

does not pick up quotes in <editor>, so you cannot give path to the
editor that has a shell IFS whitespace in it, and also give it initial
set of parameters and flags.  Replace $0 with <editor> to fix this issue.

This fixes

git config core.editor '"c:/Program Files/What/Ever.exe"'

In other words, you can specify an editor with spaces in its path using a
config containing something like this:

[core]
editor = \"c:/Program Files/Darn/Spaces.exe\"

NOTE: we cannot just replace the $0 with \"$0\", because we still want
this to work:

[core]
editor = emacs -nw

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

git rebase --abort: always restore the right commit

Previously, --abort would end by git resetting to ORIG_HEAD, but some
commands, such as git reset --hard (which happened in git rebase --skip,
but could just as well be typed by the user), would have already modified
ORIG_HEAD.

Just use the orig-head we store in $dotest instead.

[jc: cherry-picked from 48411d and 4947cf9 on 'master']

Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'kb/maint-filter-branch-disappear' into maint

* kb/maint-filter-branch-disappear:
  filter-branch: handle "disappearing tree" case correctly in subdir filter

Merge branch 'aw/maint-shortlog-blank-lines' into maint

* aw/maint-shortlog-blank-lines:
  shortlog: take the first populated line of the description

git-pull documentation: warn about the option order

We might eventually be loosening this rule, but there is a longstanding
restriction that the users currently need to be aware of.

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

git-quiltimport: better parser to grok "enhanced" series files.

The previous parser wasn't able to grok:

 * empty lines;
 * annotated patch levels (trailing -pNNN annotations);
 * trailing comments.

Now it understands them and uses the patch level hints as a git apply
argument.

Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

GIT 1.5.4.4

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

ident.c: reword error message when the user name cannot be determined

The "config --global" suggested in the message is a valid one-shot fix,
and hopefully one-shot across machines that NFS mounts the home directories.

This knowledge can hopefully be reused when you are forced to use git on
Windows, but the fix based on GECOS would not be applicable, so
it is not such a useful hint to mention the exact reason why the
name cannot be determined.

Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix dcommit, rebase when rewriteRoot is in use

When the rewriteRoot setting is used with git-svn, it causes the svn
IDs added to commit messages to bear a different URL than is actually
used to retrieve Subversion data.

It is common for Subversion repositories to be available multiple
ways: for instance, HTTP to the public, and svn+ssh to people with
commit access.  The need to switch URLs for access is fairly common as
well -- perhaps someone was just given commit access.  To switch URLs
without having to rewrite history, one can use the old url as a
rewriteRoot, and use the new one in the svn-remote url setting.

This works well for svn fetching and general git commands.

However, git-svn dcommit, rebase, and perhaps other commands do not
work in this scenario.  They scan the svn ID lines in commit messages
and attempt to match them up with url lines in [svn-remote] sections
in the git config.

This patch allows them to match rewriteRoot options, if such options
are present.

Signed-off-by: John Goerzen <jgoerzen@complete.org>
Acked-by: Eric Wong <normalperson@yhbt.net>

filter-branch: handle "disappearing tree" case correctly in subdir filter

The subdirectory filter had a bug to notice that the commit in question
did not have anything in the path-limited part of the tree.  $commit:$path
does not name an empty tree when $path does not appear in $commit.

This should fix it.  The additional test in t7003 is originally from Kevin
Ballard but with fixups.

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

Really make the LF after reset in fast-import optional

cmd_from() ends with a call to read_next_command(), which is needed
when using cmd_from() from commands where from is not the last element.

With reset, however, "from" is the last command, after which the flow
returns to the main loop, which calls read_next_command() again.

Because of this, always set unread_command_buf in cmd_reset_branch(),
even if cmd_from() was successful.

Add a test case for this in t9300-fast-import.sh.

Signed-off-by: Adeodato Simó <dato@net.com.org.es>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'mh/maint-http-proxy-fix' into maint

* mh/maint-http-proxy-fix:
  Set proxy override with http_init()

Merge branch 'js/maint-daemon' into maint

* js/maint-daemon:
  daemon: ensure that base-path is an existing directory
  daemon: send more error messages to the syslog

Merge branch 'js/maint-cvsexport' into maint

* js/maint-cvsexport:
  cvsexportcommit: be graceful when "cvs status" reorders the arguments

Conflicts:

t/t9200-git-cvsexportcommit.sh

Merge branch 'jc/maint-log-merge-left-right' into maint

* jc/maint-log-merge-left-right:
  Fix "git log --merge --left-right"

Merge branch 'ew/maint-svn-cert-fileprovider' into maint

* ew/maint-svn-cert-fileprovider:
  git-svn: Don't prompt for client cert password everytime.

unquote_c_style: fix off-by-one.

The optional endp parameter to unquote_c_style() was supposed to point at
a location past the closing double quote, but it was going one beyond it.

git-fast-import used this function heavily and the bug caused it to
misparse the input stream, especially when parsing a rename command:

R "filename that needs quoting" rename-target-name

Because the function erroneously ate the whitespace after the closing dq,
this triggered "Missing space after source" error when it shouldn't.

Thanks to Adeodato Simò for having caught this.

Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

test-lib: fix TERM to dumb for test repeatability

Dscho noticed that Term::ReadLine (used by send-email) colorized its
output for his TERM settings, inside t9001 tests.

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

config.txt: refer to --upload-pack and --receive-pack instead of --exec

The options --upload-pack (of git-fetch-pack) and --receive-pack (of
git-push) do the same as --exec (for both commands).  But the former options
have the more descriptive name.

Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

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

* 'maint' of git://repo.or.cz/git-gui:
  git-gui: Gracefully fall back to po2msg.sh if msgfmt --tcl fails

shortlog: take the first populated line of the description

Way back the perl version of shortlog would take the first populated line
of the commit body.  The builtin version mearly takes the first line.
This leads to empty shortlog entries when there is some viable text in
the commit.

Reinstate this behaviour igoring all lines with nothing but whitespace.
This is often useful when dealing with commits imported from foreign SCMs
that do not tidy up the log message of useless blank lines at the beginning.

Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-gui: Gracefully fall back to po2msg.sh if msgfmt --tcl fails

Mac OS X Tiger may have a msgfmt available but it doesn't understand
how to implement --tcl.  Falling back to po2msg.sh on such systems
is a reasonable behavior.

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

Fix 'git remote show' regression on empty repository in 1.5.4

Back in 18f7c51c we switched git-ls-remote/git-peek-remote to
use the transport backend, rather than do everything itself.

As part of that switch we started to produce a non-zero exit
status if no refs were received from the remote peer, which
happens when the remote peer has no commits pushed to it yet.
(E.g. "git --git-dir=foo.git init; git ls-remote foo.git")

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

Fix incorrect wording in git-merge.txt.

A merge is not necessarily with a remote branch, it can be with any
commit.

Thanks to Paolo Ciarrocchi for pointing out the problem, and to
Nicolas Pitre for pointing out the fact that a merge is not
necessarily with a branch head.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-merge.sh: better handling of combined --squash,--no-ff,--no-commit options

git-merge used to use either the --squash,--no-squash, --no-ff,--ff,
--no-commit,--commit option, whichever came last in the command line.
This lead to some un-intuitive behavior, having

 git merge --no-commit --no-ff <branch>

actually commit the merge.  Now git-merge respects --no-commit together
with --no-ff, as well as other combinations of the options.  However,
this broke a selftest in t/t7600-merge.sh which expected to have --no-ff
completely override the --squash option, so that

 git merge --squash --no-ff <branch>

fast-forwards, and makes a merge commit; combining --squash with --no-ff
doesn't really make sense though, and is now refused by git-merge.  The
test is adapted to test --no-ff without the preceding --squash, and
another test is added to make sure the --squash --no-ff combination is
refused.

The unexpected behavior was reported by John Goerzen through
 http://bing.sdebian.org/468568

Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix random crashes in http_cleanup()

For some reason, http_cleanup was running all active slots, which could
lead in situations where a freed slot would be accessed in
fill_active_slots. OTOH, we are cleaning up, which means the caller
doesn't care about pending requests. Just forget about them instead
or running them.

Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>