> The way of Git is that a commit (snapshot) by definition describes a > set of files (The set of all files in the project). So If you need two features > there at the same time, you probably want it in the same commit. Thank you, but if I wanted these two features to be in the same commit, I would have no reasons to see them as two distinctive groups. I mean, groups of uncommitted files. The general problem of not having multiple features in the same code tree is the cost of doing multiple builds and integration testing runs. Now I imagine there could be workaround of having two features developed at different branches and then merging them into 3rd branch for building/testing; however this introduces overhead of maintaining at lest two code trees: one for "dirty changes" where I do the code changes that are not guaranteed to be even build-able and another "build/test" code tree. Plus merging the changes from one to another. A bit too much, IMHO. On Tue, Jul 11, 2017 at 1:18 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > On Tue, Jul 11, 2017 at 8:45 AM, 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. > > So in that case the features are not independent, but related to each other? > In that case you want to have these things in the same working tree as > well as in the same branch. > > Take a look at git.git itself, for example: > > git clone git://github.com/git/git > git log --oneline --graph > > You will see a lot of "Merge X into master/maint" commits, but then > you may want to dive into each feature by: > > git log --oneline e83e71c5e1 > > for example and then you'll see lots of commits (that were developed > in the same branch), but that are closely related. However they are > different enough to be in different commits. (different features, as > I understand) > >> 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). > > you would merge the branches and then run the tests/integration. Yes that > seems cumbersome. > >> 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? > > The way of Git is that a commit (snapshot) by definition describes a > set of files (The set of all files in the project). So If you need two features > there at the same time, you probably want it in the same commit. > > If they are different enough such that you could have them independently, > but really want to test them together, your testing may need to become > more elaborate (test a merge of all feature branches) I would think. > >> >> Thanks in advance, >> - Nikolay
