Sharing Tasks via Version Control

Each developer has one plan file, named for the email in their version control configuration (git config user.email or hg config ui.username), which also gives the name shown for their work.

Wing shares three kinds of data, each by a choice of your own. Each choice applies to all your working copies of the project, and never changes what other developers share:

When Share Plan is off, the plan file lives under a .TASKS/ directory in the agent working directory, which Wing adds to the version control ignore file. Checking Share Plan moves the file into a sibling TASKS/ directory and adds it to version control, so team members can see what work is planned, in progress, and completed. Unchecking it removes the file from version control and moves it back into .TASKS/. In both cases Wing keeps only one copy of your plan in each working copy and updates it as you work. Your other working copies follow the change once they update to your commit. A working copy that had a private plan then merges it into the shared one, and one whose shared plan is removed keeps it as its private plan.

Your shared checklist steps are always in your own file in TASKS/checks/, whatever Share Plan says. Wing 12.1.1 shows and runs the steps in a checks file written by later versions, but cannot edit, move, or delete them. Steps that Wing 12.1.1 kept in .TASKS/checks/ because Share Plan was off become your personal steps, which are never committed.

Share Journal is stored in a small settings file of your own in .TASKS/settings/, which Wing's commits copy into TASKS/settings/ so that your other working copies follow it. Your Journal files are copied into TASKS/journal/ the same way. See Task History and the Journal for details.

Commits made through Wing include your shared plan file, checklist steps, Journal, and settings file whenever they have changed, including their removal when you stop sharing. Each developer writes only to their own files, so several developers can commit task changes at the same time without merge conflicts.

Queues are stored in the per-user project file and are never shared, because they belong to your own agent sessions.

Merges

Before an agent merges, Wing commits these files on their own, so the merge starts from a clean working copy. An agent stops instead of merging when any other change is uncommitted. A merge runs alone: the agent waits until every other agent session has finished its current turn, and a task whose text asks for a merge or rebase starts only once other sessions are idle. Until the merge is committed or aborted, including one you started outside Wing, only the agent that started it edits files, other tasks that may write files wait to start, and Wing saves its own changes to these files once the merge ends.

Quitting Wing during a merge waits for the agent to commit it, and offers Abort Merge to put the working copy back as it was before the merge, or Abort Merge and Quit Now to do that and quit without waiting.

Seeing Other Developers' Work

Other developers' shared data is hidden by default. Each place that can show it has a filter icon, shown only when there is such data, whose menu offers No Other Users (the default), All Other Users, or a list of the developers to check one by one:

These choices are made separately in each working copy. The TASKS/ directory is watched for external changes, so updates from other developers appear without restarting Wing once you update to their commits.