What's in git.git and announcing v1.4.1-rc1

I've merged quite a bit of stuff and tagged the tip of "master" as GIT 1.4.1-rc1.

As promised, 1.4.X series will be managed slightly differently, and this is in preparation of the first installment of it. The releases will come from the "master" branch to contain both fixes and enhancements from now on. Hotfix releases when necessary would have 1.4.X.Y revision numbers, but I am hoping that we do not have to do that very often.

Since all the exciting and potentially risky developments are to happen on the "next" branch and they are supposed to graduate to "master" branch after they are reasonably well cooked, this change will help the end-users to stay reasonably current without hopefully not introducing unexpected problems. The older scheme left out all the enhancements if people followed packaged versions, and gave big surprises when upgrading from version X.Y.Z to X.(Y+1).0 which was not so nice.

Notable improvements since v1.4.0 are:

 - PPC SHA1 routine can grok more than half-gig of data (Paul
   Mackerras)

 - rev-list and object-layer in general is less (much less)
   space hungry (Linus).

 - the source is more friendly to stricter compilers such as
   Sun's (Florian Forster).

 - git rebase --merge (Eric Wong).  This uses the usual 3-way
   merge machinery while running rebase, and you can rebase
   across renames if you use the recursive strategy which is the
   default.

 - gitweb updates -- mostly cleanups (Jakub Narebski with help
   from Pasky and Timo Hirvonen).

 - diff --color (Johannes).

 - ~/.gitconfig and $ENV{GIT_CONFIG} (Pasky and Johannes).

 - core.sharedrepository can take umask, group or world (Linus
   and I)

 - "git checkout -f" removes files that becomes untracked from
   the working tree

 - "git clone/fetch" from a corrupt repository does not
   propagate brokenness to the downloaders.

 - "git clone/fetch" over the network gives better progress
   updates; this may also help TCP timeout problems for people
   behind NAT.

 - Many more commands are built-in (Lukas Sandström)

 - git can now be used on Kiritimati (Paul Eggert)

----------------------------------------------------------------

