Re: [git-users] Git attributes smudge/clean filters
On Tue, 15 Jan 2013 08:17:50 -0800 (PST) Russell wrote: [...] > > That way your repository always keeps "normalized" blobs. > > I agree that this is exactly what I would do to mimic RCS behaviour. > But I am deliberately trying not to for the reason described below: > > Unfortunately using this method seems to create a certain ambiguity > when creating a formal release (perhaps my understanding is faulty, > so I would appreciate clarification if so). Suppose that I do all my > final commits and am now ready for release. For release suppose that > I do a fresh git clone. Using the RCS method every file will now be > smudged to have the same "last modified" date equal to the date I > cloned. This is technically not correct, although perhaps it is close > enough. > > Alternatively I could not do a fresh clone for release and use my > working directory so that files not changed for some time might not > be freshened by a pull and thus will have an older "last modified" > date. > > The problem now is that if I do the release this time, and the > next time my colleague does a release from her working directory the > files will likely have completely different "last modified" dates > depending on what sets of files have been changed between us and when > the original clones of the working directories was done. In my > opinion this is not viable since there is now no consistency at all > in the "last modified" dates between releases. > > Perhaps this RCS method is "close enough" for most purposes, but I am > trying to get a last modified date that is somewhat more realistic > and probably more defensible in the eyes of the law if it was ever > needed. Okay, so it seems what you really want is to have that "last modified" date to be actually tied to the creation time of the commit object which is checked out, not some sort of the "current" time at which the smudge filter is run. If so, then update your smudge filter to call `git rev-parse HEAD` and then parse the output of `git cat-object commit ` to extract the commit timestamp from it; use this timestamp to replace the placeholder values. This would guarantee that anyone who checks out revision XYZ would get the same actual "last modified" date in the checked out files. One caveat of this approach: if someone checks that revision XYZ out, then modifies one of the files containing the placeholder and then records a new commit, then may be they also will need to `git reset --hard` before cutting a release out of their checkout to "refresh" the actual timestamps in the files according to the updated HEAD. In any case, I start to think your approach is flawed. What if you quit updating those placeholders using filters and instead try to somehow formally automate the releasing process itself? I mean, when a new release is due, someone runs a script which does `git archive` on a blessed "release" tag and then runs through the exported tree replacing all those placeholders in the files with the timestamp obtained from that tag's underlying commit object? --
Re: [git-users] Git attributes smudge/clean filters
On Friday, January 11, 2013 5:41:39 PM UTC-5, Dale Worley wrote: > > > Half of your problem is clear: When you check in a file, the > version that gets into the repository is processed as you've arranged for > it > to be. But of course, that doesn't change the file in the working > copy, because that file isn't changed during the checkin process. > > Exactly why "checkout --force" doesn't work, I don't know. But > presumably git has recorded somewhere that the contents of the > repository were generated from the working copy file, and thus > considers them "the same". Probably this stems from the same design > assumption that called the operation "clean", that is, that the file > contents before and after the transformation are considered to be > functionally the same. > > Isn't git using the SHA1 hash to distinguish files? If so, there should be a different hash for the local copy and the repo copy - and somehow it should be clear that the repo copy is newer so I expected that at the very least git checkout would work without --force. Is this a bug in git? --
Re: [git-users] Git attributes smudge/clean filters
On Friday, January 11, 2013 5:41:57 PM UTC-5, Konstantin Khomoutov wrote: > > You seem to misunderstand the concept a bit. > The blobs kept in the repo should have some neutral placeholder, such as > to read something like "Last modified $Timestamp$" in them. > > Then, in the smudge filter, which is run after checking out the blob > into a file in the work tree, you replace that $Timestamp$ with > something appropriate for your work tree. > > Then, in the clean filter, which is run before the new blob is written > to the repository, your task is to *revert* that local change, that is, > to change whatever your smudge filter did back to $Timestamp$. > > That way your repository always keeps "normalized" blobs. > I agree that this is exactly what I would do to mimic RCS behaviour. But I am deliberately trying not to for the reason described below: Unfortunately using this method seems to create a certain ambiguity when creating a formal release (perhaps my understanding is faulty, so I would appreciate clarification if so). Suppose that I do all my final commits and am now ready for release. For release suppose that I do a fresh git clone. Using the RCS method every file will now be smudged to have the same "last modified" date equal to the date I cloned. This is technically not correct, although perhaps it is close enough. Alternatively I could not do a fresh clone for release and use my working directory so that files not changed for some time might not be freshened by a pull and thus will have an older "last modified" date. The problem now is that if I do the release this time, and the next time my colleague does a release from her working directory the files will likely have completely different "last modified" dates depending on what sets of files have been changed between us and when the original clones of the working directories was done. In my opinion this is not viable since there is now no consistency at all in the "last modified" dates between releases. Perhaps this RCS method is "close enough" for most purposes, but I am trying to get a last modified date that is somewhat more realistic and probably more defensible in the eyes of the law if it was ever needed. --
Re: [git-users] Git attributes smudge/clean filters
On Fri, Jan 11, 2013 at 11:56:43AM -0800, Russell wrote:
> I am trying to implement a filter that updates a "Last modified: "
> field in a source file comment header on commit. From the reading I've done
> so far this seems to be a different approach to the usual "mimic RCS
> behaviour" approach that uses a source file with the $Date$ (or similar)
> keyword that gets replaced with the current date on checkout.
>
> Most succintly my approach is thus:
>sed "s|Last modified: [0-9]*|Last modified: ${currentYear}|"
> ie. On a clean, look for "Last modified: " text and replace it
> with "Last modified: " as the file is committed (a change to a
> file isn't "real" until it is preserved in the repo).
>
> I think this approach makes more sense than the RCS approach because now
> the central repository always represents the actual commited changes,
> rather than some abstraction using variables and the local files should
> also be perfectly aligned with packaging for distribution via tarball or
> such because the dates are self-consistent.
>
> The problem is that the local files and the files in the repo end up out of
> sync. The local files have the old date, but the repo has the modified
> date. I have to rm the file and git checkout to get the change in
> my local directory; strangely git checkout --force doesn't pick up the
> change either.
>
> Is someone able to explain what I need to do to make this work?
You seem to misunderstand the concept a bit.
The blobs kept in the repo should have some neutral placeholder, such as
to read something like "Last modified $Timestamp$" in them.
Then, in the smudge filter, which is run after checking out the blob
into a file in the work tree, you replace that $Timestamp$ with
something appropriate for your work tree.
Then, in the clean filter, which is run before the new blob is written
to the repository, your task is to *revert* that local change, that is,
to change whatever your smudge filter did back to $Timestamp$.
That way your repository always keeps "normalized" blobs.
--
Re: [git-users] Git attributes smudge/clean filters
> From: Russell > > The problem is that the local files and the files in the repo end up out of > sync. The local files have the old date, but the repo has the modified > date. I have to rm the file and git checkout to get the change in > my local directory; strangely git checkout --force doesn't pick up the > change either. Half of your problem is clear: When you check in a file, the version that gets into the repository is processed as you've arranged for it to be. But of course, that doesn't change the file in the working copy, because that file isn't changed during the checkin process. Exactly why "checkout --force" doesn't work, I don't know. But presumably git has recorded somewhere that the contents of the repository were generated from the working copy file, and thus considers them "the same". Probably this stems from the same design assumption that called the operation "clean", that is, that the file contents before and after the transformation are considered to be functionally the same. Dale Dale Worley -- Back in 2004, The Onion predicted that Gillette would release a 5-blade razor in a satire entitled: "F**k Everything, We're Doing Five Blades". Well, it happened. It's called the Gillette Fusion. And now, the thing has a battery and vibrates... Do we really need 5 blades that vibrate? -- "The Elusive Perfect Shave" --
