From: Reece Dunn <msclrhd@googlemail.com>
Date: Sat, 09 Feb 2008 13:48:35 GMT
Subject: Re: git fetch workflow improvements
Message-ID: <3f4fd2640802090548p3f3b7c95kbbe74662dfcbeba5@mail.gmail.com>
In-Reply-To: <alpine.LSU.1.00.0802091318080.11591@racer.site>

On 09/02/2008, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 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.

Ok. That makes sense. Doing `git remote update` will do what I want in
this case.

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

That does what I want. Thanks for the information.

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

Sure. That makes sense.

- Reece