{"thread":{"id":"11985","subject":"git fetch workflow improvements","startedAt":"2008-02-09T10:57:11Z","lastAt":"2008-02-09T14:06:01Z","messageCount":7,"participants":["Reece Dunn","Johannes Schindelin","Mike Hommey"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"68066","messageId":"3f4fd2640802090257m9ab8e24l2a836abfd2ef6bf@mail.gmail.com","threadId":"11985","inReplyTo":null,"subject":"git fetch workflow improvements","fromName":"Reece Dunn","fromEmail":"msclrhd@googlemail.com","sentAt":"2008-02-09T10:57:11Z","receivedAt":"2008-02-09T10:57:11Z","isPatch":false,"sender":{"key":"msclrhd@googlemail.com","avatar":null},"body":"Hi,\n\nI have some ideas on improvements I would like to make to git fetch. I\nam not familiar with the implementation details of builtin-fetch.c and\nfriends, and having a brief look at the implementation I am unsure how\nto proceed.\n\nThe ideas for improvements I have are:\n\n 1. When running `git fetch` on a bare repository that does not\nhave a remote called 'origin', fetch fails. I would like this to pick\nup the first remote entry in the config file.\n\n 2. When mirroring a repository such as the Linux kernel and its\nstable repositories in the same git repository, it would be useful to\nbe able to fetch the latest data from all the remotes that you are\ntracking in the config file. I envision this being done by running\n`git fetch -all`.\n\n 3. When fetching, if everything is up-to-date, display a message saying so.\n\n- Reece\n"},{"id":"68079","messageId":"alpine.LSU.1.00.0802091318080.11591@racer.site","threadId":"11985","inReplyTo":"3f4fd2640802090257m9ab8e24l2a836abfd2ef6bf@mail.gmail.com","subject":"Re: git fetch workflow improvements","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-09T13:20:29Z","receivedAt":"2008-02-09T13:20:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 9 Feb 2008, Reece Dunn wrote:\n\n> I have some ideas on improvements I would like to make to git fetch. I \n> am not familiar with the implementation details of builtin-fetch.c and \n> friends, and having a brief look at the implementation I am unsure how \n> to proceed.\n> \n> The ideas for improvements I have are:\n> \n> 1. When running `git fetch` on a bare repository that does not have \n> a remote called 'origin', fetch fails. I would like this to pick up the \n> first remote entry in the config file.\n\nI am opposed to that. If you want a default remote, then set the remote \n\"origin\". That is well established semantics, and you would only confuse \nyourself if all of a sudden you fetched from a remote that you erroneously \nadded at some stage.\n\n> 2. When mirroring a repository such as the Linux kernel and its \n> stable repositories in the same git repository, it would be useful to be \n> able to fetch the latest data from all the remotes that you are tracking \n> in the config file. I envision this being done by running `git fetch \n> -all`.\n\n$ git remote update\n\n> 3. When fetching, if everything is up-to-date, display a message \n> saying so.\n\nWe recently tried to unverbosify the transports. So I think this would be \na step back.\n\nCiao,\nDscho\n"},{"id":"68081","messageId":"alpine.LSU.1.00.0802091321110.11591@racer.site","threadId":"11985","inReplyTo":"alpine.LSU.1.00.0802091318080.11591@racer.site","subject":"Re: git fetch workflow improvements","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-09T13:22:34Z","receivedAt":"2008-02-09T13:22:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 9 Feb 2008, Johannes Schindelin wrote:\n\n> On Sat, 9 Feb 2008, Reece Dunn wrote:\n> \n> > 1. When running `git fetch` on a bare repository that does not \n> > have a remote called 'origin', fetch fails. I would like this to pick \n> > up the first remote entry in the config file.\n> \n> I am opposed to that. If you want a default remote, then set the remote \n> \"origin\". That is well established semantics, and you would only \n> confuse yourself if all of a sudden you fetched from a remote that you \n> erroneously added at some stage.\n\nOh and I completely forgot: if you have a bare repository, chances are \nthat it should fetch in mirror mode. You'd probably DWIM that, too, which \nwould make semantics even worse.\n\nCiao,\nDscho\n"},{"id":"68083","messageId":"20080209132745.GA13997@glandium.org","threadId":"11985","inReplyTo":"alpine.LSU.1.00.0802091318080.11591@racer.site","subject":"Re: git fetch workflow improvements","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-02-09T13:27:45Z","receivedAt":"2008-02-09T13:27:45Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Sat, Feb 09, 2008 at 01:20:29PM +0000, Johannes Schindelin wrote:\n> Hi,\n> \n> On Sat, 9 Feb 2008, Reece Dunn wrote:\n> \n> > I have some ideas on improvements I would like to make to git fetch. I \n> > am not familiar with the implementation details of builtin-fetch.c and \n> > friends, and having a brief look at the implementation I am unsure how \n> > to proceed.\n> > \n> > The ideas for improvements I have are:\n> > \n> > 1. When running `git fetch` on a bare repository that does not have \n> > a remote called 'origin', fetch fails. I would like this to pick up the \n> > first remote entry in the config file.\n> \n> I am opposed to that. If you want a default remote, then set the remote \n> \"origin\". That is well established semantics, and you would only confuse \n> yourself if all of a sudden you fetched from a remote that you erroneously \n> added at some stage.\n> \n> > 2. When mirroring a repository such as the Linux kernel and its \n> > stable repositories in the same git repository, it would be useful to be \n> > able to fetch the latest data from all the remotes that you are tracking \n> > in the config file. I envision this being done by running `git fetch \n> > -all`.\n> \n> $ git remote update\n\nBTW, is the following normal?\n\n$ git remote update origin\nRemote group origin does not exists.\n\n(there *is* an origin remote)\n\nMike\n"},{"id":"68085","messageId":"3f4fd2640802090548p3f3b7c95kbbe74662dfcbeba5@mail.gmail.com","threadId":"11985","inReplyTo":"alpine.LSU.1.00.0802091318080.11591@racer.site","subject":"Re: git fetch workflow improvements","fromName":"Reece Dunn","fromEmail":"msclrhd@googlemail.com","sentAt":"2008-02-09T13:48:35Z","receivedAt":"2008-02-09T13:48:35Z","isPatch":false,"sender":{"key":"msclrhd@googlemail.com","avatar":null},"body":"On 09/02/2008, Johannes Schindelin wrote:\n> Hi,\n>\n> On Sat, 9 Feb 2008, Reece Dunn wrote:\n>\n> > I have some ideas on improvements I would like to make to git fetch. I\n> > am not familiar with the implementation details of builtin-fetch.c and\n> > friends, and having a brief look at the implementation I am unsure how\n> > to proceed.\n> >\n> > The ideas for improvements I have are:\n> >\n> > 1. When running `git fetch` on a bare repository that does not have\n> > a remote called 'origin', fetch fails. I would like this to pick up the\n> > first remote entry in the config file.\n>\n> I am opposed to that. If you want a default remote, then set the remote\n> \"origin\". That is well established semantics, and you would only confuse\n> yourself if all of a sudden you fetched from a remote that you erroneously\n> added at some stage.\n\nOk. That makes sense. Doing `git remote update` will do what I want in\nthis case.\n\n> > 2. When mirroring a repository such as the Linux kernel and its\n> > stable repositories in the same git repository, it would be useful to be\n> > able to fetch the latest data from all the remotes that you are tracking\n> > in the config file. I envision this being done by running `git fetch\n> > -all`.\n>\n> $ git remote update\n\nThat does what I want. Thanks for the information.\n\n> > 3. When fetching, if everything is up-to-date, display a message\n> > saying so.\n>\n> We recently tried to unverbosify the transports. So I think this would be\n> a step back.\n\nSure. That makes sense.\n\n- Reece\n"},{"id":"68086","messageId":"alpine.LSU.1.00.0802091357480.11591@racer.site","threadId":"11985","inReplyTo":"20080209132745.GA13997@glandium.org","subject":"Re: git fetch workflow improvements","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-09T14:00:12Z","receivedAt":"2008-02-09T14:00:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 9 Feb 2008, Mike Hommey wrote:\n\n> On Sat, Feb 09, 2008 at 01:20:29PM +0000, Johannes Schindelin wrote:\n> \n> > $ git remote update\n> \n> BTW, is the following normal?\n> \n> $ git remote update origin\n> Remote group origin does not exists.\n> \n> (there *is* an origin remote)\n\nStraight from the man page:\n\n-- snip --\n'update'::\n\nFetch updates for a named set of remotes in the repository as defined by\nremotes.. If a named group is not specified on the command line,\nthe configuration parameter remotes.default will get used; if\nremotes.default is not defined, all remotes which do not have the\nconfiguration parameter remote..skipDefaultUpdate set to true will\nbe updated. (See linkgit:git-config[1]).\n-- snap --\n\nTo spare you the hassle from looking up the relevant section in \ngit-config.1:\n\n-- snip --\nremotes.::\n The list of remotes which are fetched by \"git remote update\n \". See linkgit:git-remote[1].\n-- snap --\n\nSo if you add a group to your config file, like\n\n\t[remotes]\n\t\torigin = origin kernelorg repoorcz\n\nyour\n\n\t$ git remote update origin\n\nwill succeed.\n\nHth,\nDscho\n"},{"id":"68087","messageId":"20080209140601.GA16239@glandium.org","threadId":"11985","inReplyTo":"alpine.LSU.1.00.0802091357480.11591@racer.site","subject":"Re: git fetch workflow improvements","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-02-09T14:06:01Z","receivedAt":"2008-02-09T14:06:01Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Sat, Feb 09, 2008 at 02:00:12PM +0000, Johannes Schindelin wrote:\n> Hi,\n> \n> On Sat, 9 Feb 2008, Mike Hommey wrote:\n> \n> > On Sat, Feb 09, 2008 at 01:20:29PM +0000, Johannes Schindelin wrote:\n> > \n> > > $ git remote update\n> > \n> > BTW, is the following normal?\n> > \n> > $ git remote update origin\n> > Remote group origin does not exists.\n> > \n> > (there *is* an origin remote)\n> \n> Straight from the man page:\n> \n> -- snip --\n> 'update'::\n> \n> Fetch updates for a named set of remotes in the repository as defined by\n> remotes.. If a named group is not specified on the command line,\n> the configuration parameter remotes.default will get used; if\n> remotes.default is not defined, all remotes which do not have the\n> configuration parameter remote..skipDefaultUpdate set to true will\n> be updated. (See linkgit:git-config[1]).\n> -- snap --\n\nI did read the manpage and I don't know why, but my eyes didn't want to\nsee the s in remote*s*. /me hides under a rock.\n\nMike\n"}]}