From: Chris Torek <chris.torek@gmail.com>
To: Jeremy Morton <admin@game-point.net>
Cc: git@vger.kernel.org
Subject: Re: Proposal: tell git a file has been renamed
Date: Sun, 23 Apr 2023 18:43:18 -0700 [thread overview]
Message-ID: <CAPx1Gvdc6bqzt2PpqD1Z4e5w+b=8gZhUSyfUQC1n8QazdBacEw@mail.gmail.com> (raw)
In-Reply-To: <8fe188a9-c01f-9fb5-5877-8ff508094b22@game-point.net>
(By the way, apologies for the stuttering "gitt" typos that seem
to keep creeping into my messages here. I'm not sure what's
causing them -- I make a lot of typos but this is abnormal!)
On Sat, Apr 22, 2023 at 12:22 PM Jeremy Morton <admin@game-point.net> wrote:
> [renames are a problem]
I have long wondered if there was a way to improve this
experience myself.
(I also note that most of the followup messages up to this point
have missed the point. It's true that you can run `git mv` and
`git commit`, but you've already said that this becomes
particularly painful when you realize that it's appropriate *after
the fact*, when you've already made intermediate commits and/or
staged changes or whatever.)
> The standard answer for this is to rename the file in one commit, then
> make the changes. That's fine if you know ahead of time you'll want
> to do this. However it's a total PITA if you have a bunch of changes
> and you realize that a rename has caused this problem. You now have
> to back out your changes to the renamed file, add the rename, commit
> it, then re-apply the changes.
>
> Could a command be added to git that means you tell Git that counts as
> a file rename? Git would add a marker to the staging area that the
> file has been renamed, and upon commit, would first generate an
> additional commit for each rename before generating the main commit,
> ensuring the rename operation counts as an actual rename, and the
> content's history is maintained.
The index *currently* has no room to store anything like this: it
is, in effect, just the proposed next commit, stored as a
flattened tree. There are, however, extra marker records that
can be added. So:
If `git mv` (or a new command) had a flag to say "make a special
index entry so that the next `git commit` does a double commit",
we could in fact make this work. Alternatively, we could have a
command -- similar to `git commit --only` in effect -- that uses
the current (HEAD) commit to construct a renames-only commit, in
which 100%-identical-file matching would (in general) find the
desired renames -- and make it, perhaps also co-ordinating with
`git mv` of existing files in the index. (I'd also like to have
`git mv --after`, in the same vein as `hg mv --after`; I long ago
wrote a cheesy script to achieve this, but it would be nice to
have a proper command.)
On top of this, it might be nice to have a standardized commit
message and/or other marker (in the commit header?) for a "rename-
only" commit, which this kind of extra-rename-commit operation
would use. Then `git log` and `git blame` and other commands
could easily detect such commits and default to an automatic
`--follow` style following, and `git log` might be allowed to omit
the *display* of such a commit by default, by showing all the
renames as renames in the subsequent commit (though this would
presumably require an internal verification step to check for
spoofed renames that are not in fact rename-only operations).
In any case, this *idea* is easy, like many ideas. It really
comes down to implementation. If someone thinks this is a great
idea, someone (perhaps me) should work on *implementing* it. :-)
Chris
next prev parent reply other threads:[~2023-04-24 1:43 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-22 18:01 Proposal: tell git a file has been renamed Jeremy Morton
2023-04-22 18:54 ` rsbecker
2023-04-22 19:44 ` Jeremy Morton
2023-04-22 19:47 ` rsbecker
2023-04-22 19:54 ` Jeremy Morton
2023-04-22 22:09 ` rsbecker
2023-04-23 9:38 ` Erik Cervin Edin
2023-04-23 21:01 ` Kristoffer Haugsbakk
2023-04-24 1:43 ` Chris Torek [this message]
2023-04-24 10:10 ` Jeremy Morton
2023-04-24 10:24 ` Chris Torek
2023-04-24 10:49 ` Erik Cervin Edin
2023-04-24 11:17 ` Jeremy Morton
2023-04-24 14:00 ` Erik Cervin Edin
2023-04-24 14:42 ` Jeremy Morton
2023-04-24 19:25 ` Felipe Contreras
2023-04-24 19:44 ` Jacob Keller
2023-04-24 20:00 ` Felipe Contreras
2023-04-26 19:08 ` Jacob Keller
2023-04-26 20:39 ` Junio C Hamano
2023-05-11 13:44 ` Erik Cervin Edin
2023-04-24 18:26 ` Junio C Hamano
2023-04-24 19:41 ` Junio C Hamano
2023-04-24 20:05 ` Jeremy Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPx1Gvdc6bqzt2PpqD1Z4e5w+b=8gZhUSyfUQC1n8QazdBacEw@mail.gmail.com' \
--to=chris.torek@gmail.com \
--cc=admin@game-point.net \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).