summaryrefslogtreecommitdiff
path: root/revision.h
AgeCommit message (Collapse)AuthorFilesLines
2008-04-10log: teach "terminator" vs "separator" mode to "--pretty=format"Libravatar Junio C Hamano1-1/+2
This attached patch introduces a single bit "use_terminator" in "struct rev_info", which is normally false (i.e. most formats use separator semantics) but by flipping it to true, you can ask for terminator semantics just like oneline format does. The function get_commit_format(), which is what parses "--pretty=" option, now takes a pointer to "struct rev_info" and updates its commit_format and use_terminator fields. It used to return the value of type "enum cmit_fmt", but all the callers assigned it to rev->commit_format. There are only two cases the code turns use_terminator on. Obviously, the traditional oneline format (--pretty=oneline) is one of them, and the new case is --pretty=tformat:... that acts like --pretty=format:... but flips the bit on. With this, "--pretty=tformat:%H %s" acts like --pretty=oneline. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-27Merge branch 'db/cover-letter'Libravatar Junio C Hamano1-1/+1
* db/cover-letter: Improve collection of information for format-patch --cover-letter Add API access to shortlog t4014: Replace sed's non-standard 'Q' by standard 'q' Support a --cc=<email> option in format-patch Combine To: and Cc: headers Fix format.headers not ending with a newline Add tests for extra headers in format-patch Add a --cover-letter option to format-patch Export some email and pretty-printing functions Improve message-id generation flow control for format-patch Add more tests for format-patch Conflicts: builtin-log.c builtin-shortlog.c pretty.c
2008-02-19Improve message-id generation flow control for format-patchLibravatar Daniel Barkalow1-1/+1
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13Add "--show-all" revision walker flag for debuggingLibravatar Linus Torvalds1-0/+1
It's really not very easy to visualize the commit walker, because - on purpose - it obvously doesn't show the uninteresting commits! This adds a "--show-all" flag to the revision walker, which will make it show uninteresting commits too, and they'll have a '^' in front of them (it also fixes a logic error for !verbose_header for boundary commits - we should show the '-' even if left_right isn't shown). A separate patch to gitk to teach it the new '^' was sent to paulus. With the change in place, it actually is interesting even for the cases that git doesn't have any problems with, ie for the kernel you can do: gitk -d --show-all v2.6.24.. and you see just how far down it has to parse things to see it all. The use of "-d" is a good idea, since the date-ordered toposort is much better at showing why it goes deep down (ie the date of some of those commits after 2.6.24 is much older, because they were merged from trees that weren't rebased). So I think this is a useful feature even for non-debugging - just to visualize what git does internally more. When it actually breaks out due to the "everybody_uninteresting()" case, it adds the uninteresting commits (both the one it's looking at now, and the list of pending ones) to the list This way, we really list *all* the commits we've looked at. Because we now end up listing commits we may not even have been parsed at all "show_log" and "show_commit" need to protect against commits that don't have a commit buffer entry. That second part is debatable just how it should work. Maybe we shouldn't show such entries at all (with this patch those entries do get shown, they just don't get any message shown with them). But I think this is a useful case. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-11shortlog: default to HEAD when the standard input is a ttyLibravatar Junio C Hamano1-0/+2
Instead of warning the user that it is expecting git log output from the standard input (and waiting for the user to type the log from the keyboard, which is a silly thing to do), default to traverse from HEAD when there is no rev parameter given and the standard input is a tty. This factors out a useful helper "add_head()" from builtin-diff.c to a more appropriate place revision.c while renaming it to more descriptive name add_head_to_pending(), as that is what the function is about. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-14Fix parent rewriting in --early-outputLibravatar Linus Torvalds1-1/+1
We cannot tell a node that has been checked and found not to be interesting (which does not have the TREECHANGE flag) from a node that hasn't been checked if it is interesting or not, without relying on something else, such as object->parsed. But an object can get the "parsed" flag for other reasons. Which means that "TREECHANGE" has the wrong polarity. This changes the way how the path pruning logic marks an uninteresting commits. From now on, we consider a commit interesting by default, and explicitly mark the ones we decided to prune. The flag is renamed to "TREESAME". Then, this fixes the logic to show the early output with incomplete pruning. It basically says "a commit that has TREESAME set is kind-of-UNINTERESTING", but obviously in a different way than an outright UNINTERESTING commit. Until we parse and examine enough parents to determine if a commit becomes surely "kind-of-UNINTERESTING", we avoid rewriting the ancestry so that later rounds can fix things up. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05revision walker: mini clean-upLibravatar Linus Torvalds1-4/+1
This removes the unnecessary indirection of "revs->prune_fn", since that function is always the same one (or NULL), and there is in fact not even an abstraction reason to make it a function (i.e. its not called from some other file and doesn't allow us to keep the function itself static or anything like that). It then just replaces it with a bit that says "prune or not", and if not pruning, every commit gets TREECHANGE. That in turn means that - if (!revs->prune_fn || (flags & TREECHANGE)) - if (revs->prune_fn && !(flags & TREECHANGE)) just become - if (flags & TREECHANGE) - if (!(flags & TREECHANGE)) respectively. Together with adding the "single_parent()" helper function, the "complex" conditional now becomes if (!(flags & TREECHANGE) && rev->dense && single_parent(commit)) continue; Also indirection of "revs->dense" checking is thrown away the same way, because TREECHANGE bit is set appropriately now. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05Enhance --early-output formatLibravatar Linus Torvalds1-0/+8
This makes --early-output a bit more advanced, and actually makes it generate multiple "Final output:" headers as it updates things asynchronously. I realize that the "Final output:" line is now illogical, since it's not really final until it also says "done", but It now _always_ generates a "Final output:" header in front of any commit list, and that output header gives you a *guess* at the maximum number of commits available. However, it should be noted that the guess can be completely off: I do a reasonable job estimating it, but it is not meant to be exact. So what happens is that you may get output like this: - at 0.1 seconds: Final output: 2 incomplete .. 2 commits listed .. - half a second later: Final output: 33 incomplete .. 33 commits listed .. - another half a second after that: Final output: 71 incomplete .. 71 commits listed .. - another half second later: Final output: 136 incomplete .. 100 commits listed: we hit the --early-output limit, and .. will only output 100 commits, and after this you'll not .. see an "incomplete" report any more since you got as much .. early output as you asked for! - .. and then finally: Final output: 73106 done .. all the commits .. The above is a real-life scenario on my current kernel tree after having flushed all the caches. Tested with the experimental gitk patch that Paul sent out, and by looking at the actual log output (and verifying that my commit count guesses actually match real life fairly well). Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-04Add "--early-output" log flag for interactive GUI useLibravatar Linus Torvalds1-0/+4
This adds support for "--early-output[=n]" as a flag to the "git log" family of commands. This allows GUI programs to state that they want to get some output early, in order to be able to show at least something quickly, even if the full output may take longer to generate. If no count is specified, a default count of a hundred commits will be used, although the actual numbr of commits output may be smaller depending on how many commits were actually found in the first tenth of a second (or if *everything* was found before that, in which case no early output will be provided, and only the final list is made available). When the full list is generated, there will be a "Final output:" string prepended to it, regardless of whether any early commits were shown or not, so that the consumer can always know the difference between early output and the final list. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-04Simplify topo-sort logicLibravatar Linus Torvalds1-3/+1
.. by not using quite so much indirection. This currently grows the "struct commit" a bit, which could be avoided by using a union for "util" and "indegree" (the topo-sort used to use "util" anyway, so you cannot use them together), but for now the goal of this was to simplify, not optimize. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-08-14Add --log-size to git log to print message sizeLibravatar Marco Costalba1-0/+1
With this option git-log prints log message size just before the corresponding message. Porcelain tools could use this to speedup parsing of git-log output. Note that size refers to log message only. If also patch content is shown its size is not included. In case it is not possible to know the size upfront size value is set to zero. Signed-off-by: Marco Costalba <mcostalba@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-08More missing staticLibravatar Junio C Hamano1-3/+0
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-05-06Handle return code of parse_commit in revision machineryLibravatar Alex Riesen1-1/+1
This fixes a crash in broken repositories where random commits suddenly disappear. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-25Add --date={local,relative,default}Libravatar Junio C Hamano1-2/+2
This adds --date={local,relative,default} option to log family of commands, to allow displaying timestamps in user's local timezone, relative time, or the default format. Existing --relative-date option is a synonym of --date=relative; we could probably deprecate it in the long run. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-24store mode in rev_list, if <tree>:<filename> syntax is usedLibravatar Martin Koegler1-0/+1
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-11git-log --cherry-pick A...BLibravatar Junio C Hamano1-0/+1
This is meant to be a saner replacement for "git-cherry". When used with "A...B", this filters out commits whose patch text has the same patch-id as a commit on the other side. It would probably most useful to use with --left-right. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-11Add custom subject prefix support to format-patch (take 3)Libravatar Robin H. Johnson1-0/+1
Add a new option to git-format-patch, entitled --subject-prefix that allows control of the subject prefix '[PATCH]'. Using this option, the text 'PATCH' is replaced with whatever input is provided to the option. This allows easily generating patches like '[PATCH 2.6.21-rc3]' or properly numbered series like '[-mm3 PATCH N/M]'. This patch provides the implementation and documentation. Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-14git-log --first-parent: show only the first parent logLibravatar Junio C Hamano1-1/+2
If your development history does not have fast-forward merges, i.e. the "first parent" of commits in your history are special than other parents, this option gives a better overview of the evolution of a particular branch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-11Merge branch 'jc/boundary'Libravatar Junio C Hamano1-3/+6
* jc/boundary: git-bundle: prevent overwriting existing bundles git-bundle: die if a given ref is not included in bundle git-bundle: handle thin packs in subcommand "unbundle" git-bundle: Make thin packs git-bundle: avoid packing objects which are in the prerequisites bundle: fix wrong check of read_header()'s return value & add tests revision --boundary: fix uncounted case. revision --boundary: fix stupid typo git-bundle: make verify a bit more chatty. revision traversal: SHOWN means shown git-bundle: various fixups revision traversal: retire BOUNDARY_SHOW revision walker: Fix --boundary when limited
2007-03-06revision traversal: retire BOUNDARY_SHOWLibravatar Junio C Hamano1-2/+1
This removes the flag internally used by revision traversal to decide which commits are indeed boundaries and renames it to CHILD_SHOWN. builtin-bundle uses the symbol for its verification, but I think the logic it uses it is wrong. The flag is still useful but it is local to the git-bundle, so it is renamed to PREREQ_MARK. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-06revision walker: Fix --boundary when limitedLibravatar Junio C Hamano1-2/+6
This cleans up the boundary processing in the commit walker. It - rips out the boundary logic from the commit walker. Placing "negative" commits in the revs->commits list was Ok if all we cared about "boundary" was the UNINTERESTING limiting case, but conceptually it was wrong. - makes get_revision_1() function to walk the commits and return the results as if there is no funny postprocessing flags such as --reverse, --skip nor --max-count. - makes get_revision() function the postprocessing phase: If reverse is given, wait for get_revision_1() to give everything that it would normally give, and then reverse it before consuming. If skip is given, skip that many before going further. If max is given, stop when we gave out that many. Now that we are about to return one positive commit, mark the parents of that commit to be potential boundaries before returning, iff we are doing the boundary processing. Return the commit. - After get_revision() finishes giving out all the positive commits, if we are doing the boundary processing, we look at the parents that we marked as potential boundaries earlier, see if they are really boundaries, and give them out. It loses more code than it adds, even when the new gc_boundary() function, which is purely for early optimization, is counted. Note that this patch is purely for eyeballing and discussion only. It breaks git-bundle's verify logic because the logic does not use BOUNDARY_SHOW flag for its internal computation anymore. After we correct it not to attempt to affect the boundary processing by setting the BOUNDARY_SHOW flag, we can remove BOUNDARY_SHOW from revision.h and use that bit assignment for the new CHILD_SHOWN flag. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-04format-patch: add --inline option and make --attach a true attachmentLibravatar Johannes Schindelin1-0/+1
The existing --attach option did not create a true "attachment" but multipart/mixed with Content-Disposition: inline. It should have been with Content-Disposition: attachment. Introduce --inline to add multipart/mixed that is inlined, and make --attach to create an attachement. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-20Teach revision machinery about --reverseLibravatar Johannes Schindelin1-1/+2
The option --reverse reverses the order of the commits. [jc: with comments on rev_info.reverse from Simon 'corecode' Schubert.] Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-20Teach the revision walker to walk by reflogs with --walk-reflogsLibravatar Johannes Schindelin1-0/+2
When called with "--walk-reflogs", as long as there are reflogs available, the walker will take this information into account, rather than the parent information in the commit object. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-26Teach log family --encodingLibravatar Junio C Hamano1-0/+1
Updated commit objects record the encoding used in their encoding header. This updates the log family to reencode it into the encoding specified in i18n.commitencoding (or the default, which is "utf-8") upon output. To force a specific encoding that is different, log family takes command line flag --encoding=<encoding>; giving --encoding=none entirely disables the reencoding and lets you view log messges in their original encoding. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-25Merge branch 'jc/skip-count'Libravatar Junio C Hamano1-0/+1
* jc/skip-count: revision: --skip=<n>
2006-12-20revision: --skip=<n>Libravatar Junio C Hamano1-0/+1
This adds --skip=<n> option to revision traversal machinery. Documentation and test were added by Robert Fitzsimons. Signed-off-by: Robert Fitzsimons <robfitz@273k.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-19Revert "Make left-right automatic."Libravatar Junio C Hamano1-1/+0
This reverts commit 5761231975ceffa531d86d9bab0f9a9a370674f6. Feeding symmetric difference to gitk is so useful, and it is the same for other graphical Porcelains. Rather than forcing them to pass --no-left-right, making it optional. Noticed and reported by Jeff King.
2006-12-17Make left-right automatic.Libravatar Junio C Hamano1-0/+1
When using symmetric differences, I think the user almost always would want to know which side of the symmetry each commit came from. So this removes --left-right option from the command line, and turns it on automatically when a symmetric difference is used ("git log --merge" counts as a symmetric difference between HEAD and MERGE_HEAD). Just in case, a new option --no-left-right is provided to defeat this, but I do not know if it would be useful. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-17Teach all of log family --left-right output.Libravatar Junio C Hamano1-0/+1
This makes reviewing git log --left-right --merge --no-merges -p a lot more pleasant. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-17rev-list --left-rightLibravatar Junio C Hamano1-0/+1
The output from "symmetric diff", i.e. A...B, does not distinguish between commits that are reachable from A and the ones that are reachable from B. In this picture, such a symmetric diff includes commits marked with a and b. x---b---b branch B / \ / / . / / \ o---x---a---a branch A However, you cannot tell which ones are 'a' and which ones are 'b' from the output. Sometimes this is frustrating. This adds an output option, --left-right, to rev-list. rev-list --left-right A...B would show ones reachable from A prefixed with '<' and the ones reachable from B prefixed with '>'. When combined with --boundary, boundary commits (the ones marked with 'x' in the above picture) are shown with prefix '-', so you would see list that looks like this: git rev-list --left-right --boundary --pretty=oneline A...B >bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 3rd on b >bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2nd on b <aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 3rd on a <aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2nd on a -xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1st on b -xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1st on a Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-20git log: Unify header_filter and message_filter into one.Libravatar Junio C Hamano1-2/+1
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>
2006-09-20revision traversal: prepare for commit log match.Libravatar Junio C Hamano1-0/+4
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>
2006-09-07pack-objects --unpacked=<existing pack> option.Libravatar Junio C Hamano1-1/+5
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>
2006-09-05revision.c: allow injecting revision parameters after setup_revisions().Libravatar Junio C Hamano1-0/+2
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>
2006-08-28Add --relative-date option to the revision interfaceLibravatar Jonas Fonseca1-1/+2
Exposes the infrastructure from 9a8e35e98793af086f05d1ca9643052df9b44a74. Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-28Call setup_git_directory() earlyLibravatar Linus Torvalds1-1/+1
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>
2006-07-14git-format-patch: Make the second and subsequent mails replies to the firstLibravatar Josh Triplett1-0/+2
Add message_id and ref_message_id fields to struct rev_info, used in show_log with CMIT_FMT_EMAIL to set Message-Id and In-Reply-To/References respectively. Use these in git-format-patch to make the second and subsequent patch mails replies to the first patch mail. Signed-off-by: Josh Triplett <josh@freedesktop.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-19Add "named object array" conceptLibravatar Linus Torvalds1-5/+7
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>
2006-06-16gitweb.cgi history not shownLibravatar Linus Torvalds1-0/+1
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>
2006-06-02format-patch: resurrect extra headers from configLibravatar Johannes Schindelin1-0/+1
Once again, if you have [format] headers = "Origamization: EvilEmpire\n" format-patch will add these headers just after the "Subject:" line. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-31format-patch --signoffLibravatar Junio C Hamano1-0/+1
This resurrects --signoff option to format-patch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-21fmt-patch: Support --attachLibravatar Johannes Schindelin1-0/+1
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-05Teach fmt-patch about --numberedLibravatar Johannes Schindelin1-0/+1
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-18Merge branch 'lt/logopt'Libravatar Junio C Hamano1-1/+22
* 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
2006-04-17Log message printout cleanupsLibravatar Linus Torvalds1-4/+4
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>
2006-04-16rev-list --boundary: show boundary commits even when limited otherwise.Libravatar Junio C Hamano1-1/+2
The boundary commits are shown for UI like gitk to draw them as soon as topo-order sorting allows, and should not be omitted by get_revision() filtering logic. As long as their immediate child commits are shown, we should not filter them out. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-16log/whatchanged/show - log formatting cleanup.Libravatar Junio C Hamano1-0/+1
This moves the decision to print the log message, while diff options are in effect, to log-tree. It gives behaviour closer to the traditional one. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-16Tentative built-in "git show"Libravatar Linus Torvalds1-0/+1
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>
2006-04-14Common option parsing for "git log --diff" and friendsLibravatar Linus Torvalds1-1/+20
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>