[PATCH] Re-Fix SIGSEGV on unmerged files in git-diff-files -p
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: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus 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.
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.
One more time.. Clean up git-merge-one-file-script
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.
[PATCH] git-merge-one-file-script cleanups from Cogito
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 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>
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
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>
Talk about "git cvsimport" in the cvs migration docs
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..
[PATCH] read-tree: update documentation for 3-way merge.
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.
[PATCH] read-tree: save more user hassles during fast-forward.
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>
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.
[PATCH] Modify git-rev-list to linearise the commit history in 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.
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 337cb3fb8da45f10fe9a0c3cf571600f55ead2ce.
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.
[PATCH] 3-way merge tests for new "git-read-tree -m"?
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: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Three-way merge: fix silly bug that made trivial merges not work
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.
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.
git-read-tree: be a lot more careful about merging dirty trees
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.
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: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] pull: gracefully recover from delta retrieval failure.
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: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
- 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: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
- 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: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
git-apply: actually apply patches and update the index
We update the index only if the "--index" flag is given,
so you can actually use this as a strange kind of "patch"
program even for non-git usage. Not that you'd likely
want to, but it comes in handy for testing.
This _should_ more or less get everythign right, but as
usual I leave the testing to the usrs..
git-apply: find offset fragments, and really apply them
This applies the fragments in memory, but doesn't actually
write the results out to the files yet. But we now do all the
difficult parts, the rest is just basically writing the
results out and updating the index.
git-apply: first cut at actually checking fragment data
Right now it requires that the fragment offsets be exact,
and it doesn't actually apply the fragment yet, but it
does find where it goes and verify the data.
Next step: actually applying the fragment changes.
You can ask to print out "raw" format (full headers, full body),
"medium" format (author and date, full body) or "short" format
(author only, condensed body).
Use "git-rev-list --pretty=short HEAD | less -S" for an example.
Somebody finally came through - Jeff Garzik gets a gold
star for writing a shortlog script for git, so that I
can do nice release announcments again.
I added name translations from the current kernel history
(and git, for that matter). Hopefully it won't grow at
nearly the same rate the BK equivalent did, since 99% of
the time git records the full name already.
Usage: just do
git-rev-list --pretty HEAD ^LAST_HEAD | git-shortlog
or, in fact, use any of the other tools (git-diff-tree,
git-whatchanged etc) that use the default "pretty" commit format.
git-rev-list: allow arbitrary head selections, use git-rev-tree syntax
This makes git-rev-list use the same command line syntax to mark the
commits as git-rev-tree does, and instead of just allowing a start and
end commit, it allows an arbitrary list of "interesting" and "uninteresting"
commits.
For example, imagine that you had three branches (a, b and c) that you
are interested in, but you don't want to see stuff that already exists
in another persons three releases (x, y and z). You can do
git-rev-list a b c ^x ^y ^z
(order doesn't matter, btw - feel free to put the uninteresting ones
first or otherwise swithc them around), and it will show all the
commits that are reachable from a/b/c but not reachable from x/y/z.
The old syntax "git-rev-list start end" would not be written as
"git-rev-list start ^end", or "git-rev-list ^end start".
There's no limit to the number of heads you can specify (unlike
git-rev-tree, which can handle a maximum of 16 heads).
As Linus pointed out on the mailing list discussion, -B should
break a files that has many inserts even if it still keeps
enough of the original contents, so that the broken pieces can
later be matched with other files by -M or -C. However, if such
a broken pair does not get picked up by -M or -C, we would want
to apply different criteria; namely, regardless of the amount of
new material in the result, the determination of "rewrite"
should be done by looking at the amount of original material
still left in the result. If you still have the original 97
lines from a 100-line document, it does not matter if you add
your own 13 lines to make a 110-line document, or if you add 903
lines to make a 1000-line document. It is not a rewrite but an
in-place edit. On the other hand, if you did lose 97 lines from
the original, it does not matter if you added 27 lines to make a
30-line document or if you added 997 lines to make a 1000-line
document. You did a complete rewrite in either case.
This patch introduces a post-processing phase that runs after
diffcore-rename matches up broken pairs diffcore-break creates.
The purpose of this post-processing is to pick up these broken
pieces and merge them back into in-place modifications. For
this, the score parameter -B option takes is changed into a pair
of numbers, and it takes "-B99/80" format when fully spelled
out. The first number is the minimum amount of "edit" (same
definition as what diffcore-rename uses, which is "sum of
deletion and insertion") that a modification needs to have to be
broken, and the second number is the minimum amount of "delete"
a surviving broken pair must have to avoid being merged back
together. It can be abbreviated to "-B" to use default for
both, "-B9" or "-B9/" to use 90% for "edit" but default (80%)
for merge avoidance, or "-B/75" to use default (99%) "edit" and
75% for merge avoidance.
Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This cleans up diff_scoreopt_parse() function that is used to
parse the fractional notation -B, -C and -M option takes. The
callers are modified to check for errors and complain. Earlier
they silently ignored malformed input and falled back on the
default.
Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch updates diff documentation and usage strings:
- clarify the semantics of -R. It is not "output in reverse";
rather, it is "I will feed diff backwards". Semantically
they are different when -C is involved.
- describe -O in usage strings of diff-* brothers. It was
implemented, documented but not described in usage text.
Also it adds -O to diff-helper. Like -S (and unlike -M/-C/-B),
this option can work on sanitized diff-raw output produced by
the diff-* brothers. While we are at it, the call it makes to
diffcore is cleaned up to use the diffcore_std() like everybody
else, and the declaration for the low level diffcore routines
are moved from diff.h (public) to diffcore.h (private between
diff.c and diffcore backends).
Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] git-tar-tree: do only basic tests in t/t5000-git-tar-tree.sh
git-tar-tree: remove tests of long path handling out of t5000-tar-tree.sh
and make test script cope with tar programs displaying file modification
date as hh:mm (newer variants show it as hh:mm:ss).
This makes the test cover only basic functionality that is expected to
be handled even by older tar programs. Tests for long filenames (which
require pax extended headers) can be added separately.
I ran this test successfully with GNU tar 1.13, 1.14 and 1.15.1.
write_trailer() writes the last 10k (a full block) of the tar archive.
write_if_needed() writes out a block *if* it is full and then sets
the offset to 0. In nine out of ten cases the messed up write_trailer()
function didn't manage to fill the block thus not writing anything at
all, truncating the archive. I was "lucky" to hit the other case and so
my testing ran OK.
[PATCH] Handle deltified object correctly in git-*-pull family.
When a remote repository is deltified, we need to get the
objects that a deltified object we want to obtain is based upon.
The initial parts of each retrieved SHA1 file is inflated and
inspected to see if it is deltified, and its base object is
asked from the remote side when it is. Since this partial
inflation and inspection has a small performance hit, it can
optionally be skipped by giving -d flag to git-*-pull commands.
This flag should be used only when the remote repository is
known to have no deltified objects.
Rsync transport does not have this problem since it fetches
everything the remote side has.
Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
git-rev-list: factor out the commit printing from "main()"
Functions that do many things are bad. We should basically
just parse the arguments in main(). We're not quite there
yet, but it's a step in the right direction.
Make a separate helper for parsing the header of an object file
(really carefully) and for unpacking the rest. This means that
anybody who uses the "unpack_sha1_header()" interface can easily
look at the header and decide to unpack the rest too, without
doing any extra work.
It's for people who aren't necessarily interested in the whole
unpacked file, but do want to know the header information (size,
type, etc..)
For example, the delta code can use this to figure out whether
an object is already a delta object, and what it is a delta
against, without actually bothering to unpack all of the actual
data in the delta.