From: "Shawn O. Pearce" <spearce@spearce•org>
To: lmage11@twcny•rr.com
Cc: git@vger•kernel.org
Subject: Re: Proposed git mv behavioral change
Date: Thu, 18 Oct 2007 21:54:19 -0400 [thread overview]
Message-ID: <20071019015419.GV14735@spearce.org> (raw)
In-Reply-To: <c594999b2337.2337c594999b@nyroc.rr.com>
Line wrapping email at under 80 columns would be nice. It makes it
easier to read the message, and more importantly, easier to quote
a few times during discussion.
lmage11@twcny•rr.com wrote:
> Therefore, I propose that git mv's behavior be changed. I think it
> would make far more sense for a move to only change the actual name
> of the file and to not pull in unstaged changes. In other words,
> I'd like the index entry for the original file name to be removed
> and an index entry to be added with a different name, but using the
> exact same blob hash as the original file. I don't know exactly how
> git manages the index internally, but a shortcut for this would be
> to simply rename the index entry in place.
I'm somewhat hesistant to change existing behavior, as users may
be used to it or relying upon it within their scripts. But you
make an excellent argument about why the current git-mv behavior
is perhaps less than ideal.
Elsewhere in git we use the --cached command line option to mean
"only make the change in the index". For example the git-apply
--cached option. You could start a patch that uses --cached to
trigger the new behavior you propose and see if people are interested
in changing the default once the feature is working and available
for experimentation.
> I'm willing to look into what changes would need to be made to the
> code for this change to happen; I'm not asking for someone to do
> all the work for me. :)
>
> So... Yeah. I'd like to know what people think about this before
> I put a significant amount of effort into it. After all, we know
> how lazy programmers are... :)
See builtin-mv.c around l.264-283. This is where we are removing
the old names from the index (in memory) and inserting the new
names. Instead of calling add_file_to_cache() you would want
to use something like add_cacheinfo() in builtin-update-index.c,
specifying the old sha1, ce_flags and ce_mode.
I'm sure Junio could probably give you a better starting point
than I can, as he's more familiar with this sort of code, but that
should still get you looking in the right direction and maybe get
a working implementation together that you can share for discussion.
--
Shawn.
next prev parent reply other threads:[~2007-10-19 1:54 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-18 15:47 Proposed git mv behavioral change lmage11
2007-10-19 1:47 ` Michael Witten
2007-10-19 1:57 ` Shawn O. Pearce
2007-10-19 2:07 ` Michael Witten
2007-10-19 2:15 ` Shawn O. Pearce
2007-10-19 2:16 ` Jeff King
2007-10-19 2:29 ` Michael Witten
2007-10-19 11:33 ` Wincent Colaiuta
2007-10-19 15:57 ` Michael Witten
2007-10-19 1:54 ` Shawn O. Pearce [this message]
2007-10-19 2:54 ` Michael Witten
2007-10-19 3:19 ` Shawn O. Pearce
2007-10-19 3:24 ` Jeff King
2007-10-19 3:26 ` Michael Witten
2007-10-19 3:35 ` Jeff King
2007-10-19 3:40 ` Michael Witten
2007-10-19 3:47 ` Jeff King
2007-10-19 3:53 ` Michael Witten
2007-10-19 3:58 ` Jeff King
2007-10-20 5:55 ` Ari Entlich
2007-10-20 6:24 ` Jeff King
2007-10-20 6:34 ` Michael Witten
2007-10-20 6:36 ` Jeff King
2007-10-20 6:36 ` Shawn O. Pearce
2007-10-20 6:40 ` Jeff King
2007-10-22 14:00 ` Karl Hasselström
2007-10-20 6:45 ` Michael Witten
2007-10-20 7:02 ` Shawn O. Pearce
2007-10-20 11:15 ` Wincent Colaiuta
2007-10-22 14:08 ` Karl Hasselström
2007-10-20 5:55 ` Ari Entlich
2007-10-20 6:30 ` Shawn O. Pearce
2007-10-20 7:46 ` Mike Hommey
2007-10-20 6:34 ` Jeff King
-- strict thread matches above, loose matches on Subject: below --
2007-10-19 4:41 lmage11
2007-10-20 5:55 Ari Entlich
2007-10-20 6:31 ` Jeff King
2007-10-20 11:02 ` Wincent Colaiuta
2007-10-20 11:06 ` Jeff King
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=20071019015419.GV14735@spearce.org \
--to=spearce@spearce$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=lmage11@twcny$(echo .)rr.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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