Re: "groups of files" in Git?

[Junio C Hamano <gitster@pobox.com>]

Stefan Beller <sbeller@google.com> writes:

> 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.