threads / discuss / 11985

git fetch workflow improvements

Subject: git fetch workflow improvements

## tl;dr

7 messages between Feb 9, 2008 and Feb 9, 2008.

replies: 6people: 3as markdown or json

Reece Dunn· Feb 9, 2008, 10:57 UTC · lore

Hi,

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.

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

    3.  When fetching, if everything is up-to-date, display a message saying so.

- Reece

Johannes Schindelin· Feb 9, 2008, 13:20 UTC · re: Reece Dunn · lore

Re: git fetch workflow improvements

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

Johannes Schindelin· Feb 9, 2008, 13:22 UTC · re: Johannes Schindelin · lore

Re: git fetch workflow improvements

Hi,

On Sat, 9 Feb 2008, Johannes Schindelin wrote:

Show 10 quoted lines

> On Sat, 9 Feb 2008, Reece Dunn wrote:
> 
> >     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.

Oh and I completely forgot: if you have a bare repository, chances are that it should fetch in mirror mode. You'd probably DWIM that, too, which would make semantics even worse.

Ciao, Dscho

Mike Hommey· Feb 9, 2008, 13:27 UTC · re: Johannes Schindelin · lore

Re: git fetch workflow improvements

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

Johannes Schindelin· Feb 9, 2008, 14:00 UTC · re: Mike Hommey · lore

Re: git fetch workflow improvements

Hi,

On Sat, 9 Feb 2008, Mike Hommey wrote:

Show 10 quoted lines

> On Sat, Feb 09, 2008 at 01:20:29PM +0000, Johannes Schindelin wrote:
> 
> > $ git remote update
> 
> BTW, is the following normal?
> 
> $ git remote update origin
> Remote group origin does not exists.
> 
> (there *is* an origin remote)

Straight from the man page:

-- snip -- 'update'::

Fetch updates for a named set of remotes in the repository as defined by remotes.<group>. If a named group is not specified on the command line, the configuration parameter remotes.default will get used; if remotes.default is not defined, all remotes which do not have the configuration parameter remote.<name>.skipDefaultUpdate set to true will be updated. (See linkgit:git-config[1]). -- snap --

To spare you the hassle from looking up the relevant section in git-config.1:

-- snip --
remotes.<group>::
        The list of remotes which are fetched by "git remote update
        <group>".  See linkgit:git-remote[1].
-- snap --

So if you add a group to your config file, like

	[remotes]
		origin = origin kernelorg repoorcz

your

	$ git remote update origin

will succeed.

Hth, Dscho

Mike Hommey· Feb 9, 2008, 14:06 UTC · re: Johannes Schindelin · lore

Re: git fetch workflow improvements

On Sat, Feb 09, 2008 at 02:00:12PM +0000, Johannes Schindelin wrote:

Show 27 quoted lines

> Hi,
> 
> On Sat, 9 Feb 2008, Mike Hommey wrote:
> 
> > On Sat, Feb 09, 2008 at 01:20:29PM +0000, Johannes Schindelin wrote:
> > 
> > > $ git remote update
> > 
> > BTW, is the following normal?
> > 
> > $ git remote update origin
> > Remote group origin does not exists.
> > 
> > (there *is* an origin remote)
> 
> Straight from the man page:
> 
> -- snip --
> 'update'::
> 
> Fetch updates for a named set of remotes in the repository as defined by
> remotes.<group>.  If a named group is not specified on the command line,
> the configuration parameter remotes.default will get used; if
> remotes.default is not defined, all remotes which do not have the
> configuration parameter remote.<name>.skipDefaultUpdate set to true will
> be updated.  (See linkgit:git-config[1]).
> -- snap --

I did read the manpage and I don't know why, but my eyes didn't want to see the s in remote*s*. /me hides under a rock.

Mike

Reece Dunn· Feb 9, 2008, 13:48 UTC · re: Johannes Schindelin · lore

Re: git fetch workflow improvements

On 09/02/2008, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

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

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

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

That does what I want. Thanks for the information.

Show 5 quoted lines

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