Normally, diff-tree does not feed unchanged filepair to diffcore
for performance reasons, so copies are detected only when the
source file of the copy happens to be modified in the same
changeset.  This adds --find-copies-harder flag to tell
diff-tree to sacrifice the performance in order to find copies
the same way as other commands in diff-* family.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Now -B does not say silly "complete rewrite" anymore for small
files such as the one in the tutorial example.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

When rename/copy uses a file that was broken by diffcore-break
as the source, and the broken filepair gets merged back later,
the output was mislabeled as a rename.  In this case, the source
file ends up staying in the output, so we should label it as a
copy instead.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

If you want the raw stuff, just do

	git-whatchanged --pretty=raw

and it wil act like it used to.

It set verbose, but didn't set the output prefix to "diff-tree".

This steals --pretty command line option from rev-list and
teaches diff-tree to do the same.  With this change,

    $ git-whatchanged --pretty

would work as expected.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

When an unmerged path was fed via diff_unmerged() into diffcore,
it eventually called run_diff() with "one" and "two" parameters
with NULL, but run_diff() was not written carefully enough to
notice this situation.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

A meaningful (ie non-empty) git patch always has more information in the
header than just the "diff --git" line itself: it needs to have either a
patch associated with it (which implies "---" and "+++" lines in the
header) or it needs to have rename/copy/delete/create information in it.

Just ignore git patches which have no change information. Otherwise we'll
end up with a patch that doesn't have filenames etc filled in, and we'll
be unhappy.

When we choose to omit deleted entries, we should subtract
numbers of such entries from the total number in the header.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Oops.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Only when "-u" is used of course.

The diff-* brothers acquired a sibling, git-diff-stages.  With
an unmerged index file, you specify two stage numbers and it
shows the differences between them.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This is the same as "-m", but it will silently ignore any unmerged
entries, which makes it useful for efficiently forcing a new position
regardless of the state of the current index file.

IOW, to reset to a previous HEAD (in case you have had a failed
merge, for example), you'd just do

	git-read-tree -u --reset HEAD

which will also update your working tree to the right state.

NOTE! The "update" will not remove files that may have been added by the
merge.  Yet.

This uses git-checkout-file to make sure that the full pathname is
created, instead of the script having to verify it by hand.  Also,
simplify the 3-way merge case by just writing to the right file and
setting the initial index contents early.

Junio points out that we may need to create the path leading
up the the file we merge.

And we need to be more careful with the "exec"s we've done
to exit on success - only do the on the last command in the
pipeline, not the first one ;)

Chain the resolving sequences (e.g. git-cat-file - chmod -
git-update-cache) through &&s so we stop right away in case one of the
command fails, and report the error code to the script caller.

Also add a copyright notice, some blank lines, ;; on a separate line,
and nicer error messages.
Signed-off-by: NPetr Baudis <pasky@ucw.cz>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Pointed out by Junio.

This patch tidies up the git-rev-list documentation and epoch.c, which
are in severe clash with the unwritten coding style now, and quite
unreadable.

It also fixes up compile failures with older compilers due to variable
declarations after code.

The patch mostly wraps lines before or on the 80th column, removes
plenty of superfluous empty lines and changes comments from // to /* */.
Signed-off-by: NPetr Baudis <pasky@ucw.cz>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This adds a set of tests to make sure that requirements on
existing cache entries are checked when a read-tree -m 3-way
merge is run with an already populated index file.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

In the automerge case, permissions were not restored properly after the
merge tool was invoked and overwrote the target file.
Signed-off-by: NPetr Baudis <pasky@ucw.cz>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This has gotten only very light testing, but something like this is
clearly necessary and did the right thing for the one case I threw at
it.

Add missing "space" element to the description of the diff-format.
Signed-off-by: NChristian Meder <chris@absolutegiganten.org>
Acked-by: NPetr Baudis <pasky@ucw.cz>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Make 'sha1' parameters const where possible
Signed-off-by: NJason McMullan <jason.mcmullan@timesys.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Parse everything after '--' as tree name or pathspec.
Signed-off-by: NJonas Fonseca <fonseca@diku.dk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This changes how we handle merges: if a automated merge
fails, we will leave the index as a clean entry pointing
to the original branch, and leave the actual file _dirty_
the way the "merge" program left it.

You can then just do "git-diff-files -p" to see what the
merge conflicts did, fix them up, and commit the end result.

NOTE NOTE NOTE! Do _not_ use "git commit" to commit such
a merge. It won't set the parents right. I'll need to fix
that. In the meantime, you'd need to merge using

	git-commit-tree $(git-write) -p HEAD -p MERGE_HEAD

or something like that by hand.

NULL is not considered a VALID pathspec.

This updates t1000 (basic 3-way merge test) to check the merge
results for both successful cases (earlier one checked the
result for only one of them).  Also fixes typos in t1002 that
broke '&&' chain, potentially missing a test failure before the
chain got broken.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

In particular, make them readable on one line since that's what all the
tools like git-shortlog and gitk end up showing.

This patch fixes three bugs in --merge-order support
    * mark_ancestors_uninteresting was unnecessarily exponential which
      caused a problem when a commit with no parents was merged near the
      head of something like the linux kernel
    * removed a spurious statement from find_base which wasn't
      apparently causing problems now, but wasn't correct either.
    * removed an unnecessarily strict check from find_base_for_list
      that causes a problem if git-rev-list commit ^parent-of-commit
      is specified.
    * added some unit tests which were accidentally omitted from
      original merge-order patch

The fix to mark_ancestors_uninteresting isn't an optimal fix - a full
graph scan will still be performed in this case even though it is
not strictly required. However, a full graph scan is linear
and still no worse than git-rev-list HEAD which runs in less than 2
seconds on a warm cache.
Signed-off-by: NJon Seymour <jon.seymour@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

cvsps seems to put a space after the tag name, so we remove it first.

(but it will result in a warning)

We should add a lot more information about how you copy repositories,
pulling and pushing, merging etc.  Oh, well.  I'm not exactly known for
my documentation skills. Maybe somebody else will help me..

I cannot count ;-)
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This does a section to talk about "cvs annotate".
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Also, documetn the "-u" in the usage string.

It didn't set CE_UPDATE before, so "-u" was a no-op.

This explains the new merge world order that formally assigns
specific meaning to each of three tree-ish command line
arguments.  It also mentions -u option
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This gets the "cvs2git" program from the old git-tools
archive, and adds a nice script around it that makes it
much easier to use.

With this, you should be able to import a CVS archive
using just a simple

	git cvsimport <cvsroot> <module>

and you're done. At least it worked for my one single test.

NOTE!! This may need tweaking. It currently expects (and
verifies) that cvsps version 2.1 is installed, but you
can't actually set any of the cvsps parameters, like the
time fuzz.