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

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

[Junio C Hamano]

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.

[PATCH] reflog-expire: brown paper bag fix.

[Junio C Hamano]

When --stale-fix is not passed, the code did not initialize the
two commit objects properly.

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

 * If you see Segfault from "git gc", it would have left two
   .lock files under .git/refs/ and .git/logs/refs; your
   repository has not be corrupted with this.  Please remove the
   two leftover .lock files by hand, apply this patch and
   re-run.

 builtin-reflog.c |   18 ++++++++++++------
 1 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/builtin-reflog.c b/builtin-reflog.c
index ca22452..7206b7a 100644
--- a/builtin-reflog.c
+++ b/builtin-reflog.c
@@ -173,7 +173,6 @@ static int keep_entry(struct commit **it, unsigned char *sha1)
 {
 	struct commit *commit;
 
-	*it = NULL;
 	if (is_null_sha1(sha1))
 		return 1;
 	commit = lookup_commit_reference_gently(sha1, 1);
@@ -204,15 +203,22 @@ static int expire_reflog_ent(unsigned char *osha1, unsigned char *nsha1,
 	if (timestamp < cb->cmd->expire_total)
 		goto prune;
 
+	old = new = NULL;
 	if (cb->cmd->stalefix &&
 	    (!keep_entry(&old, osha1) || !keep_entry(&new, nsha1)))
 		goto prune;
 
-	if ((timestamp < cb->cmd->expire_unreachable) &&
-	    (!cb->ref_commit ||
-	     (old && !in_merge_bases(old, cb->ref_commit)) ||
-	     (new && !in_merge_bases(new, cb->ref_commit))))
-		goto prune;
+	if (timestamp < cb->cmd->expire_unreachable) {
+		if (!cb->ref_commit)
+			goto prune;
+		if (!old && !is_null_sha1(osha1))
+			old = lookup_commit_reference_gently(osha1, 1);
+		if (!new && !is_null_sha1(nsha1))
+			new = lookup_commit_reference_gently(nsha1, 1);
+		if ((old && !in_merge_bases(old, cb->ref_commit)) ||
+		    (new && !in_merge_bases(new, cb->ref_commit)))
+			goto prune;
+	}
 
 	if (cb->newlog) {
 		char sign = (tz < 0) ? '-' : '+';
-- 
1.5.0.rc1

Re: [PATCH] reflog-expire: brown paper bag fix.

[Shawn O. Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> When --stale-fix is not passed, the code did not initialize the
> two commit objects properly.
> 
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> ---
> 
>  * If you see Segfault from "git gc", it would have left two
>    .lock files under .git/refs/ and .git/logs/refs; your
>    repository has not be corrupted with this.  Please remove the
>    two leftover .lock files by hand, apply this patch and
>    re-run.

Thanks for fixing this Junio.  I noticed it myself today and meant
to debug it, but haven't had a chance to do it yet.

-- 
Shawn.

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

[Andy Parkins]

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

[PATCH] Friendlier error message for commands that can't be run from a subdirectory.

[koreth]

Signed-off-by: Steven Grimm <koreth@midwinter.com>
---

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

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

[Steven Grimm]

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

[PATCH] Change to the repository's root directory if needed.

[koreth]

Signed-off-by: Steven Grimm <koreth@midwinter.com>
---

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

Re: [PATCH] Change to the repository's root directory if needed.

[Junio C Hamano]

koreth@midwinter.com writes:

> Signed-off-by: Steven Grimm <koreth@midwinter.com>
> ---
>
> Or try this instead. It seems to work in my limited testing, but it's
> possible this breaks something somewhere.

Porcelains that define SUBDIRECTORY_OK but do not do cdup are
very valid, and they should not be cd'ed up automatically.
They set SUBDIRECTORY_OK for three different reasons:

 (1) some of them always cdup themselves.  git-fetch is the sole
     example I can think of and I do not think it even needs to.

 (2) some of them stay in the subdirectory, and rely on the
     plumbing level to limit the scope of operation with the
     current directory.  The most notable example used to be
     "git-diff" but that is now a built-in.

     Also they take filename that could be relative to the
     current directory.  git-commit is an example.

 (3) some of them are complex mixture of (1) and (2) -- most
     notable is git-checkout

 (4) some of them do not care.  git-verify-tag is an example.

Your patch assumes everybody is either (1) or (4).  I would not
be surprised if you see breakage everywhere.  For example, I
think you just broke "git-tag -F <file>".  Also I think you
surprised users of git-clean (which I do not use personally);
it would start removing stuff outside of the current directory.

Re: [PATCH] Change to the repository's root directory if needed.

[Steven Grimm]

Junio C Hamano wrote:
> Porcelains that define SUBDIRECTORY_OK but do not do cdup are
> very valid, and they should not be cd'ed up automatically.
>   

My patch doesn't do the cd if SUBDIRECTORY_OK is defined, for exactly 
that reason.

-Steve

Re: [PATCH] Change to the repository's root directory if needed.

[Junio C Hamano]

Steven Grimm <koreth@midwinter.com> writes:

> Junio C Hamano wrote:
>> Porcelains that define SUBDIRECTORY_OK but do not do cdup are
>> very valid, and they should not be cd'ed up automatically.
>>
>
> My patch doesn't do the cd if SUBDIRECTORY_OK is defined, for exactly
> that reason.

Ah, I misread the patch.  Sorry.

But the point is that the scripts that do not currently say
SUBDIRECTORY_OK have not even been audited to see if it makes
sense to always cd to the top.  Isn't your patch making as if
they are saying SUBDIRECTORY_OK=Yes and cd to the top upfront is
the right thing to do?

[PATCH] Explain "Not a git repository: '.git'".

[Junio C Hamano]

Andy Parkins noticed that the error message some "whole tree"
oriented commands emit is stated misleadingly when they refused
to run from a subdirectory.

We could probably allow some of them to work from a subdirectory
but that is a semantic change that could have unintended side
effects, so let's start at first by rewording the error message
to be easier to read without doing anything else to be safe.

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

 Andy Parkins <andyparkins@gmail.com> writes:

 > 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.

 Thanks; let's do this for now.

 git-sh-setup.sh |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 4a02b38..57f7f77 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -60,7 +60,11 @@ esac
 if [ -z "$SUBDIRECTORY_OK" ]
 then
 	: ${GIT_DIR=.git}
-	GIT_DIR=$(GIT_DIR="$GIT_DIR" git-rev-parse --git-dir) || exit
+	GIT_DIR=$(GIT_DIR="$GIT_DIR" git-rev-parse --git-dir) || {
+		exit=$?
+		echo >&2 "You need to run this command from the toplevel of the working tree."
+		exit $exit
+	}
 else
 	GIT_DIR=$(git-rev-parse --git-dir) || exit
 fi
-- 
1.5.0.rc1.g397d

Re: [PATCH] Explain "Not a git repository: '.git'".

[Junio C Hamano]

I have three follow-up patches, two are probably Ok (but I'd
rather not apply them to 'master' now -rc1 cycle is on), and the
last one debatable.

  [PATCH 1/3] Define cd_to_toplevel shell function in git-sh-setup
  [PATCH 2/3] Use cd_to_toplevel in scripts that implement it by hand.
  [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory

[PATCH 1/3] Define cd_to_toplevel shell function in git-sh-setup

[Junio C Hamano]

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 git-sh-setup.sh |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 57f7f77..6b1c142 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -36,6 +36,17 @@ is_bare_repository () {
 	esac
 }
 
+cd_to_toplevel () {
+	cdup=$(git-rev-parse --show-cdup)
+	if test ! -z "$cdup"
+	then
+		cd "$cdup" || {
+			echo >&2 "Cannot chdir to $cdup, the toplevel of the working tree"
+			exit 1
+		}
+	fi
+}
+
 require_work_tree () {
 	test $(is_bare_repository) = false ||
 	die "fatal: $0 cannot be used without a working tree."
-- 
1.5.0.rc1.g397d

[PATCH 2/3] Use cd_to_toplevel in scripts that implement it by hand.

[Junio C Hamano]

This converts scripts that do "cd $(rev-parse --show-cdup)" by
hand to use cd_to_toplevel.

I think git-fetch does not have to go to the toplevel, but that
should be dealt with in a separate patch.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 git-checkout.sh |    6 +-----
 git-commit.sh   |   22 ++++++++--------------
 git-fetch.sh    |    6 +-----
 git-reset.sh    |    6 +-----
 4 files changed, 11 insertions(+), 29 deletions(-)

diff --git a/git-checkout.sh b/git-checkout.sh
index a2b8e4f..66e40b9 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -135,11 +135,7 @@ fi
 
 # We are switching branches and checking out trees, so
 # we *NEED* to be at the toplevel.
-cdup=$(git-rev-parse --show-cdup)
-if test ! -z "$cdup"
-then
-	cd "$cdup"
-fi
+cd_to_toplevel
 
 [ -z "$new" ] && new=$old && new_name="$old_name"
 
diff --git a/git-commit.sh b/git-commit.sh
index eddd863..9fdf234 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -316,22 +316,16 @@ esac
 ################################################################
 # Prepare index to have a tree to be committed
 
-TOP=`git-rev-parse --show-cdup`
-if test -z "$TOP"
-then
-	TOP=./
-fi
-
 case "$all,$also" in
 t,)
 	save_index &&
 	(
-		cd "$TOP"
-		GIT_INDEX_FILE="$NEXT_INDEX"
-		export GIT_INDEX_FILE
+		cd_to_toplevel &&
+		GIT_INDEX_FILE="$NEXT_INDEX" &&
+		export GIT_INDEX_FILE &&
 		git-diff-files --name-only -z |
 		git-update-index --remove -z --stdin
-	)
+	) || exit
 	;;
 ,t)
 	save_index &&
@@ -339,11 +333,11 @@ t,)
 
 	git-diff-files --name-only -z -- "$@"  |
 	(
-		cd "$TOP"
-		GIT_INDEX_FILE="$NEXT_INDEX"
-		export GIT_INDEX_FILE
+		cd_to_toplevel &&
+		GIT_INDEX_FILE="$NEXT_INDEX" &&
+		export GIT_INDEX_FILE &&
 		git-update-index --remove -z --stdin
-	)
+	) || exit
 	;;
 ,)
 	case "$#" in
