{"thread":{"id":"41842","subject":"[ANNOUNCE] git-push-update, tool to push with \"server-side\" merge or rebase","startedAt":"2016-03-28T08:08:41Z","lastAt":"2016-03-30T04:55:42Z","messageCount":3,"participants":["Max Kirillov","Trevor Saunders"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"281952","messageId":"20160328080841.GA12932@wheezy.local","threadId":"41842","inReplyTo":null,"subject":"[ANNOUNCE] git-push-update, tool to push with \"server-side\" merge or rebase","fromName":"Max Kirillov","fromEmail":"max@max630.net","sentAt":"2016-03-28T08:08:41Z","receivedAt":"2016-03-28T08:08:41Z","isPatch":false,"sender":{"key":"max@max630.net","avatar":"https://avatars.githubusercontent.com/u/381560?v=4"},"body":"Hello.\n\nI would like to announce git-push-update, a tool which emulates\nserver-side merge or rebase.\n\nThe link: https://github.com/max630/git-push-update\n\nIt is a bash script which fetches latest remote branch, creates\ntemporary clone, performs there merge or rebase, pushes results to\nserver. If during the merge or rebase remote branch was updated, it\nfails cleanly, so you are not left with merge which did not go anywhere.\nOr it can even retry the whole task from the beginning, until it\neventually succeeds.\n\nI tried to make it easy to use by unexperienced users by making as few\noptions as possible and checking for some dangerous mistakes. It would\nbe nice if somebody tried to really use it, so there would be some data\ndoes this direction worth exploring. Any other feedback is also welcome.\n\nA longer explanation:\n\nWhile topic branches/pullrequests/whatever-it-named workflow is\nobviously superior to push-to-trunk approach which is used with\ncentralized VCSes, there can be cases to use the latter one. But doing\nit with Git is not easy:\n\n* when the trunk goes forward, user have to run merge or\n  rebase (further \"update\"), interrupting other work which\n  might be in progress.\n* while doing fetch, update and push back a concurrent push can happen,\n  making user to have to repeat it all over.\n* some scenarios allow user to make a mistake combining branches which\n  mean to be unrelated, for example merging or rebasing active\n  development branch into maintenance branch for older version.\n* for a merge case there is a problem of \"evil pull\"\n  (http://thread.gmane.org/gmane.comp.version-control.git/247237)\n  In short: the merges which are to go to remote branch should be \"from\n  local to remote\", and git-pull merges \"from remote to local\".\n\nThis was discussed around some time ago, but I could not find anything\ndone about it. It might seem like nobody really interested much. But I\nstill can see discussions here and there. Also, some time ago extension\n\"pushrebase\" for mercurial appeared, which indicates that there is\nreally a demand.\n\nLooks like current git remote protocol does not really allow server to\ntweak pushed commits: if it accepts reference, client will remember\nexactly the commit it was pushing, no modifications is possible. Also,\nif it is implemented as server-side feature, it might take years to\nappear at github or other big public hostings, if ever. Until that most\nusers would not be able to try it.\n\nThis leaves only one option: perform merge or rebase locally, pretending\nthat it was done at server. It does not even have to be implemented in\ngit itself, instead a wrapper script can do everything.\n\nSo here is the script.\n\n-- \nMax\n"},{"id":"282183","messageId":"20160330012945.GA8888@ball","threadId":"41842","inReplyTo":"20160328080841.GA12932@wheezy.local","subject":"Re: [ANNOUNCE] git-push-update, tool to push with \"server-side\" merge or rebase","fromName":"Trevor Saunders","fromEmail":"tbsaunde@tbsaunde.org","sentAt":"2016-03-30T01:29:45Z","receivedAt":"2016-03-30T01:29:45Z","isPatch":false,"sender":{"key":"tbsaunde@tbsaunde.org","avatar":null},"body":"On Mon, Mar 28, 2016 at 11:08:41AM +0300, Max Kirillov wrote:\n> Hello.\n> \n> I would like to announce git-push-update, a tool which emulates\n> server-side merge or rebase.\n> \n> The link: https://github.com/max630/git-push-update\n> \n> It is a bash script which fetches latest remote branch, creates\n> temporary clone, performs there merge or rebase, pushes results to\n> server. If during the merge or rebase remote branch was updated, it\n> fails cleanly, so you are not left with merge which did not go anywhere.\n> Or it can even retry the whole task from the beginning, until it\n> eventually succeeds.\n> \n> I tried to make it easy to use by unexperienced users by making as few\n> options as possible and checking for some dangerous mistakes. It would\n> be nice if somebody tried to really use it, so there would be some data\n> does this direction worth exploring. Any other feedback is also welcome.\n> \n> A longer explanation:\n> \n> While topic branches/pullrequests/whatever-it-named workflow is\n> obviously superior to push-to-trunk approach which is used with\n> centralized VCSes, there can be cases to use the latter one. But doing\n> it with Git is not easy:\n\nhm how? the workflow you use locally has basically nothingto do with how\npushes work.  I work on several projects daily where everyone pushes to\ntrunk, but locally I use branches.  You just need to fetch rebase then\neither merge your branch into master before pushing or explicitly tell\ngit push what refs to update how.\n\n> * when the trunk goes forward, user have to run merge or\n>   rebase (further \"update\"), interrupting other work which\n>   might be in progress.\n\nI don't really understand this either, if you develope everything on\nmaster then it would seem obvious if you want to update what version of\ntrunk you are using you either need to rebase or merge the remote master\nwith yours.\n\n> * while doing fetch, update and push back a concurrent push can happen,\n>   making user to have to repeat it all over.\n\nI think this is more or less the reason for the hg extension, but I\nthink the script to deal with this is basically\n\nwhile true\ndo\n\tgit fetch origin\n\tgit rebase origin/master\n\tgit push origin HEAD:master && break\ndone\n\nobviously with a little more error checking thrown in if you care.\n\n> * some scenarios allow user to make a mistake combining branches which\n>   mean to be unrelated, for example merging or rebasing active\n>   development branch into maintenance branch for older version.\n> * for a merge case there is a problem of \"evil pull\"\n>   (http://thread.gmane.org/gmane.comp.version-control.git/247237)\n>   In short: the merges which are to go to remote branch should be \"from\n>   local to remote\", and git-pull merges \"from remote to local\".\n> \n> This was discussed around some time ago, but I could not find anything\n> done about it. It might seem like nobody really interested much. But I\n> still can see discussions here and there. Also, some time ago extension\n> \"pushrebase\" for mercurial appeared, which indicates that there is\n> really a demand.\n\nI think that was really for very heavily used repos where there was a\nton of fetch rebase push repeating going on.\n\n> Looks like current git remote protocol does not really allow server to\n> tweak pushed commits: if it accepts reference, client will remember\n> exactly the commit it was pushing, no modifications is possible. Also,\n> if it is implemented as server-side feature, it might take years to\n> appear at github or other big public hostings, if ever. Until that most\n> users would not be able to try it.\n\nI'm not really clear what this is helping for most of those use cases,\nbut if you want to maintain it why not?\n\nTrev\n\n> This leaves only one option: perform merge or rebase locally, pretending\n> that it was done at server. It does not even have to be implemented in\n> git itself, instead a wrapper script can do everything.\n> \n> So here is the script.\n> \n> -- \n> Max\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"282192","messageId":"20160330045542.GA7541@wheezy.local","threadId":"41842","inReplyTo":"20160330012945.GA8888@ball","subject":"Re: [ANNOUNCE] git-push-update, tool to push with \"server-side\" merge or rebase","fromName":"Max Kirillov","fromEmail":"max@max630.net","sentAt":"2016-03-30T04:55:42Z","receivedAt":"2016-03-30T04:55:42Z","isPatch":false,"sender":{"key":"max@max630.net","avatar":"https://avatars.githubusercontent.com/u/381560?v=4"},"body":"On Tue, Mar 29, 2016 at 09:29:45PM -0400, Trevor Saunders wrote:\n> hm how? the workflow you use locally has basically nothingto do with how\n> pushes work.  I work on several projects daily where everyone pushes to\n> trunk, but locally I use branches.  You just need to fetch rebase then\n> either merge your branch into master before pushing or explicitly tell\n> git push what refs to update how.\n\nIf user is confident in manipulating with branches then\nprobably this does not provide much value. Though it also\nto some extent prevents from pushing to wrong branch by\nmistake.\n\n>> * when the trunk goes forward, user have to run merge or\n>>   rebase (further \"update\"), interrupting other work which\n>>   might be in progress.\n> \n> I don't really understand this either, if you develope everything on\n> master then it would seem obvious if you want to update what version of\n> trunk you are using you either need to rebase or merge the remote master\n> with yours.\n\nUpdating your current working branch is not free, if you\nhave a long compilation. Also new changes can break\nsomething. \n\nIn CVCS (think subversion) nobody really updates after each\ncommit to server from anybody. You 'keep uptodate' by\nupdating something like once a day. Otherwise don't have to\nupdate unless somebody touches same file as you. I tried to\nrestore this opportunity.\n\n>> * while doing fetch, update and push back a concurrent push can happen,\n>>   making user to have to repeat it all over.\n> \n> I think this is more or less the reason for the hg extension, but I\n> think the script to deal with this is basically\n> \n> while true\n> do\n> \tgit fetch origin\n> \tgit rebase origin/master\n> \tgit push origin HEAD:master && break\n> done\n> \n> obviously with a little more error checking thrown in if you care.\n\nyes, basically push-update does not do much more than this.\n\n>> This was discussed around some time ago, but I could not find anything\n>> done about it. It might seem like nobody really interested much. But I\n>> still can see discussions here and there. Also, some time ago extension\n>> \"pushrebase\" for mercurial appeared, which indicates that there is\n>> really a demand.\n> \n> I think that was really for very heavily used repos where there was a\n> ton of fetch rebase push repeating going on.\n\nIf does not have to be very heavy. Even small team (3-5\nfulltime coders) can already feel a difference.\n\n> I'm not really clear what this is helping for most of those use cases,\n> but if you want to maintain it why not?\n\nLet's see if anybody uses it. If somebody does then I can try.\n\n-- \nMax\n"}]}