kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Peter Eriksen	8e44025925	Use blob_, commit_, tag_, and tree_type throughout. This replaces occurences of "blob", "commit", "tag", and "tree", where they're really used as type specifiers, which we already have defined global constants for. Signed-off-by: Peter Eriksen <s022018@student.dtu.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	bbbc8c3a8d	revision: --max-age alone does not need limit_list() anymore. This makes git log --since=7.days to be streamable. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	5306968660	revision: simplify argument parsing. This just moves code around to consolidate the part that sets revs->limited to one place based on various flags. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	22c31bf183	revision: --topo-order and --unpacked Now, using --unpacked without limit_list() does not make much sense, but this is parallel to the earlier --max-age fix. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	be7db6e574	revision: Fix --topo-order and --max-age with reachability limiting. What ends up not working very well at all is the combination of "--topo-order" and the output filter in get_revision. It will return NULL when we see the first commit out of date-order, even if we have other commits coming. So we really should do the "past the date order" thing in get_revision() only if we have _not_ done it already in limit_list(). Something like this. The easiest way to test this is with just gitk --since=3.days.ago on the kernel tree. Without this patch, it tends to be pretty obviously broken. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	2a0925be35	Make path-limiting be incremental when possible. This makes git-rev-list able to do path-limiting without having to parse all of history before it starts showing the results. This makes things like "git log -- pathname" much more pleasant to use. This is actually a pretty small patch, and the biggest part of it is purely cleanups (turning the "goto next" statements into "continue"), but it's conceptually a lot bigger than it looks. What it does is that if you do a path-limited revision list, and you do _not_ ask for pseudo-parenthood information, it won't do all the path-limiting up-front, but instead do it incrementally in "get_revision()". This is an absolutely huge deal for anything like "git log -- <pathname>", but also for some things that we don't do yet - like the "find where things changed" logic I've described elsewhere, where we want to find the previous revision that changed a file. The reason I put "RFC" in the subject line is that while I've validated it various ways, like doing git-rev-list HEAD -- drivers/char/ \| md5sum before-and-after on the kernel archive, it's "git-rev-list" after all. In other words, it's that really really subtle and complex central piece of software. So while I think this is important and should go in asap, I also think it should get lots of testing and eyeballs looking at the code. Btw, don't even bother testing this with the git archive. git itself is so small that parsing the whole revision history for it takes about a second even with path limiting. The thing that _really_ shows this off is doing git log drivers/ on the kernel archive, or even better, on the _historic_ kernel archive. With this change, the response is instantaneous (although seeking to the end of the result will obviously take as long as it ever did). Before this change, the command would think about the result for tens of seconds - or even minutes, in the case of the bigger old kernel archive - before starting to output the results. NOTE NOTE NOTE! Using path limiting with things like "gitk", which uses the "--parents" flag to actually generate a pseudo-history of the resulting commits won't actually see the improvement in interactivity, since that forces git-rev-list to do the whole-history thing after all. MAYBE we can fix that too at some point, but I won't promise anything. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	7b0c996679	Move "--parent" parsing into generic revision.c library code Not only do we do it in both rev-list.c and git.c, the revision walking code will soon want to know whether we should rewrite parenthood information or not. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	4c0fea0f11	rev-list --boundary: fix re-injecting boundary commits. Marco reported that $ git rev-list --boundary --topo-order --parents 5aa44d5..ab57c8d misses these two boundary commits. `c649657501` `eb38cc689e` Indeed, we can see that gitk shows these two commits at the bottom, because the --boundary code failed to output them. The code did not check to avoid pushing the same uninteresting commit twice to the result list. I am not sure why this fixes the reported problem, but this seems to fix it. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	0c8b106b02	revision.c "..B" syntax: constness fix The earlier change to make "..B" to mean "HEAD..B" (aka ^HEAD B) has constness gotcha GCC complains. Fix it. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	ce4a706388	revision arguments: ..B means HEAD..B, just like A.. means A..HEAD For consistency reasons, we should probably allow that to be written as just "..branch", the same way we can write "branch.." to mean "everything in HEAD but not in "branch". Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	384e99a4a9	rev-list --boundary With the new --boundary flag, the output from rev-list includes the UNINTERESING commits at the boundary, which are usually not shown. Their object names are prefixed with '-'. For example, with this graph: C side / A---B---D master You would get something like this: $ git rev-list --boundary --header --parents side..master D B tree D^{tree} parent B ... log message for commit D here ... \0-B A tree B^{tree} parent A ... log message for commit B here ... \0 Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	5cdeae71ea	rev-list --no-merges: argument parsing fix. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	fb18a2edf7	Fix error handling for nonexistent names When passing in a pathname pattern without the "--" separator on the command line, we verify that the pathnames in question exist. However, there were two bugs in that verification: - git-rev-parse would only check the first pathname, and silently allow any invalid subsequent pathname, whether it existed or not (which defeats the purpose of the check, and is also inconsistent with what git-rev-list actually does) - git-rev-list (and "git log" etc) would check each filename, but if the check failed, it would print the error using the first one, i.e.: [torvalds@g5 git]$ git log Makefile bad-file fatal: 'Makefile': No such file or directory instead of saying that it's 'bad-file' that doesn't exist. This fixes both bugs. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	c348f31ab9	revision traversal: --remove-empty fix (take #2 ). 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 makes such parent parentless. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
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

26 Commits (a13ba129cdc66b60eef177696084ff80034069b7)