path: root/contrib/workdir
AgeCommit message (Collapse)Author
2017-05-10git-new-workdir: mark script as LF-onlyJohannes Schindelin
Bash does not handle scripts with CR/LF line endings correctly, therefore they *have* to be forced to LF-only line endings. Funnily enough, this fixes t3000-ls-files-others and t1021-rerere-in-workdir when git.git was checked out with core.autocrlf=true, as these test still use git-new-workdir (once `git worktree` is no longer marked as experimental, both scripts probably want to be ported to using that command instead). Signed-off-by: Johannes Schindelin <> Reviewed-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2014-12-03git-new-workdir: don't fail if the target directory is emptyPaul Smith
Allow new workdirs to be created in an empty directory (similar to "git clone"). Provide more error checking and clean up on failure. Signed-off-by: Paul Smith <> Signed-off-by: Junio C Hamano <>
2010-09-27prefer test -h over test -L in shell scriptsJeff King
Even though "-L" is POSIX, the former is more portable, and we tend to prefer it already. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2010-08-22Typos in code comments, an error message, documentationRalf Wildenhues
Signed-off-by: Ralf Wildenhues <> Signed-off-by: Junio C Hamano <>
2008-12-22Always show which directory is not a git repositoryRichard Hartmann
Unify all fatal: Not a git repository error messages so they include path information. Signed-off-by: Richard Hartmann <> Signed-off-by: Junio C Hamano <>
2008-03-15git-new-workdir: Share SVN meta data between work dirs and the repositoryBernt Hansen
Multiple work dirs with git svn caused each work dir to have its own stale copy of the SVN meta data in .git/svn git svn rebase updates commits with git-svn-id: in the repository and stores the SVN meta data information only in that work dir. Attempting to git svn rebase in other work dirs for the same branch would fail because the last revision fetched according to the git-svn-id is greater than the revision in the SVN meta data for that work directory. Signed-off-by: Bernt Hansen <> Acked-by: Eric Wong <> Signed-off-by: Junio C Hamano <>
2007-09-06Don't allow contrib/workdir/git-new-workdir to trash existing dirsShawn O. Pearce
Recently I found that doing a sequence like the following: git-new-workdir a b ... git-new-workdir a b by accident will cause a (and now also b) to have an infinite cycle in its refs directory. This is caused by git-new-workdir trying to create the "refs" symlink over again, only during the second time it is being created within a's refs directory and is now also pointing back at a's refs. This causes confusion in git as suddenly branches are named things like "refs/refs/refs/refs/refs/refs/refs/heads/foo" instead of the more commonly accepted "refs/heads/foo". Plenty of commands start to see ambiguous ref names and others just take ages to compute. git-clone has the same safety check, so git-new-workdir should behave just like it. Signed-off-by: Shawn O. Pearce <> Signed-off-by: Junio C Hamano <>
2007-08-22Suggest unsetting core.bare when using new-workdir on a bare repositoryShawn O. Pearce
If core.bare is set to true in the config file of a repository that the user is trying to create a working directory from we should abort and suggest to the user that they remove the option first. If we leave the core.bare=true setting in the config file then working tree operations will get confused when they attempt to execute in the new workdir, as it shares its config file with the bare repository. The working tree operations will assume that the workdir is bare and abort, which is not what the user wants. If we changed core.bare to be false then working tree operations will function in the workdir but other operations may fail in the bare repository, as it claims to not be bare. If we remove core.bare from the config then Git can fallback on the legacy guessing behavior. This allows operations in the bare repository to work as though it were bare, while operations in the workdirs to act as though they are not bare. Signed-off-by: Shawn O. Pearce <> Signed-off-by: Junio C Hamano <>
2007-08-22Fix new-workdir (again) to work on bare repositoriesShawn O. Pearce
My day-job workflow involves using multiple workdirs attached to a bunch of bare repositories. Such repositories are stored inside of a directory called "foo.git", which means `git rev-parse --git-dir` will return "." and not ".git". Under such conditions new-workdir was getting confused about where the Git repository it was supplied is actually located. If we get "." for the result of --git-dir query it means we should use the user supplied path as-is, and not attempt to perform any magic on it, as the path is directly to the repository. Signed-off-by: Shawn O. Pearce <> Signed-off-by: Junio C Hamano <>
2007-06-27git-new-workdir: Fix shell warning about operator == used with test.Simon Hausmann
Use = instead of == with test to test for equality. Signed-off-by: Simon Hausmann <> Signed-off-by: Junio C Hamano <>
2007-06-24new-workdir: handle rev-parse --git-dir not always giving full pathJulian Phillips
rev-parse --git-dir outputs a full path - except for the single case of when the path would be $(pwd)/.git, in which case it outputs simply .git. Check for this special case and handle it. Signed-off-by: Julian Phillips <> Signed-off-by: Junio C Hamano <>
2007-05-29Allow contrib new-workdir to link into bare repositoriesShawn O. Pearce
On one particular system I like to keep a cluster of bare Git repositories and spawn new-workdirs off of them. Since the bare repositories don't have working directories associated with them they don't have a .git/ subdirectory that hosts the repository we are linking to. Using a bare repository as the backing repository for a workdir created by this script does require that the user delete core.bare from the repository's configuration file, so that Git auto-senses the bareness of a repository based on pathname information, and not based on the config file. Signed-off-by: Shawn O. Pearce <> Signed-off-by: Junio C Hamano <>
2007-03-31contrib/workdir: add a simple script to create a working directoryJulian Phillips
Add a simple script to create a working directory that uses symlinks to point at an exisiting repository. This allows having different branches in different working directories but all from the same repository. Based on a description from Junio of how he creates multiple working directories[1]. With the following caveat: "This risks confusion for an uninitiated if you update a ref that is checked out in another working tree, but modulo that caveat it works reasonably well." [1] Signed-off-by: Julian Phillips <> Signed-off-by: Junio C Hamano <>