Re: git fetch workflow improvements

> 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

> >     3.  When fetching, if everything is up-to-date, display a message
> > saying so.
>
> We recently tried to unverbosify the transports.  So I think this would be
> a step back.