summaryrefslogtreecommitdiff
path: root/contrib/workdir
AgeCommit message (Collapse)AuthorFilesLines
2007-08-22Suggest unsetting core.bare when using new-workdir on a bare repositoryLibravatar Shawn O. Pearce1-0/+8
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 <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-22Fix new-workdir (again) to work on bare repositoriesLibravatar Shawn O. Pearce1-3/+7
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 <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-26git-new-workdir: Fix shell warning about operator == used with test.Libravatar Simon Hausmann1-1/+1
Use = instead of == with test to test for equality. Signed-off-by: Simon Hausmann <simon@lst.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-24new-workdir: handle rev-parse --git-dir not always giving full pathLibravatar Julian Phillips1-0/+5
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 <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-05-29Allow contrib new-workdir to link into bare repositoriesLibravatar Shawn O. Pearce1-5/+7
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 <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-31contrib/workdir: add a simple script to create a working directoryLibravatar Julian Phillips1-0/+57
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] http://article.gmane.org/gmane.comp.version-control.git/41513/ Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>