aboutsummaryrefslogtreecommitdiff
path: root/revision.h
Commit message (Collapse)AuthorAge
* revision traversal: '--simplify-by-decoration'Linus Torvalds2008-11-04
| | | | | | | | | | | | | | | | With this, you can simplify history not by the contents of the tree, but whether a commit has been named (ie it's referred to by some branch or tag) or not. This makes it possible to see the relationship between different named commits, without actually seeing any of the details. When used with pathspec, you would get the usual view that is limited to the commits that change the contents of the tree plus commits that are named. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Make '--decorate' set an explicit 'show_decorations' flagLinus Torvalds2008-11-04
| | | | | | | | | We will want to add decorations without necessarily showing them, so add an explicit revisions info flag as to whether we're showing decorations or not. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Add a 'source' decorator for commitsLinus Torvalds2008-11-04
| | | | | | | | | | | | | | | | | We already support decorating commits by tags or branches that point to them, but especially when we are looking at multiple branches together, we sometimes want to see _how_ we reached a particular commit. We can abuse the '->util' field in the commit to keep track of that as we walk the commit lists, and get a reasonably useful view into which branch or tag first reaches that commit. Of course, if the commit is reachable through multiple sources (which is common), our particular choice of "first" reachable is entirely random and depends on the particular path we happened to follow. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'tr/rev-list-reverse'Junio C Hamano2008-09-18
|\ | | | | | | | | | | * tr/rev-list-reverse: t6013: replace use of 'tac' with equivalent Perl rev-list: fix --reverse interaction with --parents
| * rev-list: fix --reverse interaction with --parentsThomas Rast2008-08-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --reverse did not interact well with --parents, as the included test case shows: in a history like A--B. \ \ `C--M--D the command git rev-list --reverse --parents --full-history HEAD erroneously lists D as having no parents at all. (Without --reverse, it correctly lists M.) This is caused by the machinery driving --reverse: it first grabs all commits through the normal routines, then runs them through the same routines again, effectively simplifying them twice. Fix this by moving the --reverse one level up, into get_revision(). This way we can cleanly grab all commits via the normal calls, then just pop them off the list one by one without interfering with get_revision_internal(). Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'tr/filter-branch'Junio C Hamano2008-09-02
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * tr/filter-branch: revision --simplify-merges: make it a no-op without pathspec revision --simplify-merges: do not leave commits unprocessed revision --simplify-merges: use decoration instead of commit->util field Documentation: rev-list-options: move --simplify-merges documentation filter-branch: use --simplify-merges filter-branch: fix ref rewriting with --subdirectory-filter filter-branch: Extend test to show rewriting bug Topo-sort before --simplify-merges revision traversal: show full history with merge simplification revision.c: whitespace fix
| * | revision --simplify-merges: use decoration instead of commit->util fieldJunio C Hamano2008-08-14
| |/ | | | | | | | | | | | | | | The users of revision walking machinery may want to use the util pointer for their own use. Use decoration to hold the data needed during merge simplification instead. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * revision traversal: show full history with merge simplificationJunio C Hamano2008-08-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The --full-history traversal keeps all merges in addition to non-merge commits that touch paths in the given pathspec. This is useful to view both sides of a merge in a topology like this: A---M---o / / ---O---B even when A and B makes identical change to the given paths. The revision traversal without --full-history aims to come up with the simplest history to explain the final state of the tree, and one of the side branches can be pruned away. The behaviour to keep all merges however is inconvenient if neither A nor B touches the paths we are interested in. --full-history reduces the topology to: ---O---M---o in such a case, without removing M. This adds a post processing phase on top of --full-history traversal to remove needless merges from the resulting history. The idea is to compute, for each commit in the "full history" result set, the commit that should replace it in the simplified history. The commit to replace it in the final history is determined as follows: * In any case, we first figure out the replacement commits of parents of the commit we are looking at. The commit we are looking at is rewritten as if the replacement commits of its original parents are its parents. While doing so, we reduce the redundant parents from the rewritten parent list by not just removing the identical ones, but also removing a parent that is an ancestor of another parent. * After the above parent simplification, if the commit is a root commit, an UNINTERESTING commit, a merge commit, or modifies the paths we are interested in, then the replacement commit of the commit is itself. In other words, such a commit is not dropped from the final result. The first point above essentially means that the history is rewritten in the bottom up direction. We can rewrite the parent list of a commit only after we know how all of its parents are rewritten. This means that the processing needs to happen on the full history (i.e. after limit_list()). Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Fix "git log -i --grep"Jeff King2008-08-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This has been broken in v1.6.0 due to the reorganization of the revision option parsing code. The "-i" is completely ignored, but works fine in "git log --grep -i". What happens is that the code for "-i" looks for revs->grep_filter; if it is NULL, we do nothing, since there are no grep filters. But that is obviously not correct, since we want it to influence the later --grep option. Doing it the other way around works, since "-i" just impacts the existing grep_filter option. Instead, we now always initialize the grep_filter member and just fill in options and patterns as we get them. This means that we can no longer check grep_filter for NULL, but instead must check the pattern list to see if we have any actual patterns. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | revision.h: make show_early_output an extern which is defined in revision.cBrandon Casey2008-08-20
|/ | | | | | | | | The variable show_early_output is defined in revision.c and should be declared extern in revision.h so that the linker does not complain about multiply defined variables. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sort_in_topological_order(): avoid setting a commit flagJohannes Schindelin2008-07-23
| | | | | | | | | | | | | | | | | | | | | | We used to set the TOPOSORT flag of commits during the topological sorting, but we can just as well use the member "indegree" for it: indegree is now incremented by 1 in the cases where the commit used to have the TOPOSORT flag. This is the same behavior as before, since indegree could not be non-zero when TOPOSORT was unset. Incidentally, this fixes the bug in show-branch where the 8th column was not shown: show-branch sorts the commits in topological order, assuming that all the commit flags are available for show-branch's private matters. But this was not true: TOPOSORT was identical to the flag corresponding to the 8th ref. So the flags for the 8th column were unset by the topological sorting. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'ph/parseopt-step-blame'Junio C Hamano2008-07-13
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * ph/parseopt-step-blame: revisions: refactor handle_revision_opt into parse_revision_opt. git-shortlog: migrate to parse-options partially. git-blame: fix lapsus git-blame: migrate to incremental parse-option [2/2] git-blame: migrate to incremental parse-option [1/2] revisions: split handle_revision_opt() from setup_revisions() parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option. parse-opt: fake short strings for callers to believe in. parse-opt: do not print errors on unknown options, return -2 intead. parse-opt: create parse_options_step. parse-opt: Export a non NORETURN usage dumper. parse-opt: have parse_options_{start,end}. git-blame --reverse builtin-blame.c: allow more than 16 parents builtin-blame.c: move prepare_final() into a separate function. rev-list --children revision traversal: --children option
| * revisions: refactor handle_revision_opt into parse_revision_opt.Pierre Habouzit2008-07-09
| | | | | | | | | | | | | | | | | | | | | | It seems we're using handle_revision_opt the same way each time, have a wrapper around it that does the 9-liner we copy each time instead. handle_revision_opt can be static in the module for now, it's always possible to make it public again if needed. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * revisions: split handle_revision_opt() from setup_revisions()Pierre Habouzit2008-07-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add two fields to struct rev_info: - .def to store --default argument; and - .show_merge 1-bit field. handle_revision_opt() is able to deal with any revision option, and consumes them, and leaves revision arguments or pseudo arguments (like --all, --not, ...) in place. For now setup_revisions() does a pass of handle_revision_opt() again so that code not using it in a parse-opt parser still work the same. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * Merge branch 'jc/blame' (early part) into HEADJunio C Hamano2008-07-08
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 'jc/blame' (early part): git-blame --reverse builtin-blame.c: allow more than 16 parents builtin-blame.c: move prepare_final() into a separate function. rev-list --children revision traversal: --children option Conflicts: Documentation/rev-list-options.txt revision.c
| | * revision traversal: --children optionJunio C Hamano2008-04-12
| | | | | | | | | | | | | | | | | | | | | | | | This adds a new --children option to the revision machinery. In addition to the list of parents, child commits of each commit are computed and stored as a decoration to each commit. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jc/report-tracking'Junio C Hamano2008-07-13
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * jc/report-tracking: branch -r -v: do not spit out garbage stat_tracking_info(): clear object flags used during counting git-branch -v: show the remote tracking statistics git-status: show the remote tracking statistics Refactor "tracking statistics" code used by "git checkout"
| * | | stat_tracking_info(): clear object flags used during countingJunio C Hamano2008-07-03
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | When left-right traversal counts the commits in a diverged history, it leaves the flags in the commits smudged, and we need to clear them before we return. Otherwise the caller cannot inspect other branches with this function again. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Move read_revisions_from_stdin from builtin-rev-list.c to revision.cAdam Brewster2008-07-05
|/ / | | | | | | | | | | | | | | | | Reading rev-list parameters from the command line can be reused by commands other than rev-list. Move this function to more "library-ish" place to promote code reuse. Signed-off-by: Adam Brewster <asb@bu.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | log and rev-list: add --graph optionAdam Simpkins2008-05-05
| | | | | | | | | | | | | | | | This new option causes a text-based representation of the history to be printed to the left of the normal output. Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | revision API: split parent rewriting and parent printing optionsAdam Simpkins2008-05-05
| | | | | | | | | | | | | | | | This change allows parent rewriting to be performed without causing the log and rev-list commands to print the parents. Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | log: teach "terminator" vs "separator" mode to "--pretty=format"Junio C Hamano2008-04-10
|/ | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'db/cover-letter'Junio C Hamano2008-02-27
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * Improve message-id generation flow control for format-patchDaniel Barkalow2008-02-19
| | | | | | | | | | Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Add "--show-all" revision walker flag for debuggingLinus Torvalds2008-02-13
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* shortlog: default to HEAD when the standard input is a ttyJunio C Hamano2007-12-11
| | | | | | | | | | | | | | 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>
* Fix parent rewriting in --early-outputLinus Torvalds2007-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* revision walker: mini clean-upLinus Torvalds2007-11-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Enhance --early-output formatLinus Torvalds2007-11-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Add "--early-output" log flag for interactive GUI useLinus Torvalds2007-11-04
| | | | | | | | | | | | | | | | | | | | | | 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>
* Simplify topo-sort logicLinus Torvalds2007-11-04
| | | | | | | | | | | .. 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>
* Add --log-size to git log to print message sizeMarco Costalba2007-08-14
| | | | | | | | | | | | | | | | | 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>
* More missing staticJunio C Hamano2007-06-08
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Handle return code of parse_commit in revision machineryAlex Riesen2007-05-06
| | | | | | | | 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>
* Add --date={local,relative,default}Junio C Hamano2007-04-25
| | | | | | | | | | | 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>
* store mode in rev_list, if <tree>:<filename> syntax is usedMartin Koegler2007-04-24
| | | | | Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-log --cherry-pick A...BJunio C Hamano2007-04-11
| | | | | | | | | | 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>
* Add custom subject prefix support to format-patch (take 3)Robin H. Johnson2007-04-11
| | | | | | | | | | | 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>
* git-log --first-parent: show only the first parent logJunio C Hamano2007-03-14
| | | | | | | | | 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>
* Merge branch 'jc/boundary'Junio C Hamano2007-03-11
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * revision traversal: retire BOUNDARY_SHOWJunio C Hamano2007-03-06
| | | | | | | | | | | | | | | | | | | | | | 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>
| * revision walker: Fix --boundary when limitedJunio C Hamano2007-03-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | format-patch: add --inline option and make --attach a true attachmentJohannes Schindelin2007-03-04
|/ | | | | | | | | | | | 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>
* Teach revision machinery about --reverseJohannes Schindelin2007-01-20
| | | | | | | | | 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>
* Teach the revision walker to walk by reflogs with --walk-reflogsJohannes Schindelin2007-01-20
| | | | | | | | | 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>
* Teach log family --encodingJunio C Hamano2006-12-26
| | | | | | | | | | | | | | 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>
* Merge branch 'jc/skip-count'Junio C Hamano2006-12-25
|\ | | | | | | | | * jc/skip-count: revision: --skip=<n>
| * revision: --skip=<n>Junio C Hamano2006-12-20
| | | | | | | | | | | | | | | | 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>
* | Revert "Make left-right automatic."Junio C Hamano2006-12-19
| | | | | | | | | | | | | | | | | | | | 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.
* | Make left-right automatic.Junio C Hamano2006-12-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.1 (git 2.18.0) at 2024-12-27 07:25:25 +0000