tokkee.org

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>

Update draft release notes for 1.5.4.4

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

revert: actually check for a dirty index

The previous code mistakenly used wt_status_prepare to check whether the
index had anything commitable in it; however, that function is just an
init function, and will never report a dirty index.

The correct way with wt_status_* would be to call wt_status_print with the
output pointing to /dev/null or similar. However, that does extra work by
both examining the working tree and spewing status information to nowhere.

Instead, let's just implement the useful subset of wt_status_print as an
"is_index_dirty" function.

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

tests: introduce test_must_fail

When we expect a git command to notice and signal errors, we
carelessly wrote in our tests:

    test_expect_success 'reject bogus request' '
        do something &&
        do something else &&
        ! git command
    '

but a non-zero exit could come from the "git command" segfaulting.

A new helper function "tset_must_fail" is introduced and it is
meant to be used to make sure the command gracefully fails (iow,
dying and exiting with non zero status is counted as a failure
to "gracefully fail").  The above example should be written as:

    test_expect_success 'reject bogus request' '
        do something &&
        do something else &&
        test_must_fail git command
    '

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

git-submodule: Fix typo 'url' which should be '$url'

Fix typo in 'test -z "url"' when checking whether a submodule url is
empty. "url" should be "$url".

Signed-off-by: Ping Yin <pkufranky@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

receive-pack: Initialize PATH to include exec-dir.

