tokkee.org

Documentation: Clarify '--signoff' for git-commit

'--signoff' uses commiter name always to add the signoff line,
make it explicit in the documentation.

Signed-off-by: Abhijit Bhopatkar <bain@devslashzero.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

reset --hard/read-tree --reset -u: remove unmerged new paths

When aborting a failed merge that has brought in a new path using "git
reset --hard" or "git read-tree --reset -u", we used to first forget about
the new path (via read_cache_unmerged) and then matched the working tree
to what is recorded in the index, thus ending up leaving the new path in
the work tree.

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

Update draft release notes for 1.6.1

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

Merge branch 'maint'

* maint:
  Hopefully the final draft release notes update before 1.6.0.3
  diff(1): clarify what "T"ypechange status means
  contrib: update packinfo.pl to not use dashed commands
  force_object_loose: Fix memory leak
  tests: shell negation portability fix

Hopefully the final draft release notes update before 1.6.0.3

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

diff(1): clarify what "T"ypechange status means

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

Merge branch 'db/maint-checkout-b' into maint

* db/maint-checkout-b:
  Check early that a new branch is new and valid

diff: add filter for converting binary to text

When diffing binary files, it is sometimes nice to see the
differences of a canonical text form rather than either a
binary patch or simply "binary files differ."

Until now, the only option for doing this was to define an
external diff command to perform the diff. This was a lot of
work, since the external command needed to take care of
doing the diff itself (including mode changes), and lost the
benefit of git's colorization and other options.

This patch adds a text conversion option, which converts a
file to its canonical format before performing the diff.
This is less flexible than an arbitrary external diff, but
is much less work to set up. For example:

  $ echo '*.jpg diff=exif' >>.gitattributes
  $ git config diff.exif.textconv exiftool
  $ git config diff.exif.binary false

allows one to see jpg diffs represented by the text output
of exiftool.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

diff: introduce diff.<driver>.binary

The "diff" gitattribute is somewhat overloaded right now. It
can say one of three things:

  1. this file is definitely binary, or definitely not
     (i.e., diff or !diff)
  2. this file should use an external diff engine (i.e.,
     diff=foo, diff.foo.command = custom-script)
  3. this file should use particular funcname patterns
     (i.e., diff=foo, diff.foo.(x?)funcname = some-regex)

Most of the time, there is no conflict between these uses,
since using one implies that the other is irrelevant (e.g.,
an external diff engine will decide for itself whether the
file is binary).

However, there is at least one conflicting situation: there
is no way to say "use the regular rules to determine whether
this file is binary, but if we do diff it textually, use
this funcname pattern." That is, currently setting diff=foo
indicates that the file is definitely text.

This patch introduces a "binary" config option for a diff
driver, so that one can explicitly set diff.foo.binary. We
default this value to "don't know". That is, setting a diff
attribute to "foo" and using "diff.foo.funcname" will have
no effect on the binaryness of a file. To get the current
behavior, one can set diff.foo.binary to true.

This patch also has one additional advantage: it cleans up
the interface to the userdiff code a bit. Before, calling
code had to know more about whether attributes were false,
true, or unset to determine binaryness. Now that binaryness
is a property of a driver, we can represent these situations
just by passing back a driver struct.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

diff: unify external diff and funcname parsing code

Both sets of code assume that one specifies a diff profile
as a gitattribute via the "diff=foo" attribute. They then
pull information about that profile from the config as
diff.foo.*.

The code for each is currently completely separate from the
other, which has several disadvantages:

  - there is duplication as we maintain code to create and
    search the separate lists of external drivers and
    funcname patterns

  - it is difficult to add new profile options, since it is
    unclear where they should go

  - the code is difficult to follow, as we rely on the
    "check if this file is binary" code to find the funcname
    pattern as a side effect. This is the first step in
    refactoring the binary-checking code.

This patch factors out these diff profiles into "userdiff"
drivers. A file with "diff=foo" uses the "foo" driver, which
is specified by a single struct.

Note that one major difference between the two pieces of
code is that the funcname patterns are always loaded,
whereas external drivers are loaded only for the "git diff"
porcelain; the new code takes care to retain that situation.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

