On Mon, Mar 28, 2016 at 11:08:41AM +0300, Max Kirillov wrote: > Hello. > > I would like to announce git-push-update, a tool which emulates > server-side merge or rebase. > > The link: https://github.com/max630/git-push-update > > It is a bash script which fetches latest remote branch, creates > temporary clone, performs there merge or rebase, pushes results to > server. If during the merge or rebase remote branch was updated, it > fails cleanly, so you are not left with merge which did not go anywhere. > Or it can even retry the whole task from the beginning, until it > eventually succeeds. > > I tried to make it easy to use by unexperienced users by making as few > options as possible and checking for some dangerous mistakes. It would > be nice if somebody tried to really use it, so there would be some data > does this direction worth exploring. Any other feedback is also welcome. > > A longer explanation: > > While topic branches/pullrequests/whatever-it-named workflow is > obviously superior to push-to-trunk approach which is used with > centralized VCSes, there can be cases to use the latter one. But doing > it with Git is not easy: hm how? the workflow you use locally has basically nothingto do with how pushes work. I work on several projects daily where everyone pushes to trunk, but locally I use branches. You just need to fetch rebase then either merge your branch into master before pushing or explicitly tell git push what refs to update how. > * when the trunk goes forward, user have to run merge or > rebase (further "update"), interrupting other work which > might be in progress. I don't really understand this either, if you develope everything on master then it would seem obvious if you want to update what version of trunk you are using you either need to rebase or merge the remote master with yours. > * while doing fetch, update and push back a concurrent push can happen, > making user to have to repeat it all over. I think this is more or less the reason for the hg extension, but I think the script to deal with this is basically while true do git fetch origin git rebase origin/master git push origin HEAD:master && break done obviously with a little more error checking thrown in if you care. > * some scenarios allow user to make a mistake combining branches which > mean to be unrelated, for example merging or rebasing active > development branch into maintenance branch for older version. > * for a merge case there is a problem of "evil pull" > (http://thread.gmane.org/gmane.comp.version-control.git/247237) > In short: the merges which are to go to remote branch should be "from > local to remote", and git-pull merges "from remote to local". > > This was discussed around some time ago, but I could not find anything > done about it. It might seem like nobody really interested much. But I > still can see discussions here and there. Also, some time ago extension > "pushrebase" for mercurial appeared, which indicates that there is > really a demand. I think that was really for very heavily used repos where there was a ton of fetch rebase push repeating going on. > Looks like current git remote protocol does not really allow server to > tweak pushed commits: if it accepts reference, client will remember > exactly the commit it was pushing, no modifications is possible. Also, > if it is implemented as server-side feature, it might take years to > appear at github or other big public hostings, if ever. Until that most > users would not be able to try it. I'm not really clear what this is helping for most of those use cases, but if you want to maintain it why not? Trev > This leaves only one option: perform merge or rebase locally, pretending > that it was done at server. It does not even have to be implemented in > git itself, instead a wrapper script can do everything. > > So here is the script. > > -- > Max > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html