Skip to content

G
git

李少辉-开发者 / git
与 Fork 源项目一致

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 26 2月, 2011 13 次提交
    • J
      vcs-svn: teach line_buffer about temporary files · b1c9b798
      由 Jonathan Nieder 提交于 
      It can sometimes be useful to write information temporarily to file,
to read back later.  These functions allow a program to use the
line_buffer facilities when doing so.

It works like this:

 1. find a unique filename with buffer_tmpfile_init.
 2. rewind with buffer_tmpfile_rewind.  This returns a stdio
    handle for writing.
 3. when finished writing, declare so with
    buffer_tmpfile_prepare_to_read.  The return value indicates
    how many bytes were written.
 4. read whatever portion of the file is needed.
 5. if finished, remove the temporary file with buffer_deinit.
    otherwise, go back to step 2,

The svn support would use this to buffer the postimage from delta
application until the length is known and fast-import can receive
the resulting blob.
Based-on-patch-by: NDavid Barr <david.barr@cordelta.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
      b1c9b798
    • J
      vcs-svn: allow input from file descriptor · cb3f87cf
      由 Jonathan Nieder 提交于 
      Based-on-patch-by: NDavid Barr <david.barr@cordelta.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
      cb3f87cf
    • J
      vcs-svn: allow character-oriented input · cc193f1f
      由 Jonathan Nieder 提交于 
      buffer_read_char can be used in place of buffer_read_string(1) to
avoid consuming valuable static buffer space.  The delta applier will
use this to read variable-length integers one byte at a time.

Underneath, it is fgetc, wrapped so the line_buffer library can
maintain its role as gatekeeper of input.

Later it might be worth checking if fgetc_unlocked is faster ---
most line_buffer functions are not thread-safe anyway.
Helpd-by: NDavid Barr <david.barr@cordelta.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
      cc193f1f
    • J
      vcs-svn: add binary-safe read function · e832f43c
      由 Jonathan Nieder 提交于 
      buffer_read_string works well for non line-oriented input except for
one problem: it does not tell the caller how many bytes were actually
written.  This means that unless one is very careful about checking
for errors (and eof) the calling program cannot tell the difference
between the string "foo" followed by an early end of file and the
string "foo\0bar\0baz".

So introduce a variant that reports the length, too, a thinner wrapper
around strbuf_fread.  Its result is written to a strbuf so the caller
does not need to keep track of the number of bytes read.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
      e832f43c
    • J
      t0081 (line-buffer): add buffering tests · d280f683
      由 Jonathan Nieder 提交于 
      POSIX makes the behavior of read(2) from a pipe fairly clear: a read
from an empty pipe will block until there is data available and any
other read will not block, prefering to return a partial result.
Likewise, fread(3) and fgets(3) are clearly specified to act as
though implemented by calling fgetc(3) in a simple loop.  But the
buffering behavior of fgetc is less clear.

Luckily, no sane platform is going to implement fgetc by calling the
equivalent of read(2) more than once.  fgetc has to be able to
return without filling its buffer to preserve errno when errors are
encountered anyway.  So let's assume the simpler behavior (trust) but
add some tests to catch insane platforms that violate that when they
come (verify).

First check that fread can handle a 0-length read from an empty fifo.
Because open(O_RDONLY) blocks until the writing end is open, open the
writing end of the fifo in advance in a subshell.

Next try short inputs from a pipe that is not filled all the way.

