On Fri, Jul 22, 2022 at 03:46:22PM -0700, Jacob Keller wrote: > 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? Same as commit message and any trailers you might have - they are preserved, concatenated, and can be regenerated. Thanks Michal
