compate/clipped-write.c: large write(2) fails on Mac OS X/XNU

Due to a bug in the Darwin kernel, write(2) calls have a maximum size
of INT_MAX bytes.

Introduce a new compat function, clipped_write(), that only writes
at most INT_MAX bytes and returns the number of bytes written, as
a substitute for write(2), and allow platforms that need this to
enable it from the build mechanism with NEEDS_CLIPPED_WRITE.

Set it for Mac OS X by default.  It may be necessary to include this
function on Windows, too.

Signed-off-by: Filipe Cabecinhas <redacted>
Signed-off-by: Junio C Hamano <redacted>

documentation: trivial style cleanups

White-spaces, missing braces, standardize --[no-]foo.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

Merge git://ozlabs.org/~paulus/gitk

* git://ozlabs.org/~paulus/gitk:
  gitk: Update Swedish translation (304t)

difftool: fix dir-diff when file does not exist in working tree

Commit 02c5631 (difftool --dir-diff: symlink all files matching the
working tree, 2013-03-14) does not handle the case where a file that is
being compared does not exist in the working tree.  Fix this by checking
for existence explicitly before running git-hash-object.

Reported-by: Kevin Bracey <redacted>
Signed-off-by: John Keeping <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-bzr: fixes for older versions of bzr

Down to v2.0, by using older but still valid interfaces.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-bzr: fix old organization destroy

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

prompt: colorize ZSH prompt

Add colors suitable for use in the ZSH prompt.  Having learnt that the
ZSH equivalent of PROMPT_COMMAND is precmd (), you can now use
GIT_PS1_SHOWCOLORHINTS with ZSH.

Signed-off-by: Ramkumar Ramachandra <redacted>
Signed-off-by: Junio C Hamano <redacted>

prompt: factor out gitstring coloring logic

So that we can extend it with ZSH-colors in a later patch.

Signed-off-by: Ramkumar Ramachandra <redacted>
Signed-off-by: Junio C Hamano <redacted>

prompt: introduce GIT_PS1_STATESEPARATOR

A typical prompt looks like:

    artagnon|master *=:~/src/git$
                   ^
                   why do we have this space?

Nobody has branch names that end with +, *, =, < or > anyway, so it
doesn't serve the purpose of disambiguation.

Make this separator configurable via GIT_PS1_STATESEPARATOR.  This means
that you can set it to "" and get this prompt:

    artagnon|master*=:~/src/git$

Signed-off-by: Ramkumar Ramachandra <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-gui: change dialog button positions for Windows to suit platform.

On windows it is more common to have cancel furthest on the right.

Signed-off-by: Pat Thoyts <redacted>

Documentation/merge-options.txt: restore `-e` option

It looks like commit f8246281af9adb0fdddbcc90d2e19cb5cd5217e5
unintentionally removed the documentation for the `-e` option.

Signed-off-by: Richard Hansen <redacted>
Signed-off-by: Junio C Hamano <redacted>

gitk: Update Swedish translation (304t)

Signed-off-by: Peter Krefting <redacted>
Signed-off-by: Paul Mackerras <redacted>

Revert "remote-hg: update bookmarks when pulling"

This reverts commit 24317ef32ac3111ed00792f9b2921dc19dd28fe2.

Different versions of Mercurial have different arguments for
bookmarks.updatefromremote(), while it should be possible to call the
right function with the right arguments depending on the version, it's
safer to restore the old behavior for now.

Reported by Rodney Lorrimar.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-gui: allow "\ No newline at end of file" for linewise staging

Counting of lines did not skip this line when generating the hunk
header.

Acked-by: Tobias Preuss <redacted>
Signed-off-by: Heiko Voigt <redacted>
Signed-off-by: Pat Thoyts <redacted>

strbuf_branchname(): do not double-expand @{-1}~22

If you were on 'frotz' branch before you checked out your current
branch, "git merge @{-1}~22" means the same as "git merge frotz~22".

The strbuf_branchname() function, when interpret_branch_name() gives
up resolving "@{-1}~22" fully, returns "frotz" and tells the caller
that it only resolved "@{-1}" part of the input, mistakes this as a
total failure, and appends the whole thing to the result, yielding
"frotz@{-1}~22", which does not make any sense.

Inspect the return value from interpret_branch_name() a bit more
carefully.  When it errored out without consuming anything, we will
get -1 and we should return the whole thing.  Otherwise, we should
append the remainder (i.e. "~22" in the earlier example) to the
partially resolved name (i.e. "frotz").

The test suite adds enough number of checkout to make @{-12} in the
last test in t0100 that tried to check "we haven't flipped branches
that many times" error case succeed; raise the number to a hundred.

Signed-off-by: Junio C Hamano <redacted>

git-submodule.txt: Clarify 'init' and 'add' subcommands.

Describe how 'add' sets the submodule's logical name, which is used in
the configuration entry names.

Clarify that 'init' only sets up the configuration entries for
submodules that have already been added elsewhere.  Describe that
<path> arguments limit the submodules that are configured.

Signed-off-by: Dale Worley <redacted>
Acked-by: Jens Lehmann <redacted>
Signed-off-by: Junio C Hamano <redacted>

revision.c: make default history consider bottom commits

Previously, the default history treated bottom commits the same as any
other UNINTERESTING commit, which could force it down side branches.

