Prevent commit before pull

We use Eclipse with Git and we have issues when committing before pulling Currently we don't use pull request, but direct pushes to the main/master branch. and failing to (commit and) push because of old commits not pull causes difficulty to merge commits later. Can we ensure/prevent commit(/push) before pulling latest commit(s)? i.e. can we execute in atomic operation pull and commit (and maybe push) instead of just commit?

Last updated 2 years ago

There is no atomic "pull and commit". Is there some magic bullet to do a pull before commit? No. When you say "old commits" preventing push realize that even a commit 1 second (or less) old will prevent a following push. It's a race condition pure and simple. No matter how you try you still need to know how to fix up your local clone to enable the next push if someone managed to push in before you. Note: "git pull" is already a 2-step operation: it does "git fetch" and then "git merge" (if required). Whether or not you allow merge commits is a religious topic for some organizations. I think I'm accurate when I say that there are a lot of Git practitioners who do not want to see merge commits so they arrange the hooks and work-flow to prevent the need for them. In general, the answer to most of these issues is normally resolved by performing a rebase.

Thanks for replying, I understand your comments, but is there a way to make atomic operation for rebase and commit? as git pull --rebase origin master and git commit

There is no way to do so - not possible. On the other hand, it really doesn't matter. Both the rebase and commit are done on the clone. Those operations are racing with the fact that during the time it took to {"git fetch", "git rebase", "git add", "git commit"} another push to the upstream repo may have occurred - which will push a subsequent push from succeeding. It's a definite race condition with no "atomicity" possibility given that the operations are happening in different physical repositories. The best that can happen is some flow-control that enables nobody else to jump in ahead (of course, this will block everyone else so going off on vacation holding the "lock" would be "bad"). You could wire up such a "lock" via a server-side pre-receive hook (but that's a lot of logic...). This type of race condition is not specific to Git. Happens with all SCMs where multiple people are working on the same code at the same time without coordination. Somebody always wins and somebody always loses and the loser needs to merge in the change of the winner. Yes, other SCMs do enable stronger locking but that just slows some things down...