{"thread":{"id":"3765","subject":"Default remote branch for local branch","startedAt":"2006-04-01T01:48:18Z","lastAt":"2006-04-14T18:26:43Z","messageCount":15,"participants":["Pavel Roskin","Junio C Hamano","Jakub Narebski","Josef Weidendorfer","Andreas Ericsson","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"18190","messageId":"1143856098.3555.48.camel@dv","threadId":"3765","inReplyTo":null,"subject":"Default remote branch for local branch","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-04-01T01:48:18Z","receivedAt":"2006-04-01T01:48:18Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello!\n\nThis is not a ready-to-use proposal, but I think my message can prompt\nuseful changes in GIT or in the \"porcelain\".\n\nLet's see how remote changes end up in the head branch of the local\nrepository (sorry for possible mistakes in terminology):\n\nbranch in          \"remote\"              local              index,\na remote  -------> branch       -------> branch     ------> tree\nrepository         (e.g. origin)         (e.g. master)\n\nBrought in sync by:\n           fetch                 merge              checkout\n\nRelationship stored in:\n          .git/remotes           nowhere!!!         .git/HEAD\n\nIf I fetch a remote branch, git knows where to get changes.  If I change\nthe current branch, git remembers that.  But git doesn't remember the\nrelationship between branches mirroring the remote branches and branches\nused for local development.\n\nThere are situations when I want to work for a significant time on a\ncertain branch.   Significant time means that changes are made by\nothers, and I'm supposed to integrate them and make more changes.  Yet I\nmay want to take advantage of some patches from another team that uses\nthe other repository.\n\nI want GIT and porcelains work the same way if I'm working with\nrepository 1 or repository 2.  As it stands now, git gives preferential\ntreatment to the \"origin\" branch.  Whatever branch I'm on, \"git-pull\"\nwill pull from \"origin\".  I believe the special role of the \"origin\"\nbranch should be reduced to cg-clone and similar commands.\n\nI think it would be convenient to have git remember the remote branch\nfor the given local branch.  git should know that if HEAD points to\n\"local-B\", \"git-fetch\" should fetch from \"remote-B\", not from \"origin\".\n\nTo implement this, git would have to implement attributes for local\nbranches (other ideas are welcome).  Currently, there are no attributes\nfor local branches other than the top SHA1 in .git/refs/heads/\n\nOnce at the topic of branch attributes, let's see what else could be\nuseful?  I think that would be the creator of the branch and the comment\n(e.g. \"this is for tested commits only, to be merged tomorrow\" etc).\nWhere can this data be stored?  Probably in blobs pointed to by refs in\ne.g. .git/refs/branch-data/ or just in plain files e.g.\nunder .git/branch-data/\n\nI know, it sounds like a lot of work to save a few keystrokes.  But I\nthink it may be worth it.  Working on different branches should have the\nsame \"look and feel\".  Otherwise, git would repeat a design error of\nCVS, where the head branch was given preference e.g. for date based\nupdates.\n\nI'm sorry, reading this mailing list is beyond my capabilities, so\ncertain overlaps with other postings may be expected, unless I'm\nsuggesting something totally off-base :-)\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"18191","messageId":"7vodzmngfp.fsf@assigned-by-dhcp.cox.net","threadId":"3765","inReplyTo":"1143856098.3555.48.camel@dv","subject":"Re: Default remote branch for local branch","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-01T03:05:46Z","receivedAt":"2006-04-01T03:05:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pavel Roskin <proski@gnu.org> writes:\n\n> This is not a ready-to-use proposal, but I think my message can prompt\n> useful changes in GIT or in the \"porcelain\".\n>...\n> I think it would be convenient to have git remember the remote branch\n> for the given local branch.  git should know that if HEAD points to\n> \"local-B\", \"git-fetch\" should fetch from \"remote-B\", not from \"origin\".\n\nI am in favor of the general direction this is going.  Something\nlike this was mentioned on the list in the past twice (I think\nJohannes was involved in the discussion but I do not remember\nthe details offhand).\n\nMy understanding is that Cogito uses $GIT_DIR/branches/$name\nfile as a configuration file per branch - currently it only\nrecords which remote repository's what remote branch the local\nbranch $name interfaces with.\n\nThe $GIT_DIR/remotes/$name file is to describe each remote\nrepository, and it _wants_ to be able to describe all the\nbranches we are interested in, primarily because uploading and\ndownloading multiple, related heads at once is more efficient.\nHow remote branches are kept track of with the local tracking\nbranch, and how remote branches are updated from the local\nbranch heads, are described by Push/Pull lines there.\n\nAs you pointed out, we do not have a convenient way to tell git\nwhere you typically merge things from per local branch.  There\nare different patterns I've seen:\n\n - Promiscous.  For example, \"master\" branch of Linus repository\n   pulls from many subsystem maintainers.  Linus could have one\n   \"remotes\" file per subsystem maintainer he often pulls from\n   (and \"for-linus\" branch name in each remote repository tends\n   to stay the same), and unlike the rest of us he does not seem\n   to pull into many local branches.  The current \"remotes\"\n   setup is really optimized for this mode of usage (you can use\n   \"remotes\" without having local tracking branches).\n\n - Merging topic branches into \"master\" (or \"release\") branch\n   and \"next\" (or \"testing\") branch -- inside local repository.\n\n - CVS-like remote tracking.  A single \"primary\" remote branch\n   is tracked using local \"origin\", merged into local \"master\"\n   and pushed back to the remote.  Both Cogito-like branches/\n   setup and having a single $GIT_DIR/remotes/origin file with\n   single Push/Pull line would work equally well.\n\n - Multiple subsystem maintainer trees tracked in the same local\n   repository.  Most generally, two local branches per each\n   remote head can be used (one tracking branch to fetch into,\n   another to build your changes based on it).  Alternatively,\n   you can use one local branch per each remote head without\n   using any tracking branch.\n\nYour proposal to give default branch to pull from per the local\nbranch would help only the last case.  The first one you do not\nswitch between local branches at all and pull from many\ndifferent places; the second is to merge from different topic\nbranches from time to time and does not benefit from fixed\nconfiguration; the third does not even need configuration.\n\nMaybe you would want something like this.\n\nIn $GIT_DIR/config:\n\n\t[pull]\n\torigin = linus for master\n        origin = irq-pio of libata for ata-irq-pio\n        origin = pata-drivers of libata for ata-pata\n\nIn $GIT_DIR/remotes/linus:\n\n\tURL: git://git.kernel.org/.../torvalds/linux-2.6.git\n\tPull: refs/heads/master:refs/heads/linus\n\nIn $GIT_DIR/remotes/libata\n\tURL: git://git.kernel.org/.../jgarzik/libata-dev.git\n\tPull: refs/heads/irq-pio:refs/remotes/libata/irq-pio\n\tPull: refs/heads/pata-drivers:refs/remotes/libata/pata-drivers\n\nThis is to maintain three local branches: master, ata-irq-pio\nand ata-pata.\n\nYou are obviously interested in the mainline Linus kernel, so\nwhile you are on your \"master\" branch, we will look for\n\"pull.origin .* for master\" and find out you would want\nremotes/linus file to be used.  His \"master\" is copied to your\nlocal \"linus\" branch, and merged into your \"master\" branch.\n\n\t$ git pull\n\nbecomes equivalent to:\n\n        $ git pull linus\n\nYou are also interested in the libata work by Jeff, and while\nyou are on your ata-pata branch\n\n\t$ git pull\n\nbecomes roughly equivalent to:\n\n\t$ git pull libata pata-drivers\n\nWhile we are on the topic, it _might_ be worthwhile to think\nabout revamping the syntax of $GIT_DIR/remotes file, maybe even\nbreaking backward compatibility.  The Pull: lines can be\nindependently specified which gives flexibility, but I suspect\nlocal tracking branches from the same remote tend to live in the\nsame place; IOW, you would probably not do something like:\n\n\tURL: git://git.kernel.org/.../jgarzik/libata-dev.git\n\tPull: refs/heads/irq-pio:refs/remotes/libata/irq-pio\n\tPull: refs/heads/pata-drivers:refs/heads/pata-drivers\n\nin practice.\n"},{"id":"18195","messageId":"1143865123.14465.26.camel@dv","threadId":"3765","inReplyTo":"7vodzmngfp.fsf@assigned-by-dhcp.cox.net","subject":"Re: Default remote branch for local branch","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-04-01T04:18:43Z","receivedAt":"2006-04-01T04:18:43Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello, Junio!\n\nOn Fri, 2006-03-31 at 19:05 -0800, Junio C Hamano wrote:\n>  - Multiple subsystem maintainer trees tracked in the same local\n>    repository.  Most generally, two local branches per each\n>    remote head can be used (one tracking branch to fetch into,\n>    another to build your changes based on it).  Alternatively,\n>    you can use one local branch per each remote head without\n>    using any tracking branch.\n> \n> Your proposal to give default branch to pull from per the local\n> branch would help only the last case.\n\nExactly.  I tried to track the main Linus repository and Jeff Garzik's\nnetdev in one place.  Then I discovered that my repository if full of\nunintended merges made by \"stg pull\".\n\n> The first one you do not\n> switch between local branches at all and pull from many\n> different places; the second is to merge from different topic\n> branches from time to time and does not benefit from fixed\n> configuration; the third does not even need configuration.\n> \n> Maybe you would want something like this.\n>\n> In $GIT_DIR/config:\n> \n> \t[pull]\n> \torigin = linus for master\n>         origin = irq-pio of libata for ata-irq-pio\n>         origin = pata-drivers of libata for ata-pata\n\nFirst of all, using \"origin\" on every line carries to little\ninformation.\n\nSecondly, I think the relationship should be between a local development\nbranch and a local tracking branch.  After all, all remote data is\nplaced on a local tracking branch first.  It's better not to jump over\nlayers of abstraction.  Suppose I want to update \"masterB\".  I tell git\nto sync \"originB\" first.  git already has rules what to do if it should\nsync \"originB\".  Let's not supersede those rules.\n\nI would write the config like this:\n\n[branch-upstream]\nmaster = linus\nata-irq-pio = irq-pio\nata-pata = pata-drivers\n\n> While we are on the topic, it _might_ be worthwhile to think\n> about revamping the syntax of $GIT_DIR/remotes file, maybe even\n> breaking backward compatibility.  The Pull: lines can be\n> independently specified which gives flexibility, but I suspect\n> local tracking branches from the same remote tend to live in the\n> same place; IOW, you would probably not do something like:\n> \n> \tURL: git://git.kernel.org/.../jgarzik/libata-dev.git\n> \tPull: refs/heads/irq-pio:refs/remotes/libata/irq-pio\n> \tPull: refs/heads/pata-drivers:refs/heads/pata-drivers\n> \n> in practice.\n\nSorry, I don't understand this part.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"18197","messageId":"e0l3l0$v4e$1@sea.gmane.org","threadId":"3765","inReplyTo":"1143856098.3555.48.camel@dv","subject":"Re: Default remote branch for local branch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-01T05:38:44Z","receivedAt":"2006-04-01T05:38:44Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Pavel Roskin wrote:\n\n> I'm sorry, reading this mailing list is beyond my capabilities, so\n> certain overlaps with other postings may be expected, unless I'm\n> suggesting something totally off-base :-)\n\nYou might want to read \"Efficient cloning\" thread where\n--use-separate-remote and --reference options were introduced:\n  http://marc.theaimsgroup.com/?l=git&m=114280442802681&w=2\n  http://www.gelato.unsw.edu.au/archives/git/0603/18113.html\n  http://thread.gmane.org/gmane.comp.version-control.git/17724\nand which had discussion on similar subjects (somewhere).\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"18200","messageId":"e0mlvh$48r$1@sea.gmane.org","threadId":"3765","inReplyTo":"e0l3l0$v4e$1@sea.gmane.org","subject":"Re: Default remote branch for local branch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-01T19:57:42Z","receivedAt":"2006-04-01T19:57:42Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"> You might want to read \"Efficient cloning\" thread where\n> --use-separate-remote and --reference options were introduced:\n>   http://marc.theaimsgroup.com/?l=git&m=114280442802681&w=2\n>   http://www.gelato.unsw.edu.au/archives/git/0603/18113.html\n>   http://thread.gmane.org/gmane.comp.version-control.git/17724\n> and which had discussion on similar subjects (somewhere).\n\nSee also\n  Message-ID: <200603011814.43573.Josef.Weidendorfer@gmx.de>\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"18221","messageId":"200604021817.30222.Josef.Weidendorfer@gmx.de","threadId":"3765","inReplyTo":"1143865123.14465.26.camel@dv","subject":"Re: Default remote branch for local branch","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-04-02T16:17:29Z","receivedAt":"2006-04-02T16:17:29Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Saturday 01 April 2006 06:18, Pavel Roskin wrote:\n> On Fri, 2006-03-31 at 19:05 -0800, Junio C Hamano wrote:\n> > Maybe you would want something like this.\n> >\n> > In $GIT_DIR/config:\n> > \n> > \t[pull]\n> > \torigin = linus for master\n> >         origin = irq-pio of libata for ata-irq-pio\n> >         origin = pata-drivers of libata for ata-pata\n\nLet me try to understand this: the general idea is that\n\n  pull.origin = [<refspec> of] <remote> for <branch>\n\nspecifies the default action of git-pull if we are on <branch>, ie.\na \"git pull\" then runs \"git pull <remote> [<refspec>]\".\n\nSo the example above, if .git/remotes/linus would contain two\nrefspecs, and you are on the branch of the 2nd refspec, it would\ndo the wrong thing: merge the 1st refspec with current branch.\nSo I think this is not useful, and if we use above syntax, we\nshould make the refspec mandatory.\n\nHowever. I think a syntax mentioning only 2 local branches is better:\n\n  pull.origin = <local upstream for branch> for <branch>\n\nPerhaps I have misunderstood the proposal?\n\n> First of all, using \"origin\" on every line carries to little\n> information.\n\n\"origin\" is part of the case-insensitive alphanum key, which is the same\nfor all config values in Junio's proposal. Especially, you can\nnot use it for head names. So this is fine.\n\nPerhaps we could make a shorther alternative form for the above where\nthe key part has not to be specified on every line with a rule like\n\n  if the line does not match /^\\S+=\"/, the full line is the value\n\nThen, above could be written as\n\n  [pull.origin]\n  linus for master\n  irq-pio of libata for ata-irq-pio\n  pata-drivers of libata for ata-pata\n\nHowever, that's only syntactical sugar.\n \n> Secondly, I think the relationship should be between a local development\n> branch and a local tracking branch.\n\nAgree.\nIt is also useful to specify this relation if the upstream is purely a\nlocal branch, e.g. when branching off a local branch, and you want to\npull in changes from the local upstream.\n\nThis works automatically if git-pull only does upstream fetching if\nthere is a remote branch associated. The default action of git-fetch\nsimilar could be \"fetch the upstream branch, if that tracks a remote\nbranch\", using the same configuration.\n\n> After all, all remote data is \n> placed on a local tracking branch first.  It's better not to jump over\n> layers of abstraction.  Suppose I want to update \"masterB\".  I tell git\n> to sync \"originB\" first.  git already has rules what to do if it should\n> sync \"originB\".  Let's not supersede those rules.\n\nJunio's proposal has the advantage that you do not have to search in all\nfiles in .git/remotes (and even .git/branches) for the remote branch that\nmaps to a given local branch.\nBut that is not the big issue.\n\n> I would write the config like this:\n> \n> [branch-upstream]\n> master = linus\n> ata-irq-pio = irq-pio\n> ata-pata = pata-drivers\n\nThat is not working, as said above. But with above syntax extension,\nwith s/=/for/ it would be fine.\n\nIt would be nice to also support the topic branches, ie. to be able\nto specify all topic branches for a branch, and make \"git-pull\" default\nto an octopus merge of the topic branches.\nHowever, \"git-pull\" can not distinguish between \"merge upstream\" and\n\"merge topic branches\". Yet, specifying multiple default branches should\nbe possible.\n\n> > While we are on the topic, it _might_ be worthwhile to think\n> > about revamping the syntax of $GIT_DIR/remotes file, maybe even\n> > breaking backward compatibility.  The Pull: lines can be\n> > independently specified which gives flexibility, but I suspect\n> > local tracking branches from the same remote tend to live in the\n> > same place; IOW, you would probably not do something like:\n> > \n> > \tURL: git://git.kernel.org/.../jgarzik/libata-dev.git\n> > \tPull: refs/heads/irq-pio:refs/remotes/libata/irq-pio\n> > \tPull: refs/heads/pata-drivers:refs/heads/pata-drivers\n> > \n> > in practice.\n\nWhat is the idea instead?\nI think the current syntax is fine, as it is very flexible.\nThe reasoning about tracking remote branches in the same place\nis a porcelain issue to be set up by git-clone.\n\nPerhaps you are missing a remotes editor command?\n\nJosef\n\n> \n> Sorry, I don't understand this part.\n"},{"id":"18239","messageId":"7v7j67k65b.fsf@assigned-by-dhcp.cox.net","threadId":"3765","inReplyTo":"200604021817.30222.Josef.Weidendorfer@gmx.de","subject":"Re: Default remote branch for local branch","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-02T21:40:48Z","receivedAt":"2006-04-02T21:40:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:\n\n> On Saturday 01 April 2006 06:18, Pavel Roskin wrote:\n>> On Fri, 2006-03-31 at 19:05 -0800, Junio C Hamano wrote:\n>> > Maybe you would want something like this.\n>> >\n>> > In $GIT_DIR/config:\n>> > \n>> > \t[pull]\n>> > \torigin = linus for master\n>> >         origin = irq-pio of libata for ata-irq-pio\n>> >         origin = pata-drivers of libata for ata-pata\n>\n> Let me try to understand this: the general idea is that\n>\n>   pull.origin = [<refspec> of] <remote> for <branch>\n>\n> specifies the default action of git-pull if we are on <branch>, ie.\n> a \"git pull\" then runs \"git pull <remote> [<refspec>]\".\n\nNot quite.\n\nIt will be (if this were a serious proposal -- I am not\nabsolutely convinced this is a good idea) more like \"git fetch\n<remote>\" followed by \"git-merge HEAD the-refspec-named-there\".\nThe implementation of the above would involve changes to\ngit-fetch, because it needs to give \".not-for-merge\" mark to\ndifferent line in FETCH_HEAD depending on [<refspec> of] part.\n\n> So the example above, if .git/remotes/linus would contain two\n> refspecs, and you are on the branch of the 2nd refspec, it would\n> do the wrong thing: merge the 1st refspec with current branch.\n\nSorry I fail to visualize this part.\n\n>> Secondly, I think the relationship should be between a local development\n>> branch and a local tracking branch.\n>\n> Agree.\n> It is also useful to specify this relation if the upstream is purely a\n> local branch, e.g. when branching off a local branch, and you want to\n> pull in changes from the local upstream.\n>\n> This works automatically if git-pull only does upstream fetching if\n> there is a remote branch associated. The default action of git-fetch\n> similar could be \"fetch the upstream branch, if that tracks a remote\n> branch\", using the same configuration.\n\nInteresting.  \n\nYou would need sanity checker for $GIT_DIR/remotes/* files if\nyou do this to make sure no local tracking branch is by mistake\nconfigured to track two remote branches, which is a good change,\nbut then:\n\n\tgit-pull, without parameter, would:\n\n        (1) check if this branch has any local branch it usually\n            merges from; if not, do whatever we traditionally\n            did (or barf).\n\n        (2) if there is a local branch it merges from, check if\n            it is a tracking branch for a remote, by looking at\n            remotes/* files.  It would be nice if we could\n            detect tracking branches fed from external svn/cvs\n            repositories via svn/cvs-import this way at this\n            time.  If not, skip the next step and go directly to\n            (4).\n\n        (3) run git-fetch (or svn/cvs-import) to update the\n            tracking branch;\n\n        (4) merge from that other local branch.\n\n> Junio's proposal has the advantage that you do not have to search in all\n> files in .git/remotes (and even .git/branches) for the remote branch that\n> maps to a given local branch.\n> But that is not the big issue.\n\nA bigger thing is that I am trying to avoid _requiring_ tracking\nbranches.  If you are not micromanaging your subsystem\nmaintainers, you should not have to care where they were the\nlast time you pulled from them.  You should be able to just\npull, examine what the merge brings in, and decide it is worth\nmerging.  If it isn't, do a \"reset\", tell them \"not good, please\nrework and let me know when you are ready,\" and forget about it.\n\nIf we are going require tracking branches, we could do a bit\nmore with them, like remembering where the tip was when we\nfetched the last time (or the time before that...) and diff with\nthat, but the tracking branch heads are not set up to do things\nlike that right now -- they are single pointers.\n\n>> Perhaps you are missing a remotes editor command?\n\nPerhaps.  Also perhaps a remotes/ sanity checker.\nSomething like this:\n\n\t$ git branch --describe ata-pata\n        Typically merges from pata-drivers branch of\n        \tgit://.../jgarzik/libata-dev.git\n\twhich is tracked with local refs/remotes/libata/pata-drivers.\n\n\t$ git branch --decribe refs/remotes/libata/pata-drivers\n\tTracking branch for pata-drivers branch of\n               \tgit://.../jgarzik/libata-dev.git\n\n\t$ git checkout origin\n        warning: you are checking out a tracking branch for \"master\" branch of\n\twarning:\tgit://.../torvalds/linux-2.6.git\n\twarning: commit/pull/merge commands are disabled.\n\thint: you can still create a new branch from here.\n"},{"id":"18248","messageId":"200604030128.42680.Josef.Weidendorfer@gmx.de","threadId":"3765","inReplyTo":"7v7j67k65b.fsf@assigned-by-dhcp.cox.net","subject":"Re: Default remote branch for local branch","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-04-02T23:28:42Z","receivedAt":"2006-04-02T23:28:42Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Sunday 02 April 2006 23:40, you wrote:\n> > Let me try to understand this: the general idea is that\n> >\n> >   pull.origin = [<refspec> of] <remote> for <branch>\n> >\n> > specifies the default action of git-pull if we are on <branch>, ie.\n> > a \"git pull\" then runs \"git pull <remote> [<refspec>]\".\n> \n> Not quite.\n> \n> It will be (if this were a serious proposal -- I am not\n> absolutely convinced this is a good idea) more like \"git fetch\n> <remote>\" followed by \"git-merge HEAD the-refspec-named-there\".\n\nSo it is not really a <refspec>, but a <localbranch> which has to\nappear in the .git/remotes file on the right side of a refspec on\na Pull line.\nThen, I think it is redundant to specify the <remote>, as\nthis can be detected by looking at the .git/remotes files and\nsearching for <localbranch>.\n\n> > So the example above, if .git/remotes/linus would contain two\n> > refspecs, and you are on the branch of the 2nd refspec, it would\n> > do the wrong thing: merge the 1st refspec with current branch.\n> \n> Sorry I fail to visualize this part.\n\nAll I wanted to remark is, that, with\n\n URL: <remote-URL>\n Pull: refs/head/master:refs/head/remote1\n Pull: refs/head/other:refs/head/remote2\n\nthe config\n\n pull.origin = <remote> for refs/head/my-devel-for-remote2\n\nwhich does not use the [<refspec> of] part, always is bogus:\nWe get remote1 merged into my-devel-for-remote2 on a git-pull,\nwhich is not what we want.\n\n> > It is also useful to specify this relation if the upstream is purely a\n> > local branch, e.g. when branching off a local branch, and you want to\n> > pull in changes from the local upstream.\n\n> \n> Interesting.\n> \n> You would need sanity checker for $GIT_DIR/remotes/* files if\n> you do this to make sure no local tracking branch is by mistake\n> configured to track two remote branches,\n\nWhy should this always be a mistake? If you have two developers\ndoing topic branches for you, you could use this type of config\nto make \"git-pull\" fetching both remotes, and creating an\noctopus merge.\n\nAnd for your \"next\", you could use this to make \"git-pull\" merge\nboth from the stable branch and all topics.\n\n> which is a good change, \n\nThe sanity checker probably should be put into a branch attribute\neditor which allows to add the config discussed here. And it\nshould only print a warning when you are trying to add multiple\nupstreams.\n\n> but then:\n> \n> \tgit-pull, without parameter, would:\n> \n>         (1) check if this branch has any local branch it usually\n>             merges from; if not, do whatever we traditionally\n>             did (or barf).\n\nYes. This is simply looking up the config.\nWe could automatically add such a config when branching off to\nspecify the upstream of a branch.\nAnd git-clone should set this, too, and: We get rid of the current\n\"origin\" hardcoded special handling.\n\nOptionally, branching <new> off from <old> could add <new> as\ntopic branch of <old>: Thus, if you are on <old> and do git-pull,\nyou get <new> merged in.\n\n>         (2) if there is a local branch it merges from, check if\n>             it is a tracking branch for a remote, by looking at\n>             remotes/* files.  It would be nice if we could\n>             detect tracking branches fed from external svn/cvs\n>             repositories via svn/cvs-import this way at this\n>             time.\n\nGood idea. I suppose this needs an entry in .git/remotes like\n\n URL: ...\n Type: SVN \n\n>             If not, skip the next step and go directly to \n>             (4).\n> \n>         (3) run git-fetch (or svn/cvs-import) to update the\n>             tracking branch;\n\nIf (1) found multiple branches, do (2)/(3) for every branch.\n\n>         (4) merge from that other local branch.\n\nOr for multiple, do an octopus.\n\n\n> A bigger thing is that I am trying to avoid _requiring_ tracking\n> branches.\n\nI don't think you force anything when you add functionality to git-pull\nfor the config discussed here. Nobody *has* to use this config - it's\na porcelain thingie.\n\nCogito could use this, too. AFAIK, it has the same origin/master hardcoded\ntracking behavior.\n\n> If you are not micromanaging your subsystem \n> maintainers, you should not have to care where they were the\n> last time you pulled from them.  You should be able to just\n> pull, examine what the merge brings in, and decide it is worth\n> merging.  If it isn't, do a \"reset\", tell them \"not good, please\n> rework and let me know when you are ready,\" and forget about it.\n> \n> If we are going require tracking branches,\n\nI do not understand. Why should we require this?\n\n> we could do a bit \n> more with them, like remembering where the tip was when we\n> fetched the last time (or the time before that...) and diff with\n> that, but the tracking branch heads are not set up to do things\n> like that right now -- they are single pointers.\n> \n> >> Perhaps you are missing a remotes editor command?\n> \n> Perhaps.  Also perhaps a remotes/ sanity checker.\n> Something like this:\n> ...\n\nDoing this as part of git-branch sounds good.\n\nJosef\n"},{"id":"18270","messageId":"4430D517.5020205@op5.se","threadId":"3765","inReplyTo":"200604030128.42680.Josef.Weidendorfer@gmx.de","subject":"Re: Default remote branch for local branch","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-04-03T07:56:07Z","receivedAt":"2006-04-03T07:56:07Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Josef Weidendorfer wrote:\n> \n> Optionally, branching <new> off from <old> could add <new> as\n> topic branch of <old>: Thus, if you are on <old> and do git-pull,\n> you get <new> merged in.\n> \n\nThis is clearly insane. If I'm on <old> and want to sync with my \nupstream source that would be impossible without explicitly telling it \n*not* to merge with <new>. Iow, this change would (possibly) simplify \nfor the one repo maintainer, but make things harder for the 30-odd \ndevelopers.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"18271","messageId":"7vr74ff4oy.fsf@assigned-by-dhcp.cox.net","threadId":"3765","inReplyTo":"200604030128.42680.Josef.Weidendorfer@gmx.de","subject":"Re: Default remote branch for local branch","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-03T08:23:25Z","receivedAt":"2006-04-03T08:23:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:\n\n> On Sunday 02 April 2006 23:40, you wrote:\n>> > Let me try to understand this: the general idea is that\n>> >\n>> >   pull.origin = [<refspec> of] <remote> for <branch>\n>> >\n>> > specifies the default action of git-pull if we are on <branch>, ie.\n>> > a \"git pull\" then runs \"git pull <remote> [<refspec>]\".\n>> \n>> Not quite.\n>> \n>> It will be (if this were a serious proposal -- I am not\n>> absolutely convinced this is a good idea) more like \"git fetch\n>> <remote>\" followed by \"git-merge HEAD the-refspec-named-there\".\n>\n> So it is not really a <refspec>, but a <localbranch> which has to\n> appear in the .git/remotes file on the right side of a refspec on\n> a Pull line.\n\nNo, I meant <refspec> not <localbranch> here, because I do not\nwant to force people to have tracking local branch.  The call to\nmerge in pull that happens immediately after fetch does not use\nlocalbranch, but uses what's recorded in FETCH_HEAD, and if we\nwere to do this change the above change would most likely to\naffect how each remote branch heads fetched are marked for (or\nnot for) merges.\n\n> All I wanted to remark is, that, with\n>\n>  URL: <remote-URL>\n>  Pull: refs/head/master:refs/head/remote1\n>  Pull: refs/head/other:refs/head/remote2\n>\n> the config\n>\n>  pull.origin = <remote> for refs/head/my-devel-for-remote2\n>\n> which does not use the [<refspec> of] part, always is bogus:\n> We get remote1 merged into my-devel-for-remote2 on a git-pull,\n> which is not what we want.\n\nI think we are on the same page, if you just think of not having\n[<refspec> of] a short-hand for naming the first Pull: line.\n\n> Optionally, branching <new> off from <old> could add <new> as\n> topic branch of <old>: Thus, if you are on <old> and do git-pull,\n> you get <new> merged in.\n\nI agree with Andreas on this part.\n\n>> A bigger thing is that I am trying to avoid _requiring_ tracking\n>> branches.\n>\n> I don't think you force anything when you add functionality to git-pull\n> for the config discussed here. Nobody *has* to use this config - it's\n> a porcelain thingie.\n\nNot if you made the [<refspec> of] part <localbranch>.  Then\nthis configuration for default merge source per local branch\nfeature is available only to people who are willing to use\ntracking branches.\n\n>> If you are not micromanaging your subsystem \n>> maintainers, you should not have to care where they were the\n>> last time you pulled from them....\n>> [...why not needing to use tracking branches is good...]\n\n>> If we are going require tracking branches,\n>\n> I do not understand. Why should we require this?\n\nI forgot to say \"on the other hand\" before that \"If\".\n\n>> we could do a bit \n>> more with them, like remembering where the tip was when we\n>> fetched the last time (or the time before that...) and diff with\n>> that, but the tracking branch heads are not set up to do things\n>> like that right now -- they are single pointers.\n\nActually I think this part is independent and I did not have to\nmention.  There is no point complicating only the tracking\nbranches at all.\n\nI just wanted to mention that it would be handy to be able to\ntake snapshots of tracking branch heads, but it does not really\nmatter whether they are \"your\" local development branches or\ntracking branches.  Just a nightly or on-demand\n\n         d=\"$GIT_DIR/refs/snapshot/`date '+%Y-%m-%d'`\" &&\n         mkdir \"$GIT_DIR/refs/snapshot/$d\" &&\n         tar Ccf \"$GIT_DIR/refs/\" - heads |\n         tar Cxf \"$d\" -\n\nwould do, and then you should be able to ask \"where was my\n'master' head yesterday?\".\n"},{"id":"18273","messageId":"200604031138.29227.Josef.Weidendorfer@gmx.de","threadId":"3765","inReplyTo":"4430D517.5020205@op5.se","subject":"Re: Default remote branch for local branch","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-04-03T09:38:29Z","receivedAt":"2006-04-03T09:38:29Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Monday 03 April 2006 09:56, Andreas Ericsson wrote:\n> Josef Weidendorfer wrote:\n> > \n> > Optionally, branching <new> off from <old> could add <new> as\n> > topic branch of <old>: Thus, if you are on <old> and do git-pull,\n> > you get <new> merged in.\n> > \n> \n> This is clearly insane. If I'm on <old> and want to sync with my \n> upstream source that would be impossible without explicitly telling it \n> *not* to merge with <new>. Iow, this change would (possibly) simplify \n> for the one repo maintainer, but make things harder for the 30-odd \n> developers.\n\nYes.\nTherefore I put \"optionally\" above. But you are right, mixing up\n\"merge upstream\" and \"merge downstream\" into one config option is insane.\n\nSome idea independent but related:\nI still think it is a better UI of a porcelain to try to note metainfo\nautomatically, ie. storing somewhere that we branched one off another.\nWhat about adding \"branch.topic\" config option for this?\n\"git-branch -t newtopic\"/\"git-checkout -b newtopic -t\"\nwould create a new topic branch, which is remembered in \"branch.topic\",\nand \"git-pull -t\" merges these topic branches?\nTo specify that a remote branch is a topic branch of a given local\nbranch (to be pulled into with \"git-pull -t\"), we could add\n\"git-branch --add-topic <refspec>|<remoteURL>\".\n\nJosef\n"},{"id":"18275","messageId":"4430F2E5.1030106@op5.se","threadId":"3765","inReplyTo":"200604031138.29227.Josef.Weidendorfer@gmx.de","subject":"Re: Default remote branch for local branch","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-04-03T10:03:17Z","receivedAt":"2006-04-03T10:03:17Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Josef Weidendorfer wrote:\n> On Monday 03 April 2006 09:56, Andreas Ericsson wrote:\n> \n>>Josef Weidendorfer wrote:\n>>\n>>>Optionally, branching <new> off from <old> could add <new> as\n>>>topic branch of <old>: Thus, if you are on <old> and do git-pull,\n>>>you get <new> merged in.\n>>>\n>>\n>>This is clearly insane. If I'm on <old> and want to sync with my \n>>upstream source that would be impossible without explicitly telling it \n>>*not* to merge with <new>. Iow, this change would (possibly) simplify \n>>for the one repo maintainer, but make things harder for the 30-odd \n>>developers.\n> \n> \n> Yes.\n> Therefore I put \"optionally\" above. But you are right, mixing up\n> \"merge upstream\" and \"merge downstream\" into one config option is insane.\n> \n> Some idea independent but related:\n> I still think it is a better UI of a porcelain to try to note metainfo\n> automatically, ie. storing somewhere that we branched one off another.\n> What about adding \"branch.topic\" config option for this?\n> \"git-branch -t newtopic\"/\"git-checkout -b newtopic -t\"\n> would create a new topic branch, which is remembered in \"branch.topic\",\n> and \"git-pull -t\" merges these topic branches?\n> To specify that a remote branch is a topic branch of a given local\n> branch (to be pulled into with \"git-pull -t\"), we could add\n> \"git-branch --add-topic <refspec>|<remoteURL>\".\n> \n\nSorry, but I still don't see the use of it. Usually, some topics mature \nfaster than others, meaning I'd still have to do the old \"git pull . \nthis and that\", leaving \"the-other-one\" to soak a bit longer. What \nyou're suggesting would make the odd case easier while adding nothing \nfor the normal flow.\n\nFor archeological purposes it might make some sense to record what the \nbranch was named that you forked from, but to me it's more interesting \nto see which state the code was in when the code forked, and this is \ndiscernable by the merge-base command.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"18277","messageId":"200604031557.35660.Josef.Weidendorfer@gmx.de","threadId":"3765","inReplyTo":"7vr74ff4oy.fsf@assigned-by-dhcp.cox.net","subject":"Re: Default remote branch for local branch","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-04-03T13:57:35Z","receivedAt":"2006-04-03T13:57:35Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Monday 03 April 2006 10:23, Junio C Hamano wrote:\n> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:\n> \n> > On Sunday 02 April 2006 23:40, you wrote:\n> >> > Let me try to understand this: the general idea is that\n> >> >\n> >> >   pull.origin = [<refspec> of] <remote> for <branch>\n> >> >\n> >> > specifies the default action of git-pull if we are on <branch>, ie.\n> >> > a \"git pull\" then runs \"git pull <remote> [<refspec>]\".\n> >> \n> >> Not quite.\n> >> \n> >> It will be (if this were a serious proposal -- I am not\n> >> absolutely convinced this is a good idea) more like \"git fetch\n> >> <remote>\" followed by \"git-merge HEAD the-refspec-named-there\".\n> >\n> > So it is not really a <refspec>, but a <localbranch> which has to\n> > appear in the .git/remotes file on the right side of a refspec on\n> > a Pull line.\n> \n> No, I meant <refspec> not <localbranch> here, because I do not\n> want to force people to have tracking local branch.\n\nOh, ok. I just had to look up the manual regarding refspecs when\npulling/fetching again: \"<ref>\" is the same as \"<ref>:\" and does\nnot create/use any local branch.\n\n> > All I wanted to remark is, that, with\n> >\n> >  URL: <remote-URL>\n> >  Pull: refs/head/master:refs/head/remote1\n> >  Pull: refs/head/other:refs/head/remote2\n> >\n> > the config\n> >\n> >  pull.origin = <remote> for refs/head/my-devel-for-remote2\n> >\n> > which does not use the [<refspec> of] part, always is bogus:\n> > We get remote1 merged into my-devel-for-remote2 on a git-pull,\n> > which is not what we want.\n> \n> I think we are on the same page, if you just think of not having\n> [<refspec> of] a short-hand for naming the first Pull: line.\n\nYes, I understand this. But I do not think that such an optional\nshortcut is useful for config files entries. It complicates parsing/editors,\nand seems to make it more confusing. Despite, I agree that such optional\nshortcuts are nice for porcelain command lines.\n\nAs I see the use of \"<refspec> of <remote>\", I still think that specifying\na local branch is useful, too. So what about\n\n  pull.origin = (<refspec> of <remote> | <localbranch>) for <branch>\t\n\ninstead? We can distinguish the two cases by looking for the \"of\".\nWhen the <refspec> is of the form <src>:<dst> (where <dst> is the local\nbranch), we probably want to sanity check against .git/remotes/.\n\n> > Optionally, branching <new> off from <old> could add <new> as\n> > topic branch of <old>: Thus, if you are on <old> and do git-pull,\n> > you get <new> merged in.\n> \n> I agree with Andreas on this part.\n\nYup. If we want to support topic branches with defaults, we should use\nanother config option. And now, I am not convinced about the usefulness\nof this any more.\n\n> Not if you made the [<refspec> of] part <localbranch>.  Then\n> this configuration for default merge source per local branch\n> feature is available only to people who are willing to use\n> tracking branches.\n\nYes, I understand this now.\n\n> I just wanted to mention that it would be handy to be able to\n> take snapshots of tracking branch heads, but it does not really\n> matter whether they are \"your\" local development branches or\n> tracking branches.  Just a nightly or on-demand\n> \n>          d=\"$GIT_DIR/refs/snapshot/`date '+%Y-%m-%d'`\" &&\n>          mkdir \"$GIT_DIR/refs/snapshot/$d\" &&\n>          tar Ccf \"$GIT_DIR/refs/\" - heads |\n>          tar Cxf \"$d\" \n\nWow. For this, versioning of the /refs directory as subproject\nwould be good ;-)\n\nJosef\n"},{"id":"18641","messageId":"20060414161627.GA27689@pasky.or.cz","threadId":"3765","inReplyTo":"200604021817.30222.Josef.Weidendorfer@gmx.de","subject":"Re: Default remote branch for local branch","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-04-14T16:16:27Z","receivedAt":"2006-04-14T16:16:27Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Apr 02, 2006 at 06:17:29PM CEST, I got a letter\nwhere Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...\n> > I would write the config like this:\n> > \n> > [branch-upstream]\n> > master = linus\n> > ata-irq-pio = irq-pio\n> > ata-pata = pata-drivers\n> \n> That is not working, as said above. But with above syntax extension,\n> with s/=/for/ it would be fine.\n\nI'm sorry but I'm slow and I don't see it - why wouldn't this work?\n(Except that the key name is case insensitive, which isn't too big a\ndeal IMHO.)\n\nI for one think that the 'for'-syntax is insane - it's unreadable (your\nprimary query is by far most likely to be \"what's the upstream when on\nbranch X\", not \"what branches is this upstream for\"), would convolute\nthe configuration file syntax unnecessarily and would possibly also\ncomplicate the git-repo-config interface. Pavel's syntax is much nicer.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nRight now I am having amnesia and deja-vu at the same time.  I think\nI have forgotten this before.\n"},{"id":"18645","messageId":"200604142026.44070.Josef.Weidendorfer@gmx.de","threadId":"3765","inReplyTo":"20060414161627.GA27689@pasky.or.cz","subject":"Re: Default remote branch for local branch","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-04-14T18:26:43Z","receivedAt":"2006-04-14T18:26:43Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Friday 14 April 2006 18:16, you wrote:\n> Dear diary, on Sun, Apr 02, 2006 at 06:17:29PM CEST, I got a letter\n> where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...\n> > > I would write the config like this:\n> > > \n> > > [branch-upstream]\n> > > master = linus\n> > > ata-irq-pio = irq-pio\n> > > ata-pata = pata-drivers\n> > \n> > That is not working, as said above. But with above syntax extension,\n> > with s/=/for/ it would be fine.\n> \n> I'm sorry but I'm slow and I don't see it - why wouldn't this work?\n> (Except that the key name is case insensitive, which isn't too big a\n> deal IMHO.)\n\nHmm...\n* IMHO \"keys are case insensitive\" is enough to not qualify for branch\nnames: currently, branch names are case sensitive, and with above syntax you\neffectively change this rule (you can not distinguish upstreams for \"master\"\nvs. \"MASTER\").\n* a dot currently seems to be allowed in branch names. For config keys, the\ndot separates subkeys.\n* I thought it is a convention for config keys to be alphanum only,\neg. \"/\" isn't allowed, too (which is mandatory for branch names).\nUnfortunately, I found nothing about allowed chars for config keys in the\ndocumentation.\n \n> I for one think that the 'for'-syntax is insane - it's unreadable (your\n> primary query is by far most likely to be \"what's the upstream when on\n> branch X\", not \"what branches is this upstream for\"), would convolute\n> the configuration file syntax unnecessarily and would possibly also\n> complicate the git-repo-config interface.\n\nAs far as I remember, the \"... for ...\" syntax was suggested by Linus for the\nproxy.command config a long time ago. The original proposal there was to\nuse an URL as key part (as far as I can remember).\n\nThat said,\n\n> Pavel's syntax is much nicer. \n\n... I agree with you here.\n\nMy suggestion would be to allow an optional syntax in the config file which is mapped\nby git-repo-config to the normalized \"... for ...\"-scheme.\nEg. it should not be mandatory to specify \"for ...\" after the value of a key.\nSo instead of\n\n  branch.upstream = linus for master\n\nyou should be able to say\n\n  [branch]\n  upstream for master = linus\n\n\nJosef\n"}]}