3

I need support of 3 versions of my program. Where most files are

joint (common) but several files contain different content for each version.

I'll probably use 4 branches A,B,C,D in Git.

Form example project Ice-cream:

____________________________________________________
Cup.txt: { Waffle cup } – common file for all version

Filling.txt { banana } - special file for B version
Filling.txt { strawberries } - special file for C version
Filling.txt { vanilla } - special file for D version
____________________________________________________

A - branch suitable only for global files (Cup.txt)

B,C,D - branch suitable only for Filling.txt file.

For this strategy I need allow to merge only in one direction: A => B,C,D

My question is how to forbid merging from B,C,D to A branches in Git?

how to forbid merging reverse direction

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
Jarikus
  • 774
  • 8
  • 18
  • @Robin, if you're going to insist on such a tag, please at least contribute a wiki excerpt to explain why it's not a horrible abomination of a meta tag. – Charles Dec 23 '13 at 06:43

2 Answers2

3

Regarding source code, it is best to avoid complex merge strategy, and modify PrintBill in order to:

  • separate content specific to client A and B
  • build the right executable for client A and client B by choosing the right source

The idea is the same than the one initially written below: avoid any complex merge strategy.

Now if that kind of refactoring isn't possible, you can try and declare a merge driver, but that won't be always called (only in case of conflicts)

Another approach would be to avoid versioning Filling.txt (that way, no more merge strategy headache).

You can:

  • version 3 different files with values for each environment
  • setup a smudge script (a content filter driver declare in a .gitattributes file) which will automatically on checkout generate, depending on the checked out branch, the right Filling.txt

smudge

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Your suggestion good work if “Filling.txt” be kind of configuration file. And smudge script copy from (FillingB.txt, FillingC.txt) to Filling.txt. But in my project the file “Filling.txt” is a source file, which often edited and must save history on each branch. – Jarikus Dec 22 '13 at 09:12
  • @Jarikus simply make sure your file include templates like @val1@, @val2@, ..., that the smudge script can easily replace. And add a clean script which will update that same file automatically on commit, with any modification you have done to that source file. Like the smudge script,you declare the clean script in a .gitattributes file. – VonC Dec 22 '13 at 09:51
  • Templates not convenient to my instance, because file ‘Filling.txt’ too different on each version. I`am make scheme, for more approach to my problem: http://i.stack.imgur.com/pDb0D.png – Jarikus Dec 22 '13 at 10:04
0

Firstly, I don't think this is really what you want to do.

You want to forbid merging in B-specific stuff into A.

But merging general bug fixes from B to A should be fine.

So you should keep B-specific stuff in separate files.

Anyway, what you need is something like a git pre-receive hook on the "central server", which checks for and prevents additions of "banned files", I think.

But note that if you do keep B-specific stuff in separate files, you don't even need to use git branches to solve this problem. You can just use separate projects with dependencies between them.

Robin Green
  • 32,079
  • 16
  • 104
  • 187