summaryrefslogtreecommitdiff
path: root/commit.c
AgeCommit message (Collapse)AuthorFilesLines
2006-07-04Re-fix clear_commit_marks().Libravatar Junio C Hamano1-5/+8
Fix clear_commit_marks() enough to be usable in get_merge_bases(), and retire now unused clear_object_marks(). Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-03revert clear-commit-marks for now.Libravatar Junio C Hamano1-7/+6
Earlier change broke "git describe A B" among other things. Revert it for now, and clean the commits smudged by get_merge_bases using clear_object_marks() function. For complex commit ancestry graph, this is way cheaper as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-03get_merge_bases: clean up even when there is no common commit.Libravatar Junio C Hamano1-1/+2
Actually in this case we would have traversed a lot of commits, so cleaning things up is even more important. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-02commit.c: do not redefine UNINTERESTING bit.Libravatar Junio C Hamano1-20/+20
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-02Fold get_merge_bases_clean() into get_merge_bases()Libravatar Rene Scharfe1-15/+6
Change get_merge_bases() to be able to clean up after itself if needed by adding a cleanup parameter. We don't need to save the flags and restore them afterwards anymore; that was a leftover from before the flags were moved out of the range used in revision.c. clear_commit_marks() sets them to zero, which is enough. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-01Make clear_commit_marks() clean harderLibravatar Rene Scharfe1-4/+3
Don't care if objects have been parsed or not and don't stop when we reach a commit that is already clean -- its parents could be dirty. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-01Add get_merge_bases_clean()Libravatar Rene Scharfe1-4/+16
Add get_merge_bases_clean(), a wrapper for get_merge_bases() that cleans up after doing its work and make get_merge_bases() NOT clean up. Single-shot programs like git-merge-base can use the dirty and fast version. Also move the object flags used in get_merge_bases() out of the range defined in revision.h. This fixes the "66ae0c77...ced9456a 89719209...262a6ef7" test of the ... operator which is introduced with the next patch. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-29move get_merge_bases() to core lib.Libravatar Johannes Schindelin1-0/+240
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28connect.c: check the commit buffer boundary while parsing.Libravatar Junio C Hamano1-4/+8
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28Make some strings constLibravatar Timo Hirvonen1-1/+1
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-19fix rfc2047 formatter.Libravatar Junio C Hamano1-4/+17
Running git-format-patch on patches from Lukas destroyed the From: line. This fixes it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-19Add specialized object allocatorLibravatar Linus Torvalds1-1/+1
This creates a simple specialized object allocator for basic objects. This avoids wasting space with malloc overhead (metadata and extra alignment), since the specialized allocator knows the alignment, and that objects, once allocated, are never freed. It also allows us to track some basic statistics about object allocations. For example, for the mozilla import, it shows object usage as follows: blobs: 627629 (14710 kB) trees: 1119035 (34969 kB) commits: 196423 (8440 kB) tags: 1336 (46 kB) and the simpler allocator shaves off about 2.5% off the memory footprint off a "git-rev-list --all --objects", and is a bit faster too. [ Side note: this concludes the series of "save memory in object storage". The thing is, there simply isn't much more to be saved on the objects. Doing "git-rev-list --all --objects" on the mozilla archive has a final total RSS of 131498 pages for me: that's about 513MB. Of that, the object overhead is now just 56MB, the rest is going somewhere else (put another way: the fact that this patch shaves off 2.5% of the total memory overhead, considering that objects are now not much more than 10% of the total shows how big the wasted space really was: this makes object allocations much more memory- and time-efficient). I haven't looked at where the rest is, but I suspect the bulk of it is just the pack-file loading. It may be that we should pack the tree objects separately from the blob objects: for git-rev-list --objects, we don't actually ever need to even look at the blobs, but since trees and blobs are interspersed in the pack-file, we end up not being dense in the tree accesses, so we end up looking at more pages than we strictly need to. So with a 535MB pack-file, it's entirely possible - even likely - that most of the remaining RSS is just the mmap of the pack-file itself. We don't need to map in _all_ of it, but we do end up mapping a fair amount. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-17Move "void *util" from "struct object" into "struct commit"Libravatar Linus Torvalds1-2/+2
Every single user actually wanted this only for commit objects, and we have no reason to waste space on it for other object types. So just move the structure member from the low-level "struct object" into the "struct commit". This leaves the commit object the same size, and removes one unnecessary pointer from all other object allocations. This shrinks memory usage (still at a fairly hefty half-gig, admittedly) of "git-rev-list --all --objects" on the mozilla repo by another 5% in my tests. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-17Shrink "struct object" a bitLibravatar Linus Torvalds1-4/+4
This shrinks "struct object" by a small amount, by getting rid of the "struct type *" pointer and replacing it with a 3-bit bitfield instead. In addition, we merge the bitfields and the "flags" field, which incidentally should also remove a useless 4-byte padding from the object when in 64-bit mode. Now, our "struct object" is still too damn large, but it's now less obviously bloated, and of the remaining fields, only the "util" (which is not used by most things) is clearly something that should be eventually discarded. This shrinks the "git-rev-list --all" memory use by about 2.5% on the kernel archive (and, perhaps more importantly, on the larger mozilla archive). That may not sound like much, but I suspect it's more on a 64-bit platform. There are other remaining inefficiencies (the parent lists, for example, probably have horrible malloc overhead), but this was pretty obvious. Most of the patch is just changing the comparison of the "type" pointer from one of the constant string pointers to the appropriate new TYPE_xxx small integer constant. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-21builtin format-patch: squelch content-type for 7-bit ASCIILibravatar Junio C Hamano1-2/+15
When --attach is not used, usually we do not say Content-Type: and fluff, but if the commit message is not 7-bit ASCII, mark it as "text/plain; charset=UTF-8". This unclutters output somewhat. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-21CMIT_FMT_EMAIL: Q-encode Subject: and display-name part of From: fields.Libravatar Junio C Hamano1-7/+72
By convention, the commit message and the author/committer names in the commit objects are UTF-8 encoded. When formatting for e-mails, Q-encode them according to RFC 2047. While we are at it, generate the content-type and content-transfer-encoding headers as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-21fmt-patch: Support --attachLibravatar Johannes Schindelin1-1/+9
This patch touches a couple of files, because it adds options to print a custom text just after the subject of a commit, and just after the diffstat. [jc: made "many dashes" used as the boundary leader into a single variable, to reduce the possibility of later tweaks to miscount the number of dashes to break it.] Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-21Merge branch 'master' into js/fmt-patchLibravatar Junio C Hamano1-16/+25
* master: (119 commits) diff family: add --check option Document that "git add" only adds non-ignored files. Add a conversion tool to migrate remote information into the config fetch, pull: ask config for remote information Fix build procedure for builtin-init-db read-tree -m -u: do not overwrite or remove untracked working tree files. apply --cached: do not check newly added file in the working tree Implement a --dry-run option to git-quiltimport Implement git-quiltimport Revert "builtin-grep: workaround for non GNU grep." builtin-grep: workaround for non GNU grep. builtin-grep: workaround for non GNU grep. git-am: use apply --cached apply --cached: apply a patch without using working tree. apply --numstat: show new name, not old name. Documentation/Makefile: create tarballs for the man pages and html files Allow pickaxe and diff-filter options to be used by git log. Libify the index refresh logic Builtin git-init-db Remove unnecessary local in get_ref_sha1. ...
2006-05-17commit: allow --pretty= args to be abbreviatedLibravatar Eric Wong1-14/+24
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-05Teach fmt-patch about --numberedLibravatar Johannes Schindelin1-4/+1
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-01Use RFC2822 dates from "git fmt-patch".Libravatar Junio C Hamano1-1/+2
Still Work-in-progress git fmt-patch (should it be known as format-patch-ng?) is matched with the fix made by Huw Davies in 262a6ef76a1dde97ab50d79fa5cd6d3f9f125765 commit to use RFC2822 date format. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-22git-fmt-patch: thinkofix to show [PATCH] properly.Libravatar Junio C Hamano1-2/+3
Updating "subject" variable without changing the hardcoded number of bytes to memcpy from it would not help much. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-19Minor tweak on subject line in --pretty=emailLibravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-18Tentative built-in format-patch.Libravatar Junio C Hamano1-5/+31
This only does --stdout right now. To write into separate files with pretty-printed filenames like the real thing does, it needs a bit mroe work. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-17Allow empty lines in info/graftsLibravatar Yann Dirson1-1/+1
In addition to the existing comment support, that just allows the user to use a convention that works pretty much everywhere else. Signed-off-by: Yann Dirson <ydirson@altern.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-16reading $GIT_DIR/info/graft - skip comments correctly.Libravatar Junio C Hamano1-1/+3
Noticed by Yann Dirson. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-14Clean up trailing whitespace when pretty-printing commitsLibravatar Linus Torvalds1-10/+5
Partly because we've messed up and now have some commits with trailing whitespace, but partly because this also just simplifies the code, let's remove trailing whitespace from the end when pretty-printing commits. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-12When showing a commit message, do not lose an incomplete line.Libravatar Linus Torvalds1-2/+2
2006-04-07blame -S <ancestry-file>Libravatar Junio C Hamano1-55/+79
This adds the -S <ancestry-file> option to blame, which is needed by the CVS server emulation. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-04Replace xmalloc+memset(0) with xcalloc.Libravatar Peter Eriksen1-2/+1
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-10Make it possible to not clobber object.util in sort_in_topological_order ↵Libravatar Fredrik Kuivinen1-9/+27
(take 2) Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-23Merge fixes early for next maint series.Libravatar Junio C Hamano1-1/+2
2006-02-22Give no terminating LF to error() function.Libravatar Junio C Hamano1-1/+2
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-15topo-order: make --date-order optional.Libravatar Junio C Hamano1-3/+10
This adds --date-order to rev-list; it is similar to topo order in the sense that no parent comes before all of its children, but otherwise things are still ordered in the commit timestamp order. The same flag is also added to show-branch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-02commit.c: "Merge" fix in pretty_print_commit.Libravatar Junio C Hamano1-5/+5
Earlier, f2d4227530499db3e273ae84f30adfd4b70791c6 commit broke Merge: lines for unabbreviated case. Do not emit extra dots if we do not abbreviate. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-28pretty_print_commit: honor grafts.Libravatar Junio C Hamano1-26/+26
When displaying Merge: lines, we used to take the real commit parents from the commit objects. Use the parsed parents from the commit object instead, so that we honor fake parent information from info/grafts. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-28pretty_print_commit(): pass commit object instead of commit->buffer.Libravatar Junio C Hamano1-1/+2
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-28diff-tree: abbreviate merge parent object names with --abbrev --pretty.Libravatar Junio C Hamano1-5/+14
When --abbrev is in effect, abbreviate the merge parent names in prettyprinted output. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-15describe: omit clearing marks on the last one.Libravatar Junio C Hamano1-2/+4
When describing more than one, we need to clear the commit marks before handling the next one, but most of the time we are running it for only one commit, and in such a case this clearing phase is totally unnecessary. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-08GIT 1.1.0Libravatar Junio C Hamano1-1/+1
2006-01-07describe: allow more than one revs to be named.Libravatar Junio C Hamano1-0/+13
The main loop was prepared to take more than one revs, but the actual naming logic wad not (it used pop_most_recent_commit while forgetting that the commit marks stay after it's done). Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-07[PATCH] Compilation: zero-length array declaration.Libravatar Junio C Hamano1-1/+1
ISO C99 (and GCC 3.x or later) lets you write a flexible array at the end of a structure, like this: struct frotz { int xyzzy; char nitfol[]; /* more */ }; GCC 2.95 and 2.96 let you to do this with "char nitfol[0]"; unfortunately this is not allowed by ISO C90. This declares such construct like this: struct frotz { int xyzzy; char nitfol[FLEX_ARRAY]; /* more */ }; and git-compat-util.h defines FLEX_ARRAY to 0 for gcc 2.95 and empty for others. If you are using a C90 C compiler, you should be able to override this with CFLAGS=-DFLEX_ARRAY=1 from the command line of "make". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-26short circuit out of a few places where we would allocate zero bytesLibravatar Eric Wong1-0/+3
dietlibc versions of malloc, calloc and realloc all return NULL if they're told to allocate 0 bytes, causes the x* wrappers to die(). There are several more places where these calls could end up asking for 0 bytes, too... Maybe simply not die()-ing in the x* wrappers if 0/NULL is returned when the requested size is zero is a safer and easier way to go. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-16GIT 0.99.9j aka 1.0rc3Libravatar Junio C Hamano1-3/+16
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-14Fix git-rev-list "date order" with --topo-orderLibravatar Linus Torvalds1-2/+3
This fixes git-rev-list so that when there are multiple branches, we still sort the heads in proper approximate date order even when sorting the output topologically. This makes things like gitk --all -d work sanely and show the branches in date order (where "date order" is obviously modified by the paren-child dependency requirements of the topological sort). The trivial fix is to just build the "work" list in date order rather than inserting the new work entries at the beginning. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-11Add --pretty=fullerLibravatar Junio C Hamano1-7/+30
git log without --pretty showed author and author-date, while with --pretty=full showed author and committer but no dates. The new formatting option, --pretty=fuller, shows both name and timestamp for author and committer. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-02Be careful when dereferencing tags.Libravatar Junio C Hamano1-1/+1
One caller of deref_tag() was not careful enough to make sure what deref_tag() returned was not NULL (i.e. we found a tag object that points at an object we do not have). Fix it, and warn about refs that point at such an incomplete tag where needed. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-14Unlocalized isspace and friendsLibravatar Linus Torvalds1-1/+0
Do our own ctype.h, just to get the sane semantics: we want locale-independence, _and_ we want the right signed behaviour. Plus we only use a very small subset of ctype.h anyway (isspace, isalpha, isdigit and isalnum). Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-15[PATCH] Avoid wasting memory in git-rev-listLibravatar Linus Torvalds1-1/+3
As pointed out on the list, git-rev-list can use a lot of memory. One low-hanging fruit is to free the commit buffer for commits that we parse. By default, parse_commit() will save away the buffer, since a lot of cases do want it, and re-reading it continually would be unnecessary. However, in many cases the buffer isn't actually necessary and saving it just wastes memory. We could just free the buffer ourselves, but especially in git-rev-list, we actually end up using the helper functions that automatically add parent commits to the commit lists, so we don't actually control the commit parsing directly. Instead, just make this behaviour of "parse_commit()" a global flag. Maybe this is a bit tasteless, but it's very simple, and it makes a noticable difference in memory usage. Before the change: [torvalds@g5 linux]$ /usr/bin/time git-rev-list v2.6.12..HEAD > /dev/null 0.26user 0.02system 0:00.28elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+3714minor)pagefaults 0swaps after the change: [torvalds@g5 linux]$ /usr/bin/time git-rev-list v2.6.12..HEAD > /dev/null 0.26user 0.00system 0:00.27elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+2433minor)pagefaults 0swaps note how the minor faults have decreased from 3714 pages to 2433 pages. That's all due to the fewer anonymous pages allocated to hold the comment buffers and their metadata. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-29Fix compilation warnings.Libravatar Junio C Hamano1-1/+1
... found by compiling them with gcc 2.95. Signed-off-by: Junio C Hamano <junkio@cox.net>