Re: Best way to apply textconv to a working tree file

From: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Date: Jun 1, 2010, 16:07 UTC
Message-ID: <vpqd3walot1.fsf@bauges.imag.fr>
In-Reply-To: <a1ace6b77167a2ad4b4995e8c4d09761@ensimag.fr>

[ Just had IRL discussion with Clément and his co-workers ]

Clément Poulain <clement.poulain@ensimag.imag.fr> writes:

Show 5 quoted lines

> In order to add textconv support to "git-gui blame", we have to run
> textconv on a file which is in the working tree.
> Currently, "git-gui blame" uses the Tcl function 'open' to display the
> content of the working-tree file. This doesn't allow us to run textconv on
> it.

There are actually two distinct issues :

1) The textconv functionality has an API, but isn't available as
   plumbing for scripting purposes (and git gui would like to be able
   to call textconv from the command-line).

2) If one solves issue 1) by adding textconv support to "git
   cat-file", then we can call textconv on a blob in the object
   database, but not on a worktree file. Hence, we still need to add
   support to display worktree files in "git cat-file".

Show 7 quoted lines

> - For revisions, "git-gui blame" is based on "git cat-file blob
> <sha1:path>". Therefore, we thought of adding a "--textconv" option on
> cat-file as well as a "--working-tree" option ("git cat-file --working-tree
> <file>" will display the content of <file> in the working-tree)
>
> - Use the "-p" (pretty print) cat-file's option, with a path beginning by
> ./ (to avoid ambiguous name like HEAD)

After thinking about it, I think a mix of these solutions would be OK:

git cat-file --textconv <blob-sha1>            # Run textconv on blob

git cat-file --textconv <tree-sha1>:<filename> # Run textconv on file
                                               # (in object database)

git cat-file --textconv ./<filename>           # Run textconv on file
                                               # (in worktree)

This preserves the property "1st argument is an option, 2nd argument is the thing to do the cat-file on", hence avoid any possible ambiguities in command-line option parsing.

Another option would be to resurect the WOKRTREE/STAGE magit tokens [1] proposal, and allow

git cat-file --textconv WORKTREE:<filename>

That sounds the most natural to me, but it's probably the most controversial too ...

[1] http://thread.gmane.org/gmane.comp.version-control.git/133087

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/