submodule: Make 'checkout' update_module explicit

This avoids the current awkwardness of having either '' or 'checkout'
for checkout-mode updates, which makes testing for checkout-mode
updates (or non-checkout-mode updates) easier.

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
submodule: Document module_clone arguments in comments

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitk: Fix mistype

Signed-off-by: Max Kirillov <max@max630.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Add Bulgarian translation (304t)

Signed-off-by: Alexander Shopov <ash@kambanaria.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Update copyright dates

Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: chmod +x po2msg.sh

The Makefile only runs it using tclsh, but because the fallback po2msg
script has the usual tcl preamble starting with #!/bin/sh it can also
be run directly.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Replace "next" and "prev" buttons with down and up arrows

Users often find that "next" and "prev" do the opposite of what they
expect.  For example, "next" moves to the next match down the list, but
that is almost always backwards in time.  Replacing the text with arrows
makes it clear where the buttons will take the user.

Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Comply with XDG base directory specification

Write the gitk config data to $XDG_CONFIG_HOME/git/gitk ($HOME/.config/git/gitk
by default) in line with the XDG specification. This makes it consistent with
git which also follows the spec.

If $HOME/.gitk already exists use that for backward compatibility, so only new
installations are affected.

Signed-off-by: Astril Hayato <astrilhayato@gmail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
git-svn: memoize _rev_list and rebuild

According to profile data, _rev_list and rebuild consume a large
portion of time.  Memoize the results of _rev_list and memoize
rebuild internals to avoid subprocess invocation.

When importing 15152 revisions on a LAN, time improved from 10
hours to 3-4 hours.

Signed-off-by: lin zuojian <manjian2006@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
gitk: Indent word-wrapped lines in commit display header

In the cases where the lines starting with Precedes:, Follows: and
Branches: in the commit display are long enough to be word-wrapped,
this adds a 1cm margin on the left of the wrapped lines, to make
the display more readable.  Suggested by Stephen Rothwell.

Signed-off-by: Paul Mackerras <paulus@samba.org>
Merge git://ozlabs.org/~paulus/gitk

* 'master' of git://ozlabs.org/~paulus/gitk:
  gitk: Indent word-wrapped lines in commit display header
  gitk: Comply with XDG base directory specification
  gitk: Replace "next" and "prev" buttons with down and up arrows
  gitk: chmod +x po2msg.sh
  gitk: Update copyright dates
  gitk: Add Bulgarian translation (304t)
  gitk: Fix mistype
Merge git://git.bogomips.org/git-svn

* 'master' of git://git.bogomips.org/git-svn:
  git-svn: memoize _rev_list and rebuild
Makefile: Fix compilation of Windows resource file

If the git version number consists of less than three period
separated numbers, then the Windows resource file compilation
issues a syntax error:

  $ touch git.rc
  $ make V=1 git.res
  GIT_VERSION = 1.9.rc0
  windres -O coff \
            -DMAJOR=1 -DMINOR=9 -DPATCH=rc0 \
            -DGIT_VERSION="\\\"1.9.rc0\\\"" git.rc -o git.res
  C:\msysgit\msysgit\mingw\bin\windres.exe: git.rc:2: syntax error
  make: *** [git.res] Error 1
  $

Note that -DPATCH=rc0.

The values passed via -DMAJOR=, -DMINOR=, and -DPATCH= are used in
FILEVERSION and PRODUCTVERSION statements, which expect up to four numeric
values. These version numbers are intended for machine consumption. They
are typically inspected by installers to decide whether a file to be
installed is newer than one that exists on the system, but are not used
for much else.

We can be pretty certain that there are no tools that look at these
version numbers, not even the installer of Git for Windows does.
Therefore, to fix the syntax error, fill in only the first two numbers,
which we are guaranteed to find in Git version numbers.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Acked-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
repack: fix typo in max-pack-size option

When we see "--max-pack-size", we accidentally propagated
this to pack-objects as "--max_pack_size", which does not
work at all.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
repack: make parsed string options const-correct

