Skip to content

G
git

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

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

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

切换分支/标签
  1. 17 5月, 2013 4 次提交
    • K
      t6111: new TREESAME test set · abdea96e
      由 Kevin Bracey 提交于 
      Some side branching and odd merging to illustrate various flaws in
revision list scans, particularly when limiting the list.

Many expected failures, which will be gone by the end of the "history
traversal refinements" series.
Signed-off-by: NKevin Bracey <kevin@bracey.fi>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      abdea96e
    • K
      t6019: test file dropped in -s ours merge · c72424b1
      由 Kevin Bracey 提交于 
      In preparation for upcoming TREESAME work, check the result for G.t,
which is dropped in "-s ours" merge L. The default rev-list is empty, as
expected - it follows the first parent path where it never existed.

Unfortunately, --ancestry-path is also empty. Merges H J and L are all
TREESAME to 1 parent, so are treated as TREESAME and not shown. This is
clearly undesirable in the case of merge L, which dropped our G.t by
taking the non-ancestry-path version. Document this as a known failure,
and expect "H J L", the 3 merges along the path that had to chose G.t
versions.
Signed-off-by: NKevin Bracey <kevin@bracey.fi>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c72424b1
    • K
      decorate.c: compact table when growing · 83f0412f
      由 Kevin Bracey 提交于 
      When growing the table, take the opportunity to "compact" it by removing
entries with NULL decoration.

Users may have "removed" decorations by passing NULL to
insert_decoration. An object's table entry can't actually be removed
during normal operation, as it would break the linear hash collision
search. But we can remove NULL decoration entries when rebuilding the
table.
Signed-off-by: NKevin Bracey <kevin@bracey.fi>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      83f0412f
    • K
      revision.c: treat A...B merge bases as if manually specified · a765499a
      由 Kevin Bracey 提交于 
      The documentation assures users that "A...B" is defined as "A B --not
$(git merge-base --all A B)". This wasn't in fact quite true, because
the calculated merge bases were not sent to add_rev_cmdline().

The main effect of this was that although

  git rev-list --ancestry-path A B --not $(git merge-base --all A B)

worked, the simpler form

  git rev-list --ancestry-path A...B

failed with a "no bottom commits" error.

Other potential users of bottom commits could also be affected by this
problem, if they examine revs->cmdline_info; I came across the issue in
my proposed history traversal refinements series.

So ensure that the calculated merge bases are sent to add_rev_cmdline(),
flagged with new 'whence' enum value REV_CMD_MERGE_BASE.
Signed-off-by: NKevin Bracey <kevin@bracey.fi>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      a765499a
  3. 14 5月, 2013 1 次提交
  5. 12 5月, 2013 2 次提交
  7. 10 5月, 2013 9 次提交
    • J
      Sync with v1.8.2.3 · b387c77b
      由 Junio C Hamano 提交于 
      * maint:
  Git 1.8.2.3
  t5004: avoid using tar for checking emptiness of archive
  t5004: ignore pax global header file
  mergetools/kdiff3: do not use --auto when diffing
  transport-helper: trivial style cleanup
      b387c77b
    • J
      Git 1.8.2.3 · 92758dd2
      由 Junio C Hamano 提交于 
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      92758dd2
    • J
      Merge branch 'mv/sequencer-pick-error-diag' · faf8fde5
      由 Junio C Hamano 提交于 
      Fix "git cherry-pick $annotated_tag", which was mistakenly rejected.

* mv/sequencer-pick-error-diag:
  cherry-pick: picking a tag that resolves to a commit is OK
      faf8fde5
    • J
      cherry-pick: picking a tag that resolves to a commit is OK · 7c0b0d8d
      由 Junio C Hamano 提交于 
      Earlier, 21246dbb (cherry-pick: make sure all input objects are
commits, 2013-04-11) tried to catch an unlikely "git cherry-pick $blob"
as an error, but broke a more important use case to cherry-pick a
tag that points at a commit.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      7c0b0d8d
    • J
      Merge branch 'tr/copy-revisions-from-stdin' into maint · 07e03d46
      由 Junio C Hamano 提交于 
      * tr/copy-revisions-from-stdin:
  read_revisions_from_stdin: make copies for handle_revision_arg
      07e03d46
    • R
      t5004: avoid using tar for checking emptiness of archive · ea2d20d4
      由 René Scharfe 提交于 
      Test 2 of t5004 checks if a supposedly empty tar archive really
