git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [ANNOUNCE] git-push-update, tool to push with "server-side" merge or rebase

From
Max Kirillov <max@max630.net>
Date
Mar 30, 2016, 04:55 UTC
Message-ID
<20160330045542.GA7541@wheezy.local>
In-Reply-To
<20160330012945.GA8888@ball>
On Tue, Mar 29, 2016 at 09:29:45PM -0400, Trevor Saunders wrote:
Show 5 quoted lines
> 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.

Show 8 quoted lines
>> * 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.

Show 14 quoted lines
>> * 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.
Show 8 quoted lines
>> 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
Previous: Trevor Saunders
Message 3 of 3 in “[ANNOUNCE] git-push-update, tool to push with "server-side" merge or rebase”
  1. Max KirillovMar 28, 2016
  2. Trevor SaundersMar 30, 2016
  3. Max KirillovMar 30, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.