6

I would like to avoid git auto merging my composer.json. This way I can have a composer.json in develop branch that uses dev-develop packages, while the one in master only uses dev-master packages.

I could use two composer.json files as suggested here, but I am afraid that I will end up forgetting to add a bundle in my composer.json for master. Especially when automating tasks, this can end up in a disaster.

So actually I would like git to either:

  • Always conflict when merging composer.json, so I can manually edit it before comitting to the branch.
  • Only merge based on the number of lines .. so if a bundle is added / removed, the number of lines changes, then it should merge, conflict, whatever. If the contents of a line change, it may ignore that ..
Community
  • 1
  • 1
rolandow
  • 1,049
  • 1
  • 15
  • 28
  • possible duplicate of [How do I tell git to always select my local version for conflicted merges on a specific file?](http://stackoverflow.com/questions/928646/how-do-i-tell-git-to-always-select-my-local-version-for-conflicted-merges-on-a-s) – Vitalii Zurian Feb 17 '14 at 13:51
  • It is considered a bad practice to include branches, especially branches without versions. Try to include versions whenever you can. This will eliminate the need to maintain two versions of `composer.json`, because the required version constraints will be the same for both of your branches. – Sven Feb 18 '14 at 00:07
  • @thecatontheflat there is no merge conflict, it will merge just fine. That's actually my point: i'd like to force a conflict. – rolandow Feb 18 '14 at 14:52
  • @sven this is mainly for my own packages, maintained with satis .. i want to checkout my develop branches on my staging server. When all is well, I will merge to master, and proceed with releasing the code in production environment. Why is that bad? – rolandow Feb 18 '14 at 14:52
  • 2
    Rethink your development process. If your development branch of the main software depends on every library to also be in their development branch, you cannot really call these "independent libraries", and you should probably not separate them in a different repository. If on the other hand you'd treat your libraries as independent software, you need not rely on them being in a certain branch, but only to have a certain version. Releasing a new version does not affect the main software (it will continue working with the old) unless you deliberately update. – Sven Feb 18 '14 at 15:32
  • As this comment discussion might lead to a better problem description, it would be great if you could update your question and add the news from your comment, i.e. explain how your development process currently works. – Sven Feb 18 '14 at 15:36

1 Answers1

5

While I do tend to agree that the particular scenario you describe might indicate that you have deeper issues with your development process, git can be made to do what you ask pretty easily by setting the merge attribute on the file in question, to one of two values. From the "Performing a three-way merge" section of git help attributes, they are:

merge unset

Take the version from the current branch as the tentative merge result, and declare that the merge has conflicts. This is suitable for binary files that do not have a well-defined merge semantics.

To establish this, do:

echo "composer.json -merge" >> .gitattributes

merge=binary

Keep the version from your branch in the work tree, but leave the path in the conflicted state for the user to sort out.

To establish this, do:

echo "composer.json merge=binary" >> .gitattributes

Both behave the same

These descriptions don't really make clear how the behaviour would differ, and indeed, upon testing, both of them produce this output:

$ git merge develop
warning: Cannot merge binary files: composer.json (HEAD vs. develop)
Auto-merging composer.json
CONFLICT (content): Merge conflict in composer.json
Automatic merge failed; fix conflicts and then commit the result.

$ git status
On branch attr-test-2
You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  (use "git add <file>..." to mark resolution)

        both modified:      composer.json

no changes added to commit (use "git add" and/or "git commit -a")

Since the semantics you want are not necessarily to declare that this file is binary, but just to tell git not to merge it automatically, -merge seems ever so slightly preferable.

Matt McHenry
  • 20,009
  • 8
  • 65
  • 64