"git diff" has a --check option that can be used to check for whitespace
problems but it only reported by printing warnings to the
console.

Now when the --check option is used we give a non-zero exit status,
making "git diff --check" nicer to use in scripts and hooks.
Signed-off-by: NWincent Colaiuta <win@wincent.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

reverse_diff was a bit-value in disguise, it's merged in the flags now.
Signed-off-by: NPierre Habouzit <madcoder@debian.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

-n is not a short form of --no-index as the documentation
suggests.  Removing it from the documentation and command
usage string.
Signed-off-by: NAndrew Ruder <andy@aeruder.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This introduces a new command-line option: --exit-code. The diff
programs will return 1 for differences, return 0 for equality, and
something else for errors.
Signed-off-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When specifying an absolute path, or a relative path pointing outside
the working tree, do not fail, but roll your own diffopt parsing,
and execute a --no-index diff.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

With this flag and given two paths, git-diff-files behaves as a GNU diff
lookalike (plus the git goodies like --check, colour, etc.).  This flag
is also available in git-diff.  It also works outside of a git repository.

In addition, if git-diff{,-files} is called without revision or stage
parameter, and with exactly two paths at least one of which is not tracked,
the default is --no-index.

So, you can now say

	git diff /etc/inittab /etc/fstab

and it actually works!

This also unifies the duplicated argument parsing between cmd_diff_files()
and builtin_diff_files().
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

They used to open and read index themselves, but they now expect
their callers to do so.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This changes the calling convention of built-in commands and
passes the "prefix" (i.e. pathname of $PWD relative to the
project root level) down to them.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Any git command that expects to work in a subdirectory of a project, and
that reads the git config files (which is just about all of them) needs to
make sure that it does the "setup_git_directory()" call before it tries to
read the config file.

This means, among other things, that we need to move the call out of
"init_revisions()", and into the caller.

This does the mostly trivial conversion to do that.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

There currently is an unfortunate circular dependency between
what init_revisions (the command line revision specification
parser) does and setting up the log and diff options.  The
function uses setup_git_directory() to find the root of the
project relative to the current directory and calls diff_setup()
to prepare diff generation.  However, some of the things that
diff_setup() does needs to depend on the configuration variable,
which needs to be read after setup_git_directory() is called.

This patch is a low impact workaround.  It first lets
init_revisions() to run and do its thing, then uses git_config()
and diff_setup() after it returns, so that configuration
variables that affects the diff operation can be used from
subdirectories.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The Porcelainish has become so much usable as the UI that there
is not much reason people should be using the core programs by
hand anymore.  At this point we are better off making the
behaviour of the core programs predictable by keeping them
unaffected by the configuration variables.  Otherwise they will
become very hard to use as reliable building blocks.

For example, "git-commit -a" internally uses git-diff-files to
figure out the set of paths that need to be updated in the
index, and we should never allow diff.renames that happens to be
in the configuration to interfere (or slow down the process).

The UI level configuration such as showing renamed diff and
coloring are still honored by the Porcelainish ("git log" family
and "git diff"), but not by the core anymore.
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>

Initialize output_format to 0 instead of DIFF_FORMAT_RAW so that we can see
later if any command line options changed it.  Default value is set only if
output format was not specified.
Signed-off-by: NTimo Hirvonen <tihirvon@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We've had this notion of a "object_list" for a long time, which eventually
grew a "name" member because some users (notably git-rev-list) wanted to
name each object as it is generated.

That object_list is great for some things, but it isn't all that wonderful
for others, and the "name" member is generally not used by everybody.

This patch splits the users of the object_list array up into two: the
traditional list users, who want the list-like format, and who don't
actually use or want the name. And another class of users that really used
the list as an extensible array, and generally wanted to name the objects.

The patch is fairly straightforward, but it's also biggish. Most of it
really just cleans things up: switching the revision parsing and listing
over to the array makes things like the builtin-diff usage much simpler
(we now see exactly how many members the array has, and we don't get the
objects reversed from the order they were on the command line).

