- 17 4月, 2013 1 次提交
-
-
由 Thomas Rast 提交于
read_revisions_from_stdin() has passed pointers to its read buffer down to handle_revision_arg() since its inception way back in 42cabc34 (Teach rev-list an option to read revs from the standard input., 2006-09-05). Even back then, this was a bug: through add_pending_object, the argument was recorded in the object_array's 'name' field. Fix it by making a copy whenever read_revisions_from_stdin() passes an argument down the callchain. The other caller runs handle_revision_arg() on argv[], where it would be redundant to make a copy. Signed-off-by: NThomas Rast <trast@inf.ethz.ch> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 9月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
Our "grep" allows complex boolean expressions to be formed to match each individual line with operators like --and, '(', ')' and --not. Introduce the "--debug" option to show the parse tree to help people who want to debug and enhance it. Also "log" learns "--grep-debug" option to do the same. The command line parser to the log family is a lot more limited than the general "git grep" parser, but it has special handling for header matching (e.g. "--author"), and a parse tree is valuable when working on it. Note that "--all-match" is *not* any individual node in the parse tree. It is an instruction to the evaluator to check all the nodes in the top-level backbone have matched and reject a document as non-matching otherwise. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 31 8月, 2012 1 次提交
-
-
由 Martin von Zweigbergk 提交于
When 'git log' is passed the --no-walk option, no revision walk takes place, naturally. Perhaps somewhat surprisingly, however, the provided revisions still get sorted by commit date. So e.g 'git log --no-walk HEAD HEAD~1' and 'git log --no-walk HEAD~1 HEAD' give the same result (unless the two revisions share the commit date, in which case they will retain the order given on the command line). As the commit that introduced --no-walk (8e64006e (Teach revision machinery about --no-walk, 2007-07-24)) points out, the sorting is intentional, to allow things like git log --abbrev-commit --pretty=oneline --decorate --all --no-walk to show all refs in order by commit date. But there are also other cases where the sorting is not wanted, such as <command producing revisions in order> | git log --oneline --no-walk --stdin To accomodate both cases, leave the decision of whether or not to sort up to the caller, by allowing --no-walk={sorted,unsorted}, defaulting to 'sorted' for backward-compatibility reasons. Signed-off-by: NMartin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 8月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
Either end of revision range operator can be omitted to default to HEAD, as in "origin.." (what did I do since I forked) or "..origin" (what did they do since I forked). But the current parser interprets ".." as an empty range "HEAD..HEAD", and worse yet, because ".." does exist on the filesystem, we get this annoying output: $ cd Documentation/howto $ git log .. ;# give me recent commits that touch Documentation/ area. fatal: ambiguous argument '..': both revision and filename Use '--' to separate filenames from revisions Surely we could say "git log ../" or even "git log -- .." to disambiguate, but we shouldn't have to. Helped-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 8月, 2012 1 次提交
-
-
由 Thomas Rast 提交于
diff_setup_done() has historically returned an error code, but lost the last nonzero return in 943d5b73 (allow diff.renamelimit to be set regardless of -M/-C, 2006-08-09). The callers were in a pretty confused state: some actually checked for the return code, and some did not. Let it return void, and patch all callers to take this into account. This conveniently also gets rid of a handful of different(!) error messages that could never be triggered anyway. Note that the function can still die(). Signed-off-by: NThomas Rast <trast@student.ethz.ch> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 30 7月, 2012 1 次提交
-
-
由 Jeff King 提交于
The diff code represents paths using the diff_filespec struct. This struct has a sha1 to represent the sha1 of the content at that path, as well as a sha1_valid member which indicates whether its sha1 field is actually useful. If sha1_valid is not true, then the filespec represents a working tree file (e.g., for the no-index case, or for when the index is not up-to-date). The diff_filespec is only used internally, though. At the interfaces to the diff subsystem, callers feed the sha1 directly, and we create a diff_filespec from it. It's at that point that we look at the sha1 and decide whether it is valid or not; callers may pass the null sha1 as a sentinel value to indicate that it is not. We should not typically see the null sha1 coming from any other source (e.g., in the index itself, or from a tree). However, a corrupt tree might have a null sha1, which would cause "diff --patch" to accidentally diff the working tree version of a file instead of treating it as a blob. This patch extends the edges of the diff interface to accept a "sha1_valid" flag whenever we accept a sha1, and to use that flag when creating a filespec. In some cases, this means passing the flag through several layers, making the code change larger than would be desirable. One alternative would be to simply die() upon seeing corrupted trees with null sha1s. However, this fix more directly addresses the problem (while bogus sha1s in a tree are probably a bad thing, it is really the sentinel confusion sending us down the wrong code path that is what makes it devastating). And it means that git is more capable of examining and debugging these corrupted trees. For example, you can still "diff --raw" such a tree to find out when the bogus entry was introduced; you just cannot do a "--patch" diff (just as you could not with any other corrupted tree, as we do not have any content to diff). Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 7月, 2012 1 次提交
-
-
由 Jeff King 提交于
During a revision traversal in which --max-count has been specified, we decrement a counter for each revision returned by get_revision. When it hits 0, we typically return NULL (the exception being if we still have boundary commits to show). However, before we check the counter, we call get_revision_1 to get the next commit. This might involve looking at a large number of commits if we have restricted the traversal (e.g., we might traverse until we find the next commit whose diff actually matches a pathspec). There's no need to make this get_revision_1 call when our counter runs out. If we are not in --boundary mode, we will just throw away the result and immediately return NULL. If we are in --boundary mode, then we will still throw away the result, and then start showing the boundary commits. However, as git_revision_1 does not impact the boundary list, it should not have an impact. In most cases, avoiding this work will not be especially noticeable. However, in some cases, it can make a big difference: [before] $ time git rev-list -1 origin Documentation/RelNotes/1.7.11.2.txt 8d141a1d real 0m0.301s user 0m0.280s sys 0m0.016s [after] $ time git rev-list -1 origin Documentation/RelNotes/1.7.11.2.txt 8d141a1d real 0m0.010s user 0m0.008s sys 0m0.000s Note that the output is produced almost instantaneously in the first case, and then git uselessly spends a long time looking for the next commit to touch that file (but there isn't one, and we traverse all the way down to the roots). Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 7月, 2012 4 次提交
-
-
由 Junio C Hamano 提交于
Add a field to setup_revision_opt structure and allow these callers to tell the setup_revisions command parsing machinery that short SHA1 it encounters are meant to name committish. This step does not go all the way to connect the setup_revisions() to sha1_name.c yet. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
The existing "cant_be_filename" that tells the function that the caller knows the arg is not a path (hence it does not have to be checked for absense of the file whose name matches it) is made into a bit in the flag word. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Many callers know that the user meant to name a committish by syntactical positions where the object name appears. Calling this function allows the machinery to disambiguate shorter-than-unique abbreviated object names between committish and others. Note that this does NOT error out when the named object is not a committish. It is merely to give a hint to the disambiguation machinery. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
The function takes user input string and returns the object name (binary SHA-1) with mode bits and path when the object was looked up in a tree. Additionally give hints to help disambiguation of abbreviated object names when the caller knows what it is looking for. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 7月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
There are only two callers, and they will benefit from being able to pass disambiguation hints to underlying get_sha1_with_context() API once it happens. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 6月, 2012 1 次提交
-
-
由 Matthieu Moy 提交于
verify_filename() can be called in two different contexts. Either we just tried to interpret a string as an object name, and it fails, so we try looking for a working tree file (i.e. we finished looking at revs that come earlier on the command line, and the next argument must be a pathname), or we _know_ that we are looking for a pathname, and shouldn't even try interpreting the string as an object name. For example, with this change, we get: $ git log COPYING HEAD:inexistant fatal: HEAD:inexistant: no such path in the working tree. Use '-- <path>...' to specify paths that do not exist locally. $ git log HEAD:inexistant fatal: Path 'inexistant' does not exist in 'HEAD' Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 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 1 次提交
-
-
由 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>
-