Salesforce CLI New Command Feedback

I believe I am having an issue with the source:retrieve command.

I have a sfdx-project.json file like the following:

{

  "packageDirectories": [

    {

      "path": "force-app",

      "default": true

    },

    {

      "path": "myApp",

      "default": false

    }

  ],

  "namespace": "",

  "sfdcLoginUrl": "https://test.salesforce.com",

  "sourceApiVersion": "45.0"

}

For this scenario lets say I am interested in retrieving a class that is currently in /myApp/main/default/classes/ called MyApexClass.cls.

I get what I expect when I use the command like either of the following:

• sfdx force:source:retrieve -x manifest/package.xml
• sfdx force:source:retrieve -m ApexClass:MyApexClass

The MyApexClass.cls file which is originally located in /myApp/main/default/classes/ is updated in that location.

However I get a different behavior when I use the command like the following:

• sfdx force:source:retrieve -p ./myApp/main/default/classes/MyApexClass.cls

The MyApexClass.cls file is retrieved, but instead of updating the copy in /myApp/main/default/classes/, a copy of the class is put into /force-app/main/default/classes/.

I expect all three ways of running source:retrieve to behave similarly. I expect the file to be placed into the location it was originally.

Hey all, 

Not sure if that would be useful anyhow, but I've recently been trying to convert medium-size, traditional implementation project (sandbox dev, ANT deployments between orgs) into source driven model and I failed (not the first time though...) and wanted to share some feedback:

• sfdx force:source:retrieve is great addition because it allows to specify a single package.xml manifest file and pull the whole metadata into repository - good. Something that was possible with mdapi, but this one is better
• what I'm able to do right now is to track source within git repository. I'm able to retrieve source from different orgs and thanks to the sfdx source format relatively easy make diff/merge (except for profiles). I'm also able to easily track those lousy admins who hotfix directly in prod and make it easier to merge them back into development branches - great!
• currently I'm struggling to find a way to deploy directly from sfdx source. As far as I can see there are two options:
  • new sfdx force:source:deploy - idea is great, but:
    • if you do sfdx force:source:deploy against full package.xml - the same that is used for retrieval - that would be the best (I really don't bother keeping full org in the source code and make a full deploy each time), but I bet it will fail at some crazy component (full org -> 2000+ components)
    • in that case you can keep small purpose-fitted package.xml's (e.g. one for each release) - but somebody needs to managed that. And yet it still is not as predictable as mdapi. 
    • there are few flaws in sfdx force:source:deploy -> e.g. if you just specify one custom field - it deploys whole object. 
  • sfdx force:source:convert -> sfdx force:mdapi:deploy
    • but this doesn't give ability to limit the scope of deployment as whole sfdx source is converted into mdapi format
• the approach I'd be willing to be able to achieve would be to:
  • have many dev boxes for feature development, where devs / consultants are building their stuff and commit them to GIT
  • code is integrated at repository level and pushed into SIT sandbox for system integration testing
  • UAT deployments are made also from GIT
  • hotfixes from prod are merged back into development branches as a rebase

Anyway, thanks for your efforts, we're looking forward for some new stuff. I'm available to answer questions if you have any.

if anyone else from partners could share their practice on how to easily embrace source driven model (without having number of people or some crazy tools like autorabbit on top of that), I'd be very thankful.