{"thread":{"id":"21494","subject":"Allowing push --dry-run through fetch url","startedAt":"2009-11-06T07:37:07Z","lastAt":"2009-12-29T16:58:23Z","messageCount":11,"participants":["Mike Hommey","Junio C Hamano","Nanako Shiraishi"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"126957","messageId":"20091106073707.GA14881@glandium.org","threadId":"21494","inReplyTo":null,"subject":"Allowing push --dry-run through fetch url","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2009-11-06T07:37:07Z","receivedAt":"2009-11-06T07:37:07Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"Hi,\n\nI am currently considering, when I'll get some time, to dive in the git\npush code to allow push --dry-run without the rights to push.\n\nWe currently have two remote configuration items for urls:\nremote..url and remote..pushurl. The latter is used when\npushing and the former when pulling/fetching.\n\nThe typical use of both at the same time is to put an authenticated\nvalue for pushurl (ssh://, for example) and an anonymous one (git://,\nfor example) for url.\n\nWhat has been annoying me lately is that git push --dry-run asks me\nfor the ssh key or password. I know I could be using an ssh-agent, but\nthat's not the point.\n\nIt would be interesting, to me at least, that git push --dry-run can do\nits job through the git:// url instead of the ssh:// one. But for now,\nall that does is telling me:\nfatal: The remote end hung up unexpectedly\n(probably because the git server doesn't allow pushes at all)\n\nSo, before I dive in, what would you think about such a feature?\n\nThere is one thing that bothers me, though, it's that --dry-run would,\nin the end, not really be a dry-run anymore, and, for example, could\nnot be used to validate that the ssh setup is good without actually\npushing.\n\nCheers,\n\nMike\n"},{"id":"126964","messageId":"7vtyx82g2a.fsf@alter.siamese.dyndns.org","threadId":"21494","inReplyTo":"20091106073707.GA14881@glandium.org","subject":"Re: Allowing push --dry-run through fetch url","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-06T08:49:49Z","receivedAt":"2009-11-06T08:49:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Hommey writes:\n\n> So, before I dive in, what would you think about such a feature?\n\nThe daemon sitting on the other end to serve \"git://\" URL won't understand\nan attempt to push into. What goes over the wire in the fetch protocol\ndoes not give your updated \"git push\" enough information to guess what\nwould happen if you pushed.\n\nOf course, it is open source and everything can be modified. You _could_\nchange the daemon whose primary purpose has been to serve fetch requests\nto also support dry-run only push to make what you outlined work.\n\nBut isn't it adding unnecessary complexity for no real reason? It would\nbe a tough sell, I would imagine.\n"},{"id":"126965","messageId":"20091106085917.GA497@glandium.org","threadId":"21494","inReplyTo":"7vtyx82g2a.fsf@alter.siamese.dyndns.org","subject":"Re: Allowing push --dry-run through fetch url","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2009-11-06T08:59:17Z","receivedAt":"2009-11-06T08:59:17Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Fri, Nov 06, 2009 at 12:49:49AM -0800, Junio C Hamano wrote:\n> The daemon sitting on the other end to serve \"git://\" URL won't understand\n> an attempt to push into. What goes over the wire in the fetch protocol\n> does not give your updated \"git push\" enough information to guess what\n> would happen if you pushed.\n\nMaybe I'm missing something, but the only missing thing I can see at\nfirst thought is whether the server is going to reject non fast-forward\nupdates. Are there any others ?\n\nMike\n"},{"id":"126966","messageId":"7v4op82fh0.fsf@alter.siamese.dyndns.org","threadId":"21494","inReplyTo":"20091106085917.GA497@glandium.org","subject":"Re: Allowing push --dry-run through fetch url","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-06T09:02:35Z","receivedAt":"2009-11-06T09:02:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Hommey writes:\n\n> On Fri, Nov 06, 2009 at 12:49:49AM -0800, Junio C Hamano wrote:\n>> The daemon sitting on the other end to serve \"git://\" URL won't understand\n>> an attempt to push into. What goes over the wire in the fetch protocol\n>> does not give your updated \"git push\" enough information to guess what\n>> would happen if you pushed.\n>\n> Maybe I'm missing something, but the only missing thing I can see at\n> first thought is whether the server is going to reject non fast-forward\n> updates. Are there any others ?\n\nHooks, for a starter.\n"},{"id":"126967","messageId":"20091106092115.GA3449@glandium.org","threadId":"21494","inReplyTo":"7v4op82fh0.fsf@alter.siamese.dyndns.org","subject":"Re: Allowing push --dry-run through fetch url","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2009-11-06T09:21:15Z","receivedAt":"2009-11-06T09:21:15Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Fri, Nov 06, 2009 at 01:02:35AM -0800, Junio C Hamano wrote:\n> > Maybe I'm missing something, but the only missing thing I can see at\n> > first thought is whether the server is going to reject non fast-forward\n> > updates. Are there any others ?\n> \n> Hooks, for a starter.\n\nAFAICS, they are not run when using --dry-run.\n\nMike\n"},{"id":"126969","messageId":"7vfx8s0yy1.fsf@alter.siamese.dyndns.org","threadId":"21494","inReplyTo":"20091106073707.GA14881@glandium.org","subject":"Re: Allowing push --dry-run through fetch url","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-06T09:44:54Z","receivedAt":"2009-11-06T09:44:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Hommey writes:\n\n> The typical use of both at the same time is to put an authenticated\n> value for pushurl (ssh://, for example) and an anonymous one (git://,\n> for example) for url.\n>\n> What has been annoying me lately is that git push --dry-run asks me\n> for the ssh key or password. I know I could be using an ssh-agent, but\n> that's not the point.\n\nI actually sense a possible XY problem here.\n\nWhat are you trying to achieve with \"git push --dry-run\", especially when\nyou would instead be doing an equivalent of \"git fetch\" (or \"ls-remote\")\nbut not storing what you learned from that session with a change like what\nyou are imagining?\n\nThe answer to the above question is the real reason \"X\".\n\nIt could be that what you are interested in is if you are ahead of the\nother side. In other words, you would want to know if some branches\nresult in non-fast-forward error, causing you to re-fetch and re-merge (or\nrebase).\n\nAnd \"push --dry-run\" that fails would give you that information, if it\nworked for you without authenticating. And that could be your \"Y\".\n\nBut doesn't \"branch -v\" give the necessary information for that purpose\nand even a bit more? Couldn't \"git fetch && git branch -v\" be a better\nsolution for your real problem \"X\"?\n\nIt is a better solution _if_ the real problem you are trying to solve is\nwhat I suspected above because:\n\n (1) If you will end up fetching to make you ahead of them again, doing\n \"push --dry-run\" to learn fast-forwardness first would still require\n you to fetch from there anyway. With \"git fetch && git branch -v\",\n you have already fetched when you learned that you are not ahead;\n\n (2) When you learn from \"git fetch && git branch -v\" that you were indeed\n ahead, you can push. In such a case, because you were ahead, the\n fetch wouldn't have slurped a lot of data from the other end anyway,\n so there is no real overhead for doing so.\n\n (3) In either case, \"branch -v\" output would give you not just \"is it\n fast-forward?\" but also \"if not, by how much they have diverged\" (in\n addition to the commit message for the tip).\n\nBut this may not be an XY problem. I am just curious.\n"},{"id":"126971","messageId":"20091106095357.GA13389@glandium.org","threadId":"21494","inReplyTo":"7vfx8s0yy1.fsf@alter.siamese.dyndns.org","subject":"Re: Allowing push --dry-run through fetch url","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2009-11-06T09:53:57Z","receivedAt":"2009-11-06T09:53:57Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Fri, Nov 06, 2009 at 01:44:54AM -0800, Junio C Hamano wrote:\n\n> But doesn't \"branch -v\" give the necessary information for that purpose\n> and even a bit more? Couldn't \"git fetch && git branch -v\" be a better\n> solution for your real problem \"X\"?\n\nUsually, when I run git push --dry-run, it's to check that what follows\n(usually the refspec part) does what I want it to do, such as not pushing\ntags I didn't intend to push(*), and stuff like that.\n\nMike\n\n(*) the fact that all tags from all remotes are being mixed doesn't help,\nhere, and without dry-running, I end up pushing tags from one remote onto\nanother.\n"},{"id":"127091","messageId":"7vfx8obz2o.fsf@alter.siamese.dyndns.org","threadId":"21494","inReplyTo":"20091106095357.GA13389@glandium.org","subject":"Re: Allowing push --dry-run through fetch url","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-08T19:23:27Z","receivedAt":"2009-11-08T19:23:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Hommey writes:\n\n> Usually, when I run git push --dry-run, it's to check that what follows\n> (usually the refspec part) does what I want it to do, such as not pushing\n> tags I didn't intend to push(*), and stuff like that.\n\nAhh, that one.\n\nThat reminds me of a topic that we discussed but went away without\nreaching the conclusion on adding a \"confirmation: are you sure this\npushes what you want?\" to the command. I had a doubt about the patch back\nthen which was that it hardcoded a tty interaction and it would be hard to\nretrofit it to help GUI frontends (so my suggestion was to use something\nlike hooks mechanism, perhaps --confirm=this-script and allow it to do its\nGUI thing), but thinking about it again, they can always use \"expect\" to\ndrive the interaction with the confirmation prompt, so it may not a big\ndeal after all---we might want to resurrect the topic.\n\nThat was an unrelated, independent thought on your comment, but if we did\nso, you might not even have to try to use --dry-run on git:// transport.\n"},{"id":"127128","messageId":"20091109075607.GA16706@glandium.org","threadId":"21494","inReplyTo":"7vfx8obz2o.fsf@alter.siamese.dyndns.org","subject":"Re: Allowing push --dry-run through fetch url","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2009-11-09T07:56:07Z","receivedAt":"2009-11-09T07:56:07Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Sun, Nov 08, 2009 at 11:23:27AM -0800, Junio C Hamano wrote:\n> Mike Hommey writes:\n> \n> > Usually, when I run git push --dry-run, it's to check that what follows\n> > (usually the refspec part) does what I want it to do, such as not pushing\n> > tags I didn't intend to push(*), and stuff like that.\n> \n> Ahh, that one.\n> \n> That reminds me of a topic that we discussed but went away without\n> reaching the conclusion on adding a \"confirmation: are you sure this\n> pushes what you want?\" to the command. I had a doubt about the patch back\n> then which was that it hardcoded a tty interaction and it would be hard to\n> retrofit it to help GUI frontends (so my suggestion was to use something\n> like hooks mechanism, perhaps --confirm=this-script and allow it to do its\n> GUI thing), but thinking about it again, they can always use \"expect\" to\n> drive the interaction with the confirmation prompt, so it may not a big\n> deal after all---we might want to resurrect the topic.\n\nHow about an option to have the confirmation asked, quite like\ncp/mv/rm's -i option ?\n\n> That was an unrelated, independent thought on your comment, but if we did\n> so, you might not even have to try to use --dry-run on git:// transport.\n\nSounds like a good trade-off.\n\nCheers\n\nMike\n"},{"id":"130443","messageId":"20091229200517.6117@nanako3.lavabit.com","threadId":"21494","inReplyTo":"7vfx8obz2o.fsf@alter.siamese.dyndns.org","subject":"Re: Allowing push --dry-run through fetch url","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-12-29T11:05:17Z","receivedAt":"2009-12-29T11:05:17Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Junio, could you tell us what happened to this thread?\n\nAfter discussing \"git push --dry-run\" that looks at URL used for\nfetching, because pushURL might require authentication, the\nmaintainer recalls an earlier \"git push --confirm\" patch\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/128426/focus=128429\n\nbut nothing happens after that.\n"},{"id":"130468","messageId":"7v1vidhg40.fsf@alter.siamese.dyndns.org","threadId":"21494","inReplyTo":"20091229200517.6117@nanako3.lavabit.com","subject":"Re: Allowing push --dry-run through fetch url","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-12-29T16:58:23Z","receivedAt":"2009-12-29T16:58:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nanako Shiraishi writes:\n\n> Junio, could you tell us what happened to this thread?\n>\n> After discussing \"git push --dry-run\" that looks at URL used for\n> fetching, because pushURL might require authentication, the\n> maintainer recalls an earlier \"git push --confirm\" patch\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/128426/focus=128429\n>\n> but nothing happens after that.\n\nYour analysis is correct --- nothing happened after that ;-)\n\nI think it is probably worthwhile to revisit Owen's patch, though. Back\nthen I was worried too much about giving IDE authors (who need to scrape\nthe output and interact with the \"confirm\" interface) enough flexibility\nand wanted to see an interface to allow plugging a more machine readable\ninteraction before proceeding, but I changed my mind.\n\nWe can have --confirm with two output styles, one that is for consumption\nby human sitting in front of a terminal (and is prone to future UI\ntinkering like coloring), and the other with machine readable interaction,\nthat is more or less frozen (or \"extensible\"). And it is perfectly Ok to\nstart only with the human readable one, clearly documented that it is not\n(yet) for use by IDE via scraping.\n\nBut I won't be the person with the --confirm itch, so interested people\nneed to help to make that happen.\n\nThanks for a stream of reminders, by the way.\n"}]}