Junio C Hamano <gitster@xxxxxxxxx> writes: > Eric Frederickson <ericfrederickson68@xxxxxxxxx> 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@xxxxxxxxx https://emfred.com