One of the main reasons for doing this at all is that the malloc overhead
of the simple object list was actually pretty high, and the array is just
a lot denser. So this patch brings down memory usage by git-rev-list by
just under 3% (on top of all the other memory use optimizations) on the
mozilla archive.

It does add more lines than it removes, and more importantly, it adds a
whole new infrastructure for maintaining lists of objects, but on the
other hand, the new dynamic array code is pretty obvious. The change to
builtin-diff-tree.c shows a fairly good example of why an array interface
is sometimes more natural, and just much simpler for everybody.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NPeter Eriksen <s022018@student.dtu.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This is the first installment to libify diff brothers.

The updated diff-files uses revision.c::setup_revisions()
infrastructure to parse its command line arguments, which means
the pathname arguments are checked more strictly than before.
The tests are adjusted to separate possibly missing paths from
the rest of arguments with double-dashes, to show the kosher
way.

As Linus pointed out, renaming diff.c to diff-lib.c was simply
stupid, so I am renaming it back.  The new diff-lib.c is to
contain pieces extracted from diff brothers.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

On Sun, 16 Apr 2006, Junio C Hamano wrote:
>
> In the mid-term, I am hoping we can drop the generate_header()
> callchain _and_ the custom code that formats commit log in-core,
> found in cmd_log_wc().

Ok, this was nastier than expected, just because the dependencies between
the different log-printing stuff were absolutely _everywhere_, but here's
a patch that does exactly that.

The patch is not very easy to read, and the "--patch-with-stat" thing is
still broken (it does not call the "show_log()" thing properly for
merges). That's not a new bug. In the new world order it _should_ do
something like

	if (rev->logopt)
		show_log(rev, rev->logopt, "---\n");

but it doesn't. I haven't looked at the --with-stat logic, so I left it
alone.

That said, this patch removes more lines than it adds, and in particular,
the "cmd_log_wc()" loop is now a very clean:

	while ((commit = get_revision(rev)) != NULL) {
		log_tree_commit(rev, commit);
		free(commit->buffer);
		commit->buffer = NULL;
	}

so it doesn't get much prettier than this. All the complexity is entirely
hidden in log-tree.c, and any code that needs to flush the log literally
just needs to do the "if (rev->logopt) show_log(...)" incantation.

I had to make the combined_diff() logic take a "struct rev_info" instead
of just a "struct diff_options", but that part is pretty clean.

This does change "git whatchanged" from using "diff-tree" as the commit
descriptor to "commit", and I changed one of the tests to reflect that new
reality. Otherwise everything still passes, and my other tests look fine
too.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Introduce tree-walk.[ch] and move "struct tree_desc" and
associated functions from various places.

Rename DIFF_FILE_CANON_MODE(mode) macro to canon_mode(mode) and
move it to cache.h.  This macro returns the canonicalized
st_mode value in the host byte order for files, symlinks and
directories -- to be compared with a tree_desc entry.
create_ce_mode(mode) in cache.h is similar but is intended to be
used for index entries (so it does not work for directories) and
returns the value in the network byte order.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The raw format "git-diff-files -c" to show unmerged state forgot
to initialize the status fields from parents, causing NUL
characters to be emitted.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This way, diff-files can make use of it.  Also implement the
full suite of what diff_flush_raw() supports just for
consistency.  With this, 'diff-tree -c -r --name-status' would
show what is expected.

There is no way to get the historical output (useful for
debugging and low-level Plumbing work) anymore, so tentatively
it makes '-m' to mean "do not combine and show individual diffs
with parents".

diff-files matches diff-tree to produce raw output for -c.  For
textual combined diff, use -p -c.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This adds "assume unchanged" logic, started by this message in the list
discussion recently:

	<Pine.LNX.4.64.0601311807470.7301@g5.osdl.org>

