Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 24 11月, 2006 6 次提交
    • J
      refs outside refs/{heads,tags} match less strongly. · 29561ad0
      由 Junio C Hamano 提交于 
      This changes the refname matching logic used to decide which ref
is updated with git-send-pack.  We used to error out when
pushing 'master' when the other end has both 'master' branch and
a tracking branch 'remotes/$name/master' but with this, 'master'
matches only 'refs/heads/master' when both and no other 'master'
exist.

Pushing 'foo' when both heads/foo and tags/foo exist at the
remote end is still considered an error and you would need to
disambiguate between them by being more explicit.

When neither heads/foo nor tags/foo exists at the remote,
pushing 'foo' when there is only remotes/origin/foo is not
ambiguous, while it still is ambiguous when there are more than
one such weaker match (remotes/origin/foo and remotes/alt/foo,
for example).
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      29561ad0
    • A
      Increase length of function name buffer · f73da29f
      由 Andy Parkins 提交于 
      In xemit.c:xdl_emit_diff() a buffer for showing the function name as
commentary is allocated; this buffer was 40 characters.  This is a bit
small; particularly for C++ function names where there is often an
identical prefix (like void LongNamespace::LongClassName) on multiple
functions, which makes the context the same everywhere.  In other words
the context is useless.  This patch increases that buffer to 80
characters - which may still not be enough, but is better
Signed-off-by: NAndy Parkins <andyparkins@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      f73da29f
    • E
      git-svn: preserve uncommitted changes after dcommit · 4769489a
      由 Eric Wong 提交于 
      Using dcommit could cause the user to lose uncommitted changes
during the reset --hard operation, so change it to reset --mixed.

If dcommit chooses the rebase path, then git-rebase will already
error out when local changes are made.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      4769489a
    • E
      git-svn: correctly handle revision 0 in SVN repositories · e70dc780
      由 Eric Wong 提交于 
      some SVN repositories have a revision 0 (committed by no author
and no date) when created; so when we need to ensure that we
check any revision variables are defined, and not just
non-zero.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      e70dc780
    • E
      git-svn: error out from dcommit on a parent-less commit · 48d044b5
      由 Eric Wong 提交于 
      dcommit would unconditionally append "~1" to a commit in order
to generate a diff.  Now we generate a meaningful error message
if we try to generate an impossible diff.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      48d044b5
    • R
      archive-zip: don't use sizeof(struct ...) · 0ea865ce
      由 René Scharfe 提交于 
      We can't rely on sizeof(struct zip_*) returning the sum of
all struct members.  At least on ARM padding is added at the
end, as Gerrit Pape reported.  This fixes the problem but
still lets the compiler do the summing by introducing
explicit padding at the end of the structs and then taking
its offset as the combined size of the preceding members.

As Junio correctly notes, the _end[] marker array's size
must be greater than zero for compatibility with compilers
other than gcc.  The space wasted by the markers can safely
be neglected because we only have one instance of each
struct, i.e. in sum 3 wasted bytes on i386, and 0 on ARM. :)

We still rely on the compiler to not add padding between the
struct members, but that's reasonable given that all of them
are unsigned char arrays.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      0ea865ce
  3. 23 11月, 2006 3 次提交
  5. 22 11月, 2006 3 次提交
  7. 20 11月, 2006 2 次提交
  9. 19 11月, 2006 8 次提交
  11. 17 11月, 2006 2 次提交
    • L
      "git fmt-merge-msg" SIGSEGV · 6b1f8c32
      由 Linus Torvalds 提交于 
      Ok, this is a _really_ stupid case, and I don't think it matters, but hey,
we should never SIGSEGV.

Steps to reproduce:

	mkdir duh
	cd duh
	git init-db
	git-fmt-merge-msg < /dev/null

will cause a SIGSEGV in cmd_fmt_merge_msg(), because we're doing a
strncmp() with a NULL current_branch.

And yeah, it's an insane schenario, and no, it doesn't really matter. The
only reason I noticed was that a broken version of my "git pull" into an
empty directory would cause this.

This silly patch just replaces the SIGSEGV with a controlled exit with an
error message.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      6b1f8c32
    • L
      git-pull: allow pulling into an empty repository · d09e79cb
      由 Linus Torvalds 提交于 
      We used to complain that we cannot merge anything we fetched
with a local branch that does not exist yet.  Just treat the
case as a natural extension of fast forwarding and make the
local branch'es tip point at the same commit we just fetched.
After all an empty repository without an initial commit is an
ancestor of any commit.

[jc: I added a trivial test.  We've become sloppy but we should
 stick to the discipline of covering new behaviour with new
 tests. ]
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      d09e79cb
  13. 16 11月, 2006 6 次提交
  15. 15 11月, 2006 1 次提交
  17. 14 11月, 2006 4 次提交
  19. 13 11月, 2006 1 次提交
  21. 12 11月, 2006 4 次提交