Nikolay Shustov [off-list ref] 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')
Thank you for the explanation. The example about backend and frontend
is relevant even though I normally have to deal with more layers at
the same time.
However, in my case I have the thing that you have already tried to
address, partially: the changes always align with file boundaries BUT
not with directory boundaries. Imagine you have the stack of backend,
data transport and frontend layers. The feature has to touch all three
layers thus resulting in the changes in the apparently different
directories. Thus, making the distinction by the pathspec (if I
understood it right from reading the documentation) would not help.
The attributes could be a solution, if I could:
1. create attribute designated to the feature
2. "mark" uncommitted files in different directory with that attribute
3. filter the list of unchanged files with such attribute
4. create commit for the files only with the certain attribute
You've kindly demonstrated that #4 is doable; however I could not
clearly get for the Git documentation if #1 - #3 are achievable...
Could you point me to the right place in the documentation, please?
On Tue, Jul 11, 2017 at 1:27 PM, Junio C Hamano [off-list ref] wrote:
Nikolay Shustov [off-list ref] writes:
quoted
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.
quoted
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')
On Tue, Jul 11, 2017 at 11:10 AM, Nikolay Shustov
[off-list ref] wrote:
Thank you for the explanation. The example about backend and frontend
is relevant even though I normally have to deal with more layers at
the same time.
However, in my case I have the thing that you have already tried to
address, partially: the changes always align with file boundaries BUT
not with directory boundaries. Imagine you have the stack of backend,
data transport and frontend layers. The feature has to touch all three
layers thus resulting in the changes in the apparently different
directories. Thus, making the distinction by the pathspec (if I
understood it right from reading the documentation) would not help.
The attributes could be a solution, if I could:
1. create attribute designated to the feature
2. "mark" uncommitted files in different directory with that attribute
1+2 should be answered by the gitattributes man page
https://git-scm.com/docs/gitattributes
3. filter the list of unchanged files with such attribute
This sounds like one of
"git status :(attr:backend) ."
"git status :(exclude,attr:backend) ."
4. create commit for the files only with the certain attribute
You've kindly demonstrated that #4 is doable; however I could not
clearly get for the Git documentation if #1 - #3 are achievable...
Could you point me to the right place in the documentation, please?
Thank you for #3.
As for 1+2, the documentation says:
"Each line in gitattributes file is of form:
pattern attr1 attr2 ...
...
When the pattern matches the path in question, the attributes listed
on the line are given to the path."
My understanding is that to have the bunch of the files in the
separate directories having the same attribute, I would have to, for
each file, create a separate gitattributes line with the exact
paths/filename and needed attribute. Is it would you are suggesting or
I misunderstood the idea?
On Tue, Jul 11, 2017 at 2:19 PM, Stefan Beller [off-list ref] wrote:
On Tue, Jul 11, 2017 at 11:10 AM, Nikolay Shustov
[off-list ref] wrote:
quoted
Thank you for the explanation. The example about backend and frontend
is relevant even though I normally have to deal with more layers at
the same time.
However, in my case I have the thing that you have already tried to
address, partially: the changes always align with file boundaries BUT
not with directory boundaries. Imagine you have the stack of backend,
data transport and frontend layers. The feature has to touch all three
layers thus resulting in the changes in the apparently different
directories. Thus, making the distinction by the pathspec (if I
understood it right from reading the documentation) would not help.
The attributes could be a solution, if I could:
1. create attribute designated to the feature
2. "mark" uncommitted files in different directory with that attribute
1+2 should be answered by the gitattributes man page
https://git-scm.com/docs/gitattributes
quoted
3. filter the list of unchanged files with such attribute
This sounds like one of
"git status :(attr:backend) ."
"git status :(exclude,attr:backend) ."
quoted
4. create commit for the files only with the certain attribute
You've kindly demonstrated that #4 is doable; however I could not
clearly get for the Git documentation if #1 - #3 are achievable...
Could you point me to the right place in the documentation, please?