- 31 3月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
When "-t template" and "-F msg" options are both given (or worse yet, there is "commit.template" configuration but a message is given in some other way), the documentation says that template is ignored. However, the "has the user edited the message?" check still used the contents of the template file as the basis of the emptyness check. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 1月, 2012 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 21 12月, 2011 1 次提交
-
-
由 Junio C Hamano 提交于
The earlier ed7a42a0 (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: NJunio C Hamano <gitster@pobox.com>
-
- 16 12月, 2011 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 12月, 2011 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 12月, 2011 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 07 12月, 2011 2 次提交
-
-
由 Thomas Rast 提交于
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: NThomas Rast <trast@student.ethz.ch> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Thomas Rast 提交于
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: NThomas Rast <trast@student.ethz.ch> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 12月, 2011 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
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: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 11月, 2011 1 次提交
-
-
由 Jonathan Nieder 提交于
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: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 11月, 2011 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 10 11月, 2011 2 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
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: 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>
-
- 13 9月, 2011 1 次提交
-
-
由 Clemens Buchacher 提交于
Also make common_prefix_len() static as this refactoring makes dir.c itself the only caller of this helper function. Signed-off-by: NClemens Buchacher <drizzd@aon.at> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 9月, 2011 1 次提交
-
-
由 Clemens Buchacher 提交于
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: NClemens Buchacher <drizzd@aon.at> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 8月, 2011 2 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 19 8月, 2011 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 8月, 2011 1 次提交
-
-
由 Clemens Buchacher 提交于
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: NClemens Buchacher <drizzd@aon.at> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 03 8月, 2011 1 次提交
-
-
由 Clemens Buchacher 提交于
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: NReuben Thomas <rrt@sc3d.org> Analyzed-by: NMichael J Gruber <git@drmicha.warpmail.net> Signed-off-by: NClemens Buchacher <drizzd@aon.at> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 5月, 2011 1 次提交
-
-
由 Boris Faure 提交于
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: NBoris Faure <billiob@gmail.com> Based-on-patch-by: NSebastian Schuberth <sschuberth@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 5月, 2011 2 次提交
-
-
由 Conrad Irwin 提交于
The --interactive flag is already shared by git add and git commit, share the -p and --patch flags too. Signed-off-by: NConrad Irwin <conrad.irwin@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Conrad Irwin 提交于
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: NConrad Irwin <conrad.irwin@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 5月, 2011 1 次提交
-
-
由 Conrad Irwin 提交于
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: NConrad Irwin <conrad.irwin@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 3月, 2011 1 次提交
-
-
由 Junio C Hamano 提交于
When we had to refresh the index internally before running diff or status, we opportunistically updated the $GIT_INDEX_FILE so that later invocation of git can use the lstat(2) we already did in this invocation. Make them share a helper function to do so. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 3月, 2011 6 次提交
-
-
由 Ævar Arnfjörð Bjarmason 提交于
Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
Gettextize the "# Please enter the commit message for your changes." message. Several tests in t7500-commit.sh and t7502-commit.sh assume that this message starts with a newline. Change the tests to to skip under GETTEXT_POISON=YesPlease. These fail under GETTEXT_POISON=YesPlease because the poison editor message doesn't do the right thing with comments and line breaks, so these messages will be incorrectly broken up across lines. This test should not be skipped under a hypothetical future testing mode that tests Git under language locales, since those messages should all start with a newline like the original. Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
Gettextize the "(root-commit)" and "detached HEAD" fragments that appear when you commit either the root commit, or a commit in a detached head translatable. Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
Gettextize the "You are in the middle of a merge -- cannot amend." message. Several tests in t7110-reset-merge.sh explicitly checked for this message. Change them to skip under GETTEXT_POISON=YesPlease. Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 3月, 2011 4 次提交
-
-
由 Jonathan Nieder 提交于
wt-status code is used to provide a reminder of changes included and not included for the commit message template opened in the operator's text editor by "git commit". Therefore each line of its output begins with the comment character "#": # Please enter the commit message for your changes. Lines starting Use the new status_printf{,_ln,_more} functions to take care of adding "#" to the beginning of such status lines automatically. Using these will have two advantages over the current code: - The obvious one is to force separation of the "#" from the translatable part of the message when git learns to translate its output. - Another advantage is that this makes it easier for us to drop "#" prefix in "git status" output in later versions of git if we want to. Explained-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
Instead of maintaining a local variable for it, use s->fp to keep track of where the commit message template should be written. This prepares us to take advantage of the status_printf functions, which use a struct wt_status instead of a FILE pointer to determine where to send their output. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
wt-status code is used to provide a reminder of changes included and not included for the commit message template opened in the operator's text editor by "git commit". Therefore each line of its output begins with the comment character "#": # Please enter the commit message for your changes. Lines starting Use the new status_printf{,_ln,_more} functions to take care of adding "#" to the beginning of such status lines automatically. Using these will have two advantages over the current code: - The obvious one is to force separation of the "#" from the translatable part of the message when git learns to translate its output. - Another advantage is that this makes it easier for us to drop "#" prefix in "git status" output in later versions of git if we want to. Explained-by: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonathan Nieder 提交于
Instead of maintaining a local variable for it, use s->fp to keep track of where the commit message template should be written. This prepares us to take advantage of the status_printf functions, which use a struct wt_status instead of a FILE pointer to determine where to send their output. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 2月, 2011 1 次提交
-
-
由 Jonathan Nieder 提交于
When "git commit" was rewritten in C (v1.5.4-rc0~78^2~30, 2007-11-08), a subtle bug in --template was introduced. If the file named by a --template parameter is missing, previously git would error out with a message: Commit template file does not exist. but in the C version the --template parameter gets ignored and the default template is used. t7500 has two tests for this case which would have caught it, except that with the default $EDITOR, the commit message template is left unmodified, causing 'git commit' to error out and the test to succeed. Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 2月, 2011 3 次提交
-
-
由 Jay Soffian 提交于
Previously the user was advised to use commit -c CHERRY_PICK_HEAD after a conflicting cherry-pick. While this would preserve the original commit's authorship, it would sadly discard cherry-pick's carefully crafted MERGE_MSG (which contains the list of conflicts as well as the original commit-id in the case of cherry-pick -x). On the other hand, if a bare 'commit' were performed, it would preserve the MERGE_MSG while resetting the authorship. In other words, there was no way to simultaneously take the authorship from CHERRY_PICK_HEAD and the commit message from MERGE_MSG. This change fixes that situation. A bare 'commit' will now take the authorship from CHERRY_PICK_HEAD and the commit message from MERGE_MSG. If the user wishes to reset authorship, that must now be done explicitly via --reset-author. A side-benefit of passing commit authorship along this way is that we can eliminate redundant authorship parsing code from revert.c. (Also removed an unused include from revert.c) Signed-off-by: NJay Soffian <jaysoffian@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jay Soffian 提交于
When a cherry-pick conflicts git advises: $ git commit -c <original commit id> to preserve the original commit message and authorship. Instead, let's record the original commit id in CHERRY_PICK_HEAD and advise: $ git commit -c CHERRY_PICK_HEAD A later patch teaches git to handle the '-c CHERRY_PICK_HEAD' part. Note that we record CHERRY_PICK_HEAD even in the case where there are no conflicts so that we may use it to communicate authorship to commit; this will then allow us to remove set_author_ident_env from revert.c. However, we do not record CHERRY_PICK_HEAD when --no-commit is used, as presumably the user intends to further edit the commit and possibly even cherry-pick additional commits on top. Tests and documentation contributed by Jonathan Nieder. Reviewed-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJay Soffian <jaysoffian@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
For its post-commit summary, commit was explicitly setting the default rename limit to 100. Presumably when the code was added, it was necessary to do so. These days, however, it will fall back properly to the diff default, and that default has long since changed from 100. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-