On Wed, Nov 26, 2014 at 8:44 AM, Derek Moore <derek.p.moore@xxxxxxxxx> wrote: > Junio, et al., > > I've completed my first pass at RCS Keywords in Git. I believe I've > come up with a solution that is accurate, performant and complete (but > I have not tested it on big repos yet, I'm doing that today...). > > https://github.com/derekm/git-keywords > > This work basically takes advantage of all the state-machine > transitions in git to surgically perform "git update-index $(git > archive $(git log -1 --format=%H @ -- $path) -- $path | tar vx)" > overwrites in the work tree. (It also exposes some state transitions > that are entirely absent from git, creating a few edge cases, but they > are relatively unimportant edge cases if your deployed git repos will > be managed by an automated system [humans doing development workflows > can trigger the edge cases when cancelling certain operations, all > edge cases just leave you with un-substituted files, which will become > substituted again after checkouts, commits, merges, rewrites, etc.].) 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. Thanks, Stefan > Only $Author$, $Date$ and $Revision$ can be emulated presently. $Id$ > and other tags requiring filename paths or basenames are possible, but > would require changes internal to git allowing "pretty format" codes > inside a file to triangulate filenames from blob hash and commit hash > pairs. > > I believe this work fundamentally proves that the theory of RCS > keywords is sound in the context of Git, and that full support in > git-core is entirely achievable in short order. In fact, other areas > in git would become improved for several reasons if git devs ingested > some of the results of this work. > > There is a lot of gainsaying and kneejerk reaction to the idea of > keywords under the assumption of distributed development because of > the fallacy of thinking in terms of shared/universal linear history > instead of in terms of relative spacetime events. > > Keyword substitution can be done accurately relative to the history of > the possessor of that history. Last edit timestamps and last authors > and revision IDs are important to many workflows inside and outside > development. > > Of the keywords emulated, the only thing I couldn't achieve > (obviously) were monotonically increasing revision numbers, instead I > went with the file's most recent commit short hash (which is more > proper for git anyway). > > To test it out... > > 1) clone the repo: > > git clone https://github.com/derekm/git-keywords > > 2) cd into the repo and setup the hooks: > > ln -sf ../../post-checkout-filter.pl .git/hooks/post-checkout > ln -sf ../../pre-commit-check.pl .git/hooks/pre-commit > ln -sf ../../post-commit-filter.pl .git/hooks/post-commit > ln -sf ../../post-merge-filter.pl .git/hooks/post-merge > ln -sf ../../post-rewrite-filter.pl .git/hooks/post-rewrite > > 3) edit .git/config and setup the filters: > > [filter "keywords"] > smudge = ./keyword-smudge.pl %f > clean = ./keyword-clean.pl > > 4) inspect the lack of substitutions: > > head -4 * > > 5) initialize the repo with first substitutions: > > for i in $(git ls-tree --name-only @); do > git update-index \ > $(git archive \ > $(git log -1 --format=%H @ -- $i) -- $i | tar vx) > done > > 6) inspect the presence of substitutions: > > head -4 * > > 7) ??? (start hacking, try to break it, etc.) > > 8) PROFIT! > > PS: I may consider rewriting the hooks in Bash, but I need to audit > what commands are available under msys-git. > -- > 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 -- 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