When we use OPT_STRING to parse an option, we get back a
pointer into the argv array, which should be "const char *".
The compiler doesn't notice because it gets passed through a
"void *" in the option struct.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
repack: propagate pack-objects options as strings

In the original shell version of git-repack, any options
destined for pack-objects were left as strings, and passed
as a whole. Since the C rewrite in commit a1bbc6c (repack:
rewrite the shell script in C, 2013-09-15), we now parse
these values to integers internally, then reformat the
integers when passing the option to pack-objects.

This has the advantage that we catch format errors earlier
(i.e., when repack is invoked, rather than when pack-objects
is invoked).

It has three disadvantages, though:

  1. Our internal data types may not be the right size. In
     the case of "--window-memory" and "--max-pack-size",
     these are "unsigned long" in pack-objects, but we can
     only represent a regular "int".

  2. Our parsing routines might not be the same as those of
     pack-objects. For the two options above, pack-objects
     understands "100m" to mean "100 megabytes", but repack
     does not.

  3. We have to keep a sentinel value to know whether it is
     worth passing the option along. In the case of
     "--window-memory", we currently do not pass it if the
     value is "0". But that is a meaningful value to
     pack-objects, where it overrides any configured value.

We can fix all of these by simply passing the strings from
the user along to pack-objects verbatim. This does not
actually fix anything for "--depth" or "--window", but these
are converted, too, for consistency.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make 'git request-pull' more strict about matching

 local/remote branches

The current 'request-pull' will try to find matching commit on the given
remote, and rewrite the "please pull" line to match that remote ref.

That may be very helpful if your local tree doesn't match the layout of
the remote branches, but for the common case it's been a recurring
disaster, when "request-pull" is done against a delayed remote update, and
it rewrites the target branch randomly to some other branch name that
happens to have the same expected SHA1 (or more commonly, leaves it
blank).

To avoid that recurring problem, this changes "git request-pull" so that
it matches the ref name to be pulled against the *local* repository, and
then warns if the remote repository does not have that exact same branch
or tag name and content.

This means that git request-pull will never rewrite the ref-name you gave
it.  If the local branch name is "xyzzy", that is the only branch name
that request-pull will ask the other side to fetch.

If the remote has that branch under a different name, that's your problem
and git request-pull will not try to fix it up (but git request-pull will
warn about the fact that no exact matching branch is found, and you can
edit the end result to then have the remote name you want if it doesn't
match your local one).

The new "find local ref" code will also complain loudly if you give an
ambiguous refname (eg you have both a tag and a branch with that same
name, and you don't specify "heads/name" or "tags/name").

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make request-pull able to take a refspec of form local:remote

This allows a user to say that a local branch has a different name on
the remote server, using the same syntax that "git push" uses to create
that situation.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
tree-walk.c: ignore trailing slash on submodule in tree_entry_interesting()

We do ignore trailing slash on a directory, so pathspec "abc/" matches
directory "abc". A submodule is also a directory. Apply the same logic
to it. This makes "git log submodule-path" and "git log submodule-path/"
produce the same output.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t7501: fix "empty commit" test with NO_PERL

t7501.9 tries to check that "git commit" will fail when the
index is unchanged. It relies on previous tests not to have
modified the index. When it was originally written, this was
always the case. However, commit c65dc35 (t7501: test the
right kind of breakage, 2012-03-30) changed earlier tests (4
and 5) to leave a modification in the index.

We never noticed, however, because t7501.7, between the two,
clears the index state as a side effect. However, that test
depends on the PERL prerequisite, and so it does not always
run. Therefore if NO_PERL is set, we do not run the
intervening test, the index is left unclean, and t7501.9
fails.

We could fix this by moving t7501.9 up in the script.
However, this patch instead leaves it in place and adds a
"git reset" before the commit. This makes the test more
explicit about its preconditions, and will future-proof it
against any other changes in the test state.

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