user/sven/git.git/git-compat-util.h, branch v1.7.7.4

Merge branch 'cb/maint-exec-error-report'

2011-08-18T00:25:55Z

* cb/maint-exec-error-report: notice error exit from pager error_routine: use parent's stderr if exec fails

error_routine: use parent's stderr if exec fails

2011-08-01T01:27:07Z

The new process's error output may be redirected elsewhere, but if the exec fails, output should still go to the parent's stderr. This has already been done for the die_routine. Do the same for error_routine. Signed-off-by: Clemens Buchacher Signed-off-by: Junio C Hamano

Merge branch 'ak/gcc46-profile-feedback'

2011-07-19T16:32:52Z

* ak/gcc46-profile-feedback: Add explanation of the profile feedback build to the README Add profile feedback build to git Add option to disable NORETURN

Merge branch 'ef/maint-win-verify-path'

2011-06-30T00:09:17Z

* ef/maint-win-verify-path: verify_dotfile(): do not assume '/' is the path seperator verify_path(): simplify check at the directory boundary verify_path: consider dos drive prefix real_path: do not assume '/' is the path seperator A Windows path starting with a backslash is absolute

Add option to disable NORETURN

2011-06-20T19:32:39Z

Due to a bug in gcc 4.6+ it can crash when doing profile feedback with a noreturn function pointer (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49299) This adds a Makefile variable to disable noreturns. [Patch by Junio, description by Andi Kleen] Signed-off-by: Andi Kleen Signed-off-by: Junio C Hamano

real_path: do not assume '/' is the path seperator

2011-05-27T17:59:16Z

real_path currently assumes it's input had '/' as path seperator. This assumption does not hold true for the code-path from prefix_path (on Windows), where real_path can be called before normalize_path_copy. Fix real_path so it doesn't make this assumption. Create a helper function to reverse-search for the last path-seperator in a string. Signed-off-by: Theo Niessink Signed-off-by: Erik Faye-Lund Signed-off-by: Junio C Hamano

Merge branch 'jc/magic-pathspec'

2011-05-23T16:58:35Z

* jc/magic-pathspec: setup.c: Fix some "symbol not declared" sparse warnings t3703: Skip tests using directory name ":" on Windows revision.c: leave a note for "a lone :" enhancement t3703, t4208: add test cases for magic pathspec rev/path disambiguation: further restrict "misspelled index entry" diag fix overslow :/no-such-string-ever-existed diagnostics fix overstrict : diagnosis grep: use get_pathspec() correctly pathspec: drop "lone : means no pathspec" from get_pathspec() Revert "magic pathspec: add ":(icase)path" to match case insensitively" magic pathspec: add ":(icase)path" to match case insensitively magic pathspec: futureproof shorthand form magic pathspec: add tentative ":/path/from/top/level" pathspec support

magic pathspec: futureproof shorthand form

2011-04-08T23:19:48Z

The earlier design was to take whatever non-alnum that the short format parser happens to support, leaving the rest as part of the pattern, so a version of git that knows '*' magic and a version that does not would have behaved differently when given ":*Makefile". The former would have applied the '*' magic to the pattern "Makefile", while the latter would used no magic to the pattern "*Makefile". Instead, just reserve all non-alnum ASCII letters that are neither glob nor regexp special as potential magic signature, and when we see a magic that is not supported, die with an error message, just like the longhand codepath does. With this, ":%#!*Makefile" will always mean "%#!" magic applied to the pattern "*Makefile", no matter what version of git is used (it is a different matter if the version of git supports all of these three magic matching rules). Also make ':' without anything else to mean "there is no pathspec". This would allow differences between "git log" and "git log ." run from the top level of the working tree (the latter simplifies no-op commits away from the history) to be expressed from a subdirectory by saying "git log :". Helped-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

Merge branch 'maint'

2011-04-03T20:53:11Z

* maint: Start preparing for 1.7.4.4 pull: do not clobber untracked files on initial pull compat: add missing #include Conflicts: RelNotes

compat: add missing #include

2011-04-03T19:21:34Z

Starting with commit c793430 (Limit file descriptors used by packs, 2011-02-28), git uses getrlimit to tell how many file descriptors it can use. Unfortunately it does not include the header declaring that function, resulting in compilation errors: sha1_file.c: In function 'open_packed_git_1': sha1_file.c:718: error: storage size of 'lim' isn't known sha1_file.c:721: warning: implicit declaration of function 'getrlimit' sha1_file.c:721: error: 'RLIMIT_NOFILE' undeclared (first use in this function) sha1_file.c:718: warning: unused variable 'lim' The standard header to include for this is (which on some systems itself requires declarations from or ). Probably the problem was missed until now because in current glibc sys/resource.h happens to be included by sys/wait.h. MinGW does not provide sys/resource.h (and compat/mingw takes care of providing getrlimit some other way), so add the missing #include to the "#ifndef __MINGW32__" block in git-compat-util.h. Reported-by: Stefan Sperling Tested-by: Stefan Sperling [on OpenBSD] Tested-by: Arnaud Lacombe [on FreeBSD 8] Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano