Thank you, this could work, but if I am adding new file to the feature/removing the existing file from the feature, aliases usage for "add" doesn't help much. I would really need to have the lists of files... and attributes look more promising. On Tue, Jul 11, 2017 at 4:20 PM, Lars Schneider <larsxschneider@xxxxxxxxx> wrote: >> On Tue, Jul 11, 2017 at 1:39 PM, Lars Schneider >> <larsxschneider@xxxxxxxxx> wrote: >>> >>>> On 11 Jul 2017, at 17:45, Nikolay Shustov <nikolay.shustov@xxxxxxxxx> wrote: >>>> >>>> Hi, >>>> I have been recently struggling with migrating my development workflow >>>> from Perforce to Git, all because of the following thing: >>>> >>>> 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 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). >>>> Build takes time and resources and considering that I have to do it on >>>> multiple platforms (I do cross-platform development) it really >>>> denominates the option of not having multiple changes in the same code >>>> tree. >>>> >>>> Am I ignorant about some Git feature/way of using Git that would help? >>>> 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? >>> >>> Interesting question that came up at my workplace, too. >>> >>> Here is what I suggested: >>> 1. Keep working on a single branch and make commits for all features >>> 2. If you make a commit, prefix the commit message with the feature name >>> 3. After you are done with a feature create a new feature branch based on >>> your combined feature branch. Use `git rebase -i` [1] to remove all >>> commits that are not relevant for the feature. Alternatively you could >>> cherry pick the relevant commits [2] if this is faster. >>> >>> I wonder what others think about this solution. Maybe there is a better >>> solution that I overlooked? >>> >>> - Lars >>> >>> [1] https://robots.thoughtbot.com/git-interactive-rebase-squash-amend-rewriting-history >>> [2] http://think-like-a-git.net/sections/rebase-from-the-ground-up/cherry-picking-explained.html >>> > >> On 11 Jul 2017, at 19:54, Nikolay Shustov <nikolay.shustov@xxxxxxxxx> wrote: >> >> Thank you for the idea, however I am having troubles with basically >> maintaining the uncommitted groups of files: I would prefer the clear >> distinction that "those files belong to feature A" and "these files >> belong to feature B", before I commit anything. Committing separately >> every change for feature A and for feature B would probably a good >> option unless I have many changes and then cherry-picking the proper >> commits to create a single changeset for the integration would become >> a nightmare. > > I see. Why so complicated with gitattributes then? > > How about this: > Let's say you start working on featureX that affects file1 and file2 > and featureY that affects file8 and file9 > > 1. Create aliases to add the files: > $ git config --local alias.featx 'add file1 file2' > $ git config --local alias.featy 'add file8 file9' > > 2. Work on the features. Whenever you have something ready for featureX > run this: > $ git featx > $ git commit > > Whenever you have something ready for featureY run this: > $ git featy > $ git commit > > Wouldn't that work? > > - Lars > >
