On Fri, Jul 22, 2022 at 1:42 PM Michal Suchánek <msuchanek@xxxxxxx> wrote: > > On Fri, Jul 22, 2022 at 09:08:56PM +0100, Philip Oakley wrote: > > On 21/07/2022 19:58, Hilco Wijbenga wrote: > > > On Thu, Jul 21, 2022 at 9:39 AM Phillip Susi <phill@xxxxxxxxxxxx> wrote: > > >> Ęvar Arnfjörš Bjarmason <avarab@xxxxxxxxx> writes: > > >> > > >>> This has come up a bunch of times. I think that the thing git itself > > >>> should be doing is to lean into the same notion that we use for tracking > > >>> renames. I.e. we don't, we analyze history after-the-fact and spot the > > >>> renames for you. > > >> I've never been a big fan of that quality of git because it is > > >> inherently unreliable. > > > Indeed, which would be fine ... if there were a way to tell Git, "no > > > this is not a rename" or "hey, you missed this rename" but there > > > isn't. > > > > > > Reading previous messages, it seems like the > > > after-the-fact-rename-heuristic makes the Git code simpler. That is a > > > perfectly valid argument for not supporting "explicit" renames but I > > > have seen several messages from which I inferred that rename handling > > > was deemed a "solved problem". And _that_, at least in my experience, > > > is definitely not the case. > > > > Part of the rename problem is that there can be many different routes to > > the same result, and often the route used isn't the one 'specified' by > > those who wish a complicated rename process to have happened 'their > > way', plus people forget to record what they actually did. Attempting to > > capture what happened still results major gaps in the record. > > Doesn't git have rebase? > > It is not required that the rename is captured perfectly every time so > long as it can be amended later. "so long as". Therefore, since it can't be amended after the commit is accepted/merged, it is required that this auxiliary data be captured perfectly before that time if it's going to be captured at all. Did I read that right?
