sfdx force:source:deploy with specified manifest having specific fields deploys everything in the local object folder

Summary

When using the org development model, the salesforce cli will deploy the entire object file if you specify a package.xml specifying child components of that object (ValidationRule,CustomField,etc.).

Steps To Reproduce:

Scenario: You want to deploy a single custom field from your workspace (that is in dx format) to a Sandbox (org development model).

1. You make a package.xml in the manifest folder named package.xml:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Account.MyCustomField__c</members>
        <name>CustomField</name>
    </types>
    <version>46.0</version>
</Package>

1. I then run the following command to deploy the custom field to the sandbox:

sfdx force:source:deploy -u [e-mail]  -x manifest/package.xml -w 10

Expected result

I would expect that the cli zips up that specific custom field and deploys it to the target org, with the below package.xml:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Account.MyCustomField__c</members>
        <name>CustomField</name>
    </types>
    <version>46.0</version>
</Package>

Actual result

The cli generates an object file with every single component in my local directory related to the custom object (fields, record types, etc.), and creates the following (incorrect) package.xml:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
  <types>
    <name>CustomObject</name>
    <members>Account</members>
  </types>
  <types>
    <name>CompactLayout</name>
    <!-- all local account compact layouts -->
  </types>
  <types>
    <name>FieldSet</name>
    <!-- all local account field sets -->
  </types>
  <types>
    <name>CustomField</name>
    <!-- all local account custom fields -->
  </types>
  <types>
    <name>ListView</name>
    <!-- all local list views -->
  </types>
  <types>
    <name>RecordType</name>
    <!-- all local record types -->
  </types>
  <types>
    <name>ValidationRule</name>
    <!-- all local validation rules -->
  </types>
  <types>
    <!-- all local web links -->
    <name>WebLink</name>
  </types>
  <version>46.0</version>
</Package>

It then proceed to deploy all of that metadata instead of the single custom field that should have been deployed.

Additional information

The only workaround I have is to add all of the unwanted components to the forceIgnore file which is not reasonable for hundred to thousands of components when I want to deploy a single field.

SFDX CLI Version:

sfdx-cli/7.20.1-d88ae4707c darwin-x64 node-v10.15.3

SFDX plugin Version:

@oclif/plugin-commands 1.2.2 (core)
@oclif/plugin-help 2.2.1 (core)
@oclif/plugin-not-found 1.2.2 (core)
@oclif/plugin-plugins 1.7.8 (core)
@oclif/plugin-update 1.3.9 (core)
@oclif/plugin-warn-if-update-available 1.7.0 (core)
@oclif/plugin-which 1.0.3 (core)
@salesforce/sfdx-trust 3.0.5 (core)
analytics 1.2.1 (core)
generator 1.1.1 (core)
salesforcedx 46.10.2 (core)
├─ force-language-services 46.14.0 (core)
└─ salesforce-alm 46.13.0 (core)

sfdx-cli 7.20.1 (core)

OS and version:

ProductName:	Mac OS X
ProductVersion:	10.14.6
BuildVersion:	18G87

[dmgerow]

@clairebianchi more importantly, there are many times where you may have parallel projects going live at different times with some overlap on objects.

For example, if Team A is implementing a quoting solution and team B is implementing a field service solution, both teams will be adding or updating different metadata on the Account object. Rather than trying to merge every change that is introduced upstream in a QA environment which can be tedious with XML documents, we should be able to trust that if we specify a single CustomField to be deployed that the entire object is not deployed.

Since it is deploying more than what is specified in the package manifest, the release manager may be unknowingly overwriting a larger number of changes on the related object even though the manifest does not indicate it.

[payensa-sf]

Hi @clairebianchi this behaviour should also apply to the command force:source:convert -x which is currently keeping the whole object in the target folder even when you only specified a single part of it. Thanks!