Hi Junio,

On Sat, 13 Aug 2016, Junio C Hamano wrote:

> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> 
> > New Features
> >
> >   • Comes with Git 2.9.3.
> 
> For future reference, what time (in UTC) of the day is convenient
> for you to see an upstream tarball?

Heh... I don't do tarballs anymore, I now use this newfangled tool to
manage source code... "gyt" or something like that, it is called.

:-)

Given that between you and me there is currently a time zone difference of
9h (except for four weeks, two in spring, when it is only 8h, and two in
fall, when it is 10h), I believe we cannot find a time that is convenient
for both of us.

But I also think it is fine, when I discover a new upstream Git version in
the morning, I can spend all day on fixing any problems and on packaging
the result ;-)

> >   • Sports a new --smudge option for git cat-file that lets it pass
> >   blob contents through smudge filters configured for the specified
> >   path.
> 
> Perhaps we want to upstream this, together with a new "--clean" option
> for git hash-object?

No question about that. I just needed this in a hurry and short-circuited
it into Git for Windows before submitting it upstream.

> And after writing all of the above, I noticed that hash-object by
> default uses the clean machinery and that can be turned off by giving
> the "--no-filters" option.  The reason why the option is not called
> "--no-clean" is because it is not just about the clean filter but is
> about using the entirety of convert_to_git() filter chain.

Right, as is the --smudge option (it is about the entirety of
convert_to_worktree()).

> We probably should teach "hash-objects" to take "--filters" for
> consistency.

I actually thought about that, too. Which was one of the reasons I did not
submit the patch to the Git mailing list first, as I expect several
iterations to be necessary to get everything into `master`.

> And then your "git cat-file" patch can be upstreamed with the option
> renamed to (or with an additional synonym) "--filters", which would make
> things consistent.

Right. I would like to ask for a `--smudge` synonym nevertheless, just
because I already use this. On the other hand, it is early enough to tell
everybody who knows about this feature to change their invocation (anybody
who would know about `--smudge` would be in that 1% of users that have
read the release notes, so most likely would read the next release notes,
too).

Ciao,
Dscho