Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 26 3月, 2006 5 次提交
    • J
      true built-in diff: run everything in-core. · cebff98d
      由 Junio C Hamano 提交于 
      This stops using temporary files when we are using the built-in
diff (including the complete rewrite).
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      cebff98d
    • J
      built-in diff: minimum tweaks · 3ce8f089
      由 Junio C Hamano 提交于 
      This fixes up a couple of minor issues with the real built-in
diff to be more usable:

 - Omit ---/+++ header unless we emit diff output;

 - Detect and punt binary diff like GNU does;

 - Honor GIT_DIFF_OPTS minimally (only -u<number> and
   --unified=<number> are currently supported);

 - Omit line count of 1 from "@@ -l,k +m,n @@" hunk header
   (i.e. when k == 1 or n == 1)

 - Adjust testsuite for the lack of -p support.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      3ce8f089
    • L
      builtin-diff: \No newline at end of file. · 621c53cc
      由 Linus Torvalds 提交于 
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      621c53cc
    • L
      Use a *real* built-in diff generator · 3443546f
      由 Linus Torvalds 提交于 
      This uses a simplified libxdiff setup to generate unified diffs _without_
doing  fork/execve of GNU "diff".

This has several huge advantages, for example:

Before:

	[torvalds@g5 linux]$ time git diff v2.6.16.. > /dev/null

	real    0m24.818s
	user    0m13.332s
	sys     0m8.664s

After:

	[torvalds@g5 linux]$ time git diff v2.6.16.. > /dev/null

	real    0m4.563s
	user    0m2.944s
	sys     0m1.580s

and the fact that this should be a lot more portable (ie we can ignore all
the issues with doing fork/execve under Windows).

Perhaps even more importantly, this allows us to do diffs without actually
ever writing out the git file contents to a temporary file (and without
any of the shell quoting issues on filenames etc etc).

NOTE! THIS PATCH DOES NOT DO THAT OPTIMIZATION YET! I was lazy, and the
current "diff-core" code actually will always write the temp-files,
because it used to be something that you simply had to do. So this current
one actually writes a temp-file like before, and then reads it into memory
again just to do the diff. Stupid.

But if this basic infrastructure is accepted, we can start switching over
diff-core to not write temp-files, which should speed things up even
further, especially when doing big tree-to-tree diffs.

Now, in the interest of full disclosure, I should also point out a few
downsides:

 - the libxdiff algorithm is different, and I bet GNU diff has gotten a
   lot more testing. And the thing is, generating a diff is not an exact
   science - you can get two different diffs (and you will), and they can
   both be perfectly valid. So it's not possible to "validate" the
   libxdiff output by just comparing it against GNU diff.

 - GNU diff does some nice eye-candy, like trying to figure out what the
   last function was, and adding that information to the "@@ .." line.
   libxdiff doesn't do that.

 - The libxdiff thing has some known deficiencies. In particular, it gets
   the "\No newline at end of file" case wrong. So this is currently for
   the experimental branch only. I hope Davide will help fix it.

That said, I think the huge performance advantage, and the fact that it
integrates better is definitely worth it. But it should go into a
development branch at least due to the missing newline issue.

Technical note: this is based on libxdiff-0.17, but I did some surgery to
get rid of the extraneous fat - stuff that git doesn't need, and seriously
cutting down on mmfile_t, which had much more capabilities than the diff
algorithm either needed or used. In this version, "mmfile_t" is just a
trivial <pointer,length> tuple.

That said, I tried to keep the differences to simple removals, so that you
can do a diff between this and the libxdiff origin, and you'll basically
see just things getting deleted. Even the mmfile_t simplifications are
left in a state where the diffs should be readable.

Apologies to Davide, whom I'd love to get feedback on this all from (I
wrote my own "fill_mmfile()" for the new simpler mmfile_t format: the old
complex format had a helper function for that, but I did my surgery with
the goal in mind that eventually we _should_ just do

	mmfile_t mf;

	buf = read_sha1_file(sha1, type, &size);
	mf->ptr = buf;
	mf->size = size;
	.. use "mf" directly ..

which was really a nightmare with the old "helpful" mmfile_t, and really
is that easy with the new cut-down interfaces).

[ Btw, as any hawk-eye can see from the diff, this was actually generated
  with itself, so it is "self-hosting". That's about all the testing it
  has gotten, along with the above kernel diff, which eye-balls correctly,
  but shows the newline issue when you double-check it with "git-apply" ]
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      3443546f
    • L
      git-apply: safety fixes · c1504628
      由 Linus Torvalds 提交于 
      This was triggered by me testing the "@@" numbering shorthand by GNU