diff --git a/git-fetch.sh b/git-fetch.sh
index c58704d..87b940b 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -5,12 +5,8 @@ USAGE='<fetch-options> <repository> <refspec>...'
 SUBDIRECTORY_OK=Yes
 . git-sh-setup
 set_reflog_action "fetch $*"
+cd_to_toplevel ;# probably unnecessary...
 
-TOP=$(git-rev-parse --show-cdup)
-if test ! -z "$TOP"
-then
-	cd "$TOP"
-fi
 . git-parse-remote
 _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
 _x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
diff --git a/git-reset.sh b/git-reset.sh
index b9045bc..91c7e6e 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -53,11 +53,7 @@ then
 	exit
 fi
 
-TOP=$(git-rev-parse --show-cdup)
-if test ! -z "$TOP"
-then
-	cd "$TOP"
-fi
+cd_to_toplevel
 
 if test "$reset_type" = "--hard"
 then
-- 
1.5.0.rc1.g397d

[PATCH 3/3] Allow whole-tree operations to be started from a subdirectory

[Junio C Hamano]

This updates five commands (merge, pull, rebase, revert and cherry-pick)
so that they can be started from a subdirectory.

This may not actually be what we want to do.  These commands are
inherently whole-tree operations, and an inexperienced user may
mistakenly expect a "git pull" from a subdirectory would merge
only the subdirectory the command started from.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 git-merge.sh  |    4 +++-
 git-pull.sh   |    4 +++-
 git-rebase.sh |    3 +++
 git-revert.sh |    3 +++
 4 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/git-merge.sh b/git-merge.sh