Consider the following history:

   *A--*B---D--*F         * marks !TREESAME parent paths
     \     /*
      `-C-'

When requesting "B..F", B is UNINTERESTING but TREESAME to D. C is
!UNINTERESTING.

So default following would go from D into the irrelevant side branch C
to A, rather than to B.  Note also that if there had been an extra
!UNINTERESTING commit B1 between B and D, it wouldn't have gone down C.

Change the default following to test relevant_commit() instead of
!UNINTERESTING, so it can proceed straight from D to B, thus finishing
the traversal of that path.

Signed-off-by: Kevin Bracey <redacted>
Signed-off-by: Junio C Hamano <redacted>

revision.c: don't show all merges for --parents

When using --parents or --children, get_commit_action() previously showed
all merges, even if TREESAME to both parents.

This was intended to tie together the topology of the rewritten parents,
but it was excessive - in fact we only need to show merges that have two
or more relevant parents. Merges at the boundary do not necessarily need
to be shown.

Signed-off-by: Kevin Bracey <redacted>
Signed-off-by: Junio C Hamano <redacted>

revision.c: discount side branches when computing TREESAME

Use the BOTTOM flag to define relevance for pruning. Relevant commits
are those that are !UNINTERESTING or BOTTOM, and this allows us to
identify irrelevant side branches (UNINTERESTING && !BOTTOM).

If a merge has relevant parents, and it is TREESAME to them, then do not
let irrelevant parents cause the merge to be treated as !TREESAME.

When considering simplification, don't always include all merges -
merges with exactly one relevant parent can be simplified, if TREESAME
according to the above rule.

These two changes greatly increase simplification in limited, pruned
revision lists.

Signed-off-by: Kevin Bracey <redacted>
Signed-off-by: Junio C Hamano <redacted>

revision.c: add BOTTOM flag for commits

When performing edge-based operations on the revision graph, it can be
useful to be able to identify the INTERESTING graph's connection(s) to
the bottom commit(s) specified by the user.

Conceptually when the user specifies "A..B" (== B ^A), they are asking
for the history from A to B. The first connection from A onto the
INTERESTING graph is part of that history, and should be considered. If
we consider only INTERESTING nodes and their connections, then we're
really only considering the history from A's immediate descendants to B.

This patch does not change behaviour, but adds a new BOTTOM flag to
indicate the bottom commits specified by the user, ready to be used by
following patches.

We immediately use the BOTTOM flag to return collect_bottom_commits() to
its original approach of examining the pending commit list rather than
the command line. This will ensure alignment of the definition of
"bottom" with future patches.

Signed-off-by: Kevin Bracey <redacted>
Signed-off-by: Junio C Hamano <redacted>

simplify-merges: drop merge from irrelevant side branch

Reimplement commit 4b7f53da on top of the new simplify-merges
infrastructure, tightening the condition to only consider root parents;
the original version incorrectly dropped parents that were TREESAME to
anything.

Original log message follows.

The merge simplification rule stated in 6546b59 (revision traversal:
show full history with merge simplification, 2008-07-31) still
treated merge commits too specially.  Namely, in a history with this
shape:

---o---o---M
          /
         x---x---x

where three 'x' were on a history completely unrelated to the main
history 'o' and do not touch any of the paths we are following, we
still said that after simplifying all of the parents of M, 'x'
(which is the leftmost 'x' that rightmost 'x simplifies down to) and
'o' (which would be the last commit on the main history that touches
the paths we are following) are independent from each other, and
both need to be kept.

That is incorrect; when the side branch 'x' never touches the paths,
it should be removed to allow M to simplify down to the last commit
on the main history that touches the paths.

Suggested-by: Junio C Hamano <redacted>
Signed-off-by: Kevin Bracey <redacted>
Signed-off-by: Junio C Hamano <redacted>

simplify-merges: never remove all TREESAME parents

When simplifying an odd merge, such as one that used "-s ours", we may
find ourselves TREESAME to apparently redundant parents. Prevent
simplify_merges() from removing every TREESAME parent; if this would
happen reinstate the first TREESAME parent - the one that the default
log would have followed.

This avoids producing a totally disjoint history from the default log
when the default log is a better explanation of the end result, and aids
visualisation of odd merges.

Signed-off-by: Kevin Bracey <redacted>
Signed-off-by: Junio C Hamano <redacted>

t6012: update test for tweaked full-history traversal

Signed-off-by: Junio C Hamano <redacted>

revision.c: Make --full-history consider more merges

History simplification previously always treated merges as TREESAME
if they were TREESAME to any parent.

While this was consistent with the default behaviour, this could be
extremely unhelpful when searching detailed history, and could not be
overridden. For example, if a merge had ignored a change, as if by "-s
ours", then:

  git log -m -p --full-history -Schange file

would successfully locate "change"'s addition but would not locate the
merge that resolved against it.

Futher, simplify_merges could drop the actual parent that a commit
was TREESAME to, leaving it as a normal commit marked TREESAME that
isn't actually TREESAME to its remaining parent.

Now redefine a commit's TREESAME flag to be true only if a commit is
TREESAME to _all_ of its parents. This doesn't affect either the default
simplify_history behaviour (because partially TREESAME merges are turned
into normal commits), or full-history with parent rewriting (because all
merges are output). But it does affect other modes. The clearest
difference is that --full-history will show more merges - sufficient to
ensure that -m -p --full-history log searches can really explain every
change to the file, including those changes' ultimate fate in merges.

Also modify simplify_merges to recalculate TREESAME after removing
a parent. This is achieved by storing per-parent TREESAME flags on the
initial scan, so the combined flag can be easily recomputed.

This fixes some t6111 failures, but creates a couple of new ones -
we are now showing some merges that don't need to be shown.

Signed-off-by: Kevin Bracey <redacted>
Signed-off-by: Junio C Hamano <redacted>

Documentation: avoid "uninteresting"

The documentation of --boundary uses the term "uninteresting", which is
not used or defined anywhere else in the documentation. This is
unhelpful and confusing to anyone who hasn't seen the UNINTERESTING
flag in the source code.

Change to use "excluded", as per revisions.txt.

Signed-off-by: Kevin Bracey <redacted>
Signed-off-by: Junio C Hamano <redacted>

rev-list-options.txt: correct TREESAME for P

In the example given, P is not TREESAME to E. This doesn't affect the
current result, but it will matter when we change behaviour.

Signed-off-by: Kevin Bracey <redacted>
Signed-off-by: Junio C Hamano <redacted>

t6111: add parents to tests

Signed-off-by: Kevin Bracey <redacted>
Signed-off-by: Junio C Hamano <redacted>

t6111: allow checking the parents as well

Signed-off-by: Junio C Hamano <redacted>

t6111: new TREESAME test set

Some side branching and odd merging to illustrate various flaws in
revision list scans, particularly when limiting the list.

Many expected failures, which will be gone by the end of the "history
traversal refinements" series.

Signed-off-by: Kevin Bracey <redacted>
Signed-off-by: Junio C Hamano <redacted>

t6019: test file dropped in -s ours merge

In preparation for upcoming TREESAME work, check the result for G.t,
which is dropped in "-s ours" merge L. The default rev-list is empty, as
expected - it follows the first parent path where it never existed.

Unfortunately, --ancestry-path is also empty. Merges H J and L are all
TREESAME to 1 parent, so are treated as TREESAME and not shown. This is
clearly undesirable in the case of merge L, which dropped our G.t by
taking the non-ancestry-path version. Document this as a known failure,
and expect "H J L", the 3 merges along the path that had to chose G.t
versions.

Signed-off-by: Kevin Bracey <redacted>
Signed-off-by: Junio C Hamano <redacted>

decorate.c: compact table when growing

When growing the table, take the opportunity to "compact" it by removing
entries with NULL decoration.

Users may have "removed" decorations by passing NULL to
insert_decoration. An object's table entry can't actually be removed
during normal operation, as it would break the linear hash collision
search. But we can remove NULL decoration entries when rebuilding the
table.

Signed-off-by: Kevin Bracey <redacted>
Signed-off-by: Junio C Hamano <redacted>

revision.c: treat A...B merge bases as if manually specified

The documentation assures users that "A...B" is defined as "A B --not
$(git merge-base --all A B)". This wasn't in fact quite true, because
the calculated merge bases were not sent to add_rev_cmdline().

The main effect of this was that although

  git rev-list --ancestry-path A B --not $(git merge-base --all A B)

worked, the simpler form

  git rev-list --ancestry-path A...B

failed with a "no bottom commits" error.

Other potential users of bottom commits could also be affected by this
problem, if they examine revs->cmdline_info; I came across the issue in
my proposed history traversal refinements series.

So ensure that the calculated merge bases are sent to add_rev_cmdline(),
flagged with new 'whence' enum value REV_CMD_MERGE_BASE.

Signed-off-by: Kevin Bracey <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-bzr: fix cloning of non-listable repos

Commit 95b0c60 (remote-bzr: add support for bzr repos) introduced a
regression by assuming all bzr remote repos are listable, but they are
not.

If they are not listable they are basically useless, so let's assume
there is no bzr repo.

Reported-by: Thorsten Kranzkowski <redacted>
Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

Merge branch 'fc/remote-hg' (early part)

* 'fc/remote-hg' (early part):
  remote-hg: update bookmarks when pulling
  remote-hg: don't push fake 'master' bookmark
  remote-hg: disable forced push by default
  remote-hg: fix new branch creation
  remote-hg: add new get_config_bool() helper
  remote-hg: enable track-branches in hg-git mode
  remote-hg: get rid of unused exception checks
  remote-hg: trivial cleanups

remote-hg: update bookmarks when pulling

Otherwise, the user would never ever see new bookmarks, only the
ones that (s)he initially cloned.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-hg: don't push fake 'master' bookmark

We skip it locally, but not for the remote, so let's do so.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-hg: disable forced push by default

In certain situations we might end up pushing garbage revisions
(e.g. in a rebase), and the patches to deal with that haven't been
merged yet.  So let's disable forced pushes by default.

We are essentially reverting back to the old v1.8.2 behavior, to
minimize the possibility of regressions, but in a way the user can
configure.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-hg: fix new branch creation

When a user creates a new branch with git:

 % git checkout -b branches/devel

and then pushes this branch

 % git push origin branches/devel

which is the way to push new mercurial branches, we do want to
create a branch, but the command would fail without newbranch=True.

This only matters when force_push=False, but setting newbranch=True
unconditionally does not hurt.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-hg: add new get_config_bool() helper

No functional changes.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-hg: enable track-branches in hg-git mode

The user can turn this off.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-hg: get rid of unused exception checks

Remove try/except check because we are no longer calling
check_output(), which may throw an exception.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-hg: trivial cleanups

Drop unused "global", and remove redundant comparison of two files.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

combine-diff.c: Fix output when changes are exactly 3 lines apart

When a deletion is followed by exactly 3 (or whatever the number of
context lines) unchanged lines, followed by another change, the combined
diff output would hide the first deletion, resulting in a malformed
diff.

This happened because the 3 lines before each change are painted
interesting, but also marked as no_pre_delete to prevent showing deletes
that were previously marked as uninteresting. This behaviour was
introduced in c86fbe53 (diff -c/--cc: do not include uninteresting
deletion before leading context). However, as a side effect, this could
also mark deletes that were already interesting as no_pre_delete. This
would happen only if the delete was exactly 3 lines away from the next
change, since lines farther away would not be touched by the "paint
three lines before the change" code and lines closer would be painted
by the "merge two adjacent hunks" code instead, which does not set the
no_pre_delete flag.

This commit fixes this problem by only setting the no_pre_delete flag
for changes that were previously uninteresting.

Signed-off-by: Matthijs Kooijman <redacted>
Signed-off-by: Junio C Hamano <redacted>

config: refactor management of color.ui's default value

The meaning of get_colorbool_found and get_diff_color_found is "the
config value if found, and -1 otherwise", but get_color_ui_found had a
slightly different meaning, as it has the value 0 (which corresponds to
the default value from the user point of view) when color.ui is unset.

Make get_color_ui_found default to -1, and make it explicit that 0 is the
default value when nothing else is found.

Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-bzr: update old organization

If a clone exists with the old organization (v1.8.2) it will prevent
the new shared bzr repository organization from working, so let's
remove this repository, which is not used any more.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

coverage: build coverage-untested-functions by default

Change the 'coverage' target to build coverage-untested-functions by
default, so as to make it more discoverable.

Signed-off-by: Thomas Rast <redacted>
Signed-off-by: Junio C Hamano <redacted>

coverage: set DEFAULT_TEST_TARGET to avoid using prove

If the user sets DEFAULT_TEST_TARGET=prove in his config.mak, that
carries over into the coverage tests.  Which is really bad if he also
sets GIT_PROVE_OPTS=-j<..> as that completely breaks the coverage
runs.

Instead of attempting to mess with the GIT_PROVE_OPTS, just force the
test target to 'test' so that we run under make, like we intended all
along.

Signed-off-by: Thomas Rast <redacted>
Signed-off-by: Junio C Hamano <redacted>

coverage: do not delete .gcno files before building

The coverage-compile target depends on coverage-clean, which is
supposed to remove the earlier build products that would get in the
way of the next coverage test run.

However, removing *.gcno is actively wrong.  These are the files that
contain the compile-time coverage related data.  They are only rebuilt
if the source is compiled.  So if one ran 'make coverage' two times in
a row, the second run would remove *.gcno, but then fail to recreate
them because neither source files nor build flags have changed.  (This
remained hidden for so long most likely because any other intervening
use of 'make' will change the build flags, causing a full rebuild.)

So we make an exception for *.gcno.  The *.gcda are the coverage
results, written when the gcov-instrumented program is run.  We still
remove those, so as to get a one-test-run view of the data; you could
probably argue the other way too.

Signed-off-by: Thomas Rast <redacted>
Signed-off-by: Junio C Hamano <redacted>

coverage: split build target into compile and test

Confusingly, the coverage-build target in fact builds with gcov
support _and runs tests_.

Split it into two targets that actually are named after what they do.

Signed-off-by: Thomas Rast <redacted>
Signed-off-by: Junio C Hamano <redacted>

Git 1.8.3-rc2

Signed-off-by: Junio C Hamano <redacted>

t6019: demonstrate --ancestry-path A...B breakage

Signed-off-by: Kevin Bracey <redacted>
Signed-off-by: Junio C Hamano <redacted>

Merge git://ozlabs.org/~paulus/gitk

* git://ozlabs.org/~paulus/gitk:
  gitk: On OSX, bring the gitk window to front
  gitk: Add support for -G'regex' pickaxe variant
  gitk: Add menu item for reverting commits
  gitk: Simplify file filtering
  gitk: Display the date of a tag in a human-friendly way
  gitk: Improve behaviour of drop-down lists
  gitk: Move hard-coded colors to .gitk

gitk: On OSX, bring the gitk window to front

On OSX, Tcl/Tk application windows are created behind all
the applications down the stack of windows.  This is very
annoying, because once a gitk window appears, it's the
downmost window and switching to it is pain.

The patch is: if we are on OSX, use osascript to
bring the current Wish process window to front.

Signed-off-by: Tair Sabirgaliev <redacted>
Thanks-to: Stefan Haller <redacted>
Signed-off-by: Paul Mackerras <redacted>

gitk: Add support for -G'regex' pickaxe variant

git log -G'regex' is a very useful alternative to the classic
pickaxe.  Minimal patch to make it usable from gitk.

[zj: reword message]
[paulus@samba.org: reword droplist item]
Signed-off-by: Zbigniew Jędrzejewski-Szmek <redacted>
Signed-off-by: Paul Mackerras <redacted>

rebase --merge: return control to caller, for housekeeping

Return control to the caller git-rebase.sh to get these two tasks

    rm -fr "$dotest"
    git gc --auto

done by it.

Signed-off-by: Ramkumar Ramachandra <redacted>
Signed-off-by: Junio C Hamano <redacted>

rebase -i: return control to caller, for housekeeping

Return control to the caller git-rebase.sh to get these two tasks

    rm -fr "$dotest"
    git gc --auto

done by it.

Signed-off-by: Ramkumar Ramachandra <redacted>
Signed-off-by: Junio C Hamano <redacted>

am: return control to caller, for housekeeping

We only need to do these two tasks

    git gc --auto
    rm -fr "$dotest"

ourselves if the script was invoked as a standalone program; when
invoked with --rebasing (from git-rebase--am.sh), cascade control back
to the ultimate caller git-rebase.sh to do this for us.

Signed-off-by: Ramkumar Ramachandra <redacted>
Signed-off-by: Junio C Hamano <redacted>

rebase: prepare to do generic housekeeping

On successful completion of a rebase in git-rebase--$backend.sh, the
$backend script cleans up on its own and exits.  The cleanup routine
is however, independent of the $backend, and each $backend script
unnecessarily duplicates this work:

    rm -rf "$state_dir"
    git gc --auto

Prepare git-rebase.sh for later patches that return control from each
$backend script back to us, for performing this generic cleanup
routine.  The code that this patch adds is currently unreachable, and
will only start to be used when git-rebase--$backend.sh scripts are
taught to return control in later patches.

Another advantage is that git-rebase.sh can implement a generic
finish_rebase() to possibly do additional tasks in addition to the
cleanup.

Signed-off-by: Ramkumar Ramachandra <redacted>
Signed-off-by: Junio C Hamano <redacted>

rebase -i: don't error out if $state_dir already exists

In preparation for a later patch that will create $state_dir/autostash
in git-rebase.sh before anything else can happen, change a `mkdir
$state_dir` call to `mkdir -p $state_dir`.  The change is safe,
because this is not a test to detect an in-progress rebase (that is
already done much earlier in git-rebase.sh).

Signed-off-by: Ramkumar Ramachandra <redacted>
Signed-off-by: Junio C Hamano <redacted>

am: tighten a conditional that checks for $dotest

In preparation for a later patch that creates $dotest/autostash in
git-rebase.sh before anything else happens, don't assume that the
presence of a $dotest directory implies the existence of the
$dotest/next and $dotest/last files.  Look for them explicitly.

Signed-off-by: Ramkumar Ramachandra <redacted>
Signed-off-by: Junio C Hamano <redacted>

t5551: do not use unportable sed '\+'

The set-up step to prepare a repository with 50000 tags used a
non-porable '\+' to match one-or-more.

The error was not caught because the next test that uses that
repository did not even bother to check if these expected tags were
actually cloned to the resulting repository.

Fix the sed construct to use BRE and update the "clone" test that
wanted to test cloning from such a repository with many refs to
check the resulting repository.

Signed-off-by: Junio C Hamano <redacted>

fetch: opportunistically update tracking refs

When we run a regular "git fetch" without arguments, we
update the tracking refs according to the configured
refspec. However, when we run "git fetch origin master" (or
"git pull origin master"), we do not look at the configured
refspecs at all, and just update FETCH_HEAD.

We miss an opportunity to update "refs/remotes/origin/master"
(or whatever the user has configured). Some users find this
confusing, because they would want to do further comparisons
against the old state of the remote master, like:

  $ git pull origin master
  $ git log HEAD...origin/master

In the currnet code, they are comparing against whatever
commit happened to be in origin/master from the last time
they did a complete "git fetch".  This patch will update a
ref from the RHS of a configured refspec whenever we happen
to be fetching its LHS. That makes the case above work.

The downside is that any users who really care about whether
and when their tracking branches are updated may be
surprised.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

refactor "ref->merge" flag

Each "struct ref" has a boolean flag that is set by the
fetch code to determine whether the ref should be marked as
"not-for-merge" or not when we write it out to FETCH_HEAD.

It would be useful to turn this boolean into a tri-state,
with the third state meaning "do not bother writing it out
to FETCH_HEAD at all". That would let us add extra refs to
the set of refs to be stored (e.g., to store copies of
things we fetched) without impacting FETCH_HEAD.

This patch turns it into an enum that covers the tri-state
case, and hopefully makes the code more explicit and easier
to read.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

fetch/pull doc: untangle meaning of bare <ref>

The documentation erroneously used the same wording for both fetch and
pull, stating that something will be merged even in git-fetch(1).

In addition, saying that "<ref> is equivalent to <ref>:" doesn't
really help anyone who still needs to read manpages.  Clarify what is
actually going on.

Signed-off-by: Thomas Rast <redacted>
Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

t5510: start tracking-ref tests from a known state

We have three sequential tests for for whether tracking refs
are updated by various fetches and pulls; the first two
should not update the ref, and the third should. Each test
depends on the state left by the test before.

This is fragile (a failing early test will confuse later
tests), and means we cannot add more "should update" tests
after the third one.

Let's instead save the initial state before these tests, and
then reset to a known state before running each test.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

test-bzr: do not use unportable sed '\+'

Using sed -e '/[0-9]\+//' to find "one or more digits" is not
portable.

Use the Basic Regular Expression '/[0-9][0-9]*//' instead.

