The patch detection wants to inspect all the headers of a rfc2822 message
and ensure that they look like header fields. The headers are always
separated from the message body with a blank line. When Thunderbird saves
the message the blank line separating the headers from the body includes a
CR. The patch detection is failing because a CRLF doesn't match /^$/. Fix
this by allowing a CR to exist on the separating line.
Signed-off-by: NStephen Boyd <bebarino@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We shouldn't have literal CR's in tests as they aren't portable.
Signed-off-by: NStephen Boyd <bebarino@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

append_cr(), remove_cr(), q_to_nul() and q_to_cr() are defined in multiple
tests. Consolidate them into test-lib.sh so we can stop redefining them.
The use of remove_cr() in t0020 to test for a CR is replaced with a new
function has_cr() to accurately reflect what is intended (the output of
remove_cr() was being thrown away).
Signed-off-by: NStephen Boyd <bebarino@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

Don't feed a multiple-line pattern to grep and expect the them to match
with lines in order.

Simplify the grep expressions in the non-fast-forward tests to check
only for the first line of the non-fast-forward warning - having that
line should be enough assurance that the full warning is printed.
Signed-off-by: NTay Ray Chuan <rctay89@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Use the modern form of printing a commit subject instead of piping
the output of rev-list to sed.
Signed-off-by: NStephen Boyd <bebarino@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Add test-run-command to .gitignore so it does not pollute
git status output.
Signed-off-by: NAlejandro Riveira Fernández <ariveira@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This is a followup to ac0ba18d (run-command: convert simple callsites to
use_shell, 2009-12-30), for consistency.
Signed-off-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In Internet Explorer 8 (IE8) the 'blame_incremental' view, which uses
JavaScript to generate blame info using AJAX, sometimes hang at the
beginning (at 0%) of blaming, e.g. for larger files with long history
like git's own gitweb/gitweb.perl.