contains no files.  24676f02 (t5004: fix issue with empty archive test
and bsdtar) removed our commit hash to make it work with bsdtar, but
the test still fails on NetBSD and OpenBSD, which use their own tar
that considers a tar file containing only NULs as broken.

Here's what the different archivers do when asked to create a tar
file without entries:

	$ uname -v
	NetBSD 6.0.1 (GENERIC)
	$ gtar --version | head -1
	tar (GNU tar) 1.26
	$ bsdtar --version
	bsdtar 2.8.4 - libarchive 2.8.4

	$ : >zero.tar
	$ perl -e 'print "\0" x 10240' >tenk.tar
	$ sha1 zero.tar tenk.tar
	SHA1 (zero.tar) = da39a3ee5e6b4b0d3255bfef95601890afd80709
	SHA1 (tenk.tar) = 34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c

	$ : | tar cf - -T - | sha1
	da39a3ee5e6b4b0d3255bfef95601890afd80709
	$ : | gtar cf - -T - | sha1
	34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c
	$ : | bsdtar cf - -T - | sha1
	34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c

So NetBSD's native tar creates an empty file, while GNU tar and bsdtar
both give us 10KB of NULs -- just like git archive with an empty tree.
Now let's see how the archivers handle these two kinds of empty tar
files:

	$ tar tf zero.tar; echo $?
	tar: Unexpected EOF on archive file
	1
	$ gtar tf zero.tar; echo $?
	gtar: This does not look like a tar archive
	gtar: Exiting with failure status due to previous errors
	2
	$ bsdtar tf zero.tar; echo $?
	0

	$ tar tf tenk.tar; echo $?
	tar: Cannot identify format. Searching...
	tar: End of archive volume 1 reached
	tar: Sorry, unable to determine archive format.
	1
	$ gtar tf tenk.tar; echo $?
	0
	$ bsdtar tf tenk.tar; echo $?
	0

NetBSD's tar complains about both, bsdtar happily accepts any of them
and GNU tar doesn't like zero-length archive files.  So the safest
course of action is to stay with our block-of-NULs format which is
compatible with GNU tar and bsdtar, as we can't make NetBSD's native
tar happy anyway.

We can simplify our test, however, by taking tar out of the picture.
Instead of extracting the archive and checking for the non-presence of
files, check if the file has a size of 10KB and contains only NULs.
This makes t5004 pass on NetBSD and OpenBSD.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      ea2d20d4
    • R
      t5004: ignore pax global header file · abdb9b2e
      由 René Scharfe 提交于 
      Versions of tar that don't know pax headers -- like the ones in NetBSD 6
and OpenBSD 5.2 -- extract them as regular files.  Explicitly ignore the
file created for our global header when checking the list of extracted
files, as this is normal and harmless fall-back behaviour.  This fixes
test 3 of t5004 on these platforms.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      abdb9b2e
    • D
      mergetools/kdiff3: do not use --auto when diffing · e2161bc3
      由 David Aguilar 提交于 
      The `kdiff3 --auto` help message is, "No GUI if all conflicts are auto-
solvable."  This flag was carried over from the original mergetool
commands.  diff_cmd() is for two-way comparisons only so remove the
superfluous flag.
Signed-off-by: NDavid Aguilar <davvid@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      e2161bc3
    • F
      transport-helper: trivial style cleanup · b120ef3e
      由 Felipe Contreras 提交于 
      Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      b120ef3e
  9. 09 5月, 2013 3 次提交
  11. 08 5月, 2013 6 次提交
  13. 07 5月, 2013 5 次提交
  15. 06 5月, 2013 2 次提交
  17. 04 5月, 2013 6 次提交
  19. 03 5月, 2013 1 次提交
  21. 02 5月, 2013 1 次提交