511707d (use only the $PATH for exec'ing git commands) made it a
requirement to call setup_path() to include the git exec-dir in PATH
before spawning any other git commands. git-receive-pack was not yet
adapted to do this and therefore fails to spawn git-unpack-objects if that
is not in the standard PATH.

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

Documentation cherry-pick: Fix cut-and-paste error

Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git.el: find the git-status buffer whatever its name is

git-status used the buffer name to find git-status buffers, and that
can fail if the buffer has another name, for example when multiple
working directories is tracked.

Signed-off-by: Rémi Vanicat <vanicat@debian.org>
Acked-by: Alexandre Julliard <julliard@winehq.org>
Tested-by: Xavier Maillard <xma@gnu.org>
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: Paper bag fix info dialog when no files are staged at commit

templates/Makefile: don't depend on local umask setting

Don't take the local umask setting into account when installing the
templates/* files and directories, running 'make install' with umask set
to 077 resulted in template/* installed with permissions 700 and 600.

The problem was discovered by Florian Zumbiehl, reported through
 http://bugs.debian.org/467518

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

Correct name of diff_flush() in API documentation

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

Start preparing for 1.5.4.4

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

git-gui: Paper bag fix info dialog when no files are staged at commit

If the user tries to commit their changes without actually staging
anything we used to display an informational dialog suggesting they
first stage those changes, then retry the commit feature.

Unfortunately I broke this in aba15f7 ("Ensure error dialogs always
appear over all other windows") and failed to fix it in the paper
bag fix that came one day after it.

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

Fix "git log --merge --left-right"

The command did not reject the combination of these options, but
did not show left/right markers.

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

Set proxy override with http_init()

In transport.c, proxy setting (the one from the remote conf) was set through
curl_easy_setopt() call, while http.c already does the same with the
http.proxy setting. We now just use this infrastructure instead, and make
http_init() now take the struct remote as argument so that it can take the
http_proxy setting from there, and any other property that would be added
later.

At the same time, we make get_http_walker() take a struct remote argument
too, and pass it to http_init(), which makes remote defined proxy be used
for more than get_refs_via_curl().

We leave out http-fetch and http-push, which don't use remotes for the
moment, purposefully.

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

daemon: ensure that base-path is an existing directory

Any request to the daemon would fail if base-path (if specified) is not
a directory. We now check for this condition early.

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

daemon: send more error messages to the syslog

There were a number of die() calls before the syslog was opened; hence,
these error messages would have been sent to /dev/null in detached mode.
Now we install the daemon-specific die routine before any error message is
generated so that these messages go to the syslog.

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

Eliminate confusing "won't bisect on seeked tree" failure

This error message is very confusing---it doesn't tell the user
anything about how to fix the situation. And the actual fix
for the situation ("git bisect reset") does a checkout of a
potentially random branch, (compared to what the user wants to
be on for the bisect she is starting).

The simplest way to eliminate the confusion is to just make
"git bisect start" do the cleanup itself. There's no significant
loss of safety here since we already have a general safety in
the form of the reflog.

Note: We preserve the warning for any cogito users. We do this
by switching from .git/head-name to .git/BISECT_START for the
extra state, (which is a more descriptive name anyway).

Signed-off-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin-reflog.c: don't install new reflog on write failure

When expiring reflog entries, a new temporary log is written which contains
only the entries to retain. After it is written, it is renamed to replace
the existing reflog. Currently, we check that writing of the new log is
successful and print a message on failure, but the original reflog is still
replaced with the new reflog even on failure. This patch causes the
original reflog to be retained if we fail when writing the new reflog.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

send-email: fix In-Reply-To regression

Fix a regression introduced by

1ca3d6e (send-email: squelch warning due to comparing undefined $_ to "")

where if the user was prompted for an initial In-Reply-To and didn't
provide one, messages would be sent out with an invalid In-Reply-To of
"<>"

Also add test cases for the regression and the fix. A small modification
was needed to allow send-email to take its replies from stdin if the
environment variable GIT_SEND_EMAIL_NOTTY is set.

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: Don't prompt for client cert password everytime.

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

Fix 'git cvsexportcommit -w $cvsdir ...' when used with relative $GIT_DIR

When using the '-w $cvsdir' option to cvsexportcommit, it will chdir into
$cvsdir before executing several other git commands. If $GIT_DIR is set to
a relative path (e.g. '.'), the git commands executed by cvsexportcommit
will naturally fail.

Therefore, ensure that $GIT_DIR is absolute before the chdir to $cvsdir.

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

Add testcase for 'git cvsexportcommit -w $cvsdir ...' with relative $GIT_DIR

The testcase verifies that 'git cvsexportcommit' functions correctly when
the '-w' option is used, and GIT_DIR is set to a relative path (e.g. '.').

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

Prompt to continue when editing during rebase --interactive

On hitting an edit point in an interactive rebase, git should prompt
the user to run "git rebase --continue"

Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation/git svn log: add a note about timezones.

git svn log mimics the timezone converting behaviour of svn log, but
this was undocumented.

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

Merge branch 'js/maint-http-push' into maint

* js/maint-http-push:
  http-push: avoid a needless goto
  http-push: do not get confused by submodules
  http-push: avoid invalid memory accesses

Don't use GIT_CONFIG in t5505-remote

For some reason, t5505-remote was setting GIT_CONFIG to .git/config
and exporting it. This should have been no-op, as test framework did
the same for a long time anyway.

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

Documentation/git-am.txt: Pass -r in the example invocation of rm -f .dotest

Signed-off-by: Bryan Donlan <bdonlan@fushizen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

timezone_names[]: fixed the tz offset for New Zealand.

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

filter-branch documentation: non-zero exit status in command abort the filter

Since commit 8c1ce0f46b85d40f215084eed7313896300082df filter-branch fails
when a <command> has a non-zero exit status. This commit makes it clear
in the documentation and also fixes the parent-filter example, that was
incorrectly returning non-zero when the commit being tested wasn't the
one to be rewritten.

Signed-off-by: Caio Marcelo de Oliveira Filho <cmarcelo@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rev-parse: fix potential bus error with --parseopt option spec handling

A non-empty line containing no spaces should be treated by --parseopt as
an option group header, but was causing a bus error. Also added a test
script for rev-parse --parseopt.

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Use a single implementation and API for copy_file()

Originally by Kristian Hï¿œgsberg; I fixed the conversion of rerere, which
had a different API.

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

Documentation/git-filter-branch: add a new msg-filter example

There were no example on how to edit commit messages, so add an msg-filter
example.

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

Correct fast-export file mode strings to match fast-import standard

The fast-import file format does not expect leading '0' in front
of a file mode; that is we want '100644' and '0100644'.

Thanks to Ian Clatworthy of the Bazaar project for noticing the
difference in output/input.

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

Protect peel_ref fallback case from NULL parse_object result

If the SHA-1 we are requesting the object for does not exist in
the object database we get a NULL back.  Accessing the type from
that is not likely to succeed on any system.

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

Ensure 'make dist' compiles git-archive.exe on Cygwin

On Cygwin we have to use git-archive.exe as the target, otherwise
running 'make dist' does not compile git-archive in the current
directory.  That may cause 'make dist' to fail on a clean source
tree that has never been built before.

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

GIT 1.5.4.3

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: Focus insertion point at end of strings in repository chooser
  git-gui: Avoid hardcoded Windows paths in Cygwin package files
  git-gui: Default TCL_PATH to same location as TCLTK_PATH
  git-gui: Paper bag fix error dialogs opening over the main window
  git-gui: Ensure error dialogs always appear over all other windows
  git-gui: relax "dirty" version detection
  git-gui: support Git Gui.app under OS X 10.5

hash: fix lookup_hash semantics

We were returning the _address of_ the stored item (or NULL)
instead of the item itself. While this sort of indirection
is useful for insertion (since you can lookup and then
modify), it is unnecessary for read-only lookup. Since the
hash code splits these functions between the internal
lookup_hash_entry function and the public lookup_hash
function, it makes sense for the latter to provide what
users of the library expect.

The result of this was that the index caching returned bogus
results on lookup. We unfortunately didn't catch this
because we were returning a "struct cache_entry **" as a
"void *", and accidentally assigning it to a "struct
cache_entry *".

As it happens, this actually _worked_ most of the time,
because the entries were defined as:

  struct cache_entry {
  struct cache_entry *next;
  ...
  };

meaning that interpreting a "struct cache_entry **" as a
"struct cache_entry *" would yield an entry where all fields
were totally bogus _except_ for the next pointer, which
pointed to the actual cache entry. When walking the list, we
would look at the bogus "name" field, which was unlikely to
match our lookup, and then proceed to the "real" entry.

The reading of bogus data was silently ignored most of the
time, but could cause a segfault for some data (which seems
to be more common on OS X).

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

git-gui: Focus insertion point at end of strings in repository chooser

When selecting a local working directory for a new repository or a
location to clone an existing repository into we now set the insert
point at the end of the selected path, allowing the user to type in
any additional parts of the path if they so desire.

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

git-gui: Avoid hardcoded Windows paths in Cygwin package files

When we are being built by the Cygwin package maintainers we need to
embed the POSIX path to our library files and not the Windows path.
Embedding the Windows path means all end-users who install our Cygwin
package would be required to install Cygwin at the same Windows path
as the package maintainer had Cygwin installed to.  This requirement
is simply not user-friendly and may be infeasible for a large number
of our users.

We now try to auto-detect if the Tcl/Tk binary we will use at runtime
is capable of translating POSIX paths into Windows paths the same way
that cygpath does the translations.  If the Tcl/Tk binary gives us the
same results then it understands the Cygwin path translation process
and should be able to read our library files from a POSIX path name.

If it does not give us the same answer as cygpath then the Tcl/Tk
binary might actually be a native Win32 build (one that is not
linked against Cygwin) and thus requires the native Windows path
to our library files.  We can assume this is not a Cygwin package
as the Cygwin maintainers do not currently ship a pure Win32 build
of Tcl/Tk.

Reported on the git mailing list by Jurko Gospodnetić.

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

git-gui: Default TCL_PATH to same location as TCLTK_PATH

Most users set TCLTK_PATH to tell git-gui where to find wish, but they
fail to set TCL_PATH to the same Tcl installation.  We use the non-GUI
tclsh during builds so headless systems are still able to create an
index file and create message files without GNU msgfmt.  So it matters
to us that we find a working TCL_PATH at build time.

If TCL_PATH hasn't been set yet we can take a better guess about what
tclsh executable to use by replacing 'wish' in the executable path with
'tclsh'.  We only do this replacement on the filename part of the path,
just in case the string "wish" appears in the directory paths.  Most of
the time the tclsh will be installed alongside wish so this replacement
is a sensible and safe default.

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

git-gui: Paper bag fix error dialogs opening over the main window

If the main window is the only toplevel we have open then we
don't have a valid grab right now, so we need to assume the
best toplevel to use for the parent is ".".

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

git-gui: Ensure error dialogs always appear over all other windows

If we are opening an error dialog we want it to appear above all of
the other windows, even those that we may have opened with a grab
to make the window modal.  Failure to do so may allow an error
dialog to open up (and grab focus!) under an existing toplevel,
making the user think git-gui has frozen up and is unresponsive,
as they cannot get to the dialog.

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

Clarified the meaning of git-add -u in the documentation

The git-add documentation did not state clearly that the -u switch
updates only the tracked files that are in the current directory and
its subdirectories.

Signed-off-by: Pekka Kaitaniemi <kaitanie@cc.helsinki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-clone.sh: properly configure remote even if remote's head is dangling

When cloning a remote repository which's HEAD refers to a nonexistent
ref, git-clone cloned all existing refs, but failed to write the
configuration for 'remote'.  Now it detects the dangling remote HEAD,
refuses to checkout any local branch since HEAD refers to nowhere, but
properly writes the configuration for 'remote', so that subsequent
'git fetch's don't fail.

The problem was reported by Daniel Jacobowitz through
 http://bugs.debian.org/466581

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

Documentation/git-stash: document options for git stash list

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

send-email: squelch warning due to comparing undefined $_ to ""

The check to see if initial_reply_to is defined was also comparing $_ to
"" for a reason I cannot ascertain (looking at the commit which made the
change didn't provide enlightenment), but if $_ is undefined, perl
generates a warning.

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

cvsexportcommit: be graceful when "cvs status" reorders the arguments

In my use cases, "cvs status" sometimes reordered the passed filenames,
which often led to a misdetection of a dirty state (when it was in
reality a clean state).

I finally tracked it down to two filenames having the same basename.

So no longer trust the order of the results blindly, but actually check
the file name.

Since "cvs status" only returns the basename (and the complete path on the
server which is useless for our purposes), run "cvs status" several times
with lists consisting of files with unique (chomped) basenames.

Be a bit clever about new files: these are reported as "no file <blabla>",
so in order to discern it from existing files, prepend "no file " to the
basename.

In other words, one call to "cvs status" will not ask for two files
"blabla" (which does not yet exist) and "no file blabla" (which exists).

This patch makes cvsexportcommit slightly slower, when the list of changed
files has non-unique basenames, but at least it is accurate now.

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

Rename git-core rpm to just git and rename the meta-pacakge to git-all.

This fixes my favorite annoyance with the git rpm packaging: don't pull
in tla when I say yum install git!  You wouldn't expect yum install gcc
to pull in gcc-gfortran, right?

With this change, and blanket 'yum update' will automatically pull in the
new 'git' package and push out the old 'git-core', and if the old 'git'
package was installed 'git-all' will be pulled in instead.  A couple of
things do break though: 'yum update git-core', because yum behaves
differently when given a specific package name - it doesn't follow obsoletes.

Instead, 'yum install git' will pull in the new git rpm, which will then
push out the old 'git-core'.  Similarly, to get the newest version of
the meta package, 'yum install git-all' will install git-all, which then
pushes out the old 'git' meta package.

Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

push: document the status output

The output was meant to be a balance of self-explanatory and
terse. In case we have erred too far on the terse side, it
doesn't hurt to explain in more detail what each line means.

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

Documentation/push: clarify matching refspec behavior

The previous text was correct, but it was easy to miss the
fact that we are talking about "matching" refs. That is, the
text can be parsed as "we push the union of the sets
of remote and local heads" and not "we push the intersection
of the sets of remote and local heads". (The former actually
doesn't make sense if you think about it, since we don't
even _have_ some of those heads). A careful reading would
reveal the correct meaning, but it makes sense to be as
explicit as possible in documentation.

We also explicitly use and introduce the term "matching";
this is a term discussed on the list, and it seems useful
to for users to be able to refer to this behavior by name.

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

push: indicate partialness of error message

The existing message indicates that an error occured during
push, but it is unclear whether _any_ refs were actually
pushed (even though the status table above shows which were
pushed successfully and which were not, the message "failed
to push" implies a total failure). By indicating that "some
refs" failed, we hopefully indicate to the user that the
table above contains the details.

We could also put in an explicit "see above for details"
message, but it seemed to clutter the output quite a bit
(both on a line of its own, or at the end of the error line,
which inevitably wraps).

This could also be made more fancy if the transport
mechanism passed back more details on how many refs
succeeded and failed:

  error: failed to push %d out of %d refs to '%s'

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

git-gui: relax "dirty" version detection

"git gui" would complain at launch if the local version of Git was
"1.5.4.2.dirty". Loosen the regular expression to look for either
"-dirty" or ".dirty", thus eliminating spurious warnings.

Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

GIT 1.5.4.2

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

Documentation/git-reset: Add an example of resetting selected paths

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

Documentation/git-reset: don't mention --mixed for selected-paths reset

The option is accepted, but that is the only form selected-paths
variant of the reset command takes, so there is no point mentioning it.
And while we're at it, use the dashless git call.

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

Documentation/git-reset:

Since 3368d11 (Remove unnecessary git-rm --cached reference from
status output), the status output marks the "Added but not yet
committed" section as "Changes to be committed".

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

commit: discard index after setting up partial commit

There may still be some entries from the original index that
should be discarded before we show the status. In
particular, if a file was added in the index but not
included in the partial commit, it would still show up in
the status listing as staged for commit.

Ultimately the correct fix is to keep the two states in
separate index_state variables. Then we can avoid having
to reload the cache from the temporary file altogether, and
just point wt_status_print at the correct index.

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

filter-branch: handle filenames that need quoting

The command used a very old fashioned construct to extract
filenames out of diff-index and ended up corrupting the output.
We can simply use --name-only and pipe into --stdin mode of
update-index.  It's been like that for the past 2 years or so
since a94d994 (update-index: work with c-quoted name).

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

http-push: avoid a needless goto

There was a goto, and while it is not half as harmful as some people
believe, it was unnecessary here.  So remove it for readability.

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

http-push: do not get confused by submodules

When encountering submodules in a tree, http-push should not try sending
the respective object.  Instead, it should ignore it.

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

http-push: avoid invalid memory accesses

Before objects are sent, the respective ref is locked.  However,
without this patch, the lock is lifted before the last object for
that ref was sent.  As a consequence, the lock data was accessed
after the lock structure was free()d.

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

diff: Fix miscounting of --check output

c1795bb (Unify whitespace checking) incorrectly made the
checking function return without incrementing the line numbers
when there is no whitespace problem is found on a '+' line.

This resurrects the earlier behaviour.

Noticed and reported by Jay Soffian.  The test script was stolen
from Jay's independent fix.

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