{"thread":{"id":"19896","subject":"push.default???","startedAt":"2009-06-22T10:02:33Z","lastAt":"2009-06-24T21:59:23Z","messageCount":18,"participants":["Paolo Bonzini","Junio C Hamano","Finn Arne Gangstad","Andreas Ericsson","Miles Bader"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"116752","messageId":"h1nks1$vdl$1@ger.gmane.org","threadId":"19896","inReplyTo":null,"subject":"push.default???","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2009-06-22T10:02:33Z","receivedAt":"2009-06-22T10:02:33Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"Hi all, I just upgraded to git 1.6.3 and found this new little gem \ncalled push.default...\n\nNow, having gone through an attempt of proposing a different semantics \nfor \"git push\", this stroke me as total nonsense, because now we have \ntwo totally incompatible ways to specify push refspecs.\n\nA sensible implementation would have been something like this:\n\n1) Also in 1.6.3, invent a special refspec for \"tracking\", something \nlike \"HEAD>\" (of course this is not a special case; \"refs/heads/*>\" \nwould also work, yadda yadda)\n\n2) Also in 1.6.3, add a \"--push={current,tracking,matching,mirror}\" \noption to \"git remote add\" that would set up a push refspec without the \nneed to actually know refspec syntax. (--mirror would become just a \nsynonym for --push=mirror).\n\n3) Possibly, in 1.6.3 make \"git clone\" add a \"push = :\" line for the \norigin branch.  This was actually suggested in a patch by myself.\n\n4) in 1.6.4 or 1.7.0, make \"git push\" fail outright if there is no push \nline, with text suggesting\n\n   For remotes that you will create in the future, please use the\n   `--push' argument to `git remote add'.  For existing remotes,\n   you can use the following command to obtain the same behavior as\n   git 1.6.3:\n\n     git config --add remote.origin.push :\n\n   For alternative configurations, please look at the release notes\n   for git 1.6.4.\n\nso that it's a quick cut'n'paste into the shell to fix this (though once \nper repository).\n\n\nI know it's my fault that I did not follow the development of git last \nMarch, but I could not help ranting that it is extremely wrong to \nspecify what to push without a refspec (in the configuration, not in the \ncommand line -- the cmdlines can always have more \"porcelain\" attached \nto them).\n\n(1) and (2) in particular can still be straightened, and (4) too maybe. \n  I can work on the implementation if we agree on the details.\n\nPaolo\n"},{"id":"116775","messageId":"7vws74cjrl.fsf@alter.siamese.dyndns.org","threadId":"19896","inReplyTo":"h1nks1$vdl$1@ger.gmane.org","subject":"Re: push.default???","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-06-22T16:31:42Z","receivedAt":"2009-06-22T16:31:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paolo Bonzini <bonzini@gnu.org> writes:\n\n> 1) Also in 1.6.3, invent a special refspec for \"tracking\", something\n> like \"HEAD>\" (of course this is not a special case; \"refs/heads/*>\"\n> would also work, yadda yadda)\n\nYou cannot do anything \"in 1.6.3\"; The ship has already left the port.\n\nYou can set push.default to \"tracking\" and have it take effect for all\nremotes you interact with from your repository (set remote.$name.push for\nsome remotes you do not want this to take effect).  Instead, you could\nleave push.default to \"matching\" and define remote.$name.push with the\n\"push tracking\" magic you are going to invent for a specific remote.\n\nBoth arrangements can do the same thing, so even if your \"HEAD>\" is never\nsupported, there is no functionality loss (similarly, if we did not have\n\"push.default\", we would be Ok if we had your \"HEAD>\" magic).  Depending\non which one you would want to use for majority of remotes you interact\nwith, you would want both.\n\nSo in that sense, I do not think the current situation is such a \"total\nnonsense\" as you seem to be painting it [*1*].  It just does not have the\nother half of the story that you are bringing up now.\n\nIn other words, I do not have objection to your \"HEAD>\" at the conceptual\nlevel.  At the syntax level, I suspect people will have suggestions for\nbetter alternatives.\n\nIn retrospect, because a push refspec (or \"magic\" you will be adding) for\na specific remote is called \"remote.$name.push\", it might have been a\nbetter idea to use \"remote.push\" instead of \"push.default\" as the name of\nthe configuration variable.  Then the rules can become\n\n\t* if you ask explicitly from the command line, it wins;\n\t* otherwise, if you have remote.$name,push, it is used;\n        * otherwise, if you have remote.push, it is used;\n        * otherwise, the default is \"matching\".\n\nwhich is slightly nicer to read, than the current situation where the\nthird rule talks about push.default instead.\n\n> 2) Also in 1.6.3, add a \"--push={current,tracking,matching,mirror}\"\n> option to \"git remote add\" that would set up a push refspec without\n> the need to actually know refspec syntax. (--mirror would become just\n> a synonym for --push=mirror).\n\nThis is probably sensible if/when we do (1).  \n\nBut here I have to qualify what I mean by (1).  I am not married to the\nidea of using remote.$name.push at all.  I view (1) as solving this issue:\n\n        Currently with push.default, we can only set push.default to\n        something other than \"matching\" and have specific remote override\n        that with remote.$name.push with a more concrete refspec, if we\n        want to have the magic 'tracking push' semantics.\n\n        We want to have a way to say \"for this and that particular\n        remotes, use the magic tracking push\" in a more direct way.\n\nAnd hiding the detail of how this \"direct way\" is implemented from the end\nuser is a good idea.\n\n> 3) Possibly, in 1.6.3 make \"git clone\" add a \"push = :\" line for the\n> origin branch.  This was actually suggested in a patch by myself.\n\nThis contradicts with (1), I think.  The default after cloning is\n\"matching\", and if one wants to change it to \"track\", one not just needs\nto set push.default but also needs to remove/twaek remote.origin.push\nif you add such a line.\n\nSo I do not think this one makes much sense.\n\n> 4) in 1.6.4 or 1.7.0, make \"git push\" fail outright if there is no\n> push line, with text suggesting\n\nThis was already part of one possible option for push.default (change the\nbuilt-in default to 'nothing-and-warn') when it was introduced, wasn't it?\nInstead of suggesting to configure remote.$name.push, it would suggest to\nset push.default to a desired value, which I think is a more sensible\nthing to do.\n\n[Footnote]\n\n*1* ... even though I admit that I am not convinced 'push \"tracking\"'\nmakes much sense for me to begin with, because pushing a branch to the\nbranch it forked from rarely if ever makes sense in my workflow.  But I\ncan see 'push \"tracking\"' makes sense in some situations and people seem\nto want to do this, so we have already added push.default.\n"},{"id":"116779","messageId":"4A3FC592.10401@gnu.org","threadId":"19896","inReplyTo":"7vws74cjrl.fsf@alter.siamese.dyndns.org","subject":"Re: push.default???","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2009-06-22T17:55:30Z","receivedAt":"2009-06-22T17:55:30Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n> You cannot do anything \"in 1.6.3\"; The ship has already left the port.\n\nYes, that was me reasoning out loud.\n\n>> 4) in 1.6.4 or 1.7.0, make \"git push\" fail outright if there is no\n>> push line, with text suggesting\n> \n> This was already part of one possible option for push.default (change the\n> built-in default to 'nothing-and-warn') when it was introduced, wasn't it?\n> Instead of suggesting to configure remote.$name.push, it would suggest to\n> set push.default to a desired value, which I think is a more sensible\n> thing to do.\n\nYes, that was also reasoning out loud.  It makes sense.\n\nAnyway, suggestion will be helpful for the \"tracking\" behavior refspec \nsyntax.\n\nThanks for the remarks,\n\nPaolo\n"},{"id":"116811","messageId":"20090623103428.GA4214@pvv.org","threadId":"19896","inReplyTo":"h1nks1$vdl$1@ger.gmane.org","subject":"Re: push.default???","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2009-06-23T10:34:28Z","receivedAt":"2009-06-23T10:34:28Z","isPatch":false,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"On Mon, Jun 22, 2009 at 12:02:33PM +0200, Paolo Bonzini wrote:\n> Hi all, I just upgraded to git 1.6.3 and found this new little gem  \n> called push.default...\n> [...]\n\nYou should have been here when we discussed this! :)\n\n> 1) Also in 1.6.3, invent a special refspec for \"tracking\", something  \n> like \"HEAD>\" (of course this is not a special case; \"refs/heads/*>\"  \n> would also work, yadda yadda)\n\nYes, this is a weakness righ now - the only way to get tracking\nsemantics is to set push.default. I could not find a very good way of\nspecifying this. We currently have the magic refspecs : and\nHEAD. Adding a \">\" to \"HEAD>\" would be annoying I think, since it has\nto be quoted in the shell.\n\nMaybe we can use \":\" as an escape, it is not allowed in refspecs.\nSomething like \"::tracking\" (and we cold also have \"::matching\",\n\"::current\" and so on for completeness)\n\n> 2) Also in 1.6.3, add a \"--push={current,tracking,matching,mirror}\"  \n> option to \"git remote add\" that would set up a push refspec without the  \n> need to actually know refspec syntax. (--mirror would become just a  \n> synonym for --push=mirror).\n\nSounds like a good idea, the options would also make sense to push I think,\nso you can \"git push [--current|tracking|...] \".\n\n> 3) Possibly, in 1.6.3 make \"git clone\" add a \"push = :\" line for the  \n> origin branch.  This was actually suggested in a patch by myself.\n\nThis would destroy the intention of my patch, it would render the\nconfiguration variable pointless I think (and would also silently push\nmatching).\n\n> 4) in 1.6.4 or 1.7.0, make \"git push\" fail outright if there is no push  \n> line, with text suggesting [...]\n\nHopefully we can get to this stage, that a unconfigured \"git push\"\ngives a small message, indicating how to configure it, and not push\nanything. Most \"oldtimers\" should have configured this already, so it\nshould not break many setups.\n\n- Finn Arne\n"},{"id":"116814","messageId":"4A40D19E.60606@gmail.com","threadId":"19896","inReplyTo":"20090623103428.GA4214@pvv.org","subject":"Re: push.default???","fromName":"Paolo Bonzini","fromEmail":"paolo.bonzini@gmail.com","sentAt":"2009-06-23T12:59:10Z","receivedAt":"2009-06-23T12:59:10Z","isPatch":false,"sender":{"key":"paolo.bonzini@gmail.com","avatar":"https://gravatar.com/avatar/7817ef2e168b4ef0570c5bb5bdc1d4b44f34d3075fe32b871710dd942d0a89f5?d=mp&s=160"},"body":"Finn Arne Gangstad wrote:\n> On Mon, Jun 22, 2009 at 12:02:33PM +0200, Paolo Bonzini wrote:\n>> Hi all, I just upgraded to git 1.6.3 and found this new little gem  \n>> called push.default...\n>> [...]\n> \n> You should have been here when we discussed this! :)\n\nYes, mea culpa.  But I would have expected a *lot* more discussion from \nwhat I remembered about the git list and community. :-)\n\n>> 1) Also in 1.6.3, invent a special refspec for \"tracking\", something  \n>> like \"HEAD>\" (of course this is not a special case; \"refs/heads/*>\"  \n>> would also work, yadda yadda)\n> \n> Yes, this is a weakness righ now - the only way to get tracking\n> semantics is to set push.default. I could not find a very good way of\n> specifying this. We currently have the magic refspecs : and\n> HEAD. Adding a \">\" to \"HEAD>\" would be annoying I think, since it has\n> to be quoted in the shell.\n\nYes, > has the disadvantage of quoting.\n\n> Maybe we can use \":\" as an escape, it is not allowed in refspecs.\n> Something like \"::tracking\" (and we cold also have \"::matching\",\n> \"::current\" and so on for completeness)\n\nBut that would lose the possibility to use wildcards.\n\nBefore going on, can you explain your use case for --push=tracking (in a \ncase where --push=current wouldn't do the same)?\n\n>> 4) in 1.6.4 or 1.7.0, make \"git push\" fail outright if there is no push  \n>> line, with text suggesting [...]\n> \n> Hopefully we can get to this stage, that a unconfigured \"git push\"\n> gives a small message, indicating how to configure it, and not push\n> anything. Most \"oldtimers\" should have configured this already, so it\n> should not break many setups.\n\nAgreed.  Possibly with a \"git remote\" command to add a push refspec.\n\nPaolo\n"},{"id":"116815","messageId":"20090623131131.GA7011@pvv.org","threadId":"19896","inReplyTo":"4A40D19E.60606@gmail.com","subject":"Re: push.default???","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2009-06-23T13:11:31Z","receivedAt":"2009-06-23T13:11:31Z","isPatch":false,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"On Tue, Jun 23, 2009 at 02:59:10PM +0200, Paolo Bonzini wrote:\n[...]\n> Before going on, can you explain your use case for --push=tracking (in a  \n> case where --push=current wouldn't do the same)?\n\nThe idea with \"tracking\" is to push the current branch to wherever it\nwould pull from, making push & pull \"equivalent\" in some sense.\n\nThis is different from \"current\" if you have/choose to name the local\nbranch something else than the remote branch. This happens a lot when\nusing multiple remotes.\n\nE.g. some remotes have only a single active branch called \"master\",\nand you have to name it something else locally, or several people have\nlocal branches called \"beta\", and you have to name it something like\n\"fred-beta\" locally if you are working on fred's beta.\n\n- Finn Arne\n"},{"id":"116816","messageId":"4A40D6C2.2060700@op5.se","threadId":"19896","inReplyTo":"20090623131131.GA7011@pvv.org","subject":"Re: push.default???","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-06-23T13:21:06Z","receivedAt":"2009-06-23T13:21:06Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Finn Arne Gangstad wrote:\n> On Tue, Jun 23, 2009 at 02:59:10PM +0200, Paolo Bonzini wrote:\n> [...]\n>> Before going on, can you explain your use case for --push=tracking (in a  \n>> case where --push=current wouldn't do the same)?\n> \n> The idea with \"tracking\" is to push the current branch to wherever it\n> would pull from, making push & pull \"equivalent\" in some sense.\n> \n> This is different from \"current\" if you have/choose to name the local\n> branch something else than the remote branch. This happens a lot when\n> using multiple remotes.\n> \n> E.g. some remotes have only a single active branch called \"master\",\n> and you have to name it something else locally, or several people have\n> local branches called \"beta\", and you have to name it something like\n> \"fred-beta\" locally if you are working on fred's beta.\n> \n\nUmm. Why not name it after the feature you're working on instead of the\nbranch you started from? That way, you get fred/beta (assuming you've\nadded Fred's repo as a remote named \"fred\" ofcourse) and all your\nbranches have names that never (in theory) clash with any of your\nupstreams.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"116817","messageId":"4A40D864.8040208@gmail.com","threadId":"19896","inReplyTo":"20090623131131.GA7011@pvv.org","subject":"Re: push.default???","fromName":"Paolo Bonzini","fromEmail":"paolo.bonzini@gmail.com","sentAt":"2009-06-23T13:28:04Z","receivedAt":"2009-06-23T13:28:04Z","isPatch":false,"sender":{"key":"paolo.bonzini@gmail.com","avatar":"https://gravatar.com/avatar/7817ef2e168b4ef0570c5bb5bdc1d4b44f34d3075fe32b871710dd942d0a89f5?d=mp&s=160"},"body":"Finn Arne Gangstad wrote:\n> On Tue, Jun 23, 2009 at 02:59:10PM +0200, Paolo Bonzini wrote:\n> [...]\n>> Before going on, can you explain your use case for --push=tracking (in a  \n>> case where --push=current wouldn't do the same)?\n> \n> The idea with \"tracking\" is to push the current branch to wherever it\n> would pull from, making push & pull \"equivalent\" in some sense.\n> \n> This is different from \"current\" if you have/choose to name the local\n> branch something else than the remote branch. This happens a lot when\n> using multiple remotes.\n\nYes, but when using multiple remotes is it really common that:\n\n1) I have the permission to push to them (as opposed to sending a pull \nrequest)?  If I have permission to push only to the mob branch, for \nexample, I would still set my tracking branch to the master branch.\n\n2) I *do* want to push to them often?  If I use tracking for my topic \nbranches, push.default=tracking seems a sure way to big mess when I do \n\"git push\" on the wrong branch.  Instead, with push.default=current \"git \npush\" would just tell me \"new branch created\" and then I can do \"git \npush branch-name:\" to delete the newly created branch.\n\nI don't remember who it was, but when I tried changing the behavior for \n\"git push\" someone screamed loudly that fetching and pushing are two \ndifferent things, and making things work uniformly across the two is not \nnecessarily correct.  The details probably were different, but I think \nthat I am saying the same now.\n\nPaolo\n"},{"id":"116818","messageId":"20090623135755.GA24974@pvv.org","threadId":"19896","inReplyTo":"4A40D6C2.2060700@op5.se","subject":"Re: push.default???","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2009-06-23T13:57:55Z","receivedAt":"2009-06-23T13:57:55Z","isPatch":false,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"On Tue, Jun 23, 2009 at 03:21:06PM +0200, Andreas Ericsson wrote:\n> Finn Arne Gangstad wrote:\n>> On Tue, Jun 23, 2009 at 02:59:10PM +0200, Paolo Bonzini wrote:\n>> [...]\n>>> Before going on, can you explain your use case for --push=tracking \n>>> (in a  case where --push=current wouldn't do the same)?\n>>\n>> The idea with \"tracking\" is to push the current branch to wherever it\n>> would pull from, making push & pull \"equivalent\" in some sense.\n>>\n>> This is different from \"current\" if you have/choose to name the local\n>> branch something else than the remote branch. This happens a lot when\n>> using multiple remotes.\n>>\n>> E.g. some remotes have only a single active branch called \"master\",\n>> and you have to name it something else locally, or several people have\n>> local branches called \"beta\", and you have to name it something like\n>> \"fred-beta\" locally if you are working on fred's beta.\n>>\n>\n> Umm. Why not name it after the feature you're working on instead of the\n> branch you started from? That way, you get fred/beta (assuming you've\n> added Fred's repo as a remote named \"fred\" ofcourse) and all your\n> branches have names that never (in theory) clash with any of your\n> upstreams.\n\nMaybe I misunderstand what you are saying, but: The point is that you\ncan not name it the same as on the remote. So the names are different,\nand --current will not work.\n\n- Finn Arne\n"},{"id":"116819","messageId":"4A40E1B4.6090303@op5.se","threadId":"19896","inReplyTo":"20090623135755.GA24974@pvv.org","subject":"Re: push.default???","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-06-23T14:07:48Z","receivedAt":"2009-06-23T14:07:48Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Finn Arne Gangstad wrote:\n> On Tue, Jun 23, 2009 at 03:21:06PM +0200, Andreas Ericsson wrote:\n>> Finn Arne Gangstad wrote:\n>>> On Tue, Jun 23, 2009 at 02:59:10PM +0200, Paolo Bonzini wrote:\n>>> [...]\n>>>> Before going on, can you explain your use case for --push=tracking \n>>>> (in a  case where --push=current wouldn't do the same)?\n>>> The idea with \"tracking\" is to push the current branch to wherever it\n>>> would pull from, making push & pull \"equivalent\" in some sense.\n>>>\n>>> This is different from \"current\" if you have/choose to name the local\n>>> branch something else than the remote branch. This happens a lot when\n>>> using multiple remotes.\n>>>\n>>> E.g. some remotes have only a single active branch called \"master\",\n>>> and you have to name it something else locally, or several people have\n>>> local branches called \"beta\", and you have to name it something like\n>>> \"fred-beta\" locally if you are working on fred's beta.\n>>>\n>> Umm. Why not name it after the feature you're working on instead of the\n>> branch you started from? That way, you get fred/beta (assuming you've\n>> added Fred's repo as a remote named \"fred\" ofcourse) and all your\n>> branches have names that never (in theory) clash with any of your\n>> upstreams.\n> \n> Maybe I misunderstand what you are saying, but: The point is that you\n> can not name it the same as on the remote. So the names are different,\n> and --current will not work.\n> \n\nI think our workflows differ quite drastically, as I very rarely see\nthe need to push more than one branch. When I do, it's for repositories\nwhere I'm the ultimate upstream, so I only have one remote that I\nactually *can* push to at all.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"116820","messageId":"20090623144805.GB24974@pvv.org","threadId":"19896","inReplyTo":"4A40D864.8040208@gmail.com","subject":"Re: push.default???","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2009-06-23T14:48:05Z","receivedAt":"2009-06-23T14:48:05Z","isPatch":false,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"On Tue, Jun 23, 2009 at 03:28:04PM +0200, Paolo Bonzini wrote:\n> Finn Arne Gangstad wrote:\n>> On Tue, Jun 23, 2009 at 02:59:10PM +0200, Paolo Bonzini wrote:\n>> [...]\n>>> Before going on, can you explain your use case for --push=tracking \n>>> (in a  case where --push=current wouldn't do the same)?\n>>\n>> The idea with \"tracking\" is to push the current branch to wherever it\n>> would pull from, making push & pull \"equivalent\" in some sense.\n>>\n>> This is different from \"current\" if you have/choose to name the local\n>> branch something else than the remote branch. This happens a lot when\n>> using multiple remotes.\n>\n> Yes, but when using multiple remotes is it really common that:\n>\n> 1) I have the permission to push to them (as opposed to sending a pull  \n> request)?  If I have permission to push only to the mob branch, for  \n> example, I would still set my tracking branch to the master branch.\n\nI don't know how common it is, but it is certainly not unheard of. You\nhave a shared public server, and a group-shared public server and so\non. You only need a single shared public server for this to make sense\nhowever.\n\n> 2) I *do* want to push to them often?  If I use tracking for my topic  \n> branches, push.default=tracking seems a sure way to big mess when I do  \n> \"git push\" on the wrong branch.\n\nIn our shared repositories, we have a few protected branches that only\nintegrators can push to, so no one else can accidentally push to\nthem. These are typically the branches that it makes sense to track\n\"by default\".\n\nIf a group sets up a shared public branch, it is typically for\nworking together on some feature. There are very few surprises if\nthe group works like this:\n\n 1. Do some modifications\n 2. git commit\n 3. git pull [--rebase]\n 4. git push\n 5. goto 1 .. \n\nFor people used to CVS, this is a nice way to start working with git.\nIt requires --tracking to work properly though (--current only works\nif you remember to use the same branch name).\n\n> Instead, with push.default=current \"git  \n> push\" would just tell me \"new branch created\" and then I can do \"git  \n> push branch-name:\" to delete the newly created branch.\n\nWell, you need to add the name of the remote. And while not exactly\nimpossible to find, for the target audience it may be a bit more\ncumbersome than it should be:\n\nbranch: git symbolic-ref HEAD | sed -e s=refs/heads/==\nremote: git config branch.<branch>.remote\n\nAnd if you want to figure out what the branch you pulled from is\nnamed, you have to do something like\n\ngit config branch.<branch>.merge | sed -e s=refs/heads/==\n\n> I don't remember who it was, but when I tried changing the behavior for  \n> \"git push\" someone screamed loudly that fetching and pushing are two  \n> different things, and making things work uniformly across the two is not  \n> necessarily correct.  The details probably were different, but I think  \n> that I am saying the same now.\n\nDifferent use cases want different things from push. If you are the top\nlevel integrator of a project and are trying to keep 3 remotes in sync\nwith your master repository, \"matching\" seems to be what you want.\n\nIf you are a leaf-node worker pushing to a public repository, it\nisn't. But --tracking may be a valid choice sometimes (and is, in some\nsense, very close to SCMs people may be used to).\n\n- Finn Arne\n"},{"id":"116825","messageId":"f865508f0906230932n4a2f2b54s1e76ab1d70d95073@mail.gmail.com","threadId":"19896","inReplyTo":"20090623144805.GB24974@pvv.org","subject":"Re: push.default???","fromName":"Paolo Bonzini","fromEmail":"paolo.bonzini@gmail.com","sentAt":"2009-06-23T16:32:28Z","receivedAt":"2009-06-23T16:32:28Z","isPatch":false,"sender":{"key":"paolo.bonzini@gmail.com","avatar":"https://gravatar.com/avatar/7817ef2e168b4ef0570c5bb5bdc1d4b44f34d3075fe32b871710dd942d0a89f5?d=mp&s=160"},"body":">> 1) I have the permission to push to them (as opposed to sending a pull\n>> request)?  If I have permission to push only to the mob branch, for\n>> example, I would still set my tracking branch to the master branch.\n>>\n>> 2) I *do* want to push to them often?  If I use tracking for my topic\n>> branches, push.default=tracking seems a sure way to big mess when I do\n>> \"git push\" on the wrong branch.\n>\n> In our shared repositories, we have a few protected branches that only\n> integrators can push to, so no one else can accidentally push to\n> them. These are typically the branches that it makes sense to track\n> \"by default\".\n\nYes, on the other hand you cannot push to them, so talking about them\nin the context if push.default is moot. :-)\n\n> If a group sets up a shared public branch, it is typically for\n> working together on some feature.\n>\n> For people used to CVS, this is a nice way to start working with git.\n> It requires --tracking to work properly though (--current only works\n> if you remember to use the same branch name).\n\nOk, this *is* a usecase.  Your local branch is named as a feature but\nit pushes into master.  Thanks, I have something to reason about now.\n:-)\n\nPaolo\n"},{"id":"116831","messageId":"7vprcu96td.fsf@alter.siamese.dyndns.org","threadId":"19896","inReplyTo":"f865508f0906230932n4a2f2b54s1e76ab1d70d95073@mail.gmail.com","subject":"Re: push.default???","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-06-23T17:51:58Z","receivedAt":"2009-06-23T17:51:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paolo Bonzini <paolo.bonzini@gmail.com> writes:\n\n>> If a group sets up a shared public branch, it is typically for\n>> working together on some feature.\n>>\n>> For people used to CVS, this is a nice way to start working with git.\n>> It requires --tracking to work properly though (--current only works\n>> if you remember to use the same branch name).\n>\n> Ok, this *is* a usecase.  Your local branch is named as a feature but\n> it pushes into master.  Thanks, I have something to reason about now.\n> :-)\n\nI actually have been having a hard time imagining how such a set-up makes\nsense, even during your absense (i.e. the timeframe we did push.default).\n\nYou are forking off of shared 'master', but you are developing a feature\non a separate branch 'feature'.\n\nThat is a sane thing to do for two reasons.  (1) Until 'feature' is done\nto your own satisfaction, you do not want to contaminate your own 'master'\nwith the half-cooked feature development in it. (2) While you are working\non 'feature', you may want to update your own 'master' from the shared\nrepository to monitor how others are doing.  Having a separate, pristine\n'master' branch allows you to do so more easily, than detaching HEAD at\n'origin/master' every once in a while.\n\nHowever, when 'feature' is fully cooked, before pushing it back to be\nshared with others in the group, don't you do any testing with the work\ndone by others while you were working on 'feature'?  That means you first\nintegrate your 'feature' locally into shared 'master' and make sure all\nfits together well.\n\nUntil you do that, you cannot be confident that the feature you developed\nis fit for public consumption.  But if you test after merging 'feature'\ninto 'master', what you determined as good is in 'master', which you can\npush back to the remote's 'master'.\n\nOne glitch I can think of is what would happen if you do not want to merge\nyour feature for final testing to master, but instead rebase your feature\non top of master (let's not discuss why you should or should not rebase at\nthis point; some projects seem to insist you rebase and there may be no\ngood technical reason but that is not the topic here).  There currently is\nno easy UI other than:\n\n\t$ git checkout master\n        $ git pull --rebase . feature\n\t$ test test test\n\t$ git push origin master\n\nor even worse:\n\n\t$ git checkout feature\n        $ git rebase master\n        $ git checkout master\n        $ git merge feature\n\t$ test test test\n\t$ git push origin master\n\nto tell git to integrate your local work done in 'feature' to 'master' by\nrebasing, instead of merging.  If you do a merge, that is quite\nstraightforward:\n\n\t$ git checkout master\n        $ git merge feature\n\t$ test test test\n\t$ git push origin master\n\nbut instead you have to do something like:\n\n\t$ git checkout feature\n        $ git rebase master\n        $ test test test\n        $ git push origin feature:master\n\nand you end up needing \"put my 'feature' into their 'master'\".\n\nCould it be possible that this desire to push \"tracking\" is not a cure for\nanything real, but merely a kludge to work around a misfeature of \"rebase\"\nUI that does not allow \"integrate that branch here but do not merge it but\nby first rebasing it\"?  In other words, if we had \"git merge --rebase\" (I\nknow, I know, it is a terrible name.  The word \"merge\" in this context\nmeans \"to integrate\"), the above can be done more naturally:\n\n\t$ git checkout master\n        $ git merge --rebase feature\n\t$ test test test\n\t$ git push origin master\n\nand the matching push (or \"git push origin HEAD\") becomes the right thing\nto do, eliminating the need for \"put my 'feature' into their 'master'\".\n\nFor a group that sets up a shared public branch to be used for working\ntogether on some feature, replace 'master' with 'some feature' above, and\n'feature' with 'your part of the work on the feature'; the story is the\nsame.\n"},{"id":"116832","messageId":"7vljni96gq.fsf@alter.siamese.dyndns.org","threadId":"19896","inReplyTo":"7vprcu96td.fsf@alter.siamese.dyndns.org","subject":"Re: push.default???","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-06-23T17:59:33Z","receivedAt":"2009-06-23T17:59:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> One glitch I can think of is what would happen if you do not want to merge\n> your feature for final testing to master, but instead rebase your feature\n> on top of master (let's not discuss why you should or should not rebase at\n> this point; some projects seem to insist you rebase and there may be no\n> good technical reason but that is not the topic here).  There currently is\n> no easy UI other than:\n>\n>       $ git checkout master\n>       $ git pull --rebase . feature\n>       $ test test test\n>       $ git push origin master\n> ...\n> to tell git to integrate your local work done in 'feature' to 'master' by\n> rebasing, instead of merging.\n\nSorry, but I screwed up.  The above rebases 'master', so it does not do\nwhat we want to do.  The only way I can think of is:\n\n> or even worse:\n>\n>       $ git checkout feature\n>       $ git rebase master\n>       $ git checkout master\n>       $ git merge feature\n>       $ test test test\n>       $ git push origin master\n\nwhich is too much typing.  That makes my suspicion that the conclusion of\nmy previous message is correct even stronger.\n\n> Could it be possible that this desire to push \"tracking\" is not a cure for\n> anything real, but merely a kludge to work around a misfeature of \"rebase\"\n> UI that does not allow \"integrate that branch here but do not merge it but\n> by first rebasing it\"?  In other words, if we had \"git merge --rebase\" (I\n> know, I know, it is a terrible name.  The word \"merge\" in this context\n> means \"to integrate\"), the above can be done more naturally:\n>\n>       $ git checkout master\n>       $ git merge --rebase feature\n>       $ test test test\n>       $ git push origin master\n>\n> and the matching push (or \"git push origin HEAD\") becomes the right thing\n> to do, eliminating the need for \"put my 'feature' into their 'master'\".\n>\n> For a group that sets up a shared public branch to be used for working\n> together on some feature, replace 'master' with 'some feature' above, and\n> 'feature' with 'your part of the work on the feature'; the story is the\n> same.\n"},{"id":"116850","messageId":"buoljniyybp.fsf@dhlpc061.dev.necel.com","threadId":"19896","inReplyTo":"7vprcu96td.fsf@alter.siamese.dyndns.org","subject":"Re: push.default???","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2009-06-24T05:50:50Z","receivedAt":"2009-06-24T05:50:50Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n> However, when 'feature' is fully cooked, before pushing it back to be\n> shared with others in the group, don't you do any testing with the work\n> done by others while you were working on 'feature'?  That means you first\n> integrate your 'feature' locally into shared 'master' and make sure all\n> fits together well.\n\nYou seem to be making a lot of assumptions about workflows here.\n\nIt seems quite plausible to me that one might want to keep the remote\nbranch separate, even after pushing.  It's very common to cooperatively\ndevelop feature branches for a very long time before merging to the\n\"real\" master, but it's still extremely useful to keep them as branches\nin the same local git directory.\n\n-Miles\n\n-- \nSomebody has to do something, and it's just incredibly pathetic that it\nhas to be us.  -- Jerry Garcia\n"},{"id":"116851","messageId":"7vbpoe16lv.fsf@alter.siamese.dyndns.org","threadId":"19896","inReplyTo":"buoljniyybp.fsf@dhlpc061.dev.necel.com","subject":"Re: push.default???","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-06-24T06:35:56Z","receivedAt":"2009-06-24T06:35:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miles Bader <miles@gnu.org> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>> However, when 'feature' is fully cooked, before pushing it back to be\n>> shared with others in the group, don't you do any testing with the work\n>> done by others while you were working on 'feature'?  That means you first\n>> integrate your 'feature' locally into shared 'master' and make sure all\n>> fits together well.\n>\n> You seem to be making a lot of assumptions about workflows here.\n>\n> It seems quite plausible to me that one might want to keep the remote\n> branch separate, even after pushing.  It's very common to cooperatively\n> develop feature branches for a very long time before merging to the\n> \"real\" master, but it's still extremely useful to keep them as branches\n> in the same local git directory.\n\nSorry, but I do not understand your point.\n\nMy \"feature is cooked, let's test it together with master\" does not mean\n\"Now we are done with the feature, so let's 'branch -d' it\" at all.  That\nis an orthogonal issue.  You can keep 'feature' in the local repository\nindefinitely.\n\nKeeping the remote branch separate means pushing 'feature' to 'feature',\nand keep it there.  I do not have any problem with that, either.\n\nThe '--track' I was having hard time justifying to myself was about\npushing 'feature' (and other features 'feature2', 'feature3',... that are\nall forked from 'master' at the remote side) to 'master' at remote.  In\nother words, the workflow being discussed to support why --track was a\ngood mode was about updating the remote 'master', not about keeping the\nbranches separate.\n\nEither you are not following the thread, or you are agreeing with me\nwithout realizing, or perhaps a bit of both.\n"},{"id":"116858","messageId":"4A41E8B8.8050803@gmail.com","threadId":"19896","inReplyTo":"7vprcu96td.fsf@alter.siamese.dyndns.org","subject":"Re: push.default???","fromName":"Paolo Bonzini","fromEmail":"paolo.bonzini@gmail.com","sentAt":"2009-06-24T08:50:00Z","receivedAt":"2009-06-24T08:50:00Z","isPatch":false,"sender":{"key":"paolo.bonzini@gmail.com","avatar":"https://gravatar.com/avatar/7817ef2e168b4ef0570c5bb5bdc1d4b44f34d3075fe32b871710dd942d0a89f5?d=mp&s=160"},"body":"> You are forking off of shared 'master', but you are developing a feature\n> on a separate branch 'feature'.\n> \n> However, when 'feature' is fully cooked, before pushing it back to be\n> shared with others in the group, don't you do any testing with the work\n> done by others while you were working on 'feature'?  That means you first\n> integrate your 'feature' locally into shared 'master' and make sure all\n> fits together well.\n> \n> Until you do that, you cannot be confident that the feature you developed\n> is fit for public consumption.  But if you test after merging 'feature'\n> into 'master', what you determined as good is in 'master', which you can\n> push back to the remote's 'master'.\n\nHere is what I think you are missing: in the proposed workflow, there is \nan entire group working on one big feature, so there is effectively one \nremote per feature.\n\nIn fact, what was not clear to me before Finn explained it is the way \nthese remotes are configured and mapped to local branches.  In his \nsetup, your own master branch is tracking integration/master, but your \nfeature branch is tracking feature/master.  You're effectively using a \ncentralized repository but splitting it across several remotes, \npresumably for two reasons: 1) access control, 2) so that people can \nchoose which parts of the repository to mirror.\n\nMind that this is quite a mangled DVCS workflow :-) since you're \ndistributing the centralized repository (!), so you're not using topic \nbranches and you're not committing very often; if you were using topic \nbranches you would have to use --no-track or risk pushing by mistake to \nfeature/master.  You just map \"svn update\" to \"git pull --rebase\" and \n\"svn commit\" to \"git commit + git push\".\n\nSo, every time you finish some aspect of 'feature', you rebase it on top \nof the tracked branch feature/master to test it with the work done by \nothers, and then push.  The rebasing is taken care of by \"git pull\", so \nit makes sense in this case that pushing to feature/master is done with \nplain \"git push\".\n\n> Could it be possible that this desire to push \"tracking\" is not a cure for\n> anything real, but merely a kludge to work around a misfeature of \"rebase\"\n> UI that does not allow \"integrate that branch here but do not merge it but\n> by first rebasing it\"?  In other words, if we had \"git merge --rebase feature\"\n> [to merge rebased feature into master, then \"git push origin HEAD\"] becomes the\n > right thing to do, eliminating the need for \"put my 'feature' into \ntheir 'master'\".\n >\n> For a group that sets up a shared public branch to be used for working\n> together on some feature, replace 'master' with 'some feature' above, and\n> 'feature' with 'your part of the work on the feature'; the story is the\n> same.\n\nI think this makes sense, but it is not what Finn was going after.  In \nhis setup, there is no 'your part of the work on the feature', \neverything is done in a single branch.\n\n\nNow, here is a plan to realize the same workflow with a different \nimplementation.\n\n1) introduce a new configuration key branch.autosetuppush that \nautomatically adds a remote.*.push entry whenever a tracking branch is \ncreated.\n\nI think this is also the right time to introduce per-remote autosetup \nkeys remote.*.autosetup{merge,rebase,push}.  In fact I would introduce \nthese per-remote configurations before, as a kind of \"step 0\".\n\n2) introduce git push --current (or maybe --head-only) that uses \nwhatever refspec \"git push\" uses, but always restrict pushing to the \ncurrent branch.  This would only apply to \"git push\" without explicit \nrefspecs.\n\n3) introduce remote.*.pushHeadOnly to make \"git push\" always behave like \n\"git push --current\".\n\nNote that the new command line option is not really needed, but it would \nmake testing harder if --current behavior could be specified only with \nconfiguration keys.\n\n4) introduce a --push option for \"git remote add\".  Every push.default \nconfiguration, thanks to steps 1 and 3, now maps to a simple configuration:\n\n  --push=current -> remote.*.push = HEAD\n  --push=tracking -> remote.*.autosetuppush=remote.*.pushHeadOnly=true\n  --push=matching -> remote.*.push = :\n\nIn addition, --push=mirror could be implemented to do the same as --mirror.\n\n\nI have a rough draft of all but the last step already implemented (I \nhave not even compiled, but I wanted to measure roughly the complexity \nof the features; unless I screwed up big, it seems like a \"calm\" patch \nseries).  I like this way more than the \"magic refspec\".  Unlike \npush.default, it builds entirely on the concept of refspecs.  But unlike \nthe magic refspec, it fits with the rest of --track better, and it just \nuses two easily understood knobs to achieve its objective.\n\nPaolo\n"},{"id":"116887","messageId":"20090624215922.GA13575@pvv.org","threadId":"19896","inReplyTo":"4A41E8B8.8050803@gmail.com","subject":"Re: push.default???","fromName":"Finn Arne Gangstad","fromEmail":"finnag@pvv.org","sentAt":"2009-06-24T21:59:23Z","receivedAt":"2009-06-24T21:59:23Z","isPatch":false,"sender":{"key":"finnag@pvv.org","avatar":"https://gravatar.com/avatar/b421ddd58c3f0f93aa473e17b98bb8d53c221fef741746bc8cb59fae4ec6d95e?d=mp&s=160"},"body":"On Wed, Jun 24, 2009 at 10:50:00AM +0200, Paolo Bonzini wrote:\n>\n> Here is what I think you are missing: in the proposed workflow, there is  \n> an entire group working on one big feature, so there is effectively one  \n> remote per feature.\n\nI think you are making this more complicated than it is. I just claim\nthat the idea that \"branch names must be identical in both ends\" is\nnot necessarily the best model.\n\nIn a sufficiently large origanisation with multiple levels of\nrepositories (access restrictions, locality, whatever) branch names\nare not globally unique, and there is no reasonable way to check if a\nbranch name is used elsewhere. It is much easier to treat local branch\nnames as strictly local, and worry about naming (only) when you push\nsomewhere.\n\nSo - even if someone decided to name something \"issue-331318\" on a\npublic repository, it doesn't mean you want to call it that locally,\neven if you want to push to it.\n\nIf a branch already exists on a public repo, it doesn't mean a branch\nwith the same name but with different contents/purpose cannot exist in\na different repo. So you may have to name the branch something else\nlocally. Pull knows how to deal with this, but push did not (before\n\"--tracking\").\n\nAnother example:\n\nYou have worked for a few days on an issue, but need help from someone\nelse with something. You have set up a public shared repo named\n\"public\", and do:\n\ngit push public HEAD:fred-helpme\n\nFred wants to name it something else that makes him remember what this\nbranch is about, and does:\n\ngit fetch public\ngit checkout -b tmp-help-john public/fred-helpme\n<hack hack>\ngit commit\ngit push   (no more arguments, and no need to remember what it was named)\n\nYou then fetch and look at what Fred has done, and maybe you just use\nit, or maybe you don't. Afterwards git push public :fred-helpme to get\nrid of the temporary shared branch.\n\n- Finn Arne\n"}]}