t4012: use test_cmp instead of cmp

This makes erroneous output slightly easier to see. We also
flip the argument order to match our usual style.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

format-patch: autonumber by default

format-patch is most commonly used for multiple patches at once when
sending a patchset, in which case we want to number the patches; on
the other hand, single patches are not usually expected to be
numbered.

In other words, the typical behavior expected from format-patch is the
one obtained by enabling autonumber, so we set it to be the default.

Users that want to disable numbering for a particular patchset can do
so with the existing -N command-line switch.  Users that want to
change the default behavior can use the format.numbering config key.

Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Test-updates-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Do not rename read-only files during a push

Win32 does not allow renaming read-only files (at least on a Samba
share), making push into a local directory to fail. Thus, defer
the chmod() call in index-pack.c:final() only after
move_temp_to_file() was called.

Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Merge branch 'pb/commit-where'

* pb/commit-where:
  tutorial: update output of git commit
  reformat informational commit message
  git commit: Reformat output somewhat
  builtin-commit.c: show on which branch a commit was added

make alloc_ref_from_str() the new alloc_ref()

With all calls to alloc_ref() gone, we can remove it and then we're free
to give alloc_ref_from_str() the shorter name.  It's a much nicer
interface, as the callers always need to have a name string when they
allocate a ref anyway and don't need to calculate and pass its length+1
any more.

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

use alloc_ref_from_str() everywhere

Replace pairs of alloc_ref() and strcpy() with alloc_ref_from_str(),
simplifying the code.

In connect.c, also a pair of alloc_ref() and memcpy() is replaced --
the additional cost of a strlen() call should not have too much of an
impact.  Consistency and simplicity are more important.

In remote.c, the code was allocating 11 bytes more than needed for
the name part, but I couldn't see them being used for anything.

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

add alloc_ref_with_prefix()

In three cases in remote.c, a "raw" ref is allocated using alloc_ref()
and then its is constructed using sprintf().  Clean it up by adding a
helper function, alloc_ref_with_prefix(), which creates a composite
name.  Use it in alloc_ref_from_str(), too, as it simplifies the code.

Open code alloc_ref() in alloc_ref_with_prefix(), as the former is
going to be removed in the patch after the next.

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

contrib: update packinfo.pl to not use dashed commands

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

force_object_loose: Fix memory leak

read_packed_sha1 expectes its caller to free the buffer it returns, which
force_object_loose didn't do.

This leak is eventually triggered by "git gc", when it is manually invoked
or there are too many packs around, making gc totally unusable when there
are lots of unreachable objects.

Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

index-pack: smarter memory usage during delta resolution

There is no need to keep the base object data around after its last delta
has been resolved.  This also means that long delta chains with only one
delta per base won't grow the cache size unnecessarily as the base will
be freed before recursing down.

To make it easy, find_delta_children() is modified so the first and last
indices are initialized in all cases.

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

index-pack: rationalize delta resolution code

Instead of having strange loops for walking unresolved deltas with the
same base duplicated in many places, let's rework the code so this is
done in a single place instead.  This simplifies callers quite a bit too.

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

gitk: Regenerate .po files

This is the result of running make update-po and removing or fixing
the strings that were fuzzily matched.  The ones that were fixed were
the ones where the only change was "git rev-list" to "git log", and
the "about gitk" message where the copyright year got updated.

To get xgettext to see the menu labels as needing translation, it
was necessary for arrange for them to be preceded by "mc".  This
therefore changes makemenu to ignore the first element in each
menu item so that it can be "mc" in the makemenu call.

Signed-off-by: Paul Mackerras <paulus@samba.org>

Fix "checkout --track -b newbranch" on detached HEAD

The test to make sure that checkout fails when --track was asked for and
we cannot set up tracking information in t7201 was wrong, and it turns out
that the implementation for that feature itself was buggy.  This fixes it.

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

Merge branch 'jk/maint-ls-files-other' into jk/fix-ls-files-other

* jk/maint-ls-files-other:
  refactor handling of "other" files in ls-files and status

