On Thu, Aug 23, 2018 at 09:34:04AM -0700, Michael Brininstool wrote: > Wow! How condescending of you! In my 35 years of programming and system > administration, tagging a script or config file with a label that > identifies which "version" it is, is essential. When you deploy these > files to 10's of thousand of servers, and problems crop up over the years, > being able to see what version of config files the problem machines have > helps determine the problem scope. Hence, I don't use git!
I don't quite grok your point. If you want to expand @version@ in your scripts kept in Git, it's a matter of setting up a pair of scripts calling sed or something like this. Keyword expansion - Necessarily slows down detection of the fact the checked out copy of a file was changed compared to its "priscine" version. - Is not flexible enough. Clear/smudge filters allows you to sidestep both of these problems. I do understand they create a necessary complexity by requiring to actually have these filters in the place where a repository is checked out. But this is solvable as it's possible to keep a tagged file in a Git repository, which is not part of any commit. I think it would be better to have some helper to do this stuff as part of the Git plumbing layer (i.e. in the core) but alas. [...] -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