index 3eef048..7de83dc 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -5,12 +5,14 @@
 
 USAGE='[-n] [--no-commit] [--squash] [-s <strategy>] [-m=<merge-message>] <commit>+'
 
+SUBDIRECTORY_OK=Yes
 . git-sh-setup
 set_reflog_action "merge $*"
 require_work_tree
+cd_to_toplevel
 
 test -z "$(git ls-files -u)" ||
-	die "You are in a middle of conflicted merge."
+	die "You are in the middle of a conflicted merge."
 
 LF='
 '
diff --git a/git-pull.sh b/git-pull.sh
index e9826fc..9592617 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -6,12 +6,14 @@
 
 USAGE='[-n | --no-summary] [--no-commit] [-s strategy]... [<fetch-options>] <repo> <head>...'
 LONG_USAGE='Fetch one or more remote refs and merge it/them into the current HEAD.'
+SUBDIRECTORY_OK=Yes
 . git-sh-setup
 set_reflog_action "pull $*"
 require_work_tree
+cd_to_toplevel
 
 test -z "$(git ls-files -u)" ||
-	die "You are in a middle of conflicted merge."
+	die "You are in the middle of a conflicted merge."
 
 strategy_args= no_summary= no_commit= squash=
 while case "$#,$1" in 0) break ;; *,-*) ;; *) break ;; esac
