9

I'm having a little problem with my colleagues and my commit history becoming unnecessary complicated when working on the same project. The problem is git pull merging non-ff if there is just a single commit difference etc. So I like to fail the git pull if a ff is not possible so that the developer can look at the commits and figure out if a merge or a rebase is more appropriate.

My question: is there a way to set --ff-only by default for all git pull commands on any branch but not for git merge? I'm aware of aliases, but that is not what I'm looking for.

Kevin Schmidt
  • 2,111
  • 2
  • 14
  • 12
  • How are the non-ff commits being generated in the first place? If your colleagues are pushing non-ff updates to the remote something is wrong with the workflow. – Christopher Jul 24 '12 at 02:57
  • If you push a lot to share code between multiple people stuff like this is bound to happen. I don't think it's a workflow problem. – Kevin Schmidt Aug 16 '12 at 16:02

2 Answers2

1

Aliases can sorta do what you need, but I'd have to agree with Christopher that you shouldn't have to be dealing with this in the first place.

Git makes branching easy, so if you want to share some code with people before its ready to merge, push to a branch.

regulatethis
  • 2,322
  • 14
  • 17
0

I think you should base your configs on a branch, as that is how the config file has sections. You can organise the in case of merge do this , in case of rebase do this, as you have to decide your strategy beforehand.

You can look at this question for the branch configs.

zhrist
  • 1,169
  • 11
  • 28