> Now knowing the edge cases won't work, I did not get an idea about the > standard case of what should work with this. Would you mind to write > a more detailed example or a more advertising paragraph of what this can do? > Not getting the big picture may be related to me having not worked with RCS yet. Stefan, RCS Keywords, while originating from RCS, are commonly used in CVS and SVN. A lot of LaTeX workflows in the scientific community, for example, use these keyword substitutions, trapping scientists in legacy SCMSes. In my environment, we do builds and deployments from within pristine working copies or "checkouts of trunk", we also have some deployments that are symlinks into live checkouts of trunk, and we have production support workflows where support personnel inspect files remotely and subsequent escalation procedures rely on the contents of the $Author$ substitutions, etc. As a result of this, projects that have migrated to git are demanding the restoration of their RCS keyword substitutions. In CVS/SVN, keywords are expanded on checkout, placing text related to the most recent history of a give file into that file. RCS has one keyword that takes action on check-in (or commit), being the $Log$ keyword, which is a running commit log of the file in the file. Keyword expansions are not stored in the repo, but are substituted on their out of the repo into the working copy, and substitutions are reversed on their way from the working copy into the repo. Git's export-subst feature in git-archive is very similar to RCS Keywords. What I'm providing here is a mechanism to enable export-subst functionality throughout normal git workflows and not just during builds that employ git-archive, as if export-subst worked alongside git's ident feature. Perhaps described the known issues I've found will also help towards understanding... Known Issues ------------ Edge Case #1 (aka, modified smudge filter) 1. create new branch 2. edit smudge filter 3. commit 4. switch back to previous branch 5. smudge filter is temporarily disappeared at the moment the smudge filter wants to run This edge case is a side-effect of the order in which git performs deletions in the worktree and extractions from the index and executions of the filters. This edge case is related to a similar to one seen in older git versions where the smudge is disappeared during a "git checkout-index -a -f", but the sequence of operations has been fixed in more recent gits, so the smudge does not disappear during a checkout-index. Edge Case #2 1. create branch B from branch A 2. make changes in branch A, commit 3. checkout branch B 4. git merge A 5. while editing commit file, file being modified lacks keywords (expected) 6. delete commit message, cancelling commit 7. file remains w/o substituted keywords 8. cancel merge w/ git reset --merge ORIG_HEAD & restored original file is w/o substituted keywords Reason: no available state transition on reset --merge Edge Case #3 1. create branch B from branch A, checkout B 2. modify file, commit 3. checkout A 4. make conflicting edit to same file 5. git rebase B, rebase will conflict 6. git rebase --abort 7. file will be w/o substituted keywords Known Unissues -------------- Not-an-Edge-Case #1 1. create branch B from branch A, checkout B 2. modify file, commit 3. checkout A 4. git merge --squash B 5. file as modified from B is w/o substituted keywords AS EXPECTED - that version of file does not yet contain history in A, file will gain substitutions following commit -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html