Cli-microsoft365: New command: Update a Microsoft To Do task list

[garrytrinder]

Usage

todo list set [options]

Description

Update a Microsoft To Do task list

Options

| Option | Description |
| ----------------------- | ----------------------------------------- |
| -i, --id <id> | The ID of the list to update |
| -n, --name <name> | The name of the task list |

Additional Information

PATCH https://graph.microsoft.com/beta/me/todo/lists/<id>
{ "displayName":"<name>" }

[ypcode]

@garrytrinder can I please take this one too ? I'll wait for your confirmation this time :P

[waldekmastykarz]

Please do @ypcode. Thank you! 👏

[ypcode]

@waldekmastykarz do you know a good way to start these ones without redoing manually the common changes (with the add and remove commands) before the PR are merged to dev? I would like to avoid any cumbersome (and maybe nasty) conflict and trying to keep only the relevant commit in the PR

[waldekmastykarz]

The approach I follow is:

• keep dev in my fork synced with upstream dev (git pull upstream dev + git push origin dev)
• for each PR I create a separate feature branch: git checkout -b feature-123
• I submit a PR from that feature
• if I want to start working on another feature, I get back to dev (git checkout dev) and create a new feature branch (git checkout -b feature-456)

That way my dev is always clean and never contains anything that's not in dev upstream. One challenge is when multiple features share some changes or one feature depends on another. Unfortunately there is no easy answer for it. You can choose from:

• submit a PR with one feature and wait with building the other until the PR is merged
• create separate PRs for each feature and include the changes in each one. Merge should see that changes are the same and handle them properly
• create branch for feature 2 off of the branch for feature 1. In that case though, you won't be able to submit a PR for feature 2 before feature 1 PR is merged and even then you could run into nasty merge conflicts.

Does this help?

[ypcode]

It's the main approach I generally use,
however in this case, I forked from my first PR branch and forgot to rebase and did not take care the previous commit was obviously ncluded.
Actually, I think I just got the easier approach here.

• fork branch from previous PR branch
• git reset to the upstream dev, and clean up the unrelated changes with the current PR.

Somehow, it might be a little "extra work" for you guys, since there will probably be conflicts since the same lines in files are then used for different changes

[waldekmastykarz]

You mean files like commands.ts or mkdocs.yml? These changes are typically easy to merge so no additional work for us ☺️

[ypcode]

Then I know how to keep smooth! Thanks for your answers. I definitely love working on the CLI. I earn a lot of experience from it!

[waldekmastykarz]

Thank you for the kind words. Happy to hear you find it worth your time 😊

[garrytrinder]

Marked as on hold until the APIs are released fully released by the Graph team.