git-filesync 0.23.4

Pull again before the commit: a staged pull is no adaptation

Changes:

• A pull staged but not committed yet no longer shows the file as
  adapted or 'not adaptable!': the committed file is compared with the
  base it was committed with. The same for add --overwrite over a
  committed file.
• Pulling a file again before the commit works, e.g. to another version;
  the proposed message gets a section for each pull. Merged adaptations
  still need a commit first.
• pull --overwrite after a staged pull no longer reports content as
  discarded.

Documentation:

• MANUAL: pulling again before the commit.

git-filesync 0.23.3

Try a newer version in the working tree; staged changes count as uncommitted

Changes:

• pull -W/--worktree: write what pull would sync into the working tree
  only - nothing staged, .git-filesync unchanged - e.g. to see whether
  your project still builds with it. 'git restore' goes back,
  'pull --overwrite' takes it.
• pull --overwrite also discards uncommitted changes, keeping them
  ('discarded: ... (git show ...)'); nothing is reported as discarded when
  the file already has what is written.
• Staged changes are uncommitted changes: status reports them (also with
  the working file as in HEAD again), and pull and rm refuse them like
  changes in the working tree.
• Commands that stage .git-filesync warn if it had changes not staged
  before; those are staged too.
• Hints say 'git restore -SW' to discard uncommitted changes.

Compatibility:

• pull --overwrite (also with --all) no longer refuses uncommitted
  changes: it discards them, keeping their content as a Git object.
• rm without -f refuses files with staged changes.

Documentation:

• MANUAL: "Trying a newer version".

git-filesync 0.23.2

pull --all only takes plain updates; source map keeps links in DIR

Changes:

• pull --all leaves out files that are no plain update along their
  branch or tag, and names them: older than last sync, history diverged
  (synced from another branch or a rebased commit, also with the same
  version), previous sync point unknown. pull FILE syncs them.
  Fixes a file synced from a commit that was later rebased: it showed
  "not pushed" forever and pull said "up to date".
• status calls such files "diverged" (was "changed").
• pull --all --overwrite also restores up-to-date files with local changes.
• source map stores DIR as given: a junction, symlink or drive letter on
  the way is no longer resolved.

Compatibility:

• pull --all no longer goes back to an older version or merges a diverged
  history, also after set -b/--tag; pull those files by name.

git-filesync 0.23.1

Patterns of a linked directory always shell-quoted in .git-filesync

Changes:

• include / exclude are written shell-quoted throughout, like git-assetsync
  writes its lists: include = '*.c' instead of include = *.c (also for
  patterns with ! or non-ASCII characters).

Compatibility:

• Existing .git-filesync files read the same; their values keep their form
  until the patterns change.

git-filesync 0.23.0

set shows what it sets; patterns of a linked directory apply at the next pull

Changes:

• set PATH... without options prints each entry as the set command that
  sets it, every aspect included; entered again, it changes nothing.
  set --list does so for all entries.
• source set NAME [--url URL] [-b BRANCH] changes a source; without
  options it shows it (--list: all sources).
• source set and source rename take -n.
• set --include/--exclude only change .git-filesync and say what the next
  pull does ("at the next pull: 2 new, 0 deleted"). status shows the
  entry as pending; pull fetches newly selected files and deletes those no
  longer selected (adapted ones: refused, --force keeps, --overwrite
  deletes).
• set -p with the path already set changes nothing.
• pull of a linked directory counts a file renamed in it as renamed.

Compatibility:

• source set-url and source set-branch are gone: use source set --url / -b.
• set --include/--exclude no longer fetch files at once, and pull deletes
  files the patterns no longer select (until now they stayed).
• set -p with the same path no longer takes the current upstream version
  as the new base.

Documentation:

• MANUAL: set, source, Linked directories; when -n is there and what it
  does.

git-filesync 0.22.0

Linked directories: add DIR links the directory, pull adds and deletes files

Changes:

• add URL|SOURCE DIR links the directory as one [dir] entry (base: upstream
  commit and tree). Its files are those of the upstream directory that its
  --include/--exclude patterns select. pull also fetches files new upstream,
  deletes those deleted there and merges adaptations (adaptable); a file
  renamed within the directory takes its adaptations along. No command
  touches files of your own in the directory.
• status shows a linked directory in one line, with the number of files
  concerned: "adapted: lib/ (1 of 40 files)".
• A file of a linked directory that is missing is never allowed, as for a
  linked file - unless upstream deleted it too: then pull stages the
  deletion.
• pull --force keeps a file of this repository that pull would delete
  (adapted here, deleted upstream) or replace (new upstream, in an
  adaptable entry).
• set --include/--exclude (--no-include/--no-exclude) change the patterns of
  a linked directory, at once; set -p makes it a new link.
• status, diff, difftool and restore also take files in a linked directory;
  pull, set, rm and unlink take the whole entry; mv moves the directory with
  your own files. Entries must not overlap.

Compatibility:

