git-gui: fix git-gui crash due to uninitialized variable

Recently, a clone initiated via git gui on Windows crashed on me due to
an "unknown variable cdone". It turns out that there is a code path
where this variable is used uninitialized.

Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
git-gui: Use PWD if it exists on Mac OS X

The current working directory is set to / when git-gui is invoked
using the Git Gui.app bundle on Mac OS X. This means that if it is
launched from a directory which contains a repository then git-gui
won't automatically find it unless the repository happens to be
located in /.

The PWD environment variable is however preserved if the bundle is
invoked using open(1). If git-gui would check for PWD then a user
could for example type open -a 'Git Gui' on a command line in order to
launch the program and it would automatically find the repository.

Teach git-gui to use the PWD environment variable on Mac OS X.

Signed-off-by: Marcus Karlsson <mk@acc.umu.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
git-gui: fix a typo in po/ files

"succeeded" was misspelled in the code, which propagated throughout the
 translations.

Fixed all of them.

Signed-off-by: Benjamin Kerensa <bkerensa <at> ubuntu.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
git-gui: open console when using --trace on windows

When starting a gui program on windows stdout, stderr and stdin are not
connected to the cmd console. As a workaround tk has a console window.
Lets open this when the --trace commandline option has been given.
This is helpful for debugging.

Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
git-gui: preserve commit messages in utf-8

The commit message buffer is automatically preserved to a local file
but this uses the system encoding which may fail to properly encode
unicode text. Forcing this file to use utf-8 preserves the message
correctly.

Reported-by: Ángel José Riesgo <ajriesgo@gmail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
git-gui: de.po: consistently add untranslated hook names within braces

The user might not really know what hook is
actually meant if it's translated. To avoid such
a confusion we should consistently write it untranslated
within braces after.

Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
git-gui: de.po: translate "bare" as "bloß"

According to the translation in git-core, we
translate "bare" as "bloß".

Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
git-gui: de.po: translate "remote" as "extern"

According to the translation in git-core, we
translate "remote" as "extern".

Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Merge branch 'rt/trans'
git-gui: Fix semi-working shortcuts for unstage and revert

Make Ctrl+U for unstaging and Ctrl+J for reverting selection behave
more like Ctrl+T for adding.

They were working only when one area was focused (diff or commit message),
now they should work everywhere.

Acked-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Vitaly _Vi Shukela <vi0oss@gmail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
git-gui: Fix a loose/lose mistake

Acked-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Beat Bolli <bbolli@ewanet.ch>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
git-gui: remove .git/CHERRY_PICK_HEAD after committing

Adding _git_ps1() to one's bash prompt displays various repo status
info after each command. After committing a git cherry-pick -n using
git-gui, the prompt still contains the "|CHERRY-PICKING" flag.

Delete the file causing this flag when cleaning up.

Signed-off-by: Beat Bolli <bbolli@ewanet.ch>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
clone --single: limit the fetch refspec to fetched branch

After running "git clone --single", the resulting repository has the
usual default "+refs/heads/*:refs/remotes/origin/*" wildcard fetch
refspec installed, which means that a subsequent "git fetch" will
end up grabbing all the other branches.

Update the fetch refspec to cover only the singly cloned ref instead
to correct this.

That means:
If "--single" is used without "--branch" or "--mirror", the
fetch refspec covers the branch on which remote's HEAD points to.
If "--single" is used with "--branch", it'll cover only the branch
specified in the "--branch" option.
If "--single" is combined with "--mirror", then it'll cover all
refs of the cloned repository.
If "--single" is used with "--branch" that specifies a tag, then
it'll cover only the ref for this tag.

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
receive-pack: redirect unpack-objects stdout to /dev/null

The unpack-objects command should not generally produce any
output on stdout. However, if it's given extra input after
the packfile, it will spew the remainder to stdout. When
called by receive-pack, this means we will break protocol,
since our stdout is connected to the remote send-pack.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
receive-pack: send pack-processing stderr over sideband

