| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* jc/combine:
combine-diff: fix hunks at the end (take #2).
combine-diff: do not lose hunks with only deletion at end.
|
|
* jc/diff:
blame and friends: adjust to multiple pathspec change.
git log --full-diff
tree-diff: do not assume we use only one pathspec
|
|
The previous round showed the delete-only hunks at the end, but
forgot to mark them interesting when they were.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
We used to lose hunks that appear at the end and have only
deletion. This makes sure that the record beyond the end of
file (which holds such deletions) is examined.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
* ds/index:
Replace index() with strchr().
Solaris 9 also wants our own unsetenv/setenv.
Retire git-log.sh (take #3)
|
|
* jc/withraw:
Separate the raw diff and patch with a newline
Document --patch-with-raw
|
|
strchr() is more portable than index() and is used everywhere in
git already.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
[jc: the original had "index() is evil" but that should be a
separate patch.]
|
|
Do not install built-in commands as separate files -- use
hardlinks instead.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
More friendly for human reading I believe, and possibly friendlier to some
parsers (although only by an epsilon).
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
* eb/apply:
Implement limited context matching in git-apply.
|
|
* jc/withraw:
diff-* --patch-with-raw
Retire git-log.sh (take#2)
Retire git-log.sh
Retire diffcore-pathspec.
Improve the git-diff-tree -c/-cc documentation
|
|
This new flag outputs the diff-raw output and diff-patch output
at the same time. Requested by Cogito.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Ok this really should be the good version. The option
handling has been reworked to be automation safe.
Currently to import the -mm tree I have to work around
git-apply by using patch. Because some of Andrews
patches in quilt will only apply with fuzz.
I started out implementing a --fuzz option and then I realized
fuzz is not a very safe concept for an automated system. What
you really want is a minimum number of context lines that must
match. This allows policy to be set without knowing how many
lines of context a patch actually provides. By default
the policy remains to match all provided lines of context.
Allowng git-apply to match a restricted set of context makes
it much easier to import the -mm tree into git. I am still only
processing 1.5 to 1.6 patches a second for the 692 patches in
2.6.17-rc1-mm2 is still painful but it does help.
If I just loop through all of Andrews patches in order
and run git-apply --index -C1 I process the entire patchset
in 1m53s or about 6 patches per second. So running
git-mailinfo, git-write-tree, git-commit-tree, and
git-update-ref everytime has a measurable impact,
and shows things can be speeded up even more.
All of these timings were taking on my poor 700Mhz Athlon
with 512MB of ram. So people with fast machiens should
see much better performance.
When a match is found after the number of context are reduced a
warning is generated. Since this is a rare event and possibly
dangerous this seems to make sense. Unless you are patching
a single file the error message is a little bit terse at
the moment, but it should be easy to go back and fix.
I have also updated the documentation for git-apply to reflect
the new -C option that sets the minimum number of context
lines that must match.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
... and install a replacement properly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
This makes things that include revision.h build again.
Blame is also built, but I am not sure how well it works (or how
well it worked to begin with) -- it was relying on tree-diff to
be using whatever pathspec was used the last time, which smells
a bit suspicious.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Without this flag, "git log -p paths..." shows commits that
touch the specified paths, and diffs about the same specified
paths. With this, the full diff is shown for commits that touch
the specified paths.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
The way tree-diff was set up assumed we would use only one set
of pathspec during the entire life of the program. Move the
pathspec related static variables out to diff_options structure
so that we can filter commits with one set of paths while show
the actual diffs using different set of paths.
I suspect this breaks blame.c, and makes "git log paths..." to
default to the --full-diff, the latter of which is dealt with
the next commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
* master:
Make "--parents" logs also be incremental
Retire diffcore-pathspec.
Improve the git-diff-tree -c/-cc documentation
|
|
* lt/rev:
Make "--parents" logs also be incremental
|
|
Nobody except diff-stages used it -- the callers instead filtered
the input to diffcore themselves. Make diff-stages do that as
well and retire diffcore-pathspec.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
This tries to clarify the -c/-cc documentation and clean up the style and
grammar.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
* jc/diff:
git log [diff-tree options]...
log-tree: separate major part of diff-tree.
|
|
And this makes "git log" to take common diff-tree options, so
that it can be used as "git whatchanged".
The recent revision walker updates by Linus to make path
limiting low-latency helps this quite a bit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
This separates out the part that deals with one-commit diff-tree
(and --stdin form) into a separate log-tree module.
There are two goals with this. The more important one is to be
able to make this part available to "git log --diff", so that we
can have a native "git whatchanged" command. Another is to
simplify the commit log generation part simpler.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
The parent rewriting feature caused us to create the whole history in one
go, and then simplify it later, because of how rewrite_parents() had been
written. However, with a little tweaking, it's perfectly possible to do
even that one incrementally.
Right now, this doesn't really much matter, because every user of
"--parents" will probably generally _also_ use "--topo-order", which will
cause the old non-incremental behaviour anyway. However, I'm hopeful that
we could make even the topological sort incremental, or at least
_partially_ so (for example, make it incremental up to the first merge).
In the meantime, this at least moves things in the right direction, and
removes a strange special case.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Compiling this module gave the following warnings (some double dutch!):
xdiff/xdiffi.c: In functie 'xdl_recs_cmp':
xdiff/xdiffi.c:298: let op: 'spl.i1' may be used uninitialized in this function
xdiff/xdiffi.c:298: let op: 'spl.i2' may be used uninitialized in this function
xdiff/xdiffi.c:219: let op: 'fbest1' may be used uninitialized in this function
xdiff/xdiffi.c:219: let op: 'bbest1' may be used uninitialized in this function
A superficial tracking of their usage, without deeper knowledge about the
algorithm, indeed confirms that there are code paths on which these
variables will be used uninitialized. In practice these code paths might never
be reached, but then these fixes will not change the algorithm. If these
code paths are ever reached we now at least have a predictable outcome. And
should the very small performance impact of these initializations be
noticeable, then they should at least be replaced by comments why certain
code paths will never be reached.
Some extra initializations in this patch now fix the warnings.
|
|
When a broken pair is matched up by rename detector to be merged
back, we do not want to say it is "dissimilar" with the
similarity index. The output should just say they were changed,
taking the break score left by the earlier diffcore-break run if
any.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
We did not read in the file data before emitting the
total-rewrite diff. Noticed by Pasky.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
* master:
GIT 1.3.0-rc3
|
|
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
* kh/svn:
git-svnimport: Don't assume that copied files haven't changed
|
|
* jc/thinpack:
Thin pack generation: optimization.
|
|
* jc/date:
date parsing: be friendlier to our European friends.
|
|
* nh/http:
Fix compile with expat, but an old curl version
http-fetch: add optional DAV-based pack list
|
|
* ew/rev-abbrev:
rev-list --abbrev-commit
|
|
* jc/blame:
blame -S <ancestry-file>
Match ofs/cnt types in diff interface.
blame: use built-in xdiff
combine-diff: move the code to parse hunk-header into common library.
combine-diff: refactor built-in xdiff interface.
combine-diff: use built-in xdiff.
|
|
* master:
gitk: Fix incorrect invocation of getmergediffline
[PATCH] gitk: Fix searching for filenames in gitk
count-delta: match get_delta_hdr_size() changes.
check patch_delta bounds more carefully
|
|
* git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Fix incorrect invocation of getmergediffline
[PATCH] gitk: Fix searching for filenames in gitk
|
|
* maint:
count-delta: match get_delta_hdr_size() changes.
check patch_delta bounds more carefully
|
|
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Let's avoid going south with invalid delta data.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
* jc/thinpack:
Thin pack generation: optimization.
|
|
* ew/rev-abbrev:
rev-list --abbrev-commit
|
|
* jc/blame:
blame -S <ancestry-file>
Match ofs/cnt types in diff interface.
|
|
* kh/svn:
git-svnimport: Don't assume that copied files haven't changed
Add Documentation/technical/pack-format.txt
Added Packing Heursitics IRC writeup.
Add documentation for git-imap-send.
|
|
Don't assume that a file that SVN claims was copied from somewhere
else is bit-for-bit identical with its parent, since SVN allows
changes to copied files before they are committed.
Without this fix, such copy-modify-commit operations causes the
imported file to lack the "modify" part -- that is, we get subtle data
corruption.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
Junio C Hamano
Dennis Stosberg
Petr Baudis
Eric W. Biederman
Linus Torvalds
Marco Roeland
Nicolas Pitre
Karl Hasselström