Signed-off-by: Alex Riesen <raa.lkml@gmail.com> --- An old test-parse-options was breaking t0040. Makefile | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index cd6d469..af827f6 100644 --- a/Makefile +++ b/Makefile @@ -999,6 +999,8 @@ test-date$X: date.o ctype.o test-delta$X: diff-delta.o patch-delta.o +test-parse-options$X: parse-options.o + .PRECIOUS: $(patsubst test-%$X,test-%.o,$(TEST_PROGRAMS)) test-%$X: test-%.o $(GITL...

[Cc: Todd A. Jacobs <nospam@codegnome.org>, git@vger.kernel.org] Take a look at gitattributes(5), namely 'filter' attribute. Although instead of implementing it "by hand", perhaps it would be enough to use 'ident' and/or 'export-subs' attribute. P.S. Because of the way git updates files, and git thinks about files it is I think universally regarded to be bad idea to put in a file any Id that depend on commit data. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

hi, i setup git to use with eclipse through global excludesfile config. git-status report just ignore files, but git-clean deleted ignore files. ---- $ git-config -l core.excludesfile=/home/pal/.gitignore $ cat /home/pal/.gitignore # ignore for eclipse .project .cproject $ git-status # On branch master nothing to commit (working directory clean) $ git-clean Removing .project -

There is no reason to forbid a dirty work tree when reverting or cherry-picking a change, as long as the index is clean. The scripted version used to allow it: case "$no_commit" in t) # We do not intend to commit immediately. We just want to # merge the differences in. head=$(git-write-tree) || die "Your index file is unmerged." ;; *) head=$(git-rev-parse --verify HEAD) || die "You do not have a valid HEAD" files=$(git-diff-index --cach...

The test wants to see if there are still remaining tasks, but checked a wrong file. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- t/t3404-rebase-interactive.sh | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh index 1113904..f1039d1 100755 --- a/t/t3404-rebase-interactive.sh +++ b/t/t3404-rebase-interactive.sh @@ -149,7 +149,7 @@ test_expect_success 'stop on conflicting pick' ' diff -u expect...

Ok, I've made a bugzilla entry for this for the Fedora people, but I thought I'd mention something I noticed yesterday but only tracked down today: it seems like the beagle file indexing code is able to screw up git in subtle ways. I do not know exactly what happens, but the symptoms are random (and quite hard-to-trigger) dirty index contents where git believes that some set of files are not clean in the index. I *suspect* that beagle is playing games with the file access times, causing ...

Last I ran across this, I believe I found it was adding extended attributes to the file. I think it's something like getfattr -d to show all the extended attributes set on the file. Does that show anything? Yeah, I just turned off beagle. It looked to me like it was doing something wrongheaded. -

Things like Beagle need a guaranteed log of global inotify events. That would let them efficiently find changes made since the last time they updated their index. Right now every time Beagle starts it hasn't got a clue what has changed in the file system since it was last run. This forces Beagle to rescan the entire filesystem every time it is started. The xattrs are used as cache to reduce this load somewhat. A better solution would be for the kernel to log inotify events to disk in a manner ...

