Re: git fetch workflow improvements
- From
Mike Hommey <mh@glandium.org>
- Date
- Feb 9, 2008, 13:27 UTC
- Message-ID
- <20080209132745.GA13997@glandium.org>
- In-Reply-To
- <alpine.LSU.1.00.0802091318080.11591@racer.site>
On Sat, Feb 09, 2008 at 01:20:29PM +0000, Johannes Schindelin wrote:
Show 27 quoted lines
> Hi, > > On Sat, 9 Feb 2008, Reece Dunn wrote: > > > I have some ideas on improvements I would like to make to git fetch. I > > am not familiar with the implementation details of builtin-fetch.c and > > friends, and having a brief look at the implementation I am unsure how > > to proceed. > > > > The ideas for improvements I have are: > > > > 1. When running `git fetch` on a bare repository that does not have > > a remote called 'origin', fetch fails. I would like this to pick up the > > first remote entry in the config file. > > I am opposed to that. If you want a default remote, then set the remote > "origin". That is well established semantics, and you would only confuse > yourself if all of a sudden you fetched from a remote that you erroneously > added at some stage. > > > 2. When mirroring a repository such as the Linux kernel and its > > stable repositories in the same git repository, it would be useful to be > > able to fetch the latest data from all the remotes that you are tracking > > in the config file. I envision this being done by running `git fetch > > -all`. > > $ git remote update
BTW, is the following normal?
$ git remote update origin Remote group origin does not exists.
(there *is* an origin remote)
Mike