Improved output for the tag command

[itaymendel]

The current output of bit tag does not do a good job in explaining what was updated. Additionally, it fails to properly explain the differences between added, changed or auto-tagged.

$ bit tag -a
2 component(s) tagged | 0 added, 1 changed, 1 auto-tagged
changed components:  [remote]/[namespace]/[name]@[version]
auto-tagged components (as a result of tagging their dependencies):  [remote]/[namespace]/[name]@[version]

Suggested output:

• Restructure output like bit status.
• Separate components into categories.
• Using lists instead of a comma-separated.
• Short explanation about each category.
• List the possible actions to do after tagging components (export or untag).
• For auto-tagged list the updated dependencies that triggered auto-tag.

$ bit tag -a
6 components tagged
(use "bit export [collection]" to push these components to a remote")
(use "bit untag" to unstage versions)

new components
(first version for components)

     > [namespace]/[name]@[version]
     > [name]@[version]


changed components
(components that got a version bump)

     > [remote]/[namespace]/[name]@[version]
     > [remote]/[name]@[version]


auto-tagged components
(version bumps due to new versions for local component dependencies)

    > [remote]/[namespcae]/[name]@[version]
      updated dependencies: [remote]/[namespace]/[name]@[version], [remote]/[name]@[version]
    > [remote]/[name]@[version]
      updated dependencies: [remote]/[name]@[version]

[imsnif]

This looks great!

Are the components under changed components and auto-tagged components duplicated? As in:

changed components
(components that got a version bump)

     > bit/foo@1.0.0
     > bit/bar@2.0.0


auto-tagged components
(version bumps due to new versions for local component dependencies)

    > bit/foo1.0.0
      updated dependencies: bit/baz@1.0.0

[itaymendel]

A component can't be both changed and auto-tagged.

auto-tag is reserved to logging implicit changes to components via modifications in their dependencies. For example, a file named foo depends on bar. A modification to bar causes an implicit modification to foo's functionality. To log a change to a dependency tree (and not actual file contents) - Bit uses auto-tag.

In cases where foo is also modified (+ the dependency bar), and you explicitly tag foo - Bit merge both dependency changes and content updates to the same version.

Still not sure how to explain this using a short enough sentence to fit a terminal output :(

[imsnif]

While I think I understand the auto-tag behaviour, I'm not sure I understand the output. Would it be possible to see an example of the terminal output with component names rather than place-holders?

[itaymendel]

Gotcha. Here's a complete flow with the updated outputs for tag.

$ bit init
successfully initialized a bit workspace.
$ touch foo.js
$ echo "require('./foo.js');" > bar.js
$ bit add foo.js --id foo
tracking component foo:
added foo.js

$ bit add bar.js --id bar
tracking component bar:
added bar.js

$ bit tag --all
2 component(s) tagged
(use "bit export [collection]" to push these components to a remote")
(use "bit untag" to unstage versions)

new components
(first version for components)

     > foo@0.0.1
     > bar@0.0.1

Now we have 2 new components foo and bar. bar depends on foo.
To show output example for auto-tag, we'll modify foo and tag the modifications.

$ echo "modification" > foo.js
$ bit tag foo                                  # we can also use --all in this case, as 'bar' is not modified
2 component(s) tagged
(use "bit export [collection]" to push these components to a remote")
(use "bit untag" to unstage versions)

changed components
(first version for components)

     > foo@0.0.2


auto-tagged components
(version bumps due to new versions for local component dependencies)

    > bar@0.0.2
      updated dependencies: foo@0.0.2

[imsnif]

Thanks for the detailed example!

What do you think about something like this?

2 component(s) tagged
(use "bit export [collection]" to push these components to a remote")
(use "bit untag" to unstage versions)

changed components
(first version for components)

     > foo@0.0.2
       auto-tagged dependents: bar@0.0.2

[itaymendel]

I like the idea of connecting the explicitly tagged components with the ones that are implicitly tagged alongside them. @GiladShoham @davidfirst what say you?

[GiladShoham]

I don't have a decided opinion, both look good for me.
from one hand there is an advantage of making the whole output shorter.
On the other hand, when connecting them someone might miss this auto tag bumping.
@davidfirst what do you think?

[davidfirst]

I like them both, but the last one @imsnif mentioned is more elegant IMO.
I actually do like the fact that the auto-tag doesn't have its own section because, in reality, it's no more than a side effect of tagging the changed components.

[davidfirst]

Completed. Merged.