This is a workaround for filesystems that do not have lstat()
that is quick enough for the index mechanism to take advantage
of.  On the paths marked as "assumed to be unchanged", the user
needs to explicitly use update-index to register the object name
to be in the next commit.

You can use two new options to update-index to set and reset the
CE_VALID bit:

	git-update-index --assume-unchanged path...
	git-update-index --no-assume-unchanged path...

These forms manipulate only the CE_VALID bit; it does not change
the object name recorded in the index file.  Nor they add a new
entry to the index.

When the configuration variable "core.ignorestat = true" is set,
the index entries are marked with CE_VALID bit automatically
after:

 - update-index to explicitly register the current object name to the
   index file.

 - when update-index --refresh finds the path to be up-to-date.

 - when tools like read-tree -u and apply --index update the working
   tree file and register the current object name to the index file.

The flag is dropped upon read-tree that does not check out the index
entry.  This happens regardless of the core.ignorestat settings.

Index entries marked with CE_VALID bit are assumed to be
unchanged most of the time.  However, there are cases that
CE_VALID bit is ignored for the sake of safety and usability:

 - while "git-read-tree -m" or git-apply need to make sure
   that the paths involved in the merge do not have local
   modifications.  This sacrifices performance for safety.

 - when git-checkout-index -f -q -u -a tries to see if it needs
   to checkout the paths.  Otherwise you can never check
   anything out ;-).

 - when git-update-index --really-refresh (a new flag) tries to
   see if the index entry is up to date.  You can start with
   everything marked as CE_VALID and run this once to drop
   CE_VALID bit for paths that are modified.

Most notably, "update-index --refresh" honours CE_VALID and does
not actively stat, so after you modified a file in the working
tree, update-index --refresh would not notice until you tell the
index about it with "git-update-index path" or "git-update-index
--no-assume-unchanged path".

This version is not expected to be perfect.  I think diff
between index and/or tree and working files may need some
adjustment, and there probably needs other cases we should
automatically unmark paths that are marked to be CE_VALID.

But the basics seem to work, and ready to be tested by people
who asked for this feature.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

Now --always flag is available in diff-tree, there is no reason
to have that hack in the diffcore side.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The previous round forgot to make sure there actually are two
versions to compare against the working tree version.  Otherwise
using -c/--cc would not make much sense.

Also plug a small memory leak.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This ports the "combined diff" to diff-files so that differences
to the working tree files since stage 2 and stage 3 are shown
the same way as combined diff output from diff-tree for the
merge commit would be shown if the current working tree files
are committed.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

After thinking about it more, I realized that much of the change
I did on top of Linus' version does not make much sense.  This
commit reverts it so that it by default shows diffs with stage0
paths or stage2 paths with working tree; the unmerged stage to
use can be overridden with -1/-2/-3 option (-2 is the default so
essentially is a no-op).

When the index file is unmerged, we are by definition in the
middle of a conflicting merge, and we should show the diff with
stage 2 by default.  More importantly, paths without conflicts
are updated in the working tree and collapsed to stage0 in the
index, so showing diff with stage0 at the same time does not
hurt.  In normal cases, stage0 entries should be in sync with
the working tree files and does not clutter the output.  It even
helps the user to realize that the working tree has local
changes unrelated to the merge and remember to be careful not to
do a "git-commit -a" after resolving the conflicts.

When there is no unmerged entries, giving diff_unmerged_stage a
default value of 2 does not cause any harm, because it would not
be used anyway.  So in all, always showing diff between stage0
paths and unmerged entries from a stage (defaulting to 2) is the
right thing to do, as Linus originally did.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

While resolving conflicted merge, it was not easy to compare the
working tree file with unmerged index entries.  This commit
introduces new options -1/-2/-3 (with synonyms --base, --ours,
and --theirs) to compare working tree files with specified
stages.

When none of these options are given, the command defaults to -2
if the index file is unmerged, otherwise it acts as before.

