| 1 |
Diamond <diamond@××××××.ru> wrote: |
| 2 |
> |
| 3 |
> There's no git cp command. |
| 4 |
> git mv is just git rm + git add. |
| 5 |
|
| 6 |
I think there is a misunderstanding about how git works. |
| 7 |
|
| 8 |
If you are used to e.g. svn (I suppose with CVS it is similar) |
| 9 |
then it makes an important difference whether you use |
| 10 |
"svn cp A B" or "/bin/cp A B", because svn is file-centric: |
| 11 |
The latter loses history and duplicates data in the repository, |
| 12 |
while the former de-duplicates. |
| 13 |
|
| 14 |
git, OTOH is "blob"-centric: It cares only about content of the |
| 15 |
file, not where this content comes from; the information that |
| 16 |
you copy A to B is not stored, and it does not need to be stored: |
| 17 |
De-duplication happens automatically. |
| 18 |
|
| 19 |
In other words, there is no way for git to "see" that B originally |
| 20 |
was a copy of A, and normally there is also no such need. |
| 21 |
If you think that this information is important enough to be |
| 22 |
stored in the history, you have to make a commit where B is |
| 23 |
completely identical to A before you make further |
| 24 |
modifications for B (identical files have the same checksum and |
| 25 |
thus are immediately identified). |
| 26 |
If you make no such commit, git can guess only by similarities |
| 27 |
of the content that B originally was as a copy of A; this, |
| 28 |
of course, needs slightly longer than omitting such comparisons. |
| 29 |
|
| 30 |
For this reason, there is absolutely no reason to use git for |
| 31 |
file operations like cp or mv (as long as you add/remove the |
| 32 |
corresponding files from the index before you commit, of course). |
Archives