Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

* jc/squash:
  git-merge --squash

* jc/diff:
  diff --color: use $GIT_DIR/config

* ml/cvsimport:
  cvsimport: always set $ENV{GIT_INDEX_FILE} to $index{$branch}
  cvsimport: setup indexes correctly for ancestors and incremental imports

* js/diff:
  Teach diff about -b and -w flags

* ew/rebase:
  rebase: allow --skip to work with --merge
  rebase: cleanup rebasing with --merge
  rebase: allow --merge option to handle patches merged upstream

pkt-line.h uses GCC's __attribute__ extension but does not include
git-compat-util.h.  So it will not compile with a compiler that does
not support this extension.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Currently the compilation fails in connect.c and merge-index.c
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

This lets you use something like this in your $GIT_DIR/config
file.

	[diff]
		color = auto

	[diff.color]
		new = blue
		old = yellow
		frag = reverse

When diff.color is set to "auto", colored diff is enabled when
the standard output is the terminal.  Other choices are "always",
and "never".  Usual boolean true/false can also be used.

The colormap entries can specify colors for the following slots:

	plain	- lines that appear in both old and new file (context)
	meta	- diff --git header and extended git diff headers
	frag	- @@ -n,m +l,k @@ lines (hunk header)
	old	- lines deleted from old file
	new	- lines added to new file

The following color names can be used:

	normal, bold, dim, l, blink, reverse, reset,
	black, red, green, yellow, blue, magenta, cyan,
	white
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Now that we control the merge base selection, we won't be forced
into rolling things in that we wanted to skip beforehand.

Also, add a test to ensure this all works as intended.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We no longer have to recommit each patch to remove the parent
information we're rebasing since we're using the low-level merge
strategies directly instead of git-merge.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Enhance t3401-rebase-partial to test with --merge as well as
the standard am -3 strategy.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The current behaviour strips out lines starting with a # even when fed
through stdin or -m.  This is particularly bad when importing history from
another SCM (tailor 0.9.23 uses git-commit).  In the best cases all lines
are stripped and the commit fails with a confusing "empty log message"
error, but in many cases the commit is done, with loss of information.

Note that it is quite peculiar to just have "#" handled as a leading
comment char here.  One commonly meet CVS: or CG: or STG: as prefixes, and
using GIT: would be more robust as well as consistent with other commit
tools.  However, that would break any tool relying on the # (if any).
Signed-off-by: NYann Dirson <ydirson@altern.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This cleans up the use of safe_strncpy() even more.  Since it has the
same semantics as strlcpy() use this name instead.  Also move the
definition from inside path.c to its own file compat/strlcpy.c, and use
it conditionally at compile time, since some platforms already has
strlcpy().  It's included in the same way as compat/setenv.c.
Signed-off-by: NPeter Eriksen <s022018@student.dtu.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

It does not make much sense to build git whose behaviour is
different depending on the brokenness of diff implementation of
the platform because the brokenness of the patch that is applied
with the tool depends on brokenness of the diff the person who
generates the patch uses.  So we do not use NO_ACCURATE_DIFF
anymore, but help people to apply patches that do not record
incomplete lines correctly with a runtime flag.
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NTimo Hirvonen <tihirvon@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Also, make sure that the initial git-read-tree is performed.
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>

Two bugs had slipped in the "keep one index per branch during import"
patch. Both incremental imports and new branches would see an
empty tree for their initial commit. Now we cover all the relevant
cases, checking whether we actually need to setup the index before
preparing the actual commit, and doing it.
Signed-off-by: NMartin Langhoff <martin@catalyst.net.nz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When a bool variable appears without any value, it means true.
However, replacing the NULL value with an empty string, an earlier
commit f067a137 broke show-config.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

git-repack was passing the -q along to pack-objects but ignoring it
itself. Correct the oversight.
Signed-off-by: NMartin Langhoff <martin@catalyst.net.nz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Some people tend to do many little commits on a topic branch,
recording all the trials and errors, and when the topic is
reasonably cooked well, would want to record the net effect of
the series as one commit on top of the mainline, removing the
cruft from the history.  The topic is then abandoned or forked
off again from that point at the mainline.

The barebone porcelainish that comes with core git tools does
not officially support such operation, but you can fake it by
using "git pull --no-merge" when such a topic branch is not a
strict superset of the mainline, like this:

	git checkout mainline
	git pull --no-commit . that-topic-branch
	: fix conflicts if any
	rm -f .git/MERGE_HEAD
        git commit -a -m 'consolidated commit log message'
	git branch -f that-topic-branch ;# now fully merged

