summaryrefslogtreecommitdiff
path: root/git-remote.perl
AgeCommit message (Collapse)AuthorFilesLines
2007-05-10Git.pm: config_boolean() -> config_bool()Libravatar Petr Baudis1-2/+2
This patch renames config_boolean() to config_bool() for consistency with the commandline interface and because it is shorter but still obvious. ;-) It also changes the return value from some obscure string to real Perl boolean, allowing for clean user code. Signed-off-by: Petr Baudis <pasky@suse.cz>
2007-03-20Teach git-remote to list pushed branches.Libravatar Johannes Sixt1-1/+15
The configured refspecs are printed almost verbatim, i.e. both the local and the remote branch name separated by a colon are printed; only the prefix 'refs/heads/' is removed, like this: Local branch(es) pushed with 'git push' master refs/tags/*:refs/tags/* next:next Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-21git-remote: support remotes with a dot in the nameLibravatar Pavel Roskin1-1/+1
[jc: the original from Pavel was limiting the variable names to only fetch and url, but I loosened it to take valid variable names.] Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20Allow git-remote to update named groups of remotesLibravatar Theodore Ts'o1-9/+31
In response to a feature request from Shawn Pearce, this patch allows a user to update a named group of remotes by using "git remote update <group>", where the group is defined in the config file by remotes.<group>. The default if the named group is not specified is now fetched group remotes.default, instead of remote.fetch, which is what had been previously used. In addition, if remotes.default is not defined, all remotes defined in the config file will be used, as before, but there is now also possible to request that a particular repository to be skipped by default by using the boolean configuration parameter remote.<name>.skipDefaultUpdate. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-19Teach git-remote to update existing remotes by fetching from themLibravatar Theodore Ts'o1-0/+13
This allows users to use the command "git remote update" to update all remotes that are being tracked in the repository. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-05Teach git-remote add to fetch and trackLibravatar Junio C Hamano1-6/+48
This adds three options to 'git-remote add'. * -f (or --fetch) option tells it to also run the initial "git fetch" using the newly created remote shorthand. * -t (or --track) option tells it not to use the default wildcard to track all branches. * -m (or --master) option tells it to make the remote/$name/HEAD point at a remote tracking branch other than master. For example, with this I can say: $ git remote add -f -t master -t quick-start -m master \ jbf-um git://linux-nfs.org/~bfields/git.git/ to (1) create remote.jbf-um.url; (2) track master and quick-start branches (and no other); the two -t options create these two lines: fetch = +refs/heads/master:refs/remotes/jbf-um/master fetch = +refs/heads/quick-start:refs/remotes/jbf-um/quick-start (3) set up remotes/jbf-um/HEAD to point at jbf-um/master so that later I can say "git log jbf-um" Or I could do $ git remote add -t 'ap/*' andy /home/andy/git.git to make Andy's topic branches kept track of under refs/remotes/andy/ap/. Other possible improvements I considered but haven't implemented (hint, hint) are: * reject wildcard letters other than a trailing '*' to the -t parameter; * make -m optional and when the first -t parameter does not have the trailing '*' default to that value (so the above example does not need to say "-m master"); * if -m is not given, and -t parameter ends with '*' (i.e. the above defaulting did not tell us where to point HEAD at), and if we did the fetch with -f, check if 'master' was fetched and make HEAD point at it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-01Teach 'git remote' how to cleanup stale tracking branches.Libravatar Shawn O. Pearce1-1/+38
Since it can be annoying to manually cleanup 40 tracking branches which were removed by the remote system, 'git remote prune <n>' can now be used to delete any tracking branches under <n> which are no longer available on the remote system. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-01Pull out remote listing functions in git-remote.Libravatar Shawn O. Pearce1-20/+23
I want to reuse the stale branch detection to implement a new 'git remote prune' subcommand. Easiest way to do that is to use the same logic that 'git remote show' uses to determine the stale tracking branches, then delete those. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28[PATCH] Rename git-repo-config to git-config.Libravatar Tom Prince1-4/+4
Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-13git-remote: no longer silent on unknown commands.Libravatar Quy Tonthat1-1/+6
Signed-off-by: Quy Tonthat <qtonthat@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-04git-remoteLibravatar Junio C Hamano1-0/+277
It might be handy to have a single command that helps you manage your configuration that relates to downloading from remote repositories. This currently does only about 20% of what I want it to do. $ git remote shows the list of 'remotes' you have defined somewhere, and $ git remote origin shows the details about the named remote (in this case "origin"). How the branches are tracked, if you have a tracking branch that is stale, etc. $ git add another git://git.kernel.org/pub/... defines the default remote.another.url and remote.another.fetch entries just like a clone does; you can say "git fetch another" afterwards. For it to be useful, I think it should be enhanced to: - check overlaps of tracking branches and warn; - offer to remove stale tracking branches in one go; - offer ways to remove or rename remote; - offer ways to update an existing remote, perhaps have an interactive mode; Other enhancements might be also possible, but I do not think of anything that is absolutely necessary other than the above right now. Signed-off-by: Junio C Hamano <junkio@cox.net>