File permissions should be synced (e.g. chmod u+x) to allow e.g. synced shell scripts to work instantaneously.

The file is removed from host where dotfim remove was executed. However, the removed state is not synced to other hosts (files simply remain).

Shebang notation requires the #!/... to stay on top of the file! Currently DotfiM moves content into a section and prepends it with comments.

Currently it's not possible to synchronize dotfile setups for specific environment types only. E.g. one would want a dotfile to exist and work for both a Windows and a Linux mashine. The ability to

• assign specific lines of a file to a profile and
• assign a file to a profile

enable the use of DotfiM for the purpose of

• managing files for different types of environments (Windows/Linux),
• using only dotfiles pertaining to a particular application and
• adding passages/files only used in specific types of environments or situations (e.g. free time vs work environment)

Command overview

• dotfim sync [--profile=<profile>] [<FilesOrFolders>]: allows syncing only specific profiles and/or files/folders
• dotfim profile: list available profiles, and e.g. mark synced ones with *, OR: list available commands only
  • ls list profiles, like above
  • add a profile to be synced on this machine
  • remove profile from this machine's synced profile list
• dotfim add --profile=<profile>[,<profiles>] <dotfile>: Add a specific file to one or more profiles
  • have to check that the file does not contain # dotfim profile <...> control statements!!!

Implications

• The ability to add specific files to profiles requires to either
  • store that info in the file itself (profile header/file name, see below)
  • or store the information in a shared/synced dotfim config file
  • Implementing both could mean a bit more resilience and user friendly design
• If no profile is specified the default profile is used. this allows a user to opt-out of the default profile and only sync specific profiles.

Control comments in dotfiles

# dotfim profile <profile1>,<profile2>,...: only applied to dotfile if the machine's dotfim is set up to be synced with the profile dotfim profile add...

• A dotfile may not contain (see below "however simply") a profile passage for a specific when that is not currently synced (user first has to use dotfim profile add <profile> && dotfim sync --profile <profile>) before allowing the addition of further passages
  • Otherwise, the order in which the new dotfile profile passage should be added is unclear
    • !!!!!! Could however simply add the new profile passage to the bottom of the last gitfile profile passage. OR!!!! use the existing other lines as a reference of where the dotfile passage should be inserted!

Further ideas

