summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2007-02-07t4200: skip gc-rerere test on systems with non GNU date.Libravatar Junio C Hamano1-20/+17
Quite nonstandard "date -d @11111111 +%s" does not even fail on OpenBSD but gives the current date in "seconds since epoch" format, which is useless for the purpose of this test. We want to make sure that this returns exactly the same input before proceeding. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-07Merge branch 'master' of git://repo.or.cz/git/fastimportLibravatar Junio C Hamano1-0/+51
* 'master' of git://repo.or.cz/git/fastimport: Add a Tips and Tricks section to fast-import's manual. Don't crash fast-import if the marks cannot be exported. Dump all refs and marks during a checkpoint in fast-import. Teach fast-import how to sit quietly in the corner. Teach fast-import how to clear the internal branch content. Minor timestamp related documentation corrections for fast-import.
2007-02-07Avoid ActiveState Perl IO in t800[12]Libravatar Alex Riesen1-1/+2
Use sed instead, it comes with cygwin and there is almost no chance of someone installing a sed with default CRLF lineendings by accident. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-07Teach fast-import how to clear the internal branch content.Libravatar Shawn O. Pearce1-0/+51
Some frontends may not be able to (easily) keep track of which files are included in the branch, and which aren't. Performing this tracking can be tedious and error prone for the frontend to do, especially if its foreign data source cannot supply the changed path list on a per-commit basis. fast-import now allows a frontend to request that a branch's tree be wiped clean (reset to the empty tree) at the start of a commit, allowing the frontend to feed in all paths which belong on the branch. This is ideal for a tar-file importer frontend, for example, as the frontend just needs to reformat the tar data stream into a gfi data stream, which may be something a few Perl regexps can take care of. :) Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-06Merge branch 'master' of git://repo.or.cz/git/fastimportLibravatar Junio C Hamano1-0/+359
* 'master' of git://repo.or.cz/git/fastimport: (81 commits) S_IFLNK != 0140000 Don't do non-fastforward updates in fast-import. Support RFC 2822 date parsing in fast-import. Minor fast-import documentation corrections. Remove unnecessary null pointer checks in fast-import. Correct fast-import timezone documentation. Correct minor style issue in fast-import. Correct compiler warnings in fast-import. Remove --branch-log from fast-import. Initial draft of fast-import documentation. Don't support shell-quoted refnames in fast-import. Reduce memory usage of fast-import. Include checkpoint command in the BNF. Accept 'inline' file data in fast-import commit structure. Reduce value duplication in t9300-fast-import. Create test case for fast-import. Support delimited data regions in fast-import. Remove unnecessary options from fast-import. Use fixed-size integers when writing out the index in fast-import. Always use struct pack_header for pack header in fast-import. ...
2007-02-06Don't do non-fastforward updates in fast-import.Libravatar Shawn O. Pearce1-0/+80
If fast-import is being used to update an existing branch of a repository, the user may not want to lose commits if another process updates the same ref at the same time. For example, the user might be using fast-import to make just one or two commits against a live branch. We now perform a fast-forward check during the ref updating process. If updating a branch would cause commits in that branch to be lost, we skip over it and display the new SHA1 to standard error. This new default behavior can be overridden with `--force`, like git-push and git-fetch. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-06Support RFC 2822 date parsing in fast-import.Libravatar Shawn O. Pearce1-0/+36
Since some frontends may be working with source material where the dates are only readily available as RFC 2822 strings, it is more friendly if fast-import exposes Git's parse_date() function to handle the conversion. This way the frontend doesn't need to perform the parsing itself. The new --date-format option to fast-import can be used by a frontend to select which format it will supply date strings in. The default is the standard `raw` Git format, which fast-import has always supported. Format rfc2822 can be used to activate the parse_date() function instead. Because fast-import could also be useful for creating new, current commits, the format `now` is also supported to generate the current system timestamp. The implementation of `now` is a trivial call to datestamp(), but is actually a whole whopping 3 lines so that fast-import can verify the frontend really meant `now`. As part of this change I have added validation of the `raw` date format. Prior to this change fast-import would accept anything in a `committer` command, even if it was seriously malformed. Now fast-import requires the '> ' near the end of the string and verifies the timestamp is formatted properly. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-02-05t9200: Work around HFS+ issues.Libravatar Junio C Hamano1-0/+14
We at least know that the test as written has a problem in an environment where "touch '$p'; ls | fgrep '$p'" fails, and have a clear understand why it fails. This tests if the filesystem has that particular issue we know "git add" has a problem with, and skips the test in such an environment. This way, we might catch issues "git add" might have in other environments. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-04git-clone --reference: saner handling of borrowed symrefs.Libravatar Junio C Hamano1-1/+39
When using --reference to borrow objects from a neighbouring repository while cloning, we copy the entire set of refs under temporary "refs/reference-tmp/refs" space and set up the object alternates. However, a textual symref copied this way would not point at the right place, and causes later steps to emit error messages (which is harmless but still alarming). This is most visible when using a clone created with the separate-remote layout as a reference, because such a repository would have refs/remotes/origin/HEAD with 'ref: refs/remotes/origin/master' as its contents. Although we do not create symbolic-link based refs anymore, they have the same problem because they are always supposed to be relative to refs/ hierarchy (we dereference by hand, so it only is good for HEAD and nothing else). In either case, the solution is simply to remove them after copying under refs/reference-tmp; if a symref points at a true ref, that true ref itself is enough to ensure that objects reachable from it do not needlessly get fetched. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-03Default GIT_MERGE_VERBOSITY to 5 during tests.Libravatar Shawn O. Pearce1-0/+2
Its really nice to be able to run a test with -v and automatically see the "debugging" dump from merge-recursive, especially if we are actually trying to debug merge-recursive. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-03Keep untracked files not involved in a merge.Libravatar Shawn O. Pearce1-0/+42
My earlier fix (8371234e) to delete renamed tracked files from the working directory also caused merge-recursive to delete untracked files that were in the working directory. The problem here is merge-recursive is deleting the working directory file without regard for which branch it was associated with. What we really want to do during a merge is to only delete files that were renamed by the branch we are merging into the current branch, and that are still tracked by the current branch. These files definitely don't belong in the working directory anymore. Anything else is either a merge conflict (already handled in other parts of the code) or a file that is untracked by the current branch and thus is not even participating in the merge. Its this latter class that must be left alone. For this fix to work we are now assuming that the first non-base argument passed to git-merge-recursive always corresponds to the working directory. This is already true for all in-tree callers of merge-recursive. This assumption is also supported by the long time usage message of "<base> ... -- <head> <remote>", where "<head>" is implied to be HEAD, which is generally assumed to be the current tree-ish. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-03Assorted typo fixesLibravatar Pavel Roskin6-9/+9
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-31t9200: do not test -x bit if the filesystem does not support it.Libravatar Junio C Hamano1-0/+6
The last test in t9200 wants to see if executable bit is retained, which has no chance of succeeding on a filesystem that does not handle executable bit correctly. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-31t9200: Re-code non-ascii path test in UTF-8Libravatar Junio C Hamano1-8/+8
For the purpose of this test we do not really care if the paths are in latin-1, but people on Cygwin seem to be having problem on foreign-looking pathnames that do not play well with their locale. Let's try to re-code them in UTF-8 and see who screams, thanks, or reports no-improvements. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-30Merge branch 'master' into sp/gfiLibravatar Shawn O. Pearce38-124/+676
git-fast-import requires use of inttypes.h, but the master branch has added it to git-compat-util differently than git-fast-import originally had used it. This merge back of master to the fast-import topic is to get (and use) inttypes.h the way master is using it. This is a partially evil merge to remove the call to setup_ident(), as the master branch now contains a change which makes this implicit and therefore removed the function declaration. (commit 01754769). Conflicts: git-compat-util.h
2007-01-28git-fsck-objects is now synonym to git-fsckLibravatar Junio C Hamano3-5/+5
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28[PATCH] Rename git-repo-config to git-config.Libravatar Tom Prince16-122/+122
Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-25Fix seriously broken "git pack-refs"Libravatar Linus Torvalds1-0/+9
Do *NOT* try this on a repository you care about: git pack-refs --all --prune git pack-refs because while the first "pack-refs" does the right thing, the second pack-refs will totally screw you over. This is because the second one tries to pack only tags; we should also pack what are already packed -- otherwise we would lose them. [jc: with an additional test] Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-24Consolidate {receive,fetch}.unpackLimitLibravatar Junio C Hamano1-1/+1
This allows transfer.unpackLimit to specify what these two configuration variables want to set. We would probably want to deprecate the two separate variables, as I do not see much point in specifying them independently. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-24fetch-pack: remove --keep-auto and make it the default.Libravatar Junio C Hamano1-1/+2
This makes git-fetch over git native protocol to automatically decide to keep the downloaded pack if the fetch results in more than 100 objects, just like receive-pack invoked by git-push does. This logic is disabled when --keep is explicitly given from the command line, so that a very small clone still keeps the downloaded pack as before. The 100 threshold can be adjusted with fetch.unpacklimit configuration. We might want to introduce transfer.unpacklimit to consolidate the two unpacklimit variables, which will be a topic for the next patch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-23t/t1300-repo-config.sh: value continued on next lineLibravatar Jakub Narebski1-0/+20
Documentation/config.txt: Variable value ending in a '`\`' is continued on the next line in the customary UNIX fashion. Test it. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-23git-checkout -m: fix merge caseLibravatar Junio C Hamano1-1/+27
Commit c1a4278e switched the "merging checkout" implementation from 3-way read-tree to merge-recursive, but forgot that merge-recursive will signal an unmerged state with its own exit status code. This prevented the clean-up phase (paths cleanly merged should not be updated in the index) from running. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-21Revert "prune: --grace=time"Libravatar Junio C Hamano4-10/+10
This reverts commit 9b088c4e394df84232cfd37aea78349a495b09c1. Protecting 'mature' objects does not make it any safer. We should admit that git-prune is inherently unsafe when run in parallel with other operations without involving unwarranted locking overhead, and with the latest git, even rebase and reset would not immediately create crufts anyway.
2007-01-20prune: --grace=timeLibravatar Matthias Lederhofer4-10/+10
This option gives grace period to objects that are unreachable from the refs from getting pruned. The default value is 24 hours and may be changed using gc.prunegrace. Signed-off-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-20Do not verify filenames in a bare repositoryLibravatar Johannes Schindelin1-0/+29
For example, it makes no sense to check the presence of a file named "HEAD" when calling "git log HEAD" in a bare repository. Noticed by Han-Wen Nienhuys. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
2007-01-19Extend read_ref_at() to be usable from places other than sha1_name.Libravatar Junio C Hamano1-3/+3
You can pass an extra argument to the function to receive the reflog message information. Also when the log does not go back beyond the point the user asked, the cut-off time and count are given back to the caller for emitting the error messages as appropriately. We could later add configuration for get_sha1_basic() to make it an error instead of it being just a warning. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19config_set_multivar(): disallow newlines in keysLibravatar Johannes Schindelin1-0/+6
This will no longer work: $ git repo-config 'key.with newline' some-value Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
2007-01-18Use standard -t option for touch.Libravatar Simon 'corecode' Schubert1-12/+12
Non-GNU touch do not have the -d option to take free form date strings. The POSIX -t option should be more widespread. For this to work, date needs to output YYYYMMDDHHMM.SS date strings. Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-18Accept 'inline' file data in fast-import commit structure.Libravatar Shawn O. Pearce1-0/+59
Its very annoying to need to specify the file content ahead of a commit and use marks to connect the individual blobs to the commit's file modification entry, especially if the frontend can't/won't generate the blob SHA1s itself. Instead it would much easier to use if we can accept the blob data at the same time as we receive each file_change line. Now fast-import accepts 'inline' instead of a mark idnum or blob SHA1 within the 'M' type file_change command. If an inline is detected the very next line must be a 'data n' command, supplying the file data. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-18Reduce value duplication in t9300-fast-import.Libravatar Shawn O. Pearce1-17/+17
It is error prone to list the value of each file twice, instead we should list the value only once early in the script and reuse the shell variable when we need to access it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-18Create test case for fast-import.Libravatar Shawn O. Pearce1-0/+184
Now that its easier to craft test cases (thanks to 'data <<') we should start to verify fast-import works as expected. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-17Add --summary to git-format-patch by defaultLibravatar Junio C Hamano6-0/+12
This adds --summary output in addition to the --stat to the output from git-format-patch by default. I think additions, removals and filemode changes are rare but notable events and always showing it makes sense. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-16Use merge-recursive in git-checkout -m (branch switching)Libravatar Junio C Hamano1-8/+33
This allows "git checkout -m <other-branch>" to notice renames and carry local changes in the working tree forward. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-15Replace "echo -n" with printf in shell scripts.Libravatar Jason Riedy3-4/+4
Not all echos know -n. This was causing a test failure in t5401-update-hooks.sh, but not t3800-mktag.sh for some reason. Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-15Start all test scripts with /bin/sh.Libravatar Jason Riedy3-1/+3
My bash refused to run the two scripts missing a #!, and it's better to use the same line for all the scripts. Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14Use merge-recursive in git-revert/git-cherry-pickLibravatar Junio C Hamano1-0/+62
This makes revert and cherry-pick to use merge-recursive, to allow them to notice renames. A pair of test scripts demonstrate that an old change before a rename happened can be applied (reverted) after a rename with cherry-pick (with revert). Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14Add describe test.Libravatar Junio C Hamano1-0/+97
... with help from Shawn. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14Merge branch 'jc/int'Libravatar Junio C Hamano3-0/+263
* jc/int: More tests in t3901. Consistent message encoding while reusing log from an existing commit. t3901: test "format-patch | am" pipe with i18n Use log output encoding in --pretty=email headers.
2007-01-14Hide output about SVN::Core not being found during tests.Libravatar Shawn O. Pearce1-1/+1
If the user doesn't have SVN::Core installed or working then the SVN tests properly turn themselves off. But the user doesn't need to know that SVN::Core isn't loadable as a Perl module. Unless of course they are trying to debug the test, so lets relegate the Perl failures to --verbose only. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-13More tests in t3901.Libravatar Junio C Hamano1-36/+137
This adds tests for "cherry-pick" and "rebase --merge" (and indirectly "commit -C" since it is used in the latter) to make sure they create a new commit with correct encoding. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-13t3901: test "format-patch | am" pipe with i18nLibravatar Junio C Hamano3-0/+162
This checks combinations of i18n.commitencoding (declares what encoding you are feeding commit-tree to make commits) and i18n.logoutputencoding (instructs what encoding to emit the commit message out to log output, including e-mail format) to make sure the "format-patch | am" pipe used in git-rebase works correctly. I suspect "git cherry-pick" and "git rebase --merge" may fail similar tests. We'll see. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-13git-svn: fix tests to work with older svnLibravatar Eric Wong2-2/+4
Some of the recent changes and shortcuts to the tests broke things for people using older versions of svn: t9104-git-svn-follow-parent.sh: v1.2.3 (from SuSE 10.0 as reported by riddochc on #git (thanks!)) required an extra 'svn up'. I was also able to reproduce this with v1.1.4 (Debian Sarge). lib-git-svn.sh: SVN::Repos bindings in versions up to and including 1.1.4 (Sarge again) do not pass fs-config options to the underlying library. BerkeleyDB repositories also seem completely broken on all my Sarge machines; so not using FSFS does not seem to be an option for most people. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-12use 'init' instead of 'init-db' for shipped docs and toolsLibravatar Nicolas Pitre9-15/+15
While 'init-db' still is and probably will always remain a valid git command for obvious backward compatibility reasons, it would be a good idea to move shipped tools and docs to using 'init' instead. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-11Merge branch 'jc/detached-head'Libravatar Junio C Hamano1-1/+1
* jc/detached-head: git-checkout: handle local changes sanely when detaching HEAD git-checkout: safety check for detached HEAD checks existing refs git-checkout: fix branch name output from the command git-checkout: safety when coming back from the detached HEAD state. git-checkout: rewording comments regarding detached HEAD. git-checkout: do not warn detaching HEAD when it is already detached. Detached HEAD (experimental) git-branch: show detached HEAD git-status: show detached HEAD
2007-01-10Fix t1410 for core.filemode==falseLibravatar Johannes Schindelin1-0/+2
Since c869753e, core.filemode is hardwired to false on Cygwin. So this test had no chance to succeed, since an early commit (changing just the filemode) failed, and therefore all subsequent tests. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-08Auto-quote config values in config.c:store_write_pair()Libravatar Brian Gernhardt1-0/+17
Suggested by Jakub Narebski <jnareb@gmail.com> on the list. When we send a value to store_write_pair(), make sure that the value that gets read out matches the one passed in. This means that for any value that contains leading or trailing whitespace or any comment character (# and ;), we need to surround it in quotes. Signed-off-by: Brian Gernhardt <benji@silverinsanity.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-08Merge branch 'jc/reflog'Libravatar Junio C Hamano1-0/+176
* jc/reflog: reflog --fix-stale: do not check the same trees and commits repeatedly. reflog expire --fix-stale Move traversal of reachable objects into a separate library. builtin-prune: separate ref walking from reflog walking. builtin-prune: make file-scope static struct to an argument.
2007-01-08--prune is now default for 'pack-refs'Libravatar Junio C Hamano1-1/+1
There is no reason not to, really. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-08git-checkout: fix branch name output from the commandLibravatar Junio C Hamano1-1/+1
When switching branches with "git checkout", we internally did $arg^0 (aka $arg^{commit}) suffix but there was no need to. The improvement is easily visible in the change to an existing test t/3200-branch.sh in this commit; it was expecting rather ugly message. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-07Merge branch 'sp/mmap'Libravatar Junio C Hamano1-0/+60
* sp/mmap: (27 commits) Spell default packedgitlimit slightly differently Increase packedGit{Limit,WindowSize} on 64 bit systems. Update packedGit config option documentation. mmap: set FD_CLOEXEC for file descriptors we keep open for mmap() pack-objects: fix use of use_pack(). Fix random segfaults in pack-objects. Cleanup read_cache_from error handling. Replace mmap with xmmap, better handling MAP_FAILED. Release pack windows before reporting out of memory. Default core.packdGitWindowSize to 1 MiB if NO_MMAP. Test suite for sliding window mmap implementation. Create pack_report() as a debugging aid. Support unmapping windows on 'temporary' packfiles. Improve error message when packfile mmap fails. Ensure core.packedGitWindowSize cannot be less than 2 pages. Load core configuration in git-verify-pack. Fully activate the sliding window pack access. Unmap individual windows rather than entire files. Document why header parsing won't exceed a window. Loop over pack_windows when inflating/accessing data. ... Conflicts: cache.h pack-check.c