git/contrib/workdir, branch v2.4.2

git-new-workdir: don't fail if the target directory is empty

2014-12-03T20:49:24Z

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

prefer test -h over test -L in shell scripts

2010-09-27T17:48:23Z

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

Typos in code comments, an error message, documentation

2010-08-22T20:25:08Z

Signed-off-by: Ralf Wildenhues Signed-off-by: Junio C Hamano

Always show which directory is not a git repository

2008-12-22T02:46:41Z

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

git-new-workdir: Share SVN meta data between work dirs and the repository

2008-03-15T07:05:18Z

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

Don't allow contrib/workdir/git-new-workdir to trash existing dirs

2007-09-06T05:24:54Z

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

Suggest unsetting core.bare when using new-workdir on a bare repository

2007-08-22T22:18:13Z

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

Fix new-workdir (again) to work on bare repositories

2007-08-22T22:18:13Z

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

git-new-workdir: Fix shell warning about operator == used with test.

2007-06-27T01:18:47Z

Use = instead of == with test to test for equality. Signed-off-by: Simon Hausmann Signed-off-by: Junio C Hamano

new-workdir: handle rev-parse --git-dir not always giving full path

2007-06-24T09:36:56Z

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