{"thread":{"id":"10954","subject":"Adding push configuration to .git/config","startedAt":"2007-11-21T10:55:17Z","lastAt":"2007-11-30T00:37:59Z","messageCount":16,"participants":["Nico -telmich- Schottelius","Steffen Prohaska","Junio C Hamano","Andreas Ericsson","Johannes Schindelin","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"60495","messageId":"20071121105517.GA11875@denkbrett.schottelius.org","threadId":"10954","inReplyTo":null,"subject":"Adding push configuration to .git/config","fromName":"Nico -telmich- Schottelius","fromEmail":"nico-linux-git@schottelius.org","sentAt":"2007-11-21T10:55:17Z","receivedAt":"2007-11-21T10:55:17Z","isPatch":false,"sender":{"key":"nico-linux-git@schottelius.org","avatar":null},"body":"Hello guys!\n\nWe are working pretty much with branches here and I think it would be\npretty cool, to make git-push recognize some configuratio in\n~/.git/config that describes where to push what:\n\n git-push origin master: is what we currenty do\n manually\n\nNice would be\n\n[branch \"master\"]\n remote-push = origin\n remote-push-merge = another_branch\n\nAnd thus perhaps also changing the existing specs:\n\n remote = ... to remote-fetch = ...\n merge = ... to remote-fetch-merge = \n\nAnd perhaps it would also make sense to replace \"refs/heads/master\" with\nonly \"master\"?\n\nWhat do you think about those three ideas?\n\nNico\n\n-- \nThink about Free and Open Source Software (FOSS).\nhttp://nico.schottelius.org/documentations/foss/the-term-foss/\n\nPGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C\n"},{"id":"60571","messageId":"90095755-2B2B-49DA-9841-7399CB53585A@zib.de","threadId":"10954","inReplyTo":"20071121105517.GA11875@denkbrett.schottelius.org","subject":"Re: Adding push configuration to .git/config","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-11-21T22:02:08Z","receivedAt":"2007-11-21T22:02:08Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Nov 21, 2007, at 11:55 AM, Nico -telmich- Schottelius wrote:\n\n> Hello guys!\n>\n> We are working pretty much with branches here and I think it would be\n> pretty cool, to make git-push recognize some configuratio in\n> ~/.git/config that describes where to push what:\n>\n> git-push origin master: is what we currenty do\n> manually\n>\n> Nice would be\n>\n> [branch \"master\"]\n> remote-push = origin\n> remote-push-merge = another_branch\n\nThis was discussed in a similar form here:\n\nhttp://marc.info/?l=git&m=119384331712996&w=2\nhttp://marc.info/?l=git&m=119400354601328&w=2\n\nSo, yes, I think it would be very useful. I did not yet find\ntime to implement it.\n\n\n> And thus perhaps also changing the existing specs:\n>\n> remote = ... to remote-fetch = ...\n> merge = ... to remote-fetch-merge =\n\nThis is a logical consequence. It gives more freedom to pull\nfrom one repo and push to another one.\n\nI'm not fully convinced, though, of the configuration names\nyou propose. However, I have no better suggestion right away.\n\n\n> And perhaps it would also make sense to replace \"refs/heads/master\" \n> with\n> only \"master\"?\n\nNo. We use full refnames everywhere. I think we should stick\nwith them.\n\n\tSteffen\n"},{"id":"60596","messageId":"7vabp79hjt.fsf@gitster.siamese.dyndns.org","threadId":"10954","inReplyTo":"20071121105517.GA11875@denkbrett.schottelius.org","subject":"Re: Adding push configuration to .git/config","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-22T01:48:22Z","receivedAt":"2007-11-22T01:48:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nico -telmich- Schottelius \nwrites:\n\n> Nice would be\n>\n> [branch \"master\"]\n> remote-push = origin\n> remote-push-merge = another_branch\n>\n> And thus perhaps also changing the existing specs:\n>\n> remote = ... to remote-fetch = ...\n> merge = ... to remote-fetch-merge = \n\nI do not think doing this is worth it, not because I think a\nsingle branch.$name.remote should be good enough for everybody,\nbut because once you need a separate remote each for fetching\nand pushing, there is no reason to say one per direction is\nenough.\n\nAn alternative could be to split [remote \"name\"] url into two\nvariants, fetch-url and push-url. While fetching by default\nfrom two places without telling from which one does not make any\nsense, pushing by default to two different places is quite a\nnormal thing to do, and we already do support more than one url\nentries in [remote \"name\"] section used for pushing.\n\nIf we were to do this, it might also make sense to rename the\nword 'origin' we use for the default remote name to 'default' or\nsomething. People with shared repository workflow would fetch\nfrom one repository and push back to the same repository, so the\ndistinction would not matter, but for others who need something\nlike you suggest, the default repository for fetching and\npushing are different, and while you may still consider where\nyou fetch from your 'origin', where you push into is not your\n'origin' anymore.\n"},{"id":"60606","messageId":"C297CFC3-8DD0-4EEE-8FD3-BF997F6E269A@zib.de","threadId":"10954","inReplyTo":"7vabp79hjt.fsf@gitster.siamese.dyndns.org","subject":"Re: Adding push configuration to .git/config","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-11-22T07:08:35Z","receivedAt":"2007-11-22T07:08:35Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Nov 22, 2007, at 2:48 AM, Junio C Hamano wrote:\n\n> Nico -telmich- Schottelius \n> writes:\n>\n>> Nice would be\n>>\n>> [branch \"master\"]\n>> remote-push = origin\n>> remote-push-merge = another_branch\n>>\n>> And thus perhaps also changing the existing specs:\n>>\n>> remote = ... to remote-fetch = ...\n>> merge = ... to remote-fetch-merge =\n>\n> I do not think doing this is worth it, not because I think a\n> single branch.$name.remote should be good enough for everybody,\n> but because once you need a separate remote each for fetching\n> and pushing, there is no reason to say one per direction is\n> enough.\n>\n> An alternative could be to split [remote \"name\"] url into two\n> variants, fetch-url and push-url. While fetching by default\n> from two places without telling from which one does not make any\n> sense, pushing by default to two different places is quite a\n> normal thing to do, and we already do support more than one url\n> entries in [remote \"name\"] section used for pushing.\n>\n> If we were to do this, it might also make sense to rename the\n> word 'origin' we use for the default remote name to 'default' or\n> something. People with shared repository workflow would fetch\n> from one repository and push back to the same repository, so the\n> distinction would not matter, but for others who need something\n> like you suggest, the default repository for fetching and\n> pushing are different, and while you may still consider where\n> you fetch from your 'origin', where you push into is not your\n> 'origin' anymore.\n\nI like this idea.\n\nBut in addition, we should have a branch.$name.push line that\ncan contain a remote head to push to. This can be used to\nmanage push's default on a per-branch basis. So, different\nbranches can have different default refspecs, even when they\nrefer to the same remote.\n\nThe default remote of \"git push\" is either origin, or it is\nspecified in the branch configuration. The following rules\nwould then be used to find the refspecs to push. The first\nrule that matches wins:\n1) Command line overrides (e.g. \"--all\", \"--current\").\n2) Check if branch.$name.push entry is available.\n (Would we allow multiple entries?)\n3) Check if remote.$remotename.push entries are available.\n4) Use default rule, which pushes matching branches.\n\n\tSteffen\n"},{"id":"60610","messageId":"47453551.3060502@op5.se","threadId":"10954","inReplyTo":"C297CFC3-8DD0-4EEE-8FD3-BF997F6E269A@zib.de","subject":"Re: Adding push configuration to .git/config","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-22T07:52:49Z","receivedAt":"2007-11-22T07:52:49Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Steffen Prohaska wrote:\n> \n> On Nov 22, 2007, at 2:48 AM, Junio C Hamano wrote:\n> \n>> Nico -telmich- Schottelius \n>> writes:\n>>\n>>> Nice would be\n>>>\n>>> [branch \"master\"]\n>>> remote-push = origin\n>>> remote-push-merge = another_branch\n>>>\n>>> And thus perhaps also changing the existing specs:\n>>>\n>>> remote = ... to remote-fetch = ...\n>>> merge = ... to remote-fetch-merge =\n>>\n>> I do not think doing this is worth it, not because I think a\n>> single branch.$name.remote should be good enough for everybody,\n>> but because once you need a separate remote each for fetching\n>> and pushing, there is no reason to say one per direction is\n>> enough.\n>>\n>> An alternative could be to split [remote \"name\"] url into two\n>> variants, fetch-url and push-url. While fetching by default\n>> from two places without telling from which one does not make any\n>> sense, pushing by default to two different places is quite a\n>> normal thing to do, and we already do support more than one url\n>> entries in [remote \"name\"] section used for pushing.\n>>\n>> If we were to do this, it might also make sense to rename the\n>> word 'origin' we use for the default remote name to 'default' or\n>> something. People with shared repository workflow would fetch\n>> from one repository and push back to the same repository, so the\n>> distinction would not matter, but for others who need something\n>> like you suggest, the default repository for fetching and\n>> pushing are different, and while you may still consider where\n>> you fetch from your 'origin', where you push into is not your\n>> 'origin' anymore.\n> \n> I like this idea.\n> \n\nI don't. It's troublesome enough to try to teach the finer points\nof git to my co-workers without different defaults between versions.\n\nSo far we're getting around the problem by the relatively crude\nexpedient of forcing everyone to update to the latest stable from\nmaster each time I say so. It works, but doesn't scale too well, and\nsince every major distro now ships git packages, it would be nice if\ndefault-names at least settled down and were only changed with new\nmajor releases (that is, from 1.x to 2.x).\n\nOn the other hand, I'm sure we'll cope whatever you decide.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"60615","messageId":"7vd4u28z90.fsf@gitster.siamese.dyndns.org","threadId":"10954","inReplyTo":"C297CFC3-8DD0-4EEE-8FD3-BF997F6E269A@zib.de","subject":"Re: Adding push configuration to .git/config","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-22T08:23:39Z","receivedAt":"2007-11-22T08:23:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steffen Prohaska writes:\n\n> On Nov 22, 2007, at 2:48 AM, Junio C Hamano wrote:\n> ...\n>> An alternative could be to split [remote \"name\"] url into two\n>> variants, fetch-url and push-url. While fetching by default\n>> from two places without telling from which one does not make any\n>> sense, pushing by default to two different places is quite a\n>> normal thing to do, and we already do support more than one url\n>> entries in [remote \"name\"] section used for pushing.\n>>\n>> If we were to do this, it might also make sense to rename the\n>> word 'origin' we use for the default remote name to 'default' or\n>> something. People with shared repository workflow would fetch\n>> from one repository and push back to the same repository, so the\n>> distinction would not matter, but for others who need something\n>> like you suggest, the default repository for fetching and\n>> pushing are different, and while you may still consider where\n>> you fetch from your 'origin', where you push into is not your\n>> 'origin' anymore.\n>\n> I like this idea.\n>\n> But in addition, we should have a branch.$name.push line that\n> can contain a remote head to push to.\n\nYes, but.\n\nAt that point, I think you would introduce a mismatch between\nthe traditional semantics of refspec and what you are trying to\ndo, unless you are careful.\n\nThe traditional semantics of refspecs-tied-to-remote is strongly\nbased on the assumption: \"I will push to this remote when these\nlocal branches are all ready to be pushed out, and they will all\ngo there together as an atomic update. When I am _that_ ready\nto push, it does not matter which local branch I am on. The\nbranches that matter are all in good shape when I push.\"\n\nYou are making the behaviour of push dependent on which branch\nyou are on. During such a push, it is safe to assume that the\ncurrent branch is ready to be pushed out, but other ones can be\nvery much un-ready. The user needs a safety valve to prevent\nother branches from being pushed out. Otherwise the user would\nnot be adding branch.$name.push to begin with.\n\nIt would probably need to become a target ref or a list of , not a list of general refspecs like the value for\nremote.$there.push variable. For example, you would want to say\n\"while on master, push it to repository A as refs/heads/master\nand to repository B as refs/remotes/satellite/master\", which\nwould be a typical arrangement if you are working on a satellite\nmachine, A is the shared central repository and B is mothership\nto your satellite machine. The specification would talk only\nabout the target ref (not just \"'can contain' a remote head to\npush to\"), and the source ref would always be the current\nbranch.\n\nI guess you could use general refspec on branch.$name.push and\nimplement the safety by requiring (1) only one refspec appears\nfor such a variable, and (2) the LHS of the refspec matches the\n$name of the branch, in order to make the parsing easier and to\nkeep the syntax uniform.\n\nOr maybe I am being overly cautious again not to introduce any\nmore unnecessary user confusion, and just should give them even\nlonger rope to hang themselves. I dunno.\n"},{"id":"60616","messageId":"7v8x4q8z0e.fsf@gitster.siamese.dyndns.org","threadId":"10954","inReplyTo":"47453551.3060502@op5.se","subject":"Re: Adding push configuration to .git/config","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-22T08:28:49Z","receivedAt":"2007-11-22T08:28:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> Steffen Prohaska wrote:\n>>\n>> On Nov 22, 2007, at 2:48 AM, Junio C Hamano wrote:\n>> ...\n>>> If we were to do this, it might also make sense to rename the\n>>> word 'origin' we use for the default remote name to 'default' or\n>>> something. People with shared repository workflow would fetch\n>>> from one repository and push back to the same repository, so the\n>>> distinction would not matter, but for others who need something\n>>> like you suggest, the default repository for fetching and\n>>> pushing are different, and while you may still consider where\n>>> you fetch from your 'origin', where you push into is not your\n>>> 'origin' anymore.\n>>\n>> I like this idea.\n>\n> I don't. It's troublesome enough to try to teach the finer points\n> of git to my co-workers without different defaults between versions.\n\nI don't like the s/origin/default/ part either, which was the\nreason I said \"it might\". That would be what I would have done\nif I were doing git from scratch right now.\n"},{"id":"60621","messageId":"7E8CB606-6CBD-4736-A2CB-0A1E1BD219D3@zib.de","threadId":"10954","inReplyTo":"7vd4u28z90.fsf@gitster.siamese.dyndns.org","subject":"Re: Adding push configuration to .git/config","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-11-22T08:54:21Z","receivedAt":"2007-11-22T08:54:21Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Nov 22, 2007, at 9:23 AM, Junio C Hamano wrote:\n\n> Steffen Prohaska writes:\n>\n>> On Nov 22, 2007, at 2:48 AM, Junio C Hamano wrote:\n>> ...\n>>> An alternative could be to split [remote \"name\"] url into two\n>>> variants, fetch-url and push-url. While fetching by default\n>>> from two places without telling from which one does not make any\n>>> sense, pushing by default to two different places is quite a\n>>> normal thing to do, and we already do support more than one url\n>>> entries in [remote \"name\"] section used for pushing.\n>>>\n>>> If we were to do this, it might also make sense to rename the\n>>> word 'origin' we use for the default remote name to 'default' or\n>>> something. People with shared repository workflow would fetch\n>>> from one repository and push back to the same repository, so the\n>>> distinction would not matter, but for others who need something\n>>> like you suggest, the default repository for fetching and\n>>> pushing are different, and while you may still consider where\n>>> you fetch from your 'origin', where you push into is not your\n>>> 'origin' anymore.\n>>\n>> I like this idea.\n>>\n>> But in addition, we should have a branch.$name.push line that\n>> can contain a remote head to push to.\n>\n> Yes, but.\n>\n> At that point, I think you would introduce a mismatch between\n> the traditional semantics of refspec and what you are trying to\n> do, unless you are careful.\n>\n> The traditional semantics of refspecs-tied-to-remote is strongly\n> based on the assumption: \"I will push to this remote when these\n> local branches are all ready to be pushed out, and they will all\n> go there together as an atomic update. When I am _that_ ready\n> to push, it does not matter which local branch I am on. The\n> branches that matter are all in good shape when I push.\"\n>\n> You are making the behaviour of push dependent on which branch\n> you are on. During such a push, it is safe to assume that the\n> current branch is ready to be pushed out, but other ones can be\n> very much un-ready. The user needs a safety valve to prevent\n> other branches from being pushed out. Otherwise the user would\n> not be adding branch.$name.push to begin with.\n\nThis is not the only reason. If I'm thinking of a workflow\nbased on a shared repo, I see two more reasons\n\nThe user wants to limit the push to the current branch\nbecause different branches in the remote (shared) repo may\nhave advanced. The user does not want to the see errors by\n\"git push\" that complain about non-fast-forwards. The safety\nvalve is needed to protect from changes in the remote repo\n(not for changes in the local one).\n\nThe second use case is to have multiple local branches that\nrefer to the same (shared) remote branch. If you want to push\nthe changes directly to the (shared) remote branch, you need to\n\"rename\" the branch during the push. But you want to push only\na single branch: the current branch you're on. Hence you need\na per-branch configuration if you want \"git push\" to to the\nwork for you automatically. It would be nice if \"git branch\"\ncould be asked to set up branch.$name.push to point to the\ncorrect remote branch (similar to \"--track\").\n\nWith what I have in mind in the longterm you could do\n\n\tgit checkout -b foo origin/master\n work work work\n\tgit checkout -b bar origin/master\n\twork work work\n\tgit checkout foo\n\tgit pull # or git fetch; git rebase\n\tgit push\n\tgit checkout bar\n\tgit branch -d foo\n work work, ... and later push bar, too\n\nNote, there are several other changes needed before this would\nwork:\n- \"git checkout\" would have to set branch.$name.push.\n- \"-d\" would needs to be accept deletion if all changes are on\n shared remote branch.\n\n\n> It would probably need to become a target ref or a list of target ref>, not a list of general refspecs like the value for\n> remote.$there.push variable. For example, you would want to say\n> \"while on master, push it to repository A as refs/heads/master\n> and to repository B as refs/remotes/satellite/master\", which\n> would be a typical arrangement if you are working on a satellite\n> machine, A is the shared central repository and B is mothership\n> to your satellite machine. The specification would talk only\n> about the target ref (not just \"'can contain' a remote head to\n> push to\"), and the source ref would always be the current\n> branch.\n>\n> I guess you could use general refspec on branch.$name.push and\n> implement the safety by requiring (1) only one refspec appears\n> for such a variable, and (2) the LHS of the refspec matches the\n> $name of the branch, in order to make the parsing easier and to\n> keep the syntax uniform.\n>\n> Or maybe I am being overly cautious again not to introduce any\n> more unnecessary user confusion, and just should give them even\n> longer rope to hang themselves. I dunno.\n\nYes.\n\nIn the simplest version, branch.$name.push should only contain\nthe remote part of the refspec. It should be symmetric to\nbranch.$name.merge.\n\nSo if branch.$name.push is set, \"git push\" means\n\n git push $name:\n\nThis is what I proposed earlier.\n\n\tSteffen\n"},{"id":"60659","messageId":"Pine.LNX.4.64.0711221120300.27959@racer.site","threadId":"10954","inReplyTo":"7E8CB606-6CBD-4736-A2CB-0A1E1BD219D3@zib.de","subject":"Re: Adding push configuration to .git/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-22T11:23:23Z","receivedAt":"2007-11-22T11:23:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 22 Nov 2007, Steffen Prohaska wrote:\n\n> \tgit checkout -b foo origin/master\n> work work work\n> \tgit checkout -b bar origin/master\n> \twork work work\n> \tgit checkout foo\n> \tgit pull # or git fetch; git rebase\n> \tgit push\n> \tgit checkout bar\n> \tgit branch -d foo\n> work work, ... and later push bar, too\n\nI have to say that I slowly grow an antipathy for \"git push\" without \nparameters. _All_ of the confusions with push that I saw stem from being \ntoo lazy to say where and what you want to push. (Okay, there is this \nother thing where people say \"git push origin master:master\" and I still \ndo not know where they got _that_ from.)\n\nI would _never_ teach people to be sloppy here. Even if you introduce \nwhatever appears convenient to you. IMHO this is not only giving rope, \nbut close to putting the noose around the neck.\n\nCiao,\nDscho\n"},{"id":"60672","messageId":"7v7ika5wld.fsf@gitster.siamese.dyndns.org","threadId":"10954","inReplyTo":"Pine.LNX.4.64.0711221120300.27959@racer.site","subject":"Re: Adding push configuration to .git/config","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-22T11:49:18Z","receivedAt":"2007-11-22T11:49:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> I have to say that I slowly grow an antipathy for \"git push\" without \n> parameters. _All_ of the confusions with push that I saw stem from being \n> too lazy to say where and what you want to push.\n\nThe same thing can be said for \"fetch\" by the way.\n"},{"id":"60674","messageId":"47456F08.5020606@op5.se","threadId":"10954","inReplyTo":"7v7ika5wld.fsf@gitster.siamese.dyndns.org","subject":"Re: Adding push configuration to .git/config","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-22T11:59:04Z","receivedAt":"2007-11-22T11:59:04Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Johannes Schindelin writes:\n> \n>> I have to say that I slowly grow an antipathy for \"git push\" without \n>> parameters. _All_ of the confusions with push that I saw stem from being \n>> too lazy to say where and what you want to push.\n> \n> The same thing can be said for \"fetch\" by the way.\n\nI disagree, since \"fetch\" at worst will auto-update the remote-tracking\nbranches only, while \"push\" may publish changes that are downright\nwrong and never meant for publishing. What's worse is that fixing up\npublished history is a whole lot messier than it is to fix ones own\nremote-tracking branches.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"60697","messageId":"D77878D1-127E-4B0C-99DF-D344845B76B0@zib.de","threadId":"10954","inReplyTo":"Pine.LNX.4.64.0711221120300.27959@racer.site","subject":"Re: Adding push configuration to .git/config","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-11-22T18:22:05Z","receivedAt":"2007-11-22T18:22:05Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Nov 22, 2007, at 12:23 PM, Johannes Schindelin wrote:\n\n> I have to say that I slowly grow an antipathy for \"git push\" without\n> parameters. _All_ of the confusions with push that I saw stem from \n> being\n> too lazy to say where and what you want to push. (Okay, there is this\n> other thing where people say \"git push origin master:master\" and I \n> still\n> do not know where they got _that_ from.)\n\n\nI don't agree. \"git push\" should support good defaults. At\nsome point you make the decision to publish, and you use\n\"git push\" for this. If you have a reasonably stable environment\nthere will be a good default, what publishing means.\n\nObviously users should think before they \"git push\". They know\nthat they are publishing, and they (hopefully) understand\nthat they can't easily undo this operation. But I believe\npeople who used any version control system before know that.\nIt's the same for every system. If you publish, others can\nget your source, and this can't easily be reverted.\n\nBut people are lazy, and having a good default is what they\nexpect from a good tool. The default should be safe, and\nreliably do something useful. A good default can safe you\nfrom typing errors. But the default should not do too much,\nand should not do unexpected things; at least not until you\nexplicitly configured.\n\nYou know that I believe the current default is not such a\nchoice. Pushing matching branches sooner or later triggers\nannoying errors if used with a shared remote repository.\nBut this is how the default is; and I'll live with it.\n\nAt least it saves me time. I learnt to ignore the error\nmessages. And we now have '--dry-run'. So I can quickly\ncheck what will happen.\n\nBut, I strongly believe that a tool that expects users to\ntype the current branch and the default remote each time;\njust for publishing some changes to the default location,\nis not what users want.\n\n\tSteffen\n"},{"id":"61388","messageId":"20071128221559.GC22395@denkbrett.schottelius.org","threadId":"10954","inReplyTo":"Pine.LNX.4.64.0711221120300.27959@racer.site","subject":"Re: Adding push configuration to .git/config","fromName":"Nico -telmich- Schottelius","fromEmail":"nico-linux-git@schottelius.org","sentAt":"2007-11-28T22:15:59Z","receivedAt":"2007-11-28T22:15:59Z","isPatch":false,"sender":{"key":"nico-linux-git@schottelius.org","avatar":null},"body":"Hello guys,\n\nI'm replying a bit late, had much to work in the last days.\n\nI really like some ideas discussed here and want to state that\n\n- \"git push\" without options is much easier and does nothing wrong,\n if you configured the branch.$name.pushto correctly\n- I also think that having support for multiple push destinations\n per branch would be excellent for a distributed version control system\n like git\n- doing 'git push origin master:myremote/myname' just covers to much\n redundant data, which imho can (but not must) be put into .git/config\n- I don't care about the configuration names, we can even stick to\n \"merge\" for now and add simply add \"push\" and rename them in git 2.x\n\nI currently would like this variant mostly, allowing high flexibility:\n\n--------------------------------------------------------------------------------\n[remote \"myremote\"]\n url = git+ssh://.... # no change\n ref = refs/heads/ # renamed fetch = ...\n\n# that way we can use the remote for fetch and push:\n\n[branch \"master\"]\n merge = myremote\n push = myremote\n push = anotherremote\n\n[branch \"otherbranch\"]\n merge = otherremote\n push = otherremote\n push = classmate\n push = myremote\n--------------------------------------------------------------------------------\n\nWhat do you think about that approach?\n\nSincerly\n\nNico\n\n-- \nThink about Free and Open Source Software (FOSS).\nhttp://nico.schottelius.org/documentations/foss/the-term-foss/\n\nPGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C\n"},{"id":"61330","messageId":"Pine.LNX.4.64.0711282348360.27959@racer.site","threadId":"10954","inReplyTo":"20071128221559.GC22395@denkbrett.schottelius.org","subject":"Re: Adding push configuration to .git/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-28T23:50:46Z","receivedAt":"2007-11-28T23:50:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 28 Nov 2007, Nico -telmich- Schottelius wrote:\n\n> [branch \"master\"]\n> merge = myremote\n> push = myremote\n> push = anotherremote\n\nThis is not how the current config works. \"merge\" specifies the remote \nref name, \"remote\" specifies the remote.\n\nSo your proposal would imply breaking most existing setups.\n\nCiao,\nDscho\n"},{"id":"61430","messageId":"7v1wa8vfee.fsf@gitster.siamese.dyndns.org","threadId":"10954","inReplyTo":"20071128221559.GC22395@denkbrett.schottelius.org","subject":"Re: Adding push configuration to .git/config","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-29T22:46:33Z","receivedAt":"2007-11-29T22:46:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nico -telmich- Schottelius writes:\n\n> ...\n> [branch \"otherbranch\"]\n> merge = otherremote\n> push = otherremote\n> push = classmate\n> push = myremote\n> --------------------------------------------------------------------------------\n>\n> What do you think about that approach?\n\nHuh?\n\nIs this a reinjection of an ancient message by some gateway?\n\nYou were already told branch.$name.merge has a defined meaning and\nsyntax, and you cannot make it refer to a remote shorthand without\nbreaking an existing setup.\n\nAlso if you want to have more than one destination repository for a\nsingle push, I think that is already supported with remote.$name.url.\n\nIIRC, there was a suggestion to enhance remote.$name configuration in\nthis way instead, so that you can use different URL for fetching and\npushing:\n\n\t[branch \"foo\"]\n remote = \"there\"\n merge = refs/heads/master\n\n\t[remote \"there\"]\n url = git://git.there.xz/repo.git\n push_url = git.there.xz:repo.git\n push_url = git.there.xz:backup.git\n\tfetch = refs/heads/*:refs/remotes/there/*\n\nI further vaguely recall that the comments on the alternative were\npositive (it might have been you who responded, or somebody else, I do\nnot remember).\n"},{"id":"61439","messageId":"finm18$9rk$2@ger.gmane.org","threadId":"10954","inReplyTo":"7v1wa8vfee.fsf@gitster.siamese.dyndns.org","subject":"Re: Adding push configuration to .git/config","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-30T00:37:59Z","receivedAt":"2007-11-30T00:37:59Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> IIRC, there was a suggestion to enhance remote.$name configuration in\n> this way instead, so that you can use different URL for fetching and\n> pushing:\n> \n>         [branch \"foo\"]\n>         remote = \"there\"\n>         merge = refs/heads/master\n> \n>         [remote \"there\"]\n>         url = git://git.there.xz/repo.git\n>         push_url = git.there.xz:repo.git\n>         push_url = git.there.xz:backup.git\n>         fetch = refs/heads/*:refs/remotes/there/*\n> \n> I further vaguely recall that the comments on the alternative were\n> positive (it might have been you who responded, or somebody else, I do\n> not remember).\n\nIf I remember correctly one of the suggestions was to allow for multiple\nURLs, and for fetch use _first_ one that responds, for push use _all_\nthat are _possible_ to push to. Or at least support multiple url for\npush; this way you would have to configure separate remote for fetch and\nfor push, but you would have to push only once to push to all repos.\n\nBut push_url, or pushURL seems like better idea, IMHO.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"}]}