Conflicts:
read-cache.c

refactor handling of "other" files in ls-files and status

When the "git status" display code was originally converted
to C, we copied the code from ls-files to discover whether a
pathname returned by read_directory was an "other", or
untracked, file.

Much later, 5698454e updated the code in ls-files to handle
some new cases caused by gitlinks.  This left the code in
wt-status.c broken: it would display submodule directories
as untracked directories. Nobody noticed until now, however,
because unless status.showUntrackedFiles was set to "all",
submodule directories were not actually reported by
read_directory. So the bug was only triggered in the
presence of a submodule _and_ this config option.

This patch pulls the ls-files code into a new function,
cache_name_is_other, and uses it in both places. This should
leave the ls-files functionality the same and fix the bug
in status.

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

describe: Make --tags and --all match lightweight tags more often

If the caller supplies --tags they want the lightweight, unannotated
tags to be searched for a match.  If a lightweight tag is closer
in the history, it should be matched, even if an annotated tag is
reachable further back in the commit chain.

The same applies with --all when matching any other type of ref.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Acked-By: Uwe Kleine-König <ukleinek@strlen.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tests: shell negation portability fix

Commit 969c8775 introduced a test which uses the non-portable construct:

  command1 && ! command2 | command3

which must be

  command1 && ! (command2 | command3)

to work on bsd shells (this is another example of bbf08124, which fixed
several similar cases).

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

pull: allow "git pull origin $something:$current_branch" into an unborn branch

Some misguided documents floating on the Net suggest this sequence:

    mkdir newdir && cd newdir
    git init
    git remote add origin $url
    git pull origin master:master

"git pull" has known about misguided "pull" that lets the underlying fetch
update the current branch for a long time.  It also has known about
"git pull origin master" into a branch yet to be born.

These two workarounds however were not aware of the existence of each
other and did not work well together.  This fixes it.

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

gitk: New way of constructing menus that allows for Alt+letter accelerators

This is inspired by patches from Robin Rosenberg but takes a different
approach.  This adds a "makemenu" procedure for constructing menus
that allows the menu layout to be specified in a clear fashion, and
provides one place where the alt+letter accelerators can be detected
and handled.

The alt+letter accelerator is specified by putting an ampersand (&)
before the letter for the accelerator in the menu item name.  (Two
ampersands in succession produce one ampersand in the menu item as
it appears on screen.)  This is handled in makemenu.

We also add an mca procedure which is like mc but also does the
ampersand translation, for use when we want to refer to a menu item
by name.  The mca name and the locations where we use it were
shamelessly stolen from Robin Rosenberg's patch.

This doesn't actually add any alt+letter accelerators yet.

Signed-off-by: Paul Mackerras <paulus@samba.org>

Merge branch 'maint'

* maint:
  t1301-shared-repo.sh: don't let a default ACL interfere with the test
  git-check-attr(1): add output and example sections
  xdiff-interface.c: strip newline (and cr) from line before pattern matching
  t4018-diff-funcname: demonstrate end of line funcname matching flaw
  t4018-diff-funcname: rework negated last expression test
  Typo "does not exists" when git remote update remote.
  remote.c: correct the check for a leading '/' in a remote name
  Add testcase to ensure merging an early part of a branch is done properly

Conflicts:
t/t7600-merge.sh

t1301-shared-repo.sh: don't let a default ACL interfere with the test

This test creates files with several different umasks and expects their
permissions to be initialized according to the umask, so a default ACL on the
trash directory (which overrides the umask for files created in that directory)
causes the test to fail.  To avoid that, remove the default ACL if possible with
setfacl(1).

Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rebase-i-p: if todo was reordered use HEAD as the rewritten parent

This seems like the best guess we can make until git sequencer marks are
available. That being said, within the context of re-ordering a commit before
its parent in todo, I think applying it on top of the current commit seems like
a reasonable assumption of what the user intended.

Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rebase-i-p: do not include non-first-parent commits touching UPSTREAM

