- 14 6月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
The simplify_merges() function needs to look at all history chain to find the closest ancestor that is relevant after the simplification, but after --first-parent traversal, side parents haven't been marked for relevance (they are irrelevant by definition due to the nature of first-parent-only traversal) nor culled from the parents list of resulting commits. We cannot simply remove these side parents from the parents list, as the output phase still wants to see the parents. Instead, teach simplify_one() and its callees to ignore the later parents. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 6月, 2012 2 次提交
-
-
由 Junio C Hamano 提交于
Among the three similar-looking loops that walk singly linked commit_list, the first one is only peeking and the same list is later used for real work. Leave a comment not to mistakenly free its elements there. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
The code internally runs sort_in_topo_order() already; it is more clear to spell it out in the option parsing phase, instead of adding a special case in simplify_merges() function.
-
- 26 4月, 2012 1 次提交
-
-
由 René Scharfe 提交于
By using commit_list_insert(), we added new items to the top of the list and, since this is not the order we want, reversed it afterwards. Simplify this process by adding new items at the bottom instead, getting rid of the reversal step. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 4月, 2012 1 次提交
-
-
由 Clemens Buchacher 提交于
If a commit-ish passed to cherry-pick or revert happens to have a file of the same name, git complains that the argument is ambiguous and advises to use '--'. To make things worse, the '--' argument is removed by parse_options, und so passing '--' has no effect. Instead, always interpret cherry-pick/revert arguments as revisions. Signed-off-by: NClemens Buchacher <drizzd@aon.at> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 4月, 2012 1 次提交
-
-
由 René Scharfe 提交于
Speed up prepare_revision_walk() by adding commits without sorting to the commit_list and at the end sort the list in one go. Thanks to mergesort() working behind the scenes, this is a lot faster for large numbers of commits than the current insert sort. Also introduce and use commit_list_reverse(), to keep the ordering of commits sharing the same commit date unchanged. That's because commit_list_insert_by_date() sorts commits with descending date, but adds later entries with the same date entries last, while commit_list_insert() always inserts entries at the top. The following commit_list_sort_by_date() keeps the order of entries sharing the same date. Jeff's test case, in a repo with lots of refs, was to run: # make a new commit on top of HEAD, but not yet referenced sha1=`git commit-tree HEAD^{tree} -p HEAD </dev/null` # now do the same "connected" test that receive-pack would do git rev-list --objects $sha1 --not --all With a git.git with a ref for each revision, master needs (best of five): real 0m2.210s user 0m2.188s sys 0m0.016s And with this patch: real 0m0.480s user 0m0.456s sys 0m0.020s Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 30 3月, 2012 1 次提交
-
-
由 Heiko Voigt 提交于
Previously it was not possible to iterate revisions twice using the revision walking api. We add a reset_revision_walk() which clears the used flags. This allows us to do multiple sequencial revision walks. We add the appropriate calls to the existing submodule machinery doing revision walks. This is done to avoid surprises if future code wants to call these functions more than once during the processes lifetime. Signed-off-by: NHeiko Voigt <hvoigt@hvoigt.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 2月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
"git log -S<string>" is a useful way to find the last commit in the codebase that touched the <string>. As it was designed to be used by a porcelain script to dig the history starting from a block of text that appear in the starting commit, it never had to look for anything but an exact match. When used by an end user who wants to look for the last commit that removed a string (e.g. name of a variable) that he vaguely remembers, however, it is useful to support case insensitive match. When given the "--regexp-ignore-case" (or "-i") option, which originally was designed to affect case sensitivity of the search done in the commit log part, e.g. "log --grep", the matches made with -S/-G pickaxe search is done case insensitively now. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 03 2月, 2012 1 次提交
-
-
由 Jeff King 提交于
Before the grep_source interface existed, grep_buffer was used by two types of callers: 1. Ones which pulled a file into a buffer, and then wanted to supply the file's name for the output (i.e., git grep). 2. Ones which really just wanted to grep a buffer (i.e., git log --grep). Callers in set (1) should now be using grep_source. Callers in set (2) always pass NULL for the "name" parameter of grep_buffer. We can therefore get rid of this now-useless parameter. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 1月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
In a topic branch workflow, you often want to find the latest commit that merged a side branch that touched a particular area of the system, so that a new topic branch to work on that area can be forked from that commit. For example, I wanted to find an appropriate fork-point to queue Luke's changes related to git-p4 in contrib/fast-import/. "git log --first-parent" traverses the first-parent chain, and "-m --stat" shows the list of paths touched by commits including merge commits. We could ask the question this way: # What is the latest commit that touched that path? $ git log --first-parent --oneline -m --stat master | sed -e '/^ contrib\/fast-import\/git-p4 /q' | tail The above finds that 8cbfc118 (Merge branch 'pw/p4-view-updates', 2012-01-06) was such a commit. But a more natural way to spell this question is this: $ git log --first-parent --oneline -m --stat -1 master -- \ contrib/fast-import/git-p4 Unfortunately, this does not work. It finds ecb7cf98 (git-p4: rewrite view handling, 2012-01-02). This commit is a part of the merged topic branch and is _not_ on the first-parent path from the 'master': $ git show-branch 8cbfc118 ecb7cf98 ! [8cbfc118] Merge branch 'pw/p4-view-updates' ! [ecb7cf98] git-p4: rewrite view handling -- - [8cbfc118] Merge branch 'pw/p4-view-updates' + [8cbfc118^2] git-p4: view spec documentation ++ [ecb7cf98] git-p4: rewrite view handling The problem is caused by the merge simplification logic when it inspects the merge commit 8cbfc118. In this case, the history leading to the tip of 'master' did not touch git-p4 since 'pw/p4-view-updates' topic forked, and the result of the merge is simply a copy from the tip of the topic branch in the view limited by the given pathspec. The merge simplification logic discards the history on the mainline side of the merge, and pretends as if the sole parent of the merge is its second parent, i.e. the tip of the topic. While this simplification is correct in the general case, it is at least surprising if not outright wrong when the user explicitly asked to show the first-parent history. Here is an attempt to fix this issue, by not allowing us to compare the merge result with anything but the first parent when --first-parent is in effect, to avoid the history traversal veering off to the side branch. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 1月, 2012 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Recursion in a DAG is generally a bad idea because it could be very deep. Be defensive and avoid recursion in mark_parents_uninteresting() and clear_commit_marks(). mark_parents_uninteresting() learns a trick from clear_commit_marks() to avoid malloc() in (dominant) single-parent case. Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 11月, 2011 1 次提交
-
-
由 Junio C Hamano 提交于
This teaches the "log" family of commands to pass the GPG signature in the commit objects to "gpg --verify" via the verify_signed_buffer() interface used to verify signed tag objects. E.g. $ git show --show-signature -s HEAD shows GPG output in the header part of the output. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 10月, 2011 2 次提交
-
-
由 René Scharfe 提交于
The new flag leak_pending in struct rev_info can be used to prevent prepare_revision_walk from freeing the list of pending objects. It will still forget about them, so it really is leaked. This behaviour may look weird at first, but it can be useful if the pointer to the list is saved before calling prepare_revision_walk. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 René Scharfe 提交于
This function is a combination of the static get_reference and add_pending_object. It can be used to easily queue objects by hash. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 9月, 2011 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
HEAD and MERGE_HEAD (among other branch tips) should never hold a tag. That can only be caused by broken tools and is cumbersome to fix by an end user with: $ git update-ref HEAD $(git rev-parse HEAD^{commit}) which may look like a magic to a new person. Be easy, warn users (so broken tools can be fixed if they bother to report) and move on. Be robust, if the given SHA-1 cannot be resolved to a commit object, die (therefore return value is always valid). Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 9月, 2011 1 次提交
-
-
由 Junio C Hamano 提交于
Often we want to verify everything reachable from a given set of commits are present in our repository and connected without a gap to the tips of our refs. We used to do this for this purpose: $ rev-list --objects $commits_to_be_tested --not --all Even though this is good enough for catching missing commits and trees, we show the object name but do not verify their existence, let alone their well-formedness, for the blob objects at the leaf level. Add a new "--verify-object" option so that we can catch missing and broken blobs as well. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 8月, 2011 2 次提交
-
-
由 Junio C Hamano 提交于
If the commit specified as the bottom of the commit range has a direct parent that has another child commit that contributed to the resulting history, "rev-list --ancestry-path" was confused and listed that side history as well, due to the command line parser subtlety corrected by the previous commit. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Given a complex set of revision specifiers on the command line, it is too late to look at the flags of the objects in the initial traversal list at the beginning of limit_list() in order to determine what the objects the end-user explicitly listed on the command line were. The process to move objects from the pending array to the traversal list may have marked objects that are not mentioned as UNINTERESTING, when handle_commit() marked the parents of UNINTERESTING commits mentioned on the command line by calling mark_parents_uninteresting(). This made "rev-list --ancestry-path ^A ..." to mistakenly list commits that are descendants of A's parents but that are not descendants of A itself, as ^A from the command line causes A and its parents marked as UNINTERESTING before coming to limit_list(), and we try to enumerate the commits that are descendants of these commits that are UNINTERESTING before we start walking the history. It actually is too late even if we inspected the pending object array before calling prepare_revision_walk(), as some of the same objects might have been mentioned twice, once as positive and another time as negative. The "rev-list --some-option A --not --all" command may want to notice, even if the resulting set is empty, that the user showed some interest in "A" and do something special about it. Prepare a separate array to keep track of what syntactic element was used to cause each object to appear in the pending array from the command line, and populate it as setup_revisions() parses the command line. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 8月, 2011 2 次提交
-
-
由 Junio C Hamano 提交于
Allocating and then immediately freeing temporary memory a million times when listing a million objects is distasteful. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
There are two copies of traverse_commit_list callback that show the object name followed by pathname the object was found, to produce output similar to "rev-list --objects". Unify them. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 5月, 2011 1 次提交
-
-
由 Junio C Hamano 提交于
Instead of barfing, simply ignore bad object names seen in the input. This is useful when reading from "git notes list" output that may refer to objects that have already been garbage collected. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 5月, 2011 1 次提交
-
-
由 Jay Soffian 提交于
Add log.abbrevCommit config variable as a convenience for users who often use --abbrev-commit with git log and friends. Allow the option to be overridden with --no-abbrev-commit. Per 635530a2 and 4f62c2bc, the config variable is ignored when log is given "--pretty=raw". (Also, a drive-by spelling correction in git log's short help.) Signed-off-by: NJay Soffian <jaysoffian@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 5月, 2011 2 次提交
-
-
由 Junio C Hamano 提交于
If we later add a command in the log family that by default limit its operation to the current subdirectory, we would need to resurrect the "a lone ':' on the command line means no pathspec whatsoever". Now the codepath was cleaned up, we can do so in one place. Leave a note to mark where it is for later generations. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
When the command line has "--" disambiguator, we take the remainder of argv[] as "prune_data", but when --stdin is given at the same time, we need to append to the existing prune_data and end up attempting to realloc(3) it. That would not work. Fix it by consistently using append_prune_data() throughout the input processing. Also avoid counting the number of existing paths in the function over and over again. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 4月, 2011 2 次提交
-
-
由 Jonathan Nieder 提交于
As v1.6.0-rc2~42 (2008-07-31) explains, even pseudo-options like --not and --glob that need to be parsed in order with revisions should be marked handled by handle_revision_opt to avoid an error when parse_revision_opt callers like "git shortlog" encounter them. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
As v1.6.0-rc2~42 (Allow "non-option" revision options in parse_option-enabled commands, 2008-07-31) explains, options handled by setup_revisions fall into two categories: 1. global options like --topo-order handled by parse_revision_opt, which can take detached arguments and can be parsed in advance; 2. pseudo-options that must be parsed in order with their revision counterparts, like --not and --all. The global options are taken care of by handle_revision_opt; the pseudo-options are currently in a deeply indented portion of setup_revisions. Give them their own function for easier reading. The only goal is to make setup_revisions easier to read straight through. No functional change intended. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 30 3月, 2011 5 次提交
-
-
由 Jeff King 提交于
With most command line options, later instances of an option override earlier ones. With cumulative options like "--notes", however, there is no way to say "forget the --notes I gave you before". Let's have --no-notes trigger this forgetting, so that: git log --notes=foo --no-notes --notes=bar will show only the "bar" notes. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
We already have --show-notes, but it has a few shortcomings: 1. Using --show-notes=<ref> implies that we should also show the default notes. Which means you also need to use --no-standard-notes if you want to suppress them. 2. It is negated by --no-notes, which doesn't match. 3. It's too long to type. :) This patch introduces --notes, which behaves exactly like --show-notes, except that using "--notes=<ref>" does not imply showing the default notes. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
This is in preparation for more notes-related revision command-line options. The "suppress_default_notes" option is renamed to "use_default_notes", and is now a tri-state with values less than one indicating "not set". If the value is "not set", then we show default refs if and only if no other refs were given. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
There's no need to use an extra pointer, which just ends up leaking memory. The fact that the list is empty tells us the same thing. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
No need to do it ourselves when there is a library function. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 3月, 2011 1 次提交
-
-
由 Michael J Gruber 提交于
Introduce --min-parents and --max-parents options which limit the revisions to those commits which have at least (or at most) that many commits, where negative arguments for --max-parents= denote infinity (i.e. no upper limit). In particular: --max-parents=1 is the same as --no-merges; --min-parents=2 is the same as --merges; --max-parents=0 shows only roots; and --min-parents=3 shows only octopus merges Using --min-parents=n and --max-parents=m with n>m gives you what you ask for (i.e. nothing) for obvious reasons, just like when you give --merges (show only merge commits) and --no-merges (show only non-merge commits) at the same time. Also, introduce --no-min-parents and --no-max-parents to do the obvious thing for convenience. We compute the number of parents only when we limit by that, so there is no performance impact when there are no limiters. Signed-off-by: NMichael J Gruber <git@drmicha.warpmail.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 3月, 2011 1 次提交
-
-
由 Michael J Gruber 提交于
Currently, commit marks (left, right, boundary, cherry) are output right before the commit sha1, which makes it difficult to copy sha1s. Sample output for "git log --oneline --cherry": =049c269 t6007: test rev-list --cherry Change this to = 049c269 t6007: test rev-list --cherry which matches exactly the current output of "git log --graph". Leave "git rev-list" output as is (no space) so that they do not break. Adjust "git-svn" which uses "git log --pretty=raw --boundary". Signed-off-by: NMichael J Gruber <git@drmicha.warpmail.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 3月, 2011 3 次提交
-
-
由 Michael J Gruber 提交于
At the porcelain level, because by definition there are many more contributors than integrators, it makes sense to give a handy short-hand for --right-only used with --cherry-mark and --no-merges. Make it so. In other words, this provides "git cherry with rev-list interface". Signed-off-by: NMichael J Gruber <git@drmicha.warpmail.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael J Gruber 提交于
for marking those commits which "--cherry-pick" would drop. The marker for those commits is '=' because '-' denotes a boundary commit already, even though 'git cherry' uses it. Nonequivalent commits are denoted '+' unless '--left-right' is used. Signed-off-by: NMichael J Gruber <git@drmicha.warpmail.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael J Gruber 提交于
Currently, we have identical code for generating revision marks ('<', '>', '-') in 5 places. Factor out the code to a single function get_revision_mark() for easier maintenance and extensibility. Note that the check for !!revs in graph.c (which gets removed effectively by this patch) is superfluous. Signed-off-by: NMichael J Gruber <git@drmicha.warpmail.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 2月, 2011 2 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael J Gruber 提交于
The existing "--cherry-pick" does not work with unsymmetric ranges (A..B) for obvious reasons. Introduce "--left-only" and "--right-only" which limit the output to commits on the respective sides of a symmetric range (i.e. only "<" resp. ">" commits as per "--left-right"). This is especially useful for things like git log --cherry-pick --right-only @{u}... which is much more flexible (and descriptive) than git cherry @{u} | sed -ne 's/^+ //p' and potentially more useful than git log --cherry-pick @{u}... Signed-off-by: NMichael J Gruber <git@drmicha.warpmail.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 2月, 2011 2 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nguyễn Thái Ngọc Duy 提交于
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-