0

Say I am working on feature/foo...isn't there a way to prevent a git commit if there are changes to remotes/origin/feature/foo?

Is there any advantage in incorporating the changes before making a new commit?

The only thing I can think of is to force us to use git stash, merge the changes (hopefully with fewer conflicts than otherwise) and then use git stash apply?

Alexander Mills
  • 90,741
  • 139
  • 482
  • 817
  • Why not commit and then `git pull --rebase`? – phd Sep 11 '18 at 10:31
  • Sounds like a good way to get your local changes clobbered by accident – Mad Physicist Sep 11 '18 at 10:45
  • I think a good question here would be why you feel the need to do this? This is actually the way git is designed to work, to allow changes to the same files to be done in parallel, and then later on merge those changes (or you can use rebase if you favor a linear timeline). Why do you feel the need to prevent this kind of use? – Lasse V. Karlsen Sep 11 '18 at 10:53

1 Answers1

3

A Pointer for your question: In principle you can get the state of the remote repository with git fetch. This Command gets the remote state and updates the origin/feature/foo branch. You should be able to use this to build your desired hook.

BUT! In principle you're just trying to recreate a situation where you use git like subversion. The big advantage of git is, that you are able to make commits completely independent of the remote repository. (For example do commits and use them to revert if you make mistakes while you're offline deep inside narnia or something)

If you have the problem that your mergeconflicts are too big too handle it seems more like a problem in your process. Maybe try to focus on smaller feature branches to prevent big mergeconflicts.

So I would guess solving this problem with a commit hook is not the best way to go.

Markus Mauksch
  • 397
  • 1
  • 9
  • Nice reasoning. Not to mention that doing it this way might implicitly clobber local work without asking. Once you have a commit, everything is recorded and you can resolve the problem. – Mad Physicist Sep 11 '18 at 10:47
  • it might help avoid a small commit, and act like a reminder to incorporate changes though, you could override it with --force or something – Alexander Mills Sep 11 '18 at 15:59
  • Why avoid small commits? interactive rebase before pushing to clean up your series for publication, git's excellent for the first-draft work too. – jthill Sep 11 '18 at 19:04
  • small commits are a bonus not a problem. If you don't want too much small commits in your public histry you can rebase (squash) before pushing. in every other case small commits give you more flexibility in debugging (bisect) und going back if you make an experiment that doesn't work out (though i prefer branches for this) – Markus Mauksch Sep 12 '18 at 07:52