git/git-clone.sh, branch v1.5.0-rc3

Escape --upload-pack from expr.

2007-01-31T21:09:58Z

Recent commit ae1dffcb28ee89a23f8d2747be65e17c8eab1690 by Junio changed the way --upload-pack was passed around between clone, fetch and ls-remote and modified the handling of the command line parameter parsing. Unfortunately FreeBSD 6.1 insists that the expression expr --upload-pack=git-upload-pack : '-[^=]*=\(.*\)' is illegal, as the --upload-pack option is not supported by their implementation of expr. Elsewhere in Git we use z as a leading prefix of both arguments, ensuring the -- isn't seen by expr. Signed-off-by: Shawn O. Pearce Signed-off-by: Junio C Hamano

Replace perl code with pure shell code

2007-01-29T09:05:01Z

Signed-off-by: Simon 'corecode' Schubert Signed-off-by: Junio C Hamano

[PATCH] Rename git-repo-config to git-config.

2007-01-29T00:16:53Z

Signed-off-by: Tom Prince Signed-off-by: Junio C Hamano

ls-remote and clone: accept --upload-pack= as well.

2007-01-25T00:12:15Z

This makes them consistent with other commands that take the path to the upload-pack program. We also pass --upload-pack instead of --exec to the underlying fetch-pack, although it is not strictly necessary. [jc: original motivation from Uwe] Signed-off-by: Junio C Hamano

use 'init' instead of 'init-db' for shipped docs and tools

2007-01-12T21:36:16Z

While 'init-db' still is and probably will always remain a valid git command for obvious backward compatibility reasons, it would be a good idea to move shipped tools and docs to using 'init' instead. Signed-off-by: Nicolas Pitre Signed-off-by: Junio C Hamano

git-clone: Make sure the master branch exists before running cat on it.

2007-01-10T00:14:41Z

Otherwise we get an error like this on stderr: cat: [...]/.git/refs/remotes/origin/master: No such file or directory which makes it look like git-clone failed. Signed-off-by: Alexandre Julliard Signed-off-by: Junio C Hamano

Allow non-fast-forward of remote tracking branches in default clone

2006-12-29T02:37:33Z

This changes the default remote.origin.fetch configuration created by git-clone so that it allows non-fast-forward updates. When using the separate-remote layout with reflog enabled, it does not make much sense to refuse to update the remote tracking branch just because some of them do not fast-forward. git-fetch issues warnings on non-fast-forwardness, and the user can peek at what the previous state was using the reflog. Signed-off-by: Junio C Hamano

Merge branch 'master' into js/shallow

2006-12-27T10:43:46Z

This is to adjust to: count-objects -v: show number of packs as well. which will break a test in this series. Signed-off-by: Junio C Hamano

git-clone: lose the traditional 'no-separate-remote' layout

2006-12-16T21:01:41Z

Finally. The separate-remote layout is so much more organized than traditional and easier to work with especially when you need to deal with remote repositories with multiple branches and/or you need to deal with more than one remote repositories, and using traditional layout for new repositories simply does not make much sense. Internally we still have code for 1:1 mappings to create a bare clone; that is a good thing and will not go away. Signed-off-by: Junio C Hamano

git-clone: lose the artificial "first" fetch refspec

2006-12-16T21:01:41Z

Now we lost the "first refspec is the one that is merged by default" rule, there is no reason for clone to list the remote primary branch in the config file explicitly anymore. We still need it for the traditional layout for other reasons, though. Signed-off-by: Junio C Hamano