Re: git fetch workflow improvements

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 9, 2008, 13:20 UTC
Message-ID: <alpine.LSU.1.00.0802091318080.11591@racer.site>
In-Reply-To: <3f4fd2640802090257m9ab8e24l2a836abfd2ef6bf@mail.gmail.com>

Hi,

On Sat, 9 Feb 2008, Reece Dunn wrote:

Show 10 quoted lines

> 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.

Show 5 quoted lines

>     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.

Ciao, Dscho