summaryrefslogtreecommitdiff
path: root/commit.c
AgeCommit message (Collapse)AuthorFilesLines
2013-04-12Sync with 'maint'Libravatar Junio C Hamano1-1/+1
* maint: Correct common spelling mistakes in comments and tests kwset: fix spelling in comments precompose-utf8: fix spelling of "want" in error message compat/nedmalloc: fix spelling in comments compat/regex: fix spelling and grammar in comments obstack: fix spelling of similar contrib/subtree: fix spelling of accidentally git-remote-mediawiki: spelling fixes doc: various spelling fixes fast-export: fix argument name in error messages Documentation: distinguish between ref and offset deltas in pack-format i18n: make the translation of -u advice in one go
2013-04-12Correct common spelling mistakes in comments and testsLibravatar Stefano Lattarini1-1/+1
Most of these were found using Lucas De Marchi's codespell tool. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-31merge/pull Check for untrusted good GPG signaturesLibravatar Sebastian Götte1-5/+9
When --verify-signatures is specified, abort the merge in case a good GPG signature from an untrusted key is encountered. Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-31commit.c/GPG signature verification: Also look at the first GPG status lineLibravatar Sebastian Götte1-5/+12
Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-31Move commit GPG signature verification to commit.cLibravatar Sebastian Götte1-0/+59
Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-05commit.c: use clear_commit_marks_many() in in_merge_bases_many()Libravatar Junio C Hamano1-2/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-05commit.c: add in_merge_bases_many()Libravatar Junio C Hamano1-6/+18
Similar to in_merge_bases(commit, other) that returns true when commit is an ancestor (i.e. in the merge bases between the two) of the other commit, in_merge_bases_many(commit, n_other, other[]) checks if commit is an ancestor of any of the other[] commits. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-05commit.c: add clear_commit_marks_many()Libravatar Junio C Hamano1-6/+13
clear_commit_marks(struct commit *, unsigned) only can clear flag bits starting from a single commit; introduce an API to allow feeding an array of commits, so that flag bits can be cleared from commits reachable from any of them with a single traversal. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-29Move print_commit_list to libgit.aLibravatar Nguyễn Thái Ngọc Duy1-0/+10
This is used by bisect.c, part of libgit.a while it stays in builtin/rev-list.c. Move it to commit.c so that we won't get undefined reference if a program that uses libgit.a happens to pull it in. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jeff King <peff@peff.net>
2012-10-08Merge branch 'jc/merge-bases-paint-fix'Libravatar Junio C Hamano1-0/+5
"git fmt-merge-msg" (an internal helper reduce_heads() it uses) had a severe performance regression; an empty "git pull" took forever to finish as the result. * jc/merge-bases-paint-fix: paint_down_to_common(): parse commit before relying on its timestamp
2012-10-04paint_down_to_common(): parse commit before relying on its timestampLibravatar Junio C Hamano1-0/+5
When refactoring the merge-base computation to reduce the pairwise O(n*(n-1)) traversals to parallel O(n) traversals, the code forgot that timestamp based heuristics needs each commit to have been parsed. This caused an empty "git pull" to spend cycles, traversing the history all the way down to 0 (because an unparsed commit object has 0 timestamp, and any other commit object with positive timestamp will be processed for its parents, all getting parsed), only to come up with a merge message to be used. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-15commit.c: mark a file-scope private symbol as staticLibravatar Junio C Hamano1-2/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-11Merge branch 'jc/merge-bases'Libravatar Junio C Hamano1-91/+120
Optimise the "merge-base" computation a bit, and also update its users that do not need the full merge-base information to call a cheaper subset. * jc/merge-bases: reduce_heads(): reimplement on top of remove_redundant() merge-base: "--is-ancestor A B" get_merge_bases_many(): walk from many tips in parallel in_merge_bases(): use paint_down_to_common() merge_bases_many(): split out the logic to paint history in_merge_bases(): omit unnecessary redundant common ancestor reduction http-push: use in_merge_bases() for fast-forward check receive-pack: use in_merge_bases() for fast-forward check in_merge_bases(): support only one "other" commit
2012-09-07Merge branch 'lt/commit-tree-guess-utf-8'Libravatar Junio C Hamano1-2/+86
Teach "git commit" and "git commit-tree" the "we are told to use utf-8 in log message, but this does not look like utf-8---attempt to pass it through convert-from-latin1-to-utf8 and see if it makes sense" heuristics "git mailinfo" already uses. * lt/commit-tree-guess-utf-8: commit/commit-tree: correct latin1 to utf-8
2012-08-31reduce_heads(): reimplement on top of remove_redundant()Libravatar Junio C Hamano1-38/+18
This is used by "git merge" and "git merge-base --independent" but used to use a similar N*(N-1) traversals to reject commits that are ancestors of other commits. Reimplement it on top of remove_redundant(). Note that the callers of this function are allowed to pass the same commit more than once, but remove_redundant() is designed to be fed each commit only once. The function removes duplicates before calling remove_redundant(). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-30get_merge_bases_many(): walk from many tips in parallelLibravatar Junio C Hamano1-21/+58
The get_merge_bases_many() function reduces the result returned by the merge_bases_many() function, which is a set of possible merge bases, by excluding commits that can be reached from other commits. We used to do N*(N-1) traversals for this, but we can check if one commit reaches which other (N-1) commits by a single traversal, and repeat it for all the candidates to find the answer. Introduce remove_redundant() helper function to do this painting; we should be able to use it to reimplement reduce_heads() as well. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-30in_merge_bases(): use paint_down_to_common()Libravatar Junio C Hamano1-10/+7
With paint_down_to_common(), we can tell if "commit" is reachable from "reference" by simply looking at its object flag, instead of iterating over the merge bases. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-30merge_bases_many(): split out the logic to paint historyLibravatar Junio C Hamano1-19/+28
Introduce a new helper function paint_down_to_common() that takes the same parameters as merge_bases_many(), but without the first optimization of not painting anything when "one" is one of the "twos" (or vice versa), and the last clean-up of removing the common ancestor that is known to be an ancestor of another common one. This way, the caller of the new function could tell if "one" is reachable from any of the "twos" by simply looking at the flag bits of "one". If (and only if) it is painted in PARENT2, it is reachable from one of the "twos". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-28in_merge_bases(): omit unnecessary redundant common ancestor reductionLibravatar Thomas Rast1-1/+4
The function get_merge_bases() needs to postprocess the result from merge_bases_many() in order to make sure none of the commit is a true ancestor of another commit, which is expensive. However, when checking if a commit is an ancestor of another commit, we only need to see if the commit is a common ancestor between the two, and do not have to care if other common ancestors merge_bases_many() finds are true merge bases or an ancestor of another merge base. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27in_merge_bases(): support only one "other" commitLibravatar Junio C Hamano1-6/+9
In early days of its life, I planned to make it possible to compute "is a commit contained in all of these other commits?" with this function, but it turned out that no caller needed it. Just make it take two commit objects and add a comment to say what these two functions do. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-21commit/commit-tree: correct latin1 to utf-8Libravatar Linus Torvalds1-2/+86
When a line in the message is not a valid utf-8, "git mailinfo" attempts to convert it to utf-8 assuming the input is latin1 (and punt if it does not convert cleanly). Using the same heuristics in "git commit" and "git commit-tree" lets the editor output be in latin1 to make the overall system more consistent. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-22Merge branch 'jc/sha1-name-more'Libravatar Junio C Hamano1-1/+1
Teaches the object name parser things like a "git describe" output is always a commit object, "A" in "git log A" must be a committish, and "A" and "B" in "git log A...B" both must be committish, etc., to prolong the lifetime of abbreviated object names. * jc/sha1-name-more: (27 commits) t1512: match the "other" object names t1512: ignore whitespaces in wc -l output rev-parse --disambiguate=<prefix> rev-parse: A and B in "rev-parse A..B" refer to committish reset: the command takes committish commit-tree: the command wants a tree and commits apply: --build-fake-ancestor expects blobs sha1_name.c: add support for disambiguating other types revision.c: the "log" family, except for "show", takes committish revision.c: allow handle_revision_arg() to take other flags sha1_name.c: introduce get_sha1_committish() sha1_name.c: teach lookup context to get_sha1_with_context() sha1_name.c: many short names can only be committish sha1_name.c: get_sha1_1() takes lookup flags sha1_name.c: get_describe_name() by definition groks only commits sha1_name.c: teach get_short_sha1() a commit-only option sha1_name.c: allow get_short_sha1() to take other flags get_sha1(): fix error status regression sha1_name.c: restructure disambiguation of short names sha1_name.c: correct misnamed "canonical" and "res" ...
2012-07-09sha1_name.c: introduce get_sha1_committish()Libravatar Junio C Hamano1-1/+1
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: Junio C Hamano <gitster@pobox.com>
2012-05-24ident: rename IDENT_ERROR_ON_NO_NAME to IDENT_STRICTLibravatar Jeff King1-2/+2
Callers who ask for ERROR_ON_NO_NAME are not so much concerned that the name will be blank (because, after all, we will fall back to using the username), but rather it is a check to make sure that low-quality identities do not end up in things like commit messages or emails (whereas it is OK for them to end up in things like reflogs). When future commits add more quality checks on the identity, each of these callers would want to use those checks, too. Rather than modify each of them later to add a new flag, let's refactor the flag. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-25commit: remove commit_list_reverse()Libravatar René Scharfe1-15/+0
The function commit_list_reverse() is not used anymore; delete it. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-25sequencer: export commit_list_append()Libravatar René Scharfe1-0/+27
This function can be used in other parts of git. Give it a new home in commit.c. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-23Merge branch 'rs/commit-list-sort-in-batch'Libravatar Junio C Hamano1-6/+38
Setting up a revision traversal with many starting points was inefficient as these were placed in a date-order priority queue one-by-one. By René Scharfe (3) and Junio C Hamano (1) * rs/commit-list-sort-in-batch: mergesort: rename it to llist_mergesort() revision: insert unsorted, then sort in prepare_revision_walk() commit: use mergesort() in commit_list_sort_by_date() add mergesort() for linked lists
2012-04-17mergesort: rename it to llist_mergesort()Libravatar Junio C Hamano1-2/+2
Even though the function is generic enough, <anything>sort() inherits connotations from the standard function qsort() that sorts an array. Rename it to llist_mergesort() and describe the external interface in its header file. This incidentally avoids name clashes with mergesort() some platforms declare in, and contaminate user namespace with, their <stdlib.h>. Reported-by: Brian Gernhardt Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-11revision: insert unsorted, then sort in prepare_revision_walk()Libravatar René Scharfe1-0/+15
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: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-11commit: use mergesort() in commit_list_sort_by_date()Libravatar René Scharfe1-6/+23
Replace the insertion sort in commit_list_sort_by_date() with a call to the generic mergesort function. This sets the stage for using commit_list_sort_by_date() for larger lists, as shown in the next patch. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-29Merge branch 'nd/index-pack-no-recurse'Libravatar Junio C Hamano1-2/+11
* nd/index-pack-no-recurse: index-pack: eliminate unlimited recursion in get_base_data() index-pack: eliminate recursion in find_unresolved_deltas Eliminate recursion in setting/clearing marks in commit list
2012-01-16Eliminate recursion in setting/clearing marks in commit listLibravatar Nguyễn Thái Ngọc Duy1-2/+11
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: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-06Merge branch 'jc/show-sig'Libravatar Junio C Hamano1-7/+111
* jc/show-sig: log --show-signature: reword the common two-head merge case log-tree: show mergetag in log --show-signature output log-tree.c: small refactor in show_signature() commit --amend -S: strip existing gpgsig headers verify_signed_buffer: fix stale comment gpg-interface: allow use of a custom GPG binary pretty: %G[?GS] placeholders test "commit -S" and "log --show-signature" log: --show-signature commit: teach --gpg-sign option Conflicts: builtin/commit-tree.c builtin/commit.c builtin/merge.c notes-cache.c pretty.c
2012-01-05commit --amend -S: strip existing gpgsig headersLibravatar Junio C Hamano1-4/+22
Any existing commit signature was made against the contents of the old commit, including its committer date that is about to change, and will become invalid by amending it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-22Merge branch 'nd/war-on-nul-in-commit'Libravatar Junio C Hamano1-3/+6
* nd/war-on-nul-in-commit: commit_tree(): refuse commit messages that contain NULs Convert commit_tree() to take strbuf as message merge: abort if fails to commit Conflicts: builtin/commit.c commit.c commit.h
2011-12-15commit_tree(): refuse commit messages that contain NULsLibravatar Nguyễn Thái Ngọc Duy1-0/+3
Current implementation sees NUL as terminator. If users give a message with NUL byte in it (e.g. editor set to save as UTF-16), the new commit message will have NULs. However following operations (displaying or amending a commit for example) will not keep anything after the first NUL. Stop user right when they do this. If NUL is added by mistake, they have their chance to fix. Otherwise, log messages will no longer be text "git log" and friends would grok. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-15Convert commit_tree() to take strbuf as messageLibravatar Nguyễn Thái Ngọc Duy1-2/+2
There wan't a way for commit_tree() to notice if the message the caller prepared contained a NUL byte, as it did not take the length of the message as a parameter. Use a pointer to a strbuf instead, so that we can either choose to allow low-level plumbing commands to make commits that contain NUL byte in its message, or forbid NUL everywhere by adding the check in commit_tree(), in later patches. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-12log: --show-signatureLibravatar Junio C Hamano1-0/+44
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: Junio C Hamano <gitster@pobox.com>
2011-11-12commit: teach --gpg-sign optionLibravatar Junio C Hamano1-3/+45
This uses the gpg-interface.[ch] to allow signing the commit, i.e. $ git commit --gpg-sign -m foo You need a passphrase to unlock the secret key for user: "Junio C Hamano <gitster@pobox.com>" 4096-bit RSA key, ID 96AFE6CB, created 2011-10-03 (main key ID 713660A7) [master 8457d13] foo 1 files changed, 1 insertions(+), 0 deletions(-) The lines of GPG detached signature are placed in a new multi-line header field, instead of tucking the signature block at the end of the commit log message text (similar to how signed tag is done), for multiple reasons: - The signature won't clutter output from "git log" and friends if it is in the extra header. If we place it at the end of the log message, we would need to teach "git log" and friends to strip the signature block with an option. - Teaching new versions of "git log" and "gitk" to optionally verify and show signatures is cleaner if we structurally know where the signature block is (instead of scanning in the commit log message). - The signature needs to be stripped upon various commit rewriting operations, e.g. rebase, filter-branch, etc. They all already ignore unknown headers, but if we place signature in the log message, all of these tools (and third-party tools) also need to learn how a signature block would look like. - When we added the optional encoding header, all the tools (both in tree and third-party) that acts on the raw commit object should have been fixed to ignore headers they do not understand, so it is not like that new header would be more likely to break than extra text in the commit. A commit made with the above sample sequence would look like this: $ git cat-file commit HEAD tree 3cd71d90e3db4136e5260ab54599791c4f883b9d parent b87755351a47b09cb27d6913e6e0e17e6254a4d4 author Junio C Hamano <gitster@pobox.com> 1317862251 -0700 committer Junio C Hamano <gitster@pobox.com> 1317862251 -0700 gpgsig -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAABAgAGBQJOjPtrAAoJELC16IaWr+bL4TMP/RSe2Y/jYnCkds9unO5JEnfG ... =dt98 -----END PGP SIGNATURE----- foo but "git log" (unless you ask for it with --pretty=raw) output is not cluttered with the signature information. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-09commit: teach --amend to carry forward extra headersLibravatar Junio C Hamano1-1/+66
After running "git pull $there for-linus" to merge a signed tag, the integrator may need to amend the resulting merge commit to fix typoes in it. Teach --amend option to read the existing extra headers, and carry them forward. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-09commit: copy merged signed tags to headers of merge commitLibravatar Junio C Hamano1-4/+92
Now MERGE_HEAD records the tag objects without peeling, we could record the result of manual conflict resolution via "git commit" without losing the tag information. Introduce a new "mergetag" multi-line header field to the commit object, and use it to store the entire contents of each signed tag merged. A commit header that has a multi-line payload begins with the header tag (e.g. "mergetag" in this case), SP, the first line of payload, LF, and all the remaining lines have a SP inserted at the beginning. In hindsight, it would have been better to make "merge --continue" as the way to continue from such an interrupted merge, not "commit", but this is a backward compatibility baggage we would need to carry around for now. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-08merge: make usage of commit->util more extensibleLibravatar Junio C Hamano1-0/+19
The merge-recursive code uses the commit->util field directly to annotate the commit objects given from the command line, i.e. the remote heads to be merged, with a single string to be used to describe it in its trace messages and conflict markers. Correct this short-signtedness by redefining the field to be a pointer to a structure "struct merge_remote_desc" that later enhancements can add more information. Store the original objects we were told to merge in a field "obj" in this struct, so that we can recover the tag we were told to merge. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-13Merge branch 'rs/pending'Libravatar Junio C Hamano1-0/+14
* rs/pending: commit: factor out clear_commit_marks_for_object_array checkout: use leak_pending flag bundle: use leak_pending flag bisect: use leak_pending flag revision: add leak_pending flag checkout: use add_pending_{object,sha1} in orphan check revision: factor out add_pending_sha1 checkout: check for "Previous HEAD" notice in t2020 Conflicts: builtin/checkout.c revision.c
2011-10-13Merge branch 'nd/maint-autofix-tag-in-head'Libravatar Junio C Hamano1-0/+12
* nd/maint-autofix-tag-in-head: Accept tags in HEAD or MERGE_HEAD merge: remove global variable head[] merge: use return value of resolve_ref() to determine if HEAD is invalid merge: keep stash[] a local variable Conflicts: builtin/merge.c
2011-10-03commit: factor out clear_commit_marks_for_object_arrayLibravatar René Scharfe1-0/+14
Factor out the code to clear the commit marks for a whole struct object_array from builtin/checkout.c into its own exported function clear_commit_marks_for_object_array and use it in bisect and bundle as well. It handles tags and commits and ignores objects of any other type. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-18Accept tags in HEAD or MERGE_HEADLibravatar Nguyễn Thái Ngọc Duy1-0/+12
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: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-28Merge branch 'nd/decorate-grafts'Libravatar Junio C Hamano1-16/+6
* nd/decorate-grafts: log: Do not decorate replacements with --no-replace-objects log: decorate "replaced" on to replaced commits log: decorate grafted commits with "grafted" Move write_shallow_commits to fetch-pack.c Add for_each_commit_graft() to iterate all grafts decoration: do not mis-decorate refs with same prefix
2011-08-25whitespace: have SP on both sides of an assignment "="Libravatar Junio C Hamano1-1/+1
I've deliberately excluded the borrowed code in compat/nedmalloc directory. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18Move write_shallow_commits to fetch-pack.cLibravatar Nguyễn Thái Ngọc Duy1-18/+0
This function produces network traffic and should be in fetch-pack. It has been in commit.c because it needs to iterate (private) graft list. It can now do so using for_each_commit_graft(). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18Add for_each_commit_graft() to iterate all graftsLibravatar Nguyễn Thái Ngọc Duy1-0/+8
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>