The error shown by JavaScript console is "Unspecified error" at char:2
of the following line in gitweb/gitweb.js:

  if (xhr.readyState === 3 && xhr.status !== 200) {

Debugging it using IE8 JScript debuger shown that the error occurs
when trying to access xhr.status (xhr is XMLHttpRequest object).
Watch for xhr object shows 'Unspecified error.' as "value" of
xhr.status, and trying to access xhr.status from console throws error.

This bug is some intermittent bug, depending on XMLHttpRequest timing,
as it doesn't occur in all cases.  It is probably caused by the fact
that handleResponse is called from timer (pollTimer), to work around
the fact that some browsers call onreadystatechange handler only once
for each state change, and not like required for 'blame_incremental'
as soon as new data is available from server.  It looks like xhr
object is not properly initialized; still it is a bug to throw an
error when accessing xhr.status (and not use 'null' or 'undefined' as
value).

Work around this bug in IE8 by using try-catch block when accessing
xhr.status.
Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* jc/fix-tree-walk:
  read-tree --debug-unpack
  unpack-trees.c: look ahead in the index
  unpack-trees.c: prepare for looking ahead in the index
  Aggressive three-way merge: fix D/F case
  traverse_trees(): handle D/F conflict case sanely
  more D/F conflict tests
  tests: move convenience regexp to match object names to test-lib.sh

Conflicts:
	builtin-read-tree.c
	unpack-trees.c
	unpack-trees.h

Signed-off-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint:
  git-gui: work from the .git dir
  git-gui: Fix applying a line when all following lines are deletions
  git-gui: Correct file_states when unstaging partly staged entry
  git-gui: Fix gitk for branch whose name matches local file
  git-gui: Keep repo_config(gui.recentrepos) and .gitconfig in sync
  git-gui: handle really long error messages in updateindex.
  git-gui: Add hotkeys for "Unstage from commit" and "Revert changes"
  git-gui: Makefile: consolidate .FORCE-* targets

* 'maint' of git://git.spearce.org/git-gui:
  git-gui: work from the .git dir
  git-gui: Fix applying a line when all following lines are deletions
  git-gui: Correct file_states when unstaging partly staged entry
  git-gui: Fix gitk for branch whose name matches local file
  git-gui: Keep repo_config(gui.recentrepos) and .gitconfig in sync
  git-gui: handle really long error messages in updateindex.
  git-gui: Add hotkeys for "Unstage from commit" and "Revert changes"
  git-gui: Makefile: consolidate .FORCE-* targets

Commit 44626dc7 (MSVC: Windows-native implementation for subset
of threads API, 2010-01-15) introduces builtin replacement of
pthreadGC2.dll functionality, thus we can completely drop
dependency on this dll.
Signed-off-by: NMichael Lukashov <michael.lukashov@gmail.com>
Acked-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

e9fcd1e2 (Add push --set-upstream, 2010-01-16) inadvertently patched
the description of --upstream in the middle of that of --repo.
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

bed575e4 (commit: support commit.status, --status, and --no-status,
2009-12-07) forgot to add the :: that sets off an item from the
paragraph that explains it, breaking the layout.
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* 'doc-style/for-next' of git://repo.or.cz/git/trast:
  Documentation: merge: use MERGE_HEAD to refer to the remote branch
  Documentation: simplify How Merge Works
  Documentation: merge: add a section about fast-forward
  Documentation: emphasize when git merge terminates early
  Documentation: merge: add an overview
  Documentation: merge: move merge strategy list to end
  Documentation: suggest `reset --merge` in How Merge Works section
  Documentation: merge: move configuration section to end
  Documentation: emphasise 'git shortlog' in its synopsis
  Documentation: show-files is now called git-ls-files
  Documentation: tiny git config manual tweaks
  Documentation: git gc packs refs by default now

Conflicts:
	Documentation/config.txt

14e5d40c (pull: Fix parsing of -X<option>, 2010-01-17) forgot that
merge_name needs to stay as a single non-interpolated string.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

commit 57bddb11 (Documentation/git-merge: reword references to
"remote" and "pull", 2010-01-07) fixed the manual to drop the
assumption that the other branch being merged is from a remote
repository.  Unfortunately, in a few places, to do so it
introduced the antecedentless phrase "their versions".  Worse, in
passages like the following, 'they' is playing two roles.

|   highlighting changes from both the HEAD and their versions.
|
| * Look at the diffs on their own. 'git log --merge -p <path>'

Using HEAD and MERGE_HEAD nicely assigns terminology to "our" and
"their" sides.  It also provides the reader with practice using
names that git will recognize on the command line.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NThomas Rast <trast@student.ethz.ch>

The user most likely does not care about the exact order of
operations because he cannot see it happening anyway.  Instead,
try to explain what it means to merge two commits into a single
tree.

While at it:

 - Change the heading to TRUE MERGE.  The entire manual page is
   about how merges work.

 - Document MERGE_HEAD.  It is a useful feature, since it makes
   the parents of the intended merge commit easier to refer to.

 - Do not assume commits named on the 'git merge' command line come
   from another repository.  For simplicity, the discussion of
   conflicts still does assume that there is only one and it is a
   branch head.

 - Do not start list items with `code`.  Otherwise, a toolchain bug
   produces a line break in the generated nroff, resulting in odd
   extra space.
Suggested-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NThomas Rast <trast@student.ethz.ch>

Novices sometimes find the behavior of 'git merge' in the
fast-forward case surprising.  Describe it thoroughly.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NThomas Rast <trast@student.ethz.ch>

A merge-based operation in git can fail in two ways: one that
stops before touching anything, or one that goes ahead and
results in conflicts.

As the 'git merge' manual explains:

| A merge is always between the current `HEAD` and one or more
| commits (usually, branch head or tag), and the index file must
| match the tree of `HEAD` commit (i.e. the contents of the last commit)
| when it starts out.

Unfortunately, the placement of this sentence makes it easy to
skip over, and its formulation leaves the important point, that
any other attempted merge will be gracefully aborted, unspoken.

So give this point its own section and expand upon it.

Probably this could be simplified somewhat: after all, a change
registered in the index is just a special kind of local
uncommited change, so the second added paragraph is only a
special case of the first.  It seemed more helpful to be explicit
here.

Inspired by <http://gitster.livejournal.com/25801.html>.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NThomas Rast <trast@student.ethz.ch>

The reader unfamiliar with the concepts of branching and merging
would have been completely lost.  Try to help him with a diagram.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NThomas Rast <trast@student.ethz.ch>

So the section layout changes as follows:

 NAME
 SYNOPSIS
 DESCRIPTION
 OPTIONS
-MERGE STRATEGIES
 HOW MERGE WORKS
 HOW CONFLICTS ARE PRESENTED
 HOW TO RESOLVE CONFLICTS
 EXAMPLES
+MERGE STRATEGIES
 CONFIGURATION
 SEE ALSO
 AUTHOR
 DOCUMENTATION
 GIT
 NOTES

The first-time user will care more about conflicts than about
strategies other than 'recursive'.

One of the examples uses -s ours, but I do not think this hinders
readability.
Suggested-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NThomas Rast <trast@student.ethz.ch>

The 'merge' manual suggests 'reset' to cancel a merge at the end
of the Merge Strategies list.  It is more logical to explain this
right before explaining how merge conflicts work, so the daunted
reader can have a way out when he or she needs it most.

While at it, make the advice more dependable and self-contained
by providing the --merge option.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NThomas Rast <trast@student.ethz.ch>

Configuration and environment variables belong to the back matter
of a manual page.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Acked-by: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NThomas Rast <trast@student.ethz.ch>

There is no point doing self-assignments of these variables.  Instead,
just export them to the environment, but do so in a sub-shell, because

	VAR1=VAL1 VAR2=VAL2 ... command arg1 arg2...

does not mark the variables exported if command that is run
is a shell function, according to POSIX.1.

The callers of do_with_author do not rely on seeing the effect of any
shell variable assignments that may happen inside what was called through
this shell function (currently "output" is the only one), so running it in
the subshell doesn't have an adverse semantic effect.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When git-gui is run from a .git dir, _gitdir would be set to "." by
rev-parse, something that confuses the worktree detection.

Fix by expanding the value of _gitdir to pwd in this special case.
Signed-off-by: NGiuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

If a diff looked like:

 @@
  context
 -del1
 -del2

and you wanted to stage the deletion 'del1', the generated patch
wouldn't apply because it was missing the line 'del2' converted to
context, but this line was counted in the @@-line
Signed-off-by: NJeff Epler <jepler@unpythonic.net>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

When unstaging a partly staged file or submodule, the file_states
list was not updated properly (unless unstaged linewise). Its
index_info part did not contain the former head_info as it should
have but kept its old value.

This seems not to have had any bad effects but diminishes the value
of the file_states list for future enhancements.
Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

When trying to run gitk on a branch name whose name matches a local
file, it will toss an error saying that the name is ambiguous. Adding
a pair of dashes will make gitk parse the options to the left of
it as branch names. Since wish eats the first pair of dashes we
throw at it, we need to add a second one to ensure they get through.
Signed-off-by: NPeter Krefting <peter@softwolves.pp.se>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

When the number of recent repo's gets to ten there can be a
situation where an item is removed from the .gitconfig file via
a call to git config --unset, but the internal representation of
that file (repo_config(gui.recentrepo)) is not updated.  Then a
subsequent attempt to remove an item from the list fails because
git-gui attempts to call --unset on a value that has already
been removed.  This leads to duplicates in the .gitconfig file,
which then also cause errors if the git-gui tries to --unset them
(rather than using --unset-all. --unset-all is not used because it
is not expected that duplicates should ever be allowed to exist.)

When loading the list of recent repositories (proc _get_recentrepos)
if a repo in the list is not considered a valid git reposoitory
then we should go ahead and remove it so it doesn't take up a slot
in the list (since we limit to 10 items). This will prevent a bunch
of invalid entries in the list (which are not shown) from making
valid entries dissapear off the list even when there are less than
ten valid entries.

See: http://code.google.com/p/msysgit/issues/detail?id=362Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

As reported to msysGit (bug #340) it is possible to get some very
long error messages when updating the index. The use of a label to
display this prevents scrolling the output. This patch replaces the
label with a scrollable text widget configured to look like a label.
Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* git://git.bogomips.org/git-svn:
  git-svn: allow subset of branches/tags to be specified in glob spec
  git-svn: allow UUID to be manually remapped via rewriteUUID
  git-svn: update svn mergeinfo test suite
  git-svn: document --username/commit-url for branch/tag
  git-svn: add --username/commit-url options for branch/tag
  git-svn: respect commiturl option for branch/tag
  git-svn: fix mismatched src/dst errors for branch/tag
  git-svn: handle merge-base failures
  git-svn: ignore changeless commits when checking for a cherry-pick

For very large projects it is useful to be able to clone a subset of the
upstream SVN repo's branches. Allow for this by letting the left-side of
the branches and tags glob specs contain a brace-delineated comma-separated
list of names. e.g.:

	branches = branches/{red,green}/src:refs/remotes/branches/*
Signed-off-by: NJay Soffian <jaysoffian@gmail.com>
Acked-by: NEric Wong <normalperson@yhbt.net>

In certain situations it may be necessary to manually remap an svn
repostitory UUID. For example:

                  o--- [git-svn clone]
                 /
[origin svn repo]
                 \
                  o--- [svnsync clone]

Imagine that only "git-svn clone" and "svnsync clone" are made available
to external users. Furthur, "git-svn clone" contains only trunk, and for
reasons unknown, "svnsync clone" is missing the revision properties that
normally provide the origin svn repo's UUID.

A git user who has cloned the "git-svn clone" repo now wishes to use
git-svn to pull in the missing branches from the "synsync clone" repo.
In order for git-svn to get the history correct for those branches,
it needs to know the origin svn repo's UUID. Hence rewriteUUID.
Signed-off-by: NJay Soffian <jaysoffian@gmail.com>
Acked-by: NEric Wong <normalperson@yhbt.net>

Add a partial branch (e.g., a branch from a project subdirectory) to the
git-svn mergeinfo test repository.

Add a tag and a branch from that tag to the git-svn mergeinfo test repository.

Update the test script to expect a known failure in git-svn exposed by these
additions where merge info for partial branches is not preserved.
Signed-off-by: NAndrew Myrick <amyrick@apple.com>
Acked-by: NEric Wong <normalperson@yhbt.net>

[ew: shortened subject]
Signed-off-by: NIgor Mironov <igor.a.mironov@gmail.com>
Acked-by: NEric Wong <normalperson@yhbt.net>

Add ability to specify on the command line the username to perform the
operation as and the writable URL of the repository to perform it on.

[ew: shortened subject]
Signed-off-by: NIgor Mironov <igor.a.mironov@gmail.com>
Acked-by: NEric Wong <normalperson@yhbt.net>