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. Thanks Michal