This covers an odd boundary case found by Avi Kivity's script where a branch
coming off of UPSTREAM is merged into HEAD. Initially it show up in
UPSTREAM..HEAD, but technically UPSTREAM is not moving, the rest of head is, so
we should not need to rewrite the merge.

This adds a check saying we can keep `preserve=t` if `p=UPSTREAM`...unless this
is the first first-parent commit in our UPSTREAM..HEAD rev-list, which could
very well point to UPSTREAM, but we still need to consider it as rewritten so we
start pulling in the rest of the UPSTREAM..HEAD commits that point to it.

Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rebase-i-p: only list commits that require rewriting in todo

This is heavily based on Stephan Beyer's git sequencer rewrite of rebase-i-p.

Each commit is still found by rev-list UPSTREAM..HEAD, but a commit is only
included in todo if at least one its parents has been marked for rewriting.

Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rebase-i-p: fix 'no squashing merges' tripping up non-merges

Also only check out the first parent if this commit if not a squash--if it is a
squash, we want to explicitly ignore the parent and leave the wc as is, as
cherry-pick will apply the squash on top of it.

Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rebase-i-p: delay saving current-commit to REWRITTEN if squashing

If the current-commit was dumped to REWRITTEN, but then we squash the next
commit in to it, we have invalidated the HEAD was just written to REWRITTEN.
Instead, append the squash hash to current-commit and save both of them the next
time around.

Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rebase-i-p: use HEAD for updating the ref instead of mapping OLDHEAD

If OLDHEAD was reordered in the todo, and its mapped NEWHEAD was used to set the
ref, commits reordered after OLDHEAD in the todo would should up as un-committed
changes.

Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rebase-i-p: test to exclude commits from todo based on its parents

The first case was based off a script from Avi Kivity <avi@redhat.com>.

The second case includes a merge-of-a-merge to ensure both are included in todo.

Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rebase--interactive: fix parent rewriting for dropped commits

`rebase -i -p` got its rev-list of commits to keep by --left-right and
--cherry-pick. Adding --cherry-pick would drop commits that duplicated changes
already in the rebase target.

The dropped commits were then forgotten about when it came to rewriting the
parents of their descendents, so the descendents would get cherry-picked with
their old, unwritten parents and essentially make the rebase a no-op.

This commit adds a $DOTEST/dropped directory to remember dropped commits and
rewrite their children's parent as the dropped commit's possibly-rewritten
first-parent.

Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-check-attr(1): use 'verse' for multi-line synopsis sections

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

git-check-attr(1): add output and example sections

Plumbing tools should document what output can be expected.

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

xdiff-interface.c: strip newline (and cr) from line before pattern matching

POSIX doth sayeth:

   "In the regular expression processing described in IEEE Std 1003.1-2001,
    the <newline> is regarded as an ordinary character and both a period and
    a non-matching list can match one. ... Those utilities (like grep) that
    do not allow <newline>s to match are responsible for eliminating any
    <newline> from strings before matching against the RE."

Thus far git has not been removing the trailing newline from strings matched
against regular expression patterns. This has the effect that (quoting
Jonathan del Strother) "... a line containing just 'FUNCNAME' (terminated by
a newline) will be matched by the pattern '^(FUNCNAME.$)' but not
'^(FUNCNAME$)'", and more simply not '^FUNCNAME$'.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

t4018-diff-funcname: demonstrate end of line funcname matching flaw

Since the newline is not removed from lines before pattern matching, a
pattern cannot match to the end of the line using the '$' operator without
using an additional operator which will indirectly match the '\n' character.

Introduce a test which should pass, but which does not due to this flaw.

Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t4018-diff-funcname: rework negated last expression test

This test used the non-zero exit status of 'git diff' to indicate that a
negated funcname pattern, when placed last, was correctly rejected.

The problem with this is that 'git diff' always returns non-zero if it
finds differences in the files it is comparing, and the files must
contain differences in order to trigger the funcname pattern codepath.

Instead of checking for non-zero exit status, make sure the expected
error message is printed.

Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Typo "does not exists" when git remote update remote.

gitk: Bind Key-Return to create on new branch dialog

The Return key can now be used as well as pressing the Create button
from the dialog box that is shown when selecting "Create new branch".

