diff options
author | Shawn O. Pearce <spearce@spearce.org> | 2007-07-15 01:40:37 -0400 |
---|---|---|
committer | Shawn O. Pearce <spearce@spearce.org> | 2007-07-15 01:41:23 -0400 |
commit | b6f3481bb456acbbb990a1045344bb06e5a40283 (patch) | |
tree | 75457994dbd8f190b5f5887b816481e936a7e7d8 /Documentation | |
parent | 48b4c3d5ab1610c6dc0198fe94334d78e8a82e16 (diff) | |
download | git-b6f3481bb456acbbb990a1045344bb06e5a40283.tar.gz git-b6f3481bb456acbbb990a1045344bb06e5a40283.tar.xz |
Teach fast-import to recursively copy files/directories
Some source material (e.g. Subversion dump files) perform directory
renames by telling us the directory was copied, then deleted in the
same revision. This makes it difficult for a frontend to convert
such data formats to a fast-import stream, as all the frontend has
on hand is "Copy a/ to b/; Delete a/" with no details about what
files are in a/, unless the frontend also kept track of all files.
The new 'C' subcommand within a commit allows the frontend to make a
recursive copy of one path to another path within the branch, without
needing to keep track of the individual file paths. The metadata
copy is performed in memory efficiently, but is implemented as a
copy-immediately operation, rather than copy-on-write.
With this new 'C' subcommand frontends could obviously implement an
'R' (rename) on their own as a combination of 'C' and 'D' (delete),
but since we have already offered up 'R' in the past and it is a
trivial thing to keep implemented I'm not going to deprecate it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/git-fast-import.txt | 40 |
1 files changed, 35 insertions, 5 deletions
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index bf1ba67ad..30ee98d17 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -302,7 +302,7 @@ change to the project. data ('from' SP <committish> LF)? ('merge' SP <committish> LF)? - (filemodify | filedelete | filerename | filedeleteall)* + (filemodify | filedelete | filecopy | filerename | filedeleteall)* LF .... @@ -325,13 +325,13 @@ commit message use a 0 length data. Commit messages are free-form and are not interpreted by Git. Currently they must be encoded in UTF-8, as fast-import does not permit other encodings to be specified. -Zero or more `filemodify`, `filedelete`, `filerename` and -`filedeleteall` commands +Zero or more `filemodify`, `filedelete`, `filecopy`, `filerename` +and `filedeleteall` commands may be included to update the contents of the branch prior to creating the commit. These commands may be supplied in any order. However it is recommended that a `filedeleteall` command preceed -all `filemodify` and `filerename` commands in the same commit, as -`filedeleteall` +all `filemodify`, `filecopy` and `filerename` commands in the same +commit, as `filedeleteall` wipes the branch clean (see below). `author` @@ -497,6 +497,27 @@ here `<path>` is the complete path of the file or subdirectory to be removed from the branch. See `filemodify` above for a detailed description of `<path>`. +`filecopy` +^^^^^^^^^^^^ +Recursively copies an existing file or subdirectory to a different +location within the branch. The existing file or directory must +exist. If the destination exists it will be completely replaced +by the content copied from the source. + +.... + 'C' SP <path> SP <path> LF +.... + +here the first `<path>` is the source location and the second +`<path>` is the destination. See `filemodify` above for a detailed +description of what `<path>` may look like. To use a source path +that contains SP the path must be quoted. + +A `filecopy` command takes effect immediately. Once the source +location has been copied to the destination any future commands +applied to the source location will not impact the destination of +the copy. + `filerename` ^^^^^^^^^^^^ Renames an existing file or subdirectory to a different location @@ -517,6 +538,15 @@ location has been renamed to the destination any future commands applied to the source location will create new files there and not impact the destination of the rename. +Note that a `filerename` is the same as a `filecopy` followed by a +`filedelete` of the source location. There is a slight performance +advantage to using `filerename`, but the advantage is so small +that it is never worth trying to convert a delete/add pair in +source material into a rename for fast-import. This `filerename` +command is provided just to simplify frontends that already have +rename information and don't want bother with decomposing it into a +`filecopy` followed by a `filedelete`. + `filedeleteall` ^^^^^^^^^^^^^^^ Included in a `commit` command to remove all files (and also all |