summaryrefslogtreecommitdiff
path: root/revision.h
AgeCommit message (Collapse)AuthorFilesLines
2006-03-31Move "--parent" parsing into generic revision.c library codeLibravatar Linus Torvalds1-1/+2
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>
2006-03-28rev-list --boundaryLibravatar Junio C Hamano1-1/+3
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>
2006-03-10rev-lib: Make it easy to do rename tracking (take 2)Libravatar Fredrik Kuivinen1-1/+17
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>
2006-03-01git-log (internal): more options.Libravatar Junio C Hamano1-0/+1
This ports the following options from rev-list based git-log implementation: * -<n>, -n<n>, and -n <n>. I am still wondering if we want this natively supported by setup_revisions(), which already takes --max-count. We may want to move them in the next round. Also I am not sure if we can get away with not setting revs->limited when we set max-count. The latest rev-list.c and revision.c in this series do not, so I left them as they are. * --pretty and --pretty=<fmt>. * --abbrev=<n> and --no-abbrev. The previous commit already handles time-based limiters (--since, --until and friends). The remaining things that rev-list based git-log happens to do are not useful in a pure log-viewing purposes, and not ported: * --bisect (obviously). * --header. I am actually in favor of doing the NUL terminated record format, but rev-list based one always passed --pretty, which defeated this option. Maybe next round. * --parents. I do not think of a reason a log viewer wants this. The flag is primarily for feeding squashed history via pipe to downstream tools. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-01Rip out merge-order and make "git log <paths>..." work again.Libravatar Linus Torvalds1-0/+2
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>
2006-02-28git-rev-list libification: rev-list walkingLibravatar Linus Torvalds1-1/+5
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>
2006-02-27Splitting rev-list into revisions lib, end of beginning.Libravatar Linus Torvalds1-1/+3
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>
2006-02-26First cut at libifying revlist generationLibravatar Linus Torvalds1-0/+48
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>
2005-04-21Include <limits.h> in commit.c for ULONG_MAX. Remove old "revision.h".Libravatar Linus Torvalds1-164/+0
The old revision.h helper header isn't used any more, but I never noticed it until I started grepping for ULONG_MAX users.
2005-04-17Make the revision tracking track the object types too.Libravatar Linus Torvalds1-8/+14
This allows fsck to verify not just that an object exists, but also that it has the type it was expected to have.
2005-04-17Make "parse_commit" return the "struct revision" for the commit.Libravatar Linus Torvalds1-3/+3
Also, make it a fatal error to pass in a non-commit object. The callers never checked, so better check here. This simplifies merge-base further. It's now so trivial that it's almost ridiculous.
2005-04-17Make "revision.h" slightly better to use.Libravatar Linus Torvalds1-6/+10
- mark_reachable() can be more generic, marking the reachable revisions with an arbitrary mask. - date parsing will parse to a date of 0 rather than ULONG_MAX for the bad old case, sorting the dates correctly.
2005-04-17Move "parse_commit()" into common revision.h file.Libravatar Linus Torvalds1-0/+40
This also drops the old-style date parsing. We just don't care enough, since we dropped that format pretty early. Yes, this could do with some cleanup, and a common library file. Some day.
2005-04-13Use common "revision.h" header for both fsck and rev-tree.Libravatar Linus Torvalds1-0/+114
It's really a very generic thing: the notion of one sha1 revision referring to another one. "fsck" uses it for all nodes, and "rev-tree" only tracks commit-node relationships, but the code was already the same - now we just make that explicit by moving it to a common header file.