Only the config file changes ...

Hi I'm new to Git and I've read the manual and tried my best to understand it.

I have a project that is going to have many versions, all the same except for the config file, the unit/functional tests and some display information.

I have seen that I can create branches and then merge them. I wondered if I could create a branch, change the config file information and then decree that the config file in the new branch is not merged.

I read about sub modules but they didn't seam relevant.

Am I barking up the wrong tree here?

Thanks,

Jez Caudle.

Jez Caudle venit, vidit, dixit 02.03.2010 13:06:

Hi I'm new to Git and I've read the manual and tried my best to
understand it.

I have a project that is going to have many versions, all the same
except for the config file, the unit/functional tests and some
display information.

I have seen that I can create branches and then merge them. I
wondered if I could create a branch, change the config file
information and then decree that the config file in the new branch is
not merged.

I read about sub modules but they didn't seam relevant.

Am I barking up the wrong tree here?

You're fellow dogs may need more details in order to decide that ;)

In general, I would recommend one branch (be it master) for changes
which apply to all clients (I guess that's what you mean by "versions,
all the same except..."), and one branch each for specific changes (to
config etc.).

Then just make sure to merge in the right direction, i.e. merge the
general, common branch into the specific ones.

Cheers,
Michael

Sounds good.

The only problem being I find a bug in version C. I fix it in version C, now I want to merge that change back to the master and then out to A,B and then D.


I'm still reading my Git book but I'm thinking of doing it this way:

Master has it's own repository.
Each version has it's own repository that is created by cloning the Master and then removing all the files that are not specific removed from the repository.
When changes are made to the master then simply copy all the non-specific files to each of the versions.

Then I can run my unit/functional tests agains each version and if they all pass - deploy.

Jez.

On 2 Mar 2010, at 13:16, Michael J Gruber wrote:

Jez Caudle venit, vidit, dixit 02.03.2010 13:06:

quoted

Hi I'm new to Git and I've read the manual and tried my best to
understand it.

I have a project that is going to have many versions, all the same
except for the config file, the unit/functional tests and some
display information.

I have seen that I can create branches and then merge them. I
wondered if I could create a branch, change the config file
information and then decree that the config file in the new branch is
not merged.

I read about sub modules but they didn't seam relevant.

Am I barking up the wrong tree here?

You're fellow dogs may need more details in order to decide that ;)

In general, I would recommend one branch (be it master) for changes
which apply to all clients (I guess that's what you mean by "versions,
all the same except..."), and one branch each for specific changes (to
config etc.).

Then just make sure to merge in the right direction, i.e. merge the
general, common branch into the specific ones.

Cheers,
Michael

Jez Caudle venit, vidit, dixit 02.03.2010 14:26:

Sounds good.

The only problem being I find a bug in version C. I fix it in version
C,

Don't do that :)

now I want to merge that change back to the master and then out to
A,B and then D.

If you've done that anyways, you can still cherry-pick that change onto
master, or merge --no-commit and checkout --ours what you don't want merged.

I'm still reading my Git book but I'm thinking of doing it this way:

Master has it's own repository. Each version has it's own repository
that is created by cloning the Master and then removing all the files
that are not specific removed from the repository. When changes are
made to the master then simply copy all the non-specific files to
each of the versions.

I don't think you need to remove any files - you do need them for
testing, don't you? It's just that you don't want to modify them in your
"specific" client repos.

Michael