mgedmin
Configurable remote name
It would be helpful to be able to specify the remote name that will be used for all of the clones.
Could you be more specific? Currently ghcloneall runs git clone -q $URL, which leaves the remote name selection to Git (and Git uses "origin" by default).
For updates, ghcloneall runs git pull -q --ff-only, which uses whichever remote was set up to be tracking the currently checked out branch. I think.
The word origin doesn't even show up in ghcloneall's sources.
Could you give an example of how you would use a different remote name?
As far as I could see, there was no way to specify the remote name to be used during the clone.
I dont believe this can be set as a git configuration. origin is hard coded, and needs to be overridden.
My dev team prefers that newcomers do not have an origin as they get confused by it, so we recommend upstream and <username>, so they have to think about it (esp. when running random commands they find on the internet)
@guyzmo's git-repo also has upstream as a special remote name for the central repository where all forks come from.
git clone has this:
--origin <name>, -o <name> Instead of using the remote name origin to keep track of the upstream repository, use <name>.
So I suppose ghcloneall could pass it to git clone.
I'm thinking a config file option git_clone_args (and/or command-line option --git-clone-args), so you could also optionally specify things like --depth=1 etc.
Does that sound useful to you?
(Would you perhaps like to create a pull request?)
Yup, that would be great. I'm a bit snowed under at the moment.
Your suggestion of --git-clone-args is also great for my needs; very flexible. However, it is not as discoverable/memoraberable for newbies. Especially --git-clone-args="--depth=1" . --shallow is much nicer to remember for newbies.
I think it would be confusing to have a command line option --origin, as people might think a URI should be given to that option. --origin-name or --remote-name would be better CLI arg names.
Under the covers of git, it will use an alternative remote name if it is the only one in the .git/config. As a result, the ghcloneall code-paths update/verify should work automatically with the alternate remote name.
why not use the traditional way: end your command's arguments with -- and all the following are passed through git?
Your suggestion of --git-clone-args is also great for my needs; very flexible. However, it is not as discoverable/memoraberable for newbies. Especially --git-clone-args="--depth=1" . --shallow is much nicer to remember for newbies.
I'm not too keen on wrapping every possible git clone option, but I would accept a pull request that adds --shallow and --origin-name.
why not use the traditional way: end your command's arguments with -- and all the following are passed through git?
ghcloneall runs git clone or git pull, and I expect those will want different options for the two commands. Using -- allows only one set of extra args.