git, branch v1.5.0-rc4

GIT v1.5.0-rc4

2007-02-07T22:31:46Z

Signed-off-by: Junio C Hamano

Documentation: Add gfi to the main command list.

2007-02-07T22:30:47Z

Signed-off-by: Junio C Hamano

Fix "git log -z" behaviour

2007-02-07T19:58:07Z

For commit messages, we should really put the "line_termination" when we output the character in between different commits, *not* between the commit and the diff. The diff goes hand-in-hand with the commit, it shouldn't be separated from it with the termination character. So this: - uses the termination character for true inter-commit spacing - uses a regular newline between the commit log and the diff We had it the other way around. For the normal case where the termination character is '\n', this obviously doesn't change anything at all, since we just switched two identical characters around. So it's very safe - it doesn't change any normal usage, but it definitely fixes "git log -z". By fixing "git log -z", you can now also do insane things like git log -p -z | grep -z "some patch expression" | tr '\0' '\n' | less -S and you will see only those commits that have the "some patch expression" in their commit message _or_ their patches. (This is slightly different from 'git log -S"some patch expression"', since the latter requires the expression to literally *change* in the patch, while the "git log -p -z | grep .." approach will see it if it's just an unchanged _part_ of the patch context) Of course, if you actually do something like the above, you're probably insane, but hey, it works! Try the above command line for a demonstration (of course, you need to change the "some patch expression" to be something relevant). The old behaviour of "git log -p -z" was useless (and got things completely wrong for log entries without patches). Signed-off-by: Linus Torvalds Signed-off-by: Junio C Hamano

git-add -i: update removed path correctly.

2007-02-07T18:56:38Z

Earlier, when a path that was removed from the working tree was chosen for update subcommand, you got an error like this: error: git-resolve.sh: does not exist and --remove not passed fatal: Unable to process file git-resolve.sh Signed-off-by: Junio C Hamano

t4200: skip gc-rerere test on systems with non GNU date.

2007-02-07T18:43:56Z

Quite nonstandard "date -d @11111111 +%s" does not even fail on OpenBSD but gives the current date in "seconds since epoch" format, which is useless for the purpose of this test. We want to make sure that this returns exactly the same input before proceeding. Signed-off-by: Junio C Hamano

Merge branch 'ml/gitk' (early part)

2007-02-07T17:47:49Z

* 'ml/gitk' (early part): gitk: Use show-ref instead of ls-remote Make gitk work reasonably well on Cygwin. gitk - remove trailing whitespace from a few lines.

fast-import: Fix compile warnings

2007-02-07T17:28:23Z

Not on all platforms are size_t and unsigned long equivalent. Since I do not know how portable %z is, I play safe, and just cast the respective variables to unsigned long. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

for-each-reflog: fix case for empty log directory

2007-02-07T17:18:57Z

When we remove the last reflog in a directory, opendir() would succeed and we would iterate over its dirents, expecting retval to be initialized to zero and setting it to non-zero only upon seeing an error. If the directory is empty, oops!, we do not have anybody that touches retval. The problem is because we initialize retval to errno even on success from opendir(), which would leave the errno unmolested. Signed-off-by: Junio C Hamano

Merge branch 'master' of git://repo.or.cz/git/fastimport

2007-02-07T16:39:16Z

* 'master' of git://repo.or.cz/git/fastimport: Add a Tips and Tricks section to fast-import's manual. Don't crash fast-import if the marks cannot be exported. Dump all refs and marks during a checkpoint in fast-import. Teach fast-import how to sit quietly in the corner. Teach fast-import how to clear the internal branch content. Minor timestamp related documentation corrections for fast-import.

git-clone --reference: work well with pack-ref'ed reference repository

2007-02-07T10:10:56Z

Earlier we only used loose refs to anchor already existing objects. When cloning from a repository that forked relatively long time ago from the reference repository, this made the want/have exchange by fetch-pack to do unnecessary work. Signed-off-by: Junio C Hamano