3 ms·

How do people handle the case where in a large repository, with people committing almost constantly, pushing your changes to a git server on the other side of t

How do people handle the case where in a large repository, with people committing almost constantly, pushing your changes to a git server on the other side of the world becomes quite tricky. By the time my push gets to the server it seems someone has gotten in before me and my repo is out of date. I have to pull the new changes and try again. During busy parts of the day (my afternoon, the U.S morning) you might have to loop this process a few times. If I was to check the code still builds after each of those merges I'd be there all day, so there is some risk there. When we had cvs this wasn't an issue since most changes are to completely different parts of the code base so you don't need their changes.

ambivalence 9y ago
You don't ever push straight to the repo. You enqueue your changeset to be pushed by a central system. At Facebook we call this "asynchronous landing" and you're right, before this became a thing about five years back, at certain times of day it was very tricky to push your changes out. Once you switch to this model, you can do convenient things like landing straight from the review system (by a "Ship it" button), landing after some checks were successfully performed, and so on. Incidentally, this is similar to how merging pull requests by rebasing works on GitHub.
- kingosticks 9y ago
  This does sound like the answer. I wonder if our Atlassian solution supports this, perhaps they call it by another name.
MaxBarraclough 9y ago
One solution is to coordinate who 'owns' master, mutex style, using something like an intranet wiki. When you 'hold the lock', you get to rebase and push, and 'release the lock', and if you've any sense the system will automatically ensure you haven't broken the build. Of course, it's important not to waste time, as this serializes the commit process, as it were.

ambivalence 9y ago

You don't ever push straight to the repo. You enqueue your changeset to be pushed by a central system. At Facebook we call this "asynchronous landing" and you're right, before this became a thing about five years back, at certain times of day it was very tricky to push your changes out. Once you switch to this model, you can do convenient things like landing straight from the review system (by a "Ship it" button), landing after some checks were successfully performed, and so on. Incidentally, this is similar to how merging pull requests by rebasing works on GitHub.

kingosticks 9y ago
This does sound like the answer. I wonder if our Atlassian solution supports this, perhaps they call it by another name.

MaxBarraclough 9y ago

One solution is to coordinate who 'owns' master, mutex style, using something like an intranet wiki. When you 'hold the lock', you get to rebase and push, and 'release the lock', and if you've any sense the system will automatically ensure you haven't broken the build. Of course, it's important not to waste time, as this serializes the commit process, as it were.