* [RFC] git-remote
@ 2007-01-03 21:40 Junio C Hamano
2007-01-03 22:05 ` Jakub Narebski
` (3 more replies)
0 siblings, 4 replies; 16+ messages in thread
From: Junio C Hamano @ 2007-01-03 21:40 UTC (permalink / raw)
To: git
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;
- give different levels of verbosity in its 'show' command,
especially if ls-remote is run;
- 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>
---
Makefile | 2 +-
git-remote.perl | 260 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 261 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index fa1a022..ea07634 100644
--- a/Makefile
+++ b/Makefile
@@ -179,7 +179,7 @@ SCRIPT_SH = \
SCRIPT_PERL = \
git-add--interactive.perl \
git-archimport.perl git-cvsimport.perl git-relink.perl \
- git-cvsserver.perl \
+ git-cvsserver.perl git-remote.perl \
git-svnimport.perl git-cvsexportcommit.perl \
git-send-email.perl git-svn.perl
diff --git a/git-remote.perl b/git-remote.perl
new file mode 100755
index 0000000..b0ec838
--- /dev/null
+++ b/git-remote.perl
@@ -0,0 +1,260 @@
+#!/usr/bin/perl -w
+
+use Git;
+my $git = Git->repository();
+
+sub add_remote_config {
+ my ($hash, $name, $what, $value) = @_;
+ if ($what eq 'url') {
+ if (exists $hash->{$name}{'URL'}) {
+ print STDERR "Warning: more than one remote.$name.url\n";
+ }
+ $hash->{$name}{'URL'} = $value;
+ }
+ elsif ($what eq 'fetch') {
+ $hash->{$name}{'FETCH'} ||= [];
+ push @{$hash->{$name}{'FETCH'}}, $value;
+ }
+ if (!exists $hash->{$name}{'SOURCE'}) {
+ $hash->{$name}{'SOURCE'} = 'config';
+ }
+}
+
+sub add_remote_remotes {
+ my ($hash, $file, $name) = @_;
+
+ if (exists $hash->{$name}) {
+ $hash->{$name}{'WARNING'} = 'ignored due to config';
+ return;
+ }
+
+ my $fh;
+ if (!open($fh, '<', $file)) {
+ print STDERR "Warning: cannot open $file\n";
+ return;
+ }
+ my $it = { 'SOURCE' => 'remotes' };
+ $hash->{$name} = $it;
+ while (<$fh>) {
+ chomp;
+ if (/^URL:\s*(.*)$/) {
+ # Having more than one is Ok -- it is used for push.
+ if (! exists $it->{'URL'}) {
+ $it->{'URL'} = $1;
+ }
+ }
+ elsif (/^Push:\s*(.*)$/) {
+ ; # later
+ }
+ elsif (/^Pull:\s*(.*)$/) {
+ $it->{'FETCH'} ||= [];
+ push @{$it->{'FETCH'}}, $1;
+ }
+ elsif (/^\#/) {
+ ; # ignore
+ }
+ else {
+ print STDERR "Warning: funny line in $file: $_\n";
+ }
+ }
+ close($fh);
+}
+
+sub list_remote {
+ my ($git) = @_;
+ my %seen = ();
+
+ for ($git->command(qw(repo-config --get-regexp), '^remote\.')) {
+ if (/^remote\.([^.]*)\.(\S*)\s+(.*)$/) {
+ add_remote_config(\%seen, $1, $2, $3);
+ }
+ }
+
+ my $dir = $git->repo_path() . "/remotes";
+ if (opendir(my $dh, $dir)) {
+ local $_;
+ while ($_ = readdir($dh)) {
+ chomp;
+ next if (! -f "$dir/$_" || ! -r _);
+ add_remote_remotes(\%seen, "$dir/$_", $_);
+ }
+ }
+
+ return \%seen;
+}
+
+sub add_branch_config {
+ my ($hash, $name, $what, $value) = @_;
+ if ($what eq 'remote') {
+ if (exists $hash->{$name}{'REMOTE'}) {
+ print STDERR "Warning: more than one branch.$name.remote\n";
+ }
+ $hash->{$name}{'REMOTE'} = $value;
+ }
+ elsif ($what eq 'merge') {
+ $hash->{$name}{'MERGE'} ||= [];
+ push @{$hash->{$name}{'MERGE'}}, $value;
+ }
+}
+
+sub list_branch {
+ my ($git) = @_;
+ my %seen = ();
+ for ($git->command(qw(repo-config --get-regexp), '^branch\.')) {
+ if (/^branch\.([^.]*)\.(\S*)\s+(.*)$/) {
+ add_branch_config(\%seen, $1, $2, $3);
+ }
+ }
+
+ return \%seen;
+}
+
+my $remote = list_remote($git);
+my $branch = list_branch($git);
+
+sub update_ls_remote {
+ my ($harder, $info) = @_;
+
+ return if (($harder == 0) ||
+ (($harder == 1) && exists $info->{'LS_REMOTE'}));
+
+ my @ref = map {
+ s|^[0-9a-f]{40}\s+refs/heads/||;
+ $_;
+ } $git->command(qw(ls-remote --heads), $info->{'URL'});
+ $info->{'LS_REMOTE'} = \@ref;
+}
+
+sub show_wildcard_mapping {
+ my ($forced, $ours, $ls) = @_;
+ my %refs;
+ for (@$ls) {
+ $refs{$_} = 01; # bit #0 to say "they have"
+ }
+ for ($git->command('for-each-ref', "refs/remotes/$ours")) {
+ chomp;
+ next unless (s|^[0-9a-f]{40}\s[a-z]+\srefs/remotes/$ours/||);
+ next if ($_ eq 'HEAD');
+ $refs{$_} ||= 0;
+ $refs{$_} |= 02; # bit #1 to say "we have"
+ }
+ my (@new, @stale, @tracked);
+ for (sort keys %refs) {
+ my $have = $refs{$_};
+ if ($have == 1) {
+ push @new, $_;
+ }
+ elsif ($have == 2) {
+ push @stale, $_;
+ }
+ elsif ($have == 3) {
+ push @tracked, $_;
+ }
+ }
+ if (@new) {
+ print " New remote branches (next fetch will store in remotes/$ours)\n";
+ print " @new\n";
+ }
+ if (@stale) {
+ print " Stale tracking branches in remotes/$ours (you'd better remove them)\n";
+ print " @stale\n";
+ }
+ if (@tracked) {
+ print " Tracked remote branches\n";
+ print " @tracked\n";
+ }
+}
+
+sub show_mapping {
+ my ($name, $info) = @_;
+ my $fetch = $info->{'FETCH'};
+ my $ls = $info->{'LS_REMOTE'};
+ my (@stale, @tracked);
+
+ for (@$fetch) {
+ next unless (/(\+)?([^:]+):(.*)/);
+ my ($forced, $theirs, $ours) = ($1, $2, $3);
+ if ($theirs eq 'refs/heads/*' &&
+ $ours =~ /^refs\/remotes\/(.*)\/\*$/) {
+ # wildcard mapping
+ show_wildcard_mapping($forced, $1, $ls);
+ }
+ elsif ($theirs =~ /\*/ || $ours =~ /\*/) {
+ print STDERR "Warning: unrecognized mapping in remotes.$name.fetch: $_\n";
+ }
+ elsif ($theirs =~ s|^refs/heads/||) {
+ if (!grep { $_ eq $theirs } @$ls) {
+ push @stale, $theirs;
+ }
+ elsif ($ours ne '') {
+ push @tracked, $theirs;
+ }
+ }
+ }
+ if (@stale) {
+ print " Stale tracking branches in remotes/$name (you'd better remove them)\n";
+ print " @stale\n";
+ }
+ if (@tracked) {
+ print " Tracked remote branches\n";
+ print " @tracked\n";
+ }
+}
+
+sub show_remote {
+ my ($name, $ls_remote) = @_;
+ if (!exists $remote->{$name}) {
+ print STDERR "No such remote $name\n";
+ return;
+ }
+ my $info = $remote->{$name};
+ update_ls_remote($ls_remote, $info);
+
+ print "* remote $name\n";
+ print " URL: $info->{'URL'}\n";
+ for my $branchname (sort keys %$branch) {
+ next if ($branch->{$branchname}{'REMOTE'} ne $name);
+ my @merged = map {
+ s|^refs/heads/||;
+ $_;
+ } split(' ',"@{$branch->{$branchname}{'MERGE'}}");
+ next unless (@merged);
+ print " Remote branch(es) merged with 'git pull' while on branch $branchname\n";
+ print " @merged\n";
+ }
+ if ($info->{'LS_REMOTE'}) {
+ show_mapping($name, $info);
+ }
+}
+
+sub add_remote {
+ my ($name, $url) = @_;
+ if (exists $remote->{$name}) {
+ print STDERR "remote $name already exists.\n";
+ exit(1);
+ }
+ $git->command('repo-config', "remote.$name.url", $url);
+ $git->command('repo-config', "remote.$name.fetch",
+ "+refs/heads/*:refs/remotes/$name/*");
+}
+
+if (!@ARGV) {
+ for (sort keys %$remote) {
+ print "$_\n";
+ }
+}
+elsif ($ARGV[0] eq 'show') {
+ if (@ARGV != 2) {
+ print STDERR "Usage: git remote show <remote>\n";
+ exit(1);
+ }
+ show_remote($ARGV[1], 1);
+}
+elsif ($ARGV[0] eq 'add') {
+ if (@ARGV != 3) {
+ print STDERR "Usage: git remote show <name> <url>\n";
+ exit(1);
+ }
+ add_remote($ARGV[1], $ARGV[2]);
+}
+
--
1.5.0.rc0.gcc26
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: [RFC] git-remote
2007-01-03 21:40 [RFC] git-remote Junio C Hamano
@ 2007-01-03 22:05 ` Jakub Narebski
2007-01-05 3:02 ` Shawn O. Pearce
` (2 subsequent siblings)
3 siblings, 0 replies; 16+ messages in thread
From: Jakub Narebski @ 2007-01-03 22:05 UTC (permalink / raw)
To: git
Junio C Hamano wrote:
> +elsif ($ARGV[0] eq 'add') {
> + if (@ARGV != 3) {
> + print STDERR "Usage: git remote show <name> <url>\n";
I think you meant to write here "Usage: git remote add <name> <url>\n";
("add" instead of "show").
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [RFC] git-remote
2007-01-03 21:40 [RFC] git-remote Junio C Hamano
2007-01-03 22:05 ` Jakub Narebski
@ 2007-01-05 3:02 ` Shawn O. Pearce
2007-01-05 3:07 ` Junio C Hamano
2007-01-05 12:59 ` Santi Béjar
2007-01-09 4:28 ` J. Bruce Fields
3 siblings, 1 reply; 16+ messages in thread
From: Shawn O. Pearce @ 2007-01-05 3:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <junkio@cox.net> wrote:
> 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
This is pretty cool. It would be nice if something like it was
in 1.5.0. ;-)
--
Shawn.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] git-remote
2007-01-05 3:02 ` Shawn O. Pearce
@ 2007-01-05 3:07 ` Junio C Hamano
2007-01-05 3:17 ` Shawn O. Pearce
0 siblings, 1 reply; 16+ messages in thread
From: Junio C Hamano @ 2007-01-05 3:07 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> 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
>
> This is pretty cool. It would be nice if something like it was
> in 1.5.0. ;-)
Hmph.
By the way, do you have comments on my counterproposal for
lockfile fix?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] git-remote
2007-01-05 3:07 ` Junio C Hamano
@ 2007-01-05 3:17 ` Shawn O. Pearce
0 siblings, 0 replies; 16+ messages in thread
From: Shawn O. Pearce @ 2007-01-05 3:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <junkio@cox.net> wrote:
> By the way, do you have comments on my counterproposal for
> lockfile fix?
Yea, see the email in that thread.
Sorry for the lag. I've been sidetracked by a new and fairly useless
(to me anyway) project that I have to put a lot of time into now.
Arrgh. At least I have a sound version control system to track
its source code in. :-)
--
Shawn.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] git-remote
2007-01-03 21:40 [RFC] git-remote Junio C Hamano
2007-01-03 22:05 ` Jakub Narebski
2007-01-05 3:02 ` Shawn O. Pearce
@ 2007-01-05 12:59 ` Santi Béjar
2007-01-05 13:53 ` Johannes Schindelin
2007-01-09 4:28 ` J. Bruce Fields
3 siblings, 1 reply; 16+ messages in thread
From: Santi Béjar @ 2007-01-05 12:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
+1. And much better than my RFC for "git clone --add".
Just some comments. I know it's in its early shape, tell me if you
want this kind of comments later.
* I think it is more coherent to list the tracked branches first and
second the "branch merges".
* In "git remote add <name> <remote>": git could use the remote url to
deduce a <name>, like what git-clone does.
* If a branch does not have a branch.<name>.remote git-remote does not
default it to "origin" and sends an:
Use of uninitialized value in string ne at
/home/santi/usr/stow/git/bin/git-remote line 222.
Maybe, in addition to this, git should require a branch.<name>.remote.
* With the config:
[remote "origin"]
url = git://git2.kernel.org/pub/scm/git/git.git
fetch = master:refs/remotes/origin/master
fetch = next:refs/remotes/origin/next
fetch = +refs/heads/pu:refs/remotes/origin/pu
fetch = refs/heads/*:refs/remotes/origin/*
[branch "next"]
merge=next
It outputs something as:
* remote origin
URL: git://git2.kernel.org/pub/scm/git/git.git
Tracked remote branches
html maint man master next pu todo
Tracked remote branches
pu
* The first "Tracked ..." is for the wildcards and the second for the
explicit fetch. Maybe it should join the two or mark different as:
Implicit tracked ...
Tracked ...
* The next and master branches are missing because they are written
without the refs/heads/ prefix. And for this reason there is no:
Remote branch(es) merged with 'git pull' while on branch next
next
(and the absence of branch.next.remote).
* In addition I would reformat this as:
Merges with 'git pull' while on branch:
"next" merges "next"
"topic" merges "master"
...
That's all for today :)
Santi
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [RFC] git-remote
2007-01-05 12:59 ` Santi Béjar
@ 2007-01-05 13:53 ` Johannes Schindelin
2007-01-05 19:53 ` Santi Béjar
0 siblings, 1 reply; 16+ messages in thread
From: Johannes Schindelin @ 2007-01-05 13:53 UTC (permalink / raw)
To: Santi Béjar; +Cc: Junio C Hamano, git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 672 bytes --]
Hi,
On Fri, 5 Jan 2007, Santi Béjar wrote:
> * In "git remote add <name> <remote>": git could use the remote url to
> deduce a <name>, like what git-clone does.
That does not make any sense. For example, I track
"git://git.kernel.org/.../git.git" and "192.168.0.128:gits/git.git".
Something very similar applies to the host name: if you track multiple
Linux repos, chances are that most of them are on git.kernel.org.
I guess _if_ you have more than one upstream you are tracking (which is
not the most common case, but hey, git-remote is for exactly that case) it
is not uncommon to have similar urls.
IMHO Junio's proposal is as good as it gets.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] git-remote
2007-01-05 13:53 ` Johannes Schindelin
@ 2007-01-05 19:53 ` Santi Béjar
2007-01-05 21:08 ` Carl Worth
0 siblings, 1 reply; 16+ messages in thread
From: Santi Béjar @ 2007-01-05 19:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
On 1/5/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 5 Jan 2007, Santi Béjar wrote:
>
> > * In "git remote add <name> <remote>": git could use the remote url to
> > deduce a <name>, like what git-clone does.
>
> That does not make any sense. For example, I track
> "git://git.kernel.org/.../git.git" and "192.168.0.128:gits/git.git".
> Something very similar applies to the host name: if you track multiple
> Linux repos, chances are that most of them are on git.kernel.org.
>
> I guess _if_ you have more than one upstream you are tracking (which is
> not the most common case, but hey, git-remote is for exactly that case) it
> is not uncommon to have similar urls.
>
> IMHO Junio's proposal is as good as it gets.
>
I was talking about the default name, so you could do:
$ git clone\
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
$ cd linux-2.6
$ git remote add \
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-2.6.git
$ git remote show libata-2.6
Santi
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] git-remote
2007-01-05 19:53 ` Santi Béjar
@ 2007-01-05 21:08 ` Carl Worth
2007-01-06 1:59 ` Junio C Hamano
0 siblings, 1 reply; 16+ messages in thread
From: Carl Worth @ 2007-01-05 21:08 UTC (permalink / raw)
To: Santi Béjar; +Cc: Johannes Schindelin, Junio C Hamano, git
[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]
On Fri, 5 Jan 2007 20:53:22 +0100, "=?ISO-8859-1?Q?Santi_B=E9jar?=" wrote:
> I was talking about the default name, so you could do:
>
> $ git clone\
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> $ cd linux-2.6
> $ git remote add \
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-2.6.git
> $ git remote show libata-2.6
Yes.
I'd go one further and say that it'd be really nice if git-clone could
be seen as equivalent, (and basically equivalent internally), to a
simple sequence of steps that could be performed manually. Something
like:
name=$(basename $url)
mkdir $name
cd $name
git init-db
git remote add $url
git pull $name
I haven't played with the new git-remote stuff at all yet, but the
rest of the above does work already, (but for a "warning: no common
commits" message). The only thing missing compared to git-clone is the
remotes configuration. So if the new git-remote can provide behavior
equivalent to what git clone provides, that would be excellent.
If for one have often wanted the ability to easily add a second remote
as if from git-clone.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] git-remote
2007-01-05 21:08 ` Carl Worth
@ 2007-01-06 1:59 ` Junio C Hamano
2007-01-08 22:52 ` Carl Worth
0 siblings, 1 reply; 16+ messages in thread
From: Junio C Hamano @ 2007-01-06 1:59 UTC (permalink / raw)
To: Carl Worth; +Cc: git
Carl Worth <cworth@cworth.org> writes:
> On Fri, 5 Jan 2007 20:53:22 +0100, "=?ISO-8859-1?Q?Santi_B=E9jar?=" wrote:
>> I was talking about the default name, so you could do:
>>
>> $ git clone\
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>> $ cd linux-2.6
>> $ git remote add \
>> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-2.6.git
>> $ git remote show libata-2.6
>
> Yes.
No. Because...
> I'd go one further and say that it'd be really nice if git-clone could
> be seen as equivalent, (and basically equivalent internally), to a
> simple sequence of steps that could be performed manually. Something
> like:
>
> name=$(basename $url)
> mkdir $name
> cd $name
> git init-db
> git remote add $url
> git pull $name
you could say "git remote add $name $url" here, having computed
$name already.
But you guessed what I was driving at right ;-).
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] git-remote
2007-01-06 1:59 ` Junio C Hamano
@ 2007-01-08 22:52 ` Carl Worth
0 siblings, 0 replies; 16+ messages in thread
From: Carl Worth @ 2007-01-08 22:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 2708 bytes --]
On Fri, 05 Jan 2007 17:59:52 -0800, Junio C Hamano wrote:
> > git init-db
> > git remote add $url
> > git pull $name
>
> you could say "git remote add $name $url" here, having computed
> $name already.
Though I guess clone would actually be doing the equivalent of:
git remote add origin $url
correct?
So that undercuts my argument a bit. If clone is always just using
"origin" for the remote that it creates then it's harder to justify
making "remote add" use part of the URL for the name. It would seem
convenient to be able to do:
git remote add git://hosting.org/$project/$maintainer1
git remote add git://hosting.org/$project/$maintainer2
but I guess that wouldn't help much if the project were organized
such that what's need is actually:
git remote add $maintainer1 git://hosting.org/~$maintainer1/$project
git remote add $maintainer2 git://hosting.org/~$maintainer2/$project
But the other piece is that clone does one thing more than setting up
a remote. It also creates a local branch "master" that is configured
with "remote" and "merge" entries. There's still no simple command
that sets this up that could be added to make the above list of steps
for a "manual clone" complete is there?
And by "simple" I mean something other than:
git repo-config branch.master.remote origin
git repo-config branch.master.merge refs/heads/master
It seems we're still missing a simple command that would create this
commonly desired arrangement. The only real input here is a local
branch name and a corresponding remote-tracking branch, (from which
the values for remote and merge could be determined). We've mentioned
before that "git checkout newbranch remote-tracking-branch" already
accepts those two pieces of information, so maybe we just want an
option there to create this extra configuration for further
tracking/merging.
-Carl
PS. It's probably too late, since "remote" already appears in
.git/remotes and in branch.*.remote entries in .git/config, but I do
have to say that "git remote add" looks really odd. The most natural
way to parse that is with "remote" as an adjective---so perhaps
interpreting this as a variant of "git add" that does something on the
remote side?
Previously, when I've wanted the functionality of what is now "remote
add" I've imagined it as a variant of "git clone" that would clone
"into" my existing repository (with a new "remote" name) rather than
creating a new repository. Or maybe this could be some new verb, (I'd
like something like "git track url [name]" perhaps. Though using a
verb would make it harder to add other actions beyond creation.
Anyway, there's some naming feedback, but like I said, it might be too
late to be used at all.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] git-remote
2007-01-03 21:40 [RFC] git-remote Junio C Hamano
` (2 preceding siblings ...)
2007-01-05 12:59 ` Santi Béjar
@ 2007-01-09 4:28 ` J. Bruce Fields
2007-01-09 5:48 ` Junio C Hamano
2007-01-09 5:50 ` Junio C Hamano
3 siblings, 2 replies; 16+ messages in thread
From: J. Bruce Fields @ 2007-01-09 4:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wed, Jan 03, 2007 at 01:40:56PM -0800, Junio C Hamano wrote:
> $ 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.
Nifty.
Would it make sense for "git add" to do the initial fetch as well?
That'd also help catch any typos in the URL early--the first time I used
this I mistyped the URL, then had to delete the configuration by hand
after I found the problem....
How about this as a man page?
--b.
Documentation: add git-remote man page
Add a preliminary man page for git-remote.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
---
Documentation/git-remote.txt | 76 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
new file mode 100644
index 0000000..7d6663e
--- /dev/null
+++ b/Documentation/git-remote.txt
@@ -0,0 +1,76 @@
+git-remote(1)
+============
+
+NAME
+----
+git-remote - manage set of tracked repositories
+
+
+SYNOPSIS
+--------
+[verse]
+'git-remote'
+'git-remote' add <name> <url>
+'git-remote' show <name>
+
+DESCRIPTION
+-----------
+
+Manage the set of repositories ("remotes") whose branches you track.
+
+With no arguments, shows a list of existing remotes.
+
+In the second form, adds a remote named <name> for the repository at
+<url>. The command `git fetch <name>` can then be used to create and
+update remote-tracking branches <name>/<branch>.
+
+In the third form, gives some information about the remote <name>.
+
+The remote configuration is achieved using the `remote.origin.url` and
+`remote.origin.fetch` configuration variables. (See
+gitlink:git-repo-config[1]).
+
+Examples
+--------
+
+Add a new remote, fetch, and check out a branch from it:
+
+------------
+$ git remote
+origin
+$ git branch -r
+origin/master
+$ git remote add linux-nfs git://linux-nfs.org/pub/nfs-2.6.git
+$ git remote
+linux-nfs
+origin
+$ git fetch
+* refs/remotes/linux-nfs/master: storing branch 'master' ...
+ commit: bf81b46
+$ git branch -r
+origin/master
+linux-nfs/master
+$ git checkout -b nfs linux-nfs/master
+...
+------------
+
+See Also
+--------
+gitlink:git-fetch[1]
+gitlink:git-branch[1]
+gitlink:git-repo-config[1]
+
+Author
+------
+Written by Junio Hamano
+
+
+Documentation
+--------------
+Documentation by J. Bruce Fields and the git-list <git@vger.kernel.org>.
+
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
--
1.4.4.4.g4083
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: [RFC] git-remote
2007-01-09 4:28 ` J. Bruce Fields
@ 2007-01-09 5:48 ` Junio C Hamano
2007-01-09 5:50 ` Junio C Hamano
1 sibling, 0 replies; 16+ messages in thread
From: Junio C Hamano @ 2007-01-09 5:48 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
"J. Bruce Fields" <bfields@fieldses.org> writes:
> How about this as a man page?
>
> --b.
>
> Documentation: add git-remote man page
Thanks.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] git-remote
2007-01-09 4:28 ` J. Bruce Fields
2007-01-09 5:48 ` Junio C Hamano
@ 2007-01-09 5:50 ` Junio C Hamano
2007-01-09 9:22 ` Andreas Ericsson
1 sibling, 1 reply; 16+ messages in thread
From: Junio C Hamano @ 2007-01-09 5:50 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
"J. Bruce Fields" <bfields@fieldses.org> writes:
> Would it make sense for "git add" to do the initial fetch as well?
It would be handy.
And perhaps we could make it the default but with a command line
override to help disconnected people.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC] git-remote
2007-01-09 5:50 ` Junio C Hamano
@ 2007-01-09 9:22 ` Andreas Ericsson
2007-01-10 18:13 ` J. Bruce Fields
0 siblings, 1 reply; 16+ messages in thread
From: Andreas Ericsson @ 2007-01-09 9:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: J. Bruce Fields, git
Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
>> Would it make sense for "git add" to do the initial fetch as well?
>
> It would be handy.
>
> And perhaps we could make it the default but with a command line
> override to help disconnected people.
>
I'd rather do it the other way around ("--fetch" switch) and if that
wasn't supplied, tell the user that he should now run
git fetch $whatever_name_was_supplied
The reason being it's easier to fetch afterwards than it is to undo the
fetch if you didn't mean to do it straight away. Judging by its other
uses, I also wouldn't expect the command to actually work over the network.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [RFC] git-remote
2007-01-09 9:22 ` Andreas Ericsson
@ 2007-01-10 18:13 ` J. Bruce Fields
0 siblings, 0 replies; 16+ messages in thread
From: J. Bruce Fields @ 2007-01-10 18:13 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
On Tue, Jan 09, 2007 at 10:22:53AM +0100, Andreas Ericsson wrote:
> Junio C Hamano wrote:
> >"J. Bruce Fields" <bfields@fieldses.org> writes:
> >
> >>Would it make sense for "git add" to do the initial fetch as well?
> >
> >It would be handy.
> >
> >And perhaps we could make it the default but with a command line
> >override to help disconnected people.
> >
>
> I'd rather do it the other way around ("--fetch" switch) and if that
> wasn't supplied, tell the user that he should now run
>
> git fetch $whatever_name_was_supplied
>
> The reason being it's easier to fetch afterwards than it is to undo the
> fetch if you didn't mean to do it straight away. Judging by its other
> uses, I also wouldn't expect the command to actually work over the network.
Actually, "git remote show" also seems to require the network, as it
does an ls-remote. That I found a little more surprising.
I don't think a user should be surprised that a command that takes a url
would require the network. And although I could imagine uses for "git
remote add" when disconnected, I'd imagine by far the most common uses
would be where the user also wants to examine a remote branch
immediately.
--b.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2007-01-10 18:13 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-01-03 21:40 [RFC] git-remote Junio C Hamano
2007-01-03 22:05 ` Jakub Narebski
2007-01-05 3:02 ` Shawn O. Pearce
2007-01-05 3:07 ` Junio C Hamano
2007-01-05 3:17 ` Shawn O. Pearce
2007-01-05 12:59 ` Santi Béjar
2007-01-05 13:53 ` Johannes Schindelin
2007-01-05 19:53 ` Santi Béjar
2007-01-05 21:08 ` Carl Worth
2007-01-06 1:59 ` Junio C Hamano
2007-01-08 22:52 ` Carl Worth
2007-01-09 4:28 ` J. Bruce Fields
2007-01-09 5:48 ` Junio C Hamano
2007-01-09 5:50 ` Junio C Hamano
2007-01-09 9:22 ` Andreas Ericsson
2007-01-10 18:13 ` J. Bruce Fields
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).