* The 'master' branch has these since the last announcement.

   Andre Noll:
      object-refs: avoid division by zero

   David Woodhouse:
      Log peer address when git-daemon called from inetd

   Dennis Stosberg:
      Make t8001-annotate and t8002-blame more portable
      Fix t8001-annotate and t8002-blame for ActiveState Perl

   Eric W. Biederman:
      Fix git-format-patch -s
      Check and document the options to prevent mistakes.

   Eric Wong:
      git-svn: fix --rmdir when using SVN:: libraries
      rebase: Allow merge strategies to be used when rebasing
      rebase: error out for NO_PYTHON if they use recursive merge
      git-svn: fix commit --edit flag when using SVN:: libraries

   Florian Forster:
      Remove ranges from switch statements.
      Initialize FAMs using `FLEX_ARRAY'.
      Don't instantiate structures with FAMs.
      Cast pointers to `void *' when used in a format.
      Don't use empty structure initializers.
      Change types used in bitfields to be `int's.
      Remove all void-pointer arithmetic.

   Jakub Narebski:
      Move gitweb style to gitweb.css
      gitweb: safely output binary files for 'blob_plain' action
      gitweb: text files for 'blob_plain' action without charset by default
      Fix gitweb stylesheet
      Make CSS file gitweb/gitweb.css more readable
      gitweb: add type="text/css" to stylesheet link
      Fix: Support for the standard mime.types map in gitweb
      gitweb: A couple of page title tweaking
      gitweb: style done with stylesheet
      gitweb: whitespace cleanup
      Add git version to gitweb output
      Move $gitbin earlier in gitweb.cgi
      gitweb: Make use of $PATH_INFO for project parameter
      gitweb: whitespace cleanup around '='

   Johannes Schindelin:
      diff options: add --color
      Initialize lock_file struct to all zero.
      Fix setting config variables with an alternative GIT_CONFIG
      Read configuration also from $HOME/.gitconfig
      repo-config: Fix late-night bug
      git_config: access() returns 0 on success, not > 0

   Junio C Hamano:
      read-tree: --prefix=<path>/ option.
      write-tree: --prefix=<path>
      read-tree: reorganize bind_merge code.
      fetch-pack: give up after getting too many "ack continue"
      shared repository: optionally allow reading to "others".
      fix rfc2047 formatter.
      xdiff: minor changes to match libxdiff-0.21
      Restore SIGCHLD to SIG_DFL where we care about waitpid().
      checkout -f: do not leave untracked working tree files.
      upload-pack: avoid sending an incomplete pack upon failure
      upload-pack: prepare for sideband message support.
      Retire git-clone-pack
      upload-pack/fetch-pack: support side-band communication
      Add renaming-rebase test.
      daemon: send stderr to /dev/null instead of closing.
      rebase --merge: fix for rebasing more than 7 commits.
      Makefile: do not force unneeded recompilation upon GIT_VERSION changes

   Linus Torvalds:
      Shrink "struct object" a bit
      Move "void *util" from "struct object" into "struct commit"
      Some more memory leak avoidance
      Remove "refs" field from "struct object"
      Add specialized object allocator
      Add "named object array" concept
      Fix grow_refs_hash()

   Lukas Sandström:
      Make git-write-tree a builtin
      Make git-mailsplit a builtin
      Make git-mailinfo a builtin
      Make git-stripspace a builtin
      Make git-update-index a builtin
      Make git-update-ref a builtin

   Paul Eggert:
      date.c: improve guess between timezone offset and year.

   Paul Mackerras:
      Fix PPC SHA1 routine for large input buffers

   Petr Baudis:
      Support for extracting configuration from different files
      Support for the standard mime.types map in gitweb

   Rene Scharfe:
      git-tar-tree: Simplify write_trailer()
      git-tar-tree: documentation update
      git-tar-tree: no more void pointer arithmetic
      Make release tarballs friendlier to older tar versions

   Timo Hirvonen:
      gitweb: Use $hash_base as $search_hash if possible

   Uwe Zeisberger:
      Fix possible out-of-bounds array access

   Yakov Lerner:
      auto-detect changed prefix and/or changed build flags
      Pass -DDEFAULT_GIT_TEMPLATE_DIR only where actually used.

* The 'pu' branch, in addition, has these.

   Johannes Schindelin:
      Teach diff about -b and -w flags

   Lukas Sandström:
      Make it possible to call cmd_apply multiple times
      Make git-am a builtin

Junio C Hamano <junkio@cox.net> writes:

I am hoping to coordinate the inclusion of this upstream first and have this hopefully in the real 1.4.1 release.

Last time I tried this, it did not work for me, so I am putting it on hold. I feel, however, "am" is a high-enough-level tool that we would prefer to keep it scriptable for quick tweaks.

If it is hurting portability because it is written in shell, maybe this can be moved to all Perl (especially when Pasky's Git.pm is ready) or Python. Personally I think Windows minded folks who cannot stand command-line interface Cygwin port gives would not be satisfied anyway, until somebody writes a native drag-this-mail-and-drop-on-that-brach tool, so porting the command out of shell may not be even worth doing. I dunno.

On 6/22/06, Junio C Hamano <junkio@cox.net> wrote:

Pulled and installed.

When I fire up gitk I see the following error messages, even if gitk
seems to be working fine:
paolo@Italia:~/git$ gitk
invalid command name ".ctop.cdet.left.ctext"
    while executing
"$ctext conf -state normal"
    (procedure "dispneartags" line 7)
    invoked from within
"dispneartags"
    (procedure "restartatags" line 28)
    invoked from within
"restartatags 869"
    ("after" script)

On Thu, 22 Jun 2006, Junio C Hamano wrote:

I like colorized diffs, but let's face it, those particular color choices will make most people decide to pick out their eyes with a fondue fork.

And that's not good. Digging in your eye-sockets with a fondue fork is strictly considered to be bad for your health, and seven out of nine optometrists are dead set against the practice.

So in order to avoid a lot of blind git users, please apply this patch.

This patch does:

 - always reset the color _before_ printing out the newline.

   This is actually important. You (and Johannes) didn't see it, because 
   it only matters if you set the background, but if you don't do this, 
   you get some random and funky behaviour if you pick a color with a 
   non-default background (which still potentially has problems with tabs 
   etc, but less so).

 - allow people to have a different color for the "file headers" 
   (DIFF_METAINFO) and for the "fragment header" (DIFF_FRAGINFO). Also, 
   make a difference between "normal color" and "reset colors"

 - default to red/green for old/new lines. That's the norm, I'd think.

 - instead of that eye-popping (and eye-ball-with-a-fondue-fork-popping) 
   purple color for metadata, use bold-face for file headers, and cyan for 
   the frag headers. I actually prefer the "gray background" for that, but 
   it only works well in xterms, so COLOR_CYAN it is..

Hmm?

		Linus
---
 diff.c |   99 +++++++++++++++++++++++++++++++++++++---------------------------
 1 files changed, 58 insertions(+), 41 deletions(-)

Dear diary, on Thu, Jun 22, 2006 at 10:53:31PM CEST, I got a letter where Linus Torvalds <torvalds@osdl.org> said that...

Great, since this also seems to make git diff more or less consistent with cg diff in the colors choice.

Isn't manually numbering the enum choices somewhat pointless, though? (Actually makes it more difficult to do changes in it later.)

On Thu, 22 Jun 2006, Petr Baudis wrote:

Yeah, I just mindlessly followed Johannes' original scheme. 

		Linus

Linus Torvalds wrote:

You might want to start at 0, just in case...

C99 (6.7.2.2) guarantees the enumeration constants start at 0 if not specified otherwise.

Hi,

On Thu, 22 Jun 2006, Linus Torvalds wrote:

... which wasn't his, to begin with ...

Linus Torvalds <torvalds@osdl.org> writes:

Well, I admit I do not use colorized diffs myself. As a matter of fact, I use specialized terminfo to disable coloring on my terminal session, since fontifying in GNUS otherwise gives me unreadable screen and I am too lazy to figure out how to turn it off.

I do however usually test colored stuff with at least white and black backgrounds,

Sorry, although I did notice this (interrupting a long diff, or running it with "less -r" and quitting it would leave the terminal in funny color), I did not bother to fix it.

OK.

Replacing it with COLOR_GRAYBG did not work out too well with either xterm nor kterm for me, although it did work under gnome-terminal.

Cyan foreground color is unreadable on white background and that was why I did magenta in my original patch, but it may be just that I am color challenged in that spectrum.

Junio C Hamano <junkio@cox.net> writes:

By the way, in the ancient history, in commit 3443546 you did:

Hi,

On Thu, 22 Jun 2006, Linus Torvalds wrote:

... and which happens to be useless for 10% of the male population (and even more if you look specifically at Asian people). But then, I just pasted that part from somewhere else.

Besides, I rarely have a fondue fork handy when I sit in front of the computer. I actually do not own one. And when I am sitting in front of the computer, shops typically are closed (yeah, I am living in Germany, but we _do_ have cars...). So at least for 100% of the writers of this email, your warning just does not apply.

Ciao, Dscho

Johannes Schindelin wrote:

:)

So 10% of the male population need to learn traffic light positions rather than colours?

I'm red/green colour blind which means I can't distinguish _subtley_ different shades of red and green.

vim is another fondue fork offender as it merges syntax highlighting and diff colours in diff mode (vimdiff). I put the following in ~/.vimrc to disable that madness:

if &diff
    "I'm only interested in diff colours
    syntax off
endif

Pádraig.

Hi,

On Fri, 23 Jun 2006, Pádraig Brady wrote:

A friend of mine was at the military and had to check new recruits for color-blindness. Only after the 20th color-blind man in a row he realized for the first time in hist life that it was _him_, being the color-blind.

Ciao, Dscho

On Fri, 23 Jun 2006, Johannes Schindelin wrote:

Sure. 

(Although I think it's 7% in general, and more in certain populations, some Western European countries included)

Which just means that we should have some way to let people set their own colors.

The _default_ should be the one people expect, though.

		Linus

This lets you use something like this in your $GIT_DIR/config file.

	[diff]
		color = auto

	[diff.color]
		new = blue
		old = yellow
		frag = reverse

When diff.color is set to "auto", colored diff is enabled when the standard output is the terminal. Other choices are "always", and "never". Usual boolean true/false can also be used.

The colormap entries can specify colors for the following slots:

	plain	- lines that appear in both old and new file (context)
	meta	- diff --git header and extended git diff headers
	frag	- @@ -n,m +l,k @@ lines (hunk header)
	old	- lines deleted from old file
	new	- lines added to new file

The following color names can be used:

	normal, bold, dim, l, blink, reverse, reset,
	black, red, green, yellow, blue, magenta, cyan,
	white

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

 Linus Torvalds <torvalds@osdl.org> writes:

 > Which just means that we should have some way to let people set their own 
 > colors.

 At the source level it is easy to specify color and attribute
 combinations (e.g. "bold|red") by having the preprocessor
 concatenate string literals, but I was too lazy to allow that
 from the configuration level.  People might want to have that,
 though.

 BTW, while doing this, I noticed that the patch does not do the
 color output for combined diffs.  Care to look into it after
 Timo's output format series settles?

 cache.h |    1 -
 diff.c  |   94 ++++++++++++++++++++++++++++++++++++++++++++++++++++++---------
 2 files changed, 80 insertions(+), 15 deletions(-)

Hi,

On Sat, 24 Jun 2006, Junio C Hamano wrote:

You mean just copying the relevant parts from your patch, which I missed, and do minimal testing? Sure ;-)

But first, by way of thanks to Martin, I have to reintroduce into format-patch the check for patches which are already upstream.

Ciao, Dscho

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 Linus Torvalds <torvalds@osdl.org> writes:

 >  - always reset the color _before_ printing out the newline.
 >
 >    This is actually important. You (and Johannes) didn't see it, because 
 >    it only matters if you set the background, but if you don't do this, 
 >    you get some random and funky behaviour if you pick a color with a 
 >    non-default background (which still potentially has problems with tabs 
 >    etc, but less so).

 Doh.

 I think you did not see it until you tried "git diff" with
 a stat-dirty but otherwise unmodified file.

 diff.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)