• add URL DIR now creates a [dir] entry; the previous behavior (a [file]
  entry for each file) is add --per-file. Existing [file] entries stay
  valid; to switch, unlink them (the files stay), then add the directory.

Documentation:

• MANUAL: new section "Linked directories"; add, pull, set, rm, mv,
  restore, diff.
• Pinned example versions in README and MANUAL set to v0.22.0.

git-filesync 0.21.3

Current directory reached through a link (Windows): no crash

Changes:

• Run directly ('python git-filesync.py', not through the git alias) in a
  directory reached through a subst drive, it no longer fails with
  "ValueError: path is on mount 'C:', start on mount 'D:'". Through a
  junction, paths are shown without '../' detours. Paths given count from
  the real directory, as for git.

Documentation:

• Pinned example versions in README and MANUAL set to v0.21.3.

git-filesync 0.21.2

Clearer hints for unknown sync points; fewer git calls

Changes:

• The hooks no longer tell to pull a file whose previous sync point isn't
  in the source (pull --all leaves such a file alone); they point to
  status, which explains it.
• The status hint fits the source: a mapped checkout may be behind
  (update it, or use --remote); a cached upstream asks the server, so
  there the commit isn't on the server - history rewritten, synced from an
  unpushed commit or from another upstream - and 'pull FILE' syncs it.
• pull --all names each file it leaves out, with the reason, as
  git-assetsync does: "warning: a.c: missing - left out (see 'git
  filesync status')"; likewise "modified, but not adaptable" and
  "previous sync point not found". Before, only their number was given
  when there were several.
• set --source and source set-url name 'pull FILE' when the synced
  version isn't in the new upstream.
• pull of an adapted file whose synced version is gone upstream names
  'pull --overwrite FILE', which takes the upstream version.
• --overwrite keeps a staged version it replaces also when the working
  tree file is already the upstream version.
• Fewer git calls, which matters most on Windows: short commit ids are
  asked for at once (before, one call each), the first syncs of a pull
  keep discarded content at once, and pull --all reads nothing for files
  it leaves alone. mv of many files stays within the Windows command line
  limit.

Documentation:

• MANUAL: set --source and pull FILE for an unknown sync point; what
  pull --all says about files it leaves out.
• Pinned example versions in README and MANUAL set to v0.21.2.

This release replaces the 0.21.2 of earlier the same day, which gave only
the number of the files pull --all left out.

git-filesync 0.21.1

Review fixes: mv all or none, unknown sync points, discarded content

Changes:

• A recorded commit the source doesn't have - it may be behind (a mapped
  checkout not updated, not fetched) or upstream history was rewritten -
  is not guessed at: status shows the file as 'changed (previous sync
  point unknown)' and names both ways on, pull --all leaves it alone
  ("need attention"), and pull FILE syncs it to the source's current
  version. Before, pull --all synced it, possibly back to an older version.
• mv OLD... DIR checks every OLD before moving any, and moves nothing if
  one fails: something in the way no longer leaves the others moved and
  .git-filesync unstaged.
• restore -S only sets the index, so something in the way in the working
  tree no longer stops it.
• --overwrite (add, and pull at the first sync of a new link) replaces an
  existing file only if it differs from the upstream version: an
  identical one is no longer reported as replaced or kept as discarded.
• Where rm -f, --overwrite or restore -S replace the index entry, a staged
  version that is neither committed nor in the working tree is kept too:
  "discarded: FILE, as staged (git show ID to get it back)", as the
  working tree file was (line ends, LFS).
• Proposed commit messages stay free of signature lines with
  log.showSignature set.
• Fewer git calls: mv of several files, and dates for pull when a
  recorded commit is unknown.

Documentation:

• README and MANUAL shorter and to the point; README "Why?" is
  "Motivation"; same structure as git-assetsync.
• MANUAL: unknown previous sync points; the scheduled CI job; discarded
  content, also staged versions; restore -S with something in the way.
• Pinned example versions in README and MANUAL set to v0.21.1.

This release replaces the 0.21.1 of earlier the same day, whose guess at
a source being behind is gone again.

git-filesync 0.21.0

--remote ignores mappings once; dates in commit messages; mv OLD... DIR

Changes:

• --remote (status, pull, diff/difftool, restore, add, set, source
  set-url/set-branch) works against the upstream URL this once, ignoring
  a mapping to a local checkout (source map); the mapping stays. With
  --no-fetch: the cached state.
• Proposed commit messages give every upstream commit id with its date
  (the committer date), the subject's included:
  "[filesync] Sync src/foo.c from owner/lib@a1b2c3d (2026-10-28)",
  "Upstream changes since 3f2a9c1 (2026-09-12):",
  "- Fix off-by-one (9e8d7c6, 2026-10-27)".
• mv OLD... DIR moves several linked files into an existing directory,
  like git mv: all are checked first, then all moved.

Documentation:

• MANUAL: --remote; dates in proposed commit messages; mv OLD... DIR.
• Pinned example versions in README and MANUAL set to v0.21.0.