What's in git.git

It's been a while since I've done v1.4.0, and I haven't fully caught up with the list traffic yet, but here is the current status.

I'm planning to manage the v1.4.X series a bit differently during this round. So far, they were supposed to be fix-only on top of v1.4.0, but people who follow the maintenance series (including the binary packages) missed out on too many good stuff that happen on the "master" branch. Also presses like lwn.net tended to cover the maint series which gets stale pretty quickly.

So I'll first merge only post-1.4.0 fixes and additions to the "master" branch until we are comfortable with its shape, tag it as 1.4.1, and continue. Essentially, "next" and "pu" will become the playpens (the first being "not proven but fixable" changes, the latter being "under consideration, but will not be missed if dropped" changes) their names originally implied, and "master" will be what "maint" was supposed to be -- fixes and good changes. The old fixes-only maintenance on "maint" branch will be halted for now -- except maybe when some urgent fixes are needed, I might do 1.4.X.Y like the kernel folks do.

* The 'master' branch has these since v1.4.0

   Dennis Stosberg:
      Make t4101-apply-nonl bring along its patches

   Eric W. Biederman:
      Don't parse any headers in the real body of an email message.

   Eric Wong:
      git-svn: t0000: add -f flag to checkout
      git-svn: fix handling of filenames with embedded '@'
      git-svn: eol_cp corner-case fixes
      git-svn: restore original LC_ALL setting (or unset) for commit
      git-svn: don't allow commit if svn tree is not current
      git-svn: support -C<num> passing to git-diff-tree
      git-svn: --branch-all-refs / -B support
      git-svn: optimize --branch and --branch-all-ref
      git-svn: support manually placed initial trees from fetch
      git-svn: Move all git-svn-related paths into $GIT_DIR/svn
      git-svn: minor cleanups, extra error-checking
      git-svn: add --repack and --repack-flags= options
      git-svn: add --shared and --template= options to pass to init-db
      git-svn: add some functionality to better support branches in svn
      git-svn: add UTF-8 message test
      git-svn: add 'log' command, a facsimile of basic `svn log'
      git-svn: add support for Perl SVN::* libraries
      git-svn: make the $GIT_DIR/svn/*/revs directory obsolete
      git-svn: avoid creating some small files
      git-svn: fix several small bugs, enable branch optimization
      git-svn: Eliminate temp file usage in libsvn_get_file()
      git-svn: bugfix and optimize the 'log' command
      git-svn: tests no longer fail if LC_ALL is not a UTF-8 locale
      git-svn: svn (command-line) 1.0.x compatibility
      git-svn: rebuild convenience and bugfixes

   Florian Forster:
      gitweb: Adding a `blame' interface.
      gitweb: Make the `blame' interface in gitweb optional.

   Fredrik Kuivinen:
      blame: Add --time to produce raw timestamps

   Jakub Narebski:
      Update gitweb README: gitweb is now included with git

   Junio C Hamano:
      gitk: rereadrefs needs listrefs
      fix git alias
      t5100: mailinfo and mailsplit tests.
      mailinfo: ignore blanks after in-body headers.

   Linus Torvalds:
      gitweb.cgi history not shown

   Martin Langhoff:
      cvsimport: ignore CVSPS_NO_BRANCH and impossible branches
      cvsimport: complete the cvsps run before starting the import
      cvsimport: keep one index per branch during import

   Peter Eriksen:
      Implement safe_strncpy() as strlcpy() and use it more.

   Sean Estabrooks:
      Add a "--notags" option for git-p4import.

   Sven Verdoolaege:
      git-cvsexportcommit.perl: fix typo

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

   Johannes Schindelin:
      diff options: add --color

   I would say this would be fine as is -- diff being quite
   important part of the system, I just wanted to cook it for a
   while.

   Junio C Hamano:
      read-tree: --prefix=<path>/ option.
      write-tree: --prefix=<path>
      read-tree: reorganize bind_merge code.

   I'll have them graduate to "master" soon, as they do not seem
   to hurt anybody.

      fetch-pack: give up after getting too many "ack continue"

   Maybe merge to "master" and see what it breaks.

      shared repository: optionally allow reading to "others".

   This should be ready.  I just want to do another round of
   check.

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

   This is more for the entertainment value than for practical
   value ;-).

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

   Johannes Schindelin:
      Read configuration also from ~/.gitconfig
      repo-config: learn the flag "--no-local"

   I see Pasky has proposed another config change (this time,
   not "also from" but "alternatively from") -- I am not sure
   which one is more appropriate.  Waiting for Johannes's
   response to Pasky's message and hoping the list can agree on
   a single patch series to apply to "next".

      Teach diff about -b and -w flags

   Yakov Lerner:
      auto-detect changed prefix and/or changed build flags

   I think this is fine, except that test-prefix-change target
   is probably unneeded as Martin noticed.

Hi,

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

There is one thing I don't like about Pasky's approach: You can change the config file name to whatever you like, even if no program will read it. That is why I decided to have a flag instead of an option: to prevent pilot-errors.

But hey, that is just me.

I cobbled together a patch, which turned out to be rather messy, introducing "--config-file <file>" to git-repo-config. If people are interested, I'll clean it up and post it. But then, if you already know you want to use another config file, you are probably better of just exporting GIT_CONFIG_FILE and be done with it.

Note that this issue is orthogonal to the need for a user-specific config file. I still think that this one should go in.

Ciao, Dscho

Dear diary, on Sun, Jun 18, 2006 at 02:26:14PM CEST, I got a letter where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...

I'm lost here, admittelly not getting your argument. :-(

$GIT_CONFIG_FILE feels nicer since any other git tool can use it as well, it's not git-repo-config-specific. But the current intent indeed is to simply override the location for git-repo-config, thus for the current purposes if we will have --config-file instead of GIT_CONFIG_FILE, I will not weep; whatever does the job.

I agree as well.

Hi,

On Sun, 18 Jun 2006, Petr Baudis wrote:

Okay, the point I was driving at:

GIT_CONFIG_FILE=~/.gitrc git repo-config blabla.blibli bloblo

_will_ succeed, but to the user it will be non-obvious that the git commands do not pick up on it (because ~/.gitconfig is read instead of ~/.gitrc), whereas

git repo-config --user blabla.blibli bloblo

is pretty obvious, and _has_ the intended effect.

Yes, that is true. Forget about my --config-file patch, please.

Ciao, Dscho

Petr Baudis <pasky@suse.cz> writes:

OK, let's have it then.

Johannes, this makes your earlier ~/.gitconfig and --no-local patches no longer applicable, so I'd drop them from "pu" for now. But I suspect we do want to have per user configuration that is used as a fallback for per repo configuration, right?

I think we should mark what we have in "next" tonight, plus a few others, as v1.4.1 sometime this coming week and continue from there.

Hi,

On Mon, 19 Jun 2006, Junio C Hamano wrote:

I'll redo the patches, then.

Ciao, Dscho