On Tue, Mar 29, 2016 at 09:29:45PM -0400, Trevor Saunders wrote: > 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. If user is confident in manipulating with branches then probably this does not provide much value. Though it also to some extent prevents from pushing to wrong branch by mistake. >> * 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. Updating your current working branch is not free, if you have a long compilation. Also new changes can break something. In CVCS (think subversion) nobody really updates after each commit to server from anybody. You 'keep uptodate' by updating something like once a day. Otherwise don't have to update unless somebody touches same file as you. I tried to restore this opportunity. >> * 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. yes, basically push-update does not do much more than this. >> 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. If does not have to be very heavy. Even small team (3-5 fulltime coders) can already feel a difference. > I'm not really clear what this is helping for most of those use cases, > but if you want to maintain it why not? Let's see if anybody uses it. If somebody does then I can try. -- 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