• Track which machine/hostname & user uses which profiles (could be stored in gitfile with #managed by dotfim): allows listing which hosts use which profiles
• A file could be assigned to one or more profiles (dotfim add --profile). This means either
  • the file name could be used for distinctaion (e.g. .vimrc.profile_<name1>), or
  • the file contains several sections with headers and splitters (use old sectionHandler?....)

TODO

Add the following ideas:

Several Profiles Can be Assigned to a Passage.
Allows e.g. creating a 'remote' profile. The same passages can be used in other profiles as well.
What about: if I want a passage profiled 'bash' to have a 'remote' and a 'normal' version? -> Add combination of passages? E.g. <'bash','normal'> and <'bash','remote'>?

profiles are like passages, but they may contain passages. E.g. a gitfile would have:

# dotfim profile windows {
# dotfim local windows-machine
...
# dotfim }

# dotfim profile linux
linux profile line

In effect it works like "local/private" (which filters the host name).

463600b#diff-064c10df0b9143aaf638ec8f14cff24aR271

                // TODO: else if git not managed, but dot is still managed?
                //       This might happen when on another machine a file is unmanaged (removed).
                //       Another machine starts up and sees an unmanaged gitfile, but dotfile is
                //       still managed ...
                //       BEWARE: Sync.4 -> Have to create something like 'unmanageDots' container... for sync.4
                //                or Sync.5 ???

One might not want to have all git repo dotfiles synchronized on a machine. At the same time picking out single dotfiles to be synchronized by hand might be tedious if the user only wants to synchronize dotfiles for a specific program (which may be more than one file).

Sets could be used to bundle dotfiles together and allowing the user to for example do

dotfim set add/sync <setName>

Add a command dotfim test <dir=.> which sets up a test environment where

• dotfile root folder is <dir>/dot
• git folder is <dir>/git
• git repo folder is <dir>/repo (run git init --bare and eventually set up some test files as examples)

Can be useful for unit tests and when users want to try/experiment with dotfim.

Should easily be usable with #8 -> just shell into container and try dotfim.

https://github.com/thoughtbot/rcm

Currently, the semantics are a bit odd. dotfim sync initializes (renamed to init in 642b79c), and dotfim syncs.

• dotfim:
  • when run for the first time (no config in pwd): "Run dotfim in a git repository. If you are new, run dotfim init."
  • when config is available: Show available commands (help)

• dotfim init <repository> [<directory>]:
  • Clones repository into directory (or repository basename if no directory given)
  • Asks user for dotfile directory (default user's $HOME)
    • Save dotfile directory info into <directory>/.dotfim/local.(json/yaml)

• dotfim sync [--profile=<profile>] [<FilesOrFolders>]: (actually does the syncing part; currently called update)
  • Currently: Run update
  • New (profiles):
    • Collect all managed gitfiles
    • Check .dotfim.(json/yaml) for managed gitfiles that do not belong to a specific profile
    • Sync these files (without any profile lines)

dotfim should be run in the git repository -> dotfim can store its settings in the git repository

Correction:
Automatically add the correct header to the gitfile (commentIndicator is known as the user had to specify it).

When the set merge tool (git config merge.tool <x>) is not available the error is thrown:

The merge tool is not available as '<x_cmd>'

This error message could be detected and the user advised to set up a working merge tool.
git config --help will display available preset mergetools under merge.tool.

Instead of sections (local and sync) there could be comment control statements to control whether the next line or couple of lines are local.

Control statements are added to the git repository, the comment line is enriched with the host machine name.

dotfile:

<commentIndicator> dotfim local
my local line

gitfile:

<commentIndicator> dotfim local (<HostName>)
my local line

#3 proposes profiles. Dotfim control comments should offer the ability to add lines to specific profile(s) only

<commentIndicator> dotfim profile myprofile1, myprofile2, ...

The default (no comment control statement) means that the line is shared and synced.

Spanning

A feature to span multiple lines with a control comment should be possible:

# dotfim local {
line 1
line 2
# dotfim }

Control comments overview

• dotfim local: will only be applied to the machine
• dotfim private: private lines are never written to the git repository. They are the only lines remaining when unsyncing a file (dotfim remove)
• dotfim profile <profile1>,<profile2>,...: only applied to dotfile if the machine's dotfim is set up to be synced with the profile dotfim sync --profile=...

Considerations

• Previously with the git section only the commit hash was compared and the merging/rebasing handled accordingly. With control comments the content has to be regarded as well and merged into the gitfile.
  • An idea could be to segment the gitfile into sections of hosts (where only local and private lines are listed). The

A Dockerfile to create an image that users of dotfim can spin up could be useful. People unfamiliar with D may feel hesitant to build the app themselves. Containers to the rescue!

Aspects to consider:

• Container requires access to the user's home directory (where dotfiles reside)

• Optimally the container should have a persistent volume (to store its settings and the git repository)

  • In Docker one can use container specific volumes.
  • OR: map git repo volume to existing git repo (offers user a neat way to manually edit the git repo, which could become useful for #3 when the user wants to edit lines in another profile not visible to the current machine (not visible in dotfile, only in gitfile))

• Should enable dotfim test for experimentation in isolated container

There may be more appropriate structures than using sections within a single dotfile.

Ideas might be

• #3 profiles and #7 control comments present a viable alternative to sections.
• Add a section to the dotfile that 'sources' (is this possible for all dotfiles?? Can all dotfiles source other files?!) the appropriate files. In regard to #3 this could relate to sourcing a "common" profile dotfile and others.
  • A possible solution could be to only use "sourcing" when the dotfile supports it (asking the user for the source command), in other cases "profile sectioning" has to be used.

Instead, dotfim remove --all should be an option.. Should that remove all currently synced files? Or all = all in git repository?

Alternatively, dotfim remove --local <dotfile> could achieve that a file is only removed locally from the sync list.

So unsync would do remove --local --all? Meaning the local dotfim will never sync any files.

This will require to keep a managed list of which hosts are tracking a file (or are not tracking, e.g. tracking the exceptions)!

Further, unsyncing a file will keep the 'local' and 'private' sections in the gitfile, so that when syncing it again, dotfim will be able to recreate the previous state. Only when a file is removed the 'local'/'private' sections are removed.
Removing a file should issue a prompt telling the user that the file will no longer be recreated as it is when added again (note: local/private sections remain in dotfile, and git sections in gitfile). (... sections=passages)

Special environment variable in dockerfile -> dotfim init knows that the folders are /git/, /dot/ and /repo/!
No need to ask user.