You still need to look at every file in the file system. People can have many millions of files in their file systems (I have two million in mine and that's small). The inotify log is the most efficient solution. I've turned Beagle off simply because it beats on my disk for an hour -- Jon Smirl jonsmirl@gmail.com -

By the way, on Debian or Ubuntu, at least, that requires an "apt-get Just looking at the attribute names and taking a wild guess, it looked to me like beagle was computing a checksum of each file's data and comparing it to a checksum previously stored in an xattr, and using that to decide whether to reindex the file data. With the result that to check whether anything's changed when it starts up again it has to read through the entire filesystem's data. Maybe I'm wrong--I hope so. I'd love t...

In a subsequent patch the path to the system-wide config file will be computed. This is a preparation for that change. It turns all accesses of ETC_GITCONFIG into function calls. There is no change in behavior. As a consequence, config.c is the only file that needs the definition of ETC_GITCONFIG. Hence, -DETC_GITCONFIG is removed from the CFLAGS and a special build rule for config.c is introduced. As a side-effect, changing the defintion of ETC_GITCONFIG (e.g. in config.mak) does not trigger a com...

I don't think so. environment.c is about things that concern the repository. This is really only about configuration. -- Hannes -

If ETC_GITCONFIG is not an absolute path, interpret it relative to --exec-dir. This makes the installed binaries relocatable because the prefix is not compiled-in. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> --- config.c | 13 ++++++++++++- 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/config.c b/config.c index dd7e9ad..9f014bb 100644 --- a/config.c +++ b/config.c @@ -6,6 +6,7 @@ * */ #include "cache.h" +#include "exec_cmd.h" #define MAXNAME...

From: Johannes Schindelin <Johannes.Schindelin@gmx.de> This is needed on Windows since open files cannot be unlinked. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> --- This was authored by Dscho, but carries only my sign-off. Is this ok? cache.h | 1 + lockfile.c | 17 ++++++++++------- 2 files changed, 11 insertions(+), 7 deletions(-) diff --git a/cache.h b/cache.h index f0a25c7..28870c5 100644 --- a/cache.h +++ b/cache.h @@ -284,6 +284,7 @@ extern in...

In order to make git relocatable (i.e. not have the prefix compiled-in) the template directory must depend on the location where this git instance is found, which is GIT_EXEC_DIR. The exec path is prepended only if the compiled-in default template directory is to be used and that is relative. Any relative directories that are specified via environment variable or the --exec-dir switch are taken as is. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> --- builtin-init-db.c | 16 ++...

... and so allow that the compiled binaries are installed in any directory that the user chooses. -- Hannes -

Sorry, I don't understand your statement. Do you see any tests breaking? These changes are only about where git-init looks up the templates and where the system configuration is looked for. They change git's behavior only if config.mak contains relative paths like this: sysconfdir = ../etc template_dir = ../share/git-core It has nothing to do with where the test suite looks for the executables. -- Hannes -

Yes. Another thing I said was that it would be grave regression for testability if the change leads git to look at somewhere else other than it was told to look via GIT_EXEC_PATH environment, -

This makes it easier to spot which of the tests failed. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> --- t/t5300-pack-object.sh | 34 ++++++++++++++++++---------------- 1 files changed, 18 insertions(+), 16 deletions(-) diff --git a/t/t5300-pack-object.sh b/t/t5300-pack-object.sh index ba7579c..f1106e6 100755 --- a/t/t5300-pack-object.sh +++ b/t/t5300-pack-object.sh @@ -187,49 +187,51 @@ test_expect_success \ test-3-${packname_3}.idx' test_expect_success \ - 'c...

There are platforms where off_t is not 64 bits wide. In this case many tests are doomed to fail. Let's skip them. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> --- t/t5302-pack-index.sh | 25 +++++++++++++++++++++++-- 1 files changed, 23 insertions(+), 2 deletions(-) diff --git a/t/t5302-pack-index.sh b/t/t5302-pack-index.sh index 4f58c4c..d93abc4 100755 --- a/t/t5302-pack-index.sh +++ b/t/t5302-pack-index.sh @@ -61,17 +61,33 @@ test_expect_success \ test_expect_success...

There are some places that test for an absolute path. Use the helper function to ease porting. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> --- sha1_file.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/sha1_file.c b/sha1_file.c index f007874..560c0e0 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -86,7 +86,7 @@ int safe_create_leading_directories(char *path) char *pos = path; struct stat st; - if (*pos == '/') + if (is_absolute_path(...

True, but this series is not yet about the MinGW port itself. It will be changed eventually, but not at this time. -- Hannes -

... since all system headers are pulled in via git-compat-util.h Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> --- git-compat-util.h | 2 ++ help.c | 1 - pager.c | 2 -- 3 files changed, 2 insertions(+), 3 deletions(-) diff --git a/git-compat-util.h b/git-compat-util.h index 7b29d1b..6a8b592 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -52,6 +52,8 @@ #include <fnmatch.h> #include <sys/poll.h> #include <sys/socke...

Signed-off-by: Sergei Organov <osv@javad.com> --- Documentation/user-manual.txt | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index d99adc6..a169ef0 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -475,7 +475,7 @@ Bisecting: 3537 revisions left to test after this If you run "git branch" at this point, you'll see that git has temporarily moved you to a new br...

Hello, I've been working on adding Git support in Scmbug, a system that integrates software configuration management with bug-tracking. I've run across what seem to be limitations in the Git hooks mechanism (at least in version 1.5.1.3). In particular: (1) http://bugzilla.mkgnu.net/show_bug.cgi?id=3D991 There's no hook that will trigger when a tag is applied. (2) http://bugzilla.mkgnu.net/show_bug.cgi?id=3D992 Git does not offer metadata describing a change on the commit trigger ...