Re: "groups of files" in Git?

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 13, 2017, 18:22 UTC
Message-ID: <xmqqiniwxkmj.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kZaf7=uwCPJoPoDiAO9QS21bchaKZvDzWJi=ewPZw9PXQ@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 12 quoted lines

> On Tue, Jul 11, 2017 at 8:45 AM, Nikolay Shustov
>
>> With Git I cannot seem to finding the possibility to figure out how to
>> achieve the same result. And the problem is that putting change sets
>> on different Git branches (or workdirs, or whatever Git offers that
>> makes the changes to be NOT in the same source tree) is not a viable
>> option from me as I would have to re-build code as I re-integrate the
>> changes between the branches (or whatever changes separation Git
>> feature is used).
>
> you would merge the branches and then run the tests/integration. Yes that
> seems cumbersome.

Sometimes the need to make trial merge for testing cannot be avoided and having branches for separate topics is the only sensible approach, at least in the Git world.

Imagine your project has two components that are interrelated, say, the server and the client, that have to work well with each other. In addition, you want to make sure your updated server works well with existing clients, and vice versa.

One way that naturally maps this scenario to the development workflow is to have a server-update topic and a client-update topic branches, and separate changes to update each side with their own commits:

             s---s---S    server-update topic
            /
    ---o---o----o----M    mainline
            \
             c---c---C    client-update topic

And during the development of these *-update topics, you try three merges:

 (1) Merge S to the mainline M and test the whole thing, to make sure
     that existing client will still be able to talk with the
     updated server.

 (2) Merge C to the mainline M and test the whole thing, to make
     sure that updated clients will still be able to talk with the
     existing server.

 (3) Merge both S and C to the mainline M and test the whole thing,
     to make sure the updated ones talk to each other.

If there is no significant development going on on the mainline in the meantime, (1) and (2) can be done by trying out S and C alone without making a trial merge with M. The same for (3)---it can be just a trial merge between S and C without updates that happened on the mainline.

I'd love to hear from folks in Perforce or other world how they address this scenario with their system.