Signed-off-by: Richard Quirk <richard.quirk@gmail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Fix binding for <Return> in sha1 entry field

This adds a break so that gitk doesn't go and execute the global
binding for <Return> (i.e. find next) when the user presses the
return key in the sha1 entry field to indicate that gitk should
jump to the commit identified by what they just put into the
sha1 field.

Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Clean up file encoding code and add enable/disable option

This adds an option allowing the user to select whether gitk should
look up per-file encoding settings using git check-attr or not.  If
not, gitk uses the global encoding set in the git config (as reported
by git config --get gui.encoding) for all files, or if that is not
set, then the system encoding.

The option is controlled by a checkbox in the Edit->Preferences
window, and defaults to off for now because git check-attr is so
slow.  When the user turns it on we discard any cached diff file
lists in treediffs, because we may not have encodings cached for
the files listed in those lists, meaning that getblobdiffline will
do it for each file, which will be really really slow.

This adjusts the limit of how many paths cache_gitattr passes to each
instance of git check-attr depending on whether we're running under
windows or not.  Passing only 30 doesn't effectively amortize the
startup costs of git check-attr, but it's all we can do under windows
because of the 32k limit on arguments to a command.  Under other OSes
we pass up to 1000.

Similarly we adjust how many lines gettreediffline processes depending
on whether we are doing per-file encodings so that we don't run for
too long.  When we are, 500 seems to be a reasonable limit, leading
to gettreediffline taking about 60-70ms under Linux (almost all of
which is in cache_gitattr, unfortunately).  This means that we can
take out the update call in cache_gitattr.

This adds a simple cache on [tclencoding].  Now that we get repeated
calls to translate the same encoding, this is useful.

This reindents the new code added in the last couple of commits to
conform to the gitk 4-space indent and makes various other improvements:
use regexp in gitattr and cache_gitattr instead of split + join + regsub,
make gui_encoding be the value from [tclencoding] to avoid having to
do [tcl_encoding $gui_encoding] in each call to get_path_encoding,
and print a warning message at startup if $gui_encoding isn't
supported by Tcl.

Signed-off-by: Paul Mackerras <paulus@samba.org>

remote.c: correct the check for a leading '/' in a remote name

This test is supposed to disallow remote entries in the config file of the
form:

   [remote "/foobar"]
      ...

The leading slash in '/foobar' is not acceptable.

Instead it was incorrectly testing that the subkey had no leading '/', which
had no effect since the subkey pointer was made to point at a '.' in the
preceding lines.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Add testcase to ensure merging an early part of a branch is done properly

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

rebase: Document --no-verify option to bypass pre-rebase hook

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

Add Linux PPC support to the pre-auto-gc example hook

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

t4018-diff-funcname: add objective-c xfuncname pattern to syntax test

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

gitk: Implement batch lookup and caching of encoding attrs

When the diff contains thousands of files, calling git-check-attr once
per file is very slow.  With this patch gitk does attribute lookup in
batches of 30 files while reading the diff file list, which leads to a
very noticeable speedup.

It may be possible to reimplement this even more efficiently, if
git-check-attr is modified to support a --stdin-paths option.
Additionally, it should quote the ':' character in file paths, or
provide a more robust way of column separation.

Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Tested-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Enhance file encoding support

This allows the encoding to be specified for file contents and used
when displaying files and diffs in the bottom-left pane.  When
displaying diffs, the encoding for each diff hunk is that for the file
that the diff hunk is from, so it can change through the course of the
diff.

The encoding for file contents is determined as follows:

- File encoding defaults to the system encoding.
- It can be overridden by setting the gui.encoding option.
- Finally, the 'encoding' attribute is checked on
  per-file basis; it has the last word.

Note: Since git-check-attr does not provide support for reading
attributes from trees, attribute lookup is done using files from the
working directory.

This also extends the range of supported encoding names, adding
ShiftJIS and Shift-JIS as aliases for Shift_JIS, and allowing
cp-*, cp_*, ibm-*, ibm_*, jis-* and jis_* as aliases for cp*,
ibm* and jis* respectively.