Receive-pack invokes either unpack-objects or index-pack to
handle the incoming pack. However, we do not redirect the
stderr of the sub-processes at all, so it is never seen by
the client. From the initial thread adding sideband support,
which is here:

  http://thread.gmane.org/gmane.comp.version-control.git/139471

it is clear that some messages are specifically kept off the
sideband (with the assumption that they are of interest only
to an administrator, not the client). The stderr of the
subprocesses is mentioned in the thread, but it's unclear if
they are included in that group, or were simply forgotten.

However, there are a few good reasons to show them to the
client:

  1. In many cases, they are directly about the incoming
     packfile (e.g., fsck warnings with --strict, corruption
     in the packfile, etc). Without these messages, the
     client just gets "unpacker error" with no extra useful
     diagnosis.

  2. No matter what the cause, we are probably better off
     showing the errors to the client. If the client and the
     server admin are not the same entity, it is probably
     much easier for the client to cut-and-paste the errors
     they see than for the admin to try to dig them out of a
     log and correlate them with a particular session.

  3. Users of the ssh transport typically already see these
     stderr messages, as the remote's stderr is copied
     literally by ssh. This brings other transports (http,
     and push-over-git if you are crazy enough to enable it)
     more in line with ssh. As a bonus for ssh users,
     because the messages are now fed through the sideband
     and printed by the local git, they will have "remote:"
     prepended and be properly interleaved with any local
     output to stderr.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
receive-pack: drop "n/a" on unpacker errors

The output from git push currently looks like this:

  $ git push dest HEAD
  fatal: [some message from index-pack]
  error: unpack failed: index-pack abnormal exit
  To dest
   ! [remote rejected] HEAD -> master (n/a (unpacker error))

That n/a is meant to be "the per-ref status is not
available" but the nested parentheses just make it look
ugly. Let's turn the final line into just:

   ! [remote rejected] HEAD -> master (unpacker error)

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git blame: document that it always follows origin across whole-file renames

Make it clear to people who (rightly or wrongly) think that the
"--follow" option should follow origin across while-file renames
that we already do so.  That would explain the output that they see
when they do give the "--follow" option to the command.

We may or may not want to do a "--no-follow" patch as a follow-up,
but that is a separate topic.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit: pay attention to submodule.$name.ignore in .gitmodules

"git status" does not list a submodule with uncommitted working tree
files as modified when "submodule.$name.ignore" is set to "dirty" in
in-tree ".gitmodules" file.  Both status and commit honor the setting
in $GIT_DIR/config, but "commit" does not pick it up from .gitmodules,
which is inconsistent.

Teach "git commit" to pay attention to the setting in .gitmodules as
well.

Signed-off-by: Orgad Shaneh <orgads@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
mergetool--lib: Allow custom commands to override built-ins

Allow users to override the default commands provided by the
mergetools/* scriptlets.

Users occasionally run into problems where they expect to be
able to override the built-in tool names.  The documentation
does not explicitly mention that built-ins cannot be overridden,
so it's easy to assume that it should work.

Lift this restriction so that built-in tools are handled the
same way as user-configured tools.  Add tests to guarantee this
behavior.

A nice benefit of this change is that it protects users from
having future versions of git trump their custom configuration
with a new built-in tool.

C.f.:

http://stackoverflow.com/questions/7435002/mergetool-from-gitconfig-being-ignored
http://thread.gmane.org/gmane.comp.version-control.msysgit/13188
http://thread.gmane.org/gmane.comp.version-control.git/148267

Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
MALLOC_CHECK: enable it, unless disabled explicitly

The malloc checks in tests are currently disabled.  Actually evaluate
the variable for turning them off and enable them if it's unset.

Also use this opportunity to give it the more descriptive and
consistent name TEST_NO_MALLOC_CHECK.

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