patch, which not only showed that git-apply thought it meant the number
was duplicated (when it means that the second number is 1), but my tests
showed than when git-apply mis-understood the number, it would then not
raise an alarm about it if the patch ended early.

Now, this doesn't actually _matter_, since with a three-line context, the
only case that "x,1" will be shorthanded to "x" is when x itself is 1 (in
which case git-apply got it right), but the fact that git-apply would also
silently accept truncated patches was a missed opportunity for additional
sanity-checking.

So make git-apply refuse to look at a patch fragment that ends early.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      c1504628
  3. 25 3月, 2006 3 次提交
  5. 24 3月, 2006 4 次提交
  7. 23 3月, 2006 1 次提交
  9. 22 3月, 2006 5 次提交
  11. 21 3月, 2006 6 次提交
    • E
      contrib/git-svn: allow rebuild to work on non-linear remote heads · ac749050
      由 Eric Wong 提交于 
      Because committing back to an SVN repository from different
machines can result in different lineages, two different
repositories running git-svn can result in different commit
SHA1s (but of the same tree).  Sometimes trees that are tracked
independently are merged together (usually via children),
resulting in non-unique git-svn-id: lines in rev-list.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      ac749050
    • N
      http-push: don't assume char is signed · a3c57c9a
      由 Nick Hengeveld 提交于 
      Declare remote_dir_exists[] as signed char to be sure that values of -1
are valid.
Signed-off-by: NNick Hengeveld <nickh@reactrix.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      a3c57c9a
    • N
      http-push: add support for deleting remote branches · 3dfaf7bc
      由 Nick Hengeveld 提交于 
      Processes new command-line arguments -d and -D to remove a remote branch
if the following conditions are met:
- one branch name is present on the command line
- the specified branch name matches exactly one remote branch name
- the remote HEAD is a symref
- the specified branch is not the remote HEAD
- the remote HEAD resolves to an object that exists locally (-d only)
- the specified branch resolves to an object that exists locally (-d only)
- the specified branch is an ancestor of the remote HEAD (-d only)
Signed-off-by: NNick Hengeveld <nickh@reactrix.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      3dfaf7bc
    • Y
      Be verbose when !initial commit · 1fa7a68f
      由 Yasushi SHOJI 提交于 
      verbose option in git-commit.sh lead us to run git-diff-index, which
needs a commit-ish we are making diff against.  When we are commiting
the fist set, we obviously don't have any commit-ish in the repo.  So
we just skip the git-diff-index run.

It might be possible to produce diff against empty but do we need
that?
Signed-off-by: NYasushi SHOJI <yashi@atmark-techno.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      1fa7a68f
    • F
      Fix multi-paragraph list items in OPTIONS section · 3070b603
      由 Francis Daly 提交于 
      This patch makes the html docs right, makes the asciidoc docs a bit odd
but consistent with what is there already, and makes the manpages look
OK using docbook-xsl 1.68, but miss a paragraph separator when using 1.69.

For the manpages, current is like

       -A <author_file>
              Read a file with lines on the form

              username = User's Full Name <email@addr.es>

              and use "User's Full Name <email@addr.es>" as the GIT

With this patch, docbook-xsl v1.68 looks like

       -A <author_file>
              Read a file with lines on the form

                      username = User's Full Name <email@addr.es>

              and use "User's Full Name <email@addr.es>" as the GIT author and

while docbook-xsl v1.69 becomes

       -A <author_file>
              Read a file with lines on the form

                        username = User's Full Name <email@addr.es>
              and use "User's Full Name <email@addr.es>" as the GIT author and

The extra indentation is to keep the v1.69 manpage looking sane.
      3070b603
    • J
      http-fetch: nicer warning for a server with unreliable 404 status · bb528079
      由 Junio C Hamano 提交于 
      When a repository otherwise properly prepared is served by a
dumb HTTP server that sends "No such page" output with 200
status for human consumption to a request for a page that does
not exist, the users will get an alarming "File X corrupt" error
message.  Hint that they might be dealing with such a server at
the end and suggest running fsck-objects to check if the result
is OK (the pack-fallback code does the right thing in this case
so unless a loose object file was actually corrupt the result
should check OK).
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      bb528079
  13. 20 3月, 2006 6 次提交
  15. 19 3月, 2006 2 次提交
  17. 18 3月, 2006 8 次提交