{"thread":{"id":"46358","subject":"\"groups of files\" in Git?","startedAt":"2017-07-11T15:45:24Z","lastAt":"2017-07-13T23:40:39Z","messageCount":26,"participants":["Nikolay Shustov","Stefan Beller","Randall S. Becker","Junio C Hamano","Lars Schneider","Fredrik Gustafsson","astian","Igor Djordjevic"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"324197","messageId":"CAEcERAz3vYekvJ8SM1FfdAVsP3LMVqA1O3yoJVThvg-0fPtVCg@mail.gmail.com","threadId":"46358","inReplyTo":null,"subject":"\"groups of files\" in Git?","fromName":"Nikolay Shustov","fromEmail":"nikolay.shustov@gmail.com","sentAt":"2017-07-11T15:45:13Z","receivedAt":"2017-07-11T15:45:24Z","isPatch":false,"sender":{"key":"nikolay.shustov@gmail.com","avatar":null},"body":"Hi,\nI have been recently struggling with migrating my development workflow\nfrom Perforce to Git, all because of the following thing:\n\nI have to work on several features in the same code tree parallel, in\nthe same Perforce workspace. The major reason why I cannot work on one\nfeature then on another is just because I have to make sure that the\nchanges in the related areas of the product play together well.\n\nWith Perforce, I can have multiple changelists opened, that group the\nchanged files as needed.\n\nWith Git I cannot seem to finding the possibility to figure out how to\nachieve the same result. And the problem is that putting change sets\non different Git branches (or workdirs, or whatever Git offers that\nmakes the changes to be NOT in the same source tree) is not a viable\noption from me as I would have to re-build code as I re-integrate the\nchanges between the branches (or whatever changes separation Git\nfeature is used).\nBuild takes time and resources and considering that I have to do it on\nmultiple platforms (I do cross-platform development) it really\ndenominates the option of not having multiple changes in the same code\ntree.\n\nAm I ignorant about some Git feature/way of using Git that would help?\nIs it worth considering adding to Git a feature like \"group of files\"\nthat would offer some virtutal grouping of the locally changed files\nin the checked-out branch?\n\nThanks in advance,\n- Nikolay\n"},{"id":"324204","messageId":"CAGZ79kZaf7=uwCPJoPoDiAO9QS21bchaKZvDzWJi=ewPZw9PXQ@mail.gmail.com","threadId":"46358","inReplyTo":"CAEcERAz3vYekvJ8SM1FfdAVsP3LMVqA1O3yoJVThvg-0fPtVCg@mail.gmail.com","subject":"Re: \"groups of files\" in Git?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-07-11T17:18:00Z","receivedAt":"2017-07-11T17:18:08Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Jul 11, 2017 at 8:45 AM, Nikolay Shustov\n wrote:\n> Hi,\n> I have been recently struggling with migrating my development workflow\n> from Perforce to Git, all because of the following thing:\n>\n> I have to work on several features in the same code tree parallel, in\n> the same Perforce workspace. The major reason why I cannot work on one\n> feature then on another is just because I have to make sure that the\n> changes in the related areas of the product play together well.\n\nSo in that case the features are not independent, but related to each other?\nIn that case you want to have these things in the same working tree as\nwell as in the same branch.\n\nTake a look at git.git itself, for example:\n\n git clone git://github.com/git/git\n git log --oneline --graph\n\nYou will see a lot of \"Merge X into master/maint\" commits, but then\nyou may want to dive into each feature by:\n\n git log --oneline e83e71c5e1\n\nfor example and then you'll see lots of commits (that were developed\nin the same branch), but that are closely related. However they are\ndifferent enough to be in different commits. (different features, as\nI understand)\n\n> With Perforce, I can have multiple changelists opened, that group the\n> changed files as needed.\n>\n> With Git I cannot seem to finding the possibility to figure out how to\n> achieve the same result. And the problem is that putting change sets\n> on different Git branches (or workdirs, or whatever Git offers that\n> makes the changes to be NOT in the same source tree) is not a viable\n> option from me as I would have to re-build code as I re-integrate the\n> changes between the branches (or whatever changes separation Git\n> feature is used).\n\nyou would merge the branches and then run the tests/integration. Yes that\nseems cumbersome.\n\n> Build takes time and resources and considering that I have to do it on\n> multiple platforms (I do cross-platform development) it really\n> denominates the option of not having multiple changes in the same code\n> tree.\n>\n> Am I ignorant about some Git feature/way of using Git that would help?\n> Is it worth considering adding to Git a feature like \"group of files\"\n> that would offer some virtutal grouping of the locally changed files\n> in the checked-out branch?\n\nThe way of Git is that a commit (snapshot) by definition describes a\nset of files (The set of all files in the project). So If you need two features\nthere at the same time, you probably want it in the same commit.\n\nIf they are different enough such that you could have them independently,\nbut really want to test them together, your testing may need to become\nmore elaborate (test a merge of all feature branches) I would think.\n\n>\n> Thanks in advance,\n> - Nikolay\n"},{"id":"324205","messageId":"000801d2fa6a$eb5e5130$c21af390$@nexbridge.com","threadId":"46358","inReplyTo":"CAEcERAz3vYekvJ8SM1FfdAVsP3LMVqA1O3yoJVThvg-0fPtVCg@mail.gmail.com","subject":"RE: \"groups of files\" in Git?","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2017-07-11T17:27:01Z","receivedAt":"2017-07-11T17:27:24Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"-----Original Message-----\nOn July 11, 2017 11:45 AM Nikolay Shustov wrote:\n>I have been recently struggling with migrating my development workflow from Perforce to Git, all because of the following thing:\n>I have to work on several features in the same code tree parallel, in the same Perforce workspace. The major reason why I cannot\n>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.\n>With Perforce, I can have multiple changelists opened, that group the changed files as needed.\n\n>With Git I cannot seem to finding the possibility to figure out how to achieve the same result. And the problem is\n>that putting change sets on different Git branches (or workdirs, or whatever Git offers that makes the changes to\n>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\n>the changes between the branches (or whatever changes separation Git feature is used).\n>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.\n\nChange sets are core git functionality. When you commit, you commit a group of changes across multiple files, not single file at a time, like most legacy SCM systems. Individual features are managed typically managed using topic branches that can be switched (using checkout) rapidly, which in your case will cause a localized rebuild based on what files were swapped.\n\nIf you need something slightly different than topic branches, do multiple clones off a base integration branch. This will give you multiple working source trees. Switch each clone to its own branch and work with them locally. If you need to move changes from one branch to another, commit, push on one branch, and pull merge to the other branch.\n\nYou could also use stash to accomplish similar things, but I wouldn't.\n\nCheers,\nRandall\n\n"},{"id":"324206","messageId":"xmqqh8yi3mur.fsf@gitster.mtv.corp.google.com","threadId":"46358","inReplyTo":"CAEcERAz3vYekvJ8SM1FfdAVsP3LMVqA1O3yoJVThvg-0fPtVCg@mail.gmail.com","subject":"Re: \"groups of files\" in Git?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-07-11T17:27:40Z","receivedAt":"2017-07-11T17:27:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nikolay Shustov writes:\n\n> I have to work on several features in the same code tree parallel, in\n> the same Perforce workspace. The major reason why I cannot work on one\n> feature then on another is just because I have to make sure that the\n> changes in the related areas of the product play together well.\n>\n> With Perforce, I can have multiple changelists opened, that group the\n> changed files as needed.\n>\n> With Git I cannot seem to finding the possibility to figure out how to\n> achieve the same result. And the problem is that putting change sets\n> on different Git branches (or workdirs, or whatever Git offers that\n> makes the changes to be NOT in the same source tree) is not a viable\n> option from me ...\n\nNaturally. If these separate changes need to work together, it is\nway too inconvenient if these changes do not appear in a single\nunified working tree to be built and tested.\n\n> Is it worth considering adding to Git a feature like \"group of files\"\n> that would offer some virtutal grouping of the locally changed files\n> in the checked-out branch?\n\nLet's step back and let me make sure if I understand you correctly.\nYou want to work on a system with two distinct areas (say, the\nfrontend and the backend), that have to work together, but you want\nto make two commits, one for each area. You make changes for both\nareas in your working tree, build and test them to make sure the\nwhole thing works well together, and at the end, you make two\ncommits. \n\nIn your real project, you may be doing more than two areas and more\nthan two commits, but is the above a good degenerative case that\nshows the basic idea? If not, then please disregard all of the\nfollowing.\n\nYou can make partial commits in Git. In the simplest case, you may\nhave two separate files backend.py and frontend.py, you make edits\nto both files and then make two commits:\n\n\t$ git commit backend.py\n\t$ git commit frontend.py\n\nChanges to some files may contain both changes for the backend and\nfor the frontend that does not allow you to separate commits at file\nboundary, and Git even lets you handle such a case. If you have the\nthird file in addition to the above two, called common.py, you could\ninstead\n\n\t$ git add backend.py\n\t$ git add -p common.py\n\nto prepare the index to contain only the changes for the backend\npart (\"add -p\" lets you interactively pick and choose the hunks\nrelevant to the backend part), and conclude the commit for the\nbackend part with\n\n\t$ git commit ;# no paths arguments\n\nand then when all the remaining changes are for the frontend part,\nyou can follow it with\n\n\t$ git commit -a\n\nto make another commit for the frontend part.\n\nA short answer to your question, provided if I understood you\ncorrectly, is \"no, there is no way to say 'backend.py, backend-2.py,\n...' are the backend things and call it a filegroup\", accompanied by\n\"a filegroup would only be effective when changes align with file\nboundary\".\n\nAnd if your response is \"but most of the time changes align with\nfile boundary\", a counter-response is \"and most of the time changes\nalign with directory boundary (in well structured project, at\nleast), so you can do 'git commit backend/' for all the backend part\nwithout having to name all the paths anyway\".\n\nThere is an experimental \"attributes-limited pathspec\" feature in\nrecent versions of Git, which lets you assign arbitrary sets of\nlabels to each paths, and using that you may be able to do\n\n\t$ git commit ':(attr:filegroup=backend).'\n\nand I suspect that would be the closest thing you would want (read\nabout 'pathspec' in 'git help glossary')\n\n"},{"id":"324207","messageId":"B5FDF25C-ED5A-4CD1-AAD7-04BD8D705C59@gmail.com","threadId":"46358","inReplyTo":"CAEcERAz3vYekvJ8SM1FfdAVsP3LMVqA1O3yoJVThvg-0fPtVCg@mail.gmail.com","subject":"Re: \"groups of files\" in Git?","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-07-11T17:39:04Z","receivedAt":"2017-07-11T17:39:14Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 11 Jul 2017, at 17:45, Nikolay Shustov wrote:\n> \n> Hi,\n> I have been recently struggling with migrating my development workflow\n> from Perforce to Git, all because of the following thing:\n> \n> I have to work on several features in the same code tree parallel, in\n> the same Perforce workspace. The major reason why I cannot work on one\n> feature then on another is just because I have to make sure that the\n> changes in the related areas of the product play together well.\n> \n> With Perforce, I can have multiple changelists opened, that group the\n> changed files as needed.\n> \n> With Git I cannot seem to finding the possibility to figure out how to\n> achieve the same result. And the problem is that putting change sets\n> on different Git branches (or workdirs, or whatever Git offers that\n> makes the changes to be NOT in the same source tree) is not a viable\n> option from me as I would have to re-build code as I re-integrate the\n> changes between the branches (or whatever changes separation Git\n> feature is used).\n> Build takes time and resources and considering that I have to do it on\n> multiple platforms (I do cross-platform development) it really\n> denominates the option of not having multiple changes in the same code\n> tree.\n> \n> Am I ignorant about some Git feature/way of using Git that would help?\n> Is it worth considering adding to Git a feature like \"group of files\"\n> that would offer some virtutal grouping of the locally changed files\n> in the checked-out branch?\n\nInteresting question that came up at my workplace, too.\n\nHere is what I suggested:\n1. Keep working on a single branch and make commits for all features\n2. If you make a commit, prefix the commit message with the feature name\n3. After you are done with a feature create a new feature branch based on\n your combined feature branch. Use `git rebase -i` [1] to remove all\n commits that are not relevant for the feature. Alternatively you could\n cherry pick the relevant commits [2] if this is faster.\n\nI wonder what others think about this solution. Maybe there is a better\nsolution that I overlooked?\n\n- Lars\n\n[1] https://robots.thoughtbot.com/git-interactive-rebase-squash-amend-rewriting-history\n[2] http://think-like-a-git.net/sections/rebase-from-the-ground-up/cherry-picking-explained.html\n\n"},{"id":"324208","messageId":"CAEcERAyU=UqHY0ez8SkJ-1vRmrgB2KcdmwXow59bRHpgs2wQhA@mail.gmail.com","threadId":"46358","inReplyTo":"CAGZ79kZaf7=uwCPJoPoDiAO9QS21bchaKZvDzWJi=ewPZw9PXQ@mail.gmail.com","subject":"Re: \"groups of files\" in Git?","fromName":"Nikolay Shustov","fromEmail":"nikolay.shustov@gmail.com","sentAt":"2017-07-11T17:47:54Z","receivedAt":"2017-07-11T17:48:00Z","isPatch":false,"sender":{"key":"nikolay.shustov@gmail.com","avatar":null},"body":"> The way of Git is that a commit (snapshot) by definition describes a\n> set of files (The set of all files in the project). So If you need two features\n> there at the same time, you probably want it in the same commit.\n\nThank you, but if I wanted these two features to be in the same\ncommit, I would have no reasons to see them as two distinctive groups.\nI mean, groups of uncommitted files.\n\nThe general problem of not having multiple features in the same code\ntree is the cost of doing multiple builds and integration testing\nruns.\nNow I imagine there could be workaround of having two features\ndeveloped at different branches and then merging them into 3rd branch\nfor building/testing; however this introduces overhead of maintaining\nat lest two code trees: one for \"dirty changes\" where I do the code\nchanges that are not guaranteed to be even build-able and another\n\"build/test\" code tree. Plus merging the changes from one to another.\nA bit too much, IMHO.\n\nOn Tue, Jul 11, 2017 at 1:18 PM, Stefan Beller wrote:\n> On Tue, Jul 11, 2017 at 8:45 AM, Nikolay Shustov\n> wrote:\n>> Hi,\n>> I have been recently struggling with migrating my development workflow\n>> from Perforce to Git, all because of the following thing:\n>>\n>> I have to work on several features in the same code tree parallel, in\n>> the same Perforce workspace. The major reason why I cannot work on one\n>> feature then on another is just because I have to make sure that the\n>> changes in the related areas of the product play together well.\n>\n> So in that case the features are not independent, but related to each other?\n> In that case you want to have these things in the same working tree as\n> well as in the same branch.\n>\n> Take a look at git.git itself, for example:\n>\n> git clone git://github.com/git/git\n> git log --oneline --graph\n>\n> You will see a lot of \"Merge X into master/maint\" commits, but then\n> you may want to dive into each feature by:\n>\n> git log --oneline e83e71c5e1\n>\n> for example and then you'll see lots of commits (that were developed\n> in the same branch), but that are closely related. However they are\n> different enough to be in different commits. (different features, as\n> I understand)\n>\n>> With Perforce, I can have multiple changelists opened, that group the\n>> changed files as needed.\n>>\n>> With Git I cannot seem to finding the possibility to figure out how to\n>> achieve the same result. And the problem is that putting change sets\n>> on different Git branches (or workdirs, or whatever Git offers that\n>> makes the changes to be NOT in the same source tree) is not a viable\n>> option from me as I would have to re-build code as I re-integrate the\n>> changes between the branches (or whatever changes separation Git\n>> feature is used).\n>\n> you would merge the branches and then run the tests/integration. Yes that\n> seems cumbersome.\n>\n>> Build takes time and resources and considering that I have to do it on\n>> multiple platforms (I do cross-platform development) it really\n>> denominates the option of not having multiple changes in the same code\n>> tree.\n>>\n>> Am I ignorant about some Git feature/way of using Git that would help?\n>> Is it worth considering adding to Git a feature like \"group of files\"\n>> that would offer some virtutal grouping of the locally changed files\n>> in the checked-out branch?\n>\n> The way of Git is that a commit (snapshot) by definition describes a\n> set of files (The set of all files in the project). So If you need two features\n> there at the same time, you probably want it in the same commit.\n>\n> If they are different enough such that you could have them independently,\n> but really want to test them together, your testing may need to become\n> more elaborate (test a merge of all feature branches) I would think.\n>\n>>\n>> Thanks in advance,\n>> - Nikolay\n"},{"id":"324210","messageId":"CAEcERAxR_G-tVKsUZ7G97E5B8zCzBoqGqAK2U0fz-p5FvRwfUg@mail.gmail.com","threadId":"46358","inReplyTo":"B5FDF25C-ED5A-4CD1-AAD7-04BD8D705C59@gmail.com","subject":"Re: \"groups of files\" in Git?","fromName":"Nikolay Shustov","fromEmail":"nikolay.shustov@gmail.com","sentAt":"2017-07-11T17:54:59Z","receivedAt":"2017-07-11T17:55:05Z","isPatch":false,"sender":{"key":"nikolay.shustov@gmail.com","avatar":null},"body":"Thank you for the idea, however I am having troubles with basically\nmaintaining the uncommitted groups of files: I would prefer the clear\ndistinction that \"those files belong to feature A\" and \"these files\nbelong to feature B\", before I commit anything. Committing separately\nevery change for feature A and for feature B would probably a good\noption unless I have many changes and then cherry-picking the proper\ncommits to create a single changeset for the integration would become\na nightmare.\n\nOn Tue, Jul 11, 2017 at 1:39 PM, Lars Schneider\n wrote:\n>\n>> On 11 Jul 2017, at 17:45, Nikolay Shustov wrote:\n>>\n>> Hi,\n>> I have been recently struggling with migrating my development workflow\n>> from Perforce to Git, all because of the following thing:\n>>\n>> I have to work on several features in the same code tree parallel, in\n>> the same Perforce workspace. The major reason why I cannot work on one\n>> feature then on another is just because I have to make sure that the\n>> changes in the related areas of the product play together well.\n>>\n>> With Perforce, I can have multiple changelists opened, that group the\n>> changed files as needed.\n>>\n>> With Git I cannot seem to finding the possibility to figure out how to\n>> achieve the same result. And the problem is that putting change sets\n>> on different Git branches (or workdirs, or whatever Git offers that\n>> makes the changes to be NOT in the same source tree) is not a viable\n>> option from me as I would have to re-build code as I re-integrate the\n>> changes between the branches (or whatever changes separation Git\n>> feature is used).\n>> Build takes time and resources and considering that I have to do it on\n>> multiple platforms (I do cross-platform development) it really\n>> denominates the option of not having multiple changes in the same code\n>> tree.\n>>\n>> Am I ignorant about some Git feature/way of using Git that would help?\n>> Is it worth considering adding to Git a feature like \"group of files\"\n>> that would offer some virtutal grouping of the locally changed files\n>> in the checked-out branch?\n>\n> Interesting question that came up at my workplace, too.\n>\n> Here is what I suggested:\n> 1. Keep working on a single branch and make commits for all features\n> 2. If you make a commit, prefix the commit message with the feature name\n> 3. After you are done with a feature create a new feature branch based on\n> your combined feature branch. Use `git rebase -i` [1] to remove all\n> commits that are not relevant for the feature. Alternatively you could\n> cherry pick the relevant commits [2] if this is faster.\n>\n> I wonder what others think about this solution. Maybe there is a better\n> solution that I overlooked?\n>\n> - Lars\n>\n> [1] https://robots.thoughtbot.com/git-interactive-rebase-squash-amend-rewriting-history\n> [2] http://think-like-a-git.net/sections/rebase-from-the-ground-up/cherry-picking-explained.html\n>\n"},{"id":"324214","messageId":"CAEcERAzRMo+fRPbc3_MAU2XgKUyaLAeCVsZvCr9FbSjo7u+MfA@mail.gmail.com","threadId":"46358","inReplyTo":"xmqqh8yi3mur.fsf@gitster.mtv.corp.google.com","subject":"Re: \"groups of files\" in Git?","fromName":"Nikolay Shustov","fromEmail":"nikolay.shustov@gmail.com","sentAt":"2017-07-11T18:10:24Z","receivedAt":"2017-07-11T18:10:31Z","isPatch":false,"sender":{"key":"nikolay.shustov@gmail.com","avatar":null},"body":"Thank you for the explanation. The example about backend and frontend\nis relevant even though I normally have to deal with more layers at\nthe same time.\n\nHowever, in my case I have the thing that you have already tried to\naddress, partially: the changes always align with file boundaries BUT\nnot with directory boundaries. Imagine you have the stack of backend,\ndata transport and frontend layers. The feature has to touch all three\nlayers thus resulting in the changes in the apparently different\ndirectories. Thus, making the distinction by the pathspec (if I\nunderstood it right from reading the documentation) would not help.\n\nThe attributes could be a solution, if I could:\n1. create attribute designated to the feature\n2. \"mark\" uncommitted files in different directory with that attribute\n3. filter the list of unchanged files with such attribute\n4. create commit for the files only with the certain attribute\n\nYou've kindly demonstrated that #4 is doable; however I could not\nclearly get for the Git documentation if #1 - #3 are achievable...\nCould you point me to the right place in the documentation, please?\n\n\nOn Tue, Jul 11, 2017 at 1:27 PM, Junio C Hamano wrote:\n> Nikolay Shustov writes:\n>\n>> I have to work on several features in the same code tree parallel, in\n>> the same Perforce workspace. The major reason why I cannot work on one\n>> feature then on another is just because I have to make sure that the\n>> changes in the related areas of the product play together well.\n>>\n>> With Perforce, I can have multiple changelists opened, that group the\n>> changed files as needed.\n>>\n>> With Git I cannot seem to finding the possibility to figure out how to\n>> achieve the same result. And the problem is that putting change sets\n>> on different Git branches (or workdirs, or whatever Git offers that\n>> makes the changes to be NOT in the same source tree) is not a viable\n>> option from me ...\n>\n> Naturally. If these separate changes need to work together, it is\n> way too inconvenient if these changes do not appear in a single\n> unified working tree to be built and tested.\n>\n>> Is it worth considering adding to Git a feature like \"group of files\"\n>> that would offer some virtutal grouping of the locally changed files\n>> in the checked-out branch?\n>\n> Let's step back and let me make sure if I understand you correctly.\n> You want to work on a system with two distinct areas (say, the\n> frontend and the backend), that have to work together, but you want\n> to make two commits, one for each area. You make changes for both\n> areas in your working tree, build and test them to make sure the\n> whole thing works well together, and at the end, you make two\n> commits.\n>\n> In your real project, you may be doing more than two areas and more\n> than two commits, but is the above a good degenerative case that\n> shows the basic idea? If not, then please disregard all of the\n> following.\n>\n> You can make partial commits in Git. In the simplest case, you may\n> have two separate files backend.py and frontend.py, you make edits\n> to both files and then make two commits:\n>\n> $ git commit backend.py\n> $ git commit frontend.py\n>\n> Changes to some files may contain both changes for the backend and\n> for the frontend that does not allow you to separate commits at file\n> boundary, and Git even lets you handle such a case. If you have the\n> third file in addition to the above two, called common.py, you could\n> instead\n>\n> $ git add backend.py\n> $ git add -p common.py\n>\n> to prepare the index to contain only the changes for the backend\n> part (\"add -p\" lets you interactively pick and choose the hunks\n> relevant to the backend part), and conclude the commit for the\n> backend part with\n>\n> $ git commit ;# no paths arguments\n>\n> and then when all the remaining changes are for the frontend part,\n> you can follow it with\n>\n> $ git commit -a\n>\n> to make another commit for the frontend part.\n>\n> A short answer to your question, provided if I understood you\n> correctly, is \"no, there is no way to say 'backend.py, backend-2.py,\n> ...' are the backend things and call it a filegroup\", accompanied by\n> \"a filegroup would only be effective when changes align with file\n> boundary\".\n>\n> And if your response is \"but most of the time changes align with\n> file boundary\", a counter-response is \"and most of the time changes\n> align with directory boundary (in well structured project, at\n> least), so you can do 'git commit backend/' for all the backend part\n> without having to name all the paths anyway\".\n>\n> There is an experimental \"attributes-limited pathspec\" feature in\n> recent versions of Git, which lets you assign arbitrary sets of\n> labels to each paths, and using that you may be able to do\n>\n> $ git commit ':(attr:filegroup=backend).'\n>\n> and I suspect that would be the closest thing you would want (read\n> about 'pathspec' in 'git help glossary')\n>\n"},{"id":"324215","messageId":"CAGZ79kb6-cDo8tmLdJzY=xd-SM_sM0aM9B6=vcKv6DWspmK7vQ@mail.gmail.com","threadId":"46358","inReplyTo":"CAEcERAzRMo+fRPbc3_MAU2XgKUyaLAeCVsZvCr9FbSjo7u+MfA@mail.gmail.com","subject":"Re: \"groups of files\" in Git?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-07-11T18:19:42Z","receivedAt":"2017-07-11T18:19:55Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Jul 11, 2017 at 11:10 AM, Nikolay Shustov\n wrote:\n> Thank you for the explanation. The example about backend and frontend\n> is relevant even though I normally have to deal with more layers at\n> the same time.\n>\n> However, in my case I have the thing that you have already tried to\n> address, partially: the changes always align with file boundaries BUT\n> not with directory boundaries. Imagine you have the stack of backend,\n> data transport and frontend layers. The feature has to touch all three\n> layers thus resulting in the changes in the apparently different\n> directories. Thus, making the distinction by the pathspec (if I\n> understood it right from reading the documentation) would not help.\n>\n> The attributes could be a solution, if I could:\n> 1. create attribute designated to the feature\n> 2. \"mark\" uncommitted files in different directory with that attribute\n\n1+2 should be answered by the gitattributes man page\nhttps://git-scm.com/docs/gitattributes\n\n\n> 3. filter the list of unchanged files with such attribute\n\nThis sounds like one of\n \"git status :(attr:backend) .\"\n \"git status :(exclude,attr:backend) .\"\n\n> 4. create commit for the files only with the certain attribute\n>\n> You've kindly demonstrated that #4 is doable; however I could not\n> clearly get for the Git documentation if #1 - #3 are achievable...\n> Could you point me to the right place in the documentation, please?\n>\n"},{"id":"324217","messageId":"CAEcERAypv3x7rFx8sRHyLV0vtn=vBYzjEF9ykJT19YNCAh6JBQ@mail.gmail.com","threadId":"46358","inReplyTo":"CAGZ79kb6-cDo8tmLdJzY=xd-SM_sM0aM9B6=vcKv6DWspmK7vQ@mail.gmail.com","subject":"Re: \"groups of files\" in Git?","fromName":"Nikolay Shustov","fromEmail":"nikolay.shustov@gmail.com","sentAt":"2017-07-11T18:30:43Z","receivedAt":"2017-07-11T18:30:49Z","isPatch":false,"sender":{"key":"nikolay.shustov@gmail.com","avatar":null},"body":"Thank you for #3.\nAs for 1+2, the documentation says:\n\n\"Each line in gitattributes file is of form:\n\npattern attr1 attr2 ...\n\n...\nWhen the pattern matches the path in question, the attributes listed\non the line are given to the path.\"\n\nMy understanding is that to have the bunch of the files in the\nseparate directories having the same attribute, I would have to, for\neach file, create a separate gitattributes line with the exact\npaths/filename and needed attribute. Is it would you are suggesting or\nI misunderstood the idea?\n\n\nOn Tue, Jul 11, 2017 at 2:19 PM, Stefan Beller wrote:\n> On Tue, Jul 11, 2017 at 11:10 AM, Nikolay Shustov\n> wrote:\n>> Thank you for the explanation. The example about backend and frontend\n>> is relevant even though I normally have to deal with more layers at\n>> the same time.\n>>\n>> However, in my case I have the thing that you have already tried to\n>> address, partially: the changes always align with file boundaries BUT\n>> not with directory boundaries. Imagine you have the stack of backend,\n>> data transport and frontend layers. The feature has to touch all three\n>> layers thus resulting in the changes in the apparently different\n>> directories. Thus, making the distinction by the pathspec (if I\n>> understood it right from reading the documentation) would not help.\n>>\n>> The attributes could be a solution, if I could:\n>> 1. create attribute designated to the feature\n>> 2. \"mark\" uncommitted files in different directory with that attribute\n>\n> 1+2 should be answered by the gitattributes man page\n> https://git-scm.com/docs/gitattributes\n>\n>\n>> 3. filter the list of unchanged files with such attribute\n>\n> This sounds like one of\n> \"git status :(attr:backend) .\"\n> \"git status :(exclude,attr:backend) .\"\n>\n>> 4. create commit for the files only with the certain attribute\n>>\n>> You've kindly demonstrated that #4 is doable; however I could not\n>> clearly get for the Git documentation if #1 - #3 are achievable...\n>> Could you point me to the right place in the documentation, please?\n>>\n"},{"id":"324228","messageId":"20170711200954.GA14625@paksenarrion.iveqy.com","threadId":"46358","inReplyTo":"CAEcERAz3vYekvJ8SM1FfdAVsP3LMVqA1O3yoJVThvg-0fPtVCg@mail.gmail.com","subject":"Re: \"groups of files\" in Git?","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2017-07-11T20:09:54Z","receivedAt":"2017-07-11T20:03:13Z","isPatch":false,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"Hi,\nI will choose a bit of a less diplomatic path here. Instead of trying to\ntell you how you can make git fit your needs, I would say that you\nshouldn't. I've two arguments:\n\n1.\nIt's always painful when you try to use a tool in some way it's not\nintended or used to work. If you're doing something different than\nanyone else using that tool, you're probably doing something wrong!\n\nI doubt that your case is so special, so my suggestion is to either use\ngit the way most people use it, with one branch for each feature, or do\nnot use git at all, since perforce seems to be better with your\nworkstyle.\n\n2.\nGit is a snapshot based SCM system. That means that each commit unique\nidentify a version of the code. With your system (as well as any time\nyou're not commiting all changed files) the commit is never tested.\nYou've no idea of actually knowing if your two changes is dependent or\nnot. Of course you can guess, but it's still a guess and in your current\nwork way with perforce you have no way of knowing if your changesets\nhave a dependency between eachother or not since you never test them\nindividually.\n\n--\n\nPlease let me know if you feel that I've missed something.\n\nI can see four solutions:\n\n1.\nNow I would suggest that you have each feature in a commit and simply\nrun your tests every few commits so you don't have to run it for each\ncommit.\n\n2.\nImprove your build and test time. I'm sure there's things here to\nimprove.\n\n3.\nContinue to use perforce. If I recall correctly perforce has even a git\nintegration today.\n\n4.\nUse integration branches in git and run the tests on that branch. This\ncan be easy todo if you write some scripts for it.\n\nGood luck!\n\n-- \nFredrik Gustafsson\n\nphone: +46 733-608274\ne-mail: iveqy@iveqy.com\nwebsite: http://www.iveqy.com\n"},{"id":"324229","messageId":"5FDE1F7C-9C01-4C50-996C-920F6E0E2DCB@gmail.com","threadId":"46358","inReplyTo":"CAEcERAxR_G-tVKsUZ7G97E5B8zCzBoqGqAK2U0fz-p5FvRwfUg@mail.gmail.com","subject":"Re: \"groups of files\" in Git?","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-07-11T20:20:37Z","receivedAt":"2017-07-11T20:20:45Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"> On Tue, Jul 11, 2017 at 1:39 PM, Lars Schneider\n> wrote:\n>> \n>>> On 11 Jul 2017, at 17:45, Nikolay Shustov wrote:\n>>> \n>>> Hi,\n>>> I have been recently struggling with migrating my development workflow\n>>> from Perforce to Git, all because of the following thing:\n>>> \n>>> I have to work on several features in the same code tree parallel, in\n>>> the same Perforce workspace. The major reason why I cannot work on one\n>>> feature then on another is just because I have to make sure that the\n>>> changes in the related areas of the product play together well.\n>>> \n>>> With Perforce, I can have multiple changelists opened, that group the\n>>> changed files as needed.\n>>> \n>>> With Git I cannot seem to finding the possibility to figure out how to\n>>> achieve the same result. And the problem is that putting change sets\n>>> on different Git branches (or workdirs, or whatever Git offers that\n>>> makes the changes to be NOT in the same source tree) is not a viable\n>>> option from me as I would have to re-build code as I re-integrate the\n>>> changes between the branches (or whatever changes separation Git\n>>> feature is used).\n>>> Build takes time and resources and considering that I have to do it on\n>>> multiple platforms (I do cross-platform development) it really\n>>> denominates the option of not having multiple changes in the same code\n>>> tree.\n>>> \n>>> Am I ignorant about some Git feature/way of using Git that would help?\n>>> Is it worth considering adding to Git a feature like \"group of files\"\n>>> that would offer some virtutal grouping of the locally changed files\n>>> in the checked-out branch?\n>> \n>> Interesting question that came up at my workplace, too.\n>> \n>> Here is what I suggested:\n>> 1. Keep working on a single branch and make commits for all features\n>> 2. If you make a commit, prefix the commit message with the feature name\n>> 3. After you are done with a feature create a new feature branch based on\n>> your combined feature branch. Use `git rebase -i` [1] to remove all\n>> commits that are not relevant for the feature. Alternatively you could\n>> cherry pick the relevant commits [2] if this is faster.\n>> \n>> I wonder what others think about this solution. Maybe there is a better\n>> solution that I overlooked?\n>> \n>> - Lars\n>> \n>> [1] https://robots.thoughtbot.com/git-interactive-rebase-squash-amend-rewriting-history\n>> [2] http://think-like-a-git.net/sections/rebase-from-the-ground-up/cherry-picking-explained.html\n>> \n\n> On 11 Jul 2017, at 19:54, Nikolay Shustov wrote:\n> \n> Thank you for the idea, however I am having troubles with basically\n> maintaining the uncommitted groups of files: I would prefer the clear\n> distinction that \"those files belong to feature A\" and \"these files\n> belong to feature B\", before I commit anything. Committing separately\n> every change for feature A and for feature B would probably a good\n> option unless I have many changes and then cherry-picking the proper\n> commits to create a single changeset for the integration would become\n> a nightmare.\n\nI see. Why so complicated with gitattributes then?\n\nHow about this:\nLet's say you start working on featureX that affects file1 and file2\nand featureY that affects file8 and file9\n\n1. Create aliases to add the files:\n $ git config --local alias.featx 'add file1 file2'\n $ git config --local alias.featy 'add file8 file9'\n\n2. Work on the features. Whenever you have something ready for featureX\n run this:\n $ git featx\n $ git commit\n\n Whenever you have something ready for featureY run this:\n $ git featy\n $ git commit\n\nWouldn't that work?\n\n- Lars\n\n\n"},{"id":"324238","messageId":"0793138e-5971-d8f6-b25e-215ed5028dae@eclipso.at","threadId":"46358","inReplyTo":"CAEcERAz3vYekvJ8SM1FfdAVsP3LMVqA1O3yoJVThvg-0fPtVCg@mail.gmail.com","subject":"Re: \"groups of files\" in Git?","fromName":"astian","fromEmail":"astian@eclipso.at","sentAt":"2017-07-11T22:27:00Z","receivedAt":"2017-07-11T22:28:03Z","isPatch":false,"sender":{"key":"astian@eclipso.at","avatar":null},"body":"Nikolay Shustov wrote:\n> With Perforce, I can have multiple changelists opened, that group the\n> changed files as needed.\n>\n> With Git I cannot seem to finding the possibility to figure out how to\n> achieve the same result. And the problem is that putting change sets\n> on different Git branches (or workdirs, or whatever Git offers that\n> makes the changes to be NOT in the same source tree) is not a viable\n> option from me as I would have to re-build code as I re-integrate the\n> changes between the branches (or whatever changes separation Git\n> feature is used).\n> Build takes time and resources and considering that I have to do it on\n> multiple platforms (I do cross-platform development) it really\n> denominates the option of not having multiple changes in the same code\n> tree.\n>\n> Am I ignorant about some Git feature/way of using Git that would help?\n> Is it worth considering adding to Git a feature like \"group of files\"\n> that would offer some virtutal grouping of the locally changed files\n> in the checked-out branch?\n\nI never used Perforce and I'm not even sure I understand your problem,\nbut I thought I'd mention something that nobody else seems to have yet\n(unless I missed it):\n\nFirst, one thing that seems obvious to me from your description is that\nthese \"parallel features\" you work on are obviously interdependent,\ntherefore I would rather consider the whole thing as a single feature.\nTherefore, it makes sense to me to work in a single \"topic branch\".\n\nThis doesn't preclude one from separating the changes in logically\nsensible pieces. Indeed this is par for the course in Git and people do\nit all the time by dividing the bulk of changes into a carefully chosen\nseries of commits.\n\nI think the most common way of doing this is to simply work on the whole\nthing and once you're happy with it you use \"git rebase --interative\" in\norder to \"prettify\" your history.\n\nBut, and here comes the part I think nobody mentioned yet, if your\nfeature work is considerably large or spans a considerably long time it\nmay be undesirable to postpone all that work until the very end (perhaps\nby then you already forgot important information, or perhaps too many\nchanges have accumulated so reviewing them all becomes significantly\nless efficient). In that case, one solution is to use a \"patch\nmanagement system\" which will let you do that work incrementally (going\nback and forth as needed).\n\nIf you know mercurial, this is \"hg mq\". I don't think Git has any such\nsystem built-in, but I know there are at least these external tools that\nintegrate with Git:\nhttps://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Patch-management_Interface_layers\n\nFeel free to ignore this if I totally misunderstood your use case.\n\nCheers.\n\n\n"},{"id":"324242","messageId":"6e4096fd-cbab-68f0-7a23-654382cb810e@gmail.com","threadId":"46358","inReplyTo":"B5FDF25C-ED5A-4CD1-AAD7-04BD8D705C59@gmail.com","subject":"Re: \"groups of files\" in Git?","fromName":"Igor Djordjevic","fromEmail":"igor.d.djordjevic@gmail.com","sentAt":"2017-07-11T22:46:02Z","receivedAt":"2017-07-11T22:46:13Z","isPatch":false,"sender":{"key":"igor.d.djordjevic@gmail.com","avatar":null},"body":"For starters, let me say that I consider myself a mere advanced \nbeginner Git user, and I haven`t used Perforce ever before (did some \nreading now), but still, for what it`s worth, here are my thoughts, \nplease bare with me :)\n\nDo feel free to correct me if I miss something.\n\nOn 11/07/2017 19:39, Lars Schneider wrote:\n> \n>> On 11 Jul 2017, at 17:45, Nikolay Shustov wrote:\n>>\n>> Hi,\n>> I have been recently struggling with migrating my development workflow\n>> from Perforce to Git, all because of the following thing:\n>>\n>> I have to work on several features in the same code tree parallel, in\n>> the same Perforce workspace. The major reason why I cannot work on one\n>> feature then on another is just because I have to make sure that the\n>> changes in the related areas of the product play together well.\n>>\n>> With Perforce, I can have multiple changelists opened, that group the\n>> changed files as needed.\n>>\n>> With Git I cannot seem to finding the possibility to figure out how to\n>> achieve the same result. And the problem is that putting change sets\n>> on different Git branches (or workdirs, or whatever Git offers that\n>> makes the changes to be NOT in the same source tree) is not a viable\n>> option from me as I would have to re-build code as I re-integrate the\n>> changes between the branches (or whatever changes separation Git\n>> feature is used).\n>> Build takes time and resources and considering that I have to do it on\n>> multiple platforms (I do cross-platform development) it really\n>> denominates the option of not having multiple changes in the same code\n>> tree.\n>>\n>> Am I ignorant about some Git feature/way of using Git that would help?\n>> Is it worth considering adding to Git a feature like \"group of files\"\n>> that would offer some virtutal grouping of the locally changed files\n>> in the checked-out branch?\n> \n> Interesting question that came up at my workplace, too.\n> \n> Here is what I suggested:\n> 1. Keep working on a single branch and make commits for all features\n> 2. If you make a commit, prefix the commit message with the feature name\n> 3. After you are done with a feature create a new feature branch based on\n> your combined feature branch. Use `git rebase -i` [1] to remove all\n> commits that are not relevant for the feature. Alternatively you could\n> cherry pick the relevant commits [2] if this is faster.\n> \n> I wonder what others think about this solution. Maybe there is a better\n> solution that I overlooked?\n> \n> - Lars\n> \n> [1] https://robots.thoughtbot.com/git-interactive-rebase-squash-amend-rewriting-history\n> [2] http://think-like-a-git.net/sections/rebase-from-the-ground-up/cherry-picking-explained.html\n\nThis \"single branch, related commits\" approach is exactly what came \nto my mind as well.\n\nBut, isn`t Perforce \"changelist\" an \"atomic\" group of changes - like \n\"commit\" in Git, \"changeset\" in Team Foundation Version Control, \netc...?\n\nIf so, it would mean that this \"multiple pending changelists\" flow \nwould/should be translated to \"multiple pending commits\" in Git, \nwhere in the end _a single_ Perforce \"changelist\" is _a single_ Git \n\"commit\".\n\nMight be this is where the confusion is coming from, trying to fit \nnatural Git \"multiple commits per feature\" (but \"single feature per \nbranch\") concept into a \"single changelist per feature\" Perforce \nconcept, described/required here?\n\nI don`t think there is a firm concept of such \"multiple pending \ncommits\" in Git, but the point is the author is having multiple \nchangelists/commits, and it actively updates them (the _same ones_), \nuntil they`re ready to be merged (submitted, in Perforce)... which \nyou can do in Git, and might be quite easily :)\n\nSo... In Git, you can create a separate commit for each changelist \nyou have in Perforce (all these commits being on the same branch, as \ndesired). Then, when you would have wanted to \"update\" the pending \nPerforce changelist (not sure what the corresponding command is in \nPerforce), you would just `git commit` your current state with \nadditional \"--squash\" or \"--fixup\" parameters (depending on if you \nwould like to add more description to existing/original commit \nmessage, or not), and the original commit SHA1.\n\nIn the end, when everything is tested together and you would like to \ncommit features separately (like submitting changelists in Perforce), \nyou would just need to `git rebase -i --autosquash` your branch, \nwhere Git would squash all your \"update\" commits (fixup/squash ones, \nthat is) to the original/initial ones you made as per your \nchangelists/features. No need for manual rearranging, cherry-picking, \nor whatever.\n\nAn example flow, with two \"changelists\" for two features (I`ll be \nusing capital letters A, B, C... instead of commit SHA1, for \nsimplicity):\n\n\t... do some \"Feature 1\" work...\n\t$ git commit -m \"Feature 1\"\n\t... do some \"Feature 2\" work...\n\t$ git commit -m \"Feature 2\"\n\t... do some \"Feature 1\" work...\n\t$ git commit --fixup A\n\t... do some \"Feature 1\" work...\n\t$ git commit --fixup A\n\t... do some \"Feature 2\" work...\n\t$ git commit --squash B\n\t... do some \"Feature 1\" work...\n\t$ git commit --fixup A\n\t... do some \"Feature 1\" work...\n\t$ git commit --squash A\n\t... do some \"Feature 2\" work...\n\t$ git commit --fixup B\n\n\nBranch history would look something like this (H is latest commit):\n\n\tH fixup! Feature 2\n\tG squash! Feature 1\n\tF fixup! Feature 1\n\tE squash! Feature 2\n\tD fixup! Feature 1\n\tC fixup! Feature 1\n\tB Feature 2\n\tA Feature 1\n\n\nWhen you finally do `git rebase -i --autosquash A^`, you should get a \nlist like this[1]:\n\n\tpick A Feature 1\n\tfixup C fixup! Feature 1\n\tfixup D fixup! Feature 1\n\tfixup F fixup! Feature 1\n\tsquash G squash! Feature 1\n\tpick B Feature 2\n\tsquash E squash! Feature 2\n\tfixup H fixup! Feature 2\n\n\nOnce rebase is finished, you`ll end up with branch history looking \nlike this:\n\n\tB' Feature 2\n\tA' Feature 1\n\n... where commits A, C, D, F and G have been squashed into a single \ncommit A', and commits B, E and H have been squashed into a single \ncommit B'. These two single commits should correspond to your two \nPerforce changelists.\n\nNow you can merge your commits separately, as desired (\"submit\" the \n\"changelists\").\n\nYou can even first rearrange/split/squash them further, or make \nseparate branches out of them, whatever you find appropriate - you \ncan do whatever you like to them while they`re your local commits \n(\"pending changelists\"), before making them live/visible for other \nusers as well (merge them to a public branch, \"submit changelist\").\n\np.s. Doesn`t the flow required here look similar to Mercurial patch\n\"queues\" approach (again, resembling \"quilt\" functionality)? If so, \n\"Guilt\"[2] may be an option here as well... if the described flow \ncan`t be altered a bit to align better with Git itself, might be \nprofiting on the side of overall workflow simplicity ;)\n\n[1] Having commits automatically grouped/ordered, you can even \n replace some \"fixup\" and \"squash\" with \"reword\", for example, so \n those commits are kept as separate ones, providing you a chance \n to edit their messages.\n[2] http://repo.or.cz/w/guilt.git\n\nRegards,\nBuga\n"},{"id":"324368","messageId":"CAEcERAyhyiQXyiJ_DdL_UaFMgYnQnxBqP_oFqAcjA6xHDOCZhw@mail.gmail.com","threadId":"46358","inReplyTo":"5FDE1F7C-9C01-4C50-996C-920F6E0E2DCB@gmail.com","subject":"Re: \"groups of files\" in Git?","fromName":"Nikolay Shustov","fromEmail":"nikolay.shustov@gmail.com","sentAt":"2017-07-13T15:21:09Z","receivedAt":"2017-07-13T15:21:16Z","isPatch":false,"sender":{"key":"nikolay.shustov@gmail.com","avatar":null},"body":"Thank you, this could work, but if I am adding new file to the\nfeature/removing the existing file from the feature, aliases usage for\n\"add\" doesn't help much.\nI would really need to have the lists of files... and attributes look\nmore promising.\n\nOn Tue, Jul 11, 2017 at 4:20 PM, Lars Schneider\n wrote:\n>> On Tue, Jul 11, 2017 at 1:39 PM, Lars Schneider\n>> wrote:\n>>>\n>>>> On 11 Jul 2017, at 17:45, Nikolay Shustov wrote:\n>>>>\n>>>> Hi,\n>>>> I have been recently struggling with migrating my development workflow\n>>>> from Perforce to Git, all because of the following thing:\n>>>>\n>>>> I have to work on several features in the same code tree parallel, in\n>>>> the same Perforce workspace. The major reason why I cannot work on one\n>>>> feature then on another is just because I have to make sure that the\n>>>> changes in the related areas of the product play together well.\n>>>>\n>>>> With Perforce, I can have multiple changelists opened, that group the\n>>>> changed files as needed.\n>>>>\n>>>> With Git I cannot seem to finding the possibility to figure out how to\n>>>> achieve the same result. And the problem is that putting change sets\n>>>> on different Git branches (or workdirs, or whatever Git offers that\n>>>> makes the changes to be NOT in the same source tree) is not a viable\n>>>> option from me as I would have to re-build code as I re-integrate the\n>>>> changes between the branches (or whatever changes separation Git\n>>>> feature is used).\n>>>> Build takes time and resources and considering that I have to do it on\n>>>> multiple platforms (I do cross-platform development) it really\n>>>> denominates the option of not having multiple changes in the same code\n>>>> tree.\n>>>>\n>>>> Am I ignorant about some Git feature/way of using Git that would help?\n>>>> Is it worth considering adding to Git a feature like \"group of files\"\n>>>> that would offer some virtutal grouping of the locally changed files\n>>>> in the checked-out branch?\n>>>\n>>> Interesting question that came up at my workplace, too.\n>>>\n>>> Here is what I suggested:\n>>> 1. Keep working on a single branch and make commits for all features\n>>> 2. If you make a commit, prefix the commit message with the feature name\n>>> 3. After you are done with a feature create a new feature branch based on\n>>> your combined feature branch. Use `git rebase -i` [1] to remove all\n>>> commits that are not relevant for the feature. Alternatively you could\n>>> cherry pick the relevant commits [2] if this is faster.\n>>>\n>>> I wonder what others think about this solution. Maybe there is a better\n>>> solution that I overlooked?\n>>>\n>>> - Lars\n>>>\n>>> [1] https://robots.thoughtbot.com/git-interactive-rebase-squash-amend-rewriting-history\n>>> [2] http://think-like-a-git.net/sections/rebase-from-the-ground-up/cherry-picking-explained.html\n>>>\n>\n>> On 11 Jul 2017, at 19:54, Nikolay Shustov wrote:\n>>\n>> Thank you for the idea, however I am having troubles with basically\n>> maintaining the uncommitted groups of files: I would prefer the clear\n>> distinction that \"those files belong to feature A\" and \"these files\n>> belong to feature B\", before I commit anything. Committing separately\n>> every change for feature A and for feature B would probably a good\n>> option unless I have many changes and then cherry-picking the proper\n>> commits to create a single changeset for the integration would become\n>> a nightmare.\n>\n> I see. Why so complicated with gitattributes then?\n>\n> How about this:\n> Let's say you start working on featureX that affects file1 and file2\n> and featureY that affects file8 and file9\n>\n> 1. Create aliases to add the files:\n> $ git config --local alias.featx 'add file1 file2'\n> $ git config --local alias.featy 'add file8 file9'\n>\n> 2. Work on the features. Whenever you have something ready for featureX\n> run this:\n> $ git featx\n> $ git commit\n>\n> Whenever you have something ready for featureY run this:\n> $ git featy\n> $ git commit\n>\n> Wouldn't that work?\n>\n> - Lars\n>\n>\n"},{"id":"324370","messageId":"CAEcERAxRmRh5pp=nXN7X9u=HQsJdSQfsXoedM_5eCDgDWwAkKg@mail.gmail.com","threadId":"46358","inReplyTo":"6e4096fd-cbab-68f0-7a23-654382cb810e@gmail.com","subject":"Re: \"groups of files\" in Git?","fromName":"Nikolay Shustov","fromEmail":"nikolay.shustov@gmail.com","sentAt":"2017-07-13T15:37:20Z","receivedAt":"2017-07-13T15:37:32Z","isPatch":false,"sender":{"key":"nikolay.shustov@gmail.com","avatar":null},"body":"Thank you for the detailed explanation, it looks like merging the\ncommits would be helpful in my case. And I think it is a very good\nanalogy that Perforce changelists are like multiple pending committs,\nif Git were supporting such.\n\nWhat it won't be achieving by using commits in this schema is the\nfollowing thing I can do in Perforce:\nIn the uncommitted Perforce changelists I can revert the changed file\nto the original state and move the files between the changelists.\nQuite often, while working on something, in the middle I would decide\nto isolate changes to a certain set of files to a separate changelsit\n- but then I might change my mind. It is all flexible until I actually\ncommit my Perforce changelist, after which it becomes very much as\ncommitted changes in any other source control.\nThis is actual flexibility I am looking for achieving in Git.\n\n\nOn Tue, Jul 11, 2017 at 6:46 PM, Igor Djordjevic\n wrote:\n> For starters, let me say that I consider myself a mere advanced\n> beginner Git user, and I haven`t used Perforce ever before (did some\n> reading now), but still, for what it`s worth, here are my thoughts,\n> please bare with me :)\n>\n> Do feel free to correct me if I miss something.\n>\n> On 11/07/2017 19:39, Lars Schneider wrote:\n>>\n>>> On 11 Jul 2017, at 17:45, Nikolay Shustov wrote:\n>>>\n>>> Hi,\n>>> I have been recently struggling with migrating my development workflow\n>>> from Perforce to Git, all because of the following thing:\n>>>\n>>> I have to work on several features in the same code tree parallel, in\n>>> the same Perforce workspace. The major reason why I cannot work on one\n>>> feature then on another is just because I have to make sure that the\n>>> changes in the related areas of the product play together well.\n>>>\n>>> With Perforce, I can have multiple changelists opened, that group the\n>>> changed files as needed.\n>>>\n>>> With Git I cannot seem to finding the possibility to figure out how to\n>>> achieve the same result. And the problem is that putting change sets\n>>> on different Git branches (or workdirs, or whatever Git offers that\n>>> makes the changes to be NOT in the same source tree) is not a viable\n>>> option from me as I would have to re-build code as I re-integrate the\n>>> changes between the branches (or whatever changes separation Git\n>>> feature is used).\n>>> Build takes time and resources and considering that I have to do it on\n>>> multiple platforms (I do cross-platform development) it really\n>>> denominates the option of not having multiple changes in the same code\n>>> tree.\n>>>\n>>> Am I ignorant about some Git feature/way of using Git that would help?\n>>> Is it worth considering adding to Git a feature like \"group of files\"\n>>> that would offer some virtutal grouping of the locally changed files\n>>> in the checked-out branch?\n>>\n>> Interesting question that came up at my workplace, too.\n>>\n>> Here is what I suggested:\n>> 1. Keep working on a single branch and make commits for all features\n>> 2. If you make a commit, prefix the commit message with the feature name\n>> 3. After you are done with a feature create a new feature branch based on\n>> your combined feature branch. Use `git rebase -i` [1] to remove all\n>> commits that are not relevant for the feature. Alternatively you could\n>> cherry pick the relevant commits [2] if this is faster.\n>>\n>> I wonder what others think about this solution. Maybe there is a better\n>> solution that I overlooked?\n>>\n>> - Lars\n>>\n>> [1] https://robots.thoughtbot.com/git-interactive-rebase-squash-amend-rewriting-history\n>> [2] http://think-like-a-git.net/sections/rebase-from-the-ground-up/cherry-picking-explained.html\n>\n> This \"single branch, related commits\" approach is exactly what came\n> to my mind as well.\n>\n> But, isn`t Perforce \"changelist\" an \"atomic\" group of changes - like\n> \"commit\" in Git, \"changeset\" in Team Foundation Version Control,\n> etc...?\n>\n> If so, it would mean that this \"multiple pending changelists\" flow\n> would/should be translated to \"multiple pending commits\" in Git,\n> where in the end _a single_ Perforce \"changelist\" is _a single_ Git\n> \"commit\".\n>\n> Might be this is where the confusion is coming from, trying to fit\n> natural Git \"multiple commits per feature\" (but \"single feature per\n> branch\") concept into a \"single changelist per feature\" Perforce\n> concept, described/required here?\n>\n> I don`t think there is a firm concept of such \"multiple pending\n> commits\" in Git, but the point is the author is having multiple\n> changelists/commits, and it actively updates them (the _same ones_),\n> until they`re ready to be merged (submitted, in Perforce)... which\n> you can do in Git, and might be quite easily :)\n>\n> So... In Git, you can create a separate commit for each changelist\n> you have in Perforce (all these commits being on the same branch, as\n> desired). Then, when you would have wanted to \"update\" the pending\n> Perforce changelist (not sure what the corresponding command is in\n> Perforce), you would just `git commit` your current state with\n> additional \"--squash\" or \"--fixup\" parameters (depending on if you\n> would like to add more description to existing/original commit\n> message, or not), and the original commit SHA1.\n>\n> In the end, when everything is tested together and you would like to\n> commit features separately (like submitting changelists in Perforce),\n> you would just need to `git rebase -i --autosquash` your branch,\n> where Git would squash all your \"update\" commits (fixup/squash ones,\n> that is) to the original/initial ones you made as per your\n> changelists/features. No need for manual rearranging, cherry-picking,\n> or whatever.\n>\n> An example flow, with two \"changelists\" for two features (I`ll be\n> using capital letters A, B, C... instead of commit SHA1, for\n> simplicity):\n>\n> ... do some \"Feature 1\" work...\n> $ git commit -m \"Feature 1\"\n> ... do some \"Feature 2\" work...\n> $ git commit -m \"Feature 2\"\n> ... do some \"Feature 1\" work...\n> $ git commit --fixup A\n> ... do some \"Feature 1\" work...\n> $ git commit --fixup A\n> ... do some \"Feature 2\" work...\n> $ git commit --squash B\n> ... do some \"Feature 1\" work...\n> $ git commit --fixup A\n> ... do some \"Feature 1\" work...\n> $ git commit --squash A\n> ... do some \"Feature 2\" work...\n> $ git commit --fixup B\n>\n>\n> Branch history would look something like this (H is latest commit):\n>\n> H fixup! Feature 2\n> G squash! Feature 1\n> F fixup! Feature 1\n> E squash! Feature 2\n> D fixup! Feature 1\n> C fixup! Feature 1\n> B Feature 2\n> A Feature 1\n>\n>\n> When you finally do `git rebase -i --autosquash A^`, you should get a\n> list like this[1]:\n>\n> pick A Feature 1\n> fixup C fixup! Feature 1\n> fixup D fixup! Feature 1\n> fixup F fixup! Feature 1\n> squash G squash! Feature 1\n> pick B Feature 2\n> squash E squash! Feature 2\n> fixup H fixup! Feature 2\n>\n>\n> Once rebase is finished, you`ll end up with branch history looking\n> like this:\n>\n> B' Feature 2\n> A' Feature 1\n>\n> ... where commits A, C, D, F and G have been squashed into a single\n> commit A', and commits B, E and H have been squashed into a single\n> commit B'. These two single commits should correspond to your two\n> Perforce changelists.\n>\n> Now you can merge your commits separately, as desired (\"submit\" the\n> \"changelists\").\n>\n> You can even first rearrange/split/squash them further, or make\n> separate branches out of them, whatever you find appropriate - you\n> can do whatever you like to them while they`re your local commits\n> (\"pending changelists\"), before making them live/visible for other\n> users as well (merge them to a public branch, \"submit changelist\").\n>\n> p.s. Doesn`t the flow required here look similar to Mercurial patch\n> \"queues\" approach (again, resembling \"quilt\" functionality)? If so,\n> \"Guilt\"[2] may be an option here as well... if the described flow\n> can`t be altered a bit to align better with Git itself, might be\n> profiting on the side of overall workflow simplicity ;)\n>\n> [1] Having commits automatically grouped/ordered, you can even\n> replace some \"fixup\" and \"squash\" with \"reword\", for example, so\n> those commits are kept as separate ones, providing you a chance\n> to edit their messages.\n> [2] http://repo.or.cz/w/guilt.git\n>\n> Regards,\n> Buga\n"},{"id":"324376","messageId":"CAEcERAy_OnwzVXPQftm8-TEXF-G0kC4haKCP+CFm31vS8A2XPQ@mail.gmail.com","threadId":"46358","inReplyTo":"0793138e-5971-d8f6-b25e-215ed5028dae@eclipso.at","subject":"Re: \"groups of files\" in Git?","fromName":"Nikolay Shustov","fromEmail":"nikolay.shustov@gmail.com","sentAt":"2017-07-13T17:04:52Z","receivedAt":"2017-07-13T17:05:00Z","isPatch":false,"sender":{"key":"nikolay.shustov@gmail.com","avatar":null},"body":"Thank you taking time to think about my issue (I am actually grateful\nto everyone in this e-mail thread, who did). I looked into Mercurian\nMQ and it doesn't seem to fit what I need - from what I understood, it\nspeaks about the committed changes and those are not amendable. This\nis kinda not what I need.\n\nOn Tue, Jul 11, 2017 at 6:27 PM, astian wrote:\n> Nikolay Shustov wrote:\n>> With Perforce, I can have multiple changelists opened, that group the\n>> changed files as needed.\n>>\n>> With Git I cannot seem to finding the possibility to figure out how to\n>> achieve the same result. And the problem is that putting change sets\n>> on different Git branches (or workdirs, or whatever Git offers that\n>> makes the changes to be NOT in the same source tree) is not a viable\n>> option from me as I would have to re-build code as I re-integrate the\n>> changes between the branches (or whatever changes separation Git\n>> feature is used).\n>> Build takes time and resources and considering that I have to do it on\n>> multiple platforms (I do cross-platform development) it really\n>> denominates the option of not having multiple changes in the same code\n>> tree.\n>>\n>> Am I ignorant about some Git feature/way of using Git that would help?\n>> Is it worth considering adding to Git a feature like \"group of files\"\n>> that would offer some virtutal grouping of the locally changed files\n>> in the checked-out branch?\n>\n> I never used Perforce and I'm not even sure I understand your problem,\n> but I thought I'd mention something that nobody else seems to have yet\n> (unless I missed it):\n>\n> First, one thing that seems obvious to me from your description is that\n> these \"parallel features\" you work on are obviously interdependent,\n> therefore I would rather consider the whole thing as a single feature.\n> Therefore, it makes sense to me to work in a single \"topic branch\".\n>\n> This doesn't preclude one from separating the changes in logically\n> sensible pieces. Indeed this is par for the course in Git and people do\n> it all the time by dividing the bulk of changes into a carefully chosen\n> series of commits.\n>\n> I think the most common way of doing this is to simply work on the whole\n> thing and once you're happy with it you use \"git rebase --interative\" in\n> order to \"prettify\" your history.\n>\n> But, and here comes the part I think nobody mentioned yet, if your\n> feature work is considerably large or spans a considerably long time it\n> may be undesirable to postpone all that work until the very end (perhaps\n> by then you already forgot important information, or perhaps too many\n> changes have accumulated so reviewing them all becomes significantly\n> less efficient). In that case, one solution is to use a \"patch\n> management system\" which will let you do that work incrementally (going\n> back and forth as needed).\n>\n> If you know mercurial, this is \"hg mq\". I don't think Git has any such\n> system built-in, but I know there are at least these external tools that\n> integrate with Git:\n> https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Patch-management_Interface_layers\n>\n> Feel free to ignore this if I totally misunderstood your use case.\n>\n> Cheers.\n>\n>\n"},{"id":"324401","messageId":"xmqqmv88xl7f.fsf@gitster.mtv.corp.google.com","threadId":"46358","inReplyTo":"CAEcERAxRmRh5pp=nXN7X9u=HQsJdSQfsXoedM_5eCDgDWwAkKg@mail.gmail.com","subject":"Re: \"groups of files\" in Git?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-07-13T18:09:40Z","receivedAt":"2017-07-13T18:09:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nikolay Shustov writes:\n\n> Thank you for the detailed explanation, it looks like merging the\n> commits would be helpful in my case. And I think it is a very good\n> analogy that Perforce changelists are like multiple pending committs,\n> if Git were supporting such.\n>\n> What it won't be achieving by using commits in this schema is the\n> following thing I can do in Perforce:\n> In the uncommitted Perforce changelists I can revert the changed file\n> to the original state and move the files between the changelists.\n> Quite often, while working on something, in the middle I would decide\n> to isolate changes to a certain set of files to a separate changelsit\n> - but then I might change my mind. It is all flexible until I actually\n> commit my Perforce changelist, after which it becomes very much as\n> committed changes in any other source control.\n> This is actual flexibility I am looking for achieving in Git.\n\nI actually think we already have such a flexibility. Unlike\nPerforce, Git is distributed, and the most important aspect of the\ndistinction is that what happens _in_ your local Git repository may\nbe called \"committed\" in Git lingo, but not visible to the public.\n\nYou can consider these commits you make in your repository \"pending\"\nwhen you think of your workflow in Perforce terms, until you merge\nand push out the result, which roughly corresponds to \"submitting\"\nin Perforce lingo.\n\nOnce you start treating your local commits that you haven't pushed\nout as changes that are still \"pending\" when observed from the\noutside world, you'd realize that you have as much flexibilty, if\nnot more, to dice and slice them with the local tools like \"rebase\n-i\", \"add -p\", etc., as you would have in your Perforce workflow,\nI would think.\n\n\n"},{"id":"324404","messageId":"xmqqiniwxkmj.fsf@gitster.mtv.corp.google.com","threadId":"46358","inReplyTo":"CAGZ79kZaf7=uwCPJoPoDiAO9QS21bchaKZvDzWJi=ewPZw9PXQ@mail.gmail.com","subject":"Re: \"groups of files\" in Git?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-07-13T18:22:12Z","receivedAt":"2017-07-13T18:22:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> On Tue, Jul 11, 2017 at 8:45 AM, Nikolay Shustov\n>\n>> With Git I cannot seem to finding the possibility to figure out how to\n>> achieve the same result. And the problem is that putting change sets\n>> on different Git branches (or workdirs, or whatever Git offers that\n>> makes the changes to be NOT in the same source tree) is not a viable\n>> option from me as I would have to re-build code as I re-integrate the\n>> changes between the branches (or whatever changes separation Git\n>> feature is used).\n>\n> you would merge the branches and then run the tests/integration. Yes that\n> seems cumbersome.\n\nSometimes the need to make trial merge for testing cannot be avoided\nand having branches for separate topics is the only sensible\napproach, at least in the Git world.\n\nImagine your project has two components that are interrelated, say,\nthe server and the client, that have to work well with each other.\nIn addition, you want to make sure your updated server works well\nwith existing clients, and vice versa.\n\nOne way that naturally maps this scenario to the development\nworkflow is to have a server-update topic and a client-update topic\nbranches, and separate changes to update each side with their own\ncommits:\n\n s---s---S server-update topic\n /\n ---o---o----o----M mainline\n \\\n c---c---C client-update topic\n\nAnd during the development of these *-update topics, you try three\nmerges:\n\n (1) Merge S to the mainline M and test the whole thing, to make sure\n that existing client will still be able to talk with the\n updated server.\n\n (2) Merge C to the mainline M and test the whole thing, to make\n sure that updated clients will still be able to talk with the\n existing server.\n\n (3) Merge both S and C to the mainline M and test the whole thing,\n to make sure the updated ones talk to each other.\n\nIf there is no significant development going on on the mainline in\nthe meantime, (1) and (2) can be done by trying out S and C alone\nwithout making a trial merge with M. The same for (3)---it can be\njust a trial merge between S and C without updates that happened on\nthe mainline.\n\nI'd love to hear from folks in Perforce or other world how they\naddress this scenario with their system.\n"},{"id":"324422","messageId":"CAEcERAyf+np9U-o-SGSOCWsibVPyEWPh2yY+uEOgLL+qYFe1mw@mail.gmail.com","threadId":"46358","inReplyTo":"xmqqmv88xl7f.fsf@gitster.mtv.corp.google.com","subject":"Re: \"groups of files\" in Git?","fromName":"Nikolay Shustov","fromEmail":"nikolay.shustov@gmail.com","sentAt":"2017-07-13T19:31:01Z","receivedAt":"2017-07-13T19:31:06Z","isPatch":false,"sender":{"key":"nikolay.shustov@gmail.com","avatar":null},"body":"Thank you, but I am not sure I quite understand the idea.\nCould you please elaborate on it for the following example?\n\nI have two Perforce changelists (\"A\" and \"B\") that group uncommitted\nsets of files (paths to each of files could be different):\n\nchangelist A:\nfile1\nfile2\n\nchangelist B:\nfile3\nfile4\n\nIn Perforce, I am able to do the following:\n- move files between changelists (e.g. file1 could be moved to changelist B)\n- add new files to changeslit (e.g. changelist B can get additional file5)\n- revert file changes which would effectively remove file from the\nchangelst (e.g. revert file2 will remove it from changelist A)\n\nHow would I do it with sets of files that would belong to Git commit?\n\n\nOn Thu, Jul 13, 2017 at 2:09 PM, Junio C Hamano wrote:\n> Nikolay Shustov writes:\n>\n>> Thank you for the detailed explanation, it looks like merging the\n>> commits would be helpful in my case. And I think it is a very good\n>> analogy that Perforce changelists are like multiple pending committs,\n>> if Git were supporting such.\n>>\n>> What it won't be achieving by using commits in this schema is the\n>> following thing I can do in Perforce:\n>> In the uncommitted Perforce changelists I can revert the changed file\n>> to the original state and move the files between the changelists.\n>> Quite often, while working on something, in the middle I would decide\n>> to isolate changes to a certain set of files to a separate changelsit\n>> - but then I might change my mind. It is all flexible until I actually\n>> commit my Perforce changelist, after which it becomes very much as\n>> committed changes in any other source control.\n>> This is actual flexibility I am looking for achieving in Git.\n>\n> I actually think we already have such a flexibility. Unlike\n> Perforce, Git is distributed, and the most important aspect of the\n> distinction is that what happens _in_ your local Git repository may\n> be called \"committed\" in Git lingo, but not visible to the public.\n>\n> You can consider these commits you make in your repository \"pending\"\n> when you think of your workflow in Perforce terms, until you merge\n> and push out the result, which roughly corresponds to \"submitting\"\n> in Perforce lingo.\n>\n> Once you start treating your local commits that you haven't pushed\n> out as changes that are still \"pending\" when observed from the\n> outside world, you'd realize that you have as much flexibilty, if\n> not more, to dice and slice them with the local tools like \"rebase\n> -i\", \"add -p\", etc., as you would have in your Perforce workflow,\n> I would think.\n>\n>\n"},{"id":"324429","messageId":"CAEcERAxJRnB55Ardhs7LDW8M8EG-y+YE-He8hiiQv3wDqtVD3g@mail.gmail.com","threadId":"46358","inReplyTo":"xmqqiniwxkmj.fsf@gitster.mtv.corp.google.com","subject":"Re: \"groups of files\" in Git?","fromName":"Nikolay Shustov","fromEmail":"nikolay.shustov@gmail.com","sentAt":"2017-07-13T19:47:36Z","receivedAt":"2017-07-13T19:47:43Z","isPatch":false,"sender":{"key":"nikolay.shustov@gmail.com","avatar":null},"body":"For me the roadblock for multiple iterations through merging of the\ndifferent parts (S, C, then C+S) is the time that will be spent on\nrebuilding the mainline.\nThat's why I would like to have C+S in the same source tree then run\ntests for S, tests for C (if they can be run standalone) and C+S\ntests, then tests for whatever other pieces may be affected. (As I\nmentioned, there are more layers than client + server in my situation,\ne.g. client + transport + server).\n\nI am not really try to ignite the holy war between Perforce and Git\n(and why would one???), but if you are interested in the answer on how\nyou'd do your scenario in Perforce, it would be: \"use shelved\nchangelists\".\nIn Perforce, you could \"shelve\" the changelist, similar to \"stash\" in\nGit, but the difference is that the Perforce shelved changes are\naccessible across clients. I.e. the other developer can \"unshelve\"\nthese pending changes to its sandbox (to the same or the different\nbranch) so that sandbox would get the pending changes as well. That\nwould be like the developer made these changes himself. Whatever\nautomated/manual process is involved, it is typical to run \"a trial\nbuild/tests\" on shelved changelist (i.e. uncommitted yet files) to\nverify the quality of changes.\nGit achieves the same through the ease of manipulation with branches\nand I like the way it does it much more.\n\nMy question was about how to robustly handle \"multiple pending\ncommits\" which in Perforce are represented by concept of pending\nchangelists.\n\nOn Thu, Jul 13, 2017 at 2:22 PM, Junio C Hamano wrote:\n> Stefan Beller writes:\n>\n>> On Tue, Jul 11, 2017 at 8:45 AM, Nikolay Shustov\n>>\n>>> With Git I cannot seem to finding the possibility to figure out how to\n>>> achieve the same result. And the problem is that putting change sets\n>>> on different Git branches (or workdirs, or whatever Git offers that\n>>> makes the changes to be NOT in the same source tree) is not a viable\n>>> option from me as I would have to re-build code as I re-integrate the\n>>> changes between the branches (or whatever changes separation Git\n>>> feature is used).\n>>\n>> you would merge the branches and then run the tests/integration. Yes that\n>> seems cumbersome.\n>\n> Sometimes the need to make trial merge for testing cannot be avoided\n> and having branches for separate topics is the only sensible\n> approach, at least in the Git world.\n>\n> Imagine your project has two components that are interrelated, say,\n> the server and the client, that have to work well with each other.\n> In addition, you want to make sure your updated server works well\n> with existing clients, and vice versa.\n>\n> One way that naturally maps this scenario to the development\n> workflow is to have a server-update topic and a client-update topic\n> branches, and separate changes to update each side with their own\n> commits:\n>\n> s---s---S server-update topic\n> /\n> ---o---o----o----M mainline\n> \\\n> c---c---C client-update topic\n>\n> And during the development of these *-update topics, you try three\n> merges:\n>\n> (1) Merge S to the mainline M and test the whole thing, to make sure\n> that existing client will still be able to talk with the\n> updated server.\n>\n> (2) Merge C to the mainline M and test the whole thing, to make\n> sure that updated clients will still be able to talk with the\n> existing server.\n>\n> (3) Merge both S and C to the mainline M and test the whole thing,\n> to make sure the updated ones talk to each other.\n>\n> If there is no significant development going on on the mainline in\n> the meantime, (1) and (2) can be done by trying out S and C alone\n> without making a trial merge with M. The same for (3)---it can be\n> just a trial merge between S and C without updates that happened on\n> the mainline.\n>\n> I'd love to hear from folks in Perforce or other world how they\n> address this scenario with their system.\n"},{"id":"324449","messageId":"xmqqzic8t4oi.fsf@gitster.mtv.corp.google.com","threadId":"46358","inReplyTo":"CAEcERAxJRnB55Ardhs7LDW8M8EG-y+YE-He8hiiQv3wDqtVD3g@mail.gmail.com","subject":"Re: \"groups of files\" in Git?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-07-13T21:20:13Z","receivedAt":"2017-07-13T21:20:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nikolay Shustov writes:\n\n> I am not really try to ignite the holy war between Perforce and Git\n> (and why would one???), but if you are interested in the answer on how\n> you'd do your scenario in Perforce, it would be: \"use shelved\n> changelists\".\n\nOh, that was not my intention, either. My interest was to see if\nthere is a good solution that we could steal from other world.\n\n> In Perforce, you could \"shelve\" the changelist, similar to \"stash\" in\n> Git, but the difference is that the Perforce shelved changes are\n> accessible across clients. I.e. the other developer can \"unshelve\"\n> these pending changes to its sandbox (to the same or the different\n> branch) so that sandbox would get the pending changes as well. That\n> would be like the developer made these changes himself. Whatever\n> automated/manual process is involved, it is typical to run \"a trial\n> build/tests\" on shelved changelist (i.e. uncommitted yet files) to\n> verify the quality of changes.\n> Git achieves the same through the ease of manipulation with branches\n> and I like the way it does it much more.\n\nThanks. Shelving and letting others unshelve is like keeping the\nchanges in separate branches and privately share them among\ndevelopers, so they sound pretty much equivalent features to me.\n\n> My question was about how to robustly handle \"multiple pending\n> commits\" which in Perforce are represented by concept of pending\n> changelists.\n\nAnd in Git, they are represented by concept of commits that are not\nyet pushed out to the public repository to become the final history\ncarved in stone.\n"},{"id":"324459","messageId":"27a3c650-5843-d446-1f59-64fabe5434a3@gmail.com","threadId":"46358","inReplyTo":"xmqqzic8t4oi.fsf@gitster.mtv.corp.google.com","subject":"Re: \"groups of files\" in Git?","fromName":"Igor Djordjevic","fromEmail":"igor.d.djordjevic@gmail.com","sentAt":"2017-07-13T22:39:25Z","receivedAt":"2017-07-13T22:39:34Z","isPatch":false,"sender":{"key":"igor.d.djordjevic@gmail.com","avatar":null},"body":"On 13/07/2017 23:20, Junio C Hamano wrote:\n> Nikolay Shustov writes:\n>> My question was about how to robustly handle \"multiple pending\n>> commits\" which in Perforce are represented by concept of pending\n>> changelists.\n> \n> And in Git, they are represented by concept of commits that are not\n> yet pushed out to the public repository to become the final history\n> carved in stone.\n\nIf I may, I don`t think \"multiple pending commits\" is the issue here \n(as that is indeed what a private branch is), but more something like \n\"multiple branches pending/live merge branch\", or something.\n\nTo illustrate, let`s say this is our starting position:\n\n(1) o---o---o (featureA)\n / \\\n ---o---o---o---M (master, HEAD)\n \\ /\n o---o---o (featureB)\n\n\nWe`re currently on commit \"M\", being a merge commit between our \n\"master\" and two feature branches.\n\nNow, what seems lacking, while still possible through a series of \nsteps, is an easy (single step) way to modify current state and \ncommit the change to the _feature branch_, while still being on the \n\"master\" branch, still having everything merged in.\n\nSo after I make a \"featureA\" related change while on \"M\", to be able \nto issue a single command, for example:\n \n $ git commit --branch=featureA\n\n... or:\n \n $ git commit -b featureA \n \n..., where \"featureA\" would need to be one of the parents of the \ncurrent commit we are at (commit \"M\", in our case), and get a \nsituation like this:\n\n(2) o---o---o---A (featureA)\n / \\\n ---o---o---o-------M' (master, HEAD)\n \\ /\n o---o---o---/ (featureB)\n\n\nHere, \"A\" is a new commit/change I`ve just made (while still being on \nthe \"master\" branch), and it is automatically commited to related \n\"featureA\" branch, with merge commit \"M\" now recreated into \"M'\" to \nhold the new \"featureA\" commit \"A\" as well.\n\nI guess it would be a kind of alias to doing:\n\n $ git checkout featureA\n $ git add ...\n $ git commit\n $ git checkout master\n $ git reset --hard HEAD^\n $ git merge featureA featureB\n\n... or something, where last merge step would need to remember \nprevious merge commit \"M\" parent branches and merge them again to \nproduce an updated \"M'\" merge commit.\n\nIn the same manner, it should be possible to drop a commit from the \nfeature branch in a single step, for example returning to the state \nas shown in (1), or even \"port\" it from one branch to the other, like\nthis (without a need for it to be the last commit, even):\n\n(3) o---o---o---\\ (featureA)\n / \\\n ---o---o---o-------M' (master, HEAD)\n \\ /\n o---o---A'--o (featureB)\n\n\nSomething like \"rebase on steroids\", lol, keeping the HEAD where it \nis, and its merge commit beneath updated.\n\nThis indeed seems similar to Mercurial`s patch \"queues\", except being \nmuch better as everything is still version controlled at all times, \nno additional tools needed to version control the patches (unless \nthat`s already been addressed in Mercurial as well, dunno).\n \nAnd it still seems to be following Git`s \"multiple commits per \nfeature, single feature per branch\" spirit, just allowing for \neasier/faster branch integration testing.\n\np.s. Even if my short sample might be flawed in one way or the other, \nit should show the essence of the functionality we`re discussing \nhere, I think.\n\nRegards,\nBuga\n"},{"id":"324462","messageId":"ee79581c-d1ad-42c8-945a-505efad1037a@gmail.com","threadId":"46358","inReplyTo":"0793138e-5971-d8f6-b25e-215ed5028dae@eclipso.at","subject":"Re: \"groups of files\" in Git?","fromName":"Igor Djordjevic","fromEmail":"igor.d.djordjevic@gmail.com","sentAt":"2017-07-13T23:06:48Z","receivedAt":"2017-07-13T23:06:57Z","isPatch":false,"sender":{"key":"igor.d.djordjevic@gmail.com","avatar":null},"body":"Hi astian,\n\nOn 12/07/2017 00:27, astian wrote:\n> Nikolay Shustov wrote:\n>> With Perforce, I can have multiple changelists opened, that group the\n>> changed files as needed.\n>>\n>> With Git I cannot seem to finding the possibility to figure out how to\n>> achieve the same result. And the problem is that putting change sets\n>> on different Git branches (or workdirs, or whatever Git offers that\n>> makes the changes to be NOT in the same source tree) is not a viable\n>> option from me as I would have to re-build code as I re-integrate the\n>> changes between the branches (or whatever changes separation Git\n>> feature is used).\n>> Build takes time and resources and considering that I have to do it on\n>> multiple platforms (I do cross-platform development) it really\n>> denominates the option of not having multiple changes in the same code\n>> tree.\n>>\n>> Am I ignorant about some Git feature/way of using Git that would help?\n>> Is it worth considering adding to Git a feature like \"group of files\"\n>> that would offer some virtutal grouping of the locally changed files\n>> in the checked-out branch?\n> \n> I never used Perforce and I'm not even sure I understand your problem,\n> but I thought I'd mention something that nobody else seems to have yet\n> (unless I missed it):\n> \n> First, one thing that seems obvious to me from your description is that\n> these \"parallel features\" you work on are obviously interdependent,\n> therefore I would rather consider the whole thing as a single feature.\n> Therefore, it makes sense to me to work in a single \"topic branch\".\n> \n> This doesn't preclude one from separating the changes in logically\n> sensible pieces. Indeed this is par for the course in Git and people do\n> it all the time by dividing the bulk of changes into a carefully chosen\n> series of commits.\n> \n> I think the most common way of doing this is to simply work on the whole\n> thing and once you're happy with it you use \"git rebase --interative\" in\n> order to \"prettify\" your history.\n> \n> But, and here comes the part I think nobody mentioned yet, if your\n> feature work is considerably large or spans a considerably long time it\n> may be undesirable to postpone all that work until the very end (perhaps\n> by then you already forgot important information, or perhaps too many\n> changes have accumulated so reviewing them all becomes significantly\n> less efficient). In that case, one solution is to use a \"patch\n> management system\" which will let you do that work incrementally (going\n> back and forth as needed).\n> \n> If you know mercurial, this is \"hg mq\". I don't think Git has any such\n> system built-in, but I know there are at least these external tools that\n> integrate with Git:\n> https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Patch-management_Interface_layers\n> \n> Feel free to ignore this if I totally misunderstood your use case.\n> \n> Cheers\nThis message actually creeped me out the first time I read it, after \nwriting an e-mail reply of my own[1].\n\nThe tone it`s written in, the points you make, and even the \nconclusion about \"hg mg\" -- as if you were reading my mind.\n\nYours was sent a bit before mine, but I guess we were writing it at \nthe same time as well... Just spooky, lol.\n\nThat said, I totally understand what you`re talking about, and I gave \nan example of the desired (yet missing?) Git work flow here[2] :)\n\n[1] https://public-inbox.org/git/6e4096fd-cbab-68f0-7a23-654382cb810e@gmail.com/\n[2] https://public-inbox.org/git/27a3c650-5843-d446-1f59-64fabe5434a3@gmail.com/\n\nRegards,\nBuga\n"},{"id":"324463","messageId":"40292f8e-e8a9-8b7a-112f-ef4b183a6b35@gmail.com","threadId":"46358","inReplyTo":"27a3c650-5843-d446-1f59-64fabe5434a3@gmail.com","subject":"Re: \"groups of files\" in Git?","fromName":"Igor Djordjevic","fromEmail":"igor.d.djordjevic@gmail.com","sentAt":"2017-07-13T23:32:52Z","receivedAt":"2017-07-13T23:33:05Z","isPatch":false,"sender":{"key":"igor.d.djordjevic@gmail.com","avatar":null},"body":"Just a small update/fixup:\n\nOn 14/07/2017 00:39, Igor Djordjevic wrote:\n> I guess it would be a kind of alias to doing:\n> \n> $ git checkout featureA\n> $ git add ...\n> $ git commit\n> $ git checkout master\n> $ git reset --hard HEAD^\n> $ git merge featureA featureB\n> \n\nThis should, in fact, be: \n \n $ git checkout featureA\n $ git commit\n $ git checkout master\n $ git reset --hard HEAD^\n $ git merge \n \n(removed \"git add\" step, as that is needed for proposed single step \nsolution as well, as a usual step preceding the commit; also replaced \nconcrete branch names in the last step with a more generic \ndescription, better communicating real intent)\n\n> In the same manner, it should be possible to drop a commit from the \n> feature branch in a single step, for example returning to the state \n> as shown in (1), or even \"port\" it from one branch to the other, like\n> this (without a need for it to be the last commit, even):\n> \n> (3) o---o---o---\\ (featureA)\n> / \\\n> ---o---o---o-------M' (master, HEAD)\n> \\ /\n> o---o---A'--o (featureB)\n\nHere, the diagram should look like this:\n\n(3) o---o---o---\\ (featureA)\n / \\\n ---o---o---o-------M'' (master, HEAD)\n \\ /\n o---o---A''-o (featureB)\n\n(replaced leftover M' from the previous diagram with M'' to show it`s \nyet another (updated) merge commit, different from both M and M' in \nterms of SHA1, yet the contents would probably, but not necessarily, \nbe the same for all three; same for leftover A', replaced with A'')\n\nRegards,\nBuga\n"},{"id":"324464","messageId":"d91f420b-8737-0c94-5a67-f3cb24c2ba22@gmail.com","threadId":"46358","inReplyTo":"40292f8e-e8a9-8b7a-112f-ef4b183a6b35@gmail.com","subject":"Re: \"groups of files\" in Git?","fromName":"Igor Djordjevic","fromEmail":"igor.d.djordjevic@gmail.com","sentAt":"2017-07-13T23:40:31Z","receivedAt":"2017-07-13T23:40:39Z","isPatch":false,"sender":{"key":"igor.d.djordjevic@gmail.com","avatar":null},"body":"Eh, yet another one, sorry:\n\nOn 14/07/2017 01:32, Igor Djordjevic wrote:\n> \n> $ git checkout featureA\n> $ git commit\n> $ git checkout master\n> $ git reset --hard HEAD^\n> $ git merge \n\nThe last line should stress , as we`re \nnot merging exact parent commits the previous merge commit was made \nof, but updated tips of the branches the previous merge commit was \nmade of... or something along those lines :)\n"}]}