aboutsummaryrefslogtreecommitdiff
path: root/t
Commit message (Collapse)AuthorAge
* Add core.symlinks to mark filesystems that do not support symbolic links.Johannes Sixt2007-03-02
| | | | | | | | | | | | | | | | | | | | | Some file systems that can host git repositories and their working copies do not support symbolic links. But then if the repository contains a symbolic link, it is impossible to check out the working copy. This patch enables partial support of symbolic links so that it is possible to check out a working copy on such a file system. A new flag core.symlinks (which is true by default) can be set to false to indicate that the filesystem does not support symbolic links. In this case, symbolic links that exist in the trees are checked out as small plain files, and checking in modifications of these files preserve the symlink property in the database (as long as an entry exists in the index). Of course, this does not magically make symbolic links work on such defective file systems; hence, this solution does not help if the working copy relies on that an entry is a real symbolic link. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge branch 'js/bundle'Junio C Hamano2007-02-28
|\ | | | | | | | | | | | | | | | | | | * js/bundle: bundle: reword missing prerequisite error message git-bundle: record commit summary in the prerequisite data git-bundle: fix 'create --all' git-bundle: avoid fork() in verify_bundle() git-bundle: assorted fixes Add git-bundle: move objects and references by archive
| * Add git-bundle: move objects and references by archiveJohannes Schindelin2007-02-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some workflows require use of repositories on machines that cannot be connected, preventing use of git-fetch / git-push to transport objects and references between the repositories. git-bundle provides an alternate transport mechanism, effectively allowing git-fetch and git-pull to operate using sneakernet transport. `git-bundle create` allows the user to create a bundle containing one or more branches or tags, but with specified basis assumed to exist on the target repository. At the receiving end, git-bundle acts like git-fetch-pack, allowing the user to invoke git-fetch or git-pull using the bundle file as the URL. git-fetch and git-ls-remote determine they have a bundle URL by checking that the URL points to a file, but are otherwise unchanged in operation with bundles. The original patch was done by Mark Levedahl <mdl123@verizon.net>. It was updated to make git-bundle a builtin, and get rid of the tar format: now, the first line is supposed to say "# v2 git bundle", the next lines either contain a prerequisite ("-" followed by the hash of the needed commit), or a ref (the hash of a commit, followed by the name of the ref), and finally the pack. As a result, the bundle argument can be "-" now. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Merge branch 'maint'Junio C Hamano2007-02-27
|\ \ | | | | | | | | | | | | | | | | | | * maint: git-apply: do not fix whitespaces on context lines. diff --cc: integer overflow given a 2GB-or-larger file mailinfo: do not get confused with logical lines that are too long.
| * | mailinfo: do not get confused with logical lines that are too long.Linus Torvalds2007-02-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It basically considers all the continuation lines to be lines of their own, and if the total line is bigger than what we can fit in it, we just truncate the result rather than stop in the middle and then get confused when we try to parse the "next" line (which is just the remainder of the first line). [jc: added test, and tightened boundary a bit per list discussion.] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | Update tests to use test-chmtimeEric Wong2007-02-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | test-lib: Make sure test-chmtime has been built before starting. t4200-rerere: Removed non-portable date dependency and avoid touch Avoid "test -a" which isn't portable, either lib-git-svn: Use test-chmtime instead of Perl one-liner to poke Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | Merge branch 'js/etc-config'Junio C Hamano2007-02-24
|\ \ \ | | | | | | | | | | | | | | | | | | | | * js/etc-config: Make tests independent of global config files config: read system-wide defaults from /etc/gitconfig
| * | | Make tests independent of global config filesJohannes Schindelin2007-02-22
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was done by setting $HOME to somewhere bogus. A better method is to reuse $GIT_CONFIG, which was invented for ignoring the global config file explicitely. Technically, setting GIT_CONFIG=.git/config could be wrong, but it passes all the tests, and we can keep the tests that way. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | | git-svn: add test for useSvnsyncPropsEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | These tests are very similar as the ones I used for useSvmProps and expect the same results because both dumps were generated from the same original repo. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: fix useSvmProps, hopefully for the last timeEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | svm:mirror is not useful at all for us. Parts of the old unit test were broken and based on my misunderstanding of the svm:mirror property. When we read svm:source; make sure we correctly handle the '!' in it: it is used to separate the path of the repository root from the virtual path within the repository. We don't need to make that distinction, honestly! We also ensure that subdirectories are also mirrored with the correct URL if we're using useSvmProps. We have a new test that uses dumped repo that was really created using SVN::Mirror to avoid ambiguities and mis-understandings about the svm: properties. Note: trailing whitespace in the svm.dump file is unfortunately a reality and required by SVN; so please ignore it when applying this patch. Also, ensure that the -R/--remote/--svn-remote flag is always in effect if explicitly passed via the command-line. This allows us to track logically different mirrors sharing the same URL (probably common with SVN::Mirror/SVK users). Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: hide the private git-svn 'config' file as '.metadata'Eric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Having it named as 'config' prevents us from tracking a ref named 'config', which is a huge mistake. On the non-technical side, the word 'config' implies that a user can freely modify it; but that's not the case here. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: brown paper bag fixesEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | * avoid skipping modification-only changes in fetch * correctly fetch when we only have branches and tags to glob from (no fetch keys defined) Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: allow 'init' to act as multi-initEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | multi-init is now just an alias that requires -T/-t/-b; all options that 'init' can now accept. This will hopefully simplify usage and reduce typing. Also, allow the --shared option in 'init' to take an optional argument now that 'git-init --shared' supports an optional argument. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | t910*: s/repo-config/config/g; poke around possible race conditionsEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some of the repo-config => config renaming missed the git-svn tests; so I'm just renaming them to be consisten with the rest of the modern git. Also, some of the newer tests didn't have 'poke' in them to workaround race conditions on fast machines. This adds places where they can _possibly_ occur; but I don't have fast enough hardware to trigger them. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: make test for SVK mirror path importsam@vilain.net2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A manual test that sets up a repository that looks like an SVK depot, and then imports it to check that it looks like we mirrored the 'original' source. There is also a minor modification to the git-svn test library shell file which sets a variable for the subversion repository's filesystem path. [ew: made some of the tests stricter and more thorough] Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: use separate, per-repository .rev_db filesEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need a separate .rev_db file for each repository we're tracking. This allows us to track the same logical path off multiple mirrors. We preserve a symlink to the old .rev_db (no-UUID) if we're (auto-)migrating from an old version to preserve backwards compatibility. Also, get rid of the uuid() wrapper since we cache UUID in our private config, and the SVN::Ra::get_uuid() function memoizes the return value per-connection. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: correctly handle globs with a right-hand-side path componentEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Several bugs were found and fixed while getting this to work: * Remember the 'R'(eplace) case of actions and treat it like we would an 'A'(dd) case. * Fix a small case of follow-parent missing a parent if a subdirectory was modified in the revision where the parent was copied. * dirents returned by get_dir sometimes expire if the data structure is too big and the pool is destroyed, so we cache get_dir (along with check_path and get_revprops) temporarily along with its pool. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: enable follow-parent functionality by defaultEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | --no-follow-parent disables and reverts it back to the old default behavior of not following parents (if you don't care for full history). Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: --follow-parent tracks multi-parent pathsEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We can have a branch that was deleted, then re-added under the same name but copied from another path, in which case we'll have multiple parents (we don't want to break the original ref, nor lose copypath info). Add a test for this, too, of course. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: prepare multi-init for wildcard supportEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | Update the tests since we no longer write so many things to the config. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: just name the default svn-remote "svn" instead of "git-svn"Eric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | It can be confusing and redundant, since historically the default remote ref (not remote itself) has been "git-svn", too. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: don't write to the config file from --follow-parentEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | Having 'fetch' entries in the config file created from --follow-parent is wasteful because it can cause *future* of invocations to follow revisions we were never interested in in the first place. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: fix several fetch bugs related to repeated invocationsEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We no longer delete the top-level directory even if it got deleted from the upstream repository. In gs_do_update; we double-check that the path we're tracking exists at both endpoints before proceeding. We have also added additional protection against fetching revisions out-of-order. To simplify our internal interfaces, I've disabled passing the 'recursive' flag to the gs_do_{switch,update} wrapper functions since we always want it in git-svn. We also pass the entire Git::SVN object rather than just the path because it helped me debug. When printing progress, the refname is printed out to make it less confusing when multi-fetch is running. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: fetch tracks initial change with --follow-parentEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We were still skipping path information from get_log if we are tracking /r9270/drunk/subversion/bindings/..., but got something like this in the log: A /r9270/drunk (from /r9270/trunk:14) Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: stop using path names as refnames with --follow-parentEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using path names as refnames breaks horribly if a user is tracking one large, toplevel directory, and a lower-level directory is followed from another project is a parent of another ref, as it will cause refnames such as: 'refs/remotes/trunk/path/to/stuff', which will conflict with a refname of 'refs/remotes/trunk'. Now we just append @$revno to the end of it the current refname. And if we have followed back to a grandparent, then we'll strip any existing '@$parent_revno' strings before appending our own '@$revno' string to it. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: correctly handle do_{switch,update} in deep directoriesEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The do_update or do_switch functions in SVN only allow for a single path component; so 'path/to/deep/dir' would be interpreted as 'path'. SVN 1.4.x has a reparent function that can let us change the session to use a higher-level root of the repository, so we can use that for do_switch (which still doesn't seem to work in SVN 1.4.3 (a fix was attempted, but they missed the rest of the typemap changes needed in trunk...)). On the do_update side, we can use set_path on higher level directories and set them to a newer revision so they don't get updated. We can't do this with do_switch, either, because the relative path we're tracking can change (directory moving into a child of itself). Because of these changes, we need to double check that our Fetch editor is correctly performing stripping on any prefixed paths from update, otherwise we'll just die() because that would be a bug. Added a test case which helped me notice and fix problems with do_switch, too. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: fix committing to subdirectories, add testsEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | I broke this part with the URL minimization; since git-svn will now try to connect to the root of the repository and will end up writing files there if it can... Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: fix segfaults from accessing svn_log_changed_path_tEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | svn_log_changed_path_t structs were being used out of scope outside of svn_ra_get_log (because I wanted to eventually be able to use git-svn with only a single connection to the repository). So now we dup them into a hash. This was fixed while making --follow-parent fetches more efficient. I've moved parsing of the command-line --revision argument outside of the Git::SVN module so Git::SVN::fetch() can be used in more places (such as find_parent_branch). Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: correctly track revisions made to deleted branchesEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git-svn has never been able to handle deleted branches very well because svn_ra_get_log() is all-or-nothing, meaning that if the max revision passed to it does not contain the path we're tracking, we miss all the revisions in the repository. Branches fetched using --follow-parent still do this sub-optimally (will be fixed soon). --follow-parent will soon become the default, so we will assume that when using get_log(); We will also avoid tracking revprops for revisions with no path-related changes since otherwise we just end up pulling logs to paths we don't care about. Also added a test for this to t9104-git-svn-follow-parent.sh and correctly commit the log message in the preceeding test (which conflicted with a filename). Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: avoid tracking change-less revisionsEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | They simply aren't interesting to track, and this will allow us to avoid get_log(). Since r0 is covered by this, we need to update the tests to not rely on r0 (which is always empty). Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: add an odd test case that seems to cause segfaults over HTTPEric Wong2007-02-23
| | | | | | | | | | | | Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: --follow-parent now works on sub-directories of larger branchesEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This means that tracking the path of: /another-larger/trunk/thunk/bump/thud inside a repository would follow: /larger-parent/trunk/thunk/bump/thud even if the svn log output looks like this: -------------------------------------------- Changed paths: A /another-larger (from /larger-parent:5) -------------------------------------------- Note: the usage of get_log() in git-svn still makes a an assumption that shouldn't be made with regard to revisions existing for a particular path. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: 'init' attempts to connect to the repository root if possibleEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | This allows connections to be used more efficiently and not require users to run 'git-svn migrate --minimize' for new repositories. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: allow --follow-parent on deleted directoriesEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | Any operations on the index in Git::SVN that is not wrapped by tmp_index_do() is wrong. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: disallow ambigious local refspecsEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | Having multiple fetch refspecs pointing to the same local ref would be a very bad thing. Start avoiding the use of fatal() or exit() inside the modules so we can libify more easily. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: --follow-parent works with svn-remotes multiple branchesEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bugs fixed: * We didn't allow manually (not using git-svn) init-ed remotes/fetch refspecs to be used before. It works now because that's what I did in this test. git-svn init should offer more control in the future. * correctly strip paths in the delta editor when using do_switch(). * Make the -i / GIT_SVN_ID option work correctly when doing fetch on a multi-ref svn-remote Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: fix --follow-parent to work with Git::SVNEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | While we're at it, beef up the test because I was getting false-passes during development. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: enable --minimize to simplify the config and connectionsEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | --minimize will update the git-svn configuration to attempt to connect to the repository root (instead of directly to the path(s) we are tracking) in order to allow more efficient reuse of connections (for multi-fetch and follow-parent). Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: add support for metadata in .git/configEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Of course, we handle metadata migrations from previous versions and we have added unit tests. The new .git/config remotes resemble non-SVN remotes. Below is an example with comments: [svn-remote "git-svn"] ; like non-svn remotes, we have one URL per-remote url = http://foo.bar.org/svn ; 'fetch' keys are done in the same way as non-svn ; remotes, too. With the left-hand-side of the ':' ; being the remote (SVN) repository path relative to the ; above 'url' key; and the right-hand-side being a ; remote ref in git (refs/remotes/*). ; An empty left-hand-side means that it will fetch ; the entire contents of the 'url' key. ; old-style (migrated from previous versions of git-svn) ; are like this: fetch = :refs/remotes/git-svn ; this is created by a current version of git-svn ; using the multi-init command with an explicit ; url (specified above). This allows multi-init ; to reuse SVN::Ra connections. fetch = trunk:refs/remotes/trunk fetch = branches/a:refs/remotes/a fetch = branches/b:refs/remotes/b fetch = tags/0.1:refs/remotes/tags/0.1 fetch = tags/0.2:refs/remotes/tags/0.2 fetch = tags/0.3:refs/remotes/tags/0.3 [svn-remote "alt"] ; this is another old-style remote migrated over ; to the new config format url = http://foo.bar.org/alt fetch = :refs/remotes/alt Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: remove graft-branches commandEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | It's becoming a maintenance burden. I've never found it particularly useful myself, nor have I heard much feedback about it; so I'm assuming it's just as useless to everyone else. Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: add a test for show-ignoreEric Wong2007-02-23
| | | | | | | | | | | | Signed-off-by: Eric Wong <normalperson@yhbt.net>
* | | git-svn: make multi-init capable of reusing the Ra connectionEric Wong2007-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a user specified a seperate URL and --tags/--branches as a sepearte URL, allow the Ra object (and therefore the connection) to be reused. We'll get rid of libsvn_ls_fullurl() since it was only used in one place. Signed-off-by: Eric Wong <normalperson@yhbt.net>
| | |
| \ \
*-. \ \ Merge branches 'lt/crlf' and 'jc/apply-config'Junio C Hamano2007-02-22
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * lt/crlf: Teach core.autocrlf to 'git apply' t0020: add test for auto-crlf Make AutoCRLF ternary variable. Lazy man's auto-CRLF * jc/apply-config: t4119: test autocomputing -p<n> for traditional diff input. git-apply: guess correct -p<n> value for non-git patches. git-apply: notice "diff --git" patch again Fix botched "leak fix" t4119: add test for traditional patch and different p_value apply: fix memory leak in prefix_one() git-apply: require -p<n> when working in a subdirectory. git-apply: do not lose cwd when run from a subdirectory. Teach 'git apply' to look at $HOME/.gitconfig even outside of a repository Teach 'git apply' to look at $GIT_DIR/config
| | * | | t4119: test autocomputing -p<n> for traditional diff input.Junio C Hamano2007-02-21
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
| | * | | git-apply: guess correct -p<n> value for non-git patches.Junio C Hamano2007-02-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This enhances the third point in the previous commit. When applying a non-git patch that begins like this: --- 2.6.orig/mm/slab.c +++ 2.6/mm/slab.c @@ -N,M +L,K @@@ ... and if you are in 'mm' subdirectory, we notice that -p2 is the right option to use to apply the patch in file slab.c in the current directory (i.e. mm/slab.c) The guess function also knows about this pattern, where you would need to use -p0 if applying from the top-level: --- mm/slab.c +++ mm/slab.c @@ -N,M +L,K @@@ ... Signed-off-by: Junio C Hamano <junkio@cox.net>
| | * | | git-apply: notice "diff --git" patch againJunio C Hamano2007-02-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Earlier one that tried to be too consistent with GNU patch by not stripping the leading path when we _know_ we are in a subdirectory and the patch is relative to the toplevel was a mistake. This fixes it. - No change to behaviour when it is run from the toplevel of the repository. - When run from a subdirectory to apply a git-generated patch, it uses the right -p<n> value automatically, with or without --index nor --cached option. - When run from a subdirectory to apply a randomly generated patch, it wants the right -p<n> value to be given by the user. The second one is a pure improvement to correct inconsistency between --index and non --index case, compared with 1.5.0. The third point could be further improved to guess what the right value for -p<n> should be by looking at the patch, but should be a topic of a separate patch. Signed-off-by: Junio C Hamano <junkio@cox.net>
| | * | | t4119: add test for traditional patch and different p_valueJunio C Hamano2007-02-21
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
| | * | | git-apply: require -p<n> when working in a subdirectory.Junio C Hamano2007-02-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git-apply running inside a subdirectory, with or without --index, used to always assume that the patch is formatted in such a way to apply with -p1 from the toplevel, but it is more useful and consistent with the use of "GNU patch -p1" if it defaulted to assume that its input is meant to apply at the level it is invoked in. This changes the behaviour. It used to be that the patch generated this way would apply without any trick: edit Documentation/Makefile git diff >patch.file cd Documentation git apply ../patch.file You need to give an explicit -p2 to git-apply now. On the other hand, if you got a patch from somebody else who did not follow "patch is to apply from the top with -p1" convention, the input patch would start with: diff -u Makefile.old Makefile --- Makefile.old +++ Makefile and in such a case, you can apply it with: git apply -p0 patch.file Signed-off-by: Junio C Hamano <junkio@cox.net>
| | * | | Teach 'git apply' to look at $GIT_DIR/configJunio C Hamano2007-02-17
| | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When neither --index nor --cached was used, git-apply did not try calling setup_git_directory(), which means it did not look at configuration files at all. This fixes it to call the setup function but still allow the command to be run in a directory not controlled by git. The bug probably meant that 'git apply', not moving up to the toplevel, did not apply properly formatted diffs from the toplevel when you are inside a subdirectory, even though 'git apply --index' would. As a side effect, this patch fixes it as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
| * | | Teach core.autocrlf to 'git apply'Junio C Hamano2007-02-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This teaches git-apply that the data read from and written to the filesystem might need to get converted to adjust for local line-ending convention. Signed-off-by: Junio C Hamano <junkio@cox.net>