Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

Finn Arne Gangstad [off-list ref] writes:

On Wed, Jun 23, 2010 at 03:09:32PM -0700, Junio C Hamano wrote:

quoted

* eb/double-convert-before-merge (2010-06-16) 1 commit
 - ll-merge: Normalize files before merging

If running git-to-worktree and then worktree-to-git _fixes_ something, it
means that these are not roundtrip operations; there is something that is
fundamentally wrong.  The commit log message doesn't help explaining it,
either.

If .gitattributes is different on the different sides, or if you
enable autocrlf, the current repo contents may change after
git-to-worktree and worktree-to-git again.

IOW, g2w-then-w2g may not be an identity function.

If we were to encourage use of this codepath to wider audiences, we may
need to have a document for people who write smudge/clean filters.  In
order for the result to be stable, applying g2w-then-w2g once again on top
of the result of running g2w-then-w2g on anything should be no-op, no?

On 24. juni 2010, at 22.21, Junio C Hamano wrote:

Finn Arne Gangstad [off-list ref] writes:

quoted

If .gitattributes is different on the different sides, or if you
enable autocrlf, the current repo contents may change after
git-to-worktree and worktree-to-git again.

IOW, g2w-then-w2g may not be an identity function.

If we were to encourage use of this codepath to wider audiences, we may
need to have a document for people who write smudge/clean filters.  In
order for the result to be stable, applying g2w-then-w2g once again on top
of the result of running g2w-then-w2g on anything should be no-op, no?

Hm.  Isn't that already a requirement?  If a clean filter doesn't clean to something normalized, simply touching a file could result in spurious differences (much like pre-safe-autocrlf autocrlf).  I could well be missing something here, though.
-- 
Eyvind

Am 6/24/2010 22:21, schrieb Junio C Hamano:

Finn Arne Gangstad [off-list ref] writes:

quoted

If .gitattributes is different on the different sides, or if you
enable autocrlf, the current repo contents may change after
git-to-worktree and worktree-to-git again.

IOW, g2w-then-w2g may not be an identity function.

If we were to encourage use of this codepath to wider audiences, we may
need to have a document for people who write smudge/clean filters.  In
order for the result to be stable, applying g2w-then-w2g once again on top
of the result of running g2w-then-w2g on anything should be no-op, no?

I think this is implicit to some degree in the documentation,
gitattributes(5):

  The content filtering is done to massage the content into a shape that
  is more convenient for the platform, filesystem, and the user to use.
  [...] the intent is that if someone unsets the filter driver
  definition, or does not have the appropriate filter program, the
  project should still be usable.

From this I read that the content of the repository can only be in a

canonical shape; hence, the only thing that a clean filter can do is to
generate the canonical shape of the data. This is, by definition, an
idempotent operation (i.e., g2w(g2w(x)) == g2w(x)).

(I'm talking only about clean filters because any pair of smudge+clean
filters where the clean filter cannot undo the effect of the smudge filter
would be noticed immediately and be considered broken without being
mentioned explicitly in the documentation.)

-- Hannes

On Thu, Jun 24, 2010 at 01:21:49PM -0700, Junio C Hamano wrote:

quoted

If .gitattributes is different on the different sides, or if you
enable autocrlf, the current repo contents may change after
git-to-worktree and worktree-to-git again.

IOW, g2w-then-w2g may not be an identity function.

Absolutely, pretty much by definition this cannot be the case (and is
not the case for any of the built-in filters like eol, autocrlf,
ident), since you have no control of what you have in the repository
before you enable the filter.

What we assume though is that g2w(g2w(x)) == g2w(x). I think it is
very hard to come up with a reasonable case for a filter where that is
not the case.

If we were to encourage use of this codepath to wider audiences, we may
need to have a document for people who write smudge/clean filters.  In
order for the result to be stable, applying g2w-then-w2g once again on top
of the result of running g2w-then-w2g on anything should be no-op, no?

This _has_ to work, otherwise you would get dirty contents after a
checkout, and that would be horrible.

So, the follolwing should be true:

g2w(x) == g2w(g2w(x))
A -> g2w() -> B -> g2w() -> B ... 

w2g(g2w(x)) == w2g(g2w(w2g(g2w(x))))
X -> g2w() -> w2g() -> Y -> g2w() -> w2g() -> Y ...

Running w2g() twice should also be the same as running it once. 
I thought nothing in git required it as such, but in the case of a
missing smudge filter git will call w2g() on something that is already
cleaned. I think the clean/smudge guidelines should be:

  "Both clean and smudge filters should be idempotent; running them
   multiple times should not alter the contents further."

- Finn Arne