author | Shawn O. Pearce <spearce@spearce.org> | |
Thu, 18 Jan 2007 20:17:58 +0000 (15:17 -0500) | ||
committer | Shawn O. Pearce <spearce@spearce.org> | |
Thu, 18 Jan 2007 20:17:58 +0000 (15:17 -0500) | ||
commit | b715cfbba4083d25ec0d0f94e440ad734607ddb0 | |
tree | 470777f640cddcc55c0ada635f182ce213871e98 | tree | snapshot |
parent | 8232dc427fb4b92b38e74e9e93b52231a67e354f | commit | diff |
Accept 'inline' file data in fast-import commit structure.
Its very annoying to need to specify the file content ahead of a
commit and use marks to connect the individual blobs to the commit's
file modification entry, especially if the frontend can't/won't
generate the blob SHA1s itself. Instead it would much easier to
use if we can accept the blob data at the same time as we receive
each file_change line.
Now fast-import accepts 'inline' instead of a mark idnum or blob
SHA1 within the 'M' type file_change command. If an inline is
detected the very next line must be a 'data n' command, supplying
the file data.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Its very annoying to need to specify the file content ahead of a
commit and use marks to connect the individual blobs to the commit's
file modification entry, especially if the frontend can't/won't
generate the blob SHA1s itself. Instead it would much easier to
use if we can accept the blob data at the same time as we receive
each file_change line.
Now fast-import accepts 'inline' instead of a mark idnum or blob
SHA1 within the 'M' type file_change command. If an inline is
detected the very next line must be a 'data n' command, supplying
the file data.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
fast-import.c | diff | blob | history | |
t/t9300-fast-import.sh | diff | blob | history |