kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Junio C Hamano	a41e109c4b	revision traversal: --remove-empty fix. Marco Costalba reports that --remove-empty omits the commit that created paths we are interested in. try_to_simplify_commit() logic was dropping a parent we introduced those paths against, which I think is not what we meant. Instead, this marks such parent uninteresting. The traversal does not go beyond that parent as advertised, but we still say that the current commit changed things from that parent. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Fredrik Kuivinen	8efdc326c9	rev-lib: Make it easy to do rename tracking (take 2) prune_fn in the rev_info structure is called in place of try_to_simplify_commit. This makes it possible to do rename tracking with a custom try_to_simplify_commit-like function. This commit also introduces init_revisions which initialises the rev_info structure with default values. Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	f3219fbbba	try_to_simplify_commit(): do not skip inspecting tree change at boundary. When git-rev-list (and git-log) collapsed ancestry chain to commits that touch specified paths, we failed to inspect and notice tree changes when we are about to hit uninteresting parent. This resulted in "git rev-list since.. -- file" to always show the child commit after the lower bound, even if it does not touch the file. This commit fixes it. Thanks for Catalin for reporting this. See also: `461cf59f89` Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Matthias Urlichs	d2c4af7373	Don't recurse into parents marked uninteresting. revision.c:make_parents_uninteresting() is exponential with the number of merges in the tree. That's fine -- unless some other part of git already has pulled the whole commit tree into memory ... Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	ea5ed3abce	get_revision(): do not dig deeper when we know we are at the end. This resurrects the special casing for "rev-list -n 1" which avoided reading parents unnecessarily. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	64bc6e3db5	setup_revisions(): handle -n<n> and -<n> internally. This moves the handling of max-count shorthand from the internal implementation of "git log" to setup_revisions() so other users of setup_revisions() can use it. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	fd751667a2	git-log (internal): add approxidate. Next will be the pretty-print format. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	765ac8ec46	Rip out merge-order and make "git log <paths>..." work again. Well, assuming breaking --merge-order is fine, here's a patch (on top of the other ones) that makes git log <filename> actually work, as far as I can tell. I didn't add the logic for --before/--after flags, but that should be pretty trivial, and is independent of this anyway. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	a4a88b2bab	git-rev-list libification: rev-list walking This actually moves the "meat" of the revision walking from rev-list.c to the new library code in revision.h. It introduces the new functions void prepare_revision_walk(struct rev_info revs); struct commit get_revision(struct rev_info *revs); to prepare and then walk the revisions that we have. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	d9a83684c4	Splitting rev-list into revisions lib, end of beginning. This makes the rewrite easier to validate in that revision flag parsing and warlking part are now all in rev_info structure. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	ae563542bf	First cut at libifying revlist generation This really just splits things up partially, and creates the interface to set things up by parsing the command line. No real code changes so far, although the parsing of filenames is a bit stricter. In particular, if there is a "--", then we do not accept any filenames before it, and if there isn't any "--", then we check that _all_ paths listed are valid, not just the first one. The new argument parsing automatically also gives us "--default" and "--not" handling as in git-rev-parse. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago

1 2 3

129 Commits (8e3d436b0b5148bac11259bac55621e285eeb6c4)