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

A new flag --aggressive resolves what we traditionally resolved
with external git-merge-one-file inside index while read-tree
3-way merge works.

git-merge-octopus and git-merge-resolve use this flag before
running git-merge-index with git-merge-one-file.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Avoid asking for zero bytes when that change simplifies overall
logic.  Later we would change the wrapper to ask for 1 byte on
platforms that return NULL for zero byte request.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

These commands are converted to run from a subdirectory.

    commit-tree convert-objects merge-base merge-index mktag
    pack-objects pack-redundant prune-packed read-tree tar-tree
    unpack-file unpack-objects update-server-info write-tree
Signed-off-by: NJunio C Hamano <junkio@cox.net>

ls-files.c and read-tree.c miss the default configuration, in
particular the filemode=false part.  The recent +x bit flip made me
notice that, because git-merge refused to merge anything saying that
git-pull.sh is not up to date.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This fixes everybody's favorite gripe that switching branche with
'git checkout' leaves empty directories.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This adds an option --trivial to restrict 3-way 'read-tree -m -u'
to happen only if there is no file-level merging required.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Initially it was to allow specifying more than one remote to
allow creation of an Octopus, but it is not being used.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Somehow I missed it when we updated read-tree to support the recursive
merge strategy.  Also -i should require -m as well, which the command
did not check.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We wanted to detect case #16 which should be rare, but botched the
case when some paths are missing, causing a segfault.  My fault.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

I really wanted to try this out, instead of asking for an adjustment
to the 'git merge' driver and waiting.  For now the new strategy is
called 'fredrik' and not in the list of default strategies to be tried.

The script wants Python 2.4 so this commit also adjusts Debian and RPM
build procecure files.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

... and it is ready to be pushed out in the "master" branch.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This will help us detect if real-world example merges have multiple
merge-base candidates and one of them matches one head while another
matches the other head.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

Adds support for multiple ancestors, removes --emu23, much simplification.
Signed-off-by: NDaniel Barkalow <barkalow@iabervon.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>

The same way "git-diff-tree" can limit its output to just a set of matches,
we can read in just a partial tree for comparison purposes.

This patch teaches read-tree 3-way merge that, when only "the
other tree" changed a path, and if the index file already has
the same change, we are not in a situation that would clobber
the index and the work tree, and lets the merge succeed; this is
case #14ALT in t1000 test.  It does not change the result of the
merge, but prevents it from failing when it does not have to.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This adds #3ALT rule (and #2ALT rule for symmetry) to the
read-tree 3-way merge logic that collapses paths that are added
only in one branch and not in the other internally.

This makes --emu23 to succeed in the last remaining case where
the pure 2-way merge succeeded and earlier one failed.  Running
diff between t1001 and t1005 test scripts shows that the only
difference between the two is that --emu23 can leave the states
into separate stages so that the user can use usual 3-way merge
resolution techniques to carry forward the local changes when
pure 2-way merge would have refused to run.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This fixes too strong index requirement 3-way merge enforces in
one case: the same file is added in both branches.

In this case, the original code insisted that if the index file
has that path, it must match our branch and be up-to-date.
However in this particular case, it only has to match it, and
can be dirty.  We just need to make sure that we keep the
work-tree copy instead of checking out the merge result.

The resolution of such a path, however, cannot be left to
outside script, because we will not keep the original stage0
entries for unmerged paths when read-tree finishes, and at that
point, the knowledge of "if we resolve it to match the new file
added in both branches, the merge succeeds and the work tree
would not lose information, but we should _not_ update the work
tree from the resulting index file" is lost.  For this reason,
the now code needs to resolve this case (#5ALT) internally.

This affects some existing tests in the test suite, but all in
positive ways.  In t1000 (3-way test), this #5ALT case now gets
one stage0 entry, instead of an identical stage2 and stage3
entry pair, for such a path, and one test that checked for merge
failure (because the test assumed the "stricter-than-necessary"
behaviour) does not have to fail anymore.  In t1005 (emu23
test), two tests that involves a case where the work tree
already had a change introduced in the upstream (aka "merged
head"), the merge succeeds instead of failing.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This new flag causes two-way fast forward to internally use the
three-way merge mechanism.  This behaviour is intended to offer
a better fast forward semantics when used in a dirty work tree.

The new test t1005 is parallel to the existing t1001 "pure
2-way" tests, but some parts that are commented out would fail.
These failures are due to three-way merge enforcing too strict
index requirements for cases that could succeed.  This problem
will be addressed by later patches.

Without even changing three-way mechanism, the --emu23 two-way
fast forward already gives the user an easier-to-handle merge
result when a file that "merged head" updates has local
modifications.  This is demonstrated as "case 16" test in t1005.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Only when "-u" is used of course.

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.

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

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

This implements the "never lose the current cache information or
the work tree state, but favor a successful merge over merge
failure" principle in the fast-forward two-tree merge operation.

It comes with a set of tests to cover all the cases described in
the case matrix found in the new documentation.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Looking good, but hey, it's not like I even have a real testcase for any
of this.  But unlike the mess that this was yerstday, today read-cache
is pretty readable and understandable.  Which is always a good sign.

Stop trying to haev this stateful thing that keeps track of what it has
seen, and use a much simpler "gather all the different stages with the
same name together and just merge them in one go" approach.

Makes it a lot more understandable, and allows the different merge
algorithms to share the basic merge loop.

This patch teaches read-tree how to use the index file locking
helpers the same way "checkout-cache -u" and "update-cache" do.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

That's the final one ("Yeah, sure, we believe you").

Anyway, at least the tests pass, which is not saying a lot, since they
don't end up testing all the new the things that the new merge world
order tries to do. But hopefully we're now at least not any worse off
than we were before the rewrite.

Making the main loop look more like the one- and two-way cases
introduced a bug where "src" had been updated early, but later
users hadn't been adjusted to match.

This is starting to look better.

Add a "-u" flag to update the tree as a result of a merge.

Right now this code is way too anal about things, and fails merges it
shouldn't, but let me fix up the different cases and this will allow for
much smoother merging even in the presense of dirty data in the working
tree.

When we collapse three entries, we need to check all of the
collapsed entries against the old pre-merge state.

We don't want to overwrite state that we haven't committed yet
when merging, so it's better to make git-read-tree fail than
end up with a merge tree that ends up not having the dirty changes.

Update git-resolve-script to fail cleanly when git-read-tree fails.

Fix various things that sparse complains about:
 - use NULL instead of 0
 - make sure we declare everything properly, or mark it static
 - use proper function declarations ("fn(void)" instead of "fn()")

Sparse is always right.

Fixes all in-code names that leaved during "big name change".
Signed-off-by: NAlexey Nezhdanov <snake@penza-gsm.ru>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

unpack_tree() would not free the tree object it has read.

This allows the programs to use various simplified versions of
the SHA1 names, eg just say "HEAD" for the SHA1 pointed to by
the .git/HEAD file etc.

For example, this commit has been done with

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

instead of the traditional "$(cat .git/HEAD)" syntax.