git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: git@vger.kernel.org
Subject: Re: [PATCH] Teach git-remote to update existing remotes by fetching from them
Date: Mon, 19 Feb 2007 14:21:01 +0100	[thread overview]
Message-ID: <erc846$bk7$1@sea.gmane.org> (raw)
In-Reply-To: 81b0412b0702190305j20cf2d10w8f75c4345ba0fc26@mail.gmail.com

Alex Riesen wrote:

> On 2/19/07, Shawn O. Pearce <spearce@spearce.org> wrote:
>> Junio C Hamano <junkio@cox.net> wrote:
>> > "Theodore Ts'o" <tytso@mit.edu> writes:
>> >
>> > > This allows users to use the command "git remote update" to update all
>> > > remotes that are being tracked in the repository.
>> >
>> > Sounds like a good idea.  Thanks.
>>
>> <personalwishlist>
>>
>> It would be nice to define "gang remotes".  For example I want to
>> be able to have:
>>
>>   `git fetch cs`  ==  `git fetch cs-one; git fetch cs-two`
>>   `git fetch jc`  ==  `git fetch origin; git fetch alt`
> 
> I was thinking about something very similar.
> 
>> Why?  Well, I often have multiple remotes setup to the *same*
>> repository depending on the SSH hostname I want to use to access
>> that repository.  This has a lot to do with the way my firewalls
>> are setup and where I'm physically connected at any given time.
> 
> For all the same reasons :)
> 
>> Yes, I really do have multiple remotes setup to the access the
>> same (remote) physical disk.  :)
>>
>> Possible syntax:
>>
>>         [remote "cs"]
>>                 remote = cs-one
>>                 remote = cs-two
>>         [remote "jc"]
>>                 remote = origin
>>                 remote = alt
>>
> 
> Or :
> 
>   [remote "jc"]
>     url = git://...
>     fetch = refs/heads/*:remotes/jc/*
>     remote ("include"? "next"?) = origin
> 
> (I mean: it can be allowed to mix url/fetch and remote).
> 
> And:
> 
>   [remote "jc"]
>     fail = all-fail
>     remote = origin
>     remote = backup
> 
> IOW: the fetch fails only if all fetches fail (with default
> being "fail = first").

Or just allow fetch remotes to have multiple URLs, and fetch from all/try to fetch starting from first.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

  reply	other threads:[~2007-02-19 13:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-19  4:00 [PATCH] Teach git-remote to update existing remotes by fetching from them Theodore Ts'o
2007-02-19  5:18 ` Junio C Hamano
2007-02-19  7:32   ` Shawn O. Pearce
2007-02-19 11:05     ` Alex Riesen
2007-02-19 13:21       ` Jakub Narebski [this message]
     [not found]         ` <20070219201111.GA3407@steel.home>
2007-02-20 15:24           ` Jakub Narebski
2007-02-19 12:52     ` Theodore Tso
2007-02-19 20:09       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='erc846$bk7$1@sea.gmane.org' \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).