summaryrefslogtreecommitdiff
path: root/contrib/workdir
AgeCommit message (Collapse)AuthorFilesLines
2010-08-22Typos in code comments, an error message, documentationLibravatar Ralf Wildenhues1-2/+2
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-21Always show which directory is not a git repositoryLibravatar Richard Hartmann1-1/+1
Unify all fatal: Not a git repository error messages so they include path information. Signed-off-by: Richard Hartmann <richih@net.in.tum.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-15git-new-workdir: Share SVN meta data between work dirs and the repositoryLibravatar Bernt Hansen1-1/+1
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 <bernt@norang.ca> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-05Don't allow contrib/workdir/git-new-workdir to trash existing dirsLibravatar Shawn O. Pearce1-0/+6
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 <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>