When we choose to omit deleted entries, we should subtract
numbers of such entries from the total number in the header.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Oops.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus 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: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Linus 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: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus 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: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Add missing "space" element to the description of the diff-format.
Signed-off-by: Christian Meder <chris@absolutegiganten.org>
Acked-by: Petr Baudis <pasky@ucw.cz>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Make 'sha1' parameters const where possible
Signed-off-by: Jason McMullan <jason.mcmullan@timesys.com>
Signed-off-by: Linus 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.
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: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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..
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: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus 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.
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: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus 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: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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: Linus 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: Linus 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: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Linus 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: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Linus 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: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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 337cb3fb8d.
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: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus 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.