Signed-off-by: Torsten Bögershausen <redacted>
Signed-off-by: Junio C Hamano <redacted>

Merge git://git.bogomips.org/git-svn

* git://git.bogomips.org/git-svn:
  git-svn: added an --include-path flag
  Git::SVN::*: add missing "NAME" section to perldoc
  git-svn: avoid self-referencing mergeinfo

Makefile: fix default regex settings on Darwin

t0070-fundamental.sh fails on Mac OS X 10.8:

$ uname -a
Darwin lustrous 12.2.0 Darwin Kernel Version 12.2.0:
Sat Aug 25 00:48:52 PDT 2012;
root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64

$ ./t0070-fundamental.sh -v
fatal: regex bug confirmed: re-build git with NO_REGEX=1

Fix it by using Git's regex library.

Reviewed-by: Jonathan Nieder <redacted>
Signed-off-by: David Aguilar <redacted>
Signed-off-by: Junio C Hamano <redacted>

clone: let the user know when check_everything_connected is run

check_everything_connected could take a long time, especially in the
clone case where the whole DAG is traversed. The user deserves to know
what's going on.

Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
Signed-off-by: Junio C Hamano <redacted>

gitk: Add menu item for reverting commits

Sometimes it's helpful (at least psychologically) to have this feature
easily accessible.  Code borrows heavily from cherrypick.

