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

Improve this question
1
  • @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. Commented Dec 23, 2013 at 6:43

2 Answers 2

Reset to default
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

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

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 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.
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: i.sstatic.net/pDb0D.png
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.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.