git best strategy for two version development

git best strategy for two version development

[Carlos Pereira]

Hello,

I am a git and CVS newbie, I bought and red most of the excellent Pro 
Git book by Scott Chacon, but I still have a doubt. I have a package 
that I distribute in two versions differing only in one library: 
version_A uses this library, version_B uses my own code to replace it. 
For strategic reasons I want to keep it this way for the time being. 
Both versions have the same documentation, the same data files, and 99% 
of the source code is the same (a few makefile changes, two additional 
files in version_B and some minor changes: a diff -r has only 170 
lines). The question is what is the best strategy to manage a situation 
like this with git?

Shall I maintain two different repositories? I don't think so...

Apparently the best solution would be to maintain two long term 
branches, say mater_A and master_B, and merge all later developments in 
both branches, keeping the initial difference... Specifically:

1) do some new work in branch master_A, commit, etc.
2) checkout master_B and merge the new work in master_B, without merging 
the initial diff between the two versions.

What is the better way to do that?

I suppose this is a fairly common situation, for example, some 
standalone code distributed with two different GUI toolkits. I could 
carefully choose which commits should be merged in both branches (the 
changes in standalone code) and which should not (the changes in GUI 
code), but that is error-prone and seems to miss the whole point of 
using a managment system...

How shall I handle this? Thanks for your help!

Regards,
Carlos Pereira,
http://www.gamgi.org/

Re: git best strategy for two version development

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2535 bytes --]

On Sat, Feb 08, 2014 at 02:06:41AM +0000, Carlos Pereira wrote:
> Hello,
> 
> I am a git and CVS newbie, I bought and red most of the excellent
> Pro Git book by Scott Chacon, but I still have a doubt. I have a
> package that I distribute in two versions differing only in one
> library: version_A uses this library, version_B uses my own code to
> replace it. For strategic reasons I want to keep it this way for the
> time being. Both versions have the same documentation, the same data
> files, and 99% of the source code is the same (a few makefile
> changes, two additional files in version_B and some minor changes: a
> diff -r has only 170 lines). The question is what is the best
> strategy to manage a situation like this with git?
> 
> Shall I maintain two different repositories? I don't think so...
> 
> Apparently the best solution would be to maintain two long term
> branches, say mater_A and master_B, and merge all later developments
> in both branches, keeping the initial difference... Specifically:
> 
> 1) do some new work in branch master_A, commit, etc.
> 2) checkout master_B and merge the new work in master_B, without
> merging the initial diff between the two versions.
> 
> What is the better way to do that?

That's pretty much the way to do it.  If you check in master-A, then
create the master-B branch off of that, copying in the code from B and
checking it in, then when you merge from master-A to master-B, git will
basically do the right thing.  Changes you make on master-A that are
specific to that version will probably conflict, but they should be easy
to fix up.

I basically do this for a consulting project for a client: there's
generic code in master, and a special branch for the client.  Since most
changes don't touch the modified code, conflicts are infrequent, and I
can fix them up when they occur.  I also do it for my dotfiles, which
vary slightly between home and work.

You could also make the changes to master-B as a set of commits on top
of master-A, and always rebase master-B on master-A, but this isn't a
good solution if other people are going to be using your code.  It has
the benefits of keeping the history free of frequent merges, which may
or may not be important to you; it doesn't really bother me very much.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: git best strategy for two version development

[Carlos Pereira]

On 02/08/2014 03:56 AM, brian m. carlson wrote:
> On Sat, Feb 08, 2014 at 02:06:41AM +0000, Carlos Pereira wrote:
>    
>> Hello,
>>
>> I am a git and CVS newbie, I bought and red most of the excellent
>> Pro Git book by Scott Chacon, but I still have a doubt. I have a
>> package that I distribute in two versions differing only in one
>> library: version_A uses this library, version_B uses my own code to
>> replace it. For strategic reasons I want to keep it this way for the
>> time being. Both versions have the same documentation, the same data
>> files, and 99% of the source code is the same (a few makefile
>> changes, two additional files in version_B and some minor changes: a
>> diff -r has only 170 lines). The question is what is the best
>> strategy to manage a situation like this with git?
>>
>> Shall I maintain two different repositories? I don't think so...
>>
>> Apparently the best solution would be to maintain two long term
>> branches, say mater_A and master_B, and merge all later developments
>> in both branches, keeping the initial difference... Specifically:
>>
>> 1) do some new work in branch master_A, commit, etc.
>> 2) checkout master_B and merge the new work in master_B, without
>> merging the initial diff between the two versions.
>>
>> What is the better way to do that?
>>      
> That's pretty much the way to do it.  If you check in master-A, then
> create the master-B branch off of that, copying in the code from B and
> checking it in, then when you merge from master-A to master-B, git will
> basically do the right thing.  Changes you make on master-A that are
> specific to that version will probably conflict, but they should be easy
> to fix up.
>    
You are right! git does not try to merge everything, only changes 
commited on the other branch (branch-A), after creating branch-B... 
otherwise it would be reverting the work done on the current branch, 
which does not make much sense...

Thank you very much...
C
> I basically do this for a consulting project for a client: there's
> generic code in master, and a special branch for the client.  Since most
> changes don't touch the modified code, conflicts are infrequent, and I
> can fix them up when they occur.  I also do it for my dotfiles, which
> vary slightly between home and work.
>
> You could also make the changes to master-B as a set of commits on top
> of master-A, and always rebase master-B on master-A, but this isn't a
> good solution if other people are going to be using your code.  It has
> the benefits of keeping the history free of frequent merges, which may
> or may not be important to you; it doesn't really bother me very much.
>
>    

Re: git best strategy for two version development

[Øystein Walle]

Carlos Pereira <jose.carlos.pereira <at> ist.utl.pt> writes:

> 
> Hello,
> 
> I am a git and CVS newbie, I bought and red most of the excellent Pro 
> Git book by Scott Chacon, but I still have a doubt. I have a package 
> that I distribute in two versions differing only in one library: 
> version_A uses this library, version_B uses my own code to replace it. 
> For strategic reasons I want to keep it this way for the time being. 
> Both versions have the same documentation, the same data files, and 99% 
> of the source code is the same (a few makefile changes, two additional 
> files in version_B and some minor changes: a diff -r has only 170 
> lines). The question is what is the best strategy to manage a situation 
> like this with git?
> 
> Shall I maintain two different repositories? I don't think so...
> 

If the changes are as small as you say, is it an option to use just one
branch but have two possible build configurations? That seems like the
easiest way to do it, in my opinion. E.g.:

    $ make LIB=versionA
    $ make LIB=versionB

Consider the above as pseudo-code, though. I don't know what build
system you use or even if your package is even something that is
"built". But you get the idea.

Øsse