summaryrefslogtreecommitdiff
path: root/diff-lib.c
AgeCommit message (Collapse)AuthorFilesLines
2007-02-16Do not take mode bits from index after type change.Libravatar Junio C Hamano1-3/+1
When we do not trust executable bit from lstat(2), we copied existing ce_mode bits without checking if the filesystem object is a regular file (which is the only thing we apply the "trust executable bit" business) nor if the blob in the index is a regular file (otherwise, we should do the same as registering a new regular file, which is to default non-executable). Noticed by Johannes Sixt. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05git-blame: no rev means start from the working tree file.Libravatar Junio C Hamano1-1/+43
Warning: this changes the semantics. This makes "git blame" without any positive rev to start digging from the working tree copy, which is made into a fake commit whose sole parent is the HEAD. It also adds --contents <file> option to pretend as if the working tree copy has the contents of the named file. You can use '-' to make the command read from the standard input. If you want the command to start annotating from the HEAD commit, you need to explicitly give HEAD parameter. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-06diff-index --cached --raw: show tree entry on the LHS for unmerged entries.Libravatar Junio C Hamano1-3/+6
This updates the way diffcore represents an unmerged pair somewhat. It used to be that entries with mode=0 on both sides were used to represent an unmerged pair, but now it has an explicit flag. This is to allow diff-index --cached to report the entry from the tree when the path is unmerged in the index. This is used in updating "git reset <tree> -- <path>" to restore absense of the path in the index from the tree. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-05diff-index --cc shows a 3-way diff between HEAD, index and working tree.Libravatar Paul Mackerras1-0/+25
This implements a 3-way diff between the HEAD commit, the state in the index, and the working directory. This is like the n-way diff for a merge, and uses much of the same code. It is invoked with the -c flag to git-diff-index, which it already accepted and did nothing with. Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-23Convert memset(hash,0,20) to hashclr(hash).Libravatar Junio C Hamano1-1/+1
In the same spirit as hashcmp() and hashcpy(). Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-23Convert memcpy(a,b,20) to hashcpy(a,b).Libravatar Shawn Pearce1-2/+1
This abstracts away the size of the hash values when copying them from memory location to memory location, much as the introduction of hashcmp abstracted away hash value comparsion. A few call sites were using char* rather than unsigned char* so I added the cast rather than open hashcpy to be void*. This is a reasonable tradeoff as most call sites already use unsigned char* and the existing hashcmp is also declared to be unsigned char*. [jc: Splitted the patch to "master" part, to be followed by a patch for merge-recursive.c which is not in "master" yet. Fixed the cast in the latter hunk to combine-diff.c which was wrong in the original. Also converted ones left-over in combine-diff.c, diff-lib.c and upload-pack.c ] Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-17Do not use memcmp(sha1_1, sha1_2, 20) with hardcoded length.Libravatar David Rientjes1-1/+1
Introduces global inline: hashcmp(const unsigned char *sha1, const unsigned char *sha2) Uses memcmp for comparison and returns the result based on the length of the hash name (a future runtime decision). Acked-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-19Merge branch 'lt/objlist' into nextLibravatar Junio C Hamano1-2/+2
* lt/objlist: Add "named object array" concept xdiff: minor changes to match libxdiff-0.21 fix rfc2047 formatter. Fix t8001-annotate and t8002-blame for ActiveState Perl Add specialized object allocator
2006-06-19Add "named object array" conceptLibravatar Linus Torvalds1-2/+2
We've had this notion of a "object_list" for a long time, which eventually grew a "name" member because some users (notably git-rev-list) wanted to name each object as it is generated. That object_list is great for some things, but it isn't all that wonderful for others, and the "name" member is generally not used by everybody. This patch splits the users of the object_list array up into two: the traditional list users, who want the list-like format, and who don't actually use or want the name. And another class of users that really used the list as an extensible array, and generally wanted to name the objects. The patch is fairly straightforward, but it's also biggish. Most of it really just cleans things up: switching the revision parsing and listing over to the array makes things like the builtin-diff usage much simpler (we now see exactly how many members the array has, and we don't get the objects reversed from the order they were on the command line). One of the main reasons for doing this at all is that the malloc overhead of the simple object list was actually pretty high, and the array is just a lot denser. So this patch brings down memory usage by git-rev-list by just under 3% (on top of all the other memory use optimizations) on the mozilla archive. It does add more lines than it removes, and more importantly, it adds a whole new infrastructure for maintaining lists of objects, but on the other hand, the new dynamic array code is pretty obvious. The change to builtin-diff-tree.c shows a fairly good example of why an array interface is sometimes more natural, and just much simpler for everybody. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-18Don't instantiate structures with FAMs.Libravatar Florian Forster1-19/+22
Since structures with `flexible array members' are an incomplete datatype ANSI C99 forbids creating instances of them. This patch removes such an instance from `diff-lib.c' and replaces it with a pointer to a `struct combine_diff_path'. Since all neccessary memory is allocated at once the number of calls to `xmalloc' is not increased. Signed-off-by: Florian Forster <octo@verplant.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-22Libified diff-index: backward compatibility fix.Libravatar Junio C Hamano1-1/+9
"diff-index -m" does not mean "do not ignore merges", but means "pretend missing files match the index". The previous round tried to address this, but failed because setup_revisions() ate "-m" flag before the caller had a chance to intervene. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-22Libify diff-index.Libravatar Junio C Hamano1-0/+203
The second installment to libify diff brothers. The pathname arguments are checked more strictly than before because we now use the revision.c::setup_revisions() infrastructure. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-22Libify diff-files.Libravatar Junio C Hamano1-1762/+100
This is the first installment to libify diff brothers. The updated diff-files uses revision.c::setup_revisions() infrastructure to parse its command line arguments, which means the pathname arguments are checked more strictly than before. The tests are adjusted to separate possibly missing paths from the rest of arguments with double-dashes, to show the kosher way. As Linus pointed out, renaming diff.c to diff-lib.c was simply stupid, so I am renaming it back. The new diff-lib.c is to contain pieces extracted from diff brothers. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19diff --stat: do not drop rename information.Libravatar Junio C Hamano1-9/+68
When a verbatim rename or copy is detected, we did not show anything on the "diff --stat" for the filepair. This makes it to show the rename information. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19diff: move diff.c to diff-lib.c to make room.Libravatar Junio C Hamano1-0/+1736
Now I am not doing any real "git-diff in C" yet, but this would help before doing so. Signed-off-by: Junio C Hamano <junkio@cox.net>