aboutsummaryrefslogtreecommitdiff
path: root/revision.c
Commit message (Collapse)AuthorAge
* git log: Unify header_filter and message_filter into one.Junio C Hamano2006-09-20
| | | | | | | | | | | | | | | | | | | | Now we can tell the built-in grep to grep only in head or in body, use that to update --author, --committer, and --grep. Unfortunately, to make --and, --not and other grep boolean expressions useful, as in: # Things written by Junio committed and by Linus and log # does not talk about diff. git log --author=Junio --and --committer=Linus \ --grep-not --grep=diff we will need to do another round of built-in grep core enhancement, because grep boolean expressions are designed to work on one line at a time. Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-log --author and --committer are not left-anchored by defaultLinus Torvalds2006-09-20
| | | | | | | | | | | | I know that I'd prefer a rule where "--author=^Junio" would result in the grep-pattern being "^author Junio", but without the initial '^' it would be "^author .*Junio". Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* revision traversal: --author, --committer, and --grep.Junio C Hamano2006-09-20
| | | | | | | | This adds three options to setup_revisions(), which lets you filter resulting commits by the author name, the committer name and the log message with regexp. Signed-off-by: Junio C Hamano <junkio@cox.net>
* revision traversal: prepare for commit log match.Junio C Hamano2006-09-20
| | | | | | | | | This is from a suggestion by Linus, just to mark the locations where we need to modify to actually implement the filtering. We do not have any actual filtering code yet. Signed-off-by: Junio C Hamano <junkio@cox.net>
* pack-objects --unpacked=<existing pack> option.Junio C Hamano2006-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Incremental repack without -a essentially boils down to: rev-list --objects --unpacked --all | pack-objects $new_pack which picks up all loose objects that are still live and creates a new pack. This implements --unpacked=<existing pack> option to tell the revision walking machinery to pretend as if objects in such a pack are unpacked for the purpose of object listing. With this, we could say: rev-list --objects --unpacked=$active_pack --all | pack-objects $new_pack instead, to mean "all live loose objects but pretend as if objects that are in this pack are also unpacked". The newly created pack would be perfect for updating $active_pack by replacing it. Since pack-objects now knows how to do the rev-list's work itself internally, you can also write the above example by: pack-objects --unpacked=$active_pack --all $new_pack </dev/null Signed-off-by: Junio C Hamano <junkio@cox.net>
* revision.c: allow injecting revision parameters after setup_revisions().Junio C Hamano2006-09-05
| | | | | | | | | | | | | | | | | | setup_revisions() wants to get all the parameters at once and then postprocesses the resulting revs structure after it is done with them. This code structure is a bit cumbersome to deal with efficiently when we want to inject revision parameters from the side (e.g. read from standard input). Fortunately, the nature of this postprocessing is not affected by revision parameters; they are affected only by flags. So it is Ok to do add_object() after the it returns. This splits out the code that deals with the revision parameter out of the main loop of setup_revisions(), so that we can later call it from elsewhere after it returns. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Add --relative-date option to the revision interfaceJonas Fonseca2006-08-28
| | | | | | | Exposes the infrastructure from 9a8e35e98793af086f05d1ca9643052df9b44a74. Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Convert memcpy(a,b,20) to hashcpy(a,b).Shawn Pearce2006-08-23
| | | | | | | | | | | | | | | | | | | | | | | 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>
* check return value from diff_setup_done()Junio C Hamano2006-08-09
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* Call setup_git_directory() earlyLinus Torvalds2006-07-28
| | | | | | | | | | | | | | | Any git command that expects to work in a subdirectory of a project, and that reads the git config files (which is just about all of them) needs to make sure that it does the "setup_git_directory()" call before it tries to read the config file. This means, among other things, that we need to move the call out of "init_revisions()", and into the caller. This does the mostly trivial conversion to do that. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Remove TYPE_* constant macros and use object_type enums consistently.Linus Torvalds2006-07-12
| | | | | | | | | | | | | | | This updates the type-enumeration constants introduced to reduce the memory footprint of "struct object" to match the type bits already used in the packfile format, by removing the former (i.e. TYPE_* constant macros) and using the latter (i.e. enum object_type) throughout the code for consistency. Eventually we can stop passing around the "type strings" entirely, and this will help - no confusion about two different integer enumeration. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git log -p --merge [[--] paths...]Junio C Hamano2006-07-07
| | | | | | | | | | This adds Linus's wish, "--merge" flag, which makes the above expand to a rough equivalent to: git log -p HEAD MERGE_HEAD ^$(git-merge-base HEAD MERGE_HEAD) \ -- $(git-ls-files -u [paths...] | cut -f2 | uniq) Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge branch 'js/merge-base'Junio C Hamano2006-07-06
|\
| * rev-list: free commit_list in ... handlerRene Scharfe2006-07-04
| | | | | | | | | | | | | | | | | | | | Johannes noticed the missing call to free_commit_list() in the patch from Santi to add ... support to rev-parse. Turns out I forgot it too in rev-list. This patch is against the next branch (3b1d06a). Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
| * Merge branch 'master' into js/merge-baseJunio C Hamano2006-07-03
| |\ | | | | | | | | | This is to pull in the object-hash clean-up from the master branch.
| * | Fold get_merge_bases_clean() into get_merge_bases()Rene Scharfe2006-07-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | Add '...' operator for revisionsRene Scharfe2006-07-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'A...B' is a shortcut for 'A B --not $(git-merge-base --all A B)'. This XOR-like operation is called symmetric difference in set theory. The symbol '...' has been chosen because it's rather similar to the existing '..' operator and the somewhat more natural caret ('^') is already taken. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | Merge branch 'th/diff'Junio C Hamano2006-07-05
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * th/diff: builtin-diff: turn recursive on when defaulting to --patch format. t4013: note improvements brought by the new output code. t4013: add format-patch tests. format-patch: fix diff format option implementation combine-diff.c: type sanity. t4013 test updates for new output code. Fix some more diff options changes. Fix diff-tree -s log --raw: Don't descend into subdirectories by default diff-tree: Use ---\n as a message separator Print empty line between raw, stat, summary and patch t4013: add more tests around -c and --cc whatchanged: Default to DIFF_FORMAT_RAW Don't xcalloc() struct diffstat_t Add msg_sep to diff_options DIFF_FORMAT_RAW is not default anymore Set default diff output format after parsing command line Make --raw option available for all diff commands Merge with_raw, with_stat and summary variables to output_format t4013: add tests for diff/log family output options.
| * | DIFF_FORMAT_RAW is not default anymoreTimo Hirvonen2006-06-26
| |/ | | | | | | | | | | | | | | | | diff_setup() used to initialize output_format to DIFF_FORMAT_RAW. Now the default is 0 (no output) so don't compare against DIFF_FORMAT_RAW to see if any diff format command line flags were given. Signed-off-by: Timo Hirvonen <tihirvon@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | revision.c: fix "dense" under --remove-emptyLinus Torvalds2006-07-02
| | | | | | | | | | | | | | | | | | | | It had the wrong test for whether a commit was a merge. What it did was to say that a non-merge has exactly one parent (which sounds almost right), but the fact is, initial trees have no parent at all, but they're obviously not merges. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | revision.c: --full-history fix.Linus Torvalds2006-07-01
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With history simplification, we still show merges that are required to make the history _complete_, i.e. say that you had: a | b / \ c d | | and neither "a" nor "b" actually changed the file, but both "c" and "d" did: in this case we have to leave "b" around just because otherwise there would be no way to show the _relationship_, even if "b" itself doesn't actually change the tree in any way what-so-ever. It would make sense to make that further simplification if the "--parents" flag wasn't present. In that case the user is literally asking for a list of commits and is not interested in the relationship between them. This patch also fixes a real bug. Without this patch, the "--parents --full-history" combination (which you'd get if you do something like gitk --full-history Makefile or similar) will actually _drop_ merges where all children are identical. That's wrong in the --full-history case, because it means that the graph ends up missing lots of entries. In the process, this also should make git-rev-list --full-history Makefile give just the _true_ list of all commits that changed Makefile (and properly ignore merges that were identical in one parent), because now we're not asking for "--parent", so we don't need the unnecessary merge commits to keep the history together. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Add "named object array" conceptLinus Torvalds2006-06-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Some more memory leak avoidanceLinus Torvalds2006-06-17
| | | | | | | | | | | | | | | | | | | | | | | | This is really the dregs of my effort to not waste memory in git-rev-list, and makes barely one percent of a difference in the memory footprint, but hey, it's also a pretty small patch. It discards the parent lists and the commit buffer after the commit has been shown by git-rev-list (and "git log" - which already did the commit buffer part), and frees the commit list entry that was used by the revision walker. The big win would be to get rid of the "refs" pointer in the object structure (another 5%), because it's only used by fsck. That would require some pretty major surgery to fsck, though, so I'm timid and did the less interesting but much easier part instead. This (percentually) makes a bigger difference to "git log" and friends, since those are walking _just_ commits, and thus the list entries tend to be a bigger percentage of the memory use. But the "list all objects" case does improve too. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Shrink "struct object" a bitLinus Torvalds2006-06-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* gitweb.cgi history not shownLinus Torvalds2006-06-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This does: - add a "rev.simplify_history" flag which defaults to on - it turns it off for "git whatchanged" (which thus now has real semantics outside of "git log") - it adds a command line flag ("--full-history") to turn it off for others (ie you can make "git log" and "gitk" etc get the semantics if you want to. Now, just as an example of _why_ you really really really want to simplify history by default, apply this patch, install it, and try these two command lines: gitk --full-history -- git.c gitk -- git.c and compare the output. So with this, you can also now do git whatchanged -p -- gitweb.cgi git log -p --full-history -- gitweb.cgi and it will show the old history of gitweb.cgi, even though it's not relevant to the _current_ state of the name "gitweb.cgi" NOTE NOTE NOTE! It will still actually simplify away merges that didn't change anything at all into either child. That creates these bogus strange discontinuities if you look at it with "gitk" (look at the --full-history gitk output for git.c, and you'll see a few strange cases). So the whole "--parent" thing ends up somewhat bogus with --full-history because of this, but I'm not sure it's worth even worrying about. I don't think you'd ever want to really use "--full-history" with the graphical representation, I just give it as an example exactly to show _why_ doing so would be insane. I think this is trivial enough and useful enough to be worth merging into the stable branch. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* tree_entry(): new tree-walking helper functionLinus Torvalds2006-05-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a "tree_entry()" function that combines the common operation of doing a "tree_entry_extract()" + "update_tree_entry()". It also has a simplified calling convention, designed for simple loops that traverse over a whole tree: the arguments are pointers to the tree descriptor and a name_entry structure to fill in, and it returns a boolean "true" if there was an entry left to be gotten in the tree. This allows tree traversal with struct tree_desc desc; struct name_entry entry; desc.buf = tree->buffer; desc.size = tree->size; while (tree_entry(&desc, &entry) { ... use "entry.{path, sha1, mode, pathlen}" ... } which is not only shorter than writing it out in full, it's hopefully less error prone too. [ It's actually a tad faster too - we don't need to recalculate the entry pathlength in both extract and update, but need to do it only once. Also, some callers can avoid doing a "strlen()" on the result, since it's returned as part of the name_entry structure. However, by now we're talking just 1% speedup on "git-rev-list --objects --all", and we're definitely at the point where tree walking is no longer the issue any more. ] NOTE! Not everybody wants to use this new helper function, since some of the tree walkers very much on purpose do the descriptor update separately from the entry extraction. So the "extract + update" sequence still remains as the core sequence, this is just a simplified interface. We should probably add a silly two-line inline helper function for initializing the descriptor from the "struct tree" too, just to cut down on the noise from that common "desc" initializer. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Convert "mark_tree_uninteresting()" to raw tree walkerLinus Torvalds2006-05-29
| | | | | | | Not very many users to go.. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Remove "tree->entries" tree-entry list from tree parserLinus Torvalds2006-05-29
| | | | | | | | | | | | | | | | | Instead, just use the tree buffer directly, and use the tree-walk infrastructure to walk the buffers instead of the tree-entry list. The tree-entry list is inefficient, and generates tons of small allocations for no good reason. The tree-walk infrastructure is generally no harder to use than following a linked list, and allows us to do most tree parsing in-place. Some programs still use the old tree-entry lists, and are a bit painful to convert without major surgery. For them we have a helper function that creates a temporary tree-entry list on demand. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Make "tree_entry" have a SHA1 instead of a union of object pointersLinus Torvalds2006-05-29
| | | | | | | | This is preparatory work for further cleanups, where we try to make tree_entry look more like the more efficient tree-walk descriptor. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Fix "--abbrev=xyz" for revision listingLinus Torvalds2006-05-28
| | | | | | | | | | | | | | | | | | | The revision argument parsing was happily parsing "--abbrev", but it didn't parse "--abbrev=<n>". Which was hidden by the fact that the diff options _would_ parse --abbrev=<n>, so it would actually silently parse it, it just wouldn't use it for the same things that a plain "--abbrev" was used for. Which seems a bit insane. With this patch, if you do "git log --abbrev=10" it will abbreviate the merge parent commit ID's to ten hex characters, which was probably what you expected. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge branch 'fix'Junio C Hamano2006-05-08
|\ | | | | | | | | | | | | | | * fix: Separate object name errors from usage errors Documentation: {caret} fixes (git-rev-list.txt) Fix "git diff --stat" with long filenames Fix repo-config set-multivar error return path.
| * Separate object name errors from usage errorsDmitry V. Levin2006-05-08
| | | | | | | | | | | | | | Separate object name errors from usage errors. Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Merge branch 'jc/diff'Junio C Hamano2006-05-03
|\ \ | | | | | | | | | | | | | | | | | | | | | * jc/diff: builtin-diff: call it "git-diff", really. builtin-diff.c: die() formatting type fix. built-in diff: assorted updates. built-in diff.
| * | built-in diff: assorted updates.Junio C Hamano2006-04-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "git diff(n)" without --base, --ours, etc. defaults to --cc, which usually is the same as -p unless you are in the middle of a conflicted merge, just like the shell script version. "git diff(n) blobA blobB path" complains and dies. "git diff(n) tree0 tree1 tree2...treeN" does combined diff that shows a merge of tree1..treeN to result in tree0. Giving "-c" option to any command that defaults to "--cc" turns off dense-combined flag. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | Merge branch 'fix'Junio C Hamano2006-05-03
|\ \ \ | | |/ | |/| | | | | | | * fix: fix various typos in documentation
| * | fix various typos in documentationMatthias Kestenholz2006-05-03
| | | | | | | | | | | | | | | Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | Merge branch 'jc/xsha1-2'Junio C Hamano2006-05-01
|\ \ \ | | | | | | | | | | | | | | | | * jc/xsha1-2: Extended SHA1 -- "rev^@" syntax to mean "all parents"
| * | | Extended SHA1 -- "rev^@" syntax to mean "all parents"Junio C Hamano2006-04-30
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A short-hand "rev^@" is understood to be "all parents of the named commit" with this patch. So you can do git show v1.0.0^@ to view the parents of a merge commit, gitk ^v1.0.0^@ v1.0.4 to view the log between two revs (including the bottom one), and git diff --cc v1.1.0 v1.0.0^@ to inspect what got changed from the merge parents of v1.0.0 to v1.1.0. This might be just my shiny new toy that is not very useful in practice. I needed it to do the multi-tree diff on Len's infamous 12-way Octopus; typing "diff --cc funmerge funmerge^1 funmerge^2 funmerge^3 ..." was too painful. [jc: taking suggestions from Linus and Johannes to match expectations from shell users who are used to see $@ or $* either of which makes sense. I tend to write "$@" more often so...] Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | revision parsing: make "rev -- paths" checks stronger.Junio C Hamano2006-04-26
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you don't have a "--" marker, then: - all of the arguments we are going to assume are pathspecs must exist in the working tree. - none of the arguments we parsed as revisions could be interpreted as a filename. so that there really isn't any possibility of confusion in case somebody does have a revision that looks like a pathname too. The former rule has been in effect; this implements the latter. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Merge branch 'fix'Junio C Hamano2006-04-26
|\ \ | |/ | | | | | | | | | | | | * fix: commit-tree.c: check_valid() microoptimization. Fix filename verification when in a subdirectory rebase: typofix. socksetup: don't return on set_reuse_addr() error
| * Fix filename verification when in a subdirectoryLinus Torvalds2006-04-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we are in a subdirectory of a git archive, we need to take the prefix of that subdirectory into accoung when we verify filename arguments. Noted by Matthias Lederhofer This also uses the improved error reporting for all the other git commands that use the revision parsing interfaces, not just git-rev-parse. Also, it makes the error reporting for mixed filenames and argument flags clearer (you cannot put flags after the start of the pathname list). [jc: with fix to a trivial typo noticed by Timo Hirvonen] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Fix "git show --stat"Junio C Hamano2006-04-21
| | | | | | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Fix uninteresting tags in new revision parsingLinus Torvalds2006-04-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When I unified the revision argument parsing, I introduced a simple bug wrt tags that had been marked uninteresting. When it was preparing for the revision walk, it would mark all the parent commits of an uninteresting tag correctly uninteresting, but it would forget about the commit itself. This means that when I just did my 2.6.17-rc2 release, and my scripts generated the log for "v2.6.17-rc1..v2.6.17-rc2", everything was fine, except the commit pointed to by 2.6.17-rc1 (which shouldn't have been there) was included. Even though it should obviously have been marked as being uninteresting. Not a huge deal, and the fix is trivial. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Merge branch 'lt/logopt'Junio C Hamano2006-04-18
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * lt/logopt: Fix "git log --stat": make sure to set recursive with --stat. combine-diff: show diffstat with the first parent. git.c: LOGSIZE is unused after log printing cleanup. Log message printout cleanups (#3): fix --pretty=oneline Log message printout cleanups (#2) Log message printout cleanups rev-list --header: output format fix Fixes for option parsing log/whatchanged/show - log formatting cleanup. Simplify common default options setup for built-in log family. Tentative built-in "git show" Built-in git-whatchanged. rev-list option parser fix. Split init_revisions() out of setup_revisions() Fix up rev-list option parsing. Fix up default abbrev in setup_revisions() argument parser. Common option parsing for "git log --diff" and friends
| * Fix "git log --stat": make sure to set recursive with --stat.Junio C Hamano2006-04-18
| | | | | | | | | | | | | | Just like "patch" format always needs recursive, "diffstat" format does not make sense without setting recursive. Signed-off-by: Junio C Hamano <junkio@cox.net>
| * Log message printout cleanupsLinus Torvalds2006-04-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Sun, 16 Apr 2006, Junio C Hamano wrote: > > In the mid-term, I am hoping we can drop the generate_header() > callchain _and_ the custom code that formats commit log in-core, > found in cmd_log_wc(). Ok, this was nastier than expected, just because the dependencies between the different log-printing stuff were absolutely _everywhere_, but here's a patch that does exactly that. The patch is not very easy to read, and the "--patch-with-stat" thing is still broken (it does not call the "show_log()" thing properly for merges). That's not a new bug. In the new world order it _should_ do something like if (rev->logopt) show_log(rev, rev->logopt, "---\n"); but it doesn't. I haven't looked at the --with-stat logic, so I left it alone. That said, this patch removes more lines than it adds, and in particular, the "cmd_log_wc()" loop is now a very clean: while ((commit = get_revision(rev)) != NULL) { log_tree_commit(rev, commit); free(commit->buffer); commit->buffer = NULL; } so it doesn't get much prettier than this. All the complexity is entirely hidden in log-tree.c, and any code that needs to flush the log literally just needs to do the "if (rev->logopt) show_log(...)" incantation. I had to make the combined_diff() logic take a "struct rev_info" instead of just a "struct diff_options", but that part is pretty clean. This does change "git whatchanged" from using "diff-tree" as the commit descriptor to "commit", and I changed one of the tests to reflect that new reality. Otherwise everything still passes, and my other tests look fine too. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
| * Tentative built-in "git show"Linus Torvalds2006-04-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This uses the "--no-walk" flag that I never actually implemented (but I'm sure I mentioned it) to make "git show" be essentially the same thing as "git whatchanged --no-walk". It just refuses to add more interesting parents to the revision walking history, so you don't actually get any history, you just get the commit you asked for. I was going to add "--no-walk" as a real argument flag to git-rev-list too, but I'm not sure anybody actually needs it. Although it might be useful for porcelain, so I left the door open. [jc: ported to the unified option structure by Linus] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
| * Split init_revisions() out of setup_revisions()Junio C Hamano2006-04-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Merging all three option parsers related to whatchanged is unarguably the right thing, but the fallout was too big to scare me away. Let's try it once again, but once step at time. This splits out init_revisions() call from setup_revisions(), so that the callers can set different defaults to match the traditional benaviour. The rev-list command is still broken in a big way, which is the topic of next step. Signed-off-by: Junio C Hamano <junkio@cox.net>
| * Fix up default abbrev in setup_revisions() argument parser.Junio C Hamano2006-04-14
| | | | | | | | | | | | The default abbreviation precision should be DEFAULT_ABBREV as before. Signed-off-by: Junio C Hamano <junkio@cox.net>
| * Common option parsing for "git log --diff" and friendsLinus Torvalds2006-04-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This basically does a few things that are sadly somewhat interdependent, and nontrivial to split out - get rid of "struct log_tree_opt" The fields in "log_tree_opt" are moved into "struct rev_info", and all users of log_tree_opt are changed to use the rev_info struct instead. - add the parsing for the log_tree_opt arguments to "setup_revision()" - make setup_revision set a flag (revs->diff) if the diff-related arguments were used. This allows "git log" to decide whether it wants to show diffs or not. - make setup_revision() also initialize the diffopt part of rev_info (which we had from before, but we just didn't initialize it) - make setup_revision() do all the "finishing touches" on it all (it will do the proper flag combination logic, and call "diff_setup_done()") Now, that was the easy and straightforward part. The slightly more involved part is that some of the programs that want to use the new-and-improved rev_info parsing don't actually want _commits_, they may want tree'ish arguments instead. That meant that I had to change setup_revision() to parse the arguments not into the "revs->commits" list, but into the "revs->pending_objects" list. Then, when we do "prepare_revision_walk()", we walk that list, and create the sorted commit list from there. This actually cleaned some stuff up, but it's the less obvious part of the patch, and re-organized the "revision.c" logic somewhat. It actually paves the way for splitting argument parsing _entirely_ out of "revision.c", since now the argument parsing really is totally independent of the commit walking: that didn't use to be true, since there was lots of overlap with get_commit_reference() handling etc, now the _only_ overlap is the shared (and trivial) "add_pending_object()" thing. However, I didn't do that file split, just because I wanted the diff itself to be smaller, and show the actual changes more clearly. If this gets accepted, I'll do further cleanups then - that includes the file split, but also using the new infrastructure to do a nicer "git diff" etc. Even in this form, it actually ends up removing more lines than it adds. It's nice to note how simple and straightforward this makes the built-in "git log" command, even though it continues to support all the diff flags too. It doesn't get much simpler that this. I think this is worth merging soonish, because it does allow for future cleanup and even more sharing of code. However, it obviously touches "revision.c", which is subtle. I've tested that it passes all the tests we have, and it passes my "looks sane" detector, but somebody else should also give it a good look-over. [jc: squashed the original and three "oops this too" updates, with another fix-up.] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>