1

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?

Or alternatively can we do a automatic rebase before push?

Ori Marko
  • 56,308
  • 23
  • 131
  • 233
  • A push will be declined anyway if the remote state of the branch doesn't match the local one (except in the case of a force push), isn't that sufficient? – Joachim Sauer Sep 15 '20 at 08:10
  • @JoachimSauer yes, but then I can't pull because I have commit that doesn't include previous commit(s), I want to avoid such situation which may cause overriding commit during merge – Ori Marko Sep 15 '20 at 08:11
  • I think the correct way to avoid or solve this issue depends a lot on what kind of git workflow you use. Do you use pull requests? Direct pushes to the main/master branch? The technical steps to fix this issue depend on what ("social") contract your team uses when working with git. – Joachim Sauer Sep 15 '20 at 08:13
  • @JoachimSauer Not pull request,Direct pushes to the main/master branch – Ori Marko Sep 15 '20 at 08:14
  • That probably boils down that you will need to use `git pull --rebase origin master` (or configure your pull to always rebase on conflicts). It's the one described as "Centralized Workflow" [in this tutorial](https://www.atlassian.com/git/tutorials/comparing-workflows). – Joachim Sauer Sep 15 '20 at 08:19
  • @JoachimSauer I want to ensure no team member can commit before pull (and rebase) – Ori Marko Sep 15 '20 at 08:26
  • Why? 1. A commit is a purely local operation, not allowing that without a network request breaks the whole idea of git and 2. commiting before pull/rebase is more robust as the changes are written to a formal commit and if the rebase goes wrong it's easy to go to the state before the rebase (which can be a lot trickier if the changes weren't commited). Basically it seems that you want to use GIT as if it was SVN, which I don't think is a good idea. – Joachim Sauer Sep 15 '20 at 08:29
  • @JoachimSauer we are migrating to Git from other source control that doesn't have local operations, and also after commit we can't pull because of other users' commit, so we prefer to do pull before commit and push – Ori Marko Sep 15 '20 at 08:34
  • You could pull if you configured git to rebase on pulls (or if you provide the `--rebase` flag). Again: if you migrate to git expecting all operations to work exactly as before you will run into many confusing issues like this. Forcing git to act as if it wasn't git will lead to pain in the long run. Solve your short-run pain, don't just try to ignore it. – Joachim Sauer Sep 15 '20 at 08:37

2 Answers2

0

You can't really prevent someone to commit before pulling, and given git distributed nature, it doesn't make much sense : even when you pull, you have no way to know if the remote has been updated by someone else in the next second.

Any git workflow has a part that says : if my local changes are not up to date with the remote changes, I have to decide what to do with the remote changes (integrate them ? squash them ?) before pushing.

I think you need to clarify your issues in your other questions, this is how you will fix your workflow.

LeGEC
  • 46,477
  • 5
  • 57
  • 104
0

Here's what I would like: a checkbox in Eclipse preferences so that when I try to do a local commit there will be a check if my local repo is up to date.

So... I make some changes and try to do a local commit. Eclipse does a fetch and since there has been a change I get a warning that reads "Project not up to date with origin. Continue commit or cancel?"

Most likely I cancel, pull in the changes, and then try my commit again.

Jeff Grimshaw
  • 11
  • 1
  • This doesn't answer the question, it's a different question/ask attached to this one. – AlBlue Dec 16 '20 at 20:07
  • @AIBlue You are probably right. But it seemed like the original poster was trying to find a way to avoid having to merge locally committed code with changes made in a remote repository. I was trying to get to his "Can we ensure/prevent commit(/push) before pulling latest commit(s)?" issue by having Eclipse give a warning before the original commit was made. – Jeff Grimshaw Dec 16 '20 at 20:16