user/sven/git.git/git-ls-remote.sh, branch v1.0rc6

ls-remote: define die() now we do not use git-sh-setup

2005-11-29T07:13:03Z

Another interesting "property" is that from inside a git managed tree, "git-ls-remote ." names the current repository no matter how deep a subdirectory you are in. Signed-off-by: Junio C Hamano

parse-remote and ls-remote clean-up.

2005-11-25T21:49:17Z

There is no reason to use git-sh-setup from git-ls-remote. git-parse-remote can help the caller to use .git/remotes shortcut if it is run inside a git repository, but can still be useful outside a git repositoryas long as the caller does not use any shortcut. Use "git-rev-parse --git-dir" to figure out where the GIT_DIR is, instead of using git-sh-setup. This also makes "git-ls-remote origin" to work from inside a subdirectory of a git managed repository as a side effect. Signed-off-by: Junio C Hamano

Do not require ls-remote to be run inside a git repository.

2005-10-06T21:10:39Z

The scripts work perfectly without a repository. Signed-off-by: Alex Riesen Signed-off-by: Junio C Hamano

Detect ls-remote failure properly.

2005-09-13T20:39:06Z

The part that can fail is before the pipe, so we need to propagate the error properly to the main process. Signed-off-by: Junio C Hamano

Big tool rename.

2005-09-08T00:45:20Z

As promised, this is the "big tool rename" patch. The primary differences since 0.99.6 are: (1) git-*-script are no more. The commands installed do not have any such suffix so users do not have to remember if something is implemented as a shell script or not. (2) Many command names with 'cache' in them are renamed with 'index' if that is what they mean. There are backward compatibility symblic links so that you and Porcelains can keep using the old names, but the backward compatibility support is expected to be removed in the near future. Signed-off-by: Junio C Hamano