Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 23 8月, 2007 10 次提交
  3. 21 8月, 2007 4 次提交
  5. 20 8月, 2007 12 次提交
  7. 19 8月, 2007 10 次提交
    • S
      Include recent command history in fast-import crash reports · 904b1941
      由 Shawn O. Pearce 提交于 
      When we crash the frontend developer (or end-user) may need to know
roughly around what part of the input stream we had a problem with
and aborted on.  Because line numbers aren't very useful in this
sort of application we instead just keep the last 100 commands in
a FIFO queue and print them as part of the crash report.

Currently one problem with this design is a commit that has
more than 100 modified files in it will flood the FIFO and any
context regarding branch/from/committer/mark/comments will be lost.
We really should save only the last few (10?) file changes for the
current commit, ensuring we have some prior higher level commands
in the FIFO when we crash on a file M/D/C/R command.

Another issue with this approach is the FIFO only includes the
commands, it does not include the commit messages.  Yet having a
commit message may be useful to help locate the relevant change in
the source material.  In practice I don't think this is going to be a
major concern as the frontend can always embed its own source change
set identifier as a comment (which will appear in the crash report)
and the commit message(s) for the most recent commits of any given
branch should be obtainable from the (packed) commit objects.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      904b1941
    • S
      Generate crash reports on die in fast-import · 8acb3297
      由 Shawn O. Pearce 提交于 
      As fast-import is quite strict about its input and die()'s anytime
something goes wrong it can be difficult for a frontend developer
to troubleshoot why fast-import rejected their input, or to even
determine what input command it rejected.

This change introduces a custom handler for Git's die() routine.
When we receive a die() for any reason (fast-import or a lower level
core Git routine we called) the error is first dumped onto stderr
and then a more extensive crash report file is prepared in GIT_DIR.
Finally we exit the process with status 128, just like the stock
builtin die handler.

An internal flag is set to prevent any further die()'s that may be
invoked during the crash report generator from causing us to enter
into an infinite loop.  We shouldn't die() from our crash report
handler, but just in case someone makes a future code change we are
prepared to gaurd against small mistakes turning into huge problems
for the end-user.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      8acb3297
    • S
      Allow frontends to bidirectionally communicate with fast-import · ac053c02
      由 Shawn O. Pearce 提交于 
      The existing checkpoint command is very useful to force fast-import
to dump the branches out to disk so that standard Git tools can
access them and the objects they refer to.  However there was not a
way to know when fast-import had finished executing the checkpoint
and it was safe to read those refs.

The progress command can be used to make fast-import output any
message of the frontend's choosing to standard out.  The frontend
can scan for these messages using select() or poll() to monitor a
pipe connected to the standard output of fast-import.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      ac053c02
    • S
      Make trailing LF optional for all fast-import commands · 1fdb649c
      由 Shawn O. Pearce 提交于 
      For the same reasons as the prior change we want to allow frontends
to omit the trailing LF that usually delimits commands.  In some
cases these just make the input stream more verbose looking than
it needs to be, and its just simpler for the frontend developer to
get started if our parser is slightly more lenient about where an
LF is required and where it isn't.

To make this optional LF feature work we now have to buffer up to one
line of input in command_buf.  This buffering can happen if we look
at the current input command but don't recognize it at this point
in the code.  In such a case we need to "unget" the entire line,
but we cannot depend upon the stdio library to let us do ungetc()
for that many characters at once.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      1fdb649c
    • S
      Make trailing LF following fast-import `data` commands optional · 2c570cde
      由 Shawn O. Pearce 提交于 
      A few fast-import frontend developers have found it odd that we
require the LF following a `data` command, especially in the exact
byte count format.  Technically we don't need this LF to parse
the stream properly, but having it here does make the stream more
readable to humans.  We can easily make the LF optional by peeking
at the next byte available from the stream and pushing it back into
the buffer if its not LF.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      2c570cde
    • S
      Teach fast-import to ignore lines starting with '#' · 401d53fa
      由 Shawn O. Pearce 提交于 
      Several frontend developers have asked that some form of stream
comments be permitted within a fast-import data stream.  This way
they can include information from their own frontend program about
where specific data was taken from in the source system, or about
a decision that their frontend may have made while creating the
fast-import data stream.

This change introduces comments in the Bourne-shell/Tcl/Perl style.
Lines starting with '#' are ignored, up to and including the LF.
Unlike the above mentioned three languages however we do not look for
and ignore leading whitespace.  This just simplifies the definition
of the comment format and the code that parses them.

To make comments work we had to stop using read_next_command() within
cmd_data() and directly invoke read_line() during the inline variant
of the function.  This is necessary to retain any lines of the
input data that might otherwise look like a comment to fast-import.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      401d53fa
    • S
      Use handy ALLOC_GROW macro in fast-import when possible · 31490074
      由 Shawn O. Pearce 提交于 
      Instead of growing our buffer by hand during the inline variant of
cmd_data() we can save a few lines of code and just use the nifty
new ALLOC_GROW macro already available to us.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      31490074
    • S
      Actually allow TAG_FIXUP branches in fast-import · ea08a6fd
      由 Shawn O. Pearce 提交于 
      Michael Haggerty <mhagger@alum.mit.edu> noticed while debugging a
Git backend for cvs2svn that fast-import was barfing when he tried
to use "TAG_FIXUP" as a branch name for temporary work needed to
cleanup the tree prior to creating an annotated tag object.

The reason we were rejecting the branch name was check_ref_format()
returns -2 when there are less than 2 '/' characters in the input
name.  TAG_FIXUP has 0 '/' characters, but is technically just as
valid of a ref as HEAD and MERGE_HEAD, so we really should permit it
(and any other similar looking name) during import.

New test cases have been added to make sure we still detect very
wrong branch names (e.g. containing [ or starting with .) and yet
still permit reasonable names (e.g. TAG_FIXUP).
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      ea08a6fd
    • A
      Fix whitespace in "Format of STDIN stream" of fast-import · c905e090
      由 Alex Riesen 提交于 
      Something probably assumed that HT indentation is 4 characters.
Signed-off-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      c905e090
    • M
      git-completion.bash - add support for git-bundle · 374a58c9
      由 Mark Levedahl 提交于 
      Signed-off-by: NMark Levedahl <mdl123@verizon.net>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      374a58c9
  9. 18 8月, 2007 3 次提交
  11. 17 8月, 2007 1 次提交