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. > > Thanks > > Michal Rebase is typically reserved only to modify commits which are not yet "permanent". Once a commit starts being referenced by many others it becomes more and more difficult to rebase it. Any rebase effectively creates a new commit. There are multiple threads discussing renames and handling them in git in the past which are worth re-reading, including at least https://public-inbox.org/git/Pine.LNX.4.58.0504141102430.7211@xxxxxxxxxxxxxxx/ A fuller analysis here too: https://public-inbox.org/git/Pine.LNX.4.64.0510221251330.10477@xxxxxxxxxxx/ As mentioned above in this thread, depending on what context you are using, a change to a commit could be many to many: i.e. a commit which splits into 2, or 3 commits merging into one, or 3 commits splitting apart and then becoming 2 commits. When that happens, what "change id" do you use for each commit?
