{"thread":{"id":"4239","subject":"Current Issues #3","startedAt":"2006-05-22T08:44:15Z","lastAt":"2006-05-23T21:58:15Z","messageCount":8,"participants":["Junio C Hamano","Linus Torvalds","Martin Waitz","Sean","Daniel Barkalow","Carl Worth","Shawn Pearce","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"20433","messageId":"7v8xoue9eo.fsf@assigned-by-dhcp.cox.net","threadId":"4239","inReplyTo":null,"subject":"Current Issues #3","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-22T08:44:15Z","receivedAt":"2006-05-22T08:44:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"[Third installment of the \"Issues\" series, but I've been half\n awake for the past week or so, and I suspect I have missed some\n topics that deserve further discussion.]\n\n* Per branch configuration\n\n The [section \"foo\"] configuration syntax update by Linus, and\n git-parse-remote update to use remote.stuff.{url,push,pull} by\n Johannes are now both in the \"master\". The stage is set to\n discuss what to actually do with per-branch configuration.\n\n We will use the [branch \"foo\"] section for configuration about\n local branch named \"foo\". I do not think there is any\n disagreement about this.\n\n The ideas floated so far (I am forgetting many of them\n perhaps):\n\n 1. \"upstream\" refers to the remote section to use when\n running \"git-{fetch,pull,push}\" while on that branch.\n\n\t[branch \"master\"]\n\t\tupstream = \"origin\"\n\n\t[remote \"origin\"]\n \turl = \"git://git.kernel.org/.../git.git\"\n\t\tfetch = refs/heads/master:refs/remotes/origin/master\n\n 2. \"url/fetch/push\" directly specifies what would usually be\n taken from a remote section by \"git-{fetch,pull,push}\"\n while on that branch.\n\n\t[branch \"foo\"]\n \turl = \"company.com.xz:myrepo\"\n\t\tfetch = refs/heads/master:refs/remotes/origin/master\n\t\tpush = refs/heads/master:refs/heads/origin\n\n* reflog\n\n I still haven't merged this series to \"next\" -- I do not have\n much against what the code does, but I am unconvinced if it is\n useful. Also objections raised on the list that this can be\n replaced by making sure that a repository that has hundreds of\n tags usable certainly have a point.\n"},{"id":"20438","messageId":"Pine.LNX.4.64.0605220216310.3697@g5.osdl.org","threadId":"4239","inReplyTo":"7v8xoue9eo.fsf@assigned-by-dhcp.cox.net","subject":"Re: Current Issues #3","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-22T10:18:02Z","receivedAt":"2006-05-22T10:18:02Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 22 May 2006, Junio C Hamano wrote:\n> \n> * Per branch configuration\n> \n> The [section \"foo\"] configuration syntax update by Linus, and\n> git-parse-remote update to use remote.stuff.{url,push,pull} by\n> Johannes are now both in the \"master\". The stage is set to\n> discuss what to actually do with per-branch configuration.\n> \n> We will use the [branch \"foo\"] section for configuration about\n> local branch named \"foo\". I do not think there is any\n> disagreement about this.\n> \n> The ideas floated so far (I am forgetting many of them\n> perhaps):\n> \n> 1. \"upstream\" refers to the remote section to use when\n> running \"git-{fetch,pull,push}\" while on that branch.\n> \n> \t[branch \"master\"]\n> \t\tupstream = \"origin\"\n> \n> \t[remote \"origin\"]\n> \turl = \"git://git.kernel.org/.../git.git\"\n> \t\tfetch = refs/heads/master:refs/remotes/origin/master\n> \n> 2. \"url/fetch/push\" directly specifies what would usually be\n> taken from a remote section by \"git-{fetch,pull,push}\"\n> while on that branch.\n> \n> \t[branch \"foo\"]\n> \turl = \"company.com.xz:myrepo\"\n> \t\tfetch = refs/heads/master:refs/remotes/origin/master\n> \t\tpush = refs/heads/master:refs/heads/origin\n\nI'd _much_ prefer (1) over (2).\n\nHowever, I wonder if we couldn't do even better. How about forgetting \nabout the \"branch\" vs \"remote\" thing, and instead splitting it into \n_three_: \"branch\", \"repository\" and \"remote branch\".\n\nSomething like\n\n\t[repo \"origin\"]\n\t\turl = \"git://git.kernel.org/.../git.git\"\n\n\t[repo \"gitk\"]\n\t\turl = \"git://git.kernel.org/.../gitk.git\"\n\nto describe two remote repositories (and NOTE! No branch descriptions \nwithin those. We're just describing the actual repository, so we might \nhave things like \"readonly\" to indicate that we can't push to them, but if \nwe do things like that, they would be \"repo-wide\" things that we \ndescribe for that repository),\n\nThen, we can describe remote branches within those repositories:\n\n\t[remote \"origin/master\"]\n\t\trepo = origin\n\t\tbranch = master\n\n\t[remote \"origin/next\"]\n\t\trepo = origin\n\t\tbranch = next\n\n\t[remote \"origin/pu\"]\n\t\trepo = origin\n\t\tbranch = pu\n\n\t[remote \"gitk/master\"]\n\t\trepo = gitk\n\t\tbranch = master\n\nnow, here we're describing two things: the name of the remote is what we \nwill then use for the \".git/remotes/\" thing to remember the last \nvalue, and we're describing where to get that data (which repo, and which \nbranch).\n\nNOTE! In the example above, I made the name of the remote always match the \n/ format, but that would be just a convention. You could do\n\n\t[remote \"linus\"]\n\t\trepo = kernel\n\t\tbranch = master\n\nto describe the \"linus\" remote as the master branch of the \"kernel\" \nrepository.\n\nFinally, local branches:\n\n\t[branch \"master\"]\n\t\tsource = origin/master\n\n\t[branch \"origin\"]\n\t\treadonly\n\t\tsource = origin/master\n\n\t[branch \"next\"]\n\t\treadonly\n\t\tsource = origin/next\n\n\t[branch \"pu\"]\n\t\treadonly\n\t\trebase\n\t\tsource = origin/pu\n\n\t[branch \"gitk\"]\n\t\treadonly\n\t\tsource = gitk/master\n\nThis marks the things that just _track_ somebody elses branch as being \nreadonly (so \"master\" and \"origin\" are really different: they're both \nbranches, but one of them just tracks remotes/origin/master, while the \nother one can be committed to), and \"pu\" has been marked as not only being \nread-only, it also re-bases to its source.\n\nI dunno. Does this sound too verbose and abstract?\n\nNormally, you'd not have a lot of these. For example, for somebody who \nfollows the kernel, you'd literally just have\n\n\t[branch \"master\"]\n\t\tsource = linus\n\n\t[remote \"linus\"]\n\t\trepo = kernel\n\t\tbranch = master\n\n\t[repo \"kernel\"]\n\t\turl = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6\n\nand you'd be done. The above would describe both the local \"master\" branch \nand the \"remotes/linus\" head, and give the relationship between them.\n\nThe git repo is actually much more complex, especially if you want to \ntrack all of the different branches Junio has, and if you want to also \ntrack the branches Paul has to gitk.\n\nBut with the above, you can fairly naturally do:\n\n - \"git pull\" \n\n\tNo arguments. fetch the remote described by the current branch, \n\tand merge into current branch (we might decide to fetch all the \n\tremotes associated with that repo, just because once we do this, \n\twe might as well, but that's not that important to the end \n\tresult).\n\n - \"git pull \"\n\n\tfetch all remotes that use . IFF the current branch is \n\tmatched to one of those remotes, merge the changes into the \n\tcurrent branch. But if you happened to be on another unrelated \n\tbranch, nothing happens aside from the fetch.\n\n - \"git pull \"\n\n\tfetch just the named remote. IFF that remote is also the remote \n\tfor the current branch, do merge it into current. Again, we \n\t_might_ decide to just do the whole repo.\n\n - \"git pull \"\n\n\tfetch the named branch from the named repository and merge it into \n\tcurrent (no ifs, buts or maybes - now we've basically overridden \n\tthe default relationships, so now the is just a pure \n\tshorthand for the location of the repository)\n\n - \"git pull :\"\n\n\tsame as now. fetch into , and merge it into the \n\tcurrent branch (again, we've overridden any default relationships).\n\nbut maybe this is overdesigned. Comments?\n\n\t\t\tLinus\n"},{"id":"20439","messageId":"20060522102029.GE12810@admingilde.org","threadId":"4239","inReplyTo":"7v8xoue9eo.fsf@assigned-by-dhcp.cox.net","subject":"Re: Current Issues #3","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2006-05-22T10:20:29Z","receivedAt":"2006-05-22T10:20:29Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Mon, May 22, 2006 at 01:44:15AM -0700, Junio C Hamano wrote:\n> 1. \"upstream\" refers to the remote section to use when\n> running \"git-{fetch,pull,push}\" while on that branch.\n> \n> \t[branch \"master\"]\n> \t\tupstream = \"origin\"\n\nwhat do you do for [branch \"next\"] here?\n\nDoes it make sense to regard all refs/remotes/*/ as\nupstream and merge these into the current branch when pulling?\n\nPerhaps a pull could even merge all newly fetched remote heads\ninto the corresponding branch, but for that we'd need to be\nable to merge without using the working dir.\n\n-- \nMartin Waitz\n"},{"id":"20441","messageId":"BAYC1-PASMTP11A8D53B4DD4B29078F810AE9A0@CEZ.ICE","threadId":"4239","inReplyTo":"Pine.LNX.4.64.0605220216310.3697@g5.osdl.org","subject":"Re: Current Issues #3","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-22T11:19:29Z","receivedAt":"2006-05-22T11:19:29Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Mon, 22 May 2006 03:18:02 -0700 (PDT)\nLinus Torvalds wrote:\n\n> [...]\n> \n> but maybe this is overdesigned. Comments?\n\n\nIt all looks good, especially your description of the git pull variations\nwhich seem more natural than what exists now.\n\nThe only minor comment i'd make is that we shouldn't mix so many different\nnames for the same thing. In your example you have \"remote\" (singular)\nsections with branch sections that contain \"source\" keys which map to those\nremote sections, both corresponding to \"refs/remotes\" (plural).\n\nThere doesn't seem to be any need to stick with \"source\" as a key, so :\n\n[remote \"origin/master\"]\n\trepo = origin\n\tbranch = master\n\n[branch \"master\"]\n\tremote = \"origin/master\"\n\nSean\n"},{"id":"20479","messageId":"Pine.LNX.4.64.0605221738090.6713@iabervon.org","threadId":"4239","inReplyTo":"7v8xoue9eo.fsf@assigned-by-dhcp.cox.net","subject":"Re: Current Issues #3","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-05-22T21:54:28Z","receivedAt":"2006-05-22T21:54:28Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 22 May 2006, Junio C Hamano wrote:\n\n> * reflog\n> \n> I still haven't merged this series to \"next\" -- I do not have\n> much against what the code does, but I am unconvinced if it is\n> useful. Also objections raised on the list that this can be\n> replaced by making sure that a repository that has hundreds of\n> tags usable certainly have a point.\n\nI think it would make gitweb's summary view clearer, and Linus seemed \ninterested in being able to look up what happened in the fast forward \nwhich was the first of several merges in a day.\n\nIt could be replaced by a repository with hundreds of machine-readable \ntags with code to parse dates into queries for suitable tags. But I don't \nthink there's an advantage to using the tag mechanism here, because you \nnever want to look the history up by exactly which history it is (the \nthing that a tag ref is good for); you'll be looking for whatever reflog \nitem is the newest not after a specified time, where the specified time is \nalmost never a time that a reflog item was created.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"20481","messageId":"87psi5pvkr.wl%cworth@cworth.org","threadId":"4239","inReplyTo":"Pine.LNX.4.64.0605221738090.6713@iabervon.org","subject":"Re: Current Issues #3","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-05-22T22:02:12Z","receivedAt":"2006-05-22T22:02:12Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Mon, 22 May 2006 17:54:28 -0400 (EDT), Daniel Barkalow wrote:\n> On Mon, 22 May 2006, Junio C Hamano wrote:\n> \n> > * reflog\n\nAm I the only one that read that as re-flog rather than ref-log the\nfirst time?\n\n-Carl\n"},{"id":"20490","messageId":"20060522231257.GA21124@spearce.org","threadId":"4239","inReplyTo":"Pine.LNX.4.64.0605221738090.6713@iabervon.org","subject":"Re: Current Issues #3","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-05-22T23:12:57Z","receivedAt":"2006-05-22T23:12:57Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Daniel Barkalow wrote:\n> On Mon, 22 May 2006, Junio C Hamano wrote:\n> \n> > * reflog\n> > \n> > I still haven't merged this series to \"next\" -- I do not have\n> > much against what the code does, but I am unconvinced if it is\n> > useful. Also objections raised on the list that this can be\n> > replaced by making sure that a repository that has hundreds of\n> > tags usable certainly have a point.\n> \n> I think it would make gitweb's summary view clearer, and Linus seemed \n> interested in being able to look up what happened in the fast forward \n> which was the first of several merges in a day.\n> \n> It could be replaced by a repository with hundreds of machine-readable \n> tags with code to parse dates into queries for suitable tags. But I don't \n> think there's an advantage to using the tag mechanism here, because you \n> never want to look the history up by exactly which history it is (the \n> thing that a tag ref is good for); you'll be looking for whatever reflog \n> item is the newest not after a specified time, where the specified time is \n> almost never a time that a reflog item was created.\n\nThe thing is this might also be easily represented as a structure\nof tags; for example:\n\n\trefs/logs/heads//// :::\n\nwhere the tag is a tag of the commit which was valid in that ref\nat that time. Searching for an entry \"around a particular time\"\nisn't that much more difficult than parsing a file, you just have\nto walk backwards through the sorted directory listings then read\nthe tag object which matches; that tag object will point at the\ntree/commit/tag which is was in that ref..\n\nWhat's ugly about this is simply the disk storage: a ref file is an\nexpensive thing (relatively speaking) on most UNIX file systems due\nto the inode overhead. If this was stored in a more compact format\n(such as a GIT tree) then this would cost very little.\n\nSo the alternative that I have been mentaly kicking around for\nthe past two days is storing the GIT_DIR/refs directory within a\nstandard GIT tree. This of course would need to be an option that\ngets enabled by the user as currently most tools expect the refs\ndirectory to actually be a directory, not a tree. The advantage here\nis that unlike proposed reflog it is a compact ref representation\nwhich could be used by other features, such as tagging a GIT\ncommit with the unique name of the same change from another SCM.\nOr tagging your repository on every automated build, which runs\nonce every 5 minutes.\n\n-- \nShawn.\n"},{"id":"20587","messageId":"e500hd$vpr$1@sea.gmane.org","threadId":"4239","inReplyTo":"Pine.LNX.4.64.0605220216310.3697@g5.osdl.org","subject":"Re: Current Issues #3","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-05-23T21:58:15Z","receivedAt":"2006-05-23T21:58:15Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n[...]\n> But with the above, you can fairly naturally do:\n> \n> - \"git pull\" \n> \n> No arguments. fetch the remote described by the current branch, \n> and merge into current branch (we might decide to fetch all the \n> remotes associated with that repo, just because once we do this, \n> we might as well, but that's not that important to the end \n> result).\n> \n> - \"git pull \"\n (i.e. re-clone)\n> fetch all remotes that use . IFF the current branch is \n> matched to one of those remotes, merge the changes into the \n> current branch. But if you happened to be on another unrelated \n> branch, nothing happens aside from the fetch.\n> \n> - \"git pull \"\n> \n> fetch just the named remote. IFF that remote is also the remote \n> for the current branch, do merge it into current. Again, we \n> _might_ decide to just do the whole repo.\n> \n> - \"git pull \"\n> \n> fetch the named branch from the named repository and merge it into \n> current (no ifs, buts or maybes - now we've basically overridden \n> the default relationships, so now the is just a pure \n> shorthand for the location of the repository)\n\nFetch into curret branch, or specified by branch configuration, then current\nif unspecified?\n\n> - \"git pull :\"\n> \n> same as now. fetch into , and merge it into the \n> current branch (again, we've overridden any default relationships).\n> \n> but maybe this is overdesigned. Comments?\n\nIt all means that within annd names should be unique\n(to know if we use \"git pull \" or \"git pull \").\n\nPerhaps it would be nice to have\n\n - \"git pull *:\"\n - \"git pull :*\"\n - \"git pull *:*\"\nand\n - \"git pull ::\"\n\nas easier to remember options. Of course what is the remote branch related\nto , and what is local branch related to would be in\nbranch/remotes/repos configuration.\n\nBTW. what about --use-separate-remotes option support?\n\n-- \nJakub Narebski\nWarsaw, Poland\n"}]}