{"thread":{"id":"45003","subject":"gitconfig get out of sync with submodule entries on branch switch","startedAt":"2017-01-30T16:22:02Z","lastAt":"2017-02-08T19:35:57Z","messageCount":7,"participants":["Benjamin Schindler","Brandon Williams","Stefan Beller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"310530","messageId":"0f14df64-1aa2-e671-9785-4e5e0a076ae6@gmail.com","threadId":"45003","inReplyTo":null,"subject":"gitconfig get out of sync with submodule entries on branch switch","fromName":"Benjamin Schindler","fromEmail":"beschindler@gmail.com","sentAt":"2017-01-30T16:21:54Z","receivedAt":"2017-01-30T16:22:02Z","isPatch":false,"sender":{"key":"beschindler@gmail.com","avatar":null},"body":"Hi\n\nConsider the following usecase: I have the master branch where I have a \nsubmodule A. I create a branch where I rename the submodule to be in the \ndirectory B. After doing all of this, everything looks good.\nNow, I switch back to master. The first oddity is, that it fails to \nremove the folder B because there are still files in there:\n\nbschindler@metis ~/Projects/submodule_test (testbranch) $ git checkout \nmaster\nwarning: unable to rmdir other_submodule: Directory not empty\nSwitched to branch 'master'\n\nGit submodule deinit on B fails because the submodule is not known to \ngit anymore (after all, the folder B exists only in the other branch). I \ncan easily just remove the folder B from disk and initialize the \nsubmodule A again, so all seems good.\n\nHowever, what is not good is that the submodule b is still known in \n.git/config. This is in particular a problem for us, because I know a \nnumber of tools which use git config to retrieve the submodule list. Is \nit therefore a bug that upon branch switch, the submodule gets \nderegistered, but its entry in .git/config remains?\n\nthanks a lot\nBenjamin Schindler\n\nP.s. I did not subscribe to the mailing list, please add me at least do \nCC. Thanks\n"},{"id":"310542","messageId":"20170130175118.GA35626@google.com","threadId":"45003","inReplyTo":"0f14df64-1aa2-e671-9785-4e5e0a076ae6@gmail.com","subject":"Re: gitconfig get out of sync with submodule entries on branch switch","fromName":"Brandon Williams","fromEmail":"bmwill@google.com","sentAt":"2017-01-30T17:51:18Z","receivedAt":"2017-01-30T17:52:10Z","isPatch":false,"sender":{"key":"bwilliams.eng@gmail.com","avatar":null},"body":"On 01/30, Benjamin Schindler wrote:\n> Hi\n> \n> Consider the following usecase: I have the master branch where I\n> have a submodule A. I create a branch where I rename the submodule\n> to be in the directory B. After doing all of this, everything looks\n> good.\n> Now, I switch back to master. The first oddity is, that it fails to\n> remove the folder B because there are still files in there:\n> \n> bschindler@metis ~/Projects/submodule_test (testbranch) $ git\n> checkout master\n> warning: unable to rmdir other_submodule: Directory not empty\n> Switched to branch 'master'\n> \n> Git submodule deinit on B fails because the submodule is not known\n> to git anymore (after all, the folder B exists only in the other\n> branch). I can easily just remove the folder B from disk and\n> initialize the submodule A again, so all seems good.\n> \n> However, what is not good is that the submodule b is still known in\n> .git/config. This is in particular a problem for us, because I know\n> a number of tools which use git config to retrieve the submodule\n> list. Is it therefore a bug that upon branch switch, the submodule\n> gets deregistered, but its entry in .git/config remains?\n> \n> thanks a lot\n> Benjamin Schindler\n> \n> P.s. I did not subscribe to the mailing list, please add me at least\n> do CC. Thanks\n\nsubmodules and checkout don't really play nicely with each other at the\nmoment.  Stefan (cc'd) is currently working on a patch series to improve\nthe behavior of checkout with submodules.  Currently, if you want to\nensure you have a good working state after a checkout you should run\n`git submodule update` to update all of the submoules.  As far as your\nsubmodule still being listed in the config, that should be expected\ngiven the scenario you described.\n\nIf I'm understanding you correctly, A and B are both the same submodule\njust renamed on a different branch.  The moment you add a submoule to a\nrepository it is given a name which is fixed.  Typically this is the\npath from the root of the repository.  The thing is, since you are able\nto freely move a submodule, its path can change.  To account for this\nthere is the .gitmodules file which allows you to do a lookup from\nsubmodule name to the path at which it exists (or vice versa).  The\nsubmodules that are stored in .git/config are those which are\n'initialize' or rather the submodules in which you are interested in and\nwill be updated by `git submodule update`.  So given your scenario you\nshould only have a single submodule in .git/config and the .gitmodules\nfile should have a single entry with a differing path for each branch.\n\nHopefully this gives you a bit more information to work with.  Since\nStefan has been working with this more recently than me he may have some\nmore input.\n\n-- \nBrandon Williams\n"},{"id":"310590","messageId":"b614a44a-fbc6-b5fe-ae40-ccf43dd9fcfb@gmail.com","threadId":"45003","inReplyTo":"20170130175118.GA35626@google.com","subject":"Re: gitconfig get out of sync with submodule entries on branch switch","fromName":"Benjamin Schindler","fromEmail":"beschindler@gmail.com","sentAt":"2017-01-31T07:46:09Z","receivedAt":"2017-01-31T07:46:17Z","isPatch":false,"sender":{"key":"beschindler@gmail.com","avatar":null},"body":"Hi Brandon\n\nI did try your suggestion, so basically:\n\ngit checkout branch\ngit submodule init\ngit submodule update\n\nUnfortunately, I still have two entries in my git config this way. It \nseems that git submodule update only considers submodules listed in \n.gitmodules.\n\nThe background of my question is this - we have a jenkins farm which \nneeds to switch branches continuously in an automated fashion and this \nneeds to work even in when submodules are around. I did however, just \nnow, find a reliable way to switch a branch, keeping the gitconfig in sync:\nThe basic workflow for switching a branch is:\ngit submodule deinit .\ngit checkout branch\ngit submodule init\ngit submodule update\n\nBecause the .git folder of the submodules are not within the submodule \ndirectories, this is, while still quite heavy-handed, reasonably fast \nand robust. At least it is better than deleting the entire repository \nevery time a branch switch is issued.\n\nRegards\n\nBenjamin Schindler\n\nOn 30.01.2017 18:51, Brandon Williams wrote:\n> On 01/30, Benjamin Schindler wrote:\n>> Hi\n>>\n>> Consider the following usecase: I have the master branch where I\n>> have a submodule A. I create a branch where I rename the submodule\n>> to be in the directory B. After doing all of this, everything looks\n>> good.\n>> Now, I switch back to master. The first oddity is, that it fails to\n>> remove the folder B because there are still files in there:\n>>\n>> bschindler@metis ~/Projects/submodule_test (testbranch) $ git\n>> checkout master\n>> warning: unable to rmdir other_submodule: Directory not empty\n>> Switched to branch 'master'\n>>\n>> Git submodule deinit on B fails because the submodule is not known\n>> to git anymore (after all, the folder B exists only in the other\n>> branch). I can easily just remove the folder B from disk and\n>> initialize the submodule A again, so all seems good.\n>>\n>> However, what is not good is that the submodule b is still known in\n>> .git/config. This is in particular a problem for us, because I know\n>> a number of tools which use git config to retrieve the submodule\n>> list. Is it therefore a bug that upon branch switch, the submodule\n>> gets deregistered, but its entry in .git/config remains?\n>>\n>> thanks a lot\n>> Benjamin Schindler\n>>\n>> P.s. I did not subscribe to the mailing list, please add me at least\n>> do CC. Thanks\n> submodules and checkout don't really play nicely with each other at the\n> moment.  Stefan (cc'd) is currently working on a patch series to improve\n> the behavior of checkout with submodules.  Currently, if you want to\n> ensure you have a good working state after a checkout you should run\n> `git submodule update` to update all of the submoules.  As far as your\n> submodule still being listed in the config, that should be expected\n> given the scenario you described.\n>\n> If I'm understanding you correctly, A and B are both the same submodule\n> just renamed on a different branch.  The moment you add a submoule to a\n> repository it is given a name which is fixed.  Typically this is the\n> path from the root of the repository.  The thing is, since you are able\n> to freely move a submodule, its path can change.  To account for this\n> there is the .gitmodules file which allows you to do a lookup from\n> submodule name to the path at which it exists (or vice versa).  The\n> submodules that are stored in .git/config are those which are\n> 'initialize' or rather the submodules in which you are interested in and\n> will be updated by `git submodule update`.  So given your scenario you\n> should only have a single submodule in .git/config and the .gitmodules\n> file should have a single entry with a differing path for each branch.\n>\n> Hopefully this gives you a bit more information to work with.  Since\n> Stefan has been working with this more recently than me he may have some\n> more input.\n>\n\n"},{"id":"310624","messageId":"CAGZ79kbCOHg9Sw01UvFe=Ek5Yf89q9Cw8VvQqVay8i-mVCEkEA@mail.gmail.com","threadId":"45003","inReplyTo":"b614a44a-fbc6-b5fe-ae40-ccf43dd9fcfb@gmail.com","subject":"Re: gitconfig get out of sync with submodule entries on branch switch","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-01-31T22:04:49Z","receivedAt":"2017-01-31T22:12:33Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Mon, Jan 30, 2017 at 11:46 PM, Benjamin Schindler\n<beschindler@gmail.com> wrote:\n> Hi Brandon\n>\n> I did try your suggestion, so basically:\n>\n> git checkout branch\n> git submodule init\n> git submodule update\n\nEventually this becomes\n\n    git submudule update --init\n    git checkout --recurse-submodules $branch\n\n\n>\n> Unfortunately, I still have two entries in my git config this way. It seems\n> that git submodule update only considers submodules listed in .gitmodules.\n\nDid you rename the name in the gitmodules file or rename the path on the FS?\n\n>\n> The background of my question is this - we have a jenkins farm which needs\n> to switch branches continuously in an automated fashion and this needs to\n> work even in when submodules are around. I did however, just now, find a\n> reliable way to switch a branch, keeping the gitconfig in sync:\n> The basic workflow for switching a branch is:\n> git submodule deinit .\n\nThis will become 'git submodule deinit --all' eventually\n\n> git checkout branch\n> git submodule init\n> git submodule update\n\nThis ought to update all the submodules, sounds fine to me.\n\n>\n> Because the .git folder of the submodules are not within the submodule\n> directories, this is, while still quite heavy-handed, reasonably fast and\n> robust. At least it is better than deleting the entire repository every time\n> a branch switch is issued.\n\nIn the next version there will be 'git submodule absorbgitdirs'\nwhich moves the git dirs of submodules inside the superproject; would\na reversion of this also be useful?\n\n>\n> Regards\n>\n> Benjamin Schindler\n>\n>\n> On 30.01.2017 18:51, Brandon Williams wrote:\n>>\n>> On 01/30, Benjamin Schindler wrote:\n>>>\n>>> Hi\n>>>\n>>> Consider the following usecase: I have the master branch where I\n>>> have a submodule A. I create a branch where I rename the submodule\n>>> to be in the directory B. After doing all of this, everything looks\n>>> good.\n>>> Now, I switch back to master. The first oddity is, that it fails to\n>>> remove the folder B because there are still files in there:\n>>>\n>>> bschindler@metis ~/Projects/submodule_test (testbranch) $ git\n>>> checkout master\n>>> warning: unable to rmdir other_submodule: Directory not empty\n>>> Switched to branch 'master'\n>>>\n>>> Git submodule deinit on B fails because the submodule is not known\n>>> to git anymore (after all, the folder B exists only in the other\n>>> branch). I can easily just remove the folder B from disk and\n>>> initialize the submodule A again, so all seems good.\n>>>\n>>> However, what is not good is that the submodule b is still known in\n>>> .git/config. This is in particular a problem for us, because I know\n>>> a number of tools which use git config to retrieve the submodule\n>>> list. Is it therefore a bug that upon branch switch, the submodule\n>>> gets deregistered, but its entry in .git/config remains?\n>>>\n>>> thanks a lot\n>>> Benjamin Schindler\n>>>\n>>> P.s. I did not subscribe to the mailing list, please add me at least\n>>> do CC. Thanks\n>>\n>> submodules and checkout don't really play nicely with each other at the\n>> moment.  Stefan (cc'd) is currently working on a patch series to improve\n>> the behavior of checkout with submodules.  Currently, if you want to\n>> ensure you have a good working state after a checkout you should run\n>> `git submodule update` to update all of the submoules.  As far as your\n>> submodule still being listed in the config, that should be expected\n>> given the scenario you described.\n>>\n>> If I'm understanding you correctly, A and B are both the same submodule\n>> just renamed on a different branch.  The moment you add a submoule to a\n>> repository it is given a name which is fixed.  Typically this is the\n>> path from the root of the repository.  The thing is, since you are able\n>> to freely move a submodule, its path can change.  To account for this\n>> there is the .gitmodules file which allows you to do a lookup from\n>> submodule name to the path at which it exists (or vice versa).  The\n>> submodules that are stored in .git/config are those which are\n>> 'initialize' or rather the submodules in which you are interested in and\n>> will be updated by `git submodule update`.  So given your scenario you\n>> should only have a single submodule in .git/config and the .gitmodules\n>> file should have a single entry with a differing path for each branch.\n>>\n>> Hopefully this gives you a bit more information to work with.  Since\n>> Stefan has been working with this more recently than me he may have some\n>> more input.\n>>\n>\n"},{"id":"310905","messageId":"CAGZ79kaZUOO4qusCDF9=VJ-6QPjAvc5eSaazjWWEocRMHuTSug@mail.gmail.com","threadId":"45003","inReplyTo":"0f14df64-1aa2-e671-9785-4e5e0a076ae6@gmail.com","subject":"Re: gitconfig get out of sync with submodule entries on branch switch","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-02-06T10:35:19Z","receivedAt":"2017-02-06T10:35:25Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"Answering the original email, as I feel we're going down the wrong rabbit\nhole in the existing thread.\n\nOn Mon, Jan 30, 2017 at 8:21 AM, Benjamin Schindler\n<beschindler@gmail.com> wrote:\n> Hi\n>\n> Consider the following usecase: I have the master branch where I have a\n> submodule A. I create a branch where I rename the submodule to be in the\n> directory B. After doing all of this, everything looks good.\n> Now, I switch back to master. The first oddity is, that it fails to remove\n> the folder B because there are still files in there:\n>\n> bschindler@metis ~/Projects/submodule_test (testbranch) $ git checkout\n> master\n> warning: unable to rmdir other_submodule: Directory not empty\n> Switched to branch 'master'\n\ncheckout currently doesn't support submodules, so it should neither\ntry to delete B nor try to repopulate A when switching back to master.\ncheckout ought to not even touch the existing submodule B.\n\n>\n> Git submodule deinit on B fails because the submodule is not known to git\n> anymore (after all, the folder B exists only in the other branch). I can\n> easily just remove the folder B from disk and initialize the submodule A\n> again, so all seems good.\n\nby initializing you mean populating(?), i.e.\n\n    git submodule update\n\nwould work without the --init flag or preceding \"git submodule init A\".\nThat ought to not redownload A, but just put files back in the working tree\nfrom the submodule git directory inside the superprojects git dir.\n\n>\n> However, what is not good is that the submodule b is still known in\n> .git/config.\n\nOh, I see. You did not just rename the path, but also the name\nin the .gitmodules?\n\n> This is in particular a problem for us, because I know a number\n> of tools which use git config to retrieve the submodule list. Is it\n> therefore a bug that upon branch switch, the submodule gets deregistered,\n> but its entry in .git/config remains?\n\nThe config remains as it indicates that you express(ed) interest in\nsubmodule A, such that when switching branches\n\n  master->renamedToB->master\n\nthen we'd still care about A. As for the tools, I'd rather see them use\n\n    git submodule status/summary\n\ninstead of directly looking at the config, because the config may\nchange in the future.\n\n>\n> thanks a lot\n> Benjamin Schindler\n>\n> P.s. I did not subscribe to the mailing list, please add me at least do CC.\n> Thanks\n"},{"id":"310906","messageId":"7e54658a-dcb2-64a7-3c67-0c4fa221b2fb@gmail.com","threadId":"45003","inReplyTo":"CAGZ79kaZUOO4qusCDF9=VJ-6QPjAvc5eSaazjWWEocRMHuTSug@mail.gmail.com","subject":"Re: gitconfig get out of sync with submodule entries on branch switch","fromName":"Benjamin Schindler","fromEmail":"beschindler@gmail.com","sentAt":"2017-02-06T12:17:30Z","receivedAt":"2017-02-06T12:17:46Z","isPatch":false,"sender":{"key":"beschindler@gmail.com","avatar":null},"body":"\n\nOn 06.02.2017 11:35, Stefan Beller wrote:\n> Answering the original email, as I feel we're going down the wrong rabbit\n> hole in the existing thread.\n>\n> On Mon, Jan 30, 2017 at 8:21 AM, Benjamin Schindler\n> <beschindler@gmail.com> wrote:\n>> Hi\n>>\n>> Consider the following usecase: I have the master branch where I have a\n>> submodule A. I create a branch where I rename the submodule to be in the\n>> directory B. After doing all of this, everything looks good.\n>> Now, I switch back to master. The first oddity is, that it fails to remove\n>> the folder B because there are still files in there:\n>>\n>> bschindler@metis ~/Projects/submodule_test (testbranch) $ git checkout\n>> master\n>> warning: unable to rmdir other_submodule: Directory not empty\n>> Switched to branch 'master'\n>\n> checkout currently doesn't support submodules, so it should neither\n> try to delete B nor try to repopulate A when switching back to master.\n> checkout ought to not even touch the existing submodule B.\n\nWell, it tried to remove the folder (the rmdir warning) but it failed so \nin some sense you are right. Is there a technical reason for this \ndefault though? Here, I frequently have to point out to people that they \nneed to initialize/update the submodule on e.g. clone.\n\n>\n>>\n>> Git submodule deinit on B fails because the submodule is not known to git\n>> anymore (after all, the folder B exists only in the other branch). I can\n>> easily just remove the folder B from disk and initialize the submodule A\n>> again, so all seems good.\n>\n> by initializing you mean populating(?), i.e.\n>\n>     git submodule update\n>\n> would work without the --init flag or preceding \"git submodule init A\".\n> That ought to not redownload A, but just put files back in the working tree\n> from the submodule git directory inside the superprojects git dir.\n>\n>>\n>> However, what is not good is that the submodule b is still known in\n>> .git/config.\n>\n> Oh, I see. You did not just rename the path, but also the name\n> in the .gitmodules?\n\nI wasn't even aware that the submodule name was something different from \nthe path because the name is by default set to be the path to it. So \nyes, I didn't just relocate it, it had a different name.\n\n>\n>> This is in particular a problem for us, because I know a number\n>> of tools which use git config to retrieve the submodule list. Is it\n>> therefore a bug that upon branch switch, the submodule gets deregistered,\n>> but its entry in .git/config remains?\n>\n> The config remains as it indicates that you express(ed) interest in\n> submodule A, such that when switching branches\n>\n>   master->renamedToB->master\n>\n> then we'd still care about A. As for the tools, I'd rather see them use\n>\n>     git submodule status/summary\n>\n> instead of directly looking at the config, because the config may\n> change in the future.\n\nThat was my feeling but its good to know to have more solid reasons why \nthat would be.\n\nCheers\nBenjamin\n\n>\n>>\n>> thanks a lot\n>> Benjamin Schindler\n>>\n>> P.s. I did not subscribe to the mailing list, please add me at least do CC.\n>> Thanks\n"},{"id":"311079","messageId":"CAGZ79kYr3pmo_+fP8O++TvcW6pohRsVmapSpoJ18_ouVg8tRiw@mail.gmail.com","threadId":"45003","inReplyTo":"7e54658a-dcb2-64a7-3c67-0c4fa221b2fb@gmail.com","subject":"Re: gitconfig get out of sync with submodule entries on branch switch","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-02-08T19:07:05Z","receivedAt":"2017-02-08T19:35:57Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Mon, Feb 6, 2017 at 4:17 AM, Benjamin Schindler\n<beschindler@gmail.com> wrote:\n>\n>\n> On 06.02.2017 11:35, Stefan Beller wrote:\n>>\n>> Answering the original email, as I feel we're going down the wrong rabbit\n>> hole in the existing thread.\n>>\n>> On Mon, Jan 30, 2017 at 8:21 AM, Benjamin Schindler\n>> <beschindler@gmail.com> wrote:\n>>>\n>>> Hi\n>>>\n>>> Consider the following usecase: I have the master branch where I have a\n>>> submodule A. I create a branch where I rename the submodule to be in the\n>>> directory B. After doing all of this, everything looks good.\n>>> Now, I switch back to master. The first oddity is, that it fails to\n>>> remove\n>>> the folder B because there are still files in there:\n>>>\n>>> bschindler@metis ~/Projects/submodule_test (testbranch) $ git checkout\n>>> master\n>>> warning: unable to rmdir other_submodule: Directory not empty\n>>> Switched to branch 'master'\n>>\n>>\n>> checkout currently doesn't support submodules, so it should neither\n>> try to delete B nor try to repopulate A when switching back to master.\n>> checkout ought to not even touch the existing submodule B.\n>\n>\n> Well, it tried to remove the folder (the rmdir warning) but it failed so in\n> some sense you are right. Is there a technical reason for this default\n> though? Here, I frequently have to point out to people that they need to\n> initialize/update the submodule on e.g. clone.\n\nThe reasoning is more based on historical momentum.\nBack then when gitlinks/submodules were invented (git repositories\ninside other git repositories! How frickin' cool is that?) nobody quite knew\nhow they were going to be used eventually.  So the safe play at the time was\nto not touch them at all. (Also easy to implement, but that was not the point\nas I learned).\n\nAnd now we have a lot of people expecting just that. So we cannot change\nthe behavior overnight. So we'd first implement the alternative (e.g. the\n--recurse-submodules flag for checkout) and then once we do a major\nrelease we may want to flip the default.\n\n>\n>>\n>>>\n>>> Git submodule deinit on B fails because the submodule is not known to git\n>>> anymore (after all, the folder B exists only in the other branch). I can\n>>> easily just remove the folder B from disk and initialize the submodule A\n>>> again, so all seems good.\n>>\n>>\n>> by initializing you mean populating(?), i.e.\n>>\n>>     git submodule update\n>>\n>> would work without the --init flag or preceding \"git submodule init A\".\n>> That ought to not redownload A, but just put files back in the working\n>> tree\n>> from the submodule git directory inside the superprojects git dir.\n>>\n>>>\n>>> However, what is not good is that the submodule b is still known in\n>>> .git/config.\n>>\n>>\n>> Oh, I see. You did not just rename the path, but also the name\n>> in the .gitmodules?\n>\n>\n> I wasn't even aware that the submodule name was something different from the\n> path because the name is by default set to be the path to it. So yes, I\n> didn't just relocate it, it had a different name.\n\nYeah the path/name is tricky and usually only differs when you move the\nsubmodule inside the working tree. (As the name stays constant we know\nwhere the git directory is expected: .git/modules<name> so we can check there\ninstead of re-cloning to the \"new\" submodule-path.)\n\n>\n>>\n>>> This is in particular a problem for us, because I know a number\n>>> of tools which use git config to retrieve the submodule list. Is it\n>>> therefore a bug that upon branch switch, the submodule gets deregistered,\n>>> but its entry in .git/config remains?\n>>\n>>\n>> The config remains as it indicates that you express(ed) interest in\n>> submodule A, such that when switching branches\n>>\n>>   master->renamedToB->master\n>>\n>> then we'd still care about A. As for the tools, I'd rather see them use\n>>\n>>     git submodule status/summary\n>>\n>> instead of directly looking at the config, because the config may\n>> change in the future.\n>\n>\n> That was my feeling but its good to know to have more solid reasons why that\n> would be.\n\nThe reasons here are backward/forward compatibility.\nWhen trying to change the behavior of submodule related things, there is no\nclear distinction of plumbing/porcelain as we have in the rest of Git.\nSo even in gits own test suite we sometimes rely on things that may change\nlater on, and that makes it very hard to move forward, which is why I try to\nhave an opinion on how to do things properly.\n\nThanks,\nStefan\n"}]}