The test is considered OK if it exits with code $1
Signed-off-by: NFredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This way it is possible to test in scripts if the merge was non-clean
or if the strategy had other problems with the merge.
Signed-off-by: NFredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

[jc: light edit applied on top of the original]
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Use the same trick Josef used to introduce line breaks for
git-mv documentation for now, to help HTML rendering.  This
breaks manpages and we need to come up with a better solution.

Noticed by linux@horizon.com (No Name).
Signed-off-by: NJunio C Hamano <junkio@cox.net>

[jc: light edit applied on top of the original]
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This hopefully concludes the latest updates that changes the
behaviour of the merge on an unsuccessful automerge.  Instead of
collapsing the conflicted path in the index to show HEAD, we
leave it unmerged, now that diff-files can compare working tree
files with higher stages.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We ran "merge" command on O->A, O->B, A!=B case without
verifying the path involved is not a symlink.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The "update-index followed by checkout-index" chain served two
purposes -- to collapse the index to "our" version, and make
sure that file exists in the working tree.  In the recent update
to leave the index unmerged on conflicting path, we wanted to
stop doing the former, but we still need to do the latter (we
allow merging to work in an un-checked-out working tree).
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

You need to pass -t flag if you want to see tree objects in
"git-ls-tree -r" output these days.  This change broke the tree
structure reading code in git-merge-recursive used to detect D/F
conflicts.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

 - Use stderr for error output
 - Build git_command more careful
 - ENOENT is good enough for check of failed exec to show usage, no
   access() check needed

[jc: Originally from Alex Riesen with inputs from Sven
 Verdoolaege mixed in.]
Signed-off-by: NJunio C Hamano <junkio@cox.net>

9ae2172a used "rmdir -p"
carelessly, causing the more important "git-update-index
--remove" to be skipped.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Fingers of some "git diff" users are trained to do --name-only
which git-ls-tree unfortunately does not take.  With this,

	cd sub/directory && git-ls-tree -r --name-only ..

would show only the names not object names nor modes.  I threw
in another synonym --name-status only for usability, but
obviously ls-tree does not do any comparison so what it does is
the same as --name-only.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

With this:

	git-ls-tree -d HEAD -- drivers/net/

shows only immediate subtrees of drivers/net.

	git-ls-tree -d -t HEAD -- drivers/net/

shows drivers, drivers/net and immediate subtrees of
drivers/net.

	git-ls-tree -d -r HEAD -- drivers/net/

shows drivers, drivers/net and all subtrees of drivers/net (but
not blobs).
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The old (new) behaviour was that it only shows trees if the object is
specified exactly, and recursive is not set. That makes sense, because
there is obviously nothing else it can show for that case.

However, with the new "-t" option, it will show the tree even with "-r",
as it traverses down into it.

NOTE! This also means that it will show all trees leading up to that tree.

For example, if you do a

	git-ls-tree -t HEAD -- drivers/char/this/file/does/not/exist

it will show the trees that lead up to the files that do not exist:

	[torvalds@g5 linux]$ git-ls-tree -t HEAD -- drivers/char/this/file/does/not/exist
	040000 tree 9cb687b77dcd64bf82e9a73214db467c964c1266    drivers
	040000 tree 298e2fadf0ff3867d1ef49936fd2c7bf6ce1eb66    drivers/char
	[torvalds@g5 linux]$

and note how this is true even though I didn't specify "-r": the fact that
I supplied a pathspec automatically implies "enough recursion" for that
particular pathspec.

I think the code is cleaner and easier to understand too: the patch looks
bigger, but it's really just splitting up the "should we recurse into this
tree" into a function of its own.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Alex Riesen wants to keep extra makefile targets in config.mak, but
the file is included before any of our real targets.  Having this
at the beginning allows you to do so.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The option description header was there without body text, confusingly
getting rendered as if the description for --tags applied to the option.

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

This makes it possible to define WITH_SEND_EMAIL etc. in config.mak.

Also remove GIT_LIST_TWEAK because it isn't used anymore.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Dereference the environment variable before using it.
Signed-off-by: NTommi Virtanen <tv@inoi.fi>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Current default, merge-recursive, gives slightly different
message while working from merge-resolve which was used to
prepare the illustration in the tutorial.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This minimally changes merge-recursive to match what happens
when O->A, O->B, A!=B 3-way filelevel merge leaves conflicts to
the new merge-resolve behaviour.
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>

When automerge fails, we used to collapse the path to stage0
from "our" branch, to help "diff-files" users to view the
half-merged state against the current HEAD.  Now diff-files has
been taught how to compare with unmerged stage2,leaving them
unmerged is a better thing to do, especially this prevents the
unresolved conflicts to be committed by mistake.
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>

When the user gives a diff option (e.g. --cached) to "git diff",
we turned off the built-in default option -p, which is usually
not what user wants to see.

This commit makes lack of --name-status, --name-only nor -r to
add -p, and lack of -B*, -C* nor -M* to add -M to the flags
given to the underlying diff.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Junio C Hamano, Sat, Nov 26, 2005 03:45:52 +0100:

> I haven't seriously used git-mv myself, so
> somebody needs to test it, and if it actually works and Ack on
> it, please.

It actually works in subdirs.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Turns out, all git programs git-mv uses are capable of operating in
a subdirectory just fine. So don't complain about it.

[jc: I think that sounds sane.  You need to grab the exit status from
 `git-rev-parse --git-dir`, which I added.  Alex Riesen says this
 worked fine.]
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

There is a lot more that could be put in, such as a selector for
the font family etc., but this is a start.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Otherwise it would show incomplete line and binary markers in
a locale dependent way.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Before GIT version at the end of output we used a 3-dash marker;
but 3-dash marker is special and should not be overused.
Instead, use "-- " which is a standard practice in e-mails to
signal the beginning of trailing garbage.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The attempt to help 3-way fallback by recording the tree object
id for the entire pre-image was unnecessary, and we already have
an better alternative in the form of per-blob "index" lines.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This matches the 3-way fallback used by applypatch to use
per-blob "index" lines, not "applies-to" tree object name, to
match what git-am does.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The -m option to fall back on 3-way merge was not honoured at
all because of a typo.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

One "svn log" (or its equivalent) per revision adds delay and server load.
Instead, open two SVN connections -- one for the log, and one for the files.

Positive side effect: Only those log entries which actually contain data
are committed => no more empty commits.

Also, change the "-l" option to set the maximum revision to be pulled,
not the number of revisions.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJon Loeliger <jdl@freescale.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The malloc patch from Jan Andres fixed the problem that was causing a
segfault when freeing the lock token, and Johannes Schindelin found
and fixed a problem when no URL is specified on the command line.
Signed-off-by: NNick Hengeveld <nickh@reactrix.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The "--shared" option to git-clone is silently ignored if "--local" is
not specified.  The manual doesn't mention such dependency.  Make
"--shared" imply "--local".
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>