What's in git.git and announcing GIT v1.5.0-rc1

The tip of 'master' branch is tagged as v1.5.0-rc1; this means a
few things:

 - The focus is shifted to stabilize 'master'.  Fixes to what
   are already there are very much appreciated.

 - I'll change my $PATH to use the 'master' version, not 'next',
   for my own use until v1.5.0 final.  I ask people who usually
   follow 'next' to do the same so that we can catch breakages
   on 'master'.

 - No new features nor major changes, whether they have been
   cooking in 'next' or not, will be merged to 'master' until
   v1.5.0 final.  I might drop patches on the floor that are not
   meant for 'master', although I intend to try hard to keep up
   with whatever the list comes up with.

Tonight's update merges a handful remaining topics from 'next',
along with fixes and updates directly applied to 'master'.


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

   Alex Riesen (1):
      Speed-up recursive by flushing index only once for all entries

   Eric Wong (1):
      Avoid errors and warnings when attempting to do I/O on zero bytes

   Johannes Schindelin (2):
      Sanitize for_each_reflog_ent()
      Fix t1410 for core.filemode==false

   Junio C Hamano (20):
      Move initialization of log_all_ref_updates
      Introduce is_bare_repository() and core.bare configuration variable
      git-fetch: allow updating the current branch in a bare repository.
      git-status: show detached HEAD
      Detached HEAD (experimental)
      git-checkout: do not warn detaching HEAD when it is already detached.
      git-checkout: rewording comments regarding detached HEAD.
      git-checkout: safety when coming back from the detached HEAD state.
      git-checkout: fix branch name output from the command
      git-checkout: safety check for detached HEAD checks existing refs
      git-checkout: handle local changes sanely when detaching HEAD
      Makefile: remove $foo when $foo.exe is built/installed.
      merge-recursive: do not use on-file index when not needed.
      Document git-init
      index-pack: write-or-die instead of unchecked write-in-full.
      config-set: check write-in-full returns in set_multivar
      git-rm: do not fail on already removed file.
      git-status: wording update to deal with deleted files.
      plug a few leaks in revision walking used in describe.
      GIT v1.5.0-rc1

   Jürgen Rühle (2):
      send-email: work around double encoding of in-body From field.
      Provide better feedback for the untracked only case in status output

   Lars Hjemli (1):
      git-branch: show detached HEAD

   Linus Torvalds (3):
      write-cache: do not leak the serialized cache-tree data.
      write_in_full: really write in full or return error on disk full.
      Better error messages for corrupt databases

   Nicolas Pitre (1):
      Add git-init documentation.

   Shawn O. Pearce (4):
      Don't save the commit buffer in git-describe.
      Make git-describe a builtin.
      Disallow working directory commands in a bare repository.
      Chose better tag names in git-describe after merges.

On Friday 2007, January 12 02:43, Junio C Hamano wrote:

 - I'll change my $PATH to use the 'master' version, not 'next',
   for my own use until v1.5.0 final.  I ask people who usually
   follow 'next' to do the same so that we can catch breakages
   on 'master'.

Minor thing: git-rebase, git-cherry-pick and git-pull (and presumably 
git-merge) all need to be the repository root to work.  If that is 
intentional, a better message than "fatal: Not a git repository: '.git'" 
would be appropriate.

For me, I'd prefer that they worked in subdirectories.  I do all almost all 
development in "src/" and having to change up a directory just to run git 
commands is inconvenient.



Andy

-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE
andyparkins@gmail.com

Signed-off-by: Steven Grimm <redacted>
---

This doesn't fix the underlying problem (those commands ought to work
from any directory) but it is at least less baffling for the common case.
It's pretty braindead -- if you for some reason have a .git directory
inside one of your subdirectories, you'll get the old error message.

 git-sh-setup.sh |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 4a02b38..803a3bc 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh

@@ -60,6 +60,9 @@ esac
 if [ -z "$SUBDIRECTORY_OK" ]
 then
 	: ${GIT_DIR=.git}
+	if [ ! -d "$GIT_DIR" ]; then
+		die "This command must be run from the root directory of a git repository."
+	fi
 	GIT_DIR=$(GIT_DIR="$GIT_DIR" git-rev-parse --git-dir) || exit
 else
 	GIT_DIR=$(git-rev-parse --git-dir) || exit

-- 
1.5.0.rc0.g4083

Andy Parkins wrote:

For me, I'd prefer that they worked in subdirectories.  I do all almost all 
development in "src/" and having to change up a directory just to run git 
commands is inconvenient.
  

I agree; I find that inconvenient too. The only catch I can see is that 
there might be an expectation that if you run, say, "git-pull" in the 
src directory, it will only update the files in src and will leave the 
ones in the other top-level directories alone. For example, "svn update" 
works that way.

But honestly I think touching files outside the current subdirectory is 
much less of an inconvenience (and it's something you only get surprised 
by once, if at all) than not working in subdirectories at all.

-Steve

Signed-off-by: Steven Grimm <redacted>
---

Or try this instead. It seems to work in my limited testing, but it's
possible this breaks something somewhere. The only weird thing here
is that if, e.g., you have a file foo.c in the top-level directory and
you run "git pull" from a subdirectory, you'll see a message indicating
that "foo.c" was updated, implying that it's updating that file in the
current directory. (Output about files in subdirectories, to my eye,
feels less ambiguous in that respect.) But after running with this for
just a few minutes, I'm willing to put up with that in exchange for
not having to manually cd.

 git-sh-setup.sh |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 4a02b38..d1c78c4 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh

@@ -59,8 +59,13 @@ esac
 # Make sure we are in a valid repository of a vintage we understand.
 if [ -z "$SUBDIRECTORY_OK" ]
 then
-	: ${GIT_DIR=.git}
-	GIT_DIR=$(GIT_DIR="$GIT_DIR" git-rev-parse --git-dir) || exit
+	GIT_DIR=$(git-rev-parse --git-dir) || exit
+	if [ "$GIT_DIR" != ".git" -a "$(basename \"$GIT_DIR\")" = ".git" ]
+	then
+		# In a subdirectory of a non-bare repository; move to root dir
+		cd "`dirname \"$GIT_DIR\"`" || \
+			die "Can't change to repository root directory"
+	fi
 else
 	GIT_DIR=$(git-rev-parse --git-dir) || exit
 fi

-- 
1.5.0.rc0.g4083

Junio C Hamano wrote:

The tip of 'master' branch is tagged as v1.5.0-rc1; this means a
few things:
  

Hi

Would it make sense to add something like this to the announcements as
it is not very easy to find references to the git-repository itself from
the net.

   You can get the git repository-itself by using a following commands

           git-clone git://git.kernel.org/pub/scm/git/git.git git_repo

   After that you can switch to tagged version <v1.5.0-rc1> or sources
from the repository by using command

          git-checkout -f v1.5.0-rc1 master

   Alternatively you can download the tar packed version of sources from
      
          http://www.kernel.org/pub/software/scm/git/

Mika