This however does not work when the topic branch is a fast
forward of the mainline, because normal "git pull" will never
create a merge commit in such a case, and there is nothing
special --no-commit could do to begin with.

This patch introduces a new option, --squash, to support such a
workflow officially in both fast-forward case and true merge
case.  The user-level operation would be the same in both cases:

	git checkout mainline
        git pull --squash . that-topic-branch
        : fix conflicts if any -- naturally, there would be
        : no conflict if fast forward.
	git commit -a -m  'consolidated commit log message'
	git branch -f that-topic-branch ;# now fully merged

When the current branch is already up-to-date with respect to
the other branch, there truly is nothing to do, so the new
option does not have any effect.

This was brought up in #git IRC channel recently.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

* pb/error:
  usage: minimum type fix.
  Customizable error handlers
  git-merge: Don't use -p when outputting summary
  git-commit: allow -e option anywhere on command line
  patch-id: take "commit" prefix as well as "diff-tree" prefix

Signed-off-by: NJunio C Hamano <junkio@cox.net>

This patch makes the usage(), die() and error() handlers customizable.
Nothing in the git code itself uses that but many other libgit users
(like Git.pm) will.

This is implemented using the mutator functions primarily because you
cannot directly modifying global variables of libgit from a program that
dlopen()ed it, apparently. But having functions for that is a better API
anyway.
Signed-off-by: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

-p is not needed and we only want diffstat and summary.
Signed-off-by: NTimo Hirvonen <tihirvon@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This adds -b (--ignore-space-change) and -w (--ignore-all-space) flags to
diff. The main part of the patch is teaching libxdiff about it.

[jc: renamed xdl_line_match() to xdl_recmatch() since the former is used
 for different purposes in xpatchi.c which is in the parts of the upstream
 source we do not use.]
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Previously, the command 'git-commit -e -m foo' would ignore the '-e' option
because the '-m' option overwrites the no_edit flag during sequential
option parsing. Now we cause -e to reset the no_edit flag after all
options are parsed.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Some time ago we changed git-log in a massive way, and one consequence is
that the keyword changed. Adjust patch-id for that.

[jc: as Linus suggests, allowing both old and new prefix.]
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NMatthias Kestenholz <matthias@spinlock.ch>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This patch does:

 - always reset the color _before_ printing out the newline.

   This is actually important. You (and Johannes) didn't see it, because
   it only matters if you set the background, but if you don't do this,
   you get some random and funky behaviour if you pick a color with a
   non-default background (which still potentially has problems with tabs
   etc, but less so).

 - allow people to have a different color for the "file headers"
   (DIFF_METAINFO) and for the "fragment header" (DIFF_FRAGINFO). Also,
   make a difference between "normal color" and "reset colors"

 - default to red/green for old/new lines. That's the norm, I'd think.

 - instead of that eye-popping (and eye-ball-with-a-fondue-fork-popping)
   purple color for metadata, use bold-face for file headers, and cyan for
   the frag headers. I actually prefer the "gray background" for that, but
   it only works well in xterms, so COLOR_CYAN it is..
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* master:
  git-svn: fix commit --edit flag when using SVN:: libraries
  Makefile: do not force unneeded recompilation upon GIT_VERSION changes
  Check and document the options to prevent mistakes.
  Pass -DDEFAULT_GIT_TEMPLATE_DIR only where actually used.

* js/lsfix:
  Initialize lock_file struct to all zero.
  Make git-update-ref a builtin
  Make git-update-index a builtin
  Make git-stripspace a builtin
  Make git-mailinfo a builtin
  Make git-mailsplit a builtin
  Make git-write-tree a builtin

* ew/rebase:
  rebase --merge: fix for rebasing more than 7 commits.
  rebase: error out for NO_PYTHON if they use recursive merge
  Add renaming-rebase test.
  rebase: Allow merge strategies to be used when rebasing

* jn/web:
  gitweb: whitespace cleanup around '='
  gitweb: Use $hash_base as $search_hash if possible
  gitweb: Make use of $PATH_INFO for project parameter
  Move $gitbin earlier in gitweb.cgi
  Add git version to gitweb output
  gitweb: whitespace cleanup
  gitweb: style done with stylesheet
  gitweb: A couple of page title tweaking
  Fix: Support for the standard mime.types map in gitweb
  gitweb: add type="text/css" to stylesheet link
  Make CSS file gitweb/gitweb.css more readable
  Fix gitweb stylesheet
  Support for the standard mime.types map in gitweb
  gitweb: text files for 'blob_plain' action without charset by default
  gitweb: safely output binary files for 'blob_plain' action
  Move gitweb style to gitweb.css