This also fixes some bugs in handling of non-ASCII filenames.  Core
git apparently supports only locale-encoded filenames, so processing
is done using the system encoding.

Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Tested-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Paul Mackerras <paulus@samba.org>

Update draft release notes to 1.6.1

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

Merge branch 'maint'

* maint:
  Update draft release notes to 1.6.0.3

Update draft release notes to 1.6.0.3

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

compat/cygwin.c - Use cygwin's stat if core.filemode == true

Cygwin's POSIX emulation allows use of core.filemode true, unlike native
Window's implementation of stat / lstat, and Cygwin/git users who have
configured core.filemode true in various repositories will be very
unpleasantly surprised to find that git is no longer honoring that option.
So, this patch forces use of Cygwin's stat functions if core.filemode is
set true, regardless of any other considerations.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix fetch/pull when run without --update-head-ok

Some confusing tutorials suggested that it would be a good idea to fetch
into the current branch with something like this:

git fetch origin master:master

(or even worse: the same command line with "pull" instead of "fetch").
While it might make sense to store what you want to pull, it typically is
plain wrong when the current branch is "master".  This should only be
allowed when (an incorrect) "git pull origin master:master" tries to work
around by giving --update-head-ok to underlying "git fetch", and otherwise
we should refuse it, but somewhere along the lines we lost that behavior.

The check for the current branch is now _only_ performed in non-bare
repositories, which is an improvement from the original behaviour.

Some newer tests were depending on the broken behaviour of "git fetch"
this patch fixes, and have been adjusted.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tests: shell negation portability fix

Commit 969c8775 introduced a test which uses the non-portable construct:

  command1 && ! command2 | command3

which must be

  command1 && ! (command2 | command3)

to work on bsd shells (this is another example of bbf08124, which fixed
several similar cases).

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

gitweb: refactor input parameters parse/validation

Since input parameters can be obtained both from CGI parameters and
PATH_INFO, we would like most of the code to be agnostic about the way
parameters were retrieved. We thus collect all the parameters into the
new %input_params hash, delaying validation after the collection is
completed.

Although the kludge removal is minimal at the moment, it makes life much
easier for future expansions such as more extensive PATH_INFO use or
other form of input such as command-line support.

Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

check-attr: Add --stdin option

This allows multiple paths to be specified on stdin.

Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

check-attr: add an internal check_attr() function

This step is preparation to introducing --stdin-paths option.

I have also added maybe_flush_or_die() at the end of main() to ensure that
we exit with the zero code only when we flushed the output successfully.

Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Merge branch 'maint'

* maint:
  test-lib: fix broken printf
  git apply --directory broken for new files

test-lib: fix broken printf

b8eecafd888d219633f4c29e8b6a90fc21a46dfd introduced usage of
printf without a format string.

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

"git diff <tree>{3,}": do not reverse order of arguments

According to the message of commit 0fe7c1de16f71312e6adac4b85bddf0d62a47168,
"git diff" with three or more trees expects the merged tree first followed by
the parents, in order.  However, this command reversed the order of its
arguments, resulting in confusing diffs.  A comment /* Again, the revs are all
reverse */ suggested there was a reason for this, but I can't figure out the
reason, so I removed the reversal of the arguments.  Test case included.

Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Replace calls to strbuf_init(&foo, 0) with STRBUF_INIT initializer

Many call sites use strbuf_init(&foo, 0) to initialize local
strbuf variable "foo" which has not been accessed since its
declaration. These can be replaced with a static initialization
using the STRBUF_INIT macro which is just as readable, saves a
function call, and takes up fewer lines.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

print an error message for invalid path

If verification of path failed, it is always better to print an
error message saying this than relying on the caller function to
print a meaningful error message (especially when the callee already
prints error message for another situation).

Because the callers of add_index_entry_with_check() did not print
any error message, it resulted that the user would not notice the
problem when checkout of an invalid path failed.

Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Documentation: remove stale howto/rebase-and-edit.txt

The "rebase and edit" howto predates the much easier solution 'git
rebase -i' by two years.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'

