# git fetch workflow improvements 7 messages from 2008-02-09 to 2008-02-09. Participants: Reece Dunn, Johannes Schindelin, Mike Hommey. Thread: https://gitlist.dev/t/11985 ## Reece Dunn, 2008-02-09 10:57 Subject: git fetch workflow improvements Message-ID: <3f4fd2640802090257m9ab8e24l2a836abfd2ef6bf@mail.gmail.com> URL: https://gitlist.dev/e/3f4fd2640802090257m9ab8e24l2a836abfd2ef6bf%40mail.gmail.com ``` 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, 2008-02-09 13:20 Subject: Re: git fetch workflow improvements Message-ID: URL: https://gitlist.dev/e/alpine.LSU.1.00.0802091318080.11591%40racer.site In-Reply-To: <3f4fd2640802090257m9ab8e24l2a836abfd2ef6bf@mail.gmail.com> ``` 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 ``` ## Johannes Schindelin, 2008-02-09 13:22 Subject: Re: git fetch workflow improvements Message-ID: URL: https://gitlist.dev/e/alpine.LSU.1.00.0802091321110.11591%40racer.site In-Reply-To: ``` 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 ``` ## Mike Hommey, 2008-02-09 13:27 Subject: Re: git fetch workflow improvements Message-ID: <20080209132745.GA13997@glandium.org> URL: https://gitlist.dev/e/20080209132745.GA13997%40glandium.org In-Reply-To: ``` 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 ``` ## Reece Dunn, 2008-02-09 13:48 Subject: Re: git fetch workflow improvements Message-ID: <3f4fd2640802090548p3f3b7c95kbbe74662dfcbeba5@mail.gmail.com> URL: https://gitlist.dev/e/3f4fd2640802090548p3f3b7c95kbbe74662dfcbeba5%40mail.gmail.com In-Reply-To: ``` On 09/02/2008, 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. 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 ``` ## Johannes Schindelin, 2008-02-09 14:00 Subject: Re: git fetch workflow improvements Message-ID: URL: https://gitlist.dev/e/alpine.LSU.1.00.0802091357480.11591%40racer.site In-Reply-To: <20080209132745.GA13997@glandium.org> ``` 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.. 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..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.:: The list of remotes which are fetched by "git remote update ". 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, 2008-02-09 14:06 Subject: Re: git fetch workflow improvements Message-ID: <20080209140601.GA16239@glandium.org> URL: https://gitlist.dev/e/20080209140601.GA16239%40glandium.org In-Reply-To: ``` 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.. 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..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 ```