From: "Randall S. Becker" <email@example.com>
To: "'Johannes Schindelin'" <Johannes.Schindelin@gmx.de>,
"'Simon Doodkin'" <firstname.lastname@example.org>
Subject: RE: feature-request: git "cp" like there is git mv.
Date: Wed, 13 Dec 2017 12:21:53 -0500 [thread overview]
Message-ID: <email@example.com> (raw)
On December 13, 2017 11:40 AM Johannes Schindelin wrote:
>On Tue, 12 Dec 2017, Simon Doodkin wrote:
>> please develop a new feature, git "cp" like there is git mv
>> tomovefile1 tofile2 (to save space).
>> there is a solution in https://stackoverflow.com/a/44036771/466363
>> however, it is not single easy command.
>This is not how this project works. The idea is that it is Open Source, so
that you can develop this feature yourself, and contribute a patch.
Agree with Johannes. Let's help though, to quantify the requirements so that
Simon can get this right. I'm putting my tyrannical repository manager hat
on here rather than developer so...
Are you looking to have git cp copy the entire history of tomovefile1 to
tofile2 or just copy the content of tomovefile1 to tofile2 and add and/or
commit the file?
In the latter, I see the convenience of this capability. Even so, a simple
cp would copy the content and then you can commit it fairly easily. In the
former, copying the entire history of a file inside the repository is going
to potentially cause tofile2 to appear in old commits where prior to the git
cp command the file was not present? In this situation, you are actually
rewriting history and potentially impacting signed commits (which would no
longer pass a signature check, I hope). Stitching repositories is sometimes
done when repairs or reorganization is required, but I'm concerned that this
is opening up a can of worms that breaks the atomicity of commits
(particularly signed ones). What I don't want, for my own teams, is for
members to think that git cp would be a harmless (unless it actually is)
command, rather than a repair/reorg mechanism used for splitting apart a
repository, or copying a file to a new project then splitting selectively.
So, I'm obviously a bit confused about the goal.
Simon: the stackoverflow post provides a few options on this command. Can
you clarify which particular direction you are interest it?
-- Brief whoami: NonStop&UNIX developer since approximately
-- In my real life, I talk too much.
next prev parent reply other threads:[~2017-12-13 17:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-12 10:53 feature-request: git "cp" like there is git mv Simon Doodkin
2017-12-13 16:39 ` Johannes Schindelin
2017-12-13 17:21 ` Randall S. Becker [this message]
2017-12-16 1:31 ` Jonathan Nieder
2017-12-31 19:11 ` Stefan Moch
2017-12-31 19:11 ` [PATCH 1/2] Add test case for mv --dry-run to t7001-mv.sh Stefan Moch
2017-12-31 19:11 ` [PATCH 2/2] mv: remove unneeded 'if (!show_only)' Stefan Moch
2018-02-07 19:49 ` feature-request: git "cp" like there is git mv Junio C Hamano
2018-02-07 20:27 ` Stefan Beller
2018-03-18 20:09 ` Stefan Moch
2018-03-19 20:03 ` Junio C Hamano
2017-12-18 0:28 ` Igor Djordjevic
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:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.
Code repositories for project(s) associated with this public inbox
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).