diff --git a/git-rebase.sh b/git-rebase.sh
index 98f9558..c8bd0f9 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -27,9 +27,12 @@ Example:       git-rebase master~1 topic
        /                   -->           /
   D---E---F---G master          D---E---F---G master
 '
+
+SUBDIRECTORY_OK=Yes
 . git-sh-setup
 set_reflog_action rebase
 require_work_tree
+cd_to_toplevel
 
 RESOLVEMSG="
 When you have resolved this problem run \"git rebase --continue\".
diff --git a/git-revert.sh b/git-revert.sh
index fcca3eb..224e654 100755
--- a/git-revert.sh
+++ b/git-revert.sh
@@ -19,8 +19,11 @@ case "$0" in
 	echo >&2 "What are you talking about?"
 	exit 1 ;;
 esac
+
+SUBDIRECTORY_OK=Yes ;# we will cd up
 . git-sh-setup
 require_work_tree
+cd_to_toplevel
 
 no_commit=
 while case "$#" in 0) break ;; esac
-- 
1.5.0.rc1.g397d

Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory

[Andy Parkins]

On Friday 2007, January 12 20:56, Junio C Hamano wrote:

> This may not actually be what we want to do.  These commands are
> inherently whole-tree operations, and an inexperienced user may
> mistakenly expect a "git pull" from a subdirectory would merge
> only the subdirectory the command started from.

You're right it might be confusing at first, however, I still think it's the 
right thing to do.

Here's my reasoning: for a while, with subversion as a user you feel all warm 
inside that commands only work on the current subdirectory, so "svn update" 
would only update the current subdirectory to the latest revision.  Of course 
as git users we all see the horrendous potential errors that behaviour can 
induce.  It creates subdirectories with mixed versions from the repository - 
absolute disaster pends.

Git is of course far more sensible, if you checkout in a subdirectory the 
whole working directory changes, meaning everything is always nicely in sync 
and really does represent a snapshot at any time.

Now; once you (as a new user) accept that git checkout should (and does) 
checkout the whole working directory regardless of where you are, then by 
extension every other working-directory-wide command should do the same.

Phew.  I'm too noisy.  What a verbose way of saying
   fromAOL("me too");


Andy

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

Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory

[Josef Weidendorfer]

On Friday 12 January 2007 21:56, Junio C Hamano wrote:
> This updates five commands (merge, pull, rebase, revert and cherry-pick)
> so that they can be started from a subdirectory.
> 
> This may not actually be what we want to do.  These commands are
> inherently whole-tree operations, and an inexperienced user may
> mistakenly expect a "git pull" from a subdirectory would merge
> only the subdirectory the command started from.

Yes, this IMHO is a problem.

Why not add a general "--top" option to the "git" wrapper,
to temporarily let git change to the toplevel while running
the command?

The wish to allow git-fetch from subdirectories is the
inconvenience to have to cd up, and later down. This is
avoided by running "git --top fetch", and theses people
should be happy.

Yet, if the command outputs some relative paths, the
user is very well aware that these paths are from the
toplevel, as he explicitly specified "--top".

