On Sat, Feb 8, 2025 at 3:28 PM Josef Wolf <jw@xxxxxxxxxxxxx> wrote: > > Hi Elijah, > > On Sat, Feb 08, 2025 at 01:43:05PM -0800, Elijah Newren wrote: > > > Ooh, nice catch. If folks had an appropriate .gitattributes file in > > place in older versions of history, they probably wouldn't have gotten > > into the mess. > > Well, you can't assume that paople get it right from the very start. An > important use case of git is fixing errors made in the past, right? [...] Sorry if it sounded like that was passing judgement; that was not what I intended. I've been in a lot of messes too. I mean, I wrote git-filter-repo because of how many things there were to clean up. I get it, life is messy. Hindsight is 20/20. You can't let perfect be the enemy of the good. You can't prioritize "everything", you have to pick your battles. Iterative improvement, etc. > > ahah, so it is passed via environment variable to the subprocess. > > I find this to be confusing: the primary call should not need this parameter, > since it is invoked from HEAD anyway. No, the primary call I think would need the parameter too; it changes HEAD immediately when it starts rebasing, and continues changing it with each commit it rebases; since it's operating on older versions, by default it'd likely pick the .gitattributes from those older versions as it goes. > Everything else gets it via env-vars. > I'd assume this variable will also be passed to the commands which are invoked > by the -x switch? Yes, I was surprised Phillip's command with --attr-source on the outer-level git invocation worked until I discovered that the code indeed sets the environment variable (which subprocesses, like those created by the --exec/-x switch, will inherit). So, yes, the -x switch stuff seems to inherit that environment variable that the primary call sets in response to that parameter.
