{"thread":{"id":"47430","subject":"feature-request: git \"cp\" like there is git mv.","startedAt":"2017-12-12T10:54:04Z","lastAt":"2018-03-19T20:03:57Z","messageCount":12,"participants":["Simon Doodkin","Johannes Schindelin","Randall S. Becker","Jonathan Nieder","Igor Djordjevic","Stefan Moch","Junio C Hamano","Stefan Beller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"334671","messageId":"CANaQPdK4xWek3PhiFZrURBBTgPBwsC3d3watd-cWVNBVZRqZRA@mail.gmail.com","threadId":"47430","inReplyTo":null,"subject":"feature-request: git \"cp\" like there is git mv.","fromName":"Simon Doodkin","fromEmail":"helpmepro1@gmail.com","sentAt":"2017-12-12T10:53:38Z","receivedAt":"2017-12-12T10:54:04Z","isPatch":false,"sender":{"key":"helpmepro1@gmail.com","avatar":null},"body":"please develop a new feature, git \"cp\" like there is git mv tomovefile1 tofile2\n(to save space).\n\nthere is a solution in https://stackoverflow.com/a/44036771/466363\nhowever, it is not single easy command.\n"},{"id":"334759","messageId":"alpine.DEB.2.21.1.1712131739080.23267@MININT-6BKU6QN.europe.corp.microsoft.com","threadId":"47430","inReplyTo":"CANaQPdK4xWek3PhiFZrURBBTgPBwsC3d3watd-cWVNBVZRqZRA@mail.gmail.com","subject":"Re: feature-request: git \"cp\" like there is git mv.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-12-13T16:39:50Z","receivedAt":"2017-12-13T16:40:11Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Simon,\n\nOn Tue, 12 Dec 2017, Simon Doodkin wrote:\n\n> please develop a new feature, git \"cp\" like there is git mv tomovefile1\n> tofile2 (to save space).\n> \n> there is a solution in https://stackoverflow.com/a/44036771/466363\n> however, it is not single easy command.\n\nThis is not how this project works. The idea is that it is Open Source, so\nthat you can develop this feature yourself, and contribute a patch.\n\nCiao,\nJohannes\n"},{"id":"334762","messageId":"000501d37436$e2659340$a730b9c0$@nexbridge.com","threadId":"47430","inReplyTo":"alpine.DEB.2.21.1.1712131739080.23267@MININT-6BKU6QN.europe.corp.microsoft.com","subject":"RE: feature-request: git \"cp\" like there is git mv.","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2017-12-13T17:21:53Z","receivedAt":"2017-12-13T17:22:10Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"-----Original Message-----\nOn December 13, 2017 11:40 AM Johannes Schindelin wrote:\n>On Tue, 12 Dec 2017, Simon Doodkin wrote:\n>> please develop a new feature, git \"cp\" like there is git mv \n>> tomovefile1 tofile2 (to save space).\n>> there is a solution in https://stackoverflow.com/a/44036771/466363\n>> however, it is not single easy command.\n>This is not how this project works. The idea is that it is Open Source, so\nthat you can develop this feature yourself, and contribute a patch.\n\nAgree with Johannes. Let's help though, to quantify the requirements so that\nSimon can get this right. I'm putting my tyrannical repository manager hat\non here rather than developer so...\n\nAre you looking to have git cp copy the entire history of tomovefile1 to\ntofile2 or just copy the content of tomovefile1 to tofile2 and add and/or\ncommit the file?\n\nIn the latter, I see the convenience of this capability. Even so, a simple\ncp would copy the content and then you can commit it fairly easily. In the\nformer, copying the entire history of a file inside the repository is going\nto potentially cause tofile2 to appear in old commits where prior to the git\ncp command the file was not present? In this situation, you are actually\nrewriting history and potentially impacting signed commits (which would no\nlonger pass a signature check, I hope). Stitching repositories is sometimes\ndone when repairs or reorganization is required, but I'm concerned that this\nis opening up a can of worms that breaks the atomicity of commits\n(particularly signed ones). What I don't want, for my own teams, is for\nmembers to think that git cp would be a harmless (unless it actually is)\ncommand, rather than a repair/reorg mechanism used for splitting apart a\nrepository, or copying a file to a new project then splitting selectively.\nSo, I'm obviously a bit confused about the goal.\n\nSimon: the stackoverflow post provides a few options on this command. Can\nyou clarify which particular direction you are interest it?\n\nCheers,\nRandall\n\n-- Brief whoami: NonStop&UNIX developer since approximately\nUNIX(421664400)/NonStop(211288444200000000) \n-- In my real life, I talk too much.\n\n\n\n"},{"id":"334910","messageId":"20171216013130.GB188893@aiede.mtv.corp.google.com","threadId":"47430","inReplyTo":"CANaQPdK4xWek3PhiFZrURBBTgPBwsC3d3watd-cWVNBVZRqZRA@mail.gmail.com","subject":"Re: feature-request: git \"cp\" like there is git mv.","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-12-16T01:31:30Z","receivedAt":"2017-12-16T01:31:39Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Simon,\n\nSimon Doodkin wrote:\n\n> please develop a new feature, git \"cp\" like there is git mv tomovefile1 tofile2\n> (to save space).\n>\n> there is a solution in https://stackoverflow.com/a/44036771/466363\n> however, it is not single easy command.\n\nThis sounds like a reasonable thing to add.  See builtin/mv.c for how\n\"git mv\" works if you're looking for inspiration.\n\ncmd_mv in that file looks rather long, so I'd also be happy if someone\ninterested refactors to break it into multiple self-contained pieces\nfor easier reading (git mostly follows\nhttps://www.kernel.org/doc/html/latest/process/coding-style.html#functions).\n\nThanks,\nJonathan\n"},{"id":"334956","messageId":"45bf86e5-1cac-58ca-8ac1-0400b7efd568@gmail.com","threadId":"47430","inReplyTo":"CANaQPdK4xWek3PhiFZrURBBTgPBwsC3d3watd-cWVNBVZRqZRA@mail.gmail.com","subject":"Re: feature-request: git \"cp\" like there is git mv.","fromName":"Igor Djordjevic","fromEmail":"igor.d.djordjevic@gmail.com","sentAt":"2017-12-18T00:28:11Z","receivedAt":"2017-12-18T00:28:22Z","isPatch":false,"sender":{"key":"igor.d.djordjevic@gmail.com","avatar":null},"body":"Hi Simon,\n\nOn 12/12/2017 11:53, Simon Doodkin wrote:\n> \n> please develop a new feature, git \"cp\" like there is git mv \n> tomovefile1 tofile2 (to save space).\n> \n> there is a solution in https://stackoverflow.com/a/44036771/466363\n> however, it is not single easy command.\n\nWhile having `git cp` alongside `git mv` would make sense, I`m afraid \nthat is not what you are really after, nor it would help in your case.\n\nLooking at referenced \"Stack Overflow\" post[1], it tries to address \n`git blame` not following \"file copy\", where it does \"file rename\".\n\nProposed steps seem to be \"solution\" from your perspective, and while \nthat may be absolutely valid and acceptable for your specific case, I \nwould argue it`s the wrong approach in general - because `git blame` \nalready supports what you want (just not by default), and making \nthree additional, unneeded and possibly confusing commits (one being \na merge), just to \"bend\" `git blame` to fit your (out of line?) usage \nexpectations doesn`t seem right.\n\nI would say a better direction might be using `git blame` \"-C[<num>]\" \noption[2], where desired effect is achieved without any artificial \nhistory fiddling.\n\nExample being worth more than plain words, I`m providing a script[3] \nthat demonstrates what I`m talking about :)\n\nRegards, Buga\n\n[1] https://stackoverflow.com/a/44036771/466363\n[2] https://git-scm.com/docs/git-blame#git-blame--Cltnumgt\n[3] Demo script showing how using (multiple) \"-C\" option(s), with \n    specified numeric value, can make `git blame` provide desired \n    information, recognizing \"file copy\" operation (line copy, actually, \n    but that is what we are really interested in, using `git blame`):\n--- >8 ---\n\tgit init\n\n\techo a >A\n\techo b >>A\n\techo c >>A\n\n\tgit add A\n\tgit commit -m \"create file A\"\n\n\tgit mv A B\n\tgit commit -m \"rename file A -> B\"\n\n\t# ---\n\t# (A) regular flow\n\tcp B C\n\tgit add C\n\tgit commit -m \"copy file B -> C\"\n\t# ---\n\n\t# ---\n\t# (B) proposed \"solution\", https://stackoverflow.com/a/44036771/466363\n\t# git mv B C\n\t# git commit -n -m \"rename file B -> C\"\n\t# SAVED=`git rev-parse HEAD`\n\t# git reset --hard HEAD^\n\t# git mv B B-temp\n\t# git commit -n -m \"rename file B -> B-temp\"\n\t# git merge $SAVED # This will generate conflicts\n\t# git commit -a -n --no-edit # Trivially resolved like this\n\t# git mv B-temp B\n\t# git commit -n -m \"rename file B-temp -> B\"\n\t# ---\n\n\techo\n\techo '(1) blames B back to A, as expected:'\n\tgit blame -- B\n\t# git blame shows that file B has a history (back to file A)...\n\n\techo\n\techo '(2) blames C only, missing B and A:'\n\tgit blame -- C\n\t# ... while file C doesn't have a history\n\n\techo\n\techo '(3) blames C back to A, as expected:'\n\tgit blame -C -C3 -- C\n\t# git blame shows that file C has a history (back to file A)\n"},{"id":"335586","messageId":"20171231191156.28359-1-stefanmoch@mail.de","threadId":"47430","inReplyTo":"20171216013130.GB188893@aiede.mtv.corp.google.com","subject":"Re: feature-request: git \"cp\" like there is git mv.","fromName":"Stefan Moch","fromEmail":"stefanmoch@mail.de","sentAt":"2017-12-31T19:11:54Z","receivedAt":"2017-12-31T19:19:09Z","isPatch":false,"sender":{"key":"stefanmoch@mail.de","avatar":null},"body":"* Jonathan Nieder <jrnieder@gmail.com> [2017-12-15T17:31:30-0800]:\n> This sounds like a reasonable thing to add.  See builtin/mv.c for how\n> \"git mv\" works if you're looking for inspiration.\n> \n> cmd_mv in that file looks rather long, so I'd also be happy if someone\n> interested refactors to break it into multiple self-contained pieces\n> for easier reading (git mostly follows\n> https://www.kernel.org/doc/html/latest/process/coding-style.html#functions).\n\nI looked at builtin/mv.c and have a rough idea how to split it\nup to support both mv and cp commands.\n\nBut first I noticed and removed a redundant check in cmd_mv,\nalso added a test case to check if mv --dry-run does not move\nthe file.\n\n\nStefan\n"},{"id":"335587","messageId":"20171231191156.28359-2-stefanmoch@mail.de","threadId":"47430","inReplyTo":"20171231191156.28359-1-stefanmoch@mail.de","subject":"[PATCH 1/2] Add test case for mv --dry-run to t7001-mv.sh","fromName":"Stefan Moch","fromEmail":"stefanmoch@mail.de","sentAt":"2017-12-31T19:11:55Z","receivedAt":"2017-12-31T19:19:11Z","isPatch":true,"sender":{"key":"stefanmoch@mail.de","avatar":null},"body":"It checks if mv --dry-run does not move file.\n\nSigned-off-by: Stefan Moch <stefanmoch@mail.de>\n---\n t/t7001-mv.sh | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/t/t7001-mv.sh b/t/t7001-mv.sh\nindex 6e5031f56..d4e6485a2 100755\n--- a/t/t7001-mv.sh\n+++ b/t/t7001-mv.sh\n@@ -38,6 +38,12 @@ test_expect_success \\\n     'git diff-tree -r -M --name-status  HEAD^ HEAD | \\\n     grep \"^R100..*path1/COPYING..*path0/COPYING\"'\n \n+test_expect_success \\\n+    'mv --dry-run does not move file' \\\n+    'git mv -n path0/COPYING MOVED &&\n+     test -f path0/COPYING &&\n+     test ! -f MOVED'\n+\n test_expect_success \\\n     'checking -k on non-existing file' \\\n     'git mv -k idontexist path0'\n-- \n2.14.3\n\n"},{"id":"335588","messageId":"20171231191156.28359-3-stefanmoch@mail.de","threadId":"47430","inReplyTo":"20171231191156.28359-1-stefanmoch@mail.de","subject":"[PATCH 2/2] mv: remove unneeded 'if (!show_only)'","fromName":"Stefan Moch","fromEmail":"stefanmoch@mail.de","sentAt":"2017-12-31T19:11:56Z","receivedAt":"2017-12-31T19:19:52Z","isPatch":true,"sender":{"key":"stefanmoch@mail.de","avatar":null},"body":"Commit a127331cd (mv: allow moving nested submodules,\n2016-04-19), introduced\n\n    if (show_only) continue;\n\nin this for-loop before\n\n    if (!show_only)\n\nwhich became redundant, because it is now always true.\n\nSigned-off-by: Stefan Moch <stefanmoch@mail.de>\n---\n builtin/mv.c | 3 +--\n 1 file changed, 1 insertion(+), 2 deletions(-)\n\ndiff --git a/builtin/mv.c b/builtin/mv.c\nindex cf3684d90..8ce6a2ddd 100644\n--- a/builtin/mv.c\n+++ b/builtin/mv.c\n@@ -286,8 +286,7 @@ int cmd_mv(int argc, const char **argv, const char *prefix)\n \n \t\tpos = cache_name_pos(src, strlen(src));\n \t\tassert(pos >= 0);\n-\t\tif (!show_only)\n-\t\t\trename_cache_entry_at(pos, dst);\n+\t\trename_cache_entry_at(pos, dst);\n \t}\n \n \tif (gitmodules_modified)\n-- \n2.14.3\n\n"},{"id":"338657","messageId":"xmqqinb87f70.fsf@gitster-ct.c.googlers.com","threadId":"47430","inReplyTo":"20171231191156.28359-1-stefanmoch@mail.de","subject":"Re: feature-request: git \"cp\" like there is git mv.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-02-07T19:49:39Z","receivedAt":"2018-02-07T19:49:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Moch <stefanmoch@mail.de> writes:\n\n> * Jonathan Nieder <jrnieder@gmail.com> [2017-12-15T17:31:30-0800]:\n>> This sounds like a reasonable thing to add.  See builtin/mv.c for how\n>> \"git mv\" works if you're looking for inspiration.\n>> \n>> cmd_mv in that file looks rather long, so I'd also be happy if someone\n>> interested refactors to break it into multiple self-contained pieces\n>> for easier reading (git mostly follows\n>> https://www.kernel.org/doc/html/latest/process/coding-style.html#functions).\n>\n> I looked at builtin/mv.c and have a rough idea how to split it\n> up to support both mv and cp commands.\n>\n> But first I noticed and removed a redundant check in cmd_mv,\n> also added a test case to check if mv --dry-run does not move\n> the file.\n\nI guess these two patches went unnoticed when posted at the end of\nlast year.  Reading them again, I think they are good changes.\n\nAs a no-op clean-up of a127331c (\"mv: allow moving nested\nsubmodules\", 2016-04-19), the attached would also make sense, I\nwould think.\n\nThanks.\n\n builtin/mv.c | 7 ++++---\n 1 file changed, 4 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin/mv.c b/builtin/mv.c\nindex 9662804d23..9cb07990fd 100644\n--- a/builtin/mv.c\n+++ b/builtin/mv.c\n@@ -266,10 +266,11 @@ int cmd_mv(int argc, const char **argv, const char *prefix)\n \t\tconst char *src = source[i], *dst = destination[i];\n \t\tenum update_mode mode = modes[i];\n \t\tint pos;\n-\t\tif (show_only || verbose)\n-\t\t\tprintf(_(\"Renaming %s to %s\\n\"), src, dst);\n-\t\tif (show_only)\n+\t\tif (show_only) {\n+\t\t\tif (verbose)\n+\t\t\t\tprintf(_(\"Renaming %s to %s\\n\"), src, dst);\n \t\t\tcontinue;\n+\t\t}\n \t\tif (mode != INDEX && rename(src, dst) < 0) {\n \t\t\tif (ignore_errors)\n \t\t\t\tcontinue;\n\n"},{"id":"338665","messageId":"CAGZ79kbX4uhDpdp0kH=8+5tj_zLWZbtbMUb5WWtOeXWRQz8K3Q@mail.gmail.com","threadId":"47430","inReplyTo":"xmqqinb87f70.fsf@gitster-ct.c.googlers.com","subject":"Re: feature-request: git \"cp\" like there is git mv.","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-02-07T20:27:27Z","receivedAt":"2018-02-07T20:27:37Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Feb 7, 2018 at 11:49 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Stefan Moch <stefanmoch@mail.de> writes:\n>\n>> * Jonathan Nieder <jrnieder@gmail.com> [2017-12-15T17:31:30-0800]:\n>>> This sounds like a reasonable thing to add.  See builtin/mv.c for how\n>>> \"git mv\" works if you're looking for inspiration.\n>>>\n>>> cmd_mv in that file looks rather long, so I'd also be happy if someone\n>>> interested refactors to break it into multiple self-contained pieces\n>>> for easier reading (git mostly follows\n>>> https://www.kernel.org/doc/html/latest/process/coding-style.html#functions).\n>>\n>> I looked at builtin/mv.c and have a rough idea how to split it\n>> up to support both mv and cp commands.\n>>\n>> But first I noticed and removed a redundant check in cmd_mv,\n>> also added a test case to check if mv --dry-run does not move\n>> the file.\n>\n> I guess these two patches went unnoticed when posted at the end of\n> last year.  Reading them again, I think they are good changes.\n>\n> As a no-op clean-up of a127331c (\"mv: allow moving nested\n> submodules\", 2016-04-19), the attached would also make sense, I\n> would think.\n>\n> Thanks.\n>\n>  builtin/mv.c | 7 ++++---\n>  1 file changed, 4 insertions(+), 3 deletions(-)\n>\n> diff --git a/builtin/mv.c b/builtin/mv.c\n> index 9662804d23..9cb07990fd 100644\n> --- a/builtin/mv.c\n> +++ b/builtin/mv.c\n> @@ -266,10 +266,11 @@ int cmd_mv(int argc, const char **argv, const char *prefix)\n>                 const char *src = source[i], *dst = destination[i];\n>                 enum update_mode mode = modes[i];\n>                 int pos;\n> -               if (show_only || verbose)\n> -                       printf(_(\"Renaming %s to %s\\n\"), src, dst);\n> -               if (show_only)\n> +               if (show_only) {\n> +                       if (verbose)\n> +                               printf(_(\"Renaming %s to %s\\n\"), src, dst);\n>                         continue;\n> +               }\n\nThis is actually changing behavior to\n\n    if (show_only && verbose)\n        print(...)\n\n    if show_only\n        continue\n\nThe second part is already there as is, only the printing behavior\nactually changes.\n\nSo I might be missing the obvious here for the claim of no-op?\n\nLooking up further we have (line 177):\n\n    if (show_only)\n        printf(_(\"Checking rename of '%s' to '%s'\\n\"), src, dst);\n\nwhich prints regardless of verbosity.\n"},{"id":"342112","messageId":"20180318210908.3ed94777.stefanmoch@mail.de","threadId":"47430","inReplyTo":"xmqqinb87f70.fsf@gitster-ct.c.googlers.com","subject":"Re: feature-request: git \"cp\" like there is git mv.","fromName":"Stefan Moch","fromEmail":"stefanmoch@mail.de","sentAt":"2018-03-18T20:09:08Z","receivedAt":"2018-03-18T20:16:33Z","isPatch":false,"sender":{"key":"stefanmoch@mail.de","avatar":null},"body":"* Junio C Hamano <gitster@pobox.com> [2018-02-07T11:49:39-0800]:\n> Stefan Moch <stefanmoch@mail.de> writes:\n> \n> > * Jonathan Nieder <jrnieder@gmail.com> [2017-12-15T17:31:30-0800]:  \n> >> This sounds like a reasonable thing to add.  See builtin/mv.c for\n> >> how \"git mv\" works if you're looking for inspiration.\n> >> \n> >> cmd_mv in that file looks rather long, so I'd also be happy if\n> >> someone interested refactors to break it into multiple\n> >> self-contained pieces for easier reading (git mostly follows\n> >> https://www.kernel.org/doc/html/latest/process/coding-style.html#functions).  \n> >\n> > I looked at builtin/mv.c and have a rough idea how to split it\n> > up to support both mv and cp commands.\n> >\n> > But first I noticed and removed a redundant check in cmd_mv,\n> > also added a test case to check if mv --dry-run does not move\n> > the file.  \n> \n> I guess these two patches went unnoticed when posted at the end of\n> last year.  Reading them again, I think they are good changes.\n\nThanks.\n\nAre such redundant checks in general a pattern worth searching\nfor and cleaning up globally? Or is this rather in the category\nof cleaning up only when noticed?\n\n\n> As a no-op clean-up of a127331c (\"mv: allow moving nested\n> submodules\", 2016-04-19), the attached would also make sense, I\n> would think.\n> \n> Thanks.\n> \n>  builtin/mv.c | 7 ++++---\n>  1 file changed, 4 insertions(+), 3 deletions(-)\n> \n> diff --git a/builtin/mv.c b/builtin/mv.c\n> index 9662804d23..9cb07990fd 100644\n> --- a/builtin/mv.c\n> +++ b/builtin/mv.c\n> @@ -266,10 +266,11 @@ int cmd_mv(int argc, const char **argv, const\n> char *prefix) const char *src = source[i], *dst = destination[i];\n>  \t\tenum update_mode mode = modes[i];\n>  \t\tint pos;\n> -\t\tif (show_only || verbose)\n> -\t\t\tprintf(_(\"Renaming %s to %s\\n\"), src, dst);\n> -\t\tif (show_only)\n> +\t\tif (show_only) {\n> +\t\t\tif (verbose)\n> +\t\t\t\tprintf(_(\"Renaming %s to %s\\n\"),\n> src, dst); continue;\n> +\t\t}\n>  \t\tif (mode != INDEX && rename(src, dst) < 0) {\n>  \t\t\tif (ignore_errors)\n>  \t\t\t\tcontinue;\n> \n\nAs Stefan Beller already noted, this changes the printing\nbehavior:\n<https://public-inbox.org/git/CAGZ79kbX4uhDpdp0kH=8+5tj_zLWZbtbMUb5WWtOeXWRQz8K3Q@mail.gmail.com/>\n\nSee also the output of\n\n    git mv -n\n    git mv -n -v\n    git mv -v\n\n\nwithout your patch:\n\n    $ git mv -n 1 2\n    Checking rename of '1' to '2'\n    Renaming 1 to 2\n    $ git mv -n -v 1 2\n    Checking rename of '1' to '2'\n    Renaming 1 to 2\n    $ git mv -v 1 2\n    Renaming 1 to 2\n\n\nand with your patch:\n\n    $ git mv -n 1 2\n    Checking rename of '1' to '2'\n    $ git mv -n -v 1 2\n    Checking rename of '1' to '2'\n    Renaming 1 to 2\n    $ git mv -v 1 2\n\n\nHaving different outputs of “git mv -n” and “git mv -n -v” seems\nodd, but not necessarily wrong. However, “git mv -v” with no\noutput at all, does not what the documentation says:\n\n       -v, --verbose\n           Report the names of files as they are moved.\n\n\n"},{"id":"342243","messageId":"xmqq370vvnmo.fsf@gitster-ct.c.googlers.com","threadId":"47430","inReplyTo":"20180318210908.3ed94777.stefanmoch@mail.de","subject":"Re: feature-request: git \"cp\" like there is git mv.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-03-19T20:03:43Z","receivedAt":"2018-03-19T20:03:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Moch <stefanmoch@mail.de> writes:\n\n> Are such redundant checks in general a pattern worth searching\n> for and cleaning up globally? Or is this rather in the category\n> of cleaning up only when noticed?\n\nA clean-up patch that is otherwise a no-op is still welcome as it\nwill improve the health of the codebase, but they become hindrances\nif there are too many of them to consume the review bandwidth that\nwould otherwise be better spent on other non no-op topics, and/or if\nthey add too many merge conflicts with other non no-op topics in\nflight.\n\nThe amount of such negative impact a no-op clean-up patch can have\non the project does not depend on how the issue was discovered, so\nwe do not even have to know if the issue was discovered by actively\nhunting or by noticing while working on a near-by area.\n\nIt is possible that by actively looking for, you may end up\nproducing more of the no-op clean-up patches and can more easily\ninterfere with other topics, which we may need to discourge or at\nleast ask you to slow down.  On the other hand, issues discovered\nwhile working on a near-by area would typically not increase\nconflicts with other topics in flight over the conflicts that would\nbe caused by that real work you were doing in a near-by area\nalready, so in that sense, \"only when noticed\" is a practical way to\navoid the clean-up fatigue.\n"}]}