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.

Allow traditional ssh path specifiers (host:path), and let the user
override the command name on the other end.

With this, I can push to kernel.org with this script

	export GIT_SSH_PULL=/home/torvalds/bin/git-ssh-pull
	git-ssh-push -a -v -w heads/master heads/master master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

which while not pretty is at least workable.

Use ntohs instead of htons to convert ce_flags to host byte order
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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>

This fixes the documentation for git-ssh-push, as called by users (if you
run git-ssh-pull or git-ssh-push on one machine, the other runs on the
other machine, and they transfer data in the specified direction).

This also adds documentation for the -w option and for using filenames for
the commit-id (which does what you'd want: uses the source side's value,
not the value already on the target, even if you're running it on the
target).

It also credits me with the programs and the documentation for
git-ssh-push.

Someone who knows asciidoc should make sure I didn't mess up the
formatting. I'm only sure of the ascii part.
Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

No point in doing a tree write that will just throw
confusing messages on the screen.

Don't continue with a merge if the fetch failed.

We used to overwrite peoples dirty state.  We don't any more.  So don't
print the scary message and don't delay, just do the update already.

This adds support for -w to git-ssh-pull and git-ssh-push to make
receiving side write the commit that was transferred to a reference file.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This adds support to pull.c for requesting a reference and writing it to a
file. All of the git-*-pull programs get stubs for now.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

rsh.c used to set the environment variable for the object database when
invoking the remote command. Now that there is a GIT_DIR variable, use
that instead.
Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch adds code to read a hash out of a specified file under
{GIT_DIR}/refs/, and to write such files atomically and optionally with an
compare and lock.
Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
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>

Only with gcc. It fixes some warnings for certain versions
of gcc, but not apparently all.

Needed for the bignum stuff used by merge-order.

This patch linearises the GIT commit history graph into merge order
which is defined by invariants specified in Documentation/git-rev-list.txt.

The linearisation produced by this patch is superior in an objective sense
to that produced by the existing git-rev-list implementation in that
the linearisation produced is guaranteed to have the minimum number of
discontinuities, where a discontinuity is defined as an adjacent pair of
commits in the output list which are not related in a direct child-parent
relationship.

With this patch a graph like this:

	a4 ---
	| \   \
	|  b4 |
	|/ |  |
	a3 |  |
	|  |  |
	a2 |  |
	|  |  c3
	|  |  |
	|  |  c2
	|  b3 |
	|  | /|
	|  b2 |
	|  |  c1
	|  | /
	|  b1
	a1 |
	|  |
	a0 |
	| /
	root

Sorts like this:

	= a4
	| c3
	| c2
	| c1
	^ b4
	| b3
	| b2
	| b1
	^ a3
	| a2
	| a1
	| a0
	= root

Instead of this:

	= a4
	| c3
	^ b4
	| a3
	^ c2
	^ b3
	^ a2
	^ b2
	^ c1
	^ a1
	^ b1
	^ a0
	= root

A test script, t/t6000-rev-list.sh, includes a test which demonstrates
that the linearisation produced by --merge-order has less discontinuities
than the linearisation produced by git-rev-list without the --merge-order
flag specified. To see this, do the following:

	cd t
	./t6000-rev-list.sh
	cd trash
	cat actual-default-order
	cat actual-merge-order

The existing behaviour of git-rev-list is preserved, by default. To obtain
the modified behaviour, specify --merge-order or --merge-order --show-breaks
on the command line.

This version of the patch has been tested on the git repository and also on the linux-2.6
repository and has reasonable performance on both - ~50-100% slower than the original algorithm.

This version of the patch has incorporated a functional equivalent of the Linus' output limiting
algorithm into the merge-order algorithm itself. This operates per the notes associated
with Linus' commit 337cb3fb.

This version has incorporated Linus' feedback regarding proposed changes to rev-list.c.
(see: [PATCH] Factor out filtering in rev-list.c)

This version has improved the way sort_first_epoch marks commits as uninteresting.

For more details about this change, refer to Documentation/git-rev-list.txt
and http://blackcubes.dyndns.org/epoch/.
Signed-off-by: NJon Seymour <jon.seymour@gmail.com>
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.

The updated git-tread-tree -m is more strict in that it wants to
have the original cache up to date.  The initial part of t1000
(merge tests from hell) fails due to it.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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.

Bad Linus.

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.

The merge stuff will want it soon, and we don't want to
duplicate all the work..

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.

Make the --force-remove flag behave same as --add, --remove and
--replace. This means I can do

	git-update-cache --force-remove -- file1.c file2.c

which is probably saner and also makes it easier to use in cg-rm.
Signed-off-by: NPetr Baudis <pasky@ucw.cz>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

In preparation for 1.0 release, this makes the command names
consistent with others in git-*-pull family.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Clearly even Junio felt git "rename" header lines should say "from/to"
instead of "old/new", since he wrote the documentation that way.

This way it also matches "copy".

git-apply will accept both versions, at least for a while.

A "--stat" or a "--check" will just be quiet, but if
you try to apply something with no changes, that's an
error.

The documentation failed to describe "diff --git" extended diff
headers, so add some.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This adds documentation for the diffcore mechanism and explains
how numeric parameters to -B/-C/-M options affect the output,
which was left "black magic" so far.

The documentation is not connected to any of the other asciidoc
nodes yet.  Awaiting for suggestions, fixes and help from other
people.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

It's not "rename from" and "rename to", it's "rename old" and "rename new".

Which is illogical and doesn't match the "copy from/to" case, but that's
life. Maybe Junio will fix it up one of these days.

This addresses a concern raised by Jason McMullan in the mailing
list discussion.  After retrieving and storing a potentially
deltified object, pull logic tries to check and fulfil its delta
dependency.  When the pull procedure is killed at this point,
however, there was no easy way to recover by re-running pull,
since next run would have found that we already have that
deltified object and happily reported success, without really
checking its delta dependency is satisfied.

This patch introduces --recover option to git-*-pull family
which causes them to re-validate dependency of deltified objects
we are fetching.  A new test t5100-delta-pull.sh covers such a
failure mode.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This fixes three bugs in the -B heuristics.

 - Although it was advertised that the initial break criteria
   used was the same as what diffcore-rename uses, it was using
   something different.  Instead of using smaller of src and dst
   size to compare with "edit" size, (insertion and deletion),
   it was using larger of src and dst, unlike the rename/copy
   detection logic.  This caused the parameter to -B to mean
   something different from the one to -M and -C.  To compensate
   for this change, the default break score is also changed to
   match that of the default for rename/copy.

 - The code would have crashed with division by zero when trying
   to break an originally empty file.

 - Contrary to what the comment said, the algorithm was breaking
   small files, only to later merge them together.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This fixes a bug that was preventing non-default parameter to -B
option to be passed correctly; you could not give more than 50%
break score.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This fixes two bugs.

 - declaration of auto variable "cmp" was preceeded by a
   statement, causing compilation error on real C compilers;
   noticed and patch given by Yoichi Yuasa.

 - the function's calling convention was overloading its size
   parameter to mean "largest possible value means do not add
   entry", which was a bad taste.  Brought up during a
   discussion with Peter Baudis.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>