Signed-off-by: Knut Franke <redacted>
Signed-off-by: Paul Mackerras <redacted>

gitk: Simplify file filtering

git diff is perfectly able to do this with '-- files', no need for
manual filtering.  This makes gettreediffs consistent with getblobdiffs.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Paul Mackerras <redacted>

gitk: Display the date of a tag in a human-friendly way

By selecting a tag within gitk you can display information about it.
This information is output by using the command

 'git cat-file tag <tagid>'

This outputs the *raw* information from the tag, amongst which is the
time - in seconds since the epoch. As useful as that value is, I find it
a lot easier to read and process time which it is something like:

 "Mon Dec 31 14:26:11 2012 -0800"

This change will modify the display of tags in gitk like so:

  @@ -1,7 +1,7 @@
   object 5d417842efeafb6e109db7574196901c4e95d273
   type commit
   tag v1.8.1
  -tagger Junio C Hamano <redacted> 1356992771 -0800
  +tagger Junio C Hamano <redacted> Mon Dec 31 14:26:11 2012 -0800

   Git 1.8.1
   -----BEGIN PGP SIGNATURE-----

Signed-off-by: Anand Kumria <redacted>
Signed-off-by: Paul Mackerras <redacted>

gitk: Improve behaviour of drop-down lists

The drop-down lists used for things like the criteria for finding
commits (containing/touching paths/etc.) use a combobox if we are
using the ttk widgets.  By default the combobox exports its value
as the selection when it is changed, which is unnecessary, and sometimes
the combobox wouldn't release the selection, which is annoying.