Aside from this, the "--top" options sometimes could
be handy even for other git commands.

And when e.g. git fetch is run from a subdirectory, we
could add to the (now better) error message:

You need to run this command from the toplevel of the working tree.
Alternatively, run "git --top ..." to temporary switch to the
toplevel while running the git command.

Josef

Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory

[Shawn O. Pearce]

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> The wish to allow git-fetch from subdirectories is the
> inconvenience to have to cd up, and later down. This is
> avoided by running "git --top fetch", and theses people
> should be happy.

But not only that, git-fetch *never* alters the working directory.
So it doesn't matter where git-fetch is invoked from, just that
it can find the correct .git directory to run against.  And --top
isn't necessary to do that, the command will find the implied .git
directory own its own.
 
-- 
Shawn.

Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory

[Josef Weidendorfer]

On Sunday 14 January 2007 01:21, Shawn O. Pearce wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> > The wish to allow git-fetch from subdirectories is the
> > inconvenience to have to cd up, and later down. This is
> > avoided by running "git --top fetch", and theses people
> > should be happy.
> 
> But not only that, git-fetch *never* alters the working directory.

Ah, typo.
s/fetch/merge/ (or pull, rebase, ...)

Josef

Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory

[Junio C Hamano]

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

> On Friday 12 January 2007 21:56, Junio C Hamano wrote:
>> This updates five commands (merge, pull, rebase, revert and cherry-pick)
>> so that they can be started from a subdirectory.
>> 
>> This may not actually be what we want to do.  These commands are
>> inherently whole-tree operations,...
>
> Why not add a general "--top" option to the "git" wrapper,
> to temporarily let git change to the toplevel while running
> the command?
>
> The wish to allow git-fetch from subdirectories is the
> inconvenience to have to cd up, and later down. This is
> avoided by running "git --top fetch", and theses people
> should be happy.

