Nikolay Shustov wrote: > 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? I never used Perforce and I'm not even sure I understand your problem, but I thought I'd mention something that nobody else seems to have yet (unless I missed it): First, one thing that seems obvious to me from your description is that these "parallel features" you work on are obviously interdependent, therefore I would rather consider the whole thing as a single feature. Therefore, it makes sense to me to work in a single "topic branch". This doesn't preclude one from separating the changes in logically sensible pieces. Indeed this is par for the course in Git and people do it all the time by dividing the bulk of changes into a carefully chosen series of commits. I think the most common way of doing this is to simply work on the whole thing and once you're happy with it you use "git rebase --interative" in order to "prettify" your history. But, and here comes the part I think nobody mentioned yet, if your feature work is considerably large or spans a considerably long time it may be undesirable to postpone all that work until the very end (perhaps by then you already forgot important information, or perhaps too many changes have accumulated so reviewing them all becomes significantly less efficient). In that case, one solution is to use a "patch management system" which will let you do that work incrementally (going back and forth as needed). If you know mercurial, this is "hg mq". I don't think Git has any such system built-in, but I know there are at least these external tools that integrate with Git: https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Patch-management_Interface_layers Feel free to ignore this if I totally misunderstood your use case. Cheers.
