git/environment.c, branch v1.6.4

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

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

New config push.default to decide default behavior for push

2009-03-17T21:50:21Z

When "git push" is not told what refspecs to push, it pushes all matching branches to the current remote. For some workflows this default is not useful, and surprises new users. Some have even found that this default behaviour is too easy to trigger by accident with unwanted consequences. Introduce a new configuration variable "push.default" that decides what action git push should take if no refspecs are given or implied by the command line arguments or the current remote configuration. Possible values are: 'nothing' : Push nothing; 'matching' : Current default behaviour, push all branches that already exist in the current remote; 'tracking' : Push the current branch to whatever it is tracking; 'current' : Push the current branch to a branch of the same name, i.e. HEAD. Signed-off-by: Finn Arne Gangstad Signed-off-by: Junio C Hamano

Revert "Merge branch 'js/notes'"

2009-02-11T05:32:10Z

This reverts commit 7b75b331f6744fbf953fe8913703378ef86a2189, reversing changes made to 5d680a67d7909c89af96eba4a2d77abed606292b.

Introduce commit notes

2008-12-21T10:47:21Z

Commit notes are blobs which are shown together with the commit message. These blobs are taken from the notes ref, which you can configure by the config variable core.notesRef, which in turn can be overridden by the environment variable GIT_NOTES_REF. The notes ref is a branch which contains "files" whose names are the names of the corresponding commits (i.e. the SHA-1). The rationale for putting this information into a ref is this: we want to be able to fetch and possibly union-merge the notes, maybe even look at the date when a note was introduced, and we want to store them efficiently together with the other objects. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Add cache preload facility

2008-11-15T03:11:49Z

This can do the lstat() storm in parallel, giving potentially much improved performance for cold-cache cases or things like NFS that have weak metadata caching. Just use "read_cache_preload()" instead of "read_cache()" to force an optimistic preload of the index stat data. The function takes a pathspec as its argument, allowing us to preload only the relevant portion of the index. Signed-off-by: Linus Torvalds Signed-off-by: Junio C Hamano

Merge branch 'maint'

2008-11-11T22:49:50Z

* maint: Fix non-literal format in printf-style calls git-submodule: Avoid printing a spurious message. git ls-remote: make usage string match manpage Makefile: help people who run 'make check' by mistake