summaryrefslogtreecommitdiff
path: root/revision.c
Commit message (Collapse)AuthorAgeFilesLines
* Fix "git log --diff-filter" bugArjen Laarhoven2007-12-261-2/+4
| | | | | | | | | | | | In commit b7bb760d5ed4881422673d32f869d140221d3564 (Fix revision log diff setup, avoid unnecessary diff generation) an optimization was made to avoid unnecessary diff generation. This was partly fixed in 99516e35d096f41e7133cacde8fbed8ee9a3ecd0 (Fix embarrassing "git log --follow" bug). The '--diff-filter' option also needs the diff machinery in action. Signed-off-by: Arjen Laarhoven <arjen@yaph.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* shortlog: default to HEAD when the standard input is a ttyJunio C Hamano2007-12-111-0/+12
| | | | | | | | | | | | | | 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>
* Merge branch 'lt/rev-list-gitlink'Junio C Hamano2007-11-181-2/+9
|\ | | | | | | | | * lt/rev-list-gitlink: Fix rev-list when showing objects involving submodules
| * Fix rev-list when showing objects involving submodulesLinus Torvalds2007-11-141-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The function mark_tree_uninteresting() assumed that the tree entries are blob when they are not trees. This is not so. Since we do not traverse into submodules (yet), the gitlinks should be ignored. In general, we should try to start moving away from using the "S_ISLNK()" like things for internal git state. It was a mistake to just assume the numbers all were same across all systems in the first place. This implementation converts to the "object_type", and then uses a case statement. Noticed by Ilari on IRC. Test script taken from an earlier version by Dscho. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'lt/rev-list-interactive'Junio C Hamano2007-11-181-43/+82
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | * lt/rev-list-interactive: Fix parent rewriting in --early-output revision walker: mini clean-up Enhance --early-output format Add "--early-output" log flag for interactive GUI use Simplify topo-sort logic
| * | Fix parent rewriting in --early-outputLinus Torvalds2007-11-141-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-051-7/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-051-27/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-041-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-041-6/+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>
* | Make the diff_options bitfields be an unsigned with explicit masks.Pierre Habouzit2007-11-111-11/+11
|/ | | | | | | reverse_diff was a bit-value in disguise, it's merged in the flags now. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'maint'Shawn O. Pearce2007-10-151-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * maint: Whip post 1.5.3.4 maintenance series into shape. rebase -i: use diff plumbing instead of porcelain Do not remove distributed configure script git-archive: document --exec git-reflog: document --verbose git-config: handle --file option with relative pathname properly clear_commit_marks(): avoid deep recursion git add -i: Remove unused variables git add -i: Fix parsing of abbreviated hunk headers git-config: don't silently ignore options after --list Clean up "git log" format with DIFF_FORMAT_NO_OUTPUT Fix embarrassing "git log --follow" bug Conflicts: RelNotes git-rebase--interactive.sh
| * Fix embarrassing "git log --follow" bugLinus Torvalds2007-10-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that I completely broke "git log --follow" with my recent patch to revision.c ("Fix revision log diff setup, avoid unnecessary diff generation", commit b7bb760d5ed4881422673d32f869d140221d3564). Why? Because --follow obviously requires the diff machinery to function, exactly the same way pickaxe does. So everybody is away right now, but considering that nobody even noticed this bug, I don't think it matters. But for the record, here's the trivial one-liner fix (well, two, since I also fixed the comment). Because of the nature of the bug, if you ask for patches when following (which is one of the things I normally do), the bug is hidden, because then the request for diff output will automatically also enable the diffs themselves. So while "git log --follow <filename>" didn't work, adding a "-p" magically made it work again even without this fix. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | parse_date_format(): convert a format name to an enum date_modeAndy Parkins2007-09-291-16/+1
|/ | | | | | | | | | | | | | | | | | Factor out the code to parse --date=<format> parameter to revision walkers into a separate function, parse_date_format(). This function is passed a string and converts it to an enum date_format: - "relative" => DATE_RELATIVE - "iso8601" or "iso" => DATE_ISO8601 - "rfc2822" => DATE_RFC2822 - "short" => DATE_SHORT - "local" => DATE_LOCAL - "default" => DATE_NORMAL In the event that none of these strings is found, the function die()s. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Fix revision log diff setup, avoid unnecessary diff generationLinus Torvalds2007-09-291-2/+8
| | | | | | | | | | | | | | | | | | | | | | We used to incorrectly start calculating diffs whenever any argument but '-z' was recognized by the diff options parsing. That was bogus, since not all arguments result in diffs being needed, so we just waste a lot of time and effort on calculating diffs that don't matter. This actually also fixes another bug in "git log". Try this: git log -C and notice how it prints an extra empty line in between log entries, even though it never prints the actual diff (because we didn't ask for any diff format, so the diff machinery never prints anything). With this patch, that bogus empty line is gone, because "revs->diff" is never set. So this isn't just a "wasted time and effort" issue, it's also a slight semantic fix. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* revision walker: --cherry-pick is a limited operationJohannes Schindelin2007-09-151-0/+1
| | | | | | | | | | | | | | | | | | We used to rely on the fact that cherry-pick would trigger the code path to set limited = 1 in handle_commit(), when an uninteresting commit was encountered. However, when cherry picking between two independent branches, i.e. when there are no merge bases, and there is only linear development (which can happen when you cvsimport a fork of a project), no uninteresting commit will be encountered. So set limited = 1 when --cherry-pick was asked for. Noticed by Martin Bähr. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Make "git-log --" without paths behave the same as "git-log" without --Junio C Hamano2007-08-311-1/+2
| | | | | | | | | | | | "git log" family of commands, even when run from a subdirectory, do not limit the revision range with the current directory as the path limiter, but with double-dash without any paths after it, i.e. "git log --" do so. It was a mistake to have a difference between "git log --" and "git log" introduced in commit ae563542bf10fa8c33abd2a354e4b28aca4264d7 (First cut at libifying revlist generation). Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Don't allow combination of -g and --reverse as it doesn't workShawn O. Pearce2007-08-191-0/+3
| | | | | | | | | | | | | | | | | | The --walk-reflogs logic and the --reverse logic are completely incompatible with one another. Attempting to use both at the same time leads to confusing results that sometimes violates the user's formatting options or ignores the user's request to see the reflog message and timestamp. Unfortunately the implementation of both of these features is glued onto the side of the revision walking machinary in such a way that they are probably not going to be easy to make them compatible with each other. Rather than offering the user confusing results we are better off bailing out with an error message until such a time as the implementations can be refactored to be compatible. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Add --log-size to git log to print message sizeMarco Costalba2007-08-141-0/+4
| | | | | | | | | | | | | | | | | 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>
* git log -g: Complain, but do not fail, when no reflogs are thereJohannes Schindelin2007-07-241-3/+4
| | | | | | | | | | When asking "git log -g --all", clearly you want to see only those refs that do have reflogs, but you do not want it to fail, either. So instead of die()ing, complain about it, but move on to the other refs. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Teach revision machinery about --no-walkJohannes Schindelin2007-07-231-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | The flag "no_walk" is present in struct rev_info since a long time, but so far has been in use exclusively by "git show". With this flag, you can see all your refs, ordered by date of the last commit: $ git log --abbrev-commit --pretty=oneline --decorate --all --no-walk which is extremely helpful if you have to juggle with a lot topic branches, and do not remember in which one you introduced that uber debug option, or simply want to get an overview what is cooking. (Note that the "git log" invocation above does not output the same as $ git show --abbrev-commit --pretty=oneline --decorate --all --quiet since "git show" keeps the alphabetic order that "--all" returns the refs in, even if the option "--date-order" was passed.) For good measure, this also adds the "--do-walk" option which overrides "--no-walk". Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Synonyms: -i == --regexp-ignore-case, -E == --extended-regexpJunio C Hamano2007-07-221-2/+4
| | | | | | | | | These options to log family were too long to type. Give them shorter synonyms. Fix the parsing of the long options while at it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Fix up duplicate parents removalLinus Torvalds2007-07-201-5/+6
| | | | | | | This removes duplicate parents properly, making gitk happy again. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Wire new date formats to --date=<format> parser.Junio C Hamano2007-07-131-0/+8
| | | | | | | | | | Now we can use all internally supported date formats with git log --date=<format> syntax. Earlier, we only allowed relative/local/default. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Fix --cherry-pick with given pathsJohannes Schindelin2007-07-111-2/+7
| | | | | | | | | | | | | | If you say --cherry-pick, you do not want to see patches which are in the upstream. If you specify paths with that, what you usually expect is that only those parts of the patches are looked at which actually touch the given paths. With this patch, that expectation is met. Noticed by Sam Vilain. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* revision.c: remove duplicated parents after history simplificationJunio C Hamano2007-07-081-0/+20
| | | | | | | | | | When we simplify history due to path limits, the parents list for a rewritten commit can end up having duplicates. Instead of filtering them out in the output codepath like earlier commit 88494423 did, remove them much earlier, when the parent information actually gets rewritten. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* format-patch: Add format.subjectprefix config optionAdam Roben2007-07-021-1/+0
| | | | | | | | This change lets you use the format.subjectprefix config option to override the default subject prefix. Signed-off-by: Adam Roben <aroben@apple.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Finally implement "git log --follow"Linus Torvalds2007-06-221-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ok, I've really held off doing this too damn long, because I'm lazy, and I was always hoping that somebody else would do it. But no, people keep asking for it, but nobody actually did anything, so I decided I might as well bite the bullet, and instead of telling people they could add a "--follow" flag to "git log" to do what they want to do, I decided that it looks like I just have to do it for them.. The code wasn't actually that complicated, in that the diffstat for this patch literally says "70 insertions(+), 1 deletions(-)", but I will have to admit that in order to get to this fairly simple patch, you did have to know and understand the internal git diff generation machinery pretty well, and had to really be able to follow how commit generation interacts with generating patches and generating the log. So I suspect that while I was right that it wasn't that hard, I might have been expecting too much of random people - this patch does seem to be firmly in the core "Linus or Junio" territory. To make a long story short: I'm sorry for it taking so long until I just did it. I'm not going to guarantee that this works for everybody, but you really can just look at the patch, and after the appropriate appreciative noises ("Ooh, aah") over how clever I am, you can then just notice that the code itself isn't really that complicated. All the real new code is in the new "try_to_follow_renames()" function. It really isn't rocket science: we notice that the pathname we were looking at went away, so we start a full tree diff and try to see if we can instead make that pathname be a rename or a copy from some other previous pathname. And if we can, we just continue, except we show *that* particular diff, and ever after we use the _previous_ pathname. One thing to look out for: the "rename detection" is considered to be a singular event in the _linear_ "git log" output! That's what people want to do, but I just wanted to point out that this patch is *not* carrying around a "commit,pathname" kind of pair and it's *not* going to be able to notice the file coming from multiple *different* files in earlier history. IOW, if you use "git log --follow", then you get the stupid CVS/SVN kind of "files have single identities" kind of semantics, and git log will just pick the identity based on the normal move/copy heuristics _as_if_ the history could be linearized. Put another way: I think the model is broken, but given the broken model, I think this patch does just about as well as you can do. If you have merges with the same "file" having different filenames over the two branches, git will just end up picking _one_ of the pathnames at the point where the newer one goes away. It never looks at multiple pathnames in parallel. And if you understood all that, you probably didn't need it explained, and if you didn't understand the above blathering, it doesn't really mtter to you. What matters to you is that you can now do git log -p --follow builtin-rev-list.c and it will find the point where the old "rev-list.c" got renamed to "builtin-rev-list.c" and show it as such. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'maint' to sync with GIT 1.5.2.2Junio C Hamano2007-06-161-1/+2
|\
| * Avoid diff cost on "git log -z"Junio C Hamano2007-06-151-1/+2
| | | | | | | | | | | | | | Johannes and Marco discovered that "git log -z" spent cycles in diff even though there is no need to actually compute diffs. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | More missing staticJunio C Hamano2007-06-081-8/+8
| | | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-rev-list: Add regexp tuning optionsPetr Baudis2007-05-201-0/+12
|/ | | | | | | | | This patch introduces --extended-regexp and --regexp-ignore-case options to tune what kind of patterns the pattern-limiting options (--grep, --author, ...) accept. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Handle return code of parse_commit in revision machineryAlex Riesen2007-05-061-23/+50
| | | | | | | | 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-251-1/+12
| | | | | | | | | | | 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-241-5/+12
| | | | | Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge branch 'jc/cherry'Junio C Hamano2007-04-121-0/+88
|\ | | | | | | | | | | | | | | * jc/cherry: Documentation: --cherry-pick git-log --cherry-pick A...B Refactor patch-id filtering out of git-cherry and git-format-patch. Add %m to '--pretty=format:'
| * git-log --cherry-pick A...BJunio C Hamano2007-04-111-0/+88
| | | | | | | | | | | | | | | | | | | | 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>
* | Fix git {log,show,...} --pretty=emailJunio C Hamano2007-04-121-0/+1
|/ | | | | | | | An earlier --subject-prefix patch forgot that format-patch is not the only codepath that adds the "[PATCH]" prefix, and broke everybody else in the log family. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Rename warn() to warning() to fix symbol conflicts on BSD and Mac OSTheodore Ts'o2007-03-311-1/+1
| | | | | | | | | | | | | | | | | This fixes a problem reported by Randal Schwartz: >I finally tracked down all the (albeit inconsequential) errors I was getting >on both OpenBSD and OSX. It's the warn() function in usage.c. There's >warn(3) in BSD-style distros. It'd take a "great rename" to change it, but if >someone with better C skills than I have could do that, my linker and I would >appreciate it. It was annoying to me, too, when I was doing some mergetool testing on Mac OS X, so here's a fix. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Cc: "Randal L. Schwartz" <merlyn@stonehenge.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge branch 'jc/fpl'Junio C Hamano2007-03-251-4/+10
|\ | | | | | | | | * jc/fpl: git-log --first-parent: show only the first parent log
| * git-log --first-parent: show only the first parent logJunio C Hamano2007-03-141-4/+10
| | | | | | | | | | | | | | | | | | 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>
* | Initialize tree descriptors with a helper function rather than by hand.Linus Torvalds2007-03-211-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | This removes slightly more lines than it adds, but the real reason for doing this is that future optimizations will require more setup of the tree descriptor, and so we want to do it in one place. Also renamed the "desc.buf" field to "desc.buffer" just to trigger compiler errors for old-style manual initializations, making sure I didn't miss anything. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Replace remaining instances of strdup with xstrdup.James Bowes2007-03-191-1/+1
| | | | | | | | | | Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | try-to-simplify-commit: use diff-tree --quiet machinery.Junio C Hamano2007-03-141-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This uses diff-tree --quiet machinery to terminate the internal diff-tree between a commit and its parents via revs.pruning (not revs.diffopt) as soon as we find enough about the tree change. With respect to the optionally given pathspec, we are interested if the tree of commit is identical to the parent's, only adds new paths to the parent's, or there are other differences. As soon as we find out that there is one such other kind of difference, we do not have to compare the rest of the tree. Because we do not call standard diff_addremove/diff_change, we instruct the diff-tree machinery to stop early by setting has_changes when we say we found the trees to be different. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | revision.c: explain what tree_difference doesJunio C Hamano2007-03-141-2/+9
|/ | | | | | | This explains how tree_difference variable is used, and updates two places where the code knows symbolic constant REV_TREE_SAME is 0. Signed-off-by: Junio C Hamano <junkio@cox.net>
* revision --boundary: fix uncounted case.Junio C Hamano2007-03-061-8/+8
| | | | | | | | When the list is truly limited and get_revision_1() returned NULL, the code incorrectly returned it without switching to boundary emiting mode. Silly. Signed-off-by: Junio C Hamano <junkio@cox.net>
* revision --boundary: fix stupid typoJunio C Hamano2007-03-061-1/+1
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* revision traversal: SHOWN means shownJunio C Hamano2007-03-061-8/+18
| | | | | | | | | | This moves the code to set SHOWN on the commit from get_revision_1() back to get_revision(), so that the bit means what it originally meant: this commit has been given back to the caller. Also it fixes the --reverse breakage Dscho pointed out. Signed-off-by: Junio C Hamano <junkio@cox.net>
* revision traversal: retire BOUNDARY_SHOWJunio C Hamano2007-03-061-1/+8
| | | | | | | | | | | 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-061-114/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
View Lorry Controller Status