Nikolay Shustov <nikolay.shustov@xxxxxxxxx> writes:
> I have to work on several features in the same code tree parallel, in
> the same Perforce workspace. The major reason why I cannot work on one
> feature then on another is just because I have to make sure that the
> changes in the related areas of the product play together well.
>
> With Perforce, I can have multiple changelists opened, that group the
> changed files as needed.
>
> 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 ...
Naturally. If these separate changes need to work together, it is
way too inconvenient if these changes do not appear in a single
unified working tree to be built and tested.
> Is it worth considering adding to Git a feature like "group of files"
> that would offer some virtutal grouping of the locally changed files
> in the checked-out branch?
Let's step back and let me make sure if I understand you correctly.
You want to work on a system with two distinct areas (say, the
frontend and the backend), that have to work together, but you want
to make two commits, one for each area. You make changes for both
areas in your working tree, build and test them to make sure the
whole thing works well together, and at the end, you make two
commits.
In your real project, you may be doing more than two areas and more
than two commits, but is the above a good degenerative case that
shows the basic idea? If not, then please disregard all of the
following.
You can make partial commits in Git. In the simplest case, you may
have two separate files backend.py and frontend.py, you make edits
to both files and then make two commits:
$ git commit backend.py
$ git commit frontend.py
Changes to some files may contain both changes for the backend and
for the frontend that does not allow you to separate commits at file
boundary, and Git even lets you handle such a case. If you have the
third file in addition to the above two, called common.py, you could
instead
$ git add backend.py
$ git add -p common.py
to prepare the index to contain only the changes for the backend
part ("add -p" lets you interactively pick and choose the hunks
relevant to the backend part), and conclude the commit for the
backend part with
$ git commit ;# no paths arguments
and then when all the remaining changes are for the frontend part,
you can follow it with
$ git commit -a
to make another commit for the frontend part.
A short answer to your question, provided if I understood you
correctly, is "no, there is no way to say 'backend.py, backend-2.py,
...' are the backend things and call it a filegroup", accompanied by
"a filegroup would only be effective when changes align with file
boundary".
And if your response is "but most of the time changes align with
file boundary", a counter-response is "and most of the time changes
align with directory boundary (in well structured project, at
least), so you can do 'git commit backend/' for all the backend part
without having to name all the paths anyway".
There is an experimental "attributes-limited pathspec" feature in
recent versions of Git, which lets you assign arbitrary sets of
labels to each paths, and using that you may be able to do
$ git commit ':(attr:filegroup=backend).'
and I suspect that would be the closest thing you would want (read
about 'pathspec' in 'git help glossary')