[jc: majorly butchered from the version Linus originally posted.]
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Otherwise we would end up linking all the unneeded stuff into git-daemon
only to link with git_default_config.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

It adds "--" to the git-diff.sh scripts, to keep any filenames that start
with a "-" from being confused with an option.

But in order to do that, it needs to teach git-diff-files to honor "--".
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

With "[core] filemode = false", you can tell git to ignore
differences in the working tree file only in executable bit.

 * "git-update-index --refresh" does not say "needs update" if index
   entry and working tree file differs only in executable bit.

 * "git-update-index" on an existing path takes executable bit
   from the existing index entry, if the path and index entry are
   both regular files.

 * "git-diff-files" and "git-diff-index" without --cached flag
   pretend the path on the filesystem has the same executable
   bit as the existing index entry, if the path and index entry
   are both regular files.

If you are on a filesystem with unreliable mode bits, you may need to
force the executable bit after registering the path in the index.

 * "git-update-index --chmod=+x foo" flips the executable bit of the
   index file entry for path "foo" on.  Use "--chmod=-x" to flip it
   off.

Note that --chmod only works in index file and does not look at nor
update the working tree.

So if you are on a filesystem and do not have working executable bit,
you would do:

 1. set the appropriate .git/config option;

 2. "git-update-index --add new-file.c"

 3. "git-ls-files --stage new-file.c" to see if it has the desired
   mode bits.  If not, e.g. to drop executable bit picked up from the
   filesystem, say "git-update-index --chmod=-x new-file.c".
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This is a first cut at a very simple parser for a git config file.

The format of the file is a simple ini-file like thing, with simple
variable/value pairs. You can (and should) make the variables have a
simple single-level scope, ie a valid file looks something like this:

	#
	# This is the config file, and
	# a '#' or ';' character indicates
	# a comment
	#

	; core variables
	[core]
		; Don't trust file modes
		filemode = false

	; Our diff algorithm
	[diff]
		external = "/usr/local/bin/gnu-diff -u"
		renames = true

which parses into three variables: "core.filemode" is associated with the
string "false", and "diff.external" gets the appropriate quoted value.

Right now we only react to one variable: "core.filemode" is a boolean that
decides if we should care about the 0100 (user-execute) bit of the stat
information. Even that is just a parsing demonstration - this doesn't
actually implement that st_mode compare logic itself.

Different programs can react to different config options, although they
should always fall back to calling "git_default_config()" on any config
option name that they don't recognize.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junio@twinsun.com>

This is a long overdue clean-up to the code for parsing and passing
diff options.  It also tightens some constness issues.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We always show the diff as an absolute path, but pathnames to diff are
taken relative to the current working directory (and if no pathnames are
given, the default ends up being all of the current working directory).

Note that "../xyz" also works, so you can do

	cd linux/drivers/char
	git diff ../block

and it will generate a diff of the linux/drivers/block changes.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

All usage strings are now declared as static const char [].

This is carried over from my old git-pb branch.
Signed-off-by: NPetr Baudis <pasky@ucw.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This removes the separate "formats" for name and name-with-zero-
termination.

It also removes the difference between HUMAN and MACHINE formats, and
they both become DIFF_FORMAT_RAW, with the difference being just in the
line and inter-filename termination.

It also makes the code easier to understand.

... and make git-diff-files use it too.  This all _should_ make the
diffcore-pathspec.c phase unnecessary, since the diff'ers now all do the
path matching early interally.

I got tired of maintaining almost duplicated descriptions in
diff-* brothers, both in usage string and documentation.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Porcelain layers often want to find only names of changed files,
and even with diff-raw output format they end up having to pick
out only the filename.  Support --name-only (and --name-only-z
for xargs -0 and cpio -0 users that want to treat filenames with
embedded newlines sanely) flag to help them.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

I'm probably not the only one whose fingers have gotten hard-wired to
use "-u" for "unified diff".