Mbed-cli: Enhancement request: mbed upgrade or mbed update -f

[RobMeades]

See conversation over in #505, it is a complete pain trying to develop a set of libraries as there is no way to tell mbed to just update everything to latest. I recognise that there are dangers in doing this but, when actively developing a suite of libraries, a developer is perfectly aware of any changes he/she has made and just wants everything to stay in sync with what's archived; the only way to do that is to jump through all the directories and update each one individually, which is just horrible, almost unworkable, especially when one has to do it in the right order to avoid elements higher in the try downgrading the ones below again.

Hence, I request a new feature, which could either be mbed upgrade or a -f (==force) switch to mbed update. The effect of this would be to update all the libraries to their latest versions, re-writing the .lib files as it goes. A warning could be provided, something like "All libraries will be update to their latest versions, which may introduce incompatibilities; are you sure you want to continue? (y/n)"

[bridadan]

How would you feel about mbed update --recursive/-r ?

[RobMeades]

Yes, like that, even more intuitive.

[bridadan]

@theotherjimmy @screamerbg Thoughts? Concerns?

[theotherjimmy]

Sounds like a good idea. Would be useful for developing libraries. I like the "default behavior that probably won't break something" and "turn on dangerous mode" duality. @screamerbg will probably want a warning.

[bridadan]

Feature request: mbed config -G dangerous_mode enabled 😛

[theotherjimmy]

@bridadan FTFY

Feature request: mbed config -G danger_zone enabled 😛

[screamerbg]

@RobMeades @bridadan I like the feature request, and also that it doesn't impact the default behavior. The online IDE supports this via the Update All functionality already.

Want to hear @sg- 's thoughts as well.

[sg-]

👍

[theotherjimmy]

@RobMeades It looks like your feature has approval. Did you plan on implementing it?

[RobMeades]

Ah, well, umm, I'd have to learn Python first...

[theotherjimmy]

@RobMeades No worries. I'll get on it soon. :wink:

[theotherjimmy]

I just tried some stuff here, the diff is _tiny_ (+3, -2). However, There is a limitation: You cannot update the repos that have a detached head state. my current implementation of -r/--recursive updates all repos that are _on a branch_ in the tree of the current project.

[RobMeades]

If I've understood detached head state properly, that might be the kind of situation where you'd really appreciate mbed update -r, as a sort of "get me to head" rescue. I suppose it could warn the user and they'd have to go and do a manual mbed update in the directory instead?

[theotherjimmy]

@RobMeades When your dependency is in a detached head state, mbed CLI has no way to determine what branch you are on, so mbed update -r will do the same thing as mbed update for that one dependency. If, OTOH, you are not in a detached head state, it updates to the latest revision of the current tracking branch.

[theotherjimmy]

The reason we can't determine which branch you are on is simple. Let's talk about a repo with a single commit:

a - master

Now I create another branch with another commit on top:

a---b - new-branch
 \
  master

Now we do something very reasonable: we add a commit to master

a---b - new-branch
 \  
   c - master

Now I check out the commit before master (a in the diagram). Which branch am I behind now?

[RobMeades]

Understood. I think it would be good for the user to know if mbed update -r was unable to update a .lib because it was in a detached HEAD state, basically print a message saying so, then they know it's going to be left behind and they can fix it manually. That would be fine.

[theotherjimmy]

@RobMeades I'll look into making that happen.

[RobMeades]

Many thanks.

[theotherjimmy]

@RobMeades It's done. Check PR #512

[RobMeades]

Excellent, many thanks guys, I'll wait for it to get into a release and try it out.