summaryrefslogtreecommitdiff
path: root/builtin/commit.c
AgeCommit message (Collapse)AuthorFilesLines
2012-02-12Merge branch 'nd/cache-tree-api-refactor'Libravatar Junio C Hamano1-2/+2
* nd/cache-tree-api-refactor: cache-tree: update API to take abitrary flags
2012-02-10Merge branch 'jc/parse-date-raw'Libravatar Junio C Hamano1-0/+6
* jc/parse-date-raw: parse_date(): '@' prefix forces git-timestamp parse_date(): allow ancient git-timestamp
2012-02-07cache-tree: update API to take abitrary flagsLibravatar Nguyễn Thái Ngọc Duy1-2/+2
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-03parse_date(): '@' prefix forces git-timestampLibravatar Junio C Hamano1-0/+6
The only place that the issue this series addresses was observed where we read "cat-file commit" output and put it in GIT_AUTHOR_DATE in order to replay a commit with an ancient timestamp. With the previous patch alone, "git commit --date='20100917 +0900'" can be misinterpreted to mean an ancient timestamp, not September in year 2010. Guard this codepath by requring an extra '@' in front of the raw git timestamp on the parsing side. This of course needs to be compensated by updating get_author_ident_from_commit and the code for "git commit --amend" to prepend '@' to the string read from the existing commit in the GIT_AUTHOR_DATE environment variable. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-01i18n: git-commit whence_s "merge/cherry-pick" messageLibravatar Jiang Xin1-3/+3
Mark the "merge/cherry-pick" messages in whence_s for translation. These messages returned from whence_s function are used as argument to build other messages. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-06Merge branch 'jc/show-sig'Libravatar Junio C Hamano1-2/+12
* 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-1/+2
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>
2012-01-05Merge branch 'jc/signed-commit' and 'jc/pull-signed-tag'Libravatar Junio C Hamano1-1/+10
They both use the extended headers in commit objects, and the former has necessary infrastructure to show them that is useful to view the result of the latter. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-22Merge branch 'jk/maint-strbuf-missing-init'Libravatar Junio C Hamano1-1/+1
* jk/maint-strbuf-missing-init: commit, merge: initialize static strbuf Conflicts: builtin/merge.c
2011-12-22Merge branch 'nd/war-on-nul-in-commit'Libravatar Junio C Hamano1-1/+1
* 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-21Sync with v1.7.8.1Libravatar Junio C Hamano1-1/+1
2011-12-21Merge branch 'ms/commit-cc-option-helpstring' into maintLibravatar Junio C Hamano1-1/+1
* ms/commit-cc-option-helpstring: builtin/commit: add missing '/' in help message
2011-12-20Merge branch 'jc/pull-signed-tag'Libravatar Junio C Hamano1-1/+5
* jc/pull-signed-tag: commit: do not lose mergetag header when not amending
2011-12-20commit: do not lose mergetag header when not amendingLibravatar Junio C Hamano1-1/+5
The earlier ed7a42a (commit: teach --amend to carry forward extra headers, 2011-11-08) broke "git merge/pull; edit to fix conflict; git commit" workflow by forgetting that commit_tree_extended() takes the whole extra header list. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-19Merge branch 'nd/resolve-ref'Libravatar Junio C Hamano1-1/+1
* nd/resolve-ref: Rename resolve_ref() to resolve_ref_unsafe() Convert resolve_ref+xstrdup to new resolve_refdup function revert: convert resolve_ref() to read_ref_full()
2011-12-19Merge branch 'tr/cache-tree'Libravatar Junio C Hamano1-4/+3
* tr/cache-tree: reset: update cache-tree data when appropriate commit: write cache-tree data when writing index anyway Refactor cache_tree_update idiom from commit Test the current state of the cache-tree optimization Add test-scrap-cache-tree
2011-12-18Update jk/maint-strbuf-missing-init to builtin/ renameLibravatar Junio C Hamano1-0/+1310
2011-12-16Merge branch 'jc/commit-amend-no-edit'Libravatar Junio C Hamano1-4/+5
* jc/commit-amend-no-edit: test: commit --amend should honor --no-edit commit: honour --no-edit t7501 (commit): modernize style test: remove a porcelain test that hard-codes commit names test: add missing "&&" after echo command
2011-12-15Convert commit_tree() to take strbuf as messageLibravatar Nguyễn Thái Ngọc Duy1-1/+1
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-12-13Rename resolve_ref() to resolve_ref_unsafe()Libravatar Nguyễn Thái Ngọc Duy1-1/+1
resolve_ref() may return a pointer to a shared buffer and can be overwritten by the next resolve_ref() calls. Callers need to pay attention, not to keep the pointer when the next call happens. Rename with "_unsafe" suffix to warn developers (or reviewers) before introducing new call sites. This patch is generated using the following command git grep -l 'resolve_ref(' -- '*.[ch]'|xargs sed -i 's/resolve_ref(/resolve_ref_unsafe(/g' Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-09Merge branch 'nd/resolve-ref'Libravatar Junio C Hamano1-1/+2
* nd/resolve-ref: Copy resolve_ref() return value for longer use Convert many resolve_ref() calls to read_ref*() and ref_exists() Conflicts: builtin/fmt-merge-msg.c builtin/merge.c refs.c
2011-12-09Merge branch 'jc/pull-signed-tag'Libravatar Junio C Hamano1-7/+12
* jc/pull-signed-tag: commit-tree: teach -m/-F options to read logs from elsewhere commit-tree: update the command line parsing commit: teach --amend to carry forward extra headers merge: force edit and no-ff mode when merging a tag object commit: copy merged signed tags to headers of merge commit merge: record tag objects without peeling in MERGE_HEAD merge: make usage of commit->util more extensible fmt-merge-msg: Add contents of merged tag in the merge message fmt-merge-msg: package options into a structure fmt-merge-msg: avoid early returns refs DWIMmery: use the same rule for both "git fetch" and others fetch: allow "git fetch $there v1.0" to fetch a tag merge: notice local merging of tags and keep it unwrapped fetch: do not store peeled tag object names in FETCH_HEAD Split GPG interface into its own helper library Conflicts: builtin/fmt-merge-msg.c builtin/merge.c
2011-12-08commit: honour --no-editLibravatar Junio C Hamano1-4/+5
After making fixes to the contents to be committed, it is not unusual to update the current commit without rewording the message. Idioms to tell "commit --amend" that we do not need an editor have been: $ EDITOR=: git commit --amend $ git commit --amend -C HEAD but that was only because a more natural "--no-edit" option in $ git commit --amend --no-edit was not honoured. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-06commit: write cache-tree data when writing index anywayLibravatar Thomas Rast1-0/+2
In prepare_index(), we refresh the index, and then write it to disk if this changed the index data. After running hooks we re-read the index and compute the root tree sha1 with the cache-tree machinery. This gives us a mostly free opportunity to write up-to-date cache-tree data: we can compute it in prepare_index() immediately before writing the index to disk. If we do this, we were going to write the index anyway, and the later cache-tree update has no further work to do. If we don't do it, we don't do any extra work, though we still don't have have cache-tree data after the commit. The only case that suffers badly is when the pre-commit hook changes many trees in the index. I'm writing this off as highly unusual. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-06Refactor cache_tree_update idiom from commitLibravatar Thomas Rast1-4/+1
We'll need to safely create or update the cache-tree data of the_index from other places. While at it, give it an argument that lets us silence the messages produced by unmerged entries (which prevent it from working). Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-05Copy resolve_ref() return value for longer useLibravatar Nguyễn Thái Ngọc Duy1-1/+2
resolve_ref() may return a pointer to a static buffer. Callers that use this value longer than a couple of statements should copy the value to avoid some hidden resolve_ref() call that may change the static buffer's value. The bug found by Tony Wang <wwwjfy@gmail.com> in builtin/merge.c demonstrates this. The first call is in cmd_merge() branch = resolve_ref("HEAD", head_sha1, 0, &flag); Then deep in lookup_commit_or_die() a few lines after, resolve_ref() may be called again and destroy "branch". lookup_commit_or_die lookup_commit_reference lookup_commit_reference_gently parse_object lookup_replace_object do_lookup_replace_object prepare_replace_object for_each_replace_ref do_for_each_ref get_loose_refs get_ref_dir get_ref_dir resolve_ref All call sites are checked and made sure that xstrdup() is called if the value should be saved. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-22revert: write REVERT_HEAD pseudoref during conflicted revertLibravatar Jonathan Nieder1-0/+1
When conflicts are encountered while reverting a commit, it can be handy to have the name of that commit easily available. For example, to produce a copy of the patch to refer to while resolving conflicts: $ git revert 2eceb2a8 error: could not revert 2eceb2a8... awesome, buggy feature $ git show -R REVERT_HEAD >the-patch $ edit $(git diff --name-only) Set a REVERT_HEAD pseudoref when "git revert" does not make a commit, for cases like this. This also makes it possible for scripts to distinguish between a revert that encountered conflicts and other sources of an unmerged index. After successfully committing, resetting with "git reset", or moving to another commit with "git checkout" or "git reset", the pseudoref is no longer useful, so remove it. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-12commit: teach --gpg-sign optionLibravatar Junio C Hamano1-1/+10
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-2/+7
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-5/+5
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-10-13Merge branch 'nd/maint-autofix-tag-in-head'Libravatar Junio C Hamano1-2/+4
* 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-10Merge branch 'cb/common-prefix-unification'Libravatar Junio C Hamano1-2/+3
* cb/common-prefix-unification: rename pathspec_prefix() to common_prefix() and move to dir.[ch] consolidate pathspec_prefix and common_prefix remove prefix argument from pathspec_prefix
2011-09-18Accept tags in HEAD or MERGE_HEADLibravatar Nguyễn Thái Ngọc Duy1-2/+4
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-09-12rename pathspec_prefix() to common_prefix() and move to dir.[ch]Libravatar Clemens Buchacher1-1/+1
Also make common_prefix_len() static as this refactoring makes dir.c itself the only caller of this helper function. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-06remove prefix argument from pathspec_prefixLibravatar Clemens Buchacher1-2/+3
Passing a prefix to a function that is supposed to find the prefix is strange. And it's really only used if the pathspec is NULL. Make the callers handle this case instead. As we are always returning a fresh copy of a string (or NULL), change the type of the returned value to non-const "char *". Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-28Merge branch 'jk/color-and-pager'Libravatar Junio C Hamano1-11/+2
* jk/color-and-pager: want_color: automatically fallback to color.ui diff: don't load color config in plumbing config: refactor get_colorbool function color: delay auto-color decision until point of use git_config_colorbool: refactor stdout_is_tty handling diff: refactor COLOR_DIFF from a flag into an int setup_pager: set GIT_PAGER_IN_USE t7006: use test_config helpers test-lib: add helper functions for config t7006: modernize calls to unset Conflicts: builtin/commit.c parse-options.c
2011-08-25Merge branch 'jc/maint-autofix-tag-in-head'Libravatar Junio C Hamano1-42/+45
* jc/maint-autofix-tag-in-head: commit: reduce use of redundant global variables
2011-08-23Merge branch 'cb/maint-ls-files-error-report'Libravatar Junio C Hamano1-1/+1
* cb/maint-ls-files-error-report: ls-files: fix pathspec display on error
2011-08-19want_color: automatically fallback to color.uiLibravatar Jeff King1-10/+1
All of the "do we want color" flags default to -1 to indicate that we don't have any color configured. This value is handled in one of two ways: 1. In porcelain, we check early on whether the value is still -1 after reading the config, and set it to the value of color.ui (which defaults to 0). 2. In plumbing, it stays untouched as -1, and want_color defaults it to off. This works fine, but means that every porcelain has to check and reassign its color flag. Now that want_color gives us a place to put this check in a single spot, we can do that, simplifying the calling code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-19commit: reduce use of redundant global variablesLibravatar Junio C Hamano1-42/+45
The file-scope global variable head_sha1[] was used to hold the object name of the current HEAD commit (unless we are about to make an initial commit). Also there is an independent "static int initial_commit". Fix all the functions on the call-chain that use these two variables to take a new "(const) struct commit *current_head" argument instead, and replace their uses, e.g. "if (initial_commit)" becomes "if (!current_head)" and a reference to "head_sha1" becomes "current_head->object.sha1". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18git_config_colorbool: refactor stdout_is_tty handlingLibravatar Jeff King1-1/+1
Usually this function figures out for itself whether stdout is a tty. However, it has an extra parameter just to allow git-config to override the auto-detection for its --get-colorbool option. Instead of an extra parameter, let's just use a global variable. This makes calling easier in the common case, and will make refactoring the colorbool code much simpler. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-11ls-files: fix pathspec display on errorLibravatar Clemens Buchacher1-1/+1
The following sequence of commands reveals an issue with error reporting of relative paths: $ mkdir sub $ cd sub $ git ls-files --error-unmatch ../bbbbb error: pathspec 'b' did not match any file(s) known to git. $ git commit --error-unmatch ../bbbbb error: pathspec 'b' did not match any file(s) known to git. This bug is visible only if the normalized path (i.e., the relative path from the repository root) is longer than the prefix. Otherwise, the code skips over the normalized path and reads from an unused memory location which still contains a leftover of the original command line argument. So instead, use the existing facilities to deal with relative paths correctly. Also fix inconsistency between "checkout" and "commit", e.g. $ cd Documentation $ git checkout nosuch.txt error: pathspec 'Documentation/nosuch.txt' did not match... $ git commit nosuch.txt error: pathspec 'nosuch.txt' did not match... by propagating the prefix down the codepath that reports the error. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-02commit: allow partial commits with relative pathsLibravatar Clemens Buchacher1-2/+4
In order to do partial commits, git-commit overlays a tree on the cache and checks pathspecs against the result. Currently, the overlaying is done using "prefix" which prevents relative pathspecs with ".." and absolute pathspec from matching when they refer to files not under "prefix" and absent from the index, but still in the tree (i.e. files staged for removal). The point of providing a prefix at all is performance optimization. If we say there is no common prefix for the files of interest, then we have to read the entire tree into the index. But even if we cannot use the working directory as a prefix, we can still figure out if there is a common prefix for all given paths, and use that instead. The pathspec_prefix() routine from ls-files.c does exactly that. Any use of global variables is removed from pathspec_prefix() so that it can be called from commit.c. Reported-by: Reuben Thomas <rrt@sc3d.org> Analyzed-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-06Merge branch 'bc/maint-status-z-to-use-porcelain'Libravatar Junio C Hamano1-3/+4
* bc/maint-status-z-to-use-porcelain: builtin/commit.c: set status_format _after_ option parsing t7508: demonstrate status's failure to use --porcelain format with -z Conflicts: builtin/commit.c
2011-05-16Merge branch 'ci/commit--interactive-atomic'Libravatar Junio C Hamano1-12/+34
* ci/commit--interactive-atomic: Test atomic git-commit --interactive Add commit to list of config.singlekey commands Add support for -p/--patch to git-commit Allow git commit --interactive with paths t7501.8: feed a meaningful command Use a temporary index for git commit --interactive
2011-05-11Do not strip empty lines / trailing spaces from a commit message templateLibravatar Boris Faure1-1/+3
Templates should be just that: A form that the user fills out, and forms have blanks. If people are attached to not having extra whitespace in the editor, they can simply clean up their templates. Added test with editor adding even more whitespace. Signed-off-by: Boris Faure <billiob@gmail.com> Based-on-patch-by:Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-09Add support for -p/--patch to git-commitLibravatar Conrad Irwin1-3/+7
The --interactive flag is already shared by git add and git commit, share the -p and --patch flags too. Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-09Allow git commit --interactive with pathsLibravatar Conrad Irwin1-2/+0
Make git commit --interactive feel more like git add --interactive by allowing the user to restrict the list of files they have to deal with. A test in t7501 used to ensure that this is not allowed; no need for that anymore. Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-08Use a temporary index for git commit --interactiveLibravatar Conrad Irwin1-8/+28
Change the behaviour of git commit --interactive so that when you abort the commit (by leaving the commit message empty) the index remains unchanged. Hitherto an aborted commit --interactive has added the selected hunks to the index regardless of whether the commit succeeded or not. Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-01Merge branch 'ab/i18n-st'Libravatar Junio C Hamano1-83/+83
* ab/i18n-st: (69 commits) i18n: git-shortlog basic messages i18n: git-revert split up "could not revert/apply" message i18n: git-revert literal "me" messages i18n: git-revert "Your local changes" message i18n: git-revert basic messages i18n: git-notes GIT_NOTES_REWRITE_MODE error message i18n: git-notes basic commands i18n: git-gc "Auto packing the repository" message i18n: git-gc basic messages i18n: git-describe basic messages i18n: git-clean clean.requireForce messages i18n: git-clean basic messages i18n: git-bundle basic messages i18n: git-archive basic messages i18n: git-status "renamed: " message i18n: git-status "Initial commit" message i18n: git-status "Changes to be committed" message i18n: git-status shortstatus messages i18n: git-status "nothing to commit" messages i18n: git-status basic messages ... Conflicts: builtin/branch.c builtin/checkout.c builtin/clone.c builtin/commit.c builtin/grep.c builtin/merge.c builtin/push.c builtin/revert.c t/t3507-cherry-pick-conflict.sh t/t7607-merge-overwrite.sh