summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2010-01-10rerere forget path: forget recorded resolutionLibravatar Junio C Hamano1-0/+25
After you find out an earlier resolution you told rerere to use was a mismerge, there is no easy way to clear it. A new subcommand "forget" can be used to tell git to forget a recorded resolution, so that you can redo the merge from scratch. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-25resolve-undo: teach "update-index --unresolve" to use resolve-undo infoLibravatar Junio C Hamano1-0/+7
The update-index plumbing command had a hacky --unresolve implementation that was written back in the days when merge was the only way for users to end up with higher stages in the index, and assumed that stage #2 must have come from HEAD, stage #3 from MERGE_HEAD and didn't bother to compute the stage #1 information. There were several issues with this approach: - These days, merge is not the only command, and conflicts coming from commands like cherry-pick, "am -3", etc. cannot be recreated by looking at MERGE_HEAD; - For a conflict that came from a merge that had renames, picking up the same path from MERGE_HEAD and HEAD wouldn't help recreating it, either; - It may have been Ok not to recreate stage #1 back when it was written, because "diff --ours/--theirs" were the only availble ways to review conflicts and they don't need stage #1 information. "diff --cc" that was invented much later is a lot more useful way but it needs stage #1. We can use resolve-undo information recorded in the index extension to solve all of these issues. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-25resolve-undo: "checkout -m path" uses resolve-undo informationLibravatar Junio C Hamano1-0/+11
Once you resolved conflicts by "git add path", you cannot recreate the conflicted state with "git checkout -m path", because you lost information from higher stages in the index when you resolved them. Since we record the necessary information in the resolve-undo index extension these days, we can reproduce the unmerged state in the index and check it out. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-25resolve-undo: allow plumbing to clear the informationLibravatar Junio C Hamano1-0/+12
At the Porcelain level, operations such as merge that populate an initially cleanly merged index with conflicted entries clear the resolve-undo information upfront. Give scripted Porcelains a way to do the same, by implementing "update-index --clear-resolve-info". With this, a scripted Porcelain may "update-index --clear-resolve-info" first and repeatedly run "update-index --cacheinfo" to stuff unmerged entries to the index, to be resolved by the user with "git add" and stuff. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-25resolve-undo: basic testsLibravatar Junio C Hamano1-0/+88
Make sure that resolving a failed merge with git add records the conflicted state, committing the result keeps that state, and checking out another commit clears the state. "git ls-files" learns a new option --resolve-undo to show the recorded information. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-23git svn: add test for a git svn gc followed by a git svn mkdirsLibravatar Robert Zeh1-0/+40
git svn gc will compress the unhandled.log files that git svn mkdirs reads, causing git svn mkdirs to skip directory creation. [ew: trivial whitespace cleanups] Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Robert Zeh <robert.a.zeh@gmail.com>
2009-12-22Merge branch 'maint'Libravatar Junio C Hamano1-0/+13
* maint: Prevent git blame from segfaulting on a missing author name
2009-12-22Prevent git blame from segfaulting on a missing author nameLibravatar David Reiss1-0/+13
The human-readable author and committer name can be missing from commits imported from foreign SCM interfaces. Make sure we parse the "author" and "committer" line a bit more leniently and avoid segfaulting by assuming the name always exists. Signed-off-by: David Reiss <dreiss@facebook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-21git-svn: detect cherry-picks correctly.Libravatar Sam Vilain1-2/+2
The old function was incorrect; in some instances it marks a cherry picked range as a merged branch (because of an incorrect assumption that 'rev-list COMMIT --not RANGE' would work). This is replaced with a function which should detect them correctly, memoized to limit the expense of dealing with branches with many cherry picks to one 'merge-base' call per merge, per branch which used cherry picking. Signed-off-by: Sam Vilain <sam@vilain.net> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-12-21git-svn: fix some mistakes with interpreting SVN mergeinfo commit rangesLibravatar Sam Vilain1-1/+1
SVN's list of commit ranges in mergeinfo tickets is inclusive, whereas git commit ranges are exclusive on the left hand side. Also, the end points of the commit ranges may not exist; they simply delineate ranges of commits which may or may not exist. Fix these two mistakes. Signed-off-by: Sam Vilain <sam@vilain.net> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-12-21git-svn: expand the svn mergeinfo test suite, highlighting some failuresLibravatar Sam Vilain3-172/+860
As shown, git-svn has some problems; not all svn merges are correctly detected, and cherry picks may incorrectly be detected as real merges. These test cases will be marked as _success once the relevant fixes are in. Signed-off-by: Sam Vilain <sam@vilain.net> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-12-19t9146: use 'svn_cmd' wrapperLibravatar Eric Wong1-1/+1
Using 'svn' directly may not work for all users. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2009-12-19git svn: make empty directory creation gc-awareLibravatar Eric Wong1-0/+24
The "git svn gc" command creates and appends to unhandled.log.gz files which should be parsed before the uncompressed unhandled.log files. Reported-by: Robert Zeh Signed-off-by: Eric Wong <normalperson@yhbt.net>
2009-12-16Merge branch 'maint' to sync with 1.6.5.7Libravatar Junio C Hamano2-0/+32
* maint: Git 1.6.5.7 worktree: don't segfault with an absolute pathspec without a work tree ignore unknown color configuration help.autocorrect: do not run a command if the command given is junk Illustrate "filter" attribute with an example
2009-12-16worktree: don't segfault with an absolute pathspec without a work treeLibravatar Junio C Hamano1-0/+15
If a command is run with an absolute path as a pathspec inside a bare repository, e.g. "rev-list HEAD -- /home", the code tried to run strlen() on NULL, which is the result of get_git_work_tree(), and segfaulted. It should just fail instead. Currently the function returns NULL even inside .git/ in a repository with a work tree, but that is a separate issue. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-16ignore unknown color configurationLibravatar Jeff King1-0/+17
When parsing the config file, if there is a value that is syntactically correct but unused, we generally ignore it. This lets non-core porcelains store arbitrary information in the config file, and it means that configuration files can be shared between new and old versions of git (the old versions might simply ignore certain configuration). The one exception to this is color configuration; if we encounter a color.{diff,branch,status}.$slot variable, we die if it is not one of the recognized slots (presumably as a safety valve for user misconfiguration). This behavior has existed since 801235c (diff --color: use $GIT_DIR/config, 2006-06-24), but hasn't yet caused a problem. No porcelain has wanted to store extra colors, and we once a color area (like color.diff) has been introduced, we've never changed the set of color slots. However, that changed recently with the addition of color.diff.func. Now a user with color.diff.func in their config can no longer freely switch between v1.6.6 and older versions; the old versions will complain about the existence of the variable. This patch loosens the check to match the rest of git-config; unknown color slots are simply ignored. This doesn't fix this particular problem, as the older version (without this patch) is the problem, but it at least prevents it from happening again in the future. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-10Sync with 1.6.5.6Libravatar Junio C Hamano1-69/+0
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-10Remove post-upload-hookLibravatar Junio C Hamano1-69/+0
This hook runs after "git fetch" in the repository the objects are fetched from as the user who fetched, and has security implications. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-08Merge branch 'maint'Libravatar Junio C Hamano1-0/+20
* maint: add-interactive: fix deletion of non-empty files pull: clarify advice for the unconfigured error case
2009-12-08Merge branch 'jk/maint-add-p-delete-fix' into maintLibravatar Junio C Hamano1-0/+20
* jk/maint-add-p-delete-fix: add-interactive: fix deletion of non-empty files
2009-12-07add-interactive: fix deletion of non-empty filesLibravatar Jeff King1-0/+20
Commit 24ab81a fixed the deletion of empty files, but broke deletion of non-empty files. The approach it took was to factor out the "deleted" line from the patch header into its own hunk, the same way we do for mode changes. However, unlike mode changes, we only showed the special "delete this file" hunk if there were no other hunks. Otherwise, the user would annoyingly be presented with _two_ hunks: one for deleting the file and one for deleting the content. This meant that in the non-empty case, we forgot about the deleted line entirely, and we submitted a bogus patch to git-apply (with "/dev/null" as the destination file, but not marked as a deletion). Instead, this patch combines the file deletion hunk and the content deletion hunk (if there is one) into a single deletion hunk which is either staged or not. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-07git svn: log removals of empty directoriesLibravatar Eric Wong1-0/+10
This also adds a test case for: "git svn: Don't create empty directories whose parents were deleted" which was the reason we found this bug in the first place. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2009-12-05Sync with 1.6.5.5Libravatar Junio C Hamano1-3/+29
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-05reset: improve worktree safety valvesLibravatar Jeff King1-3/+29
The existing code checked to make sure we were not in a bare repository when doing a hard reset. However, we should take this one step further, and make sure we are in a worktree. Otherwise, we can end up munging files inside of '.git'. Furthermore, we should do the same check for --merge resets, which have the same properties. Actually, a merge reset of HEAD^ would already complain, since further down in the code we want a worktree. However, it is nicer to check up-front; then we are sure we cover all cases ("git reset --merge" would run, even though it wasn't doing anything) and we can give a more specific message. Add tests to t7103 to cover these cases and some missing ones. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-03Merge branch 'maint'Libravatar Junio C Hamano1-2/+2
* maint: Prepare for 1.6.5.5 Documentation: xmlto 0.0.18 does not know --stringparam t4201: use ISO8859-1 rather than ISO-8859-1
2009-12-03Merge branch 'uk/maint-shortlog-encoding' into maintLibravatar Junio C Hamano1-0/+28
* uk/maint-shortlog-encoding: t4201: use ISO8859-1 rather than ISO-8859-1 shortlog: respect commit encoding
2009-12-03Merge branch 'fc/maint-format-patch-pathspec-dashes' into maintLibravatar Junio C Hamano1-0/+5
* fc/maint-format-patch-pathspec-dashes: format-patch: add test for parsing of "--" format-patch: fix parsing of "--" on the command line
2009-12-03Merge branch 'rj/maint-t9700' into maintLibravatar Junio C Hamano1-1/+1
* rj/maint-t9700: t9700-perl-git.sh: Fix a test failure on Cygwin
2009-12-03Merge branch 'ls/maint-mailinfo-no-inbody' into maintLibravatar Junio C Hamano14-1/+101
* ls/maint-mailinfo-no-inbody: git am/mailinfo: Don't look at in-body headers when rebasing
2009-12-03Merge branch 'pb/maint-use-custom-perl' into maintLibravatar Junio C Hamano3-4/+4
* pb/maint-use-custom-perl: Make sure $PERL_PATH is defined when the test suite is run.
2009-12-03Merge branch 'bc/grep-i-F' into maintLibravatar Junio C Hamano1-0/+10
* bc/grep-i-F: grep: Allow case insensitive search of fixed-strings
2009-12-03Fix crasher on encountering SHA1-like non-note in notes treeLibravatar Johan Herland1-0/+172
When loading a notes tree, the code primarily looks for SHA1-like paths whose total length (discounting directory separators) are 40 chars (interpreted as valid note entries) or less (interpreted as subtree entries that may in turn contain note entries when unpacked). However, there is an additional condition that must hold for valid subtree entries: They must be _tree_ objects (duh). This patch adds an appropriate test for this condition, thereby fixing the crash that occured when passing a non-tree object to the tree-walk API. The patch also adds another selftest verifying correct behaviour of non-notes in note trees. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-03t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'Libravatar Brandon Casey1-1/+1
The '--no-chain-reply-to' option is a Getopt::Long boolean option. The '--no-' prefix (as in --no-chain-reply-to) for boolean options is not supported in Getopt::Long version 2.32 which was released with Perl 5.8.0. This version only supports '--no' as in '--nochain-reply-to'. More recent versions of Getopt::Long, such as version 2.34, support either prefix. So use the older form in the tests. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-03t4201: use ISO8859-1 rather than ISO-8859-1Libravatar Brandon Casey1-2/+2
Some ancient platforms do not have an extensive list of alternate names for character encodings. For example, Solaris 7 and IRIX 6.5 do not know that ISO-8859-1 is the same as ISO8859-1. Modern platforms do know this, so use the older name. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-02Merge branch 'maint'Libravatar Junio C Hamano1-5/+2
* maint: Prepare for 1.6.5.4 merge: do not add standard message when message is given with -m option Do not misidentify "git merge foo HEAD" as an old-style invocation Conflicts: RelNotes
2009-12-02merge: do not add standard message when message is given with -m optionLibravatar Junio C Hamano1-5/+2
Even if the user explicitly gave her own message to "git merge", the command still added its standard merge message. It resulted in a useless repetition like this: % git merge -m "Merge early part of side branch" `git rev-parse side~2` % git show -s commit 37217141e7519629353738d5e4e677a15096206f Merge: e68e646 a1d2374 Author: しらいし ななこ <nanako3@lavabit.com> Date: Wed Dec 2 14:33:20 2009 +0900 Merge early part of side branch Merge commit 'a1d2374f8f52f4e8a53171601a920b538a6cec23' The gave her own message because she didn't want git to add the standard message (if she wanted to, she wouldn't have given one, or she would have prepared it using git-fmt-merge-msg command). Noticed by Nanako Shiraishi Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-30Merge branch 'fc/maint-format-patch-pathspec-dashes'Libravatar Junio C Hamano1-0/+5
Conflicts: t/t4014-format-patch.sh
2009-11-30Merge branch 'jc/pretty-lf'Libravatar Junio C Hamano1-0/+22
Conflicts: pretty.c t/t6006-rev-list-format.sh
2009-11-30Merge branch 'em/commit-claim'Libravatar Junio C Hamano1-0/+114
2009-11-30Merge branch 'fc/send-email-envelope'Libravatar Junio C Hamano1-0/+34
2009-11-30Merge branch 'uk/maint-shortlog-encoding'Libravatar Junio C Hamano1-0/+28
Conflicts: builtin-shortlog.c
2009-11-30Merge branch 'ns/send-email-no-chain-reply-to'Libravatar Junio C Hamano1-0/+49
2009-11-30Merge branch 'bw/diff-color-hunk-header'Libravatar Junio C Hamano1-5/+7
2009-11-29t/README: Document GIT_TEST_INSTALLED and GIT_TEST_EXEC_PATHLibravatar Matthew Ogilvie1-0/+13
These were added without documentation in 2009-03-16 (6720721). Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-29t3409 t4107 t7406 t9150: use dashless commandsLibravatar Matthew Ogilvie4-16/+16
This is needed to allow test suite to run against a standard install bin directory instead of GIT_EXEC_PATH. Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-29t2300: use documented technique to invoke git-sh-setupLibravatar Matthew Ogilvie1-1/+1
This is needed to allow the test suite to run against a standard install bin directory instead of GIT_EXEC_PATH. Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-29prepare send-email for smoother change of --chain-reply-to defaultLibravatar Nanako Shiraishi1-0/+49
Give a warning message when send-email uses chain-reply-to to thread the messages because of the current default, not because the user explicitly asked to, either from the command line or from the configuration. This way, by the time 1.7.0 switches the default, everybody will be ready. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-28Give the hunk comment its own colorLibravatar Bert Wesarg1-1/+3
Inspired by the coloring of quilt. Introduce a separate color and paint the hunk comment part, i.e. the name of the function, in a separate color "diff.func" (defaults to plain). Whitespace between hunk header and hunk comment is printed in plain color. Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-27send-email: automatic envelope senderLibravatar Felipe Contreras1-0/+17
This adds the option to specify the envelope sender as "auto" which would pick the 'from' address. This is good because now we can specify the address only in one place in $HOME/.gitconfig and change it easily. [jc: added tests] Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-27emit_line(): don't emit an empty <SET><RESET> followed by a newlineLibravatar Junio C Hamano1-4/+4
When emit_line() is called with an empty line (but non-zero length, as we send line terminating LF or CRLF to the function), it used to emit <SET><RESET> followed by a newline. Stop the wastefulness. Signed-off-by: Junio C Hamano <gitster@pobox.com>