Re: A Question from a Hopeful Future Contributor

[Eric Frederickson <ericfrederickson68@gmail.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Eric Frederickson <ericfrederickson68@gmail.com> writes:
>
>> Looking through the repo for a place to find todo items, I naturally stumbled
>> upon the TODO file in the origin/todo branch,...
>
> Please disregard that file (I should remove it from the repository,
> too).  It is not curated at all, and the last update to it is more
> than 13 years ago.

I see -- sorry for the noise on that.

(Funnily enough, I had checked blame of those lines to (try to) make sure that
they were at least semi-recent, and took a glance at the commit that shipped
them, which I saw was dated from April. Somehow, I had assumed that "April"
meant "April of this year" and forgot to check the actual year... it was, as
you're indicating, from April 2011. (*facepalm*))

> Sorry for wasting your time.

The mistake was all mine. Lesson learned!

> A better sources of inspiration might
> come from list archive searches for the past 3 year or so.
>
> https://lore.kernel.org/git/?q=%22%23leftoverbit%22+d%3A20220718..
>
> But even then, many itches have already been scratched.

I've been enjoying looking through these "leftoverbits", and may take some up
soon.

> As is often said, in open source, the easiest is to start scratching
> your own itch ;-)

Indeed! And I have 2 things to bring up on that subject, which are also in reply to
Ayush's suggestions about trying out a micro-project:

Firstly, I was reading through git-bisect.adoc (on master, 90c0775e97) and
noticed a small error on line 146 (the entire paragraph, lines 146-148, is given
for context):

> To use "old" and "new" instead of "good" and bad, you must run `git
> bisect start` without commits as argument and then run the following
> commands to add the commits:

It seems that the word "bad" should be quoted there, resulting in this revised
version:

> To use "old" and "new" instead of "good" and "bad", you must run `git
> bisect start` without commits as argument and then run the following
> commands to add the commits:

Writing here to ask if a tiny fix like this would be a good thing to submit as a
first patch. (This feels like it would be an embarrassingly small patch, but you
have said prior [1] that "it is rare that anything is too trivial as a
microproject material", so perhaps I'm in-bounds here :)).

Secondly, and more substantially, there's an itch I'm thinking about trying to
scratch, which involves teaching git-diff some options which can enable it to
give more useful outputs when diffing binary files, and, moreover, to diff them
"natively" without converting them to line-oriented plaintext first (as that
behavior is already covered by use of the "textconv" config option).

I'm imagining a way for users to pass some information to git-diff which
specifies a concept of "logical lines", similar in concept to the "--word-diff"
option, but where what's parsed as a "word" / "line" / delimiter can be
specified by the user. A feature like this could enable users to have git do
things like diff an image file pixel by pixel, or diff an audio file second by
second ("second" meaning "1 real-time second in playback"), all without doing
any batch conversions. (Note that I'm not intending to denigrate the very useful
"textconv" option and its associated workflow; just proposing another way of
trying to work towards a similar ideal.)

This itch comes from my use of git repositories to manage audio files that I
publish on my website, and being unsatisfied with the "Binary files differ"
message while also not having anything available as a "textconv" worker program.
I feel like there's a lot of "potential energy" in these kinds of use-cases for
git to provide ways of (re)viewing changes to these files to users who work with
updating binary data.

Writing here to ask if pursuing this line of thought would be a good idea. I've
intentionally been light on concrete detail here, because I'm still working
things out myself and don't want to waste anyone's time with details that aren't
worth reading through. Something as simple as a "Yay" or "Nay" on this idea is
all I'd need to know if I'm walking a useful path here.

Thank you, and best wishes,
--
Eric Frederickson
ericfrederickson68@gmail.com
https://emfred.com