To fix this, we make these comboboxes not export their selection,
and also clear their selection whenever they are changed.  This makes
them more like a simple selection of alternatives, improving the look
and feel of gitk.

Signed-off-by: Paul Mackerras <redacted>

transport-helper: fix remote helper namespace regression

Commit 664059f (transport-helper: update remote helper namespace)
updates the namespace when the push succeeds or not; we should do it
only when it succeeded.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

CodingGuidelines: Documentation/*.txt are the sources

People not familiar with AsciiDoc may not realize they are
supposed to update *.txt files and not *.html/*.1 files when
preparing patches to the project.

Signed-off-by: Dale Worley <redacted>
Signed-off-by: Junio C Hamano <redacted>

grep: honor --textconv for the case rev:path

Make "grep" honor the "--textconv" option also for the object case, i.e.
when used with an argument "rev:path".

Signed-off-by: Michael J Gruber <redacted>
Signed-off-by: Junio C Hamano <redacted>

grep: allow to use textconv filters

Recently and not so recently, we made sure that log/grep type operations
use textconv filters when a userfacing diff would do the same:

ef90ab6 (pickaxe: use textconv for -S counting, 2012-10-28)
b1c2f57 (diff_grep: use textconv buffers for add/deleted files, 2012-10-28)
0508fe5 (combine-diff: respect textconv attributes, 2011-05-23)

"git grep" currently does not use textconv filters at all, that is
neither for displaying the match and context nor for the actual grepping,
even when requested by --textconv.

Introduce an option "--textconv" which makes git grep use any configured
textconv filters for grepping and output purposes. It is off by default.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Michael J Gruber <redacted>
Signed-off-by: Junio C Hamano <redacted>

t7008: demonstrate behavior of grep with textconv

Currently, "git grep" does not honor any textconv filters, with nor
without --textconv. Demonstrate this in the tests.

The default is expected to remain unchanged.

Signed-off-by: Michael J Gruber <redacted>
Signed-off-by: Junio C Hamano <redacted>

cat-file: do not die on --textconv without textconv filters

When a command is supposed to use textconv filters (by default or with
"--textconv") and none are configured then the blob is output without
conversion; the only exception to this rule is "cat-file --textconv".

Make it behave like the rest of textconv aware commands.

Signed-off-by: Michael J Gruber <redacted>
Signed-off-by: Junio C Hamano <redacted>

show: honor --textconv for blobs

Currently, "diff" and "cat-file" for blobs honor "--textconv" options
(with the former defaulting to "--textconv" and the latter to
"--no-textconv") whereas "show" does not honor this option, even though
it takes diff options.

Make "show" on blobs honor "--textconv" when it is asked.  The default
is not to apply textconv, which is in line with what "cat-file" does.

Signed-off-by: Michael J Gruber <redacted>
Signed-off-by: Junio C Hamano <redacted>

diff_opt: track whether flags have been set explicitly

The diff_opt infrastructure sets flags based on defaults and command
line options.  It is impossible to tell whether a flag has been set
as a default or on explicit request.  Update the structure so that
this detection is possible:

 * Add an extra "opt->touched_flags" that keeps track of all the
   fields that have been touched by DIFF_OPT_SET and DIFF_OPT_CLR.

 * You may continue setting the default values to the flags, like
   commands in the "log" family do in cmd_log_init_defaults(), but
   after you finished setting the defaults, you clear the
   touched_flags field;

 * And then you let the usual callchain call diff_opt_parse(),
   allowing the opt->flags be set or unset, while keeping track of
   which bits the user touched;

 * There is an optional callback "opt->set_default" that is called
   at the very beginning to let you inspect touched_flags and update
   opt->flags appropriately, before the remainder of the diffcore
   machinery is set up, taking the opt->flags value into account.

Signed-off-by: Michael J Gruber <redacted>
Signed-off-by: Junio C Hamano <redacted>

t4030: demonstrate behavior of show with textconv

"git show <commit>" honors the --textconv option while "git show <blob>"
does not. Demonstrate this in the test.

Since the current behavior is supposed to stay as is, we expect the
default for "git show <blob>" to remain --no-textconv.

Signed-off-by: Michael J Gruber <redacted>
Signed-off-by: Junio C Hamano <redacted>

test: remote-helper: add missing and

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

Sync with v1.8.2.3

* maint:
  Git 1.8.2.3
  t5004: avoid using tar for checking emptiness of archive
  t5004: ignore pax global header file
  mergetools/kdiff3: do not use --auto when diffing
  transport-helper: trivial style cleanup

Git 1.8.2.3

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'mv/sequencer-pick-error-diag'

Fix "git cherry-pick $annotated_tag", which was mistakenly rejected.

* mv/sequencer-pick-error-diag:
  cherry-pick: picking a tag that resolves to a commit is OK

cherry-pick: picking a tag that resolves to a commit is OK

Earlier, 21246dbb9e0a (cherry-pick: make sure all input objects are
commits, 2013-04-11) tried to catch an unlikely "git cherry-pick $blob"
as an error, but broke a more important use case to cherry-pick a
tag that points at a commit.

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'tr/copy-revisions-from-stdin' into maint

* tr/copy-revisions-from-stdin:
  read_revisions_from_stdin: make copies for handle_revision_arg

t5004: avoid using tar for checking emptiness of archive

Test 2 of t5004 checks if a supposedly empty tar archive really
contains no files.  24676f02 (t5004: fix issue with empty archive test
and bsdtar) removed our commit hash to make it work with bsdtar, but
the test still fails on NetBSD and OpenBSD, which use their own tar
that considers a tar file containing only NULs as broken.

Here's what the different archivers do when asked to create a tar
file without entries:

$ uname -v
NetBSD 6.0.1 (GENERIC)
$ gtar --version | head -1
tar (GNU tar) 1.26
$ bsdtar --version
bsdtar 2.8.4 - libarchive 2.8.4

$ : >zero.tar
$ perl -e 'print "\0" x 10240' >tenk.tar
$ sha1 zero.tar tenk.tar
SHA1 (zero.tar) = da39a3ee5e6b4b0d3255bfef95601890afd80709
SHA1 (tenk.tar) = 34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c

$ : | tar cf - -T - | sha1
da39a3ee5e6b4b0d3255bfef95601890afd80709
$ : | gtar cf - -T - | sha1
34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c
$ : | bsdtar cf - -T - | sha1
34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c

So NetBSD's native tar creates an empty file, while GNU tar and bsdtar
both give us 10KB of NULs -- just like git archive with an empty tree.
Now let's see how the archivers handle these two kinds of empty tar
files:

$ tar tf zero.tar; echo $?
tar: Unexpected EOF on archive file
1
$ gtar tf zero.tar; echo $?
gtar: This does not look like a tar archive
gtar: Exiting with failure status due to previous errors
2
$ bsdtar tf zero.tar; echo $?
0

$ tar tf tenk.tar; echo $?
tar: Cannot identify format. Searching...
tar: End of archive volume 1 reached
tar: Sorry, unable to determine archive format.
1
$ gtar tf tenk.tar; echo $?
0
$ bsdtar tf tenk.tar; echo $?
0

NetBSD's tar complains about both, bsdtar happily accepts any of them
and GNU tar doesn't like zero-length archive files.  So the safest
course of action is to stay with our block-of-NULs format which is
compatible with GNU tar and bsdtar, as we can't make NetBSD's native
tar happy anyway.

We can simplify our test, however, by taking tar out of the picture.
Instead of extracting the archive and checking for the non-presence of
files, check if the file has a size of 10KB and contains only NULs.
This makes t5004 pass on NetBSD and OpenBSD.

Signed-off-by: Rene Scharfe <redacted>
Signed-off-by: Junio C Hamano <redacted>

t5004: resurrect original empty tar archive test

Add a test to verify the emptiness of an archive by extracting its
contents.  Don't run this test if the version of tar doesn't support
archives containing only a comment header, though.

The existing check 'tar archive of empty tree is empty' used to work
like that (minus the tar capability check) but was changed to depend
on the exact representation of empty tar files created by git archive
instead of on the behaviour of tar in order to avoid issues with
different tar versions.

The different approaches test different things: The existing one is
for empty trees, for which we know the exact expected output and thus
we can simply check it without extracting; the new one is for commits
with empty trees, whose archives include stamps and so the more
"natural" check by extraction is a better fit because it focuses on
the interesting aspect, namely the absence of any archive entries.

Signed-off-by: Rene Scharfe <redacted>
Signed-off-by: Junio C Hamano <redacted>

t5004: avoid using tar for checking emptiness of archive

Test 2 of t5004 checks if a supposedly empty tar archive really
contains no files.  24676f02 (t5004: fix issue with empty archive test
and bsdtar) removed our commit hash to make it work with bsdtar, but
the test still fails on NetBSD and OpenBSD, which use their own tar
that considers a tar file containing only NULs as broken.

Here's what the different archivers do when asked to create a tar
file without entries:

$ uname -v
NetBSD 6.0.1 (GENERIC)
$ gtar --version | head -1
tar (GNU tar) 1.26
$ bsdtar --version
bsdtar 2.8.4 - libarchive 2.8.4

$ : >zero.tar
$ perl -e 'print "\0" x 10240' >tenk.tar
$ sha1 zero.tar tenk.tar
SHA1 (zero.tar) = da39a3ee5e6b4b0d3255bfef95601890afd80709
SHA1 (tenk.tar) = 34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c

$ : | tar cf - -T - | sha1
da39a3ee5e6b4b0d3255bfef95601890afd80709
$ : | gtar cf - -T - | sha1
34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c
$ : | bsdtar cf - -T - | sha1
34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c

So NetBSD's native tar creates an empty file, while GNU tar and bsdtar
both give us 10KB of NULs -- just like git archive with an empty tree.
Now let's see how the archivers handle these two kinds of empty tar
files:

$ tar tf zero.tar; echo $?
tar: Unexpected EOF on archive file
1
$ gtar tf zero.tar; echo $?
gtar: This does not look like a tar archive
gtar: Exiting with failure status due to previous errors
2
$ bsdtar tf zero.tar; echo $?
0

$ tar tf tenk.tar; echo $?
tar: Cannot identify format. Searching...
tar: End of archive volume 1 reached
tar: Sorry, unable to determine archive format.
$ gtar tf tenk.tar; echo $?
0
$ bsdtar tf tenk.tar; echo $?
0

NetBSD's tar complains about both, bsdtar happily accepts any of them
and GNU tar doesn't like zero-length archive files.  So the safest
course of action is to stay with our block-of-NULs format which is
compatible with GNU tar and bsdtar, as we can't make NetBSD's native
tar happy anyway.

We can simplify our test, however, by taking tar out of the picture.
Instead of extracting the archive and checking for the non-presence of
files, check if the file has a size of 10KB and contains only NULs.
This makes t5004 pass on NetBSD and OpenBSD.

Signed-off-by: Rene Scharfe <redacted>
Signed-off-by: Junio C Hamano <redacted>

t5004: ignore pax global header file

Versions of tar that don't know pax headers -- like the ones in NetBSD 6
and OpenBSD 5.2 -- extract them as regular files.  Explicitly ignore the
file created for our global header when checking the list of extracted
files, as this is normal and harmless fall-back behaviour.  This fixes
test 3 of t5004 on these platforms.

Signed-off-by: Rene Scharfe <redacted>
Signed-off-by: Junio C Hamano <redacted>

mergetools/kdiff3: do not use --auto when diffing

The `kdiff3 --auto` help message is, "No GUI if all conflicts are auto-
solvable."  This flag was carried over from the original mergetool
commands.  diff_cmd() is for two-way comparisons only so remove the
superfluous flag.

Signed-off-by: David Aguilar <redacted>
Signed-off-by: Junio C Hamano <redacted>

transport-helper: trivial style cleanup

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-svn: added an --include-path flag

The SVN::Fetcher module is now able to filter for inclusion as well
as exclusion (as used by --ignore-path). Also added tests, documentation
changes and git completion script.

If you have an SVN repository with many top level directories and you
only want a git-svn clone of some of them then using --ignore-path is
difficult as it requires a very long regexp. In this case it's much
easier to filter for inclusion.

[ew: remove trailing whitespace]

Signed-off-by: Paul Walmsley <redacted>
Signed-off-by: Eric Wong <redacted>

Git::SVN::*: add missing "NAME" section to perldoc

lexgrog(1) relies on the NAME section to find a manpage's subject's
name and description for easy access later using "man -k".  Add the
section it expects.

Noticed using lintian.

Signed-off-by: Jonathan Nieder <redacted>
Signed-off-by: Eric Wong <redacted>

git-svn: avoid self-referencing mergeinfo

When svn.pushmergeinfo is set, the target branch is included in the
mergeinfo if it was previously merged into one of the source branches.
SVN does not do this.

Remove merge target branch path from resulting mergeinfo when
svn.pushmergeinfo is set to better match the behavior of SVN. Update the
svn-mergeinfo-push test.

[ew: 80 columns]

Signed-off-by: Michael Contreras <redacted>
Reported-by: Avishay Lavie <redacted>
Acked-by: Eric Wong <redacted>

merge: use help_unknown_ref()

Use help.c:help_unknown_ref() instead of die() to provide a
friendlier error message before exiting, when one of the refs
specified in a merge is unknown.

Signed-off-by: Vikrant Varma <redacted>
Signed-off-by: Junio C Hamano <redacted>

help: add help_unknown_ref()

When the user gives an unknown string to a command that expects to
get a ref, we could be more helpful than just saying "that's not a
ref" and die.

Add helper function help_unknown_ref() to take care of displaying an
error message along with a list of suggested refs the user might
have meant.  An interaction with "git merge" might go like this:

$ git merge foo
merge: foo - not something we can merge

Did you mean one of these?
    origin/foo
    upstream/foo

Signed-off-by: Vikrant Varma <redacted>
Signed-off-by: Junio C Hamano <redacted>

cygwin: Remove the CYGWIN_V15_WIN32API build variable

Commit 380a4d92 ("Update cygwin.c for new mingw-64 win32 api headers",
11-11-2012) solved an header include order problem on cygwin 1.7 when
using the new mingw-64 WIN32 API headers. The solution involved using
a new build variable (V15_MINGW_HEADERS) to conditionally compile the
cygwin.c source file to use an include order appropriate for the old
and new header files. (The build variable was later renamed in commit
9fca6cff to CYGWIN_V15_WIN32API).

The include order used for cygwin 1.7 includes the "win32.h" header
before "../git-compat-util.h". This order was problematic on cygwin
1.5, since it lead to the WIN32 symbol being defined along with the
inclusion of some WIN32 API headers (e.g. <winsock2.h>) which cause
compilation errors.

The header include order problem on cygwin 1.5 has since been fixed
(see commit "mingw: rename WIN32 cpp macro to GIT_WINDOWS_NATIVE"),
so we can now remove the conditional compilation along with the
associated CYGWIN_V15_WIN32API build variable.

Signed-off-by: Ramsay Jones <redacted>
Signed-off-by: Junio C Hamano <redacted>