Well, git-fetch does not have anything to do with the working
tree, so it does not matter if you run from a subdirectory.  You
do not even need --top for it (and you don't with v1.5.0-rc1).

If we replace "git-fetch" in what you said with one of the
commands I listed in the message you quoted, what you said
becomes at least internally consistent.  But I do not
necessarily agree with it.

Adding --top and refusing to work without the option gives a
false impression that it is a bug that they do not work from the
top in the current implementation, and someday we might do these
commands limited to the current directory when the user is in a
subdirectory.  But for the above commands, it is definitely not
the case.  They are inherently whole-tree operations and it
ould actually be a bug to limit their operation to a single
subdirectory.

For example, what would a "merge" limited to the current
directory do?  It would probably do the usual 3-way merge for
the current directory and apply the 'ours' strategy for the rest
of the tree.

But that is obviously wrong.  The new commit claims that "I
considered the whole tree states these two commits record, and
came up with this another whole tree this commit records -- it
suits my purpose better than either of these other two trees".
Future merges that involve the resulting commit will take this
statement into account, and will revert the changes the other
branch would have brought in outside the current directory if
your merge result is later merged into somebody else's tree.

Rebasing a series of commits on top of some other branch, but
limiting only to the current directory does not make much sense,
either; it would lose the changes to the other parts of the
tree.  Losing the changes to the other parts of the tree might
sometimes be what the user would want, but for the most cases
that would not be true.  Also what the original log messages say
would not match the set of partial changes limited to the
current directory you are porting forward, so you would need to
reword the logs as well if you are limiting its operation to the
current directory.  In other words, it might be sometimes useful
but that is not a "rebase" anymore -- it is something else.  The
same discussion applies to the last two commands in the list
(revert and cherry-pick).

So for that reason, I think there are only two valid choices.
Either we insist these commands to be run from the top, or we
always automatically run these commands by cd'ing to the top
ourselves.

Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory

[Steven Grimm]

Josef Weidendorfer wrote:
> Why not add a general "--top" option to the "git" wrapper,
> to temporarily let git change to the toplevel while running
> the command?
>   

If I can add a config entry so --top is the default, then that's 
acceptable, but IMO it should be the default and we should, at most, 
spit out a warning if a command is run in a subdirectory and there's a 
chance of confusion.

When I run one of the commands that currently can't run in a 
subdirectory and it spits out its error message, I NEVER react to that 
by saying, "Oops, forgot I was in a subdirectory, guess I didn't want to 
run that after all." (Have any of you said that, even once?) I react by 
grimacing and typing "cd" so the command will do what I told it to do. I 
have done that every single time I've gotten the in-a-subdirectory 
error. And muttering under my breath something along the lines of, "The 
code knows everything it needs to know to do what I just told it to, but 
it's making me take seconds to do by hand what it could have done on its 
own in nanoseconds."

Which is why I think the commands should just cd to the top directory as 
needed. Doing otherwise is just making the user do pointless busywork. 
IMO any command that, if run in a subdirectory, currently does nothing 
but spit out a "hey, you can't run me in a subdirectory!" error is not 
doing what the user wanted. The user never runs one of those commands 
hoping to see an error message or to test whether he's in the top-level 
directory. I can't think of any situation in which I'd want to see that 
error instead of the --top behavior.

It is entirely possible that automatically changing to the top directory 
will also do something other than what the user wanted some percentage 
of the time, but that percentage will be far, far lower than 100, which 
is what it is now. And I posit that the number of users confused or 
frustrated by the whole-tree operations after the first time they see it 
happen (after which it won't be unexpected) will be far smaller than the 
number frustrated by the current pointless error message on a regular basis.

> The wish to allow git-fetch from subdirectories is the
> inconvenience to have to cd up, and later down. This is
> avoided by running "git --top fetch", and theses people
> should be happy.
>
> Yet, if the command outputs some relative paths, the
> user is very well aware that these paths are from the
> toplevel, as he explicitly specified "--top".
>   

That would be covered just as well by outputting a status message before 
any relative paths, e.g.

Updating /home/john/git-repo ...
Conflict: src/foo.c

(Not that that's real git output, but you get the idea.) It could be 
suppressed when the command is run from the top-level directory, though 
I think it'd be better to just always output it for consistency's sake.

-Steve

Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory

[Junio C Hamano]

Steven Grimm <koreth@midwinter.com> writes:

> Josef Weidendorfer wrote:
>> Why not add a general "--top" option to the "git" wrapper,
>> to temporarily let git change to the toplevel while running
>> the command?
>>
>
> If I can add a config entry so --top is the default, then that's
> acceptable, but IMO it should be the default and we should, at most,
> spit out a warning if a command is run in a subdirectory and there's a
> chance of confusion.
>
> When I run one of the commands that currently can't run in a
> subdirectory and it spits out its error message, I NEVER react to that
> by saying, "Oops, forgot I was in a subdirectory, guess I didn't want
> to run that after all." (Have any of you said that, even once?)

I agree with you 90% -- the other 10% are:

 - when these whole-tree operations fail in conflicts, I need to
   cd to the top to deal with "the other parts" of the tree
   anyway.

 - the result of merging other tree may make the current
   directory disappear (say, I haven't changed anything in the
   current directory and the other branch moved it to somewhere
   else, so it cleanly merged but now the current directory
   should not be there).

These worries are only small percentage because most of the
merges (or merge-like operations) are clean and directory
removal is rare.

I would understand why somebody might want to fetch from others
while working in subdirectory -- to see what other people might
be doing in the same area as you are currently working on.

I consider that being in a subdirectory means the user is in the
middle of actively working on something in that area.  Honestly
I do not understand why anybody would want to run the five
whole-tree commands under discussion (merge, pull, rebase,
revert and cherry-pick) in the middle of doing something, so
from the theoretical point of view I would agree that it makes
sense for the commands to internally cd-up to do their work, I
am not sure how much practical value it would add.

> ... I
> react by grimacing and typing "cd" so the command will do what I told
> it to do. I have done that every single time I've gotten the
> in-a-subdirectory error. And muttering under my breath something along
> the lines of, "The code knows everything it needs to know to do what I
> just told it to, but it's making me take seconds to do by hand what it
> could have done on its own in nanoseconds."

I do understand that you would want to cuss --- I probably would
if that happened to me, too.

However, I am somewhat doubtful to put me in that situation in
the first place, because running these five commands would be
something I would do when my work-in-progress is somewhat in a
stable state (perhaps after creating a temporary commit with
"git-commit -a -m WIP" on the current topic branch), and am
switching my attention to do something else.  Doing one of these
five commands (say "rebase") would be the first action of the
next stage of my work, but that would most likely be preceded by
cd'ing to the top; I am unlikely to stay in the "current
subdirectory" when running the "rebase".

I most likely am missing something, some obvious thing in your
workflow that is not mine.

Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory

[Steven Grimm]

Junio C Hamano wrote:
> I consider that being in a subdirectory means the user is in the
> middle of actively working on something in that area.  Honestly
> I do not understand why anybody would want to run the five
> whole-tree commands under discussion (merge, pull, rebase,
> revert and cherry-pick) in the middle of doing something, so
> from the theoretical point of view I would agree that it makes
> sense for the commands to internally cd-up to do their work, I
> am not sure how much practical value it would add.
>   

Here's one use case for merge/pull/rebase that is, if not an everyday 
thing, then at least fairly common in my group: Person B fixes a bug in 
some code that's causing problems for the code person A is working on. 
Person A is not at a stopping point in his own work yet, but wants to 
get the fix.

Revert and cherry-pick are less common here but consider this: some 
people want submodule support because they're working on a specific part 
of the tree. They only cd into a subdirectory because there's no way for 
them to make that subdirectory the top level of their local repository. 
The fact that there are siblings of their current directory is just an 
artifact of the project layout and has nothing to do with what they're 
doing at the moment.

For example, on a simple Web project, the UI designers will always cd to 
the "html" directory. They get "src" and "lib" too, but if they had a 
choice they wouldn't. When they cherry-pick, it'll always be a 
cherry-pick of their own stuff (in the html directory) and likewise with 
a revert, so they have no reason to cd-up for any of those operations if 
the tool doesn't demand it. And perhaps less obvious: in a typical 
shared integration area setup, they will never have any conflicts 
anywhere but their subdirectory since the other directories will always 
be able to fast-forward merge. So cd-up isn't useful for them even in 
the case of merge conflicts.

-Steve

Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory

[Steven Grimm]

Steven Grimm wrote:
> Here's one use case for merge/pull/rebase that is, if not an everyday 
> thing, then at least fairly common in my group: Person B fixes a bug 
> in some code that's causing problems for the code person A is working 
> on. Person A is not at a stopping point in his own work yet, but wants 
> to get the fix.

I'll add that that's also the use case where I want git-pull and 
git-rebase to merge changes into my uncommitted working copy. It's 
probably less common in big distributed open-source projects where 
everyone is working on a logically separate, non-overlapping change to 
an otherwise stable code base, but in highly collaborative workgroup 
settings where 5 people are working on the same brand-new feature, it's 
not at all rare, and in those cases, where people are typically editing 
the same small set of files, you really do want to update early and 
often so as to minimize the scope of your merge conflicts and catch any 
integration problems as early as possible.

In that setting, I'd rather not have to commit before each update since 
I'd end up with a change history like "update" "update" "update" 
"implement function foo()" "update" "update" "fix a bug in bar()" etc., 
even if I use rebase.

Cogito handles this case reasonably well, though it has to play tricks 
to do it.

-Steve

Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory

[Junio C Hamano]

Steven Grimm <koreth@midwinter.com> writes:

> For example, on a simple Web project, the UI designers will always cd
> to the "html" directory. They get "src" and "lib" too, but if they had
> a choice they wouldn't. When they cherry-pick, it'll always be a
> cherry-pick of their own stuff (in the html directory) and likewise
> with a revert, so they have no reason to cd-up for any of those
> operations if the tool doesn't demand it. And perhaps less obvious: in
> a typical shared integration area setup, they will never have any
> conflicts anywhere but their subdirectory since the other directories
> will always be able to fast-forward merge. So cd-up isn't useful for
> them even in the case of merge conflicts.

Both good points.  Especially the latter one, I did not think of
myself.

Thanks.

Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory

[Junio C Hamano]

Steven Grimm <koreth@midwinter.com> writes:

> Which is why I think the commands should just cd to the top directory
> as needed. Doing otherwise is just making the user do pointless
> busywork. IMO any command that, if run in a subdirectory, currently
> does nothing but spit out a "hey, you can't run me in a subdirectory!"
> error is not doing what the user wanted. The user never runs one of
> those commands hoping to see an error message or to test whether he's
> in the top-level directory. I can't think of any situation in which
> I'd want to see that error instead of the --top behavior.

Having said what I said in the other message, I 120% agree with
this.

The 20% you did not say but I am adding because I really want it
to happen is this.  I want to make running "git merge" from a
subdirectory first cd-up the interactive shell I am typing "git
merge" into and then run the command.  This is because the
reason why I am running one of these "whole tree" operations is
because I am done with what I have been doing in the
subdirectory I was in, and I am moving onto something different.

Of course this cannot be done from within "git merge" command,
but perhaps with clever use of shell aliases it might be
possible.

Re: [PATCH 3/3] Allow whole-tree operations to be started from a subdirectory

[Andreas Ericsson]

Josef Weidendorfer wrote:
> On Friday 12 January 2007 21:56, Junio C Hamano wrote:
>> This updates five commands (merge, pull, rebase, revert and cherry-pick)
>> so that they can be started from a subdirectory.
>>
>> This may not actually be what we want to do.  These commands are
>> inherently whole-tree operations, and an inexperienced user may
>> mistakenly expect a "git pull" from a subdirectory would merge
>> only the subdirectory the command started from.
> 
> Yes, this IMHO is a problem.
> 
> Why not add a general "--top" option to the "git" wrapper,
> to temporarily let git change to the toplevel while running
> the command?
> 
> The wish to allow git-fetch from subdirectories is the
> inconvenience to have to cd up, and later down. This is
> avoided by running "git --top fetch", and theses people
> should be happy.
> 

It has the feel of forcing me to tell git to do the right thing when 
it's perfectly capable of figuring out what the right thing is on its own.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

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

[lamikr]

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

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

[Horst H. von Brand]

lamikr <lamikr@cc.jyu.fi> wrote:
> 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/

Be careful, this gives you a old-fashioned repository, the repositories
created by 1.5.0-rc are different, and 1.4.4.4 doesn't grok them:

   * refusing to create funny ref 'remotes/origin/*' locally
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513

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

[lamikr]

>> 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/
>>     
>
> Be careful, this gives you a old-fashioned repository, the repositories
> created by 1.5.0-rc are different, and 1.4.4.4 doesn't grok them:
>
>    * refusing to create funny ref 'remotes/origin/*' locally
>   
So that would also not work if one uses git-1.4.4 client for fetching
from the git-1.5.x repository?
How one is then supposed to jump from head/master to tagged version?

Mika

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

[Junio C Hamano]

lamikr <lamikr@cc.jyu.fi> writes:

>> Be careful, this gives you a old-fashioned repository, the repositories
>> created by 1.5.0-rc are different, and 1.4.4.4 doesn't grok them:
>>
>>    * refusing to create funny ref 'remotes/origin/*' locally
>>   
> So that would also not work if one uses git-1.4.4 client for fetching
> from the git-1.5.x repository?

That is untrue.  You do not care (nor you would not generally be
even to tell) which version the repository at the remote end was
prepared with when cloning or fetching from a remote git
repository.

A new repository created by 'git-clone' in 1.5.0 will create the
repository with default configuration that uses a new feature to
allow all (present or future) remote branches tracked.  

The feature is
"refspec wildcard" and looks like this:

	[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*

1.4.4 and older do not understand this new feature used in the
configuration, so if you create a new repository by running
1.5.0 clone, you would need to futz with the configuration file
if we want to use that repository with 1.4.4; you would need to
specify the branches you would want individually:

	[remote "origin"]
        fetch = +refs/heads/master:refs/remotes/origin/master
        fetch = +refs/heads/next:refs/remotes/origin/next

Even if you are updating to 1.5.0, if you will never be
interested in some of the remote branches, the above to exclude
unwanted ones is a good trick to know.