Since dbf5e1e9, the '--no-validate' option is a Getopt::Long boolean
option. The '--no-' prefix (as in --no-validate) for boolean options
is not supported in Getopt::Long version 2.32 which was released with
Perl 5.8.0. This version only supports '--no' as in '--novalidate'.
More recent versions of Getopt::Long, such as version 2.34, support
either prefix. So use the older form in the tests.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git apply --directory broken for new files

We carefully verify that the input to git-apply is sane,
including cross-checking that the filenames we see in "+++"
headers match what was provided on the command line of "diff
--git". When --directory is used, however, we ended up
comparing the unadorned name to one with the prepended root,
causing us to complain about a mismatch.

We simply need to prepend the root directory, if any, when
pulling the name out of the git header.

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

git-gui: Mark-up strings in show_{other,unmerged}_diff() for localization

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Show a round number of bytes of large untracked text files

If an untracked text file is selected, then its contents are displayed
instead of a diff. If the file is large, then the following hint is
inserted at the top:

  * Untracked file is 14774881 bytes.
  * Showing only first 131072 bytes.

Why exactly 131072 bytes? With this patch it is 100000 bytes.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Fix the blame viewer destroy handler.

It did not delete the object, which is not very good.
Also, destroy may be fired up for subwindows, so we
should check %W.

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

git-gui: Add a search command to the blame viewer.

One of the largest deficiencies in the blame viewer at
the moment is the impossibility to search for a text
string. This commit fixes it by adding a Firefox-like
search panel to the viewer.

The panel can be shown by pressing F7 or clicking a
menu entry, and is hidden by pressing Esc. Find Next
is available through the F3 key.

Implementation is based on the gitk code, but heavily
refactored. It now also supports case-insensitive
searches, and uses the text box background color to
signal success or failure of the search.

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

git-gui: Fix the blame window shape.

On modern high-resolution monitors the blame viewer
window is very high, yet too narrow. This patch
makes it gravitate to a more sane resolution, which
takes the font size into account.

It also changes the default text view size to 80% of
the window, and slightly modifies the border decorations
for better appearance.

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

git-gui: Fix switch statement in lib/merge.tcl

0aea2842 (Make Ctrl-T safe to use for conflicting files) introduced a new
case, but forgot the '-' to indicate that it shares the body with the
subsequent case label.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Merge branch 'maint'

* maint:
  rebase -i: do not fail when there is no commit to cherry-pick
  test-lib: fix color reset in say_color()
  fix pread()'s short read in index-pack

Conflicts:
csum-file.c

rebase -i: do not fail when there is no commit to cherry-pick

In case there is no commit to apply (for example because you rebase to
upstream and all your local patches have been applied there), do not
fail.  The non-interactive rebase already behaves that way.

Do this by introducing a new command, "noop", which is substituted for
an empty commit list, so that deleting the commit list can still abort
as before.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

test-lib: fix color reset in say_color()

When executing a single test with colors enabled, the cursor was not set
back to the previous one, and you had to hit an extra enter to get it
back.

Work around this problem by calling 'tput sgr0' before printing the
final newline.

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

fix pread()'s short read in index-pack

Since v1.6.0.2~13^2~ the completion of a thin pack uses sha1write() for
its ability to compute a SHA1 on the written data.  This also provides
data buffering which, along with commit 92392b4a45, will confuse pread()
whenever an appended object is 1) freed due to memory pressure because
of the depth-first delta processing, and 2) needed again because it has
many delta children, and 3) its data is still buffered by sha1write().

Let's fix the issue by simply forcing cached data out when such an
object is written so it can be pread()'d at leisure.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Implement git clone -v

The new -v option forces the progressbar, even in case the output
is not a terminal.  This can be useful if the caller is an IDE or
wrapper which wants to scrape the progressbar from stderr and show
its information in a different format.

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Merge branch 'js/objc-funchdr'

* js/objc-funchdr:
  Teach git diff about Objective-C syntax

Merge branch 'pb/gitweb'