Lastly (two tests) try very large inputs from a pipe that will not fit
in the relevant buffers.  The first of these tests reads a little
more than 8192 bytes, which is BUFSIZ (the size of stdio's buffers)
on this Linux machine.  The second reads a little over 64 KiB (the
pipe capacity on Linux) and is not run unless requested by setting
the GIT_REMOTE_SVN_TEST_BIG_FILES environment variable.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
      d280f683
    • J
      vcs-svn: tweak test-line-buffer to not assume line-oriented input · 7b990c90
      由 Jonathan Nieder 提交于 
      Do not expect an implicit newline after each input record.
Use a separate command to exercise buffer_skip_bytes.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
      7b990c90
    • J
      tests: give vcs-svn/line_buffer its own test script · 232087fd
      由 Jonathan Nieder 提交于 
      Split the line_buffer test into small pieces and move it to its
own file as preparation for adding more tests.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
      232087fd
    • J
      vcs-svn: make test-line-buffer input format more flexible · 850c5ea4
      由 Jonathan Nieder 提交于 
      Imitate the input format of test-obj-pool to support arbitrary
sequences of commands rather than alternating read/copy.  This should
make it easier to add tests that exercise other line_buffer functions.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
      850c5ea4
    • J
      vcs-svn: teach line_buffer to handle multiple input files · e5e45ca1
      由 Jonathan Nieder 提交于 
      Collect the line_buffer state in a newly public line_buffer struct.
Callers can use multiple line_buffers to manage input from multiple
files at a time.

svn-fe's delta applier will use this to stream a delta from svnrdump
and the preimage it applies to from fast-import at the same time.

The tests don't take advantage of the new features, but I think that's
okay.  It is easier to find lingering examples of nonreentrant code by
searching for "static" in line_buffer.c.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
      e5e45ca1
    • J
      vcs-svn: collect line_buffer data in a struct · d350822f
      由 Jonathan Nieder 提交于 
      Prepare for the line_buffer lib to support input from multiple files,
by collecting global state in a struct that can be easily passed
around.

No API change yet.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
      d350822f
    • J
      vcs-svn: replace buffer_read_string memory pool with a strbuf · deadcef4
      由 Jonathan Nieder 提交于 
      obj_pool is inherently global and does not use the standard growing
factor alloc_nr, which makes it feel out of place in the git codebase.
Plus it is overkill for this application: all that is needed is a
buffer that can grow between requests to accomodate larger strings.
Use a strbuf instead.

As a side effect, this improves the error handling: allocation
failures will result in a clean exit instead of segfaults.  It would
be nice to add a test case (using ulimit or failmalloc) but that can
wait for another day.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
      deadcef4
    • J
      vcs-svn: eliminate global byte_buffer · 4d21bec0
      由 Jonathan Nieder 提交于 
      The data stored in byte_buffer[] is always either discarded or
written to stdout immediately.  No need for it to persist between
function calls.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
      4d21bec0
    • D
      fast-import: add 'ls' command · 8dc6a373
      由 David Barr 提交于 
      Lazy fast-import frontend authors that want to rely on the backend to
keep track of the content of the imported trees _almost_ have what
they need in the 'cat-blob' command (v1.7.4-rc0~30^2~3, 2010-11-28).
But it is not quite enough, since

 (1) cat-blob can be used to retrieve the content of files, but
     not their mode, and

 (2) using cat-blob requires the frontend to keep track of a name
     (mark number or object id) for each blob to be retrieved

Introduce an 'ls' command to complement cat-blob and take care of the
remaining needs.  The 'ls' command finds what is at a given path
within a given tree-ish (tag, commit, or tree):

	'ls' SP <dataref> SP <path> LF

or in fast-import's active commit:

	'ls' SP <path> LF

The response is a single line sent through the cat-blob channel,
imitating ls-tree output.  So for example:

	FE> ls :1 Documentation
	gfi> 040000 tree 9e6c2b599341d28a2a375f8207507e0a2a627fe9	Documentation
	FE> ls 9e6c2b599341d28a2a375f8207507e0a2a627fe9 git-fast-import.txt
	gfi> 100644 blob 4f92954396e3f0f97e75b6838a5635b583708870	git-fast-import.txt
	FE> ls :1 RelNotes
	gfi> 120000 blob b942e499449d97aeb50c73ca2bdc1c6e6d528743	RelNotes
	FE> cat-blob b942e499449d97aeb50c73ca2bdc1c6e6d528743
	gfi> b942e499449d97aeb50c73ca2bdc1c6e6d528743 blob 32
	gfi> Documentation/RelNotes/1.7.4.txt

The most interesting parts of the reply are the first word, which is
a 6-digit octal mode (regular file, executable, symlink, directory,
or submodule), and the part from the second space to the tab, which is
a <dataref> that can be used in later cat-blob, ls, and filemodify (M)
commands to refer to the content (blob, tree, or commit) at that path.

If there is nothing there, the response is "missing some/path".

The intent is for this command to be used to read files from the
active commit, so a frontend can apply patches to them, and to copy
files and directories from previous revisions.

For example, proposed updates to svn-fe use this command in place of
its internal representation of the repository directory structure.
This simplifies the frontend a great deal and means support for
resuming an import in a separate fast-import run (i.e., incremental
import) is basically free.
Signed-off-by: NDavid Barr <david.barr@cordelta.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Improved-by: NJunio C Hamano <gitster@pobox.com>
Improved-by: NSverre Rabbelier <srabbelier@gmail.com>
      8dc6a373
  3. 23 2月, 2011 2 次提交
  5. 22 2月, 2011 7 次提交
  7. 17 2月, 2011 6 次提交
  9. 16 2月, 2011 10 次提交
  11. 15 2月, 2011 2 次提交
    • R
      configure: use AC_LANG_PROGRAM consistently · 1e58dba1
      由 Ralf Wildenhues 提交于 
      Avoid warnings from Autoconf 2.68 about missing use of AC_LANG_PROGRAM
and friends.

Quoting autoconf-2.68/NEWS:

  ** The macros AC_PREPROC_IFELSE, AC_COMPILE_IFELSE, AC_LINK_IFELSE, and
     AC_RUN_IFELSE now warn if the first argument failed to use
     AC_LANG_SOURCE or AC_LANG_PROGRAM to generate the conftest file
     contents.  A new macro AC_LANG_DEFINES_PROVIDED exists if you have
     a compelling reason why you cannot use AC_LANG_SOURCE but must
     avoid the warning.

The underlying reason for that change is that AC_LANG_{SOURCE,PROGRAM}
take care to supply the previously computed set of #defines (and
include standard headers if so desired) for preprocessed languages
like C and C++.

In some cases, AC_LANG_PROGRAM is already used but not sufficiently
m4-quoted, so we just need to add another set of [quotes] to prevent
the autoconf warning from being triggered bogusly.  Quoting all
arguments (except when calling special macros that need to be expanded
before recursion) is better style, anyway.  These and more rules are
described in detail in 'info Autoconf "Programming in M4"'.

No change in the resulting config.mak.autogen after running
./configure intended.
Signed-off-by: NRalf Wildenhues <Ralf.Wildenhues@gmx.de>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      1e58dba1
    • J
      string_list_append: always set util pointer to NULL · 62b8102c
      由 Jeff King 提交于 
      It is not immediately obvious that the util field may
contain random bytes after appending an item. Especially
since the string_list_insert* functions _do_ explicitly zero
the util pointer.

This does not appear to be a bug in any current git code, as
all callers either fill in the util field immediately or
never use it. However, it is worth it to be less surprising
to new users of the string-list API who may expect it to be
intialized to NULL.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      62b8102c