What's in git.git

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

 - git.el updates (Alexandre Julliard)
 - git-svn updates (Eric Wong)
 - git-blame updates (Fredrik Kuivinen)
 - documentation updates (Francis Daly, Jon Loeliger)
 - Makefile: Add TAGS and tags targets (Fredrik Kuivinen)
 - http-push support for deleting remote branches (Nick Hengeveld)

 - assorted minor fixes and tweaks (Alexandre Julliard, Mark
   Hollomon, Shawn Pearce, Yasushi SHOJI, Nicolas Pitre, Randal
   L. Schwartz and me)

* The 'next' branch, in addition, has two important fixes and
  enhancements, and it probably is a good time to do a 1.3
  release when they graduate to "master" and prove stable.

 - quicker and dirtier rename detection by Linus and me.

   I've been using this myself and haven't seen major
   misdetection so far, but I do not use much renames.  Maybe
   it's time to push this out and see what happens.  This is
   _not_ the "important" part.

 - cvsimport post-import checkout fix.

   Earlier we had a workaround to deal with people who import
   into the current branch by not checking out.  After
   incrementally importing from the same CVS repository again,
   however, the code did update the branch head.  This made the
   working tree and the index stale and was causing more
   confusion than it avoided.

   This fix is to make re-importing act more like git-pull, not
   git-fetch.  So if you run an incremental import into the
   current branch, it tries to fast-forward the working tree and
   index (your current branch head, index and working tree had
   better be pristine with respect to the CVS repository for
   this, but that is already an requirement for a tracking
   branch anyway) when your current branch is the tracking
   branch, or merge the imported result into your current branch
   if you are using a separate tracking branch.

   I've done some testing on this myself, but am waiting for
   independent confirmations from cvsimport users.  Merlyn?

 - refs/remotes support.

   This has been the recent hot topic, on git-clone.

   First, not so controversial one.  A new option --reference
   can be used to help cloning a project similar to what you
   already have over thin wire:

	$ git clone --reference /git/linux-2.6.git \
          git://git.kernel.org/pub/.../jgarzik/libata-dev.git/ \
          libata-dev

   What happens here is that the new repository (libata-dev you
   are creating by cloning from Jeff) is set up to borrow from
   vanilla Linus repository you already keep track of, and the
   initial clone downloads and expands objects that are only
   present in Jeff's tree.

   Another new option, --use-separate-remote, changes the way
   $GIT_DIR/remotes/origin file and your tracking branches are
   set up after the initial cloning.  Without it, all the remote
   heads are copied to your $GIT_DIR/refs/heads/ and a copy of
   the remote HEAD is made as $GIT_DIR/refs/heads/origin, and
   remotes/origin file is set up to keep this structure up to
   date.  This is the traditional behaviour.

   When --use-separate-remote is in effect, the tracking
   branches are created in $GIT_DIR/refs/remotes/origin/ and you
   will not get the extra "origin" head.  Your local branch
   namespace under $GIT_DIR/refs/heads/ will only have "master".
   In addition, a symref $GIT_DIR/refs/remotes/origin/HEAD
   points at the primary branch of the remote repository.
   Similar to a filename in $GIT_DIR/refs/{heads,tags} that can
   be used to name a ref (e.g. when you say "git diff frotz",
   you are telling git to read from $GIT_DIR/refs/heads/frotz
   and use that commit ID to diff your working tree against), a
   directory that has such a symref under $GIT_DIR/refs/remotes
   can be used to name the ref.  IOW, "git diff origin" in a
   repository a cloned this way means you want a diff against
   $GIT_DIR/refs/remotes/origin/HEAD.

   I've done reasonable amount of testing over git:// transport,
   and some with http:// as well, but I do not know if rsync://
   works at all (I never use rsync:// transport myself).  If
   anybody cares about rsync:// transport, please test it while
   it still is in "next" to keep things working for you.

   A new configuration option, 'core.warnambiguousrefs', can be
   set to warn you if you use "frotz" to name a ref when you
   have more than one "frotz" under $GIT_DIR/refs (e.g. you have
   both branch "frotz" and tag "frotz", and/or you have
   refs/remotes/frotz/HEAD).

   It also has changes by Eric Wong to teach git-fetch about
   $GIT_DIR/refs/remotes hierarchy.

Junio>  - cvsimport post-import checkout fix.

Junio> Earlier we had a workaround to deal with people who import Junio> into the current branch by not checking out. After Junio> incrementally importing from the same CVS repository again, Junio> however, the code did update the branch head. This made the Junio> working tree and the index stale and was causing more Junio> confusion than it avoided.

Junio> This fix is to make re-importing act more like git-pull, not Junio> git-fetch. So if you run an incremental import into the Junio> current branch, it tries to fast-forward the working tree and Junio> index (your current branch head, index and working tree had Junio> better be pristine with respect to the CVS repository for Junio> this, but that is already an requirement for a tracking Junio> branch anyway) when your current branch is the tracking Junio> branch, or merge the imported result into your current branch Junio> if you are using a separate tracking branch.

Junio> I've done some testing on this myself, but am waiting for Junio> independent confirmations from cvsimport users. Merlyn?

I'm waiting for that CVS tree to change again. It changes every 4-5 days.

Randal> I'm waiting for that CVS tree to change again. It changes every Randal> 4-5 days.

Speaking of which, I *know* you sent me a patch to apply to incorporate the one difference, but is there a more automatic way of cherry-picking git-cvsimport.perl from "next" into a new topic branch of mine?

For example, I can do this:

$ git-checkout next $ cp git-cvsimport.perl DUMMY $ git-checkout -b my-playground $ mv DUMMY git-cvsimport.perl $ git-commit -a -m 'trying that other version'

But this wastes a commit. Is there any way to get an index that simply includes the file from that other branch?

merlyn@stonehenge.com (Randal L. Schwartz) writes:

        $ git checkout master
        $ git checkout next git-cvsimport.perl

Junio> $ git checkout master Junio> $ git checkout next git-cvsimport.perl

Yow.  How simple is *that*?  Thanks.

merlyn@stonehenge.com (Randal L. Schwartz) writes:

There is one thing you would want to be careful about. This updates the index.

On Tue, 21 Mar 2006, Junio C Hamano wrote:

Yes. Btw, I've been bitten by that. I think it might be better to _not_ update the index when we check out a file from another branch than the one we're on (or rather, we should perhaps update the index with the value from the current branch every time, even though the _working_tree_ is updated from another branch)

		Linus

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

Ah cool :) I had the problem recently. Also, Would could I know all configuration option ?

-- Beber #e.fr@freenode

Dear diary, on Wed, Mar 22, 2006 at 02:58:28AM CET, I got a letter where Junio C Hamano <junkio@cox.net> said that...

Sounds very good.

Is there any reason why this isn't enabled by default?

Petr Baudis <pasky@suse.cz> writes:

Not in particular, other than Inertia and trying one baby step at a time.