git fetch workflow improvements

git fetch workflow improvements

[Reece Dunn]

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

Re: git fetch workflow improvements

[Johannes Schindelin]

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.

Ciao,
Dscho

Re: git fetch workflow improvements

[Johannes Schindelin]

Hi,

On Sat, 9 Feb 2008, Johannes Schindelin wrote:

> 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

Re: git fetch workflow improvements

[Mike Hommey]

On Sat, Feb 09, 2008 at 01:20:29PM +0000, Johannes Schindelin 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.
> 
> >     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

Re: git fetch workflow improvements

[Johannes Schindelin]

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

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

Re: git fetch workflow improvements

[Mike Hommey]

On Sat, Feb 09, 2008 at 02:00:12PM +0000, Johannes Schindelin wrote:
> 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

Re: git fetch workflow improvements

[Reece Dunn]

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