user/sven/git.git/cache.h, branch v1.6.4.5

check_path(): allow symlinked directories to checkout-index --prefix

2009-08-18T10:32:45Z

Merlyn noticed that Documentation/install-doc-quick.sh no longer correctly removes old installed documents when the target directory has a leading path that is a symlink. It turns out that "checkout-index --prefix" was broken by recent b6986d8 (git-checkout: be careful about untracked symlinks, 2009-07-29). I suspect has_symlink_leading_path() could learn the third parameter (prefix that is allowed to be symlinked directories) to allow us to retire a similar function has_dirs_only_path(). Another avenue of fixing this I considered was to get rid of base_dir and base_dir_len from "struct checkout", and instead make "git checkout-index" when run with --prefix mkdir the leading path and chdir in there. It might be the best longer term solution to this issue, as the base_dir feature is used only by that rather obscure codepath as far as I know. But at least this patch should fix this breakage. Signed-off-by: Junio C Hamano

git-checkout: be careful about untracked symlinks

2009-07-30T03:24:28Z

This fixes the case where an untracked symlink that points at a directory with tracked paths confuses the checkout logic, demostrated in t6035. Signed-off-by: Junio C Hamano

Merge branch 'js/maint-graft-unhide-true-parents'

2009-07-25T07:45:03Z

* js/maint-graft-unhide-true-parents: git repack: keep commits hidden by a graft Add a test showing that 'git repack' throws away grafted-away parents Conflicts: git-repack.sh

git repack: keep commits hidden by a graft

2009-07-24T16:10:16Z

When you have grafts that pretend that a given commit has different parents than the ones recorded in the commit object, it is dangerous to let 'git repack' remove those hidden parents, as you can easily remove the graft and end up with a broken repository. So let's play it safe and keep those parent objects and everything that is reachable by them, in addition to the grafted parents. As this behavior can only be triggered by git pack-objects, and as that command handles duplicate parents gracefully, we do not bother to cull duplicated parents that may result by using both true and grafted parents. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

push: do not give big warning when no preference is configured

2009-07-19T00:20:52Z

If the message said "we will be changing the default in the future, so this is to warn people who want to keep the current default what to do", it would have made some sense, but as it stands, the message is merely an unsolicited advertisement for a new feature, which it is not helpful at all. Squelch it. Signed-off-by: Junio C Hamano

Export thread-safe version of 'has_symlink_leading_path()'

2009-07-10T03:05:19Z

The threaded index preloading will want it, so that it can avoid locking by simply using a per-thread symlink/directory cache. Signed-off-by: Linus Torvalds Signed-off-by: Junio C Hamano

diff: generate pretty filenames in prep_temp_blob()

2009-06-01T00:57:59Z

Naturally, prep_temp_blob() did not care about filenames. As a result, GIT_EXTERNAL_DIFF and textconv generated filenames such as ".diff_XXXXXX". This modifies prep_temp_blob() to generate user-friendly filenames when creating temporary files. Diffing "name.ext" now generates "XXXXXX_name.ext". Signed-off-by: David Aguilar Signed-off-by: Junio C Hamano

Fix a bunch of pointer declarations (codestyle)

2009-05-01T22:17:31Z

Essentially; s/type* /type */ as per the coding guidelines. Signed-off-by: Felipe Contreras Signed-off-by: Junio C Hamano

Rename core.unreliableHardlinks to core.createObject

2009-04-29T23:50:07Z

"Unreliable hardlinks" is a misleading description for what is happening. So rename it to something less misleading. Suggested by Linus Torvalds. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Add an option not to use link(src, dest) && unlink(src) when that is unreliable

2009-04-25T16:49:21Z

It seems that accessing NTFS partitions with ufsd (at least on my EeePC) has an unnerving bug: if you link() a file and unlink() it right away, the target of the link() will have the correct size, but consist of NULs. It seems as if the calls are simply not serialized correctly, as single-stepping through the function move_temp_to_file() works flawlessly. As ufsd is "Commertial software" (sic!), I cannot fix it, and have to work around it in Git. At the same time, it seems that this fixes msysGit issues 222 and 229 to assume that Windows cannot handle link() && unlink(). Signed-off-by: Johannes Schindelin Acked-by: Johannes Sixt Signed-off-by: Junio C Hamano