* pb/gitweb:
  gitweb: Support for simple project search form
  gitweb: Make the by_tag filter delve in forks as well
  gitweb: Support for tag clouds
  gitweb: Add support for extending the action bar with custom links
  gitweb: Sort the list of forks on the summary page by age
  gitweb: Clean-up sorting of project list

Merge branch 'dm/svn-branch'

* dm/svn-branch:
  Add git-svn branch to allow branch creation in SVN repositories

Merge branch 'bc/xdiffnl'

* bc/xdiffnl:
  xdiff-interface.c: strip newline (and cr) from line before pattern matching

Merge branch 'dp/cywginstat'

* dp/cywginstat:
  cygwin: Use native Win32 API for stat
  mingw: move common functionality to win32.h
  add have_git_dir() function

Merge branch 'lt/time-reject-fractional-seconds'

* lt/time-reject-fractional-seconds:
  date/time: do not get confused by fractional seconds

Merge branch 'jc/add-ita'

* jc/add-ita:
  git-add --intent-to-add (-N)

Merge branch 'mw/sendemail'

* mw/sendemail:
  bash completion: Add --[no-]validate to "git send-email"
  send-email: signedoffcc -> signedoffbycc, but handle both
  Docs: send-email: Create logical groupings for man text
  Docs: send-email: Create logical groupings for --help text
  Docs: send-email: Remove unnecessary config variable description
  Docs: send-email: --chain_reply_to -> --[no-]chain-reply-to
  send-email: change --no-validate to boolean --[no-]validate
  Docs: send-email: Man page option ordering
  Docs: send-email usage text much sexier
  Docs: send-email's usage text and man page mention same options

Merge branch 'mv/merge-refresh'

* mv/merge-refresh:
  builtin-merge: refresh the index before calling a strategy

Merge branch 'ph/parseopt'

* ph/parseopt:
  parse-opt: migrate builtin-merge-file.
  parse-opt: migrate git-merge-base.
  parse-opt: migrate fmt-merge-msg.

Merge branch 'rz/grepz'

* rz/grepz:
  git grep: Add "-z/--null" option as in GNU's grep.

Merge branch 'mg/verboseprune'

* mg/verboseprune:
  make prune report removed objects on -v

Merge branch 'maint'

* maint:
  builtin-apply: fix typo leading to stack corruption
  git-stash.sh: fix flawed fix of invalid ref handling (commit da65e7c1)
  builtin-merge.c: allocate correct amount of memory
  Makefile: do not set NEEDS_LIBICONV for Solaris 8
  rebase -i: remove leftover debugging
  rebase -i: proper prepare-commit-msg hook argument when squashing

Merge branch 'sg/maint-intrebase-msghook' into maint

* sg/maint-intrebase-msghook:
  rebase -i: remove leftover debugging
  rebase -i: proper prepare-commit-msg hook argument when squashing

builtin-apply: fix typo leading to stack corruption

This typo led to stack corruption for lines with whitespace fixes
and length > 1024.

Signed-off-by: Imre Deak <imre.deak@gmail.com>
Looks-good-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-stash.sh: fix flawed fix of invalid ref handling (commit da65e7c1)

The referenced commit tried to fix a flaw in stash's handling of a user
supplied invalid ref. i.e. 'git stash apply fake_ref@{0}' should fail
instead of applying stash@{0}. But, it did so in a naive way by avoiding the
use of the --default option of rev-parse, and instead manually supplied the
default revision if the user supplied an empty command line. This prevented
a common usage scenario of supplying flags on the stash command line (i.e.
non-empty command line) which would be parsed by lower level git commands,
without supplying a specific revision. This should fall back to the default
revision, but now it causes an error. e.g. 'git stash show -p'

The correct fix is to use the --verify option of rev-parse, which fails
properly if an invalid ref is supplied, and still allows falling back to a
default ref when one is not supplied.

Convert stash-drop to use --verify while we're at it, since specifying
multiple revisions for any of these commands is also an error and --verify
makes it so.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Merge branch 'jk/maint-soliconv' into maint

* jk/maint-soliconv:
  Makefile: do not set NEEDS_LIBICONV for Solaris 8