Allowing override of the default "origin" nickname

Allowing override of the default "origin" nickname

[Mark Levedahl]

git's current support for remote nicknames other than
"origin" is restricted to tracking branches where
branch.<name>.remote is defined. This does not work on
detached heads, and thus does not work for managed
submodules as those are kept on detached heads. When working
with submodules, the remote must be called "origin."

As my project is distributed across multiple domains with
many firewalls and airgaps such that no single server is
available to all, we really need to use nicknames to refer
to different servers, and we need that to work well with
submodules.

So, this patch series:
1) defines a new "remotes.default" config variable per
repository to be the default remote used if no
branch.<name>.remote is found.

2) teaches clone to set remotes.default according to
the user's command (via -o).

3) teaches remote rm to unset remotes.default if deleting
that remote.

4) teaches git-submodule to propoagate the parent's default
branch to submoules during "init", IFF those modules are
defined using relative urls. (Modules using absolute urls
are likely from a different server, so this inheritence is
not likely the right thing in that case.)


This is working well for me, allowing

        git clone -o myserver <url> project
        cd project
        git submodule init
        git submoule update

to work as expected, with all submodules pointing to
"myserver" rather than "origin" and updating correctly despite
being on detached heads.

Mark Levedahl

[PATCH] Teach remote machinery about remotes.default config variable

[Mark Levedahl]

This introduces a new configuration variable, remotes.default, that
defines the name of the default remote to be used. Traditionally, this
is "origin", and could be overridden for a given branch. This change
introduces a way to redefine the default as desired and have that honored
regardless of the currently checked out head (e.g., remotes.default is
used when on a detached head or any other non-tracking branch).

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
 Documentation/config.txt |    6 ++++++
 git-parse-remote.sh      |    5 +++--
 remote.c                 |   11 ++++++++++-
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1b6d6d6..01ce295 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -800,6 +800,12 @@ remote.<name>.tagopt::
 	Setting this value to --no-tags disables automatic tag following when fetching
 	from remote <name>
 
+remotes.default::
+	The name of the remote used by default for fetch / pull. If unset,
+	origin is assumed. This value is used whenever the current branch
+	has no corresponding branch.<name>.remote, such as when working on
+	a detached head.
+
 remotes.<group>::
 	The list of remotes which are fetched by "git remote update
 	<group>".  See linkgit:git-remote[1].
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 695a409..1b235e0 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -56,8 +56,9 @@ get_remote_url () {
 
 get_default_remote () {
 	curr_branch=$(git symbolic-ref -q HEAD | sed -e 's|^refs/heads/||')
-	origin=$(git config --get "branch.$curr_branch.remote")
-	echo ${origin:-origin}
+	git config --get "branch.$curr_branch.remote" ||
+	git config --get "remotes.default" ||
+	echo origin
 }
 
 get_remote_default_refs_for_push () {
diff --git a/remote.c b/remote.c
index 0e00680..4937237 100644
--- a/remote.c
+++ b/remote.c
@@ -10,6 +10,7 @@ static int allocated_branches;
 
 static struct branch *current_branch;
 static const char *default_remote_name;
+static const char *remotes_default_name;
 
 #define BUF_SIZE (2048)
 static char buffer[BUF_SIZE];
@@ -233,6 +234,11 @@ static int handle_config(const char *key, const char *value)
 			add_merge(branch, xstrdup(value));
 		return 0;
 	}
+	if (!strcmp(key, "remotes.default")) {
+		if (value)
+			remotes_default_name = xstrdup(value);
+		return 0;
+	}
 	if (prefixcmp(key,  "remote."))
 		return 0;
 	name = key + 7;
@@ -291,7 +297,6 @@ static void read_config(void)
 	int flag;
 	if (default_remote_name) // did this already
 		return;
-	default_remote_name = xstrdup("origin");
 	current_branch = NULL;
 	head_ref = resolve_ref("HEAD", sha1, 0, &flag);
 	if (head_ref && (flag & REF_ISSYMREF) &&
@@ -300,6 +305,10 @@ static void read_config(void)
 			make_branch(head_ref + strlen("refs/heads/"), 0);
 	}
 	git_config(handle_config);
+	if (!default_remote_name) {
+			default_remote_name = remotes_default_name ?
+				remotes_default_name : xstrdup("origin");
+	}
 }
 
 struct refspec *parse_ref_spec(int nr_refspec, const char **refspec)
-- 
1.5.4.rc2.99.g3ef7-dirty

[PATCH] git-remote - Unset remotes.default when deleting the default remote

[Mark Levedahl]

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
 git-remote.perl |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/git-remote.perl b/git-remote.perl
index d13e4c1..2469b59 100755
--- a/git-remote.perl
+++ b/git-remote.perl
@@ -328,6 +328,11 @@ sub rm_remote {
 
 	$git->command('config', '--remove-section', "remote.$name");
 
+	my $defremote = $git->config("remotes.default");
+	if (defined $defremote && $defremote eq $name) {
+	       $git->command("config", "--unset", "remotes.default");
+	}
+
 	eval {
 	    my @trackers = $git->command('config', '--get-regexp',
 			'branch.*.remote', $name);
-- 
1.5.4.rc2.99.g3ef7-dirty

[PATCH] git-clone - Set remotes.default config variable

[Mark Levedahl]

This records the users choice of default remote name (by default "origin")
as given by the -o option.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
 Documentation/git-clone.txt |    3 ++-
 git-clone.sh                |    1 +
 2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index fdccbd4..7fd3ea1 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -95,7 +95,8 @@ OPTIONS
 --origin <name>::
 -o <name>::
 	Instead of using the remote name 'origin' to keep track
-	of the upstream repository, use <name> instead.
+	of the upstream repository, use <name> instead. The name
+        is recorded in the  remotes.default config variable.
 
 --upload-pack <upload-pack>::
 -u <upload-pack>::
diff --git a/git-clone.sh b/git-clone.sh
index b4e858c..efbcee2 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -242,6 +242,7 @@ fi &&
 export GIT_DIR &&
 GIT_CONFIG="$GIT_DIR/config" git-init $quiet ${template+"$template"} || usage
 
+git config remotes.default $origin
 if test -n "$bare"
 then
 	GIT_CONFIG="$GIT_DIR/config" git config core.bare true
-- 
1.5.4.rc2.99.g3ef7-dirty

[PATCH] git-submodule - Possibly inherit parent's default remote on init/clone

[Mark Levedahl]

For submodules defined relative to their parent, it is likely that the
parent's defined default remote is correct for the child as well. This
allows use of remote names other than "origin", important as managed
submodules are typically checked out on a detached head and therefore
submodule-update invokes git-fetch using the default remote. Without this
change, submodules effectively had to have a default remote of "origin."

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
 Documentation/git-submodule.txt |    8 +++++---
 git-submodule.sh                |   15 ++++++++++++---
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index cffc6d4..440e234 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -36,9 +36,11 @@ status::
 
 init::
 	Initialize the submodules, i.e. register in .git/config each submodule
-	name and url found in .gitmodules. The key used in .git/config is
-	`submodule.$name.url`. This command does not alter existing information
-	in .git/config.
+	name and url found in .gitmodules, along with the default remote origin.
+	For submodules using a relative url, the default remote is inherited
+	from the parent project, for absolute urls the default "origin" is used.
+	The key used in .git/config is submodule.$name.url`. This command does
+	not alter existing information in .git/config.
 
 update::
 	Update the registered submodules, i.e. clone missing submodules and
diff --git a/git-submodule.sh b/git-submodule.sh
index ad9fe62..30e0270 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -7,6 +7,7 @@
 USAGE='[--quiet] [--cached] [add <repo> [-b branch]|status|init|update] [--] [<path>...]'
 OPTIONS_SPEC=
 . git-sh-setup
+. git-parse-remote
 require_work_tree
 
 add=
@@ -95,6 +96,7 @@ module_clone()
 {
 	path=$1
 	url=$2
+	origin=${3:-origin}
 
 	# If there already is a directory at the submodule path,
 	# expect it to be empty (since that is the default checkout
@@ -110,7 +112,7 @@ module_clone()
 	test -e "$path" &&
 	die "A file already exist at path '$path'"
 
-	git-clone -n "$url" "$path" ||
+	git-clone -n -o "$origin" "$url" "$path" ||
 	die "Clone of '$url' into submodule path '$path' failed"
 }
 
@@ -130,9 +132,11 @@ module_add()
 		usage
 	fi
 
+	origin=origin
 	case "$repo" in
 	./*|../*)
 		# dereference source url relative to parent's url
+		origin=$(get_default_remote)
 		realrepo="$(resolve_relative_url $repo)" ;;
 	*)
 		# Turn the source into an absolute path if
@@ -157,7 +161,7 @@ module_add()
 	git ls-files --error-unmatch "$path" > /dev/null 2>&1 &&
 	die "'$path' already exists in the index"
 
-	module_clone "$path" "$realrepo" || exit
+	module_clone "$path" "$realrepo" "$origin" || exit
 	(unset GIT_DIR; cd "$path" && git checkout -q ${branch:+-b "$branch" "origin/$branch"}) ||
 	die "Unable to checkout submodule '$path'"
 	git add "$path" ||
@@ -189,12 +193,15 @@ modules_init()
 		die "No url found for submodule path '$path' in .gitmodules"
 
 		# Possibly a url relative to parent
+		origin=origin
 		case "$url" in
 		./*|../*)
 			url="$(resolve_relative_url "$url")"
+			origin=$(get_default_remote)
 			;;
 		esac
 
+		git config submodule."$name".origin "$origin" &&
 		git config submodule."$name".url "$url" ||
 		die "Failed to register url for submodule path '$path'"
 
@@ -222,10 +229,12 @@ modules_update()
 			say "Submodule path '$path' not initialized"
 			continue
 		fi
+		origin=$(git config submodule."$name".origin)
+		origin=${origin:-origin}
 
 		if ! test -d "$path"/.git
 		then
-			module_clone "$path" "$url" || exit
+			module_clone "$path" "$url" "$origin" || exit
 			subsha1=
 		else
 			subsha1=$(unset GIT_DIR; cd "$path" &&
-- 
1.5.4.rc2.99.g3ef7-dirty

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Junio C Hamano]

Mark Levedahl <mlevedahl@gmail.com> writes:

> This introduces a new configuration variable, remotes.default, that
> defines the name of the default remote to be used.

Does this mean "default" is now a new reserved word that cannot
be used as "git remote update default"?

> ... Traditionally, this
> is "origin", and could be overridden for a given branch. This change
> introduces a way to redefine the default as desired and have that honored
> regardless of the currently checked out head (e.g., remotes.default is
> used when on a detached head or any other non-tracking branch).

I'd 100% agree that being able to use anything not just
hardcoded 'origin' is much better than not being able to.  I do
not have much against that goal.

However, it is a bit hard to judge how much of inconvenience it
really is in your real life that the current behaviour does not
allow you to.

In your cover letter, you said:

>> As my project is distributed across multiple domains with
>> many firewalls and airgaps such that no single server is
>> available to all, we really need to use nicknames to refer
>> to different servers,...

If you need to access different repositories on different
machines from your submodules, you would of course need to
access different domains from your submodule repositories.  But
that does not mean each of them cannot be named 'origin'.  That
name is local to each of the submodule (and the toplevel) and
can point at different domains over different transfer channels.

> diff --git a/git-parse-remote.sh b/git-parse-remote.sh
> index 695a409..1b235e0 100755
> --- a/git-parse-remote.sh
> +++ b/git-parse-remote.sh
> @@ -56,8 +56,9 @@ get_remote_url () {
>  
>  get_default_remote () {
>  	curr_branch=$(git symbolic-ref -q HEAD | sed -e 's|^refs/heads/||')
> -	origin=$(git config --get "branch.$curr_branch.remote")
> -	echo ${origin:-origin}
> +	git config --get "branch.$curr_branch.remote" ||
> +	git config --get "remotes.default" ||
> +	echo origin

This sequence cascaded with || is much nicer than the original,
even if it did not change the behaviour.

> @@ -300,6 +305,10 @@ static void read_config(void)
>  			make_branch(head_ref + strlen("refs/heads/"), 0);
>  	}
>  	git_config(handle_config);
> +	if (!default_remote_name) {
> +			default_remote_name = remotes_default_name ?
> +				remotes_default_name : xstrdup("origin");
> +	}

Is this a bit too deep indentation?

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Mark Levedahl]

On Jan 11, 2008 3:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Does this mean "default" is now a new reserved word that cannot
> be used as "git remote update default"?

oops...git-remote already has a (partially undocumented) use for
remotes.* as well as remote.*, so I need another variable name,
probably core.origin to avoid either defining new namespace or
polluting one reserved for arbitrary end-user use. Will resend patches
later tonight.

>
> However, it is a bit hard to judge how much of inconvenience it
> really is in your real life that the current behaviour does not
> allow you to.

I believe I addressed this in the thread with Dscho.

> >       git_config(handle_config);
> > +     if (!default_remote_name) {
> > +                     default_remote_name = remotes_default_name ?
> > +                             remotes_default_name : xstrdup("origin");
> > +     }
>
> Is this a bit too deep indentation?
>

will fix.


Mark

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Junio C Hamano]

"Mark Levedahl" <mlevedahl@gmail.com> writes:

>> However, it is a bit hard to judge how much of inconvenience it
>> really is in your real life that the current behaviour does not
>> allow you to.
>
> I believe I addressed this in the thread with Dscho.

Thanks.

I have to admit that I happen to agree with Dscho.  I do not see
this helping to solve communication issues very much.

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Mark Levedahl]

Junio C Hamano wrote:
> "Mark Levedahl" <mlevedahl@gmail.com> writes:
>   
> Thanks.
>
> I have to admit that I happen to agree with Dscho.  I do not see
> this helping to solve communication issues very much.
>   
Junio,

My use really is a different use-case than is typical. Origin is a great 
concept for the common case of projects with a single upstream 
repository. Except for cloning, you don't have to know or care the name 
of the upstream as you move from project to project, it is just always 
"origin" and you use the same remote nickname in each.

This breaks down in a project like mine where there are multiple servers 
and the differences are important. Content and usage vary server to 
server, not just connectivity. At this point, hiding the server names is 
counterproductive. Basically, use of origin is data hiding, and data 
hiding is not good when you actually need the data.

Across the git project, I believe everyone basically understands origin 
as git.kernel.org/..., and origin is not ambiguous. There is just one 
server. For my project, there are multiple servers and a number of us 
pull from and push to multiple servers with no intent that any one 
server has everything (This multiplicity is necessary for several 
reasons, and we have various guards in place restrict the content of 
different servers). Thus, there really is no usefully defined *origin*. 
There just isn't. This is where the disagreements lie.

The argument against my approach of explicitly naming the server rests 
upon the premise that hiding a half-dozen servers, all different and 
with those differences being important, under the single universal name 
"origin", makes things easier. It doesn't when different servers are 
different. Yes, it is possible to figure out what "origin" means at a 
given client, and thus understand how to address a given server from 
that client. That is the essence of the problem. It is clear to address 
server1 as "server1", and server3 as "server3." It is not helpful to 
sometimes refer to server1 as origin, sometimes as server3, and thus 
need to know the definition of origin to know how to name the server. 
For the "normal" git use-case the specific definition of origin is 
unimportant when you use it and so provides a useful abstraction. That I 
must know what origin means in order to know what to do indicates the 
abstraction is counter-productive.

Until we started using sub-modules, we used git clone --origin 
<nickname> and per our standard usage never even had "origin" defined. 
We just agreed on a common set of nicknames for our servers and used 
those. Not everyone had all the remotes defined, but nickname "foo" 
meant the same thing everywhere it was defined. That worked very well 
for us.

So, all I am doing here is trying to extend a basic multi-server 
capability git already has for a monolithic project into projects using 
sub-modules. This will let us resume working the way we did before and 
stop overloading a single nickname (origin) with multiple meanings.

Mark

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Junio C Hamano]

Mark Levedahl <mlevedahl@gmail.com> writes:

> My use really is a different use-case than is typical....
>
> This breaks down in a project like mine where there are multiple
> servers and the differences are important. Content and usage vary
> server to server, not just connectivity. At this point, hiding the
> server names is counterproductive. Basically, use of origin is data
> hiding, and data hiding is not good when you actually need the data.

If you need explicit name, you do not have to use "origin".

You can spell URL explicitly to name which exact repository you
mean to reach over which datapath (one physical host may have
different name depending on the network interface you reach it
via).  You can always say

	$ git pull git://that.exact.machine/repo that-branch

if you want to avoid ambiguity.

And that is not atypical at all.  Scan the kernel mailing list,
looking for "please pull" requests.  You will never see 'origin'
or any short nickname.  The names used in communication should
be unambiguous in the context of the communication.  If you know
'origin' mean different things to different people, do not use
that in public communication.

It's that simple.  Isn't it?

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Mark Levedahl]

Junio C Hamano wrote:
> Mark Levedahl <mlevedahl@gmail.com> writes:
>
>
>   
> It's that simple.  Isn't it?
>
>   
Yes, until you hit submodules whose state you are managing from a super 
project. Then it gets hard because the machinery brings origin into play.

Mark

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Junio C Hamano]

Mark Levedahl <mlevedahl@gmail.com> writes:

> Junio C Hamano wrote:
>> Mark Levedahl <mlevedahl@gmail.com> writes:
>>
>>   It's that simple.  Isn't it?
>>
> Yes, until you hit submodules whose state you are managing from a
> super project. Then it gets hard because the machinery brings origin
> into play.

Sorry, I may be missing something.

Even if you have a submodule, you can go there and that will be
a valid freestanding repository.  You can always be explicit,
bypassing any behaviour that defaults to 'origin' to avoid
ambiguity.

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Mark Levedahl]

Junio C Hamano wrote:
> Sorry, I may be missing something.
>
> Even if you have a submodule, you can go there and that will be
> a valid freestanding repository.  You can always be explicit,
> bypassing any behaviour that defaults to 'origin' to avoid
> ambiguity.
>   
"git-submodule update" *requires* that origin is defined in all 
sub-modules. There is no way to avoid this behavior.

Mark

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Junio C Hamano]

Mark Levedahl <mlevedahl@gmail.com> writes:

> Junio C Hamano wrote:
>> Sorry, I may be missing something.
>>
>> Even if you have a submodule, you can go there and that will be
>> a valid freestanding repository.  You can always be explicit,
>> bypassing any behaviour that defaults to 'origin' to avoid
>> ambiguity.
>>
> "git-submodule update" *requires* that origin is defined in all
> sub-modules. There is no way to avoid this behavior.

Ahh.

Does that suggest the new configuration thing is only about the
"submodule update" command, not "remotes.default" that affects
how the non-submodule merge and fetch works?

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Mark Levedahl]

Junio C Hamano wrote:
> Ahh.
>
> Does that suggest the new configuration thing is only about the
> "submodule update" command, not "remotes.default" that affects
> how the non-submodule merge and fetch works?
>
>   
Yes - this patch set was inspired by the single question of "how do I 
avoid needing to define origin as opposed to a server-specific nickname 
now that I am using sub-modules?"

Mark

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Johannes Schindelin]

Hi,

On Sat, 12 Jan 2008, Mark Levedahl wrote:

> Junio C Hamano wrote:
> > Ahh.
> > 
> > Does that suggest the new configuration thing is only about the 
> > "submodule update" command, not "remotes.default" that affects how the 
> > non-submodule merge and fetch works?
>
> Yes - this patch set was inspired by the single question of "how do I 
> avoid needing to define origin as opposed to a server-specific nickname 
> now that I am using sub-modules?"

Why is your patch then not about git-submodule?

And I still fail to see -- even for submodules -- how you begin to tackle 
that lookup problem.

Ciao,
Dscho

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Mark Levedahl]

Johannes Schindelin wrote:
> Why is your patch then not about git-submodule?
>
> And I still fail to see -- even for submodules -- how you begin to tackle 
> that lookup problem.
>
> Ciao,
> Dscho
>
>   
Because git-submodule is a wrapper around git-fetch and git-clone and 
git-remote, and those lacked the mechanism to honor the fact that when I 
said

       git clone -o  frotz frontz.foo.bar/foo.git

I *defined* the upstream's nickname as "frotz", not "origin", and origin 
is *not* defined so don't try to use it. As sub-modules are git 
projects, fixing this in a sub-module necessarily fixes it in any git 
project.

Mark

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Johannes Schindelin]

Hi,

On Sat, 12 Jan 2008, Mark Levedahl wrote:

> Johannes Schindelin wrote:
> > Why is your patch then not about git-submodule?
> > 
> > And I still fail to see -- even for submodules -- how you begin to 
> > tackle that lookup problem.
> 
> Because git-submodule is a wrapper around git-fetch and git-clone and 
> git-remote, and those lacked the mechanism to honor the fact that when I 
> said
> 
>       git clone -o  frotz frontz.foo.bar/foo.git
> 
> I *defined* the upstream's nickname as "frotz", not "origin", and origin 
> is *not* defined so don't try to use it. As sub-modules are git 
> projects, fixing this in a sub-module necessarily fixes it in any git 
> project.

Unfortunately, you _still_ fail to even ackonwledge that you still need a 
lookup, and that I have a point when saying "your patch does not help, 
since you still have a lookup".

But I start to believe that you do not even want to present an argument 
against this reasoning, so I will stop here.

Ciao,
Dscho

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Mark Levedahl]

Johannes Schindelin wrote:
> Unfortunately, you _still_ fail to even ackonwledge that you still need a 
> lookup, and that I have a point when saying "your patch does not help, 
> since you still have a lookup".
>   
I don't acknowledge this point as it is not true.

I will try to explain one more time.

1 - "origin" is fine as an abstraction IFF everyone on the project can 
reasonably expect that "git fetch origin" will yield the same results 
for anyone who executes that command. As I have tried (and apparently 
failed) to explain, for numerous complex and unchangeable reasons, "git 
fetch origin" is *NOT* expected to give the same results around this 
project and therefore, "origin" is not a useful abstraction.

2 - Until we used submodules, we never defined "origin", but instead 
explicitly named the server using standard nicknames (e.g., "git fetch 
frotz", not "git fetch"). Everyone who can access frotz gets the same 
result. Those who can't, and have to use server "zorft", get a different 
result but it is obvious to all they didn't go to frotz.

3 - As the servers are different and have different content, it is just 
part of the workflow to know the server names and use them. We have 
agreed upon a common set of server nicknames. There is no lookup, we 
just know them. Maybe you call this a lookup step, but frankly this is 
part of *required* job knowledge (which server has what and which to use 
for which purpose).

4 - The problem came with submodules. Now, the recipe of "git clone -o 
frotz" no longer really works, as all of the submodules now have remote 
origin = frotz, and remote frotz is undefined while the master-project 
is the other way around. This is confusing to say the least. As 
submodules forced origin in, the path of least resistance  was just 
giving in and using origin. Now we have to be very aware not only of 
what server to use, but now also what origin is so that we can know how 
to reach the server we wanted. (i.e., Do I use "origin" or "frotz" to 
reach frotz?) This *IS* an extra lookup step required because of origin 
being defined.

Now, we can recusively use "git remote add" to just go ahead and add all 
remotes needed regardless of what origin says, and *partly* get back to 
where we were. Only partly, because git submodule update will still use 
origin, and *only* origin for fetching. So we still have to know what 
origin is (problem #1, fixed by my patches 1-4), and if what we need to 
fetch from is in fact not origin (even though the master project knows 
what server to access), submodule update in fact doesn't even work 
(fixed by the fifth patch that flows the remote down from the master).

So no, I do not acknowledge that we have an extra lookup step and that 
just using origin is the same or simpler or whatever. It absolutely is 
not. Quite the opposite, for us using "origin" forces an unnecessary 
extra lookup and translation step and complicates, not simplifies, use 
of submodules.

Mark

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Junio C Hamano]

Mark Levedahl <mlevedahl@gmail.com> writes:

> ... if what
> we need to fetch from is in fact not origin (even though the master
> project knows what server to access), submodule update in fact doesn't
> even work ...

This is an interesting point.

Perhaps git-submodule.sh::modules_update should use $url it
obtains from the configuration in the upper level when running
git-fetch in the submodule.

If you view the problem this way, your earlier "git fetch while
the HEAD is detached always uses 'origin'" may turn out to be a
non-issue.

Which again brings us back to Johannes's earlier point.  If the
issue is about submodule, maybe what needs to be fixes is in
git-submodule, and not the defaulting to 'origin' git-fetch and
friends do.

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Mark Levedahl]

Junio C Hamano wrote:
> Mark Levedahl <mlevedahl@gmail.com> writes:
>
>   
>> ... if what
>> we need to fetch from is in fact not origin (even though the master
>> project knows what server to access), submodule update in fact doesn't
>> even work ...
>>     
>
> This is an interesting point.
>
> Perhaps git-submodule.sh::modules_update should use $url it
> obtains from the configuration in the upper level when running
> git-fetch in the submodule.
>   
yes, I like this change, it works very nicely. but that last patch is 
only a partial solution...
> If you view the problem this way, your earlier "git fetch while
> the HEAD is detached always uses 'origin'" may turn out to be a
> non-issue.
>
> Which again brings us back to Johannes's earlier point.  If the
> issue is about submodule, maybe what needs to be fixes is in
> git-submodule, and not the defaulting to 'origin' git-fetch and
> friends do.
>   
Nope, git submodule *still* requires origin (e.g., execute git submodule 
init or update on a detached head). We are dancing around the issue, not 
fixing the root cause. This is perhaps illuminated by splitting projects 
into two camps:

Camp1 - there is no need to distinguish the upstream servers (or there 
is only one), calling it/all origin is fine.
Camp2 - there is a need to distinguish servers, they are not identical, 
uniform naming across project is required (but folks might still like to 
be able to have a default, and probably want to change that default on 
occasion), .

So far, git is written as if the whole world is in Camp1, and the 
problems appear for Camp2. The underlying issue is that git has 
convolved the referencing, naming, and designation of a default remote 
into *one* thing when it is really three things. For git, the default 
remote is named origin, which is also how it is designated as the 
default, and is also how you reference the default in commands. 
Non-default remotes have an arbitrary nickname, are not default as they 
are not called origin, and are referenced by using their nicknames.

To serve Camp2 (and not impact Camp1), origin should be a handle that 
dereferences to the name of the default remote, and designation of the 
default remote should be by a separate config item rather than a special 
name for the remote. Assume core.origin names the default remote:

For Campl, we have
    core.origin=origin
with the default remote having nickname origin.

For Camp2, we could have
    core.origin=<whatever>
with the default remote having nickname <whatever>

At the command line, "git fetch" dereferences to $(git config 
core.origin), which is origin for Camp1, but <whatever> for Camp2. So, 
Camp1 users don't notice anything is different, and Camp2 users don't 
have a number of different servers all referred to as "origin".

The key is that in Camp2, a given remote now can have  the *same* 
nickname for all members of the project, regardless of which remote they 
have made their default. "git fetch" and "git fetch origin" still work, 
they just dereference core.origin (perhaps verbosely to warn that the 
remote being updated is *not* actually named origin), then update the 
remotes/$(git config core.origin)/* branches.

Obviously, Camp1 with core.origin=origin is the default, and everything 
in user land works exactly as it does today. Camp2 with 
core.origin~=default is only mentioned in the graduate level git course 
and shielded with "Caution, Sharp Knives!" signs. Fine, I need the knives.

Mark

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Junio C Hamano]

Mark Levedahl <mlevedahl@gmail.com> writes:

> Junio C Hamano wrote:
> ...
>> Perhaps git-submodule.sh::modules_update should use $url it
>> obtains from the configuration in the upper level when running
>> git-fetch in the submodule.
>>
> yes, I like this change, it works very nicely. but that last patch is
> only a partial solution...
>> If you view the problem this way, your earlier "git fetch while
>> the HEAD is detached always uses 'origin'" may turn out to be a
>> non-issue.
>>
>> Which again brings us back to Johannes's earlier point.  If the
>> issue is about submodule, maybe what needs to be fixes is in
>> git-submodule, and not the defaulting to 'origin' git-fetch and
>> friends do.
>>
> Nope, git submodule *still* requires origin (e.g., execute git
> submodule init or update on a detached head).

Now I am even more confused.

The approach I suggested in a few paragraphs above, to which you
just said "I like this change", is about making "git submodule
update" to use the url configured in the upper level repository
when it runs "git fetch".  I am looking at around l.238 of
git-submodule.sh.  In the current code, it runs "git-fetch"
without any parameter, which would allow it default to origin or
whatever, which may or may not be desirable depending on where
the 'origin' points at.  If you make that particular git-fetch
explicitly say where the fetch should be done from, wouldn't it
fix the issue for that codepath?  Why does it still require
origin?

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Mark Levedahl]

Junio C Hamano wrote:
>> Nope, git submodule *still* requires origin (e.g., execute git
>> submodule init or update on a detached head).
>>     
>
> Now I am even more confused.
>
> The approach I suggested in a few paragraphs above, to which you
> just said "I like this change", is about making "git submodule
> update" to use the url configured in the upper level repository
> when it runs "git fetch".  I am looking at around l.238 of
> git-submodule.sh.  In the current code, it runs "git-fetch"
> without any parameter, which would allow it default to origin or
> whatever, which may or may not be desirable depending on where
> the 'origin' points at.  If you make that particular git-fetch
> explicitly say where the fetch should be done from, wouldn't it
> fix the issue for that codepath?  Why does it still require
> origin?
1) If top-level is on a detached head, then the remotes machinery will 
find current remote is "origin". This is what would be passed down the 
chain.

2) Absent the other changes in the thread, git-submodule-init still 
invokes   git clone *without* -o in the submodules, and thus still 
defines and points to remote "origin".

Mark

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Johannes Schindelin]

Hi,

On Tue, 15 Jan 2008, Mark Levedahl wrote:

> Junio C Hamano wrote:
> > > Nope, git submodule *still* requires origin (e.g., execute git
> > > submodule init or update on a detached head).
> > >     
> > 
> > Now I am even more confused.
> > 
> > The approach I suggested in a few paragraphs above, to which you
> > just said "I like this change", is about making "git submodule
> > update" to use the url configured in the upper level repository
> > when it runs "git fetch".  I am looking at around l.238 of
> > git-submodule.sh.  In the current code, it runs "git-fetch"
> > without any parameter, which would allow it default to origin or
> > whatever, which may or may not be desirable depending on where
> > the 'origin' points at.  If you make that particular git-fetch
> > explicitly say where the fetch should be done from, wouldn't it
> > fix the issue for that codepath?  Why does it still require
> > origin?
> 1) If top-level is on a detached head, then the remotes machinery will 
> find current remote is "origin". This is what would be passed down the 
> chain.
> 
> 2) Absent the other changes in the thread, git-submodule-init still 
> invokes git clone *without* -o in the submodules, and thus still defines 
> and points to remote "origin".

There's got to be a way to fix this _without_ affecting other users.

Ciao,
Dscho

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Mark Levedahl]

Johannes Schindelin wrote:
>
> There's got to be a way to fix this _without_ affecting other users.
>
> Ciao,
> Dscho
>
>
>   
I believe the only normally visible change from my proposal is that   
git-submodule update will follow top-level's branch from 
branch.<name>.remote, which is a good thing. The other changes are only 
visible if using clone -o or otherwise explicitly asking that "origin" 
not be used or defined, which again is actually following the user's 
request.

If you know of other effects, please explain them.

Mark

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Johannes Schindelin]

Hi,

On Tue, 15 Jan 2008, Mark Levedahl wrote:

> Johannes Schindelin wrote:
> 
> > There's got to be a way to fix this _without_ affecting other users.
>   I believe the only normally visible change from my proposal is that 
> git-submodule update will follow top-level's branch from 
> branch.<name>.remote, which is a good thing. The other changes are only 
> visible if using clone -o or otherwise explicitly asking that "origin" 
> not be used or defined, which again is actually following the user's 
> request.
> 
> If you know of other effects, please explain them.

Do I really have to explain this late in the game for 1.5.4 how such 
intrusive changes can affect stability of code paths which would be 
otherwise unaffected by submodules?  I think not.

Ciao,
Dscho

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Junio C Hamano]

Mark Levedahl <mlevedahl@gmail.com> writes:

> Junio C Hamano wrote:
>> Ahh.
>>
>> Does that suggest the new configuration thing is only about the
>> "submodule update" command, not "remotes.default" that affects
>> how the non-submodule merge and fetch works?
>>
>>
> Yes - this patch set was inspired by the single question of "how do I
> avoid needing to define origin as opposed to a server-specific
> nickname now that I am using sub-modules?"

If it is truly only about "submodule update" then the change
seems too intrusive, especially "remotes.default" variable that
affects the way how fetch and merge works in situations that do
not involve submodules.

If it is not limited to "submodule update" but equally valid fix
to non-submodule situations, the changes to the other parts may
very well be justifiable, but that would mean your "Yes" is a
lie and instead should be "No, but these situations are helped
by these changes because...".

In any case, let's step back a bit.

Earlier you said in a response to Dscho that your servers are
named consistently across repositories.  servername.foo.bar has
nickname servername everywhere.

If your top-level repository needs to access a specific server
"frotz.foo.bar" for updates, then you would have bootstrapped
the whole thing with:

	$ git clone git://frotz.foo.bar/toplevel.git

and in that particular instance of the repository, the source
repository on frotz.foo.bar would have been known as 'origin',
right?  I would not object if you also gave another nickname
'frotz' to the same repository for consistency across
developers.

If that is the case, I am wondering why your subprojects are not
pointing at the corresponding repository on that same
'frotz.foo.bar' machine as 'origin'.  I suspect the reason is
that .gitmodules do not say 'frotz.foo.bar' but name some other
machine.

And in-tree .gitmodules can name only one URL, as it is project
global and shared by everybody.  There is no escaping it.

At least as things were designed, "git submodule init" takes URL
recorded in .gitmodules as a hint, but this is for the user to
override in .git/config in the top-level.  Maybe the UI to allow
this overriding is not easy enough to use, and your submodules
ended up pointing at wrong (from the machine's point of view)
URL as 'origin'.  And perhaps that is the root cause of this
issue?

I am looking at the discussion on the list archive when we
discussed the initial design of .gitmodules:

    http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47502
    http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47548
    http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47621

I do not think we are there yet, and suspect that the current
"git submodule init" does not give the user a chance to say "the
URL recorded in the in-tree .gitmodules corresponds to this URL
in this repository for administrative or network connectivity or
whatever reasons".

Maybe that is the real issue that we should be tackling.  I
dunno.

Although I _think_ being able to use nickname other than
hardcoded 'origin' for fetch/merge is a good change, if my above
suspicion is correct, that change alone would not make the life
easier to people who _use_ submodules, as the need for them to
set up extra nicknames (like 'frotz') and configure the
submodule repositories to use that specific nickname instead of
'origin' would not change.

For communication purposes, I would agree with Dscho that the
name 'origin' that names different things for different people
is wrong and using specific name 'frotz' would solve
communication issues.  But when using the repository and doing
actual work, wouldn't it be _much_ better if you can
consistently go to a repository on a random machine and always
can say 'origin' to mean the other repository this repository
usually gets new objects from (and sends its new objects to)?

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Mark Levedahl]

Junio C Hamano wrote:
> If it is truly only about "submodule update" then the change
> seems too intrusive, especially "remotes.default" variable that
> affects the way how fetch and merge works in situations that do
> not involve submodules.
> If it is not limited to "submodule update" but equally valid fix
> to non-submodule situations, the changes to the other parts may
> very well be justifiable, but that would mean your "Yes" is a
> lie and instead should be "No, but these situations are helped
> by these changes because...".
>
>   
First, I resent the patch series last night, it now uses core.origin to 
avoid touching remotes.* namespace.

The changes *do* fix a nit when on a non-tracking branch. With this, 
fetch / merge / pull will now honor that the user said (via git clone -o 
frotz) "my upstream is nicknamed frotz" and not try to use origin when 
origin was never defined.

So, while fixing this minor aggravation wasn't my motivation, I view 
this as a nice side-benefit :^).

The driving issues:
1) I deal with too many servers for "origin" to be a useful nick name, 
and we have an agreed set of nickname / server pairings across my project.
2) Therefore, we always do git clone -o frotz  frotz.foo.bar/path_to_git.
3) Because of 2, for top-level, "origin" is not defined, tracking 
branches set up via git branch --track point to the correct remote, and 
we basically understand branch names as <nickname>/branch. In other 
words, we *are* aware of what server we are using.
4) git-submodule update breaks the above:
- a) it invokes git clone frotz.foo.bar/path_to_git thus defining 
"origin" as the nickname for frotz.foo.bar.
  b) it invokes bare git-fetch on a detached head, so the upstream *has* 
to be origin.

> If your top-level repository needs to access a specific server
> "frotz.foo.bar" for updates, then you would have bootstrapped
> the whole thing with:
>
> 	$ git clone git://frotz.foo.bar/toplevel.git
>
> and in that particular instance of the repository, the source
> repository on frotz.foo.bar would have been known as 'origin',
> right? 
Nope, we did it with git clone -o frotz git://frotz.foo.bar/toplevel.git
We *never* define origin, frozt.foo.bar is *always* frotz.

>  I would not object if you also gave another nickname
> 'frotz' to the same repository for consistency across
> developers.
>   
good. We are making (some) progress. :^)
> If that is the case, I am wondering why your subprojects are not
> pointing at the corresponding repository on that same
> 'frotz.foo.bar' machine as 'origin'.  I suspect the reason is
> that .gitmodules do not say 'frotz.foo.bar' but name some other
> machine.
>   
Actually,
1) We don't use origin because we avoid having to wonder "Is 
frotz.foo.bar named "origin" or "frotz" on this client, and thus how do 
I get data from frotz?
2) I submitted the change allowing submodules to be recorded into 
.gitmodules with a relative url (e.g., ./path_from_parent_to_submodule) 
rather than an absolute, so we record the relative path only.
3) Thus, git submodule has set up the submodules to point at the parent 
project's default remote. However, in the parent the server is nicknamed 
"frotz", but now in the submodule the server is nicknamed "origin"  Oops.

With my patches, parent and submodule both refer to frotz.foo.bar as frotz.

> And in-tree .gitmodules can name only one URL, as it is project
> global and shared by everybody.  There is no escaping it.
> At least as things were designed, "git submodule init" takes URL
> recorded in .gitmodules as a hint, but this is for the user to
> override in .git/config in the top-level.  Maybe the UI to allow
> this overriding is not easy enough to use, and your submodules
> ended up pointing at wrong (from the machine's point of view)
> URL as 'origin'.  And perhaps that is the root cause of this
> issue?
>
>   
Again, the relative-url patch was to address this so that a project that 
is mirrored to another server remains valid on the new server without 
modifying the .gitmodules in-tree. (Yes, I know you *can* modify 
information in a given clones .git/config, but I'm trying to avoid such 
manual per clone/checkout modifications where it can reasonably be done.).

Basically, I think an important (but not complete) test of the design is 
that

    git clone -o frotz git://frotz.foo.bar/myproject.git
    cd myproject
    git submodule init
    git submodule update

work, with origin = frotz throughout the submodules, and with the whole 
project correctly checked out even if the entire project was rehosted 
onto a different server. With relative urls and my latest patch series 
last night, this all works, and of course upstream can still be "origin" 
if that is what is desired.

While our overall project exists on many servers, mirroring is an 
incorrect term. Rather, only certain branches of  various parts exist 
everywhere, many other branches are specific to a given server, so we 
really name branches using servername/branchname. It is this aspect of 
the project that causes us to be aware of the server in use, and thus 
makes use of "origin" as a generic upstream not useful.

> I am looking at the discussion on the list archive when we
> discussed the initial design of .gitmodules:
>
>     http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47502
>     http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47548
>     http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47621
>
> I do not think we are there yet, and suspect that the current
> "git submodule init" does not give the user a chance to say "the
> URL recorded in the in-tree .gitmodules corresponds to this URL
> in this repository for administrative or network connectivity or
> whatever reasons".
>   
> Maybe that is the real issue that we should be tackling.  I
> dunno.
>
> Although I _think_ being able to use nickname other than
> hardcoded 'origin' for fetch/merge is a good change, if my above
> suspicion is correct, that change alone would not make the life
> easier to people who _use_ submodules, as the need for them to
> set up extra nicknames (like 'frotz') and configure the
> submodule repositories to use that specific nickname instead of
> 'origin' would not change.
>
>   

git-submodule right now supports two different layouts (urls relative to 
the parent, and absolute urls such that each sub-module is on an 
independent server). The management approaches to these are going to be 
different.

I also suspect there are two basic use cases here: accumulation of a 
number of independently managed projects vs. splitting a single major 
project into a number of smaller pieces to allow some decoupling, but 
still managing the set as a composite whole.

There may be some direct correlation of use-case and submodule layout, 
don't know. My project uses relative-urls, and I am managing a large 
project that has been split into a number of components. So, my 
suggestions are focused entirely upon this design and use-case, and I 
don't expect I am addressing the others at all. (As usual, this requires 
someone who needs the other model(s) to step up and drive).

For *my* uses (relative urls, single logical project):

1) There are times when the parent's branch.<name>.remote should be 
flowed down to all subprojects for git submodule update, of course this 
would require that the remote be defined for all.
2) Thus, there needs to be a way to define a new remote globally for the 
project, and have it be correctly interpreted by each submodule (e.g., a 
repeat of the relative-url dereferencing now done by submodule init, but 
applied later to all submodules to define a new remote). Yes, this could 
be accomplished by going into each submodule independently and issuing 
appropriate commands, but administration would be much easier given a 
top-level command that could recurse and "do the right thing" per 
sub-project.

I *suspect* that origin is a much more useful concept for the alternate 
construct (absolute urls, loose alliance of separately managed 
projects), but as I said that is not my problem so please ask folks who 
have that model to define what works for them.
> For communication purposes, I would agree with Dscho that the
> name 'origin' that names different things for different people
> is wrong and using specific name 'frotz' would solve
> communication issues.  But when using the repository and doing
> actual work, wouldn't it be _much_ better if you can
> consistently go to a repository on a random machine and always
> can say 'origin' to mean the other repository this repository
> usually gets new objects from (and sends its new objects to)?
>
>
>   
(Acutally, I thought I was the one arguing that using origin when it 
means different things to different folks is not good. That's the root 
of my problems. :^) )

Anyway, I have not found any use of "origin" on my project really 
useful. We have to be and *are* aware of the server/branchname in use, 
not just the branch. Partly this is because different subgroups have 
different natural gathering points (we tend to exchange data via ad hoc 
"mob" branches on whatever server is most accessible to the particular 
group), and partly because some information simply cannot be allowed on 
some servers, but basically the more accessible a server is, the less 
information that server can have. I believe "origin" is really useful 
only when it has just one meaning, or when all values are effectively 
identical (e.g., you have several mirrors for load balancing, etc, but 
all are identical modulo mirroring delays).

OTOH, a reasonable change to the semantics of "origin" might be to have:
1) core.origin name the remote that is the "normal" upstream.
2) Reserve and allow use of the name "origin" to mean $core.origin, 
e.g., in shell scripts replace all references to remote "origin" with 
$(git config core.origin). Of course, if core.origin = origin, then no 
user visible change occurs.

In this way, git would  not record the same remote's branches in two 
ways (as origin/master and as frotz/master), but rather dereference 
origin -> frotz and then get frotz/master. Dunno, no matter how you 
slice it, having more than one way to refer to the same remote is going 
to be confusing, and that's why we don't use origin.


Mark

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Junio C Hamano]

Mark Levedahl <mlevedahl@gmail.com> writes:

> Basically, I think an important (but not complete) test of the design
> is that
>
>    git clone -o frotz git://frotz.foo.bar/myproject.git
>    cd myproject
>    git submodule init
>    git submodule update
>
> work, with origin = frotz throughout the submodules, and with the
> whole project correctly checked out even if the entire project was
> rehosted onto a different server.

I like that.  This is a very good argument, especially because
it clarifies very well that the issue is not about "'submodule
init' misbehaves" but "fetch/pull/merge does not play well with
clone -o".

The only remaining (minor) doubt I have (not in the sense that
"I object to it!", but in the sense that "I wish there could be
a better alternative, but I do not think of one offhand") is
polluting the core.* namespace with this configuration variable.

Looking at Documentation/config.txt, I realize that we already
have made a mistake of allowing core.gitproxy, but other than
that single mistake, everything in core.* is still about things
that apply to the use of git even when the repository does not
talk with any other repository.  If we deprecate and rename away
that one mistake, we can again make core.* to mean things that
are _really_ core, but using core.origin for "the default remote
is not called 'origin' but 'frotz' here" is a step backwards
from that ideal.

But that's a minor naming issue.

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Mark Levedahl]

Junio C Hamano wrote:
> Mark Levedahl <mlevedahl@gmail.com> writes:
>
>   
>> Basically, I think an important (but not complete) test of the design
>> is that
>>
>>    git clone -o frotz git://frotz.foo.bar/myproject.git
>>    cd myproject
>>    git submodule init
>>    git submodule update
>>
>> work, with origin = frotz throughout the submodules, and with the
>> whole project correctly checked out even if the entire project was
>> rehosted onto a different server.
>>     
>
> I like that.  This is a very good argument, especially because
> it clarifies very well that the issue is not about "'submodule
> init' misbehaves" but "fetch/pull/merge does not play well with
> clone -o"
Carrying the above forward...  Assume I have a checked out project as 
above, then in top-level master project I do:

git remote add zoo git://zoo.tar.fu hisfork.git
git fetch zoo
git checkout --track -b fork zoo/fork
git submodule update

I claim the submodule machinery *should* now follow master's default 
remote, which is "zoo", for the current branch. In addition, the 
submodule machinery should define remote "zoo" in each submodule  where 
it does not already exist, using the same logic using in the original 
init/update phase. This should only apply to modules defined using 
relative urls.

Basically, this formalizes the notion that:

* submodules defined using relative urls are "owned" by the master 
project and will exist anywhere the master does.
* submodules defined using absolute urls are incorporated into the 
project but are separately managed. (While some improved mechanism to 
automate their management from top-level may be proposed, it is not 
obvious to me nor addressed here.)

The subsequent patch modifies git-submodule to implement this logic, and 
applies on top of my previous series.

(Note: I cannot find my latest series in the git-archives on gmane nor 
on marc.info, both have only part, and I am suspicious that something 
went wrong in my sending via gmail, so I am resending the series here, 
now five patches long. Please excuse if this is redundant).

Mark

[PATCH] Teach remote machinery about core.origin config variable

[Mark Levedahl]

This introduces a new configuration variable, core.origin, that
defines the name of the default remote to be used. Traditionally, this
is "origin", and could be overridden for a given branch. This change
introduces a way to redefine the default as desired and have that honored
regardless of the currently checked out head (e.g., core.origin is
used when on a detached head or any other non-tracking branch).

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
 Documentation/config.txt |    6 ++++++
 git-parse-remote.sh      |    5 +++--
 remote.c                 |   11 ++++++++++-
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index df091d1..b7241cf 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -291,6 +291,12 @@ core.editor::
 	`GIT_EDITOR` environment, `core.editor`, `VISUAL` and
 	`EDITOR` environment variables and then finally `vi`.
 
+core.origin::
+	The name of the remote used by default for fetch / pull. If unset,
+	origin is assumed. This value is used whenever the current branch
+	has no corresponding branch.<name>.remote, such as when working on
+	a detached head.
+
 core.pager::
 	The command that git will use to paginate output.  Can be overridden
 	with the `GIT_PAGER` environment variable.
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 695a409..c7ac7c7 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -56,8 +56,9 @@ get_remote_url () {
 
 get_default_remote () {
 	curr_branch=$(git symbolic-ref -q HEAD | sed -e 's|^refs/heads/||')
-	origin=$(git config --get "branch.$curr_branch.remote")
-	echo ${origin:-origin}
+	git config --get "branch.$curr_branch.remote" ||
+	git config --get "core.origin" ||
+	echo origin
 }
 
 get_remote_default_refs_for_push () {
diff --git a/remote.c b/remote.c
index 0e00680..302d499 100644
--- a/remote.c
+++ b/remote.c
@@ -10,6 +10,7 @@ static int allocated_branches;
 
 static struct branch *current_branch;
 static const char *default_remote_name;
+static const char *core_origin;
 
 #define BUF_SIZE (2048)
 static char buffer[BUF_SIZE];
@@ -233,6 +234,11 @@ static int handle_config(const char *key, const char *value)
 			add_merge(branch, xstrdup(value));
 		return 0;
 	}
+	if (!strcmp(key, "core.origin")) {
+		if (value)
+			core_origin = xstrdup(value);
+		return 0;
+	}
 	if (prefixcmp(key,  "remote."))
 		return 0;
 	name = key + 7;
@@ -291,7 +297,6 @@ static void read_config(void)
 	int flag;
 	if (default_remote_name) // did this already
 		return;
-	default_remote_name = xstrdup("origin");
 	current_branch = NULL;
 	head_ref = resolve_ref("HEAD", sha1, 0, &flag);
 	if (head_ref && (flag & REF_ISSYMREF) &&
@@ -300,6 +305,10 @@ static void read_config(void)
 			make_branch(head_ref + strlen("refs/heads/"), 0);
 	}
 	git_config(handle_config);
+	if (!default_remote_name) {
+		default_remote_name = core_origin ?
+		core_origin : xstrdup("origin");
+	}
 }
 
 struct refspec *parse_ref_spec(int nr_refspec, const char **refspec)
-- 
1.5.4.rc3.14.gc50f

[PATCH] git-remote - Unset core.origin when deleting the default remote

[Mark Levedahl]

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
 git-remote.perl |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/git-remote.perl b/git-remote.perl
index d13e4c1..75d2371 100755
--- a/git-remote.perl
+++ b/git-remote.perl
@@ -328,6 +328,11 @@ sub rm_remote {
 
 	$git->command('config', '--remove-section', "remote.$name");
 
+	my $defremote = $git->config("core.origin");
+	if (defined $defremote && $defremote eq $name) {
+	       $git->command("config", "--unset", "core.origin");
+	}
+
 	eval {
 	    my @trackers = $git->command('config', '--get-regexp',
 			'branch.*.remote', $name);
-- 
1.5.4.rc3.14.gc50f

[PATCH] git-clone - Set remotes.origin config variable

[Mark Levedahl]

This records the users choice of default remote name (by default "origin")
as given by the -o option.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
 Documentation/git-clone.txt |    3 ++-
 git-clone.sh                |    1 +
 2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index fdccbd4..6c15fa4 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -95,7 +95,8 @@ OPTIONS
 --origin <name>::
 -o <name>::
 	Instead of using the remote name 'origin' to keep track
-	of the upstream repository, use <name> instead.
+	of the upstream repository, use <name> instead. The name
+	is recorded in the core.origin config variable.
 
 --upload-pack <upload-pack>::
 -u <upload-pack>::
diff --git a/git-clone.sh b/git-clone.sh
index b4e858c..7208d68 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -242,6 +242,7 @@ fi &&
 export GIT_DIR &&
 GIT_CONFIG="$GIT_DIR/config" git-init $quiet ${template+"$template"} || usage
 
+git config core.origin $origin
 if test -n "$bare"
 then
 	GIT_CONFIG="$GIT_DIR/config" git config core.bare true
-- 
1.5.4.rc3.14.gc50f

[PATCH] git-submodule - Possibly inherit parent's default remote on init/clone

[Mark Levedahl]

For submodules defined relative to their parent, it is likely that the
parent's defined default remote is correct for the child as well. This
allows use of remote names other than "origin", important as managed
submodules are typically checked out on a detached head and therefore
submodule-update invokes git-fetch using the default remote. Without this
change, submodules effectively had to have a default remote of "origin."

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
 Documentation/git-submodule.txt |    8 +++++---
 git-submodule.sh                |   19 +++++++++++++------
 2 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index cffc6d4..440e234 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -36,9 +36,11 @@ status::
 
 init::
 	Initialize the submodules, i.e. register in .git/config each submodule
-	name and url found in .gitmodules. The key used in .git/config is
-	`submodule.$name.url`. This command does not alter existing information
-	in .git/config.
+	name and url found in .gitmodules, along with the default remote origin.
+	For submodules using a relative url, the default remote is inherited
+	from the parent project, for absolute urls the default "origin" is used.
+	The key used in .git/config is submodule.$name.url`. This command does
+	not alter existing information in .git/config.
 
 update::
 	Update the registered submodules, i.e. clone missing submodules and
diff --git a/git-submodule.sh b/git-submodule.sh
index ad9fe62..42be4b9 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -7,6 +7,7 @@
 USAGE='[--quiet] [--cached] [add <repo> [-b branch]|status|init|update] [--] [<path>...]'
 OPTIONS_SPEC=
 . git-sh-setup
+. git-parse-remote
 require_work_tree
 
 add=
@@ -43,9 +44,7 @@ get_repo_base() {
 # Resolve relative url by appending to parent's url
 resolve_relative_url ()
 {
-	branch="$(git symbolic-ref HEAD 2>/dev/null)"
-	remote="$(git config branch.${branch#refs/heads/}.remote)"
-	remote="${remote:-origin}"
+	remote="$(get_default_remote)"
 	remoteurl="$(git config remote.$remote.url)" ||
 		die "remote ($remote) does not have a url in .git/config"
 	url="$1"
@@ -95,6 +94,7 @@ module_clone()
 {
 	path=$1
 	url=$2
+	origin=${3:-origin}
 
 	# If there already is a directory at the submodule path,
 	# expect it to be empty (since that is the default checkout
@@ -110,7 +110,7 @@ module_clone()
 	test -e "$path" &&
 	die "A file already exist at path '$path'"
 
-	git-clone -n "$url" "$path" ||
+	git-clone -n -o "$origin" "$url" "$path" ||
 	die "Clone of '$url' into submodule path '$path' failed"
 }
 
@@ -130,9 +130,11 @@ module_add()
 		usage
 	fi
 
+	origin=origin
 	case "$repo" in
 	./*|../*)
 		# dereference source url relative to parent's url
+		origin=$(get_default_remote)
 		realrepo="$(resolve_relative_url $repo)" ;;
 	*)
 		# Turn the source into an absolute path if
@@ -157,7 +159,7 @@ module_add()
 	git ls-files --error-unmatch "$path" > /dev/null 2>&1 &&
 	die "'$path' already exists in the index"
 
-	module_clone "$path" "$realrepo" || exit
+	module_clone "$path" "$realrepo" "$origin" || exit
 	(unset GIT_DIR; cd "$path" && git checkout -q ${branch:+-b "$branch" "origin/$branch"}) ||
 	die "Unable to checkout submodule '$path'"
 	git add "$path" ||
@@ -189,12 +191,15 @@ modules_init()
 		die "No url found for submodule path '$path' in .gitmodules"
 
 		# Possibly a url relative to parent
+		origin=origin
 		case "$url" in
 		./*|../*)
 			url="$(resolve_relative_url "$url")"
+			origin=$(get_default_remote)
 			;;
 		esac
 
+		git config submodule."$name".origin "$origin" &&
 		git config submodule."$name".url "$url" ||
 		die "Failed to register url for submodule path '$path'"
 
@@ -222,10 +227,12 @@ modules_update()
 			say "Submodule path '$path' not initialized"
 			continue
 		fi
+		origin=$(git config submodule."$name".origin)
+		origin=${origin:-origin}
 
 		if ! test -d "$path"/.git
 		then
-			module_clone "$path" "$url" || exit
+			module_clone "$path" "$url" "$origin" || exit
 			subsha1=
 		else
 			subsha1=$(unset GIT_DIR; cd "$path" &&
-- 
1.5.4.rc3.14.gc50f

[PATCH] Teach git-submodule to use master's remote when updating subprojects

[Mark Levedahl]

Modules that are defined using relative urls to the master project are
assumed to be completely owned by the project. When running
"submodule update" from the top level, it is reasonable that the entire
project exists at the current master's remote. Using the
branch.$name.remote machinery, this remote can be different for each
branch and can be different than the current defaults in each submodule.

This teaches submodule to:

1) Possibly define the current master's remote in each submodule, using
the same relative url used by submodule init.
2) Fetch each submodule's updates from the master's remote.

Submodules defined using absolute urls (not relative to the parent) are
not touched by this logic. These modules are assumed to be independent
of the master project so submodule can do no better than to fetch from
their currently defined default remotes as already done.


Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
 git-submodule.sh |   20 +++++++++++++++++++-
 1 files changed, 19 insertions(+), 1 deletions(-)

diff --git a/git-submodule.sh b/git-submodule.sh
index 42be4b9..5b4b16f 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -209,11 +209,14 @@ modules_init()
 
 #
 # Update each submodule path to correct revision, using clone and checkout as needed
+# For owned submodules (defined using relative url), we use master project's remote
+# and define that in each submodule if not already there
 #
 # $@ = requested paths (default to all)
 #
 modules_update()
 {
+	master_remote=$(get_default_remote)
 	git ls-files --stage -- "$@" | grep -e '^160000 ' |
 	while read mode sha1 stage path
 	do
@@ -240,9 +243,24 @@ modules_update()
 			die "Unable to find current revision in submodule path '$path'"
 		fi
 
+		baseurl="$(GIT_CONFIG=.gitmodules git config submodule."$name".url)"
+		case "$baseurl" in
+		./*|../*)
+			fetch_remote=$master_remote
+			(unset GIT_DIR ; cd "$path" && git config remote."$fetch_remote".url > nul) ||
+			(
+				absurl="$(resolve_relative_url $baseurl)"
+				unset GIT_DIR; cd "$path" && git remote add "$master_remote" "$absurl"
+			) || die "Unable to define remote '$fetch_remote' in submodule path '$path'"
+			;;
+		*)
+			fetch_remote=
+			;;
+		esac
+
 		if test "$subsha1" != "$sha1"
 		then
-			(unset GIT_DIR; cd "$path" && git-fetch &&
+			(unset GIT_DIR; cd "$path" && git-fetch "$fetch_remote" &&
 				git-checkout -q "$sha1") ||
 			die "Unable to checkout '$sha1' in submodule path '$path'"
 
-- 
1.5.4.rc3.14.gc50f

Re: [PATCH] git-remote - Unset core.origin when deleting the default remote

[Jeff King]

On Sun, Jan 13, 2008 at 11:27:08AM -0500, Mark Levedahl wrote:

> --- a/git-remote.perl
> +++ b/git-remote.perl
> @@ -328,6 +328,11 @@ sub rm_remote {
>  
>  	$git->command('config', '--remove-section', "remote.$name");
>  
> +	my $defremote = $git->config("core.origin");
> +	if (defined $defremote && $defremote eq $name) {
> +	       $git->command("config", "--unset", "core.origin");
> +	}
> +

I'm not sure I see the use case that this helps. Presumably you are
doing one of (assuming your core.origin is 'foo'):

  - delete 'foo', and then proceed with usual git commands. In this
    case, your core.origin has reverted to 'origin', but what is the
    chance that you actually have such a remote (since you presumably
    cloned with -o foo)?

  - delete 'foo', then re-add 'foo'. I would expect this to be
    equivalent to editing the config, but as a side effect, your
    core.origin has mysteriously changed.

  - delete 'foo', then re-add 'bar' with the intent of making it your
    new origin. This doesn't help at all, since there's nothing
    automatically setting core.origin to 'bar', so you might as well
    leave it as the bogus 'foo' rather than the bogus 'origin'. And to
    help this use case, something like a "-d" flag to git-remote to set
    the new origin as the default might make sense. I.e.,

      git remote rm foo
      git remote add -d bar git://bar/project.git

    Alternatively, when adding a remote, if it is the _only_ remote (or
    perhaps if the current core.origin doesn't exist), we could set
    core.origin which would automagically cover the latter two cases.
    Although it feels a little too DWIM.

-Peff

Re: [PATCH] git-remote - Unset core.origin when deleting the default remote

[Mark Levedahl]

Jeff King wrote:
> On Sun, Jan 13, 2008 at 11:27:08AM -0500, Mark Levedahl wrote:
>
>   
>> --- a/git-remote.perl
>> +++ b/git-remote.perl
>> @@ -328,6 +328,11 @@ sub rm_remote {
>>  
>>  	$git->command('config', '--remove-section', "remote.$name");
>>  
>> +	my $defremote = $git->config("core.origin");
>> +	if (defined $defremote && $defremote eq $name) {
>> +	       $git->command("config", "--unset", "core.origin");
>> +	}
>> +
>>     
>
> I'm not sure I see the use case that this helps.
>   
Just being thorough: the man page claims that "git remote rm foo" 
removes all mention of remote foo.

>     Alternatively, when adding a remote, if it is the _only_ remote (or
>     perhaps if the current core.origin doesn't exist), we could set
>     core.origin which would automagically cover the latter two cases.
>     Although it feels a little too DWIM.
>
> -Peff
>   
I suspect anything done in this case is going to suffer from DWIM-itis 
in some conditions. I can't offer a better argument than the one above.

Mark

Re: [PATCH] git-remote - Unset core.origin when deleting the default remote

[Jeff King]

On Tue, Jan 15, 2008 at 12:02:45AM -0500, Mark Levedahl wrote:

>> I'm not sure I see the use case that this helps.
>>   
> Just being thorough: the man page claims that "git remote rm foo" removes 
> all mention of remote foo.

I was going to respond "by that rationale, 'git remote rm' should be
removing branch.*.remote keys that point to the removed remote". But
looking at the code, it already does that. So your change actually keeps
things consistent.

Not the choice I would have made, but I guess it just goes to show that
I use "vi" instead of "git remote". Consider my objection withdrawn.

-Peff

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Johannes Schindelin]

Hi,

On Sat, 12 Jan 2008, Junio C Hamano wrote:

> Mark Levedahl <mlevedahl@gmail.com> writes:
> 
> > Basically, I think an important (but not complete) test of the design
> > is that
> >
> >    git clone -o frotz git://frotz.foo.bar/myproject.git
> >    cd myproject
> >    git submodule init
> >    git submodule update
> >
> > work, with origin = frotz throughout the submodules, and with the
> > whole project correctly checked out even if the entire project was
> > rehosted onto a different server.
> 
> I like that.  This is a very good argument, especially because it 
> clarifies very well that the issue is not about "'submodule init' 
> misbehaves" but "fetch/pull/merge does not play well with clone -o".

FWIW I disagree.

I never understood why people want to complicate things by being able to 
name default _keys_ differently.  Why not letting "origin" being the 
default being pulled from, and be done with it?

Besides, I _really_ do not understand why we have such a discussion in rc 
phase.  There are _many_ more interesting discussions now that _also_ do 
not belong into a freeze phase.

Ciao,
Dscho

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> I never understood why people want to complicate things by being able to 
> name default _keys_ differently.  Why not letting "origin" being the 
> default being pulled from, and be done with it?

That happens to match my personal feeling.

HOWEVER.

We treat 'origin' in a special way when you do this:

	$ git clone somewhere new.git
        $ cd new.git
        $ git checkout HEAD^0
        $ git pull

And we already have "clone -o" and claim to support that option.
I think that it is very reasonable from the consistency point of
view to make sure that the following sequence treats 'frotz' the
same special way the above treats 'origin' specially:

	$ git clone -o frotz somewhere new.git
        $ cd new.git
        $ git checkout HEAD^0
        $ git pull

A purist alternative is to deprecate "git clone -o" and
eventually remove it.

Note that I was agreeing only with this specific aspect of the
argument.  I am not at all interested in getting involved in
refining or re-defining the existing submodule semantics this
late in the cycle before 1.5.4.  But I can very well see that
fixing this specific inconsistency can be separated out from the
rest of Mark's series and viewed as a set of trivially correct
fixes.

> Besides, I _really_ do not understand why we have such a
> discussion in rc phase.  There are _many_ more interesting
> discussions now that _also_ do not belong into a freeze phase.

Currently the ones I looked at and consider possible 1.5.4
material are http-push fixes from Grégoire Barbier and
parse_commit_buffer() tightening from Martin Koegler.

Recently I looked at the following patches and topics but I do
not think any of them belongs to 1.5.4.  None of them is obvious
and trivially correct fix to regressions or serious existing
bugs:

 * compress/decompress abstraction (Marco)

 * crlf (Steffen Prohaska and Dmitry Potapov)

 * whitespace error: "cr at eol is ok" (me)

 * various conflicting submodule changes(Ping Yin, Mark
   Levedahl, Imran M Yousuf)

 * unconfigured ident safety (Stephen Sinclair)

 * gitweb feed from commit to commitdiff (Florian La Rouche --
   Jakub seems to be on top of this so I am not worried about it
   too much).

 * color.ui (Matthias Kestenholz)

 * test scripts to use valgrind (Jeff King, but there was another
   one in the past -- can their efforts compared and coordinated
   better?).

 * various lstat(2) reduction changes (me).

 * pathname safety on insane filesystems (Linus, Robin
   Rosenberg, me).

(yes, some of the above list do not even have any code).

I am hoping that authors will resend the ones they really care
about after 1.5.4, as I do not want to take patches early.

Thanks.

safecrlf not in 1.5.4 (was Re: [PATCH] Teach remote machinery about remotes.default config variable)

[Steffen Prohaska]

On Jan 14, 2008, at 2:50 AM, Junio C Hamano wrote:

> Recently I looked at the following patches and topics but I do
> not think any of them belongs to 1.5.4.  None of them is obvious
> and trivially correct fix to regressions or serious existing
> bugs:
>
[...]


>  * crlf (Steffen Prohaska and Dmitry Potapov)

[...]


> I am hoping that authors will resend the ones they really care
> about after 1.5.4, as I do not want to take patches early.

Thanks for your update on this.  I agree with your opinion,
although I'd prefer to have the safecrlf option soon.

Without safecrlf I'll not enable core.autocrlf=true in msysgit.
Now that I see a reasonable way of having at least a warning
about potential data corruption when core.autocrlf=true, I'm
even stronger against enabling it without a safety valve.

As I pointed out in the recent CRLF discussion, I believe the
problem is not specific to Windows but is about a reasonable
default configuration for cross-platform projects.  CRLF
conversion must be enabled on all platforms to have good defaults
for a mixed Unix/Windows environment, and hence the safecrlf if
also needed on all platforms.

So I don't see much value in having the safecrlf only in msysgit
and not in official git.

Junio,
Do you see a chance to have safecrlf in 1.5.4.1?

I am currently considering wether it is worth following the maint
series of official git with msysgit.  That is we'd have a maint
branch in msysgit, which would merge from Junio's maint.
Although we're still in preview mode with msysgit I tend to
believe that this would be a good idea.

The preview tag is mostly due to the unspecified set of features
of msysgit, not that I think part of msysgit is not already very
stable and usable.  But msysgit only supports a subset of the
commands of official git and we don't really say or even know
which commands currently work reliably.  It could be worth to
compile such a list and only install the commands that we are
convinced of being ready for production.

	Steffen

Re: safecrlf not in 1.5.4

[Junio C Hamano]

Steffen Prohaska <prohaska-wjoc1KHpMeg@public.gmane.org> writes:

> Do you see a chance to have safecrlf in 1.5.4.1?

By definition of 'maint', 1.5.4.X are to fix bugs in the
features that are in 1.5.4, so the answer is no.

But we could end up having a short cycle for 1.5.5 if we agree
that the lack of crlf=safe is a severe bug that is worth fixing
post 1.5.4.

Currently I am not convinced that the lack of crlf=safe is a
severe and urgent bug worth "fixing" for 1.5.4.  I see it as a
new feature, a different variant of crlf behaviour we will be
introducing for audience who are not satisfied with existing the
crlf variants.

Re: safecrlf not in 1.5.4

[Steffen Prohaska]

On Jan 14, 2008, at 8:30 AM, Junio C Hamano wrote:

>
> Steffen Prohaska <prohaska-wjoc1KHpMeg@public.gmane.org> writes:
>
>> Do you see a chance to have safecrlf in 1.5.4.1?
>
> By definition of 'maint', 1.5.4.X are to fix bugs in the
> features that are in 1.5.4, so the answer is no.

I expected this answer.


> But we could end up having a short cycle for 1.5.5 if we agree
> that the lack of crlf=safe is a severe bug that is worth fixing
> post 1.5.4.
>
> Currently I am not convinced that the lack of crlf=safe is a
> severe and urgent bug worth "fixing" for 1.5.4.  I see it as a
> new feature, a different variant of crlf behaviour we will be
> introducing for audience who are not satisfied with existing the
> crlf variants.


So I should try harder to find better arguments.  But this has
time until the 1.5.4 release is out.  For now, I am being quiet.

(Well, I'll continue to improve the safecrlf patch and most
likely will send it to the list, too.  But I don't expect to find
it anywhere in your repo before 1.5.4.)

	Steffen

Re: [msysGit] Re: safecrlf not in 1.5.4

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> On Jan 14, 2008, at 8:30 AM, Junio C Hamano wrote:
>
>> By definition of 'maint', 1.5.4.X are to fix bugs in the
>> features that are in 1.5.4, so the answer is no.
>
> I expected this answer.

And it won't change.

>> But we could end up having a short cycle for 1.5.5 if we agree
>> that the lack of crlf=safe is a severe bug that is worth fixing
>> post 1.5.4.
> ...
> So I should try harder to find better arguments.  But this has
> time until the 1.5.4 release is out.  For now, I am being quiet.

Instead, you could be louder and convince people that it is a
severe bug worth fixing before 1.5.4, like Linus did with the
issue with performance regression on a partial commit.  It's
entirely your choice.

> (Well, I'll continue to improve the safecrlf patch and most
> likely will send it to the list, too...)

Please do.  "I am currently not convinced" does not mean "I am
always right" nor "I won't reconsider".

Re: safecrlf not in 1.5.4

[Dmitry Potapov]

On Sun, Jan 13, 2008 at 11:30:51PM -0800, Junio C Hamano wrote:
> 
> But we could end up having a short cycle for 1.5.5 if we agree
> that the lack of crlf=safe is a severe bug that is worth fixing
> post 1.5.4.

Hopefully, the cycle for 1.5.5 will be a bit shorter than 1.5.4, because
1.5.4 seems to have the longest development cycle of all versions, and
it already contains almost as much changes as three previous versions
("git diff v1.5.3 master" is almost as big as "git diff v1.5.0 v1.5.3").

Dmitry

Re: safecrlf not in 1.5.4

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

On Mon, Jan 14, 2008 at 09:04:56AM +0000, Dmitry Potapov wrote:
> On Sun, Jan 13, 2008 at 11:30:51PM -0800, Junio C Hamano wrote:
> > 
> > But we could end up having a short cycle for 1.5.5 if we agree
> > that the lack of crlf=safe is a severe bug that is worth fixing
> > post 1.5.4.
> 
> Hopefully, the cycle for 1.5.5 will be a bit shorter than 1.5.4, because
> 1.5.4 seems to have the longest development cycle of all versions, and
> it already contains almost as much changes as three previous versions
> ("git diff v1.5.3 master" is almost as big as "git diff v1.5.0 v1.5.3").

  hehe, though we still do not have Megabytes of changes between two RCs
yet ;)

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Johannes Schindelin]

Hi,

On Sun, 13 Jan 2008, Junio C Hamano wrote:

> And we already have "clone -o" and claim to support that option.

My understanding was _always_ that the "-o" option was meant for the case 
that you want to clone from somewhere else than where you want to pull 
from.  Something like an initial clone from a USB disk.

>  * test scripts to use valgrind (Jeff King, but there was another
>    one in the past -- can their efforts compared and coordinated
>    better?).

Yes, that was written in Perl by Christian Couder:

http://article.gmane.org/gmane.comp.version-control.git/69236

Peff's version does not need Perl, and is better integrated with the 
testsuite (via the new option -m).  Christian's version parses the output, 
and might therefore be nicer to look at.

However, I think that both versions do not account for scripts, and I 
imagine that going through Git.pm and git-sh-setup is necessary for that.

Also, it might be a good idea to be able to provide extra arguments, such 
as "--attach-db=yes".

Post 1.5.4, definitely.

Ciao,
Dscho

valgrind test scripts (was Re: [PATCH] Teach remote...)

[Jeff King]

On Mon, Jan 14, 2008 at 12:18:13PM +0100, Johannes Schindelin wrote:

> >  * test scripts to use valgrind (Jeff King, but there was another
> >    one in the past -- can their efforts compared and coordinated
> >    better?).
> 
> Yes, that was written in Perl by Christian Couder:
> 
> http://article.gmane.org/gmane.comp.version-control.git/69236
> 
> Peff's version does not need Perl, and is better integrated with the 
> testsuite (via the new option -m).  Christian's version parses the output, 
> and might therefore be nicer to look at.

I don't think parsing is necessary. Christian's version counts the
errors, whereas I just barf if valgrind has mentioned any errors. And
using the '-q' output of valgrind means the output is fairly cleaned up.

But of course the main difference is that I tried to integrate into the
test scripts, and stop running as soon as any errors are found.

> However, I think that both versions do not account for scripts, and I 
> imagine that going through Git.pm and git-sh-setup is necessary for that.

Both versions use the 'alias' approach. A more comprehensive approach
would be something like:

  mkdir wrapper-bin
  cat >wrapper-bin/git <<EOF
  ...
  EOF
  chmod 755 wrapper-bin/git
  for i in $GIT_PROGRAMS; do
    ln -s git wrapper-bin/git-$i
  done
  PATH=$PWD/wrapper-bin:$PATH

which should get all git calls (though we should probably not wrap
"git-foo" if git-foo is a script (or we should convert it to "git
foo") since I have no desire to valgrind bash or perl).

> Also, it might be a good idea to be able to provide extra arguments, such 
> as "--attach-db=yes".

Yes. I suspect some people will need to add custom suppression files
depending on their platform, as well.

> Post 1.5.4, definitely.

Agreed.

-Peff

What's not in 'master' but should be

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Currently the ones I looked at and consider possible 1.5.4
> material are http-push fixes from Grégoire Barbier and
> parse_commit_buffer() tightening from Martin Koegler.

It seems that for the past few days, people were having too much
fun bashing how broken MacOS X is, and the real work has stalled
in the meantime.  Well, not really stalled but they certainly
made the patches and discussions harder to find in the list
archive.

But that's Ok.  You cannot win every battle.

Now the lack of unsetenv can be autodetected, and coloring
breakage of --color-words has been fixed.  We have also managed
to catch a real breakage in fast-import, but somebody seems to
have managed to bash OS X even in that thread ;-)

But there are still unapplied patches that deserve attention.
The one that I am most worried about is Grégoire Barbier's
http-push changes:

  $gmane/70406 <1200250979-19604-1-git-send-email-gb@gbarbier.org>
  $gmane/70407 <1200250979-19604-2-git-send-email-gb@gbarbier.org>
  $gmane/70405 <1200250979-19604-3-git-send-email-gb@gbarbier.org>

They look sensible on paper. I do not, however, use http-push
myself, and I'd really like an independent success (or failure)
reports on them.  I can also threaten to apply them and see if
it breaks for anybody, which I may end up doing.

Martin Koegler's parse_commit_buffer() tightening is much easier:

  $gname/70478 <12003456313661-git-send-email-mkoegler@auto.tuwien.ac.at>

It needs a proper commit message; the patch itself is good.  I
could write one myself but I'd rather want description from the
real contributor.

  gmane = http://news.gmane.org/gmane.comp.version-control.git

Re: What's not in 'master' but should be

[Lars Hjemli]

On Jan 18, 2008 10:41 AM, Junio C Hamano <gitster@pobox.com> wrote:
> It seems that for the past few days, people were having too much
> fun bashing how broken MacOS X is, and the real work has stalled
> in the meantime.  Well, not really stalled but they certainly
> made the patches and discussions harder to find in the list
> archive.

Here's a patch which might have been lost in the noise:

http://thread.gmane.org/gmane.comp.version-control.git/70463

--
larsh

Re: What's not in 'master' but should be

[Junio C Hamano]

"Lars Hjemli" <hjemli@gmail.com> writes:

> On Jan 18, 2008 10:41 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> It seems that for the past few days, people were having too much
>> fun bashing how broken MacOS X is, and the real work has stalled
>> in the meantime.  Well, not really stalled but they certainly
>> made the patches and discussions harder to find in the list
>> archive.
>
> Here's a patch which might have been lost in the noise:
>
> http://thread.gmane.org/gmane.comp.version-control.git/70463

Not really.  It came late into rc cycle without fixing any
breakage.  Not 1.5.4 material.

Re: What's not in 'master' but should be

[Lars Hjemli]

On Jan 18, 2008 11:24 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> "Lars Hjemli" <hjemli@gmail.com> writes:
>
> > Here's a patch which might have been lost in the noise:
> >
> > http://thread.gmane.org/gmane.comp.version-control.git/70463
>
> Not really.  It came late into rc cycle without fixing any
> breakage.  Not 1.5.4 material.

Hmm, isn't a nonfunctional libgit considered breakage? Without
something like this patch it is no longer possible to use
write_tar_archive()/write_zip_archive() in libgit.a.

--
larsh

Re: What's not in 'master' but should be

[Junio C Hamano]

"Lars Hjemli" <hjemli@gmail.com> writes:

> Hmm, isn't a nonfunctional libgit considered breakage? Without
> something like this patch it is no longer possible to use
> write_tar_archive()/write_zip_archive() in libgit.a.

Sorry, but libgit.a is not part of what we deliver.  We do not
support linking random stuff against libgit.a.  We never did.
It is not a "library".

It has always been just an implementation detail for us to be
lax about our Makefile, so that we do not have to write down
exactly which *.o files git-foo command depended upon (and it is
ceasing to be useful for that as very many things have moved to
"the single git binary" these days).  Instead we let the linker
pick out the necessary pieces out of the archive.

So, no, there is no breakage.

The code movement you did _should_ not hurt so it may be a fine
material for post 1.5.4, but I haven't carefully compared what
other change might have accidentally snuck in that patch, and I
would rather not have to during the rc cycle.

Re: What's not in 'master' but should be

[Lars Hjemli]

On Jan 18, 2008 12:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Lars Hjemli" <hjemli@gmail.com> writes:
>
> > Hmm, isn't a nonfunctional libgit considered breakage? Without
> > something like this patch it is no longer possible to use
> > write_tar_archive()/write_zip_archive() in libgit.a.
>
> Sorry, but libgit.a is not part of what we deliver.  We do not
> support linking random stuff against libgit.a.  We never did.
> It is not a "library".

I kind of expected this reply, and I know libgit isn't supposed to be
a stable API aginst git internals, but it still feels like a
regression: cgit has been linking against libgit for over a year now
(initial snapshot support added feb 8, 2007), and git-1.5.4 looks like
the first git release which cgit cannot use.

> The code movement you did _should_ not hurt so it may be a fine
> material for post 1.5.4, but I haven't carefully compared what
> other change might have accidentally snuck in that patch, and I
> would rather not have to during the rc cycle.

Ok, I can't argue with that.

But could the patch then be part of 1.5.4.X or would I have to wait
for 1.5.5 since it's not considered to fix any breakage in 1.5.4? The
reason I'm asking is that cgit relies on offical git releases (or
rather, the tarballs published on kernel.org when a release is cut),
and it would be a shame if the 1.5.4-series becomes unusable for me
(there's always the possibility to link against a forked git, but I'd
rather not).

-- 
larsh

Re: What's not in 'master' but should be

[Johannes Schindelin]

Hi,

On Fri, 18 Jan 2008, Lars Hjemli wrote:

> On Jan 18, 2008 12:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > "Lars Hjemli" <hjemli@gmail.com> writes:
> >
> > > Hmm, isn't a nonfunctional libgit considered breakage? Without 
> > > something like this patch it is no longer possible to use 
> > > write_tar_archive()/write_zip_archive() in libgit.a.
> >
> > Sorry, but libgit.a is not part of what we deliver.  We do not support 
> > linking random stuff against libgit.a.  We never did. It is not a 
> > "library".
> 
> I kind of expected this reply, and I know libgit isn't supposed to be a 
> stable API aginst git internals, but it still feels like a regression: 
> cgit has been linking against libgit for over a year now (initial 
> snapshot support added feb 8, 2007), and git-1.5.4 looks like the first 
> git release which cgit cannot use.

So you did something that is unsupported, and now it breaks for you.

I'd almost say: you should have expected that.  HOWEVER, this makes you 
the perfect guy to actually do something about libification (which has 
been on my mind for some time, with the prospect of GitCheetah), and 
therefore you deserve a little help, IMHO.

> > The code movement you did _should_ not hurt so it may be a fine 
> > material for post 1.5.4, but I haven't carefully compared what other 
> > change might have accidentally snuck in that patch, and I would rather 
> > not have to during the rc cycle.

I have.  The 80 lines that were removed are _exactly_ the 80 lines that 
were added (prepended with some #includes).

Like Lars said, the prototype of the only non-static function, 
sha1_file_to_archive(), was in archive.h, which is included from 
builtin-archive.c (where the big hunk was moved from), so there is no 
possibility of a breakage there.

It is no _functional_ change, but if Lars _uses_ the function in cgit, I'd 
say it would be a "courtesy fix" before 1.5.4.

Mind you, I would not propose to make libgit.a fully functional as a 
standalone library before 1.5.4.

But Lars contributed a lot, and did a very good job of collecting git 
patches back in October.  Therefore I think that he deserves a little 
extra attention, even if it does not fix a bug in git proper.

Ciao,
Dscho

Re: What's not in 'master' but should be

[Lars Hjemli]

On Jan 18, 2008 1:34 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> So you did something that is unsupported, and now it breaks for you.
>
> I'd almost say: you should have expected that.

Yeah, it was bound to happen. The sad thing is that I didn't notice
earlier; I should probably add a test branch to cgit and run something
like this in a cron-job:

git checkout test && git fetch && git reset --hard origin/master &&
(cd git && git fetch && git reset --hard origin/master) &&
make clean &&
make test &&
git commit -a -m "Updated to latest git" &&
git push --force origin test

This should help catching this kind of "breakage" a lot earlier.

> [snip]

Thanks for the review and the kind words!

-- 
larsh

Re: What's not in 'master' but should be

[Junio C Hamano]

"Lars Hjemli" <hjemli@gmail.com> writes:

> On Jan 18, 2008 12:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> "Lars Hjemli" <hjemli@gmail.com> writes:
>>
>> > Hmm, isn't a nonfunctional libgit considered breakage? Without
>> > something like this patch it is no longer possible to use
>> > write_tar_archive()/write_zip_archive() in libgit.a.
>>
>> Sorry, but libgit.a is not part of what we deliver.  We do not
>> support linking random stuff against libgit.a.  We never did.
>> It is not a "library".
>
> I kind of expected this reply, and I know libgit isn't supposed to be
> a stable API aginst git internals, but it still feels like a
> regression: cgit has been linking against libgit for over a year now
> (initial snapshot support added feb 8, 2007), and git-1.5.4 looks like
> the first git release which cgit cannot use.

If you expected it, you should have added the above four and
half lines in the initial message.  cgit is something even I
have heard of, and breakage of it because of what we have is
worth taking into consideration.  It would have been nicer if
this came before -rc0.

>> The code movement you did _should_ not hurt so it may be a fine
>> material for post 1.5.4, but I haven't carefully compared what
>> other change might have accidentally snuck in that patch, and I
>> would rather not have to during the rc cycle.
>
> Ok, I can't argue with that.

Instead of wasting more time in the exchange in this thread, I
spent a several uninterrupted minutes' attention to read over
your patch to make sure there is no accidental slippage (with
help from Dscho as well).  I'll make an exception and will
apply.

Thanks for the patch.

What's not in 'master', and likely not to be until 1.5.4

[Junio C Hamano]

Here is an update to the list I sent earlier.  Topics that I
thought may deserve attention, discussion and eventual inclusion
but are not 1.5.4 material.

I think some of them actually have a slight chance of being
1.5.4 material, if interested parties present good enough
arguments that they are actually good and safe bugfixes.

 * compress/decompress abstraction (Marco)

 * crlf (Steffen Prohaska and Dmitry Potapov)

 * whitespace error: "cr at eol is ok" (me)

 * moving archive related helpers to libgit.a (Lars Hjemli)

 * marking output from "diff --{no,src,dst}-prefix" as a non-git
   diff (me)

 * submodule subcommand parser fix for "git submodule add init
   update" (Imran M Yousuf and me)

 * submodule recursive wrapper (Imran M Yousuf)

 * 'origin' is not so special after "clone -o frotz" (Mark Levedahl)

 * "submodule summary" (Ping Yin)

 * unconfigured ident safety (Stephen Sinclair)

 * gitweb feed from commit to commitdiff (Florian La Rouche --
   Jakub seems to be on top of this so I am not worried about it
   too much).

 * color.ui (Matthias Kestenholz)

 * test scripts to use valgrind (Jeff King)

 * various lstat(2) reduction changes (me).

 * "rebase -i" UI -- should it be simplified to do commit --amend
   itself? (Dscho)

 * "cherry-pick/revert" error message fix (Björn Steinbrink and me)

 * pathname safety on filesystems whose readdir(3) thinks it
   knows better than users (Linus, Robin Rosenberg, me and
   others).

Again, I am hoping that authors will resend the ones they really
care about after 1.5.4, as I do not want to take patches early.

Re: What's not in 'master', and likely not to be until 1.5.4

[Johannes Sixt]

Junio C Hamano schrieb:
> Here is an update to the list I sent earlier.  Topics that I
> thought may deserve attention, discussion and eventual inclusion
> but are not 1.5.4 material.

BTW, how would you like to have a 40+ patch series presented that
implements the port to MinGW? Should I send to the ML despite its volume?
(Of course not before 1.5.4 is released.)

The current state of the series is available here:
http://repo.or.cz/w/git/mingw/j6t.git?a=shortlog;h=upstream

-- Hannes

Re: What's not in 'master', and likely not to be until 1.5.4

[Junio C Hamano]

Johannes Sixt <j.sixt@viscovery.net> writes:

> BTW, how would you like to have a 40+ patch series presented that
> implements the port to MinGW? Should I send to the ML despite its volume?

My gut feeling is that you did your usual great job separating
them into logical chunks and it will be a pleasure to review on
the usual channel, just like the trickle you did earlier.

> The current state of the series is available here:
> http://repo.or.cz/w/git/mingw/j6t.git?a=shortlog;h=upstream

Let me take a look sometime (but I cannot even say when right
now).  I might change my mind about the above.

Re: What's not in 'master', and likely not to be until 1.5.4

[Steffen Prohaska]

On Jan 18, 2008, at 12:40 PM, Junio C Hamano wrote:

> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> BTW, how would you like to have a 40+ patch series presented that
>> implements the port to MinGW? Should I send to the ML despite its  
>> volume?
>
> My gut feeling is that you did your usual great job separating
> them into logical chunks and it will be a pleasure to review on
> the usual channel, just like the trickle you did earlier.
>
>> The current state of the series is available here:
>> http://repo.or.cz/w/git/mingw/j6t.git?a=shortlog;h=upstream
>
> Let me take a look sometime (but I cannot even say when right
> now).  I might change my mind about the above.

I have one or two patches that could be added, most notably
the gpg/CRLF patch.  Maybe we should discuss them before the
whole series is proposed for git.git?  Maybe not; then I'd
send my patches to the list after Junio applied your series.

	Steffen

Re: What's not in 'master', and likely not to be until 1.5.4

[Johannes Schindelin]

Hi,

On Fri, 18 Jan 2008, Steffen Prohaska wrote:

> On Jan 18, 2008, at 12:40 PM, Junio C Hamano wrote:
> 
> > Johannes Sixt <j.sixt@viscovery.net> writes:
> > 
> > > BTW, how would you like to have a 40+ patch series presented that 
> > > implements the port to MinGW? Should I send to the ML despite its 
> > > volume?
> > 
> > My gut feeling is that you did your usual great job separating them 
> > into logical chunks and it will be a pleasure to review on the usual 
> > channel, just like the trickle you did earlier.
> > 
> > > The current state of the series is available here: 
> > > http://repo.or.cz/w/git/mingw/j6t.git?a=shortlog;h=upstream
> > 
> > Let me take a look sometime (but I cannot even say when right now).  
> > I might change my mind about the above.
> 
> I have one or two patches that could be added, most notably the gpg/CRLF 
> patch.  Maybe we should discuss them before the whole series is proposed 
> for git.git?  Maybe not; then I'd send my patches to the list after 
> Junio applied your series.

I think it is long enough as it is.  My plan is to look at the 40+ 
patches, and try to find a sensible subgrouping so that they can be sent 
in bite-sized chunks.

Ciao,
Dscho

Re: What's not in 'master', and likely not to be until 1.5.4

[Johannes Schindelin]

Hi,

On Fri, 18 Jan 2008, Johannes Sixt wrote:

> Junio C Hamano schrieb:
> > Here is an update to the list I sent earlier.  Topics that I
> > thought may deserve attention, discussion and eventual inclusion
> > but are not 1.5.4 material.
> 
> BTW, how would you like to have a 40+ patch series presented that
> implements the port to MinGW? Should I send to the ML despite its volume?
> (Of course not before 1.5.4 is released.)
> 
> The current state of the series is available here:
> http://repo.or.cz/w/git/mingw/j6t.git?a=shortlog;h=upstream

Comments from reading the patches briefly (since there are 42 patches, it 
needs quite some time to even do it briefly):

- Possibly some of these commits could be folded back into
  f90524e(Add target architecture MinGW):

  96a27f1(MinGW: Implement gettimeofday()),
  2e05f891(Implement a rudimentary poll() emulation for Windows),
  142bda0(Fake implementions of getpwuid(), getuid(), and getpwnam() for 
	  Windows),
  e799caf(Implement setitimer() and sigaction()),
  075fee7(Implement a wrapper of execve that can invoke shell scripts),
  495f0af(Work around misbehaved rename() on Windows),
  34cf7fd(Implement a pipe() replacement whose ends are not inherited to 
	  children),
  4504323(Implement start_command() for Windows),
  b8e84a6(Implement a work-around for a misbehaved vsnprintf on Windows),
  08bbcb4(Windows: always chmod(, 0666) before unlink()),
  f6bbf12(Windows: Implement a wrapper of the open() function),
  56cedf3(Windows: Fix PRIuMAX definition),
  7458a97(Windows: Implement wrappers for gethostbyname(), socket(), and 
	  connect()),
  ef25947(Windows: Fix ntohl() related warnings about printf formatting),
  b9db7ad(Windows: Implement a custom spawnve()), and
  47dacb3(compat/pread.c: Add foward decl to fix warning)

- 142bda0(Fake implementions of getpwuid(), getuid(), and getpwnam() for 
	  Windows)
  does not really implement getuid() and getpwnam(), and does not "fake" 
  the implementation of getpwuid() either, but has a minimal 
  implementation of it (affecting the other two functions, of course).

- d6596ed(gitk: Disable msgfmt on MinGW) and
  004fb4b(Fix renaming .gitk-new to .gitk on Windows if there is already a 
	  .gitk)
  are gitk patches.

  Further, I think that d6596ed would be better done as an automatic 
  detection of msgfmt's presence; on my Eee PC, there is no msgfmt 
  either...

- 20fd16e(Windows: Use a customized struct stat that also has the 
	  st_blocks member) should be folded into
  6f97065(Add a new lstat and fstat implementation based on Win32 API)
  (with a comment that you customized the struct stat, too)

  But then, without 20fd16e, git does not compile, so again I would rather
  fold that back into the MinGW commit.

- I would group the following path related commits:

  f15879a(MSYS: local clone must use the drive letter in absolute paths),
  788324d(Handle Windows style absolute paths in 
	  safe_create_leading_directories( )),
  851d28d(Treat Windows style path names),
  8b9ce70(On Windows use the Windows style PATH separator in add_path()),
  8811d9c(On Windows strip ".exe" from the program name),
  af7a879(Windows: Disambiguate DOS style paths from SSH URLs),

  71911a8(Windows: TMP and TEMP environment variables specify a temporary 
	  directory),

  ea035ed(Turn builtin_exec_path into a function.)
  4e7e438(Compute the ultimate fallback for exec_path from the program 
	  invocation),

  abd87b3(Windows: Use a relative default template_dir and ETC_GITCONFIG),
  7162bf5(When installing, be prepared that template_dir may be relative).

  The latter two probably want to be merged, too.

- in git.git, the onelines are not terminated by "."

- in f6bbf12(Windows: Implement a wrapper of the open() function) there is 
  a typo: "on^".

- 47dacb3(compat/pread.c: Add foward decl to fix warning) has a typo:
  "foward".

- The SOB line does not come last in 075fee7(Implement a wrapper of execve 
  that can invoke shell scripts.)

- I'd prefer f90524e(Add target architecture MinGW) to come last.  
  Alternatively, you could cut out the Makefile change so that the series 
  is still bisectable: MinGW will just not be supported until the very 
  end.

Implementation-wise I could not go into too much depth, naturally, but one 
thing still struck me as odd:

	$ git grep __MINGW j6t/upstream

comes up with 26 hits.

The first of them: cache.h:381, function is_absolute_path().  That just 
cries out loud to be "#ifdef DOS_STYLE_PATHS" instead of "#ifdef 
__MINGW32__".

I guess there should also be -DHAS_NO_FORK_BUT_THREADS -DHAS_TMP_AND_TEMP 
-DHAS_WINSOCK2, but most of them look like -DDOS_STYLE_PATHS to me.

Uff.  That were quite some things to wade through, and it's only to get 
worse when I start for real ;-)

Ciao,
Dscho

Re: What's not in 'master', and likely not to be until 1.5.4

[Johannes Schindelin]

Hi,

On Fri, 18 Jan 2008, Johannes Schindelin wrote:

> - d6596ed(gitk: Disable msgfmt on MinGW) and
>   004fb4b(Fix renaming .gitk-new to .gitk on Windows if there is already a 
> 	  .gitk)
>   are gitk patches.
> 
>   Further, I think that d6596ed would be better done as an automatic 
>   detection of msgfmt's presence; on my Eee PC, there is no msgfmt 
>   either...

IOW I think something like this:

-- snipsnap --
[PATCH] Fall back to po2msg when msgfmt is unavailable

At least on my Eee PC I do not have msgfmt.

This should be split into two patches, one for git-gui and one for gitk.
---
 git-gui/Makefile  |    6 ++++--
 gitk-git/Makefile |    7 +++++--
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/git-gui/Makefile b/git-gui/Makefile
index c109eab..c7921e7 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -193,8 +193,9 @@ $(GITGUI_MAIN): git-gui.sh GIT-VERSION-FILE GIT-GUI-VARS
 	mv $@+ $@
 
 XGETTEXT   ?= xgettext
+PO2MSG = $(TCL_PATH) po/po2msg.sh
 ifdef NO_MSGFMT
-	MSGFMT ?= $(TCL_PATH) po/po2msg.sh
+	MSGFMT ?= $(PO2MSG)
 else
 	MSGFMT ?= msgfmt
 endif
@@ -210,7 +211,8 @@ $(PO_TEMPLATE): $(SCRIPT_SH) $(ALL_LIBFILES)
 update-po:: $(PO_TEMPLATE)
 	$(foreach p, $(ALL_POFILES), echo Updating $p ; msgmerge -U $p $(PO_TEMPLATE) ; )
 $(ALL_MSGFILES): %.msg : %.po
-	$(QUIET_MSGFMT0)$(MSGFMT) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< $(QUIET_MSGFMT1)
+	$(QUIET_MSGFMT0)$(MSGFMT) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< $(QUIET_MSGFMT1) || \
+	$(QUIET_MSGFMT0)$(PO2MSG) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< $(QUIET_MSGFMT1)
 
 lib/tclIndex: $(ALL_LIBFILES) GIT-GUI-VARS
 	$(QUIET_INDEX)if echo \
diff --git a/gitk-git/Makefile b/gitk-git/Makefile
index ae2b80b..669ab0e 100644
--- a/gitk-git/Makefile
+++ b/gitk-git/Makefile
@@ -8,6 +8,7 @@ gitk_libdir   ?= $(sharedir)/gitk/lib
 msgsdir    ?= $(gitk_libdir)/msgs
 msgsdir_SQ  = $(subst ','\'',$(msgsdir))
 
+TCL_PATH ?= tclsh
 TCLTK_PATH ?= wish
 INSTALL ?= install
 RM ?= rm -f
@@ -18,8 +19,9 @@ TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
 
 ## po-file creation rules
 XGETTEXT   ?= xgettext
+PO2MSG = $(TCL_PATH) po/po2msg.sh
 ifdef NO_MSGFMT
-	MSGFMT ?= $(TCL_PATH) po/po2msg.sh
+	MSGFMT ?= $(PO2MSG)
 else
 	MSGFMT ?= msgfmt
 endif
@@ -59,5 +61,6 @@ update-po:: $(PO_TEMPLATE)
 	$(foreach p, $(ALL_POFILES), echo Updating $p ; msgmerge -U $p $(PO_TEMPLATE) ; )
 $(ALL_MSGFILES): %.msg : %.po
 	@echo Generating catalog $@
-	$(MSGFMT) --statistics --tcl $< -l $(basename $(notdir $<)) -d $(dir $@)
+	$(MSGFMT) --statistics --tcl $< -l $(basename $(notdir $<)) -d $(dir $@) || \
+	$(PO2MSG) --statistics --tcl $< -l $(basename $(notdir $<)) -d $(dir $@)
 
-- 
1.5.4.rc3.30.g1de144

Re: What's not in 'master', and likely not to be until 1.5.4

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> [PATCH] Fall back to po2msg when msgfmt is unavailable
> 
> diff --git a/git-gui/Makefile b/git-gui/Makefile
> index c109eab..c7921e7 100644
> --- a/git-gui/Makefile
> +++ b/git-gui/Makefile
> @@ -210,7 +211,8 @@ $(PO_TEMPLATE): $(SCRIPT_SH) $(ALL_LIBFILES)
>  update-po:: $(PO_TEMPLATE)
>  	$(foreach p, $(ALL_POFILES), echo Updating $p ; msgmerge -U $p $(PO_TEMPLATE) ; )
>  $(ALL_MSGFILES): %.msg : %.po
> -	$(QUIET_MSGFMT0)$(MSGFMT) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< $(QUIET_MSGFMT1)
> +	$(QUIET_MSGFMT0)$(MSGFMT) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< $(QUIET_MSGFMT1) || \
> +	$(QUIET_MSGFMT0)$(PO2MSG) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< $(QUIET_MSGFMT1)

That will cause the QUIET_MSGFMT0 script to echo twice; once
when we try to run msgfmt and again when we fallback to po2msg.

That messes with the user's display and won't look very nice coming
out of a supposedly quiet make.

In other words this is probably better:

+	$(QUIET_MSGFMT0)($(MSGFMT) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< || \
+	$(PO2MSG) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< )$(QUIET_MSGFMT1)

But it is a lot uglier to read, and I tend to not like subshells.

-- 
Shawn.

Re: What's not in 'master', and likely not to be until 1.5.4

[Johannes Schindelin]

Hi,

On Sun, 20 Jan 2008, Shawn O. Pearce wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > [PATCH] Fall back to po2msg when msgfmt is unavailable
> > 
> > diff --git a/git-gui/Makefile b/git-gui/Makefile
> > index c109eab..c7921e7 100644
> > --- a/git-gui/Makefile
> > +++ b/git-gui/Makefile
> > @@ -210,7 +211,8 @@ $(PO_TEMPLATE): $(SCRIPT_SH) $(ALL_LIBFILES)
> >  update-po:: $(PO_TEMPLATE)
> >  	$(foreach p, $(ALL_POFILES), echo Updating $p ; msgmerge -U $p $(PO_TEMPLATE) ; )
> >  $(ALL_MSGFILES): %.msg : %.po
> > -	$(QUIET_MSGFMT0)$(MSGFMT) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< $(QUIET_MSGFMT1)
> > +	$(QUIET_MSGFMT0)$(MSGFMT) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< $(QUIET_MSGFMT1) || \
> > +	$(QUIET_MSGFMT0)$(PO2MSG) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< $(QUIET_MSGFMT1)
> 
> That will cause the QUIET_MSGFMT0 script to echo twice; once when we try 
> to run msgfmt and again when we fallback to po2msg.
> 
> That messes with the user's display and won't look very nice coming out 
> of a supposedly quiet make.
> 
> In other words this is probably better:
> 
> +	$(QUIET_MSGFMT0)($(MSGFMT) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< || \
> +	$(PO2MSG) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< )$(QUIET_MSGFMT1)
> 
> But it is a lot uglier to read, and I tend to not like subshells.

It was exactly this ugliness which made me not do it.

Note: There might be yet a better way.  Instead of trying each and every 
time, we could detect the presence of msgfmt with something like this:

+ifeq $(shell msgfmt2 2>/dev/null >/dev/null; echo $?) = 127
+	MSGFMT = $(TCL_PATH) po/po2msg.sh
+endif

This is not tested, yet, tough,

Ciao,
Dscho

Re: What's not in 'master', and likely not to be until 1.5.4

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Note: There might be yet a better way.  Instead of trying each and every 
> time, we could detect the presence of msgfmt with something like this:
> 
> +ifeq $(shell msgfmt2 2>/dev/null >/dev/null; echo $?) = 127
> +	MSGFMT = $(TCL_PATH) po/po2msg.sh
> +endif

I like it.  I'm applying this diff (which I tested) to git-gui:

diff --git a/Makefile b/Makefile
index 1baf4b0..5f1023e 100644
--- a/Makefile
+++ b/Makefile
@@ -198,6 +198,9 @@ ifdef NO_MSGFMT
 	MSGFMT ?= $(TCL_PATH) po/po2msg.sh
 else
 	MSGFMT ?= msgfmt
+	ifeq ($(shell $(MSGFMT) >/dev/null 2>&1 || echo $$?),127)
+		MSGFMT := $(TCL_PATH) po/po2msg.sh
+	endif
 endif
 
 msgsdir     = $(gg_libdir)/msgs

-- 
Shawn.

Re: What's not in 'master', and likely not to be until 1.5.4

[Johannes Schindelin]

Hi,

On Tue, 22 Jan 2008, Shawn O. Pearce wrote:

> diff --git a/Makefile b/Makefile
> index 1baf4b0..5f1023e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -198,6 +198,9 @@ ifdef NO_MSGFMT
>  	MSGFMT ?= $(TCL_PATH) po/po2msg.sh
>  else
>  	MSGFMT ?= msgfmt
> +	ifeq ($(shell $(MSGFMT) >/dev/null 2>&1 || echo $$?),127)
> +		MSGFMT := $(TCL_PATH) po/po2msg.sh
> +	endif
>  endif
>  
>  msgsdir     = $(gg_libdir)/msgs
> 

Thanks!

Paul, you might want to do something like that for gitk, too.  I imagine 
that the diff even applies as-is...

Ciao,
Dscho

Re: What's not in 'master', and likely not to be until 1.5.4

[Johannes Sixt]

[Don't have Cc: in KNode. oh well...]

Johannes Schindelin wrote:
> On Fri, 18 Jan 2008, Johannes Sixt wrote:
>> BTW, how would you like to have a 40+ patch series presented that
>> implements the port to MinGW? Should I send to the ML despite its volume?
>> (Of course not before 1.5.4 is released.)
>> 
>> The current state of the series is available here:
>> http://repo.or.cz/w/git/mingw/j6t.git?a=shortlog;h=upstream
> 
> Comments from reading the patches briefly (since there are 42 patches, it
> needs quite some time to even do it briefly):

Thanks a lot!

I agree with everything I didn't quote from your message.

> - Possibly some of these commits could be folded back into
>   f90524e(Add target architecture MinGW):
> 
>   96a27f1(MinGW: Implement gettimeofday()),
>   2e05f891(Implement a rudimentary poll() emulation for Windows),
>   142bda0(Fake implementions of getpwuid(), getuid(), and getpwnam() for
> Windows),
>   e799caf(Implement setitimer() and sigaction()),
>   075fee7(Implement a wrapper of execve that can invoke shell scripts),
>   495f0af(Work around misbehaved rename() on Windows),
>   34cf7fd(Implement a pipe() replacement whose ends are not inherited to
> children),
>   4504323(Implement start_command() for Windows),
>   b8e84a6(Implement a work-around for a misbehaved vsnprintf on Windows),
>   08bbcb4(Windows: always chmod(, 0666) before unlink()),
>   f6bbf12(Windows: Implement a wrapper of the open() function),
>   56cedf3(Windows: Fix PRIuMAX definition),
>   7458a97(Windows: Implement wrappers for gethostbyname(), socket(), and
> connect()),
>   ef25947(Windows: Fix ntohl() related warnings about printf formatting),
>   b9db7ad(Windows: Implement a custom spawnve()), and
>   47dacb3(compat/pread.c: Add foward decl to fix warning)

This would become a gigantic patch, which I really dislike. It's much easier
to follow (and bisect) if things appear in smaller pieces.

> - d6596ed(gitk: Disable msgfmt on MinGW) and
>   004fb4b(Fix renaming .gitk-new to .gitk on Windows if there is already a
> .gitk)
>   are gitk patches.
>   Further, I think that d6596ed would be better done as an automatic
>   detection of msgfmt's presence; on my Eee PC, there is no msgfmt
>   either...

Let's do that later.

> - 20fd16e(Windows: Use a customized struct stat that also has the
> st_blocks member) should be folded into
>   6f97065(Add a new lstat and fstat implementation based on Win32 API)
>   (with a comment that you customized the struct stat, too)
> 
>   But then, without 20fd16e, git does not compile, so again I would rather
>   fold that back into the MinGW commit.

The custom lstat() implementation cannot come after the custom struct stat
because we can't call Windows's stat() with a custom struct stat. But I
also don't want the custom lstat() in the code from the beginning because
it's merely an optimization.

> - in git.git, the onelines are not terminated by "."

You mean commit messages?

> - I'd prefer f90524e(Add target architecture MinGW) to come last.
>   Alternatively, you could cut out the Makefile change so that the series
>   is still bisectable: MinGW will just not be supported until the very
>   end.

I strongly disagree. The series is completely bisectable on *nix. But if the
Makefile change comes last, it becomes difficult to bisect on MinGW.

> $ git grep __MINGW j6t/upstream
> 
> comes up with 26 hits.
> 
> The first of them: cache.h:381, function is_absolute_path().  That just
> cries out loud to be "#ifdef DOS_STYLE_PATHS" instead of "#ifdef
> __MINGW32__".
> 
> I guess there should also be -DHAS_NO_FORK_BUT_THREADS -DHAS_TMP_AND_TEMP
> -DHAS_WINSOCK2, but most of them look like -DDOS_STYLE_PATHS to me.

Doesn't this go too far? How many systems are there where not all of them
would be set at the same time?

-- Hannes

Re: What's not in 'master', and likely not to be until 1.5.4

[Johannes Schindelin]

Hi,

On Fri, 18 Jan 2008, Johannes Sixt wrote:

> Johannes Schindelin wrote:
> 
> > - Possibly some of these commits could be folded back into
> >   f90524e(Add target architecture MinGW):
> > 
> >   96a27f1(MinGW: Implement gettimeofday()),
> >   2e05f891(Implement a rudimentary poll() emulation for Windows),
> >   142bda0(Fake implementions of getpwuid(), getuid(), and getpwnam() for
> > Windows),
> >   e799caf(Implement setitimer() and sigaction()),
> >   075fee7(Implement a wrapper of execve that can invoke shell scripts),
> >   495f0af(Work around misbehaved rename() on Windows),
> >   34cf7fd(Implement a pipe() replacement whose ends are not inherited to
> > children),
> >   4504323(Implement start_command() for Windows),
> >   b8e84a6(Implement a work-around for a misbehaved vsnprintf on Windows),
> >   08bbcb4(Windows: always chmod(, 0666) before unlink()),
> >   f6bbf12(Windows: Implement a wrapper of the open() function),
> >   56cedf3(Windows: Fix PRIuMAX definition),
> >   7458a97(Windows: Implement wrappers for gethostbyname(), socket(), and
> > connect()),
> >   ef25947(Windows: Fix ntohl() related warnings about printf formatting),
> >   b9db7ad(Windows: Implement a custom spawnve()), and
> >   47dacb3(compat/pread.c: Add foward decl to fix warning)
> 
> This would become a gigantic patch, which I really dislike. It's much 
> easier to follow (and bisect) if things appear in smaller pieces.

Yes, probably.  (See below for the bisection.)

> > - d6596ed(gitk: Disable msgfmt on MinGW) and
> >   004fb4b(Fix renaming .gitk-new to .gitk on Windows if there is already a
> > .gitk)
> >   are gitk patches.
> >   Further, I think that d6596ed would be better done as an automatic
> >   detection of msgfmt's presence; on my Eee PC, there is no msgfmt
> >   either...
> 
> Let's do that later.

I think these are more or less independent of the rest.

> > - 20fd16e(Windows: Use a customized struct stat that also has the
> > st_blocks member) should be folded into
> >   6f97065(Add a new lstat and fstat implementation based on Win32 API)
> >   (with a comment that you customized the struct stat, too)
> > 
> >   But then, without 20fd16e, git does not compile, so again I would rather
> >   fold that back into the MinGW commit.
> 
> The custom lstat() implementation cannot come after the custom struct 
> stat because we can't call Windows's stat() with a custom struct stat. 
> But I also don't want the custom lstat() in the code from the beginning 
> because it's merely an optimization.

Okay.

> > - in git.git, the onelines are not terminated by "."
> 
> You mean commit messages?

I meant the subjects of the commit messages.  I.e. "Add target 
architecture MinGW.".  But that's such a minor issue.

> > - I'd prefer f90524e(Add target architecture MinGW) to come last.
> >   Alternatively, you could cut out the Makefile change so that the series
> >   is still bisectable: MinGW will just not be supported until the very
> >   end.
> 
> I strongly disagree. The series is completely bisectable on *nix. But if 
> the Makefile change comes last, it becomes difficult to bisect on MinGW.

Hmm.  You're right, of course, for *nix.

But for MinGW I am not really sure, as you do not really get a 
fully functional system prior to all of the 42 patches...

I am really torn on this, because I can understand your point of view.

But when there would be an issue with MinGW, and I wanted to find out if 
it worked _at all_, it would be nice to have an easily determined commit 
where MinGW was supposed to be fully functional first, without a private 
tag or something.

Reading again what I wrote it appears that my opinion on that was strong; 
it is not.  I am not quite sure what would be best.  (In the end, I will 
always have the option to not care and let it be Junio's problem ;-)

> > $ git grep __MINGW j6t/upstream
> > 
> > comes up with 26 hits.
> > 
> > The first of them: cache.h:381, function is_absolute_path().  That just
> > cries out loud to be "#ifdef DOS_STYLE_PATHS" instead of "#ifdef
> > __MINGW32__".
> > 
> > I guess there should also be -DHAS_NO_FORK_BUT_THREADS 
> > -DHAS_TMP_AND_TEMP -DHAS_WINSOCK2, but most of them look like 
> > -DDOS_STYLE_PATHS to me.
> 
> Doesn't this go too far? How many systems are there where not all of 
> them would be set at the same time?

I am not only thinking about other systems... it is also a pretty nice way 
of documenting _why_ this change was made.  With the possible exception of 
HAS_TMP_AND_TEMP, I really would like to see that.  So much so that I 
hereby offer to do the transform myself.

Ciao,
Dscho

Re: What's not in 'master', and likely not to be until 1.5.4

[Jakub Narebski]

Junio C Hamano <gitster@pobox.com> writes:

> Here is an update to the list I sent earlier.  Topics that I
> thought may deserve attention, discussion and eventual inclusion
> but are not 1.5.4 material.
> 
> I think some of them actually have a slight chance of being
> 1.5.4 material, if interested parties present good enough
> arguments that they are actually good and safe bugfixes.
 
>  * submodule subcommand parser fix for "git submodule add init
>    update" (Imran M Yousuf and me)

Isn't it a bugfix, and shouldn't it for this reason be in 1.5.4?
 
>  * gitweb feed from commit to commitdiff (Florian La Rouche --
>    Jakub seems to be on top of this so I am not worried about it
>    too much).

What need IMHO to be changed is commit message: state stronger
that the only thing that changed is that feed entry refers now
to 'commitdiff' view rather than 'commit' view. I can agree that
it might be better... but I do not use gitweb feeds myself.

Reasonably post 1.5.4

> Again, I am hoping that authors will resend the ones they really
> care about after 1.5.4, as I do not want to take patches early.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: What's not in 'master', and likely not to be until 1.5.4

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Here is an update to the list I sent earlier.  Topics that I
>> thought may deserve attention, discussion and eventual inclusion
>> but are not 1.5.4 material.
>> 
>> I think some of them actually have a slight chance of being
>> 1.5.4 material, if interested parties present good enough
>> arguments that they are actually good and safe bugfixes.
>  
>>  * submodule subcommand parser fix for "git submodule add init
>>    update" (Imran M Yousuf and me)
>
> Isn't it a bugfix, and shouldn't it for this reason be in 1.5.4?

Yeah, I tend to agree.  I was waiting for an Ack or failure
report from Imran, as I turned the table around.

Re: What's not in 'master', and likely not to be until 1.5.4

[Imran M Yousuf]

On Jan 19, 2008 3:49 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> >> Here is an update to the list I sent earlier.  Topics that I
> >> thought may deserve attention, discussion and eventual inclusion
> >> but are not 1.5.4 material.
> >>
> >> I think some of them actually have a slight chance of being
> >> 1.5.4 material, if interested parties present good enough
> >> arguments that they are actually good and safe bugfixes.
> >
> >>  * submodule subcommand parser fix for "git submodule add init
> >>    update" (Imran M Yousuf and me)
> >
> > Isn't it a bugfix, and shouldn't it for this reason be in 1.5.4?
>
> Yeah, I tend to agree.  I was waiting for an Ack or failure
> report from Imran, as I turned the table around.

Sorry I forgot to mention it earlier, your patches worked fine :),
thank you once again for the help.

>



-- 
Imran M Yousuf

Re: What's not in 'master', and likely not to be until 1.5.4

[Junio C Hamano]

Thanks.

Re: What's not in 'master', and likely not to be until 1.5.4

[Steffen Prohaska]

On Jan 21, 2008, at 6:55 AM, Imran M Yousuf wrote:

> On Jan 19, 2008 3:49 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> Junio C Hamano <gitster@pobox.com> writes:
>>>
>>>> Here is an update to the list I sent earlier.  Topics that I
>>>> thought may deserve attention, discussion and eventual inclusion
>>>> but are not 1.5.4 material.
>>>>
>>>> I think some of them actually have a slight chance of being
>>>> 1.5.4 material, if interested parties present good enough
>>>> arguments that they are actually good and safe bugfixes.
>>>
>>>>  * submodule subcommand parser fix for "git submodule add init
>>>>    update" (Imran M Yousuf and me)
>>>
>>> Isn't it a bugfix, and shouldn't it for this reason be in 1.5.4?
>>
>> Yeah, I tend to agree.  I was waiting for an Ack or failure
>> report from Imran, as I turned the table around.
>
> Sorry I forgot to mention it earlier, your patches worked fine :),
> thank you once again for the help.

I read through the patch and it looks good.

I think the documentation should be slightly adjusted.  Patch follows
as a reply to this mail.

	Steffen

[PATCH] submodule: Document the details of the command line syntax

[Steffen Prohaska]

Only "status" accepts "--cached" and the preferred way of
passing sub-command specific options is after the sub-command.

The documentation is adapted to reflect this.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 Documentation/git-submodule.txt |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index cffc6d4..e818e6e 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -9,8 +9,9 @@ git-submodule - Initialize, update or inspect submodules
 SYNOPSIS
 --------
 [verse]
-'git-submodule' [--quiet] [-b branch] add <repository> [<path>]
-'git-submodule' [--quiet] [--cached] [status|init|update] [--] [<path>...]
+'git-submodule' [--quiet] add [-b branch] [--] <repository> [<path>]
+'git-submodule' [--quiet] status [--cached] [--] [<path>...]
+'git-submodule' [--quiet] [init|update] [--] [<path>...]
 
 
 COMMANDS
-- 
1.5.4.rc4.3.g7c32b

Re: [PATCH] submodule: Document the details of the command line syntax

[Junio C Hamano]

Thanks.  That change makes sense to me.

Re: What's not in 'master', and likely not to be until 1.5.4

[Marco Costalba]

On Jan 18, 2008 11:40 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> I think some of them actually have a slight chance of being
> 1.5.4 material, if interested parties present good enough
> arguments that they are actually good and safe bugfixes.
>
>  * compress/decompress abstraction (Marco)
>

I have good enough arguments to NOT include it in 1.5.4: it's a
cleanup, so it's developer oriented, not user oriented, no
performance/feature benefit, no bug fix.

Please apply only after 1.5.4 is out.

Thanks
Marco

Re: What's not in 'master', and likely not to be until 1.5.4

[Marco Costalba]

On Jan 18, 2008 1:17 PM, Marco Costalba <mcostalba@gmail.com> wrote:
>
> Please apply only after 1.5.4 is out.
>

BTW I will resend the whole series this time without lines wrapping I
promise (I have learnt git send-mail in the mean time ;-)

Marco

Re: What's not in 'master', and likely not to be until 1.5.4

[Steffen Prohaska]

On Jan 18, 2008, at 11:40 AM, Junio C Hamano wrote:

> Here is an update to the list I sent earlier.  Topics that I
> thought may deserve attention, discussion and eventual inclusion
> but are not 1.5.4 material.
>
> I think some of them actually have a slight chance of being
> 1.5.4 material, if interested parties present good enough
> arguments that they are actually good and safe bugfixes.
>
[...]
>
>  * crlf (Steffen Prohaska and Dmitry Potapov)


I am working on an alternative to the patch I sent last week.
I hope I can present the two approaches soon.

The first approach is a lazy check in crlf_to_git() that warns
about an irreversible conversion; or dies if safecrlf=true.  This
is relatively simple code but at least for git-add a workaround
is needed to suppress printing a warning twice.  The runtime
overhead is negligible.

The second approach adds a new machinery is_worktree_crlfsafe()
that could be run independently of the crlf_to_git() conversion.
The code doing the conversion would stay unmodified.  The
advantage is that the whole work tree could be verified before
any conversion actually happens and we could die() after printing
all the warnings instead of printing only the first one.  The
drawback is that this approach most likely needs more code and
will introduce runtime overhead.  A straight forward
implementation would add another pass over the work tree running
the stats in convert.c.  So the stats would be run twice.
And for a simple "git add <file>" the situation is even worse:
the full work tree would be verified even is only a single file
is to be added.

I haven't found time during the week, so I'll continue to work
on this over the weekend.  Maybe even more time is needed to
discuss the two alternatives.

I do not expect that this topic will be ready for 1.5.4.

	Steffen

Re: What's not in 'master', and likely not to be until 1.5.4

[Johannes Schindelin]

Hi,

On Fri, 18 Jan 2008, Steffen Prohaska wrote:

> 
> On Jan 18, 2008, at 11:40 AM, Junio C Hamano wrote:
> 
> >  * crlf (Steffen Prohaska and Dmitry Potapov)
> 
> I am working on an alternative to the patch I sent last week. I hope I 
> can present the two approaches soon.
> 
> The first approach is a lazy check in crlf_to_git() that warns about an 
> irreversible conversion; or dies if safecrlf=true.  This is relatively 
> simple code but at least for git-add a workaround is needed to suppress 
> printing a warning twice.  The runtime overhead is negligible.
> 
> The second approach adds a new machinery is_worktree_crlfsafe()
> that could be run independently of the crlf_to_git() conversion.

>From the sound of it, I like the first approach much better.

> I do not expect that this topic will be ready for 1.5.4.

What with our ongoing discussion when to go out of preview phase for 
msysGit, I think this makes sense.

Ciao,
Dscho

Re: What's not in 'master', and likely not to be until 1.5.4

[Steffen Prohaska]

On Jan 18, 2008, at 2:09 PM, Johannes Schindelin wrote:

> On Fri, 18 Jan 2008, Steffen Prohaska wrote:
>
>>
>> On Jan 18, 2008, at 11:40 AM, Junio C Hamano wrote:
>>
>>>  * crlf (Steffen Prohaska and Dmitry Potapov)
>>
>> I am working on an alternative to the patch I sent last week. I  
>> hope I
>> can present the two approaches soon.
>>
>> The first approach is a lazy check in crlf_to_git() that warns  
>> about an
>> irreversible conversion; or dies if safecrlf=true.  This is  
>> relatively
>> simple code but at least for git-add a workaround is needed to  
>> suppress
>> printing a warning twice.  The runtime overhead is negligible.
>>
>> The second approach adds a new machinery is_worktree_crlfsafe()
>> that could be run independently of the crlf_to_git() conversion.
>
> From the sound of it, I like the first approach much better.

Ok.  I'll start with cleaning up the first approach tomorrow and
send resend the patch.


>> I do not expect that this topic will be ready for 1.5.4.
>
> What with our ongoing discussion when to go out of preview phase for
> msysGit, I think this makes sense.

I'll work on creating an improved installer that installs only a
subset of the commands.  I'll exclude commands that are not yet
ready for Windows (e.g.  git-svn, ...).

After we have the first version of this installer we can further
discuss if we leave the preview phase.

	Steffen

What's not in 'master', and likely not to be in, until 1.5.4

[Junio C Hamano]

Here is an update to the list I sent earlier.

Topics that I thought may deserve attention, discussion and
eventual inclusion but are not 1.5.4 material.

I think these two could be part of 1.5.4, but I left them out of
1.5.4-rc4 (IOW, I do not think they should be on this list):

 * marking output from "diff --{no,src,dst}-prefix" as a non-git
   diff (me)

   Linus had an objection but I think I made a reasonable
   argument against that.  Haven't heard back since then, so
   this is in limbo.

 * submodule subcommand parser fix for "git submodule add init
   update" (Imran M Yousuf and me)

   As Jakub noticed, this is meant to be a bugfix but as I do
   not use submodule heavily myself, backing it with real-world
   success stories would be needed.

Now these two out of our way, here is the list.

 * various lstat(2) reduction changes (me, Linus and Dscho).

   This will be queued in 'pu'; it appears this introduces a
   timing related breakages in t75?? tests.

 * compress/decompress abstraction (Marco)

 * crlf (Steffen Prohaska and Dmitry Potapov)

 * whitespace error: "cr at eol is ok" (me)

 * submodule recursive wrapper (Imran M Yousuf)

 * 'origin' is not so special after "clone -o frotz" (Mark Levedahl)

 * "submodule summary" (Ping Yin)

 * unconfigured ident safety (Stephen Sinclair)

 * gitweb feed from commit to commitdiff (Florian La Rouche --
   Jakub seems to be on top of this so I am not worried about it
   too much).

 * color.ui (Matthias Kestenholz)

 * test scripts to use valgrind (Jeff King)

 * "rebase -i" UI -- should it be simplified to do commit --amend
   itself? (Dscho)

 * "cherry-pick/revert" error message fix (Björn Steinbrink and me)

 * pathname safety on filesystems whose readdir(3) thinks it
   knows better than users (Linus, Robin Rosenberg, me and
   others).

   I tend to prefer a much simpler approach Linus suggested, to
   wrap readdir(3) on systems that are known to mangle files,
   but I have a slight suspicion it would not work well enough
   for cross platform projects.

Again, I am hoping that authors will resend the ones they really
care about after 1.5.4, as I do not want to take patches early.

The previous version of this list did not include the some that
were discussed and landed in 'pu' (or 'offcuts').  The ones that
we may want to polish that are in 'pu' are:

 * omit cc recipients from send-email (David Brown)

 * sha1 lookup optimization (me)

 * rewrite cherry-pick/revert in order to improve its D/F
   conflict resolution (me)

 * allow native protocol to tell exactly which branch HEAD
   points at (me)

There is also 1.6.0 material queued already, way before the rc
cycle:

 * Moving "git-foo" out of users' $PATH (Nguyễn Thái Ngọc Duy)

I suspect it might be a good idea to make an early declaration
that 1.5.5 is to resolve the above listed issues plus the ones
already in 'pu' (and nothing else), and have a fairly short
cycle after 1.5.4.

Re: What's not in 'master', and likely not to be in, until 1.5.4

[Linus Torvalds]

On Sun, 20 Jan 2008, Junio C Hamano wrote:
> 
>  * marking output from "diff --{no,src,dst}-prefix" as a non-git
>    diff (me)
> 
>    Linus had an objection but I think I made a reasonable
>    argument against that.  Haven't heard back since then, so
>    this is in limbo.

I just didn'̈́t really care enough. I still don't think the prefix has 
anything to do with git'ness, but at the same time it's just not something 
I'll ever use, so..

>  * various lstat(2) reduction changes (me, Linus and Dscho).
> 
>    This will be queued in 'pu'; it appears this introduces a
>    timing related breakages in t75?? tests.

Can you send some more info on this? I obviously like that series, and 
I've been running various versions of it for a while now, and have run 
"make test" a lot. Haven't seen any failures (except the ones I've 
introduced while developing), but would be happy to see reports.

			Linus

Re: What's not in 'master', and likely not to be in, until 1.5.4

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Sun, 20 Jan 2008, Junio C Hamano wrote:
>> 
>>  * marking output from "diff --{no,src,dst}-prefix" as a non-git
>>    diff (me)
>> 
>>    Linus had an objection but I think I made a reasonable
>>    argument against that.  Haven't heard back since then, so
>>    this is in limbo.
>
> I just didn'̈́t really care enough. I still don't think the prefix has 
> anything to do with git'ness, but at the same time it's just not something 
> I'll ever use, so..
>
>>  * various lstat(2) reduction changes (me, Linus and Dscho).
>> 
>>    This will be queued in 'pu'; it appears this introduces a
>>    timing related breakages in t75?? tests.
>
> Can you send some more info on this?

It's a Heisenbug.  I actually merged it to 'next' but rewound it
before pushing the result out after seeing a breakage.

"make clean test" to run everything through sometimes fails and
immediately after that when I do "cd t && sh t75??-???.sh -i -v"
it happily runs through the end.

I'll be back with more details when I have some.

Re: What's not in 'master', and likely not to be in, until 1.5.4

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> It's a Heisenbug.  I actually merged it to 'next' but rewound it
> before pushing the result out after seeing a breakage.
>
> "make clean test" to run everything through sometimes fails and
> immediately after that when I do "cd t && sh t75??-???.sh -i -v"
> it happily runs through the end.
>
> I'll be back with more details when I have some.

In t7501-commit.sh, "partial commit that involves removal (1)"
test, it _sometimes_ fails.

    test_expect_success 'partial commit that involves removal (1)' '

        git rm --cached file &&
        mv file elif &&
        git add elif &&
        git diff-index --name-status HEAD >changes &&
        git commit -m "Partial: add elif" elif &&
        git diff-tree --name-status HEAD^ HEAD >current &&
        echo "A     elif" >expected &&
        diff expected current

    '

It removes "file" from the index, adds "elif" to the index, and
tries to commit _only_ the addition of "elif" without recording
the removal of "file" (I added "diff-index" above to see where
it fails, its presense or absense does not change the bug, and
it shows that both addition of elif and removal of file are in
the index).

When the test fails, the resulting commit however does not
record the addition of elif.  The commit records the same tree
as its parent instead.  The index that is left has "elif" but
not "file" (iow, it records the expected state after such a
partial commit).

Re: What's not in 'master', and likely not to be in, until 1.5.4

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> It's a Heisenbug.  I actually merged it to 'next' but rewound it
>> before pushing the result out after seeing a breakage.
>>
>> "make clean test" to run everything through sometimes fails and
>> immediately after that when I do "cd t && sh t75??-???.sh -i -v"
>> it happily runs through the end.
>>
>> I'll be back with more details when I have some.
>
> In t7501-commit.sh, "partial commit that involves removal (1)"
> test, it _sometimes_ fails.
>
>     test_expect_success 'partial commit that involves removal (1)' '
>
>         git rm --cached file &&
>         mv file elif &&
>         git add elif &&
>         git diff-index --name-status HEAD >changes &&
>         git commit -m "Partial: add elif" elif &&
>         git diff-tree --name-status HEAD^ HEAD >current &&
>         echo "A     elif" >expected &&
>         diff expected current
>
>     '
>
> It removes "file" from the index, adds "elif" to the index, and
> tries to commit _only_ the addition of "elif" without recording
> the removal of "file" (I added "diff-index" above to see where
> it fails, its presense or absense does not change the bug, and
> it shows that both addition of elif and removal of file are in
> the index).
>
> When the test fails, the resulting commit however does not
> record the addition of elif.  The commit records the same tree
> as its parent instead.  The index that is left has "elif" but
> not "file" (iow, it records the expected state after such a
> partial commit).

Bad news is that this does not seem to have much to do with the
incore-index series.  v1.5.4-rc4 shows the same breakage.

Re: What's not in 'master', and likely not to be in, until 1.5.4

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Bad news is that this does not seem to have much to do with the
> incore-index series.  v1.5.4-rc4 shows the same breakage.

Please disregard that bad news -- that was my stupidity while
bisecting.  v1.5.4-rc4 seems to be Ok.

Re: What's not in 'master', and likely not to be in, until 1.5.4

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Bad news is that this does not seem to have much to do with the
>> incore-index series.  v1.5.4-rc4 shows the same breakage.
>
> Please disregard that bad news -- that was my stupidity while
> bisecting.  v1.5.4-rc4 seems to be Ok.

And the bisection points at the first one in the series "Updated
in-memory index cleanup".  Which is kind of odd and sad, as it
is not supposed to change the semantics at all, and I did not
see anything obviously wrong with it.

$ cd t
$ while :
  do
    sh -x ./t7501-commit.sh -i -v >,,log 2>&1 || break
  done

Re: What's not in 'master', and likely not to be in, until 1.5.4

[Junio C Hamano]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

An update, with three attachments (sorry), but not final
resolution yet (sorry again) and I am going to bed.

t7501-commit-2.sh is a very reduced test script.  Drop it in t/
and run it like:

 $ while :; do sh ./t7501-commit-2.sh -i -v || break; done

I stops after running for a while with "Updated in-memory index
cleanup" patch (and does not seem to stop without).  Note that
this is before any of the lstat(2) reduction changes.

The attached "trace.log.old" is strace output from the round that
ran successfully, and "trace.log" is the same from the round
that failed.

The real place the logs start diverging is around line 240, the
good one runs two lstat(2) on "elif", opens "elif" in O_RDONLY
and closes it immediately (eh, what is it doing?  I do not even
see any read or mmap --- it is just open and close) and then
reads the config and attributes (presumably this is doing the
convert-to-git stuff).  The bad one runs three lstat(2) on it
and writes the next-index out, without even opening "elif".


[-- Attachment #2: Reduced 7501 test --]
[-- Type: text/plain, Size: 552 bytes --]

#!/bin/sh

test_description='reduced 7501'

. ./test-lib.sh

test_expect_success setup '

	>file &&
	git add file &&
	test_tick &&
	git commit -m initial

'

if test -f ../trace.log
then
	mv ../trace.log ../trace.log.old
fi

test_expect_success 'partial commit that involves removal (1)' '

	test_tick &&
	git rm --cached file &&
	mv file elif &&
	git add elif &&

	strace -f -o ../trace.log git commit -m "Partial: add elif" elif &&

	git diff-tree --name-status HEAD^ HEAD >current &&
	echo "A	elif" >expected &&
	diff expected current

'

test_done

[-- Attachment #3: strace output from a good run --]
[-- Type: text/plain, Size: 50037 bytes --]

10888 execve("/opt/packrat/playpen/public/in-place/git/git.junio/t/../git", ["git", "commit", "-m", "Partial: add elif", "elif"], [/* 51 vars */]) = 0
10888 brk(0)                            = 0x6f7000
10888 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b064998c000
10888 uname({sys="Linux", node="gitster", ...}) = 0
10888 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10888 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b064998d000
10888 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
10888 open("/etc/ld.so.cache", O_RDONLY) = 6
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=70263, ...}) = 0
10888 mmap(NULL, 70263, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2b064998f000
10888 close(6)                          = 0
10888 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10888 open("/usr/lib/libcurl.so.3", O_RDONLY) = 6
10888 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`m\0\0\0"..., 832) = 832
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=227856, ...}) = 0
10888 mmap(NULL, 1275080, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2b06499a1000
10888 mprotect(0x2b06499d7000, 1048576, PROT_NONE) = 0
10888 mmap(0x2b0649ad7000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x36000) = 0x2b0649ad7000
10888 close(6)                          = 0
10888 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10888 open("/usr/lib/libz.so.1", O_RDONLY) = 6
10888 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@!\0\0\0"..., 832) = 832
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=93504, ...}) = 0
10888 mmap(NULL, 2188616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2b0649b8d000
10888 mprotect(0x2b0649ba3000, 2097152, PROT_NONE) = 0
10888 mmap(0x2b0649da3000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x16000) = 0x2b0649da3000
10888 close(6)                          = 0
10888 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10888 open("/usr/lib/libcrypto.so.0.9.8", O_RDONLY) = 6
10888 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\364"..., 832) = 832
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=1510344, ...}) = 0
10888 mmap(NULL, 2571832, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2b0649da4000
10888 mprotect(0x2b0649ef2000, 1048576, PROT_NONE) = 0
10888 mmap(0x2b0649ff2000, 143360, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x14e000) = 0x2b0649ff2000
10888 mmap(0x2b064a015000, 11832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2b064a015000
10888 close(6)                          = 0
10888 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10888 open("/lib/libc.so.6", O_RDONLY)  = 6
10888 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\334\1\0"..., 832) = 832
10888 fstat(6, {st_mode=S_IFREG|0755, st_size=1391928, ...}) = 0
10888 mmap(NULL, 3498360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2b064a018000
10888 mprotect(0x2b064a165000, 2097152, PROT_NONE) = 0
10888 mmap(0x2b064a365000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x14d000) = 0x2b064a365000
10888 mmap(0x2b064a36a000, 16760, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2b064a36a000
10888 close(6)                          = 0
10888 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10888 open("/usr/lib/libgssapi_krb5.so.2", O_RDONLY) = 6
10888 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20e\0\0"..., 832) = 832
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=173640, ...}) = 0
10888 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b064a36f000
10888 mmap(NULL, 2269136, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2b064a370000
10888 mprotect(0x2b064a399000, 2093056, PROT_NONE) = 0
10888 mmap(0x2b064a598000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x28000) = 0x2b064a598000
10888 close(6)                          = 0
10888 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10888 open("/usr/lib/libkrb5.so.3", O_RDONLY) = 6
10888 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\221"..., 832) = 832
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=635688, ...}) = 0
10888 mmap(NULL, 2730976, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2b064a59a000
10888 mprotect(0x2b064a631000, 2097152, PROT_NONE) = 0
10888 mmap(0x2b064a831000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x97000) = 0x2b064a831000
10888 close(6)                          = 0
10888 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10888 open("/usr/lib/libk5crypto.so.3", O_RDONLY) = 6
10888 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320X\0\0"..., 832) = 832
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=150656, ...}) = 0
10888 mmap(NULL, 2246952, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2b064a835000
10888 mprotect(0x2b064a858000, 2097152, PROT_NONE) = 0
10888 mmap(0x2b064aa58000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x23000) = 0x2b064aa58000
10888 close(6)                          = 0
10888 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10888 open("/lib/libcom_err.so.2", O_RDONLY) = 6
10888 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\f\0"..., 832) = 832
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=7984, ...}) = 0
10888 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b064aa5a000
10888 mmap(NULL, 1054920, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2b064aa5b000
10888 mprotect(0x2b064aa5d000, 1044480, PROT_NONE) = 0
10888 mmap(0x2b064ab5c000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x1000) = 0x2b064ab5c000
10888 close(6)                          = 0
10888 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10888 open("/usr/lib/libkrb5support.so.0", O_RDONLY) = 6
10888 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\35\0"..., 832) = 832
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=30408, ...}) = 0
10888 mmap(NULL, 2125648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2b064ab5d000
10888 mprotect(0x2b064ab64000, 2093056, PROT_NONE) = 0
10888 mmap(0x2b064ad63000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x6000) = 0x2b064ad63000
10888 close(6)                          = 0
10888 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10888 open("/lib/libresolv.so.2", O_RDONLY) = 6
10888 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0003\0\0"..., 832) = 832
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=76664, ...}) = 0
10888 mmap(NULL, 2181896, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2b064ad64000
10888 mprotect(0x2b064ad75000, 2097152, PROT_NONE) = 0
10888 mmap(0x2b064af75000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x11000) = 0x2b064af75000
10888 mmap(0x2b064af77000, 6920, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2b064af77000
10888 close(6)                          = 0
10888 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10888 open("/usr/lib/libidn.so.11", O_RDONLY) = 6
10888 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340/\0\0"..., 832) = 832
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=202368, ...}) = 0
10888 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b064af79000
10888 mmap(NULL, 1249152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2b064af7a000
10888 mprotect(0x2b064afab000, 1044480, PROT_NONE) = 0
10888 mmap(0x2b064b0aa000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x30000) = 0x2b064b0aa000
10888 close(6)                          = 0
10888 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10888 open("/lib/libdl.so.2", O_RDONLY) = 6
10888 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \16\0\0"..., 832) = 832
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=14624, ...}) = 0
10888 mmap(NULL, 2109728, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2b064b0ab000
10888 mprotect(0x2b064b0ad000, 2097152, PROT_NONE) = 0
10888 mmap(0x2b064b2ad000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x2000) = 0x2b064b2ad000
10888 close(6)                          = 0
10888 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10888 open("/usr/lib/libssl.so.0.9.8", O_RDONLY) = 6
10888 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\31\1"..., 832) = 832
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=291816, ...}) = 0
10888 mmap(NULL, 1338608, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2b064b2af000
10888 mprotect(0x2b064b2f0000, 1048576, PROT_NONE) = 0
10888 mmap(0x2b064b3f0000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x41000) = 0x2b064b3f0000
10888 close(6)                          = 0
10888 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10888 open("/lib/libkeyutils.so.1", O_RDONLY) = 6
10888 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\v\0"..., 832) = 832
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=7304, ...}) = 0
10888 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b064b3f6000
10888 mmap(NULL, 1054160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2b064b3f7000
10888 mprotect(0x2b064b3f9000, 1044480, PROT_NONE) = 0
10888 mmap(0x2b064b4f8000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x1000) = 0x2b064b4f8000
10888 close(6)                          = 0
10888 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b064b4f9000
10888 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b064b4fa000
10888 arch_prctl(ARCH_SET_FS, 0x2b064b4f9f10) = 0
10888 mprotect(0x2b064a365000, 12288, PROT_READ) = 0
10888 munmap(0x2b064998f000, 70263)     = 0
10888 brk(0)                            = 0x6f7000
10888 brk(0x718000)                     = 0x718000
10888 getcwd("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash", 4096) = 59
10888 access(".git/objects", X_OK)      = 0
10888 access(".git/refs", X_OK)         = 0
10888 lstat(".git/HEAD", {st_mode=S_IFREG|0664, st_size=23, ...}) = 0
10888 open(".git/HEAD", O_RDONLY)       = 6
10888 read(6, "ref: refs/heads/master\n", 255) = 23
10888 read(6, "", 232)                  = 0
10888 close(6)                          = 0
10888 open(".git/config", O_RDONLY)     = 6
10888 fstat(6, {st_mode=S_IFREG|0664, st_size=92, ...}) = 0
10888 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b064998f000
10888 read(6, "[core]\n\trepositoryformatversion "..., 4096) = 92
10888 read(6, "", 4096)                 = 0
10888 close(6)                          = 0
10888 munmap(0x2b064998f000, 4096)      = 0
10888 stat(".git", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 getcwd("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash", 1024) = 59
10888 chdir(".git")                     = 0
10888 getcwd("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git", 4096) = 64
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 chdir("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash") = 0
10888 chdir("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash") = 0
10888 open(".git/config", O_RDONLY)     = 6
10888 fstat(6, {st_mode=S_IFREG|0664, st_size=92, ...}) = 0
10888 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b064998f000
10888 read(6, "[core]\n\trepositoryformatversion "..., 4096) = 92
10888 read(6, "", 4096)                 = 0
10888 close(6)                          = 0
10888 munmap(0x2b064998f000, 4096)      = 0
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/HEAD", {st_mode=S_IFREG|0664, st_size=23, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/HEAD", O_RDONLY) = 6
10888 read(6, "ref: refs/heads/master\n", 255) = 23
10888 read(6, "", 232)                  = 0
10888 close(6)                          = 0
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", {st_mode=S_IFREG|0664, st_size=41, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", O_RDONLY) = 6
10888 read(6, "1bd44cb9d13204b0fe1958db0082f502"..., 255) = 41
10888 read(6, "", 214)                  = 0
10888 close(6)                          = 0
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/HEAD", 0x7fff611379c0) = -1 ENOENT (No such file or directory)
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/packed-refs", O_RDONLY) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/tags/HEAD", 0x7fff611379c0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/HEAD", 0x7fff611379c0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/remotes/HEAD", 0x7fff611379c0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/remotes/HEAD/HEAD", 0x7fff611379c0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/MERGE_HEAD", 0x7fff611379c0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/MERGE_HEAD", 0x7fff611379c0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/tags/MERGE_HEAD", 0x7fff611379c0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/MERGE_HEAD", 0x7fff611379c0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/remotes/MERGE_HEAD", 0x7fff611379c0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/remotes/MERGE_HEAD/HEAD", 0x7fff611379c0) = -1 ENOENT (No such file or directory)
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/index", O_RDONLY) = 6
10888 fstat(6, {st_mode=S_IFREG|0664, st_size=104, ...}) = 0
10888 mmap(NULL, 104, PROT_READ|PROT_WRITE, MAP_PRIVATE, 6, 0) = 0x2b064998f000
10888 close(6)                          = 0
10888 munmap(0x2b064998f000, 104)       = 0
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/MERGE_HEAD", 0x7fff61137b30) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/HEAD", {st_mode=S_IFREG|0664, st_size=23, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/HEAD", O_RDONLY) = 6
10888 read(6, "ref: refs/heads/master\n", 255) = 23
10888 read(6, "", 232)                  = 0
10888 close(6)                          = 0
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", {st_mode=S_IFREG|0664, st_size=41, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", O_RDONLY) = 6
10888 read(6, "1bd44cb9d13204b0fe1958db0082f502"..., 255) = 41
10888 read(6, "", 214)                  = 0
10888 close(6)                          = 0
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/HEAD", 0x7fff611378f0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/tags/HEAD", 0x7fff611378f0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/HEAD", 0x7fff611378f0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/remotes/HEAD", 0x7fff611378f0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/remotes/HEAD/HEAD", 0x7fff611378f0) = -1 ENOENT (No such file or directory)
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/pack", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 6
10888 fstat(6, {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 fcntl(6, F_SETFD, FD_CLOEXEC)     = 0
10888 getdents(6, /* 2 entries */, 4096) = 48
10888 getdents(6, /* 0 entries */, 4096) = 0
10888 close(6)                          = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/info/alternates", O_RDONLY) = -1 ENOENT (No such file or directory)
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/1b/d44cb9d13204b0fe1958db0082f5028a16eb3a", {st_mode=S_IFREG|0444, st_size=136, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/1b/d44cb9d13204b0fe1958db0082f5028a16eb3a", O_RDONLY|O_NOATIME) = 6
10888 mmap(NULL, 136, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2b064998f000
10888 close(6)                          = 0
10888 munmap(0x2b064998f000, 136)       = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/info/grafts", O_RDONLY) = -1 ENOENT (No such file or directory)
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/shallow", O_RDONLY) = -1 ENOENT (No such file or directory)
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/df/2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078", {st_mode=S_IFREG|0444, st_size=49, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/df/2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078", O_RDONLY|O_NOATIME) = 6
10888 mmap(NULL, 49, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2b064998f000
10888 close(6)                          = 0
10888 brk(0x739000)                     = 0x739000
10888 brk(0x736000)                     = 0x736000
10888 munmap(0x2b064998f000, 49)        = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/index", O_RDONLY) = 6
10888 fstat(6, {st_mode=S_IFREG|0664, st_size=104, ...}) = 0
10888 mmap(NULL, 104, PROT_READ|PROT_WRITE, MAP_PRIVATE, 6, 0) = 0x2b064998f000
10888 close(6)                          = 0
10888 munmap(0x2b064998f000, 104)       = 0
10888 readlink("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/index", 0x7fff61136b90, 4096) = -1 EINVAL (Invalid argument)
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/index.lock", O_RDWR|O_CREAT|O_EXCL, 0666) = 6
10888 rt_sigaction(SIGINT, {0x44bc70, [INT], SA_RESTORER|SA_RESTART, 0x2b064a0496a0}, {SIG_DFL}, 8) = 0
10888 getpid()                          = 10888
10888 lstat("elif", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
10888 lstat("elif", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
10888 open("elif", O_RDONLY)            = 7
10888 close(7)                          = 0
10888 open(".git/config", O_RDONLY)     = 7
10888 fstat(7, {st_mode=S_IFREG|0664, st_size=92, ...}) = 0
10888 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b064998f000
10888 read(7, "[core]\n\trepositoryformatversion "..., 4096) = 92
10888 read(7, "", 4096)                 = 0
10888 close(7)                          = 0
10888 munmap(0x2b064998f000, 4096)      = 0
10888 open(".gitattributes", O_RDONLY)  = -1 ENOENT (No such file or directory)
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/info/attributes", O_RDONLY) = -1 ENOENT (No such file or directory)
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391", {st_mode=S_IFREG|0444, st_size=15, ...}) = 0
10888 lstat("elif", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
10888 open("elif", O_RDONLY)            = 7
10888 close(7)                          = 0
10888 lstat("elif", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
10888 open("elif", O_RDONLY)            = 7
10888 close(7)                          = 0
10888 write(6, "DIRC\0\0\0\2\0\0\0\1G\224S\266\0\0\0\0G\224S\266\0\0\0"..., 104) = 104
10888 close(6)                          = 0
10888 readlink("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/next-index-10888", 0x7fff61136b90, 4096) = -1 ENOENT (No such file or directory)
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/next-index-10888.lock", O_RDWR|O_CREAT|O_EXCL, 0666) = 6
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/1b/d44cb9d13204b0fe1958db0082f5028a16eb3a", {st_mode=S_IFREG|0444, st_size=136, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/1b/d44cb9d13204b0fe1958db0082f5028a16eb3a", O_RDONLY|O_NOATIME) = 7
10888 mmap(NULL, 136, PROT_READ, MAP_PRIVATE, 7, 0) = 0x2b064998f000
10888 close(7)                          = 0
10888 munmap(0x2b064998f000, 136)       = 0
10888 lstat("elif", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
10888 lstat("elif", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
10888 open("elif", O_RDONLY)            = 7
10888 close(7)                          = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391", {st_mode=S_IFREG|0444, st_size=15, ...}) = 0
10888 lstat("elif", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
10888 open("elif", O_RDONLY)            = 7
10888 close(7)                          = 0
10888 lstat("file", 0x7fff61137a80)     = -1 ENOENT (No such file or directory)
10888 lstat("elif", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
10888 open("elif", O_RDONLY)            = 7
10888 close(7)                          = 0
10888 write(6, "DIRC\0\0\0\2\0\0\0\2G\224S\266\0\0\0\0G\224S\266\0\0\0"..., 176) = 176
10888 close(6)                          = 0
10888 access("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/hooks/pre-commit", X_OK) = -1 ENOENT (No such file or directory)
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/COMMIT_EDITMSG", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 6
10888 fstat(6, {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
10888 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b064998f000
10888 write(6, "Partial: add elif\n", 18) = 18
10888 close(6)                          = 0
10888 munmap(0x2b064998f000, 4096)      = 0
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/HEAD", {st_mode=S_IFREG|0664, st_size=23, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/HEAD", O_RDONLY) = 6
10888 read(6, "ref: refs/heads/master\n", 255) = 23
10888 read(6, "", 232)                  = 0
10888 close(6)                          = 0
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", {st_mode=S_IFREG|0664, st_size=41, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", O_RDONLY) = 6
10888 read(6, "1bd44cb9d13204b0fe1958db0082f502"..., 255) = 41
10888 read(6, "", 214)                  = 0
10888 close(6)                          = 0
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/HEAD", 0x7fff611376a0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/tags/HEAD", 0x7fff611376a0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/HEAD", 0x7fff611376a0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/remotes/HEAD", 0x7fff611376a0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/remotes/HEAD/HEAD", 0x7fff611376a0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/HEAD", {st_mode=S_IFREG|0664, st_size=23, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/HEAD", O_RDONLY) = 6
10888 read(6, "ref: refs/heads/master\n", 255) = 23
10888 read(6, "", 232)                  = 0
10888 close(6)                          = 0
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", {st_mode=S_IFREG|0664, st_size=41, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", O_RDONLY) = 6
10888 read(6, "1bd44cb9d13204b0fe1958db0082f502"..., 255) = 41
10888 read(6, "", 214)                  = 0
10888 close(6)                          = 0
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/HEAD", 0x7fff611375f0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/tags/HEAD", 0x7fff611375f0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/HEAD", 0x7fff611375f0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/remotes/HEAD", 0x7fff611375f0) = -1 ENOENT (No such file or directory)
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/remotes/HEAD/HEAD", 0x7fff611375f0) = -1 ENOENT (No such file or directory)
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/1b/d44cb9d13204b0fe1958db0082f5028a16eb3a", {st_mode=S_IFREG|0444, st_size=136, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/1b/d44cb9d13204b0fe1958db0082f5028a16eb3a", O_RDONLY|O_NOATIME) = 6
10888 mmap(NULL, 136, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2b064998f000
10888 close(6)                          = 0
10888 munmap(0x2b064998f000, 136)       = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/1b/d44cb9d13204b0fe1958db0082f5028a16eb3a", {st_mode=S_IFREG|0444, st_size=136, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/1b/d44cb9d13204b0fe1958db0082f5028a16eb3a", O_RDONLY|O_NOATIME) = 6
10888 mmap(NULL, 136, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2b064998f000
10888 close(6)                          = 0
10888 munmap(0x2b064998f000, 136)       = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/next-index-10888.lock", O_RDONLY) = 6
10888 fstat(6, {st_mode=S_IFREG|0664, st_size=176, ...}) = 0
10888 mmap(NULL, 176, PROT_READ|PROT_WRITE, MAP_PRIVATE, 6, 0) = 0x2b064998f000
10888 close(6)                          = 0
10888 munmap(0x2b064998f000, 176)       = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391", {st_mode=S_IFREG|0444, st_size=15, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391", {st_mode=S_IFREG|0444, st_size=15, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/a7/3843106991cb043bd823dd0bf7c821354cc125", 0x7fff611379b0) = -1 ENOENT (No such file or directory)
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/a7/3843106991cb043bd823dd0bf7c821354cc125", O_RDONLY) = -1 ENOENT (No such file or directory)
10888 gettimeofday({1200903094, 936786}, NULL) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/tmp_obj_p1kDCU", O_RDWR|O_CREAT|O_EXCL, 0600) = 6
10888 brk(0x75a000)                     = 0x75a000
10888 brk(0x74a000)                     = 0x74a000
10888 brk(0x73a000)                     = 0x73a000
10888 brk(0x738000)                     = 0x738000
10888 write(6, "x\1+)JMU03a040031QH\315\311Lcx6\367\321\354M\27\2579{"..., 57) = 57
10888 fchmod(6, 0444)                   = 0
10888 close(6)                          = 0
10888 link("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/tmp_obj_p1kDCU", "/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/a7/3843106991cb043bd823dd0bf7c821354cc125") = -1 ENOENT (No such file or directory)
10888 mkdir("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/a7", 0777) = 0
10888 link("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/tmp_obj_p1kDCU", "/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/a7/3843106991cb043bd823dd0bf7c821354cc125") = 0
10888 unlink("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/tmp_obj_p1kDCU") = 0
10888 brk(0x736000)                     = 0x736000
10888 getuid()                          = 1012
10888 socket(PF_FILE, SOCK_STREAM, 0)   = 6
10888 fcntl(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0
10888 connect(6, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
10888 close(6)                          = 0
10888 socket(PF_FILE, SOCK_STREAM, 0)   = 6
10888 fcntl(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0
10888 connect(6, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
10888 close(6)                          = 0
10888 open("/etc/nsswitch.conf", O_RDONLY) = 6
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=465, ...}) = 0
10888 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b064998f000
10888 read(6, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 465
10888 read(6, "", 4096)                 = 0
10888 close(6)                          = 0
10888 munmap(0x2b064998f000, 4096)      = 0
10888 open("/etc/ld.so.cache", O_RDONLY) = 6
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=70263, ...}) = 0
10888 mmap(NULL, 70263, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2b064998f000
10888 close(6)                          = 0
10888 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10888 open("/lib/libnss_compat.so.2", O_RDONLY) = 6
10888 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\23\0"..., 832) = 832
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=35632, ...}) = 0
10888 mmap(NULL, 2131176, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2b064b4fb000
10888 mprotect(0x2b064b502000, 2097152, PROT_NONE) = 0
10888 mmap(0x2b064b702000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x7000) = 0x2b064b702000
10888 close(6)                          = 0
10888 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10888 open("/lib/libnsl.so.1", O_RDONLY) = 6
10888 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0A\0\0\0"..., 832) = 832
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=93088, ...}) = 0
10888 mmap(NULL, 2198224, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2b064b704000
10888 mprotect(0x2b064b719000, 2097152, PROT_NONE) = 0
10888 mmap(0x2b064b919000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x15000) = 0x2b064b919000
10888 mmap(0x2b064b91b000, 6864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2b064b91b000
10888 close(6)                          = 0
10888 munmap(0x2b064998f000, 70263)     = 0
10888 open("/etc/ld.so.cache", O_RDONLY) = 6
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=70263, ...}) = 0
10888 mmap(NULL, 70263, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2b064998f000
10888 close(6)                          = 0
10888 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10888 open("/lib/libnss_nis.so.2", O_RDONLY) = 6
10888 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000 \0\0"..., 832) = 832
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=43480, ...}) = 0
10888 mmap(NULL, 2139352, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2b064b91d000
10888 mprotect(0x2b064b927000, 2093056, PROT_NONE) = 0
10888 mmap(0x2b064bb26000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x9000) = 0x2b064bb26000
10888 close(6)                          = 0
10888 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10888 open("/lib/libnss_files.so.2", O_RDONLY) = 6
10888 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P \0\0\0"..., 832) = 832
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=43448, ...}) = 0
10888 mmap(NULL, 2139464, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2b064bb28000
10888 mprotect(0x2b064bb32000, 2093056, PROT_NONE) = 0
10888 mmap(0x2b064bd31000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x9000) = 0x2b064bd31000
10888 close(6)                          = 0
10888 munmap(0x2b064998f000, 70263)     = 0
10888 open("/etc/passwd", O_RDONLY)     = 6
10888 fcntl(6, F_GETFD)                 = 0
10888 fcntl(6, F_SETFD, FD_CLOEXEC)     = 0
10888 lseek(6, 0, SEEK_CUR)             = 0
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=1663, ...}) = 0
10888 mmap(NULL, 1663, PROT_READ, MAP_SHARED, 6, 0) = 0x2b064998f000
10888 lseek(6, 1663, SEEK_SET)          = 1663
10888 munmap(0x2b064998f000, 1663)      = 0
10888 close(6)                          = 0
10888 uname({sys="Linux", node="gitster", ...}) = 0
10888 open("/etc/resolv.conf", O_RDONLY) = 6
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=44, ...}) = 0
10888 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b064998f000
10888 read(6, "search pv.oc.cox.net\nnameserver "..., 4096) = 44
10888 read(6, "", 4096)                 = 0
10888 close(6)                          = 0
10888 munmap(0x2b064998f000, 4096)      = 0
10888 stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=44, ...}) = 0
10888 open("/etc/resolv.conf", O_RDONLY) = 6
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=44, ...}) = 0
10888 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b064998f000
10888 read(6, "search pv.oc.cox.net\nnameserver "..., 4096) = 44
10888 read(6, "", 4096)                 = 0
10888 close(6)                          = 0
10888 munmap(0x2b064998f000, 4096)      = 0
10888 socket(PF_FILE, SOCK_STREAM, 0)   = 6
10888 fcntl(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0
10888 connect(6, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
10888 close(6)                          = 0
10888 socket(PF_FILE, SOCK_STREAM, 0)   = 6
10888 fcntl(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0
10888 connect(6, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
10888 close(6)                          = 0
10888 open("/etc/host.conf", O_RDONLY)  = 6
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=9, ...}) = 0
10888 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b064998f000
10888 read(6, "multi on\n", 4096)       = 9
10888 read(6, "", 4096)                 = 0
10888 close(6)                          = 0
10888 munmap(0x2b064998f000, 4096)      = 0
10888 open("/etc/hosts", O_RDONLY)      = 6
10888 fcntl(6, F_GETFD)                 = 0
10888 fcntl(6, F_SETFD, FD_CLOEXEC)     = 0
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=570, ...}) = 0
10888 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b064998f000
10888 read(6, "127.0.0.1\tlocalhost\n#127.0.1.1\tg"..., 4096) = 570
10888 read(6, "", 4096)                 = 0
10888 close(6)                          = 0
10888 munmap(0x2b064998f000, 4096)      = 0
10888 gettimeofday({1200903094, 941441}, NULL) = 0
10888 open("/usr/share/zoneinfo/UTC", O_RDONLY) = 6
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
10888 fstat(6, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
10888 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b064998f000
10888 read(6, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0"..., 4096) = 118
10888 lseek(6, -62, SEEK_CUR)           = 56
10888 read(6, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0"..., 4096) = 62
10888 close(6)                          = 0
10888 munmap(0x2b064998f000, 4096)      = 0
10888 access("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/hooks/commit-msg", X_OK) = -1 ENOENT (No such file or directory)
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/COMMIT_EDITMSG", O_RDONLY) = 6
10888 read(6, "Partial: add elif\n", 8192) = 18
10888 read(6, "", 12400)                = 0
10888 close(6)                          = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/c1/7ca051cb2649d9f7bed8021db2cfc08eb9b330", 0x7fff61137ad0) = -1 ENOENT (No such file or directory)
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/c1/7ca051cb2649d9f7bed8021db2cfc08eb9b330", O_RDONLY) = -1 ENOENT (No such file or directory)
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/tmp_obj_BZH0dB", O_RDWR|O_CREAT|O_EXCL, 0600) = 6
10888 brk(0x75c000)                     = 0x75c000
10888 brk(0x74c000)                     = 0x74c000
10888 brk(0x73c000)                     = 0x73c000
10888 brk(0x73b000)                     = 0x73b000
10888 write(6, "x\1\205\316A\212\0021\20\205a\3279E]@\251\252$v\"2\214"..., 174) = 174
10888 fchmod(6, 0444)                   = 0
10888 close(6)                          = 0
10888 link("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/tmp_obj_BZH0dB", "/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/c1/7ca051cb2649d9f7bed8021db2cfc08eb9b330") = -1 ENOENT (No such file or directory)
10888 mkdir("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/c1", 0777) = 0
10888 link("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/tmp_obj_BZH0dB", "/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/c1/7ca051cb2649d9f7bed8021db2cfc08eb9b330") = 0
10888 unlink("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/tmp_obj_BZH0dB") = 0
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/HEAD", {st_mode=S_IFREG|0664, st_size=23, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/HEAD", O_RDONLY) = 6
10888 read(6, "ref: refs/heads/master\n", 255) = 23
10888 read(6, "", 232)                  = 0
10888 close(6)                          = 0
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", {st_mode=S_IFREG|0664, st_size=41, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", O_RDONLY) = 6
10888 read(6, "1bd44cb9d13204b0fe1958db0082f502"..., 255) = 41
10888 read(6, "", 214)                  = 0
10888 close(6)                          = 0
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", {st_mode=S_IFREG|0664, st_size=41, ...}) = 0
10888 stat("/opt", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
10888 stat("/opt/packrat", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen/public", {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place", {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio", {st_mode=S_IFDIR|S_ISGID|0775, st_size=98304, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t", {st_mode=S_IFDIR|S_ISGID|0775, st_size=8192, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 readlink("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", 0x7fff61136b70, 4096) = -1 EINVAL (Invalid argument)
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master.lock", O_RDWR|O_CREAT|O_EXCL, 0666) = 6
10888 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", {st_mode=S_IFREG|0664, st_size=41, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", O_RDONLY) = 7
10888 read(7, "1bd44cb9d13204b0fe1958db0082f502"..., 255) = 41
10888 read(7, "", 214)                  = 0
10888 close(7)                          = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/c1/7ca051cb2649d9f7bed8021db2cfc08eb9b330", {st_mode=S_IFREG|0444, st_size=174, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/c1/7ca051cb2649d9f7bed8021db2cfc08eb9b330", O_RDONLY|O_NOATIME) = 7
10888 mmap(NULL, 174, PROT_READ, MAP_PRIVATE, 7, 0) = 0x2b064998f000
10888 close(7)                          = 0
10888 munmap(0x2b064998f000, 174)       = 0
10888 write(6, "c17ca051cb2649d9f7bed8021db2cfc0"..., 40) = 40
10888 write(6, "\n", 1)                 = 1
10888 close(6)                          = 0
10888 stat("/opt", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
10888 stat("/opt/packrat", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen/public", {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place", {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio", {st_mode=S_IFDIR|S_ISGID|0775, st_size=98304, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t", {st_mode=S_IFDIR|S_ISGID|0775, st_size=8192, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/logs", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/logs/refs", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/logs/refs/heads", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/logs/refs/heads/master", O_WRONLY|O_APPEND|O_CREAT, 0666) = 6
10888 write(6, "1bd44cb9d13204b0fe1958db0082f502"..., 160) = 160
10888 close(6)                          = 0
10888 stat("/opt", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
10888 stat("/opt/packrat", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen/public", {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place", {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio", {st_mode=S_IFDIR|S_ISGID|0775, st_size=98304, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t", {st_mode=S_IFDIR|S_ISGID|0775, st_size=8192, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/logs", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/logs/HEAD", O_WRONLY|O_APPEND|O_CREAT, 0666) = 6
10888 write(6, "1bd44cb9d13204b0fe1958db0082f502"..., 160) = 160
10888 close(6)                          = 0
10888 rename("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master.lock", "/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master") = 0
10888 unlink("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/MERGE_HEAD") = -1 ENOENT (No such file or directory)
10888 unlink("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/MERGE_MSG") = -1 ENOENT (No such file or directory)
10888 rename("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/index.lock", "/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/index") = 0
10888 unlink("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/next-index-10888.lock") = 0
10888 open(".git/config", O_RDONLY)     = 6
10888 fstat(6, {st_mode=S_IFREG|0664, st_size=92, ...}) = 0
10888 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b064998f000
10888 read(6, "[core]\n\trepositoryformatversion "..., 4096) = 92
10888 read(6, "", 4096)                 = 0
10888 close(6)                          = 0
10888 munmap(0x2b064998f000, 4096)      = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/rr-cache", 0x7fff61137b90) = -1 ENOENT (No such file or directory)
10888 access("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/hooks/post-commit", X_OK) = -1 ENOENT (No such file or directory)
10888 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 6), ...}) = 0
10888 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b064998f000
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/1b/d44cb9d13204b0fe1958db0082f5028a16eb3a", {st_mode=S_IFREG|0444, st_size=136, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/1b/d44cb9d13204b0fe1958db0082f5028a16eb3a", O_RDONLY|O_NOATIME) = 6
10888 mmap(NULL, 136, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2b0649990000
10888 close(6)                          = 0
10888 munmap(0x2b0649990000, 136)       = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/df/2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078", {st_mode=S_IFREG|0444, st_size=49, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/df/2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078", O_RDONLY|O_NOATIME) = 6
10888 mmap(NULL, 49, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2b0649990000
10888 close(6)                          = 0
10888 munmap(0x2b0649990000, 49)        = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/c1/7ca051cb2649d9f7bed8021db2cfc08eb9b330", {st_mode=S_IFREG|0444, st_size=174, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/c1/7ca051cb2649d9f7bed8021db2cfc08eb9b330", O_RDONLY|O_NOATIME) = 6
10888 mmap(NULL, 174, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2b0649990000
10888 close(6)                          = 0
10888 munmap(0x2b0649990000, 174)       = 0
10888 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/a7/3843106991cb043bd823dd0bf7c821354cc125", {st_mode=S_IFREG|0444, st_size=57, ...}) = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/a7/3843106991cb043bd823dd0bf7c821354cc125", O_RDONLY|O_NOATIME) = 6
10888 mmap(NULL, 57, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2b0649990000
10888 close(6)                          = 0
10888 munmap(0x2b0649990000, 57)        = 0
10888 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/c1/", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 6
10888 fstat(6, {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10888 fcntl(6, F_SETFD, FD_CLOEXEC)     = 0
10888 getdents(6, /* 3 entries */, 4096) = 112
10888 getdents(6, /* 0 entries */, 4096) = 0
10888 close(6)                          = 0
10888 write(1, "Created commit c17ca05: Partial:"..., 42) = 42
10888 lstat("elif", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
10888 open("elif", O_RDONLY)            = 6
10888 close(6)                          = 0
10888 lstat("elif", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
10888 write(1, " 0 files changed, 0 insertions(+"..., 50) = 50
10888 write(1, " create mode 100644 elif\n", 25) = 25
10888 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 6), ...}) = 0
10888 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 6), ...}) = 0
10888 close(1)                          = 0
10888 munmap(0x2b064998f000, 4096)      = 0
10888 exit_group(0)                     = ?

[-- Attachment #4: strace output from a bad run --]
[-- Type: text/plain, Size: 46509 bytes --]

10922 execve("/opt/packrat/playpen/public/in-place/git/git.junio/t/../git", ["git", "commit", "-m", "Partial: add elif", "elif"], [/* 51 vars */]) = 0
10922 brk(0)                            = 0x6f7000
10922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac02877e000
10922 uname({sys="Linux", node="gitster", ...}) = 0
10922 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10922 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac02877f000
10922 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
10922 open("/etc/ld.so.cache", O_RDONLY) = 6
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=70263, ...}) = 0
10922 mmap(NULL, 70263, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2ac028781000
10922 close(6)                          = 0
10922 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10922 open("/usr/lib/libcurl.so.3", O_RDONLY) = 6
10922 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`m\0\0\0"..., 832) = 832
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=227856, ...}) = 0
10922 mmap(NULL, 1275080, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2ac028793000
10922 mprotect(0x2ac0287c9000, 1048576, PROT_NONE) = 0
10922 mmap(0x2ac0288c9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x36000) = 0x2ac0288c9000
10922 close(6)                          = 0
10922 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10922 open("/usr/lib/libz.so.1", O_RDONLY) = 6
10922 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@!\0\0\0"..., 832) = 832
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=93504, ...}) = 0
10922 mmap(NULL, 2188616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2ac02897f000
10922 mprotect(0x2ac028995000, 2097152, PROT_NONE) = 0
10922 mmap(0x2ac028b95000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x16000) = 0x2ac028b95000
10922 close(6)                          = 0
10922 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10922 open("/usr/lib/libcrypto.so.0.9.8", O_RDONLY) = 6
10922 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\364"..., 832) = 832
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=1510344, ...}) = 0
10922 mmap(NULL, 2571832, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2ac028b96000
10922 mprotect(0x2ac028ce4000, 1048576, PROT_NONE) = 0
10922 mmap(0x2ac028de4000, 143360, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x14e000) = 0x2ac028de4000
10922 mmap(0x2ac028e07000, 11832, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ac028e07000
10922 close(6)                          = 0
10922 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10922 open("/lib/libc.so.6", O_RDONLY)  = 6
10922 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\334\1\0"..., 832) = 832
10922 fstat(6, {st_mode=S_IFREG|0755, st_size=1391928, ...}) = 0
10922 mmap(NULL, 3498360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2ac028e0a000
10922 mprotect(0x2ac028f57000, 2097152, PROT_NONE) = 0
10922 mmap(0x2ac029157000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x14d000) = 0x2ac029157000
10922 mmap(0x2ac02915c000, 16760, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ac02915c000
10922 close(6)                          = 0
10922 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10922 open("/usr/lib/libgssapi_krb5.so.2", O_RDONLY) = 6
10922 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20e\0\0"..., 832) = 832
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=173640, ...}) = 0
10922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac029161000
10922 mmap(NULL, 2269136, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2ac029162000
10922 mprotect(0x2ac02918b000, 2093056, PROT_NONE) = 0
10922 mmap(0x2ac02938a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x28000) = 0x2ac02938a000
10922 close(6)                          = 0
10922 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10922 open("/usr/lib/libkrb5.so.3", O_RDONLY) = 6
10922 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\221"..., 832) = 832
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=635688, ...}) = 0
10922 mmap(NULL, 2730976, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2ac02938c000
10922 mprotect(0x2ac029423000, 2097152, PROT_NONE) = 0
10922 mmap(0x2ac029623000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x97000) = 0x2ac029623000
10922 close(6)                          = 0
10922 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10922 open("/usr/lib/libk5crypto.so.3", O_RDONLY) = 6
10922 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320X\0\0"..., 832) = 832
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=150656, ...}) = 0
10922 mmap(NULL, 2246952, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2ac029627000
10922 mprotect(0x2ac02964a000, 2097152, PROT_NONE) = 0
10922 mmap(0x2ac02984a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x23000) = 0x2ac02984a000
10922 close(6)                          = 0
10922 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10922 open("/lib/libcom_err.so.2", O_RDONLY) = 6
10922 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\f\0"..., 832) = 832
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=7984, ...}) = 0
10922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac02984c000
10922 mmap(NULL, 1054920, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2ac02984d000
10922 mprotect(0x2ac02984f000, 1044480, PROT_NONE) = 0
10922 mmap(0x2ac02994e000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x1000) = 0x2ac02994e000
10922 close(6)                          = 0
10922 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10922 open("/usr/lib/libkrb5support.so.0", O_RDONLY) = 6
10922 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\35\0"..., 832) = 832
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=30408, ...}) = 0
10922 mmap(NULL, 2125648, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2ac02994f000
10922 mprotect(0x2ac029956000, 2093056, PROT_NONE) = 0
10922 mmap(0x2ac029b55000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x6000) = 0x2ac029b55000
10922 close(6)                          = 0
10922 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10922 open("/lib/libresolv.so.2", O_RDONLY) = 6
10922 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0003\0\0"..., 832) = 832
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=76664, ...}) = 0
10922 mmap(NULL, 2181896, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2ac029b56000
10922 mprotect(0x2ac029b67000, 2097152, PROT_NONE) = 0
10922 mmap(0x2ac029d67000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x11000) = 0x2ac029d67000
10922 mmap(0x2ac029d69000, 6920, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ac029d69000
10922 close(6)                          = 0
10922 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10922 open("/usr/lib/libidn.so.11", O_RDONLY) = 6
10922 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340/\0\0"..., 832) = 832
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=202368, ...}) = 0
10922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac029d6b000
10922 mmap(NULL, 1249152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2ac029d6c000
10922 mprotect(0x2ac029d9d000, 1044480, PROT_NONE) = 0
10922 mmap(0x2ac029e9c000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x30000) = 0x2ac029e9c000
10922 close(6)                          = 0
10922 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10922 open("/lib/libdl.so.2", O_RDONLY) = 6
10922 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \16\0\0"..., 832) = 832
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=14624, ...}) = 0
10922 mmap(NULL, 2109728, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2ac029e9d000
10922 mprotect(0x2ac029e9f000, 2097152, PROT_NONE) = 0
10922 mmap(0x2ac02a09f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x2000) = 0x2ac02a09f000
10922 close(6)                          = 0
10922 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10922 open("/usr/lib/libssl.so.0.9.8", O_RDONLY) = 6
10922 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\31\1"..., 832) = 832
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=291816, ...}) = 0
10922 mmap(NULL, 1338608, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2ac02a0a1000
10922 mprotect(0x2ac02a0e2000, 1048576, PROT_NONE) = 0
10922 mmap(0x2ac02a1e2000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x41000) = 0x2ac02a1e2000
10922 close(6)                          = 0
10922 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10922 open("/lib/libkeyutils.so.1", O_RDONLY) = 6
10922 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\v\0"..., 832) = 832
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=7304, ...}) = 0
10922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac02a1e8000
10922 mmap(NULL, 1054160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2ac02a1e9000
10922 mprotect(0x2ac02a1eb000, 1044480, PROT_NONE) = 0
10922 mmap(0x2ac02a2ea000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x1000) = 0x2ac02a2ea000
10922 close(6)                          = 0
10922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac02a2eb000
10922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac02a2ec000
10922 arch_prctl(ARCH_SET_FS, 0x2ac02a2ebf10) = 0
10922 mprotect(0x2ac029157000, 12288, PROT_READ) = 0
10922 munmap(0x2ac028781000, 70263)     = 0
10922 brk(0)                            = 0x6f7000
10922 brk(0x718000)                     = 0x718000
10922 getcwd("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash", 4096) = 59
10922 access(".git/objects", X_OK)      = 0
10922 access(".git/refs", X_OK)         = 0
10922 lstat(".git/HEAD", {st_mode=S_IFREG|0664, st_size=23, ...}) = 0
10922 open(".git/HEAD", O_RDONLY)       = 6
10922 read(6, "ref: refs/heads/master\n", 255) = 23
10922 read(6, "", 232)                  = 0
10922 close(6)                          = 0
10922 open(".git/config", O_RDONLY)     = 6
10922 fstat(6, {st_mode=S_IFREG|0664, st_size=92, ...}) = 0
10922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac028781000
10922 read(6, "[core]\n\trepositoryformatversion "..., 4096) = 92
10922 read(6, "", 4096)                 = 0
10922 close(6)                          = 0
10922 munmap(0x2ac028781000, 4096)      = 0
10922 stat(".git", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 getcwd("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash", 1024) = 59
10922 chdir(".git")                     = 0
10922 getcwd("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git", 4096) = 64
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 chdir("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash") = 0
10922 chdir("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash") = 0
10922 open(".git/config", O_RDONLY)     = 6
10922 fstat(6, {st_mode=S_IFREG|0664, st_size=92, ...}) = 0
10922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac028781000
10922 read(6, "[core]\n\trepositoryformatversion "..., 4096) = 92
10922 read(6, "", 4096)                 = 0
10922 close(6)                          = 0
10922 munmap(0x2ac028781000, 4096)      = 0
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/HEAD", {st_mode=S_IFREG|0664, st_size=23, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/HEAD", O_RDONLY) = 6
10922 read(6, "ref: refs/heads/master\n", 255) = 23
10922 read(6, "", 232)                  = 0
10922 close(6)                          = 0
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", {st_mode=S_IFREG|0664, st_size=41, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", O_RDONLY) = 6
10922 read(6, "1bd44cb9d13204b0fe1958db0082f502"..., 255) = 41
10922 read(6, "", 214)                  = 0
10922 close(6)                          = 0
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/HEAD", 0x7fff82343bd0) = -1 ENOENT (No such file or directory)
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/packed-refs", O_RDONLY) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/tags/HEAD", 0x7fff82343bd0) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/HEAD", 0x7fff82343bd0) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/remotes/HEAD", 0x7fff82343bd0) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/remotes/HEAD/HEAD", 0x7fff82343bd0) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/MERGE_HEAD", 0x7fff82343bd0) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/MERGE_HEAD", 0x7fff82343bd0) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/tags/MERGE_HEAD", 0x7fff82343bd0) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/MERGE_HEAD", 0x7fff82343bd0) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/remotes/MERGE_HEAD", 0x7fff82343bd0) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/remotes/MERGE_HEAD/HEAD", 0x7fff82343bd0) = -1 ENOENT (No such file or directory)
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/index", O_RDONLY) = 6
10922 fstat(6, {st_mode=S_IFREG|0664, st_size=104, ...}) = 0
10922 mmap(NULL, 104, PROT_READ|PROT_WRITE, MAP_PRIVATE, 6, 0) = 0x2ac028781000
10922 close(6)                          = 0
10922 munmap(0x2ac028781000, 104)       = 0
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/MERGE_HEAD", 0x7fff82343d40) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/HEAD", {st_mode=S_IFREG|0664, st_size=23, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/HEAD", O_RDONLY) = 6
10922 read(6, "ref: refs/heads/master\n", 255) = 23
10922 read(6, "", 232)                  = 0
10922 close(6)                          = 0
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", {st_mode=S_IFREG|0664, st_size=41, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", O_RDONLY) = 6
10922 read(6, "1bd44cb9d13204b0fe1958db0082f502"..., 255) = 41
10922 read(6, "", 214)                  = 0
10922 close(6)                          = 0
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/HEAD", 0x7fff82343b00) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/tags/HEAD", 0x7fff82343b00) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/HEAD", 0x7fff82343b00) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/remotes/HEAD", 0x7fff82343b00) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/remotes/HEAD/HEAD", 0x7fff82343b00) = -1 ENOENT (No such file or directory)
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/pack", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 6
10922 fstat(6, {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 fcntl(6, F_SETFD, FD_CLOEXEC)     = 0
10922 getdents(6, /* 2 entries */, 4096) = 48
10922 getdents(6, /* 0 entries */, 4096) = 0
10922 close(6)                          = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/info/alternates", O_RDONLY) = -1 ENOENT (No such file or directory)
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/1b/d44cb9d13204b0fe1958db0082f5028a16eb3a", {st_mode=S_IFREG|0444, st_size=136, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/1b/d44cb9d13204b0fe1958db0082f5028a16eb3a", O_RDONLY|O_NOATIME) = 6
10922 mmap(NULL, 136, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2ac028781000
10922 close(6)                          = 0
10922 munmap(0x2ac028781000, 136)       = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/info/grafts", O_RDONLY) = -1 ENOENT (No such file or directory)
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/shallow", O_RDONLY) = -1 ENOENT (No such file or directory)
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/df/2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078", {st_mode=S_IFREG|0444, st_size=49, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/df/2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078", O_RDONLY|O_NOATIME) = 6
10922 mmap(NULL, 49, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2ac028781000
10922 close(6)                          = 0
10922 brk(0x739000)                     = 0x739000
10922 brk(0x736000)                     = 0x736000
10922 munmap(0x2ac028781000, 49)        = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/index", O_RDONLY) = 6
10922 fstat(6, {st_mode=S_IFREG|0664, st_size=104, ...}) = 0
10922 mmap(NULL, 104, PROT_READ|PROT_WRITE, MAP_PRIVATE, 6, 0) = 0x2ac028781000
10922 close(6)                          = 0
10922 munmap(0x2ac028781000, 104)       = 0
10922 readlink("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/index", 0x7fff82342da0, 4096) = -1 EINVAL (Invalid argument)
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/index.lock", O_RDWR|O_CREAT|O_EXCL, 0666) = 6
10922 rt_sigaction(SIGINT, {0x44bc70, [INT], SA_RESTORER|SA_RESTART, 0x2ac028e3b6a0}, {SIG_DFL}, 8) = 0
10922 getpid()                          = 10922
10922 lstat("elif", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
10922 lstat("elif", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
10922 lstat("elif", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
10922 write(6, "DIRC\0\0\0\2\0\0\0\1G\224S\267\0\0\0\0G\224S\266\0\0\0"..., 104) = 104
10922 close(6)                          = 0
10922 readlink("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/next-index-10922", 0x7fff82342da0, 4096) = -1 ENOENT (No such file or directory)
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/next-index-10922.lock", O_RDWR|O_CREAT|O_EXCL, 0666) = 6
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/1b/d44cb9d13204b0fe1958db0082f5028a16eb3a", {st_mode=S_IFREG|0444, st_size=136, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/1b/d44cb9d13204b0fe1958db0082f5028a16eb3a", O_RDONLY|O_NOATIME) = 7
10922 mmap(NULL, 136, PROT_READ, MAP_PRIVATE, 7, 0) = 0x2ac028781000
10922 close(7)                          = 0
10922 munmap(0x2ac028781000, 136)       = 0
10922 lstat("elif", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
10922 lstat("elif", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
10922 lstat("elif", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
10922 lstat("file", 0x7fff82343c90)     = -1 ENOENT (No such file or directory)
10922 write(6, "DIRC\0\0\0\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 104) = 104
10922 close(6)                          = 0
10922 access("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/hooks/pre-commit", X_OK) = -1 ENOENT (No such file or directory)
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/COMMIT_EDITMSG", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 6
10922 fstat(6, {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
10922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac028781000
10922 write(6, "Partial: add elif\n", 18) = 18
10922 close(6)                          = 0
10922 munmap(0x2ac028781000, 4096)      = 0
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/HEAD", {st_mode=S_IFREG|0664, st_size=23, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/HEAD", O_RDONLY) = 6
10922 read(6, "ref: refs/heads/master\n", 255) = 23
10922 read(6, "", 232)                  = 0
10922 close(6)                          = 0
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", {st_mode=S_IFREG|0664, st_size=41, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", O_RDONLY) = 6
10922 read(6, "1bd44cb9d13204b0fe1958db0082f502"..., 255) = 41
10922 read(6, "", 214)                  = 0
10922 close(6)                          = 0
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/HEAD", 0x7fff823438b0) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/tags/HEAD", 0x7fff823438b0) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/HEAD", 0x7fff823438b0) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/remotes/HEAD", 0x7fff823438b0) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/remotes/HEAD/HEAD", 0x7fff823438b0) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/HEAD", {st_mode=S_IFREG|0664, st_size=23, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/HEAD", O_RDONLY) = 6
10922 read(6, "ref: refs/heads/master\n", 255) = 23
10922 read(6, "", 232)                  = 0
10922 close(6)                          = 0
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", {st_mode=S_IFREG|0664, st_size=41, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", O_RDONLY) = 6
10922 read(6, "1bd44cb9d13204b0fe1958db0082f502"..., 255) = 41
10922 read(6, "", 214)                  = 0
10922 close(6)                          = 0
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/HEAD", 0x7fff82343800) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/tags/HEAD", 0x7fff82343800) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/HEAD", 0x7fff82343800) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/remotes/HEAD", 0x7fff82343800) = -1 ENOENT (No such file or directory)
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/remotes/HEAD/HEAD", 0x7fff82343800) = -1 ENOENT (No such file or directory)
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/1b/d44cb9d13204b0fe1958db0082f5028a16eb3a", {st_mode=S_IFREG|0444, st_size=136, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/1b/d44cb9d13204b0fe1958db0082f5028a16eb3a", O_RDONLY|O_NOATIME) = 6
10922 mmap(NULL, 136, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2ac028781000
10922 close(6)                          = 0
10922 munmap(0x2ac028781000, 136)       = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/1b/d44cb9d13204b0fe1958db0082f5028a16eb3a", {st_mode=S_IFREG|0444, st_size=136, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/1b/d44cb9d13204b0fe1958db0082f5028a16eb3a", O_RDONLY|O_NOATIME) = 6
10922 mmap(NULL, 136, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2ac028781000
10922 close(6)                          = 0
10922 munmap(0x2ac028781000, 136)       = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/next-index-10922.lock", O_RDONLY) = 6
10922 fstat(6, {st_mode=S_IFREG|0664, st_size=104, ...}) = 0
10922 mmap(NULL, 104, PROT_READ|PROT_WRITE, MAP_PRIVATE, 6, 0) = 0x2ac028781000
10922 close(6)                          = 0
10922 munmap(0x2ac028781000, 104)       = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391", {st_mode=S_IFREG|0444, st_size=15, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/df/2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078", {st_mode=S_IFREG|0444, st_size=49, ...}) = 0
10922 getuid()                          = 1012
10922 socket(PF_FILE, SOCK_STREAM, 0)   = 6
10922 fcntl(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0
10922 connect(6, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
10922 close(6)                          = 0
10922 socket(PF_FILE, SOCK_STREAM, 0)   = 6
10922 fcntl(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0
10922 connect(6, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
10922 close(6)                          = 0
10922 open("/etc/nsswitch.conf", O_RDONLY) = 6
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=465, ...}) = 0
10922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac028781000
10922 read(6, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 465
10922 read(6, "", 4096)                 = 0
10922 close(6)                          = 0
10922 munmap(0x2ac028781000, 4096)      = 0
10922 open("/etc/ld.so.cache", O_RDONLY) = 6
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=70263, ...}) = 0
10922 mmap(NULL, 70263, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2ac028781000
10922 close(6)                          = 0
10922 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10922 open("/lib/libnss_compat.so.2", O_RDONLY) = 6
10922 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\23\0"..., 832) = 832
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=35632, ...}) = 0
10922 mmap(NULL, 2131176, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2ac02a2ed000
10922 mprotect(0x2ac02a2f4000, 2097152, PROT_NONE) = 0
10922 mmap(0x2ac02a4f4000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x7000) = 0x2ac02a4f4000
10922 close(6)                          = 0
10922 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10922 open("/lib/libnsl.so.1", O_RDONLY) = 6
10922 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0A\0\0\0"..., 832) = 832
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=93088, ...}) = 0
10922 mmap(NULL, 2198224, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2ac02a4f6000
10922 mprotect(0x2ac02a50b000, 2097152, PROT_NONE) = 0
10922 mmap(0x2ac02a70b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x15000) = 0x2ac02a70b000
10922 mmap(0x2ac02a70d000, 6864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ac02a70d000
10922 close(6)                          = 0
10922 munmap(0x2ac028781000, 70263)     = 0
10922 open("/etc/ld.so.cache", O_RDONLY) = 6
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=70263, ...}) = 0
10922 mmap(NULL, 70263, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2ac028781000
10922 close(6)                          = 0
10922 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10922 open("/lib/libnss_nis.so.2", O_RDONLY) = 6
10922 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000 \0\0"..., 832) = 832
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=43480, ...}) = 0
10922 mmap(NULL, 2139352, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2ac02a70f000
10922 mprotect(0x2ac02a719000, 2093056, PROT_NONE) = 0
10922 mmap(0x2ac02a918000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x9000) = 0x2ac02a918000
10922 close(6)                          = 0
10922 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
10922 open("/lib/libnss_files.so.2", O_RDONLY) = 6
10922 read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P \0\0\0"..., 832) = 832
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=43448, ...}) = 0
10922 mmap(NULL, 2139464, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2ac02a91a000
10922 mprotect(0x2ac02a924000, 2093056, PROT_NONE) = 0
10922 mmap(0x2ac02ab23000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x9000) = 0x2ac02ab23000
10922 close(6)                          = 0
10922 munmap(0x2ac028781000, 70263)     = 0
10922 open("/etc/passwd", O_RDONLY)     = 6
10922 fcntl(6, F_GETFD)                 = 0
10922 fcntl(6, F_SETFD, FD_CLOEXEC)     = 0
10922 lseek(6, 0, SEEK_CUR)             = 0
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=1663, ...}) = 0
10922 mmap(NULL, 1663, PROT_READ, MAP_SHARED, 6, 0) = 0x2ac028781000
10922 lseek(6, 1663, SEEK_SET)          = 1663
10922 munmap(0x2ac028781000, 1663)      = 0
10922 close(6)                          = 0
10922 uname({sys="Linux", node="gitster", ...}) = 0
10922 open("/etc/resolv.conf", O_RDONLY) = 6
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=44, ...}) = 0
10922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac028781000
10922 read(6, "search pv.oc.cox.net\nnameserver "..., 4096) = 44
10922 read(6, "", 4096)                 = 0
10922 close(6)                          = 0
10922 munmap(0x2ac028781000, 4096)      = 0
10922 stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=44, ...}) = 0
10922 open("/etc/resolv.conf", O_RDONLY) = 6
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=44, ...}) = 0
10922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac028781000
10922 read(6, "search pv.oc.cox.net\nnameserver "..., 4096) = 44
10922 read(6, "", 4096)                 = 0
10922 close(6)                          = 0
10922 munmap(0x2ac028781000, 4096)      = 0
10922 socket(PF_FILE, SOCK_STREAM, 0)   = 6
10922 fcntl(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0
10922 connect(6, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
10922 close(6)                          = 0
10922 socket(PF_FILE, SOCK_STREAM, 0)   = 6
10922 fcntl(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0
10922 connect(6, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
10922 close(6)                          = 0
10922 open("/etc/host.conf", O_RDONLY)  = 6
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=9, ...}) = 0
10922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac028781000
10922 read(6, "multi on\n", 4096)       = 9
10922 read(6, "", 4096)                 = 0
10922 close(6)                          = 0
10922 munmap(0x2ac028781000, 4096)      = 0
10922 open("/etc/hosts", O_RDONLY)      = 6
10922 fcntl(6, F_GETFD)                 = 0
10922 fcntl(6, F_SETFD, FD_CLOEXEC)     = 0
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=570, ...}) = 0
10922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac028781000
10922 read(6, "127.0.0.1\tlocalhost\n#127.0.1.1\tg"..., 4096) = 570
10922 read(6, "", 4096)                 = 0
10922 close(6)                          = 0
10922 munmap(0x2ac028781000, 4096)      = 0
10922 gettimeofday({1200903095, 36084}, NULL) = 0
10922 open("/usr/share/zoneinfo/UTC", O_RDONLY) = 6
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
10922 fstat(6, {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
10922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac028781000
10922 read(6, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0"..., 4096) = 118
10922 lseek(6, -62, SEEK_CUR)           = 56
10922 read(6, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0"..., 4096) = 62
10922 close(6)                          = 0
10922 munmap(0x2ac028781000, 4096)      = 0
10922 access("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/hooks/commit-msg", X_OK) = -1 ENOENT (No such file or directory)
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/COMMIT_EDITMSG", O_RDONLY) = 6
10922 read(6, "Partial: add elif\n", 8192) = 18
10922 read(6, "", 12400)                = 0
10922 close(6)                          = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/94/5b990ce4a77ccd314fbc9b33c5959023a92714", 0x7fff82343ce0) = -1 ENOENT (No such file or directory)
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/94/5b990ce4a77ccd314fbc9b33c5959023a92714", O_RDONLY) = -1 ENOENT (No such file or directory)
10922 gettimeofday({1200903095, 36797}, NULL) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/tmp_obj_bX9DDU", O_RDWR|O_CREAT|O_EXCL, 0600) = 6
10922 brk(0x75c000)                     = 0x75c000
10922 brk(0x74c000)                     = 0x74c000
10922 brk(0x73c000)                     = 0x73c000
10922 brk(0x73b000)                     = 0x73b000
10922 write(6, "x\1\205\316Aj\0031\f\205\341\254}\n]\240A\322\330\31;\204"..., 176) = 176
10922 fchmod(6, 0444)                   = 0
10922 close(6)                          = 0
10922 link("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/tmp_obj_bX9DDU", "/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/94/5b990ce4a77ccd314fbc9b33c5959023a92714") = -1 ENOENT (No such file or directory)
10922 mkdir("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/94", 0777) = 0
10922 link("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/tmp_obj_bX9DDU", "/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/94/5b990ce4a77ccd314fbc9b33c5959023a92714") = 0
10922 unlink("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/tmp_obj_bX9DDU") = 0
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/HEAD", {st_mode=S_IFREG|0664, st_size=23, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/HEAD", O_RDONLY) = 6
10922 read(6, "ref: refs/heads/master\n", 255) = 23
10922 read(6, "", 232)                  = 0
10922 close(6)                          = 0
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", {st_mode=S_IFREG|0664, st_size=41, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", O_RDONLY) = 6
10922 read(6, "1bd44cb9d13204b0fe1958db0082f502"..., 255) = 41
10922 read(6, "", 214)                  = 0
10922 close(6)                          = 0
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", {st_mode=S_IFREG|0664, st_size=41, ...}) = 0
10922 stat("/opt", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
10922 stat("/opt/packrat", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen/public", {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place", {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio", {st_mode=S_IFDIR|S_ISGID|0775, st_size=98304, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t", {st_mode=S_IFDIR|S_ISGID|0775, st_size=8192, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 readlink("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", 0x7fff82342d80, 4096) = -1 EINVAL (Invalid argument)
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master.lock", O_RDWR|O_CREAT|O_EXCL, 0666) = 6
10922 lstat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", {st_mode=S_IFREG|0664, st_size=41, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master", O_RDONLY) = 7
10922 read(7, "1bd44cb9d13204b0fe1958db0082f502"..., 255) = 41
10922 read(7, "", 214)                  = 0
10922 close(7)                          = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/94/5b990ce4a77ccd314fbc9b33c5959023a92714", {st_mode=S_IFREG|0444, st_size=176, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/94/5b990ce4a77ccd314fbc9b33c5959023a92714", O_RDONLY|O_NOATIME) = 7
10922 mmap(NULL, 176, PROT_READ, MAP_PRIVATE, 7, 0) = 0x2ac028781000
10922 close(7)                          = 0
10922 munmap(0x2ac028781000, 176)       = 0
10922 write(6, "945b990ce4a77ccd314fbc9b33c59590"..., 40) = 40
10922 write(6, "\n", 1)                 = 1
10922 close(6)                          = 0
10922 stat("/opt", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
10922 stat("/opt/packrat", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen/public", {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place", {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio", {st_mode=S_IFDIR|S_ISGID|0775, st_size=98304, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t", {st_mode=S_IFDIR|S_ISGID|0775, st_size=8192, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/logs", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/logs/refs", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/logs/refs/heads", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/logs/refs/heads/master", O_WRONLY|O_APPEND|O_CREAT, 0666) = 6
10922 write(6, "1bd44cb9d13204b0fe1958db0082f502"..., 160) = 160
10922 close(6)                          = 0
10922 stat("/opt", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
10922 stat("/opt/packrat", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen/public", {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place", {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio", {st_mode=S_IFDIR|S_ISGID|0775, st_size=98304, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t", {st_mode=S_IFDIR|S_ISGID|0775, st_size=8192, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/logs", {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/logs/HEAD", O_WRONLY|O_APPEND|O_CREAT, 0666) = 6
10922 write(6, "1bd44cb9d13204b0fe1958db0082f502"..., 160) = 160
10922 close(6)                          = 0
10922 rename("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master.lock", "/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/refs/heads/master") = 0
10922 unlink("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/MERGE_HEAD") = -1 ENOENT (No such file or directory)
10922 unlink("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/MERGE_MSG") = -1 ENOENT (No such file or directory)
10922 rename("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/index.lock", "/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/index") = 0
10922 unlink("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/next-index-10922.lock") = 0
10922 open(".git/config", O_RDONLY)     = 6
10922 fstat(6, {st_mode=S_IFREG|0664, st_size=92, ...}) = 0
10922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac028781000
10922 read(6, "[core]\n\trepositoryformatversion "..., 4096) = 92
10922 read(6, "", 4096)                 = 0
10922 close(6)                          = 0
10922 munmap(0x2ac028781000, 4096)      = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/rr-cache", 0x7fff82343da0) = -1 ENOENT (No such file or directory)
10922 access("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/hooks/post-commit", X_OK) = -1 ENOENT (No such file or directory)
10922 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 6), ...}) = 0
10922 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ac028781000
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/1b/d44cb9d13204b0fe1958db0082f5028a16eb3a", {st_mode=S_IFREG|0444, st_size=136, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/1b/d44cb9d13204b0fe1958db0082f5028a16eb3a", O_RDONLY|O_NOATIME) = 6
10922 mmap(NULL, 136, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2ac028782000
10922 close(6)                          = 0
10922 munmap(0x2ac028782000, 136)       = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/df/2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078", {st_mode=S_IFREG|0444, st_size=49, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/df/2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078", O_RDONLY|O_NOATIME) = 6
10922 mmap(NULL, 49, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2ac028782000
10922 close(6)                          = 0
10922 munmap(0x2ac028782000, 49)        = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/94/5b990ce4a77ccd314fbc9b33c5959023a92714", {st_mode=S_IFREG|0444, st_size=176, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/94/5b990ce4a77ccd314fbc9b33c5959023a92714", O_RDONLY|O_NOATIME) = 6
10922 mmap(NULL, 176, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2ac028782000
10922 close(6)                          = 0
10922 munmap(0x2ac028782000, 176)       = 0
10922 stat("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/df/2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078", {st_mode=S_IFREG|0444, st_size=49, ...}) = 0
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/df/2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078", O_RDONLY|O_NOATIME) = 6
10922 mmap(NULL, 49, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2ac028782000
10922 close(6)                          = 0
10922 munmap(0x2ac028782000, 49)        = 0
10922 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 6), ...}) = 0
10922 write(1, "Created commit ", 15)   = 15
10922 open("/opt/packrat/playpen/public/in-place/git/git.junio/t/trash/.git/objects/94/", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 6
10922 fstat(6, {st_mode=S_IFDIR|S_ISGID|0775, st_size=4096, ...}) = 0
10922 fcntl(6, F_SETFD, FD_CLOEXEC)     = 0
10922 getdents(6, /* 3 entries */, 4096) = 112
10922 getdents(6, /* 0 entries */, 4096) = 0
10922 close(6)                          = 0
10922 write(1, "945b990: Partial: add elif\n", 27) = 27
10922 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 6), ...}) = 0
10922 close(1)                          = 0
10922 munmap(0x2ac028781000, 4096)      = 0
10922 exit_group(0)                     = ?

[PATCH 1/2] read-cache.c: introduce is_racy_timestamp() helper

[Junio C Hamano]

This just moves a common boolean expression into a helper function.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 read-cache.c |   13 ++++++++-----
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/read-cache.c b/read-cache.c
index f5f9c3d..9554896 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -177,6 +177,12 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
 	return changed;
 }
 
+static int is_racy_timestamp(struct index_state *istate, struct cache_entry *ce)
+{
+	return (istate->timestamp &&
+		istate->timestamp <= ce->ce_mtime);
+}
+
 int ie_match_stat(struct index_state *istate,
 		  struct cache_entry *ce, struct stat *st,
 		  unsigned int options)
@@ -210,9 +216,7 @@ int ie_match_stat(struct index_state *istate,
 	 * whose mtime are the same as the index file timestamp more
 	 * carefully than others.
 	 */
-	if (!changed &&
-	    istate->timestamp &&
-	    istate->timestamp <= ce->ce_mtime) {
+	if (!changed && is_racy_timestamp(istate, ce)) {
 		if (assume_racy_is_modified)
 			changed |= DATA_CHANGED;
 		else
@@ -1207,8 +1211,7 @@ int write_index(struct index_state *istate, int newfd)
 		struct cache_entry *ce = cache[i];
 		if (ce->ce_flags & CE_REMOVE)
 			continue;
-		if (istate->timestamp &&
-		    istate->timestamp <= ce->ce_mtime)
+		if (is_racy_timestamp(istate, ce))
 			ce_smudge_racily_clean_entry(ce);
 		if (ce_write_entry(&c, newfd, ce) < 0)
 			return -1;
-- 
1.5.4.rc4.5.g36a1

[PATCH 2/2] read-cache.c: fix timestamp comparison

[Junio C Hamano]

The mtime recorded in the cache entry is not time_t anymore but
of type (unsigned int).  This casts the comparison and also adds
fuzz factor of 1 second.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 * With these two patches the t7501 Heisenbug seems to go away.
   I do not understand why this fuzz factor of 1 second helps,
   but it apparently does.  I do not want to commit this before
   I understand why, but it is past my bedtime.

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

diff --git a/read-cache.c b/read-cache.c
index 9554896..745c3fe 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -180,7 +180,7 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
 static int is_racy_timestamp(struct index_state *istate, struct cache_entry *ce)
 {
 	return (istate->timestamp &&
-		istate->timestamp <= ce->ce_mtime);
+		((unsigned int) istate->timestamp) <= ce->ce_mtime + 1);
 }
 
 int ie_match_stat(struct index_state *istate,
-- 
1.5.4.rc4.5.g36a1

Re: [PATCH 2/2] read-cache.c: fix timestamp comparison

[Linus Torvalds]

On Mon, 21 Jan 2008, Junio C Hamano wrote:
>
> The mtime recorded in the cache entry is not time_t anymore but
> of type (unsigned int).  This casts the comparison and also adds
> fuzz factor of 1 second.

I really don't think this is the right fix.

The real problem seems to be that the whole "racy_timestamp()" thing 
*hides* the bug, and your change actually makes racy_timestamp() just hide 
things even more (by making it trigger all the time).

Adding a "sleep 1" to your test-case (appended) actually makes it fail 
reliably (without your hack - with your "+1" hack I assume you'd need to 
make the sleep longer).

So the problem is that the test-suite actually *hid* the bug by doing 
thigns so fast that the racy code triggered, and that in turn somehow 
fixed things up. 

Will experiment more now that I have a case that reliably fails. The 
commit that causes this literally shouldn't have caused any semantic 
changes at all, so this is rather interesting.

		Linus

---
#!/bin/sh

test_description='reduced 7501'

. ./test-lib.sh

test_expect_success setup '

        >file &&
        git add file &&
        test_tick &&
        git commit -m initial

'

if test -f ../trace.log
then
        mv ../trace.log ../trace.log.old
fi

test_expect_success 'partial commit that involves removal (1)' '

        test_tick &&
        git rm --cached file &&
        mv file elif &&
	sleep 1 &&
        git add elif &&
	sleep 1 &&

        strace -v -o ../trace.log git commit -m "Partial: add elif" elif &&

        git diff-tree --name-status HEAD^ HEAD >current &&
        echo "A	elif" >expected &&
        diff expected current

'

test_done

Re: [PATCH 2/2] read-cache.c: fix timestamp comparison

[Johannes Schindelin]

Hi,

On Mon, 21 Jan 2008, Linus Torvalds wrote:

> On Mon, 21 Jan 2008, Junio C Hamano wrote:
> >
> > The mtime recorded in the cache entry is not time_t anymore but of 
> > type (unsigned int).  This casts the comparison and also adds fuzz 
> > factor of 1 second.
> 
> I really don't think this is the right fix.

Junio, have you tried Hannes' fix (using ln instead of cp -p)?  I would 
not be surprised if the same happened on Linux as on Windows, only much 
rarer, since Linux is so darned fast...

Ciao,
Dscho

Re: [PATCH 2/2] read-cache.c: fix timestamp comparison

[Linus Torvalds]

On Mon, 21 Jan 2008, Linus Torvalds wrote:
> 
> Will experiment more now that I have a case that reliably fails. The 
> commit that causes this literally shouldn't have caused any semantic 
> changes at all, so this is rather interesting.

Intriguing. It's the "ce_mode" -> CE_REMOVE changes that trigger this bug.

The problem goes away with this one-liner.

I haven't figured out *why*, yet, but the reason I checked CE_REMOVE was 
that it was the only part that wasn't just a pure network order change.

I suspect we have some code-path that didn't check for explicit removal, 
but that happened to check for "mode doesn't match", so clearing ce_mode 
just magically triggered it.

Still looking.

		Linus

---
diff --git a/unpack-trees.c b/unpack-trees.c
index ff46fd6..d6fcf60 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -613,6 +613,7 @@ static int deleted_entry(struct cache_entry *ce, struct cache_entry *old,
 	else
 		verify_absent(ce, "removed", o);
 	ce->ce_flags |= CE_REMOVE;
+	ce->ce_mode = 0;
 	add_cache_entry(ce, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE);
 	invalidate_ce_path(ce);
 	return 1;

Re: [PATCH 2/2] read-cache.c: fix timestamp comparison

[Linus Torvalds]

On Mon, 21 Jan 2008, Linus Torvalds wrote:
> 
> Still looking.

Damn.

The comment that I also  moved says it all.

I'd forgotten about that really ugly special case. It's no longer ugly, 
but missing that part of the ce_mode handling cleanup certainly explains 
the test-suite failing.

		Linus

---
 read-cache.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/read-cache.c b/read-cache.c
index f5f9c3d..58a9b95 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -124,6 +124,9 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
 {
 	unsigned int changed = 0;
 
+	if (ce->ce_flags & CE_REMOVE)
+		return MODE_CHANGED | DATA_CHANGED | TYPE_CHANGED;
+
 	switch (ce->ce_mode & S_IFMT) {
 	case S_IFREG:
 		changed |= !S_ISREG(st->st_mode) ? TYPE_CHANGED : 0;
@@ -145,8 +149,6 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
 		else if (ce_compare_gitlink(ce))
 			changed |= DATA_CHANGED;
 		return changed;
-	case 0: /* Special case: unmerged file in index */
-		return MODE_CHANGED | DATA_CHANGED | TYPE_CHANGED;
 	default:
 		die("internal error: ce_mode is %o", ce->ce_mode);
 	}

Re: [PATCH 2/2] read-cache.c: fix timestamp comparison

[Johannes Schindelin]

Hi,

On Mon, 21 Jan 2008, Linus Torvalds wrote:

> diff --git a/read-cache.c b/read-cache.c
> index f5f9c3d..58a9b95 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -124,6 +124,9 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
>  {
>  	unsigned int changed = 0;
>  
> +	if (ce->ce_flags & CE_REMOVE)
> +		return MODE_CHANGED | DATA_CHANGED | TYPE_CHANGED;
> +
>  	switch (ce->ce_mode & S_IFMT) {
>  	case S_IFREG:
>  		changed |= !S_ISREG(st->st_mode) ? TYPE_CHANGED : 0;
> @@ -145,8 +149,6 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
>  		else if (ce_compare_gitlink(ce))
>  			changed |= DATA_CHANGED;
>  		return changed;
> -	case 0: /* Special case: unmerged file in index */
> -		return MODE_CHANGED | DATA_CHANGED | TYPE_CHANGED;

Not that I understand what is _really_ going on, but shouldn't the comment 
be actually moved, not be deleted?

Ciao,
Dscho

Re: [PATCH 2/2] read-cache.c: fix timestamp comparison

[Linus Torvalds]

On Mon, 21 Jan 2008, Johannes Schindelin wrote:
> 
> Not that I understand what is _really_ going on, but shouldn't the comment 
> be actually moved, not be deleted?

Well, the thing is, it's not a special case any more, and you can now see 
the code, and say "that's obviously correct".

The whole point of that function is to compare a index entry with the stat 
information, and it does that by validating it in special ways. It used to 
be that the "ce_mode = 0" was a special case. Now it isn't.

A deleted entry can obviously never match an entry that is still on disk 
(regardless of *any* other issues). So now the

	if (ce->ce_flags & CE_REMOVE)
		return MODE_CHANGED | DATA_CHANGED | TYPE_CHANGED;

statement is in no way a special case - rather the reverse, it's a lot 
more obvious than testing for inode ownership changes etc.

So I removed the comment, because it doesn't make sense any more.

Of course, I could have - instead of deleting it - changed it from 
"Special case: .." to something like "A deleted index entry doesn't match 
any on-disk file", but does that actually add any information to the above 
two lines? Sure, we can comment things, but shouldn't we comment the ones 
that are subtle or odd, rather than the obvious ones?

This was why the CE_REMOVE bit was done in the first place: to remove the 
rather special case of ce_mode being zero meaning something special.

			Linus

Re: [PATCH 2/2] read-cache.c: fix timestamp comparison

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Mon, 21 Jan 2008, Linus Torvalds wrote:
>> 
>> Still looking.
>
> Damn.
>
> The comment that I also  moved says it all.
>
> I'd forgotten about that really ugly special case. It's no longer ugly, 
> but missing that part of the ce_mode handling cleanup certainly explains 
> the test-suite failing.

Very good catch.

Re: [PATCH 2/2] read-cache.c: fix timestamp comparison

[Linus Torvalds]

On Mon, 21 Jan 2008, Junio C Hamano wrote:
> >
> > I'd forgotten about that really ugly special case. It's no longer ugly, 
> > but missing that part of the ce_mode handling cleanup certainly explains 
> > the test-suite failing.
> 
> Very good catch.

The stupid thing is that I literally _grepped_ for the code testing 
"ce_mode".

I had missed that one because I had looked for things like

	if ([!].*ce_mode)

but that switch statement meant that the comparison to zero was 
non-local and my grep didn't see it. And while the test-suite did have a 
test for this, it was hidden by the racy index logic.. Unlucky.

Anyway, I've created a rebased tree with the commits fixed (and some 
whitespace fixes too), so that it should hopefully all be bisect-clean 
etc.

[ To clarify: it's both rebased to the current git 'master' (which is 
  currently -rc4) _and_ it has the commits fixed up. So I also squashed 
  the "-m" flag fix into the commit that made diff-index use unpack_trees, 
  etc, so that none of the commits should be introducing bugs that get 
  fixed later.

  I also cleaned up some of the commit messages, particularly the one 
  about using unpack_trees() (which was talking about "take 2" of lstat 
  reduction - true, but not very descriptive of what it actually did) ]

It's in the same place: branch 'new-lstat' at

	git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git new-lstat

and I'll continue to maintain it if only because it's what I use myself 
(until I just switch to 'next' or something).

		Linus

Re: [PATCH 2/2] read-cache.c: fix timestamp comparison

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> It's in the same place: branch 'new-lstat' at
>
> 	git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git new-lstat
>
> and I'll continue to maintain it if only because it's what I use myself 
> (until I just switch to 'next' or something).

I'll find time to replace lt/in-core-index branch that is
currently in 'pu' with it, hopefully sometime tonight.  Mine has
these two idiotic stuff you commented on.

Re: [PATCH 2/2] read-cache.c: fix timestamp comparison

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> The stupid thing is that I literally _grepped_ for the code testing 
> "ce_mode".
>
> I had missed that one because I had looked for things like
>
> 	if ([!].*ce_mode)
>
> but that switch statement meant that the comparison to zero was 
> non-local and my grep didn't see it.

Would a patch to sparse help you in cases like this?

Re: [PATCH 2/2] read-cache.c: fix timestamp comparison

[Linus Torvalds]

On Tue, 22 Jan 2008, Junio C Hamano wrote:

> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
> > The stupid thing is that I literally _grepped_ for the code testing 
> > "ce_mode".
> >
> > I had missed that one because I had looked for things like
> >
> > 	if ([!].*ce_mode)
> >
> > but that switch statement meant that the comparison to zero was 
> > non-local and my grep didn't see it.
> 
> Would a patch to sparse help you in cases like this?

Heh. Sparse can do anything, but some things are more specialized than 
others. In this case, I could possibly have added a type modifier that 
says "don't compare against zero", and that kind of thing may even make 
sense (ie you can mark pointers that are known not to be NULL), and yes, 
it would have caught this.

But sparse right now doesn't have that kind of flag (the "safe expression" 
thing comes pretty close).

So yes, sparse could do things like this, but it's generally a fair amount 
of work to add specialized sparse rules.

		Linus

Re: [PATCH 2/2] read-cache.c: fix timestamp comparison

[Linus Torvalds]

On Mon, 21 Jan 2008, Linus Torvalds wrote:
> On Mon, 21 Jan 2008, Junio C Hamano wrote:
> > 
> > Very good catch.
> 
> The stupid thing is that I literally _grepped_ for the code testing 
> "ce_mode".
> 
> I had missed that one because I had looked for things like
> 
> 	if ([!].*ce_mode)
> 
> but that switch statement meant that the comparison to zero was 
> non-local and my grep didn't see it. And while the test-suite did have a 
> test for this, it was hidden by the racy index logic.. Unlucky.

Ok, having looked a bit more, I found another two cases that my grep had 
missed. They were regular if-statements, just more complex than my stupid 
grep pattern had taken into account.

Both are in read-cache.c:

read-cache.c:                   if (stage || istate->cache[pos]->ce_mode) {
read-cache.c:                   if (ce_stage(p) == stage && (stage || p->ce_mode))

and I'd send a patch, except my tree right now is in pretty bad shape 
because I'm also trying to see if I can add a name hash to the index.

Anyway, the "xyzzy->ce_mode" check should in both cases become a 
"!(xyzzy->ce_flags & CE_REMOVE)" instead.

And we obviously don't seem to have any tests for this situation (I think 
they are both D/F conflicts with the file having been marked removed by an 
earlier phase, so they'd be some really odd kind of merge or something).

		Linus

Re: [PATCH 2/2] read-cache.c: fix timestamp comparison

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> Ok, having looked a bit more, I found another two cases that my grep had 
> missed. They were regular if-statements, just more complex than my stupid 
> grep pattern had taken into account.
>
> Both are in read-cache.c:
>
> read-cache.c:                   if (stage || istate->cache[pos]->ce_mode) {
> read-cache.c:                   if (ce_stage(p) == stage && (stage || p->ce_mode))
>
> and I'd send a patch, except my tree right now is in pretty bad shape 
> because I'm also trying to see if I can add a name hash to the index.

-- >8 --
read-cache.c: fix a couple more CE_REMOVE conversion

It is a D/F conflict if you want to add "foo/bar" to the index
when "foo" already exists.  Also it is a conflict if you want to
add a file "foo" when "foo/bar" exists.

An exception is when the existing entry is there only to mark "I
used to be here but I am being removed".  This is needed for
operations such as "git read-tree -m -u" that update the index
and then reflect the result to the work tree --- we need to
remember what to remove somewhere, and we use the index for
that.  In such a case, an existing file "foo" is being removed
and we can create "foo/" directory and hang "bar" underneath it
without any conflict.

We used to use (ce->ce_mode == 0) to mark an entry that is being
removed, but (CE_REMOVE & ce->ce_flags) is used for that purpose
these days.  An earlier commit forgot to convert the logic in
the code that checks D/F conflict condition.

The old code knew that "to be removed" entries cannot be at
higher stage and actively checked that condition, but it was an
unnecessary check.  This patch removes the extra check as well.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 read-cache.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/read-cache.c b/read-cache.c
index 8ba8f0f..8f5d02a 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -615,7 +615,7 @@ static int has_dir_name(struct index_state *istate,
 			 * it is Ok to have a directory at the same
 			 * path.
 			 */
-			if (stage || istate->cache[pos]->ce_mode) {
+			if (!(istate->cache[pos]->ce_flags & CE_REMOVE)) {
 				retval = -1;
 				if (!ok_to_replace)
 					break;
@@ -637,8 +637,9 @@ static int has_dir_name(struct index_state *istate,
 			    (p->name[len] != '/') ||
 			    memcmp(p->name, name, len))
 				break; /* not our subdirectory */
-			if (ce_stage(p) == stage && (stage || p->ce_mode))
-				/* p is at the same stage as our entry, and
+			if (ce_stage(p) == stage && !(p->ce_flags & CE_REMOVE))
+				/*
+				 * p is at the same stage as our entry, and
 				 * is a subdirectory of what we are looking
 				 * at, so we cannot have conflicts at our
 				 * level or anything shorter.

Re: [PATCH 2/2] read-cache.c: fix timestamp comparison

[Linus Torvalds]

On Tue, 22 Jan 2008, Junio C Hamano wrote:
>
> read-cache.c: fix a couple more CE_REMOVE conversion

Acked-by: Linus Torvalds <torvalds@linux-foundation.org>

			Linus

Re: What's not in 'master', and likely not to be in, until 1.5.4

[Johannes Sixt]

Junio C Hamano schrieb:
> Junio C Hamano <gitster@pobox.com> writes:
> 
>> It's a Heisenbug.  I actually merged it to 'next' but rewound it
>> before pushing the result out after seeing a breakage.
>>
>> "make clean test" to run everything through sometimes fails and
>> immediately after that when I do "cd t && sh t75??-???.sh -i -v"
>> it happily runs through the end.
>>
>> I'll be back with more details when I have some.
> 
> In t7501-commit.sh, "partial commit that involves removal (1)"
> test, it _sometimes_ fails.
> 
>     test_expect_success 'partial commit that involves removal (1)' '
> 
>         git rm --cached file &&
>         mv file elif &&
>         git add elif &&
>         git diff-index --name-status HEAD >changes &&
>         git commit -m "Partial: add elif" elif &&
>         git diff-tree --name-status HEAD^ HEAD >current &&
>         echo "A     elif" >expected &&
>         diff expected current
> 
>     '
> 
> It removes "file" from the index, adds "elif" to the index, and
> tries to commit _only_ the addition of "elif" without recording
> the removal of "file" (I added "diff-index" above to see where
> it fails, its presense or absense does not change the bug, and
> it shows that both addition of elif and removal of file are in
> the index).
> 
> When the test fails, the resulting commit however does not
> record the addition of elif.  The commit records the same tree
> as its parent instead.  The index that is left has "elif" but
> not "file" (iow, it records the expected state after such a
> partial commit).

Déjà-vu! We had similar problems on Windows. I was able to solve it this
way when git-commit was still a shell script:

 save_index () {
-	cp -p "$THIS_INDEX" "$NEXT_INDEX"
+	ln "$THIS_INDEX" "$NEXT_INDEX"
 }

because 'cp -p' does not keep the precise timestamp, but 'ln' does (which
creates hardlinks on NTFS). This violated the assumptions on which the
racy-git check relies.

-- Hannes

Re: What's not in 'master', and likely not to be in, until 1.5.4

[Daniel Barkalow]

On Sun, 20 Jan 2008, Junio C Hamano wrote:

> Here is an update to the list I sent earlier.
> 
> Topics that I thought may deserve attention, discussion and
> eventual inclusion but are not 1.5.4 material.
> 
> I think these two could be part of 1.5.4, but I left them out of
> 1.5.4-rc4 (IOW, I do not think they should be on this list):
> 
>  * marking output from "diff --{no,src,dst}-prefix" as a non-git
>    diff (me)
> 
>    Linus had an objection but I think I made a reasonable
>    argument against that.  Haven't heard back since then, so
>    this is in limbo.

If Linus is still not happy with it, we could instead require that the 
prefixes have at least one slash, not at the beginning, and figure that 
'a/foo/' 'b/foo/' intends the effect it will have on git-apply. The effect 
of --no-prefix on git-apply is kind of incoherent, so that's more sensible 
to prohibit.

> I suspect it might be a good idea to make an early declaration
> that 1.5.5 is to resolve the above listed issues plus the ones
> already in 'pu' (and nothing else), and have a fairly short
> cycle after 1.5.4.

I've got 4 topics that I've been holding back until 1.5.4 is out:

 * Use fewer connections to perform git-native fetches (this is actually 
   from before transport.c made it to master, and I forgot about it until 
   I was rebasing stuff and it didn't go away).

 * Make checkout a builtin (includes a certain amount of infrastructure 
   improvement for programs that might wants to read multiple trees into 
   the same index in memory in sequence)

 * Generate a cover letter from format-patch (originally Dscho's patch; I 
   reworked a bunch of it)

 * Let the user provide aliases for URL patterns (should be useful for 
   groups whose members don't all have the same best access to a remote
   repository)

If you want to have cycles that only handle stuff that's been submitted 
beforehand, it doesn't make sense to have a feature freeze beforehand, and 
therefore only take patches in that cycle from people who ignore your 
wishes. I think in order to do that sort of thing, we'd need a tree run 
like -mm, maintained by somebody whose attention won't be taken away from 
the mainline release process by managing patches that are cooking.

	-Daniel
*This .sig left intentionally blank*

Re: What's not in 'master', and likely not to be in, until 1.5.4

[Marco Costalba]

On Jan 21, 2008 3:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> I suspect it might be a good idea to make an early declaration
> that 1.5.5 is to resolve the above listed issues plus the ones
> already in 'pu' (and nothing else), and have a fairly short
> cycle after 1.5.4.
>

I have another patch, already sent to the list but lost somewhere
about pretty=format optimization that I'm planning to resend after a
cleanup when 1.5.4 is out.
Patch improves git log speed when --pretty=format is used.

Marco

Re: What's not in 'master' but should be

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2952 bytes --]

Hi,

On Fri, 18 Jan 2008, Junio C Hamano wrote:

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Currently the ones I looked at and consider possible 1.5.4 material 
> > are http-push fixes from Grégoire Barbier and parse_commit_buffer() 
> > tightening from Martin Koegler.
> 
> It seems that for the past few days, people were having too much fun 
> bashing how broken MacOS X is, and the real work has stalled in the 
> meantime.  Well, not really stalled but they certainly made the patches 
> and discussions harder to find in the list archive.
> 
> [...]
>
> But there are still unapplied patches that deserve attention. The one 
> that I am most worried about is Grégoire Barbier's http-push changes:
> 
>   $gmane/70406 <1200250979-19604-1-git-send-email-gb@gbarbier.org>

This patch makes http-push Warn if URL does not end if "/", but it would 
be even better to just handle it... we know exactly that HTTP URLs _must_ 
end in a slash.

It gives a better warning if the URL cannot be accessed, alright.  But I 
hate the fact that it introduces yet another function which does a bunch 
of curl_easy_setopt()s only to start an active slot and check for errors.

Currently, I am not familiar enough with http-push.c to suggest a proper 
alternative, but I suspect that the return values of the _existing_ calls 
to curl should know precisely why the requests failed, and _this_ should 
be reported.

>   $gmane/70407 <1200250979-19604-2-git-send-email-gb@gbarbier.org>

I first could not reproduce the breakage described in the commit message 
(bad or no ref given on command line).

After playing around for a while, all of a sudden, I got a segmentation 
fault:

Waiting for 
http://dscho@127.0.0.1/test.git/objects/56/5e84516c1c6dca168be1715b45aeae70b24d13_36e8d912-4841-455a-bbd9-69e54d00db99
Segmentation fault (core dumped)

Unfortunately, this is with _and_ without this patch.

In gdb, it looks like this:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1213430096 (LWP 31418)]
check_locks () at http-push.c:637
637                     if (!lock->refreshing && time_remaining < 
LOCK_REFRESH) {
(gdb) p lock
$1 = (struct remote_lock *) 0x20
(gdb) bt
#0  check_locks () at http-push.c:637
#1  0x08053f8a in process_response (callback_data=0x80c4550)
    at http-push.c:683
#2  0x0804dbf4 in process_curl_messages () at http.c:539
#3  0x0804dc46 in step_active_slots () at http.c:453
#4  0x0804dccb in run_active_slot (slot=0x80c2388) at http.c:474
#5  0x0804deaa in http_cleanup () at http.c:291
#6  0x0805268f in main (argc=3, argv=Cannot access memory at address 0x4
) at http-push.c:2428

So it seems that there is more to fix.

>   $gmane/70405 <1200250979-19604-3-git-send-email-gb@gbarbier.org>

This makes sense.  I only tried to compile http-push once without 
CURL_MULTI, and gave up (I think I even sent out a patch disabling 
CURL_MULTI for curl versions lacking a certain symbol).

Ciao,
Dscho

Re: What's not in 'master' but should be

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1768 bytes --]

Hi,

On Fri, 18 Jan 2008, Johannes Schindelin wrote:

> >   $gmane/70407 <1200250979-19604-2-git-send-email-gb@gbarbier.org>
> 
> I first could not reproduce the breakage described in the commit message 
> (bad or no ref given on command line).
> 
> After playing around for a while, all of a sudden, I got a segmentation 
> fault:
> 
> Waiting for 
> http://dscho@127.0.0.1/test.git/objects/56/5e84516c1c6dca168be1715b45aeae70b24d13_36e8d912-4841-455a-bbd9-69e54d00db99
> Segmentation fault (core dumped)
> 
> Unfortunately, this is with _and_ without this patch.
>
> 
> In gdb, it looks like this:
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1213430096 (LWP 31418)]
> check_locks () at http-push.c:637
> 637                     if (!lock->refreshing && time_remaining < 
> LOCK_REFRESH) {
> (gdb) p lock
> $1 = (struct remote_lock *) 0x20
> (gdb) bt
> #0  check_locks () at http-push.c:637
> #1  0x08053f8a in process_response (callback_data=0x80c4550)
>     at http-push.c:683
> #2  0x0804dbf4 in process_curl_messages () at http.c:539
> #3  0x0804dc46 in step_active_slots () at http.c:453
> #4  0x0804dccb in run_active_slot (slot=0x80c2388) at http.c:474
> #5  0x0804deaa in http_cleanup () at http.c:291
> #6  0x0805268f in main (argc=3, argv=Cannot access memory at address 0x4
> ) at http-push.c:2428
> 
> So it seems that there is more to fix.

The segmentation fault occurs due to check_locks() accessing the remote 
that was just free()d, due to the new change.

But now I cannot even reproduce the segmentation fault, it seems.  
Strange.  Very strange.

Grégoire, it would help tremendously if you could come up with a test 
case.  The description you gave did not lead to something reproducible 
here.

Ciao,
Dscho

Re: What's not in 'master' but should be

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 452 bytes --]

Hi,

On Fri, 18 Jan 2008, Johannes Schindelin wrote:

> Grégoire, it would help tremendously if you could come up with a test 
> case.  The description you gave did not lead to something reproducible 
> here.

It seems that I hit the problem myself recently; it only showed when there 
was more than one ref.  A fix is already in "next".

Grégoire, could you please test a current "next", just to make sure that 
the problem is now gone?

Ciao,
Dscho

Re: What's not in 'master' but should be

[Mike Hommey]

On Fri, Jan 18, 2008 at 06:28:03PM +0000, Johannes Schindelin wrote:
> Hi,
> 
> On Fri, 18 Jan 2008, Junio C Hamano wrote:
> 
> > Junio C Hamano <gitster@pobox.com> writes:
> > 
> > > Currently the ones I looked at and consider possible 1.5.4 material 
> > > are http-push fixes from Grégoire Barbier and parse_commit_buffer() 
> > > tightening from Martin Koegler.
> > 
> > It seems that for the past few days, people were having too much fun 
> > bashing how broken MacOS X is, and the real work has stalled in the 
> > meantime.  Well, not really stalled but they certainly made the patches 
> > and discussions harder to find in the list archive.
> > 
> > [...]
> >
> > But there are still unapplied patches that deserve attention. The one 
> > that I am most worried about is Grégoire Barbier's http-push changes:
> > 
> >   $gmane/70406 <1200250979-19604-1-git-send-email-gb@gbarbier.org>
> 
> This patch makes http-push Warn if URL does not end if "/", but it would 
> be even better to just handle it... we know exactly that HTTP URLs _must_ 
> end in a slash.
> 
> It gives a better warning if the URL cannot be accessed, alright.  But I 
> hate the fact that it introduces yet another function which does a bunch 
> of curl_easy_setopt()s only to start an active slot and check for errors.
> 
> Currently, I am not familiar enough with http-push.c to suggest a proper 
> alternative, but I suspect that the return values of the _existing_ calls 
> to curl should know precisely why the requests failed, and _this_ should 
> be reported.

FWIW, I have a work in progress refactoring the http code, avoiding a
great amount of curl_easy_setopt()s and simplifying the whole thing.
It's been sitting on my hard drive during my (quite long) vacation. I
will probably start working again on this soonish.

Mike

Re: [PATCH] http-push: fix webdav lock leak.

[Grégoire Barbier]

Johannes Schindelin a écrit :
> > $gmane/70407 <1200250979-19604-2-git-send-email-gb@gbarbier.org>
>
>  I first could not reproduce the breakage described in the commit
>  message (bad or no ref given on command line).

It's rather easy anyway:

First, you need a test git repository availlable over http+webdav, let's 
say at http://myhost/myrepo.git/
Then, you do this:
$ git clone http://myhost/myrepo.git/
$ cd myrepo
$ git push http
Fetching remote heads...
  refs/
  refs/heads/
  refs/tags/
No refs in common and none specified; doing nothing.
$ git push http
Fetching remote heads...
  refs/
  refs/heads/
  refs/tags/
No refs in common and none specified; doing nothing.
$

Finally, you look at the web server logs, and will find one LOCK query 
and no UNLOCK query, of course the second one will be in 423 return code 
instead of 200:
1.2.3.4 - gb [19/Jan/2008:14:24:56 +0100] "LOCK /myrepo.git/info/refs 
HTTP/1.1" 200 465
(...)
1.2.3.4 - gb [19/Jan/2008:14:25:10 +0100] "LOCK /myrepo.git/info/refs 
HTTP/1.1" 423 363

With my patch, there would have be two UNLOCKs in addition of the LOCKs

 From the user point of view:
- If you realize that you should have typed e.g. "git push http master" 
instead of "git push http", you will have to wait for 10 minutes for the 
lock to expire by its own.
- Furthermore, if somebody else is dumb enough to type "git push http" 
while you need to push "master" branch, then you'll need too to wait for 
10 minutes too.

>  After playing around for a while, all of a sudden, I got a
>  segmentation fault:
>
>  Waiting for
> 
http://dscho@127.0.0.1/test.git/objects/56/5e84516c1c6dca168be1715b45aeae70b24d13_36e8d912-4841-455a-bbd9-69e54d00db99
>  Segmentation fault (core dumped)
>
>  Unfortunately, this is with _and_ without this patch.
>
>  In gdb, it looks like this:
(...)
>  The segmentation fault occurs due to check_locks() accessing the
>  remote that was just free()d, due to the new change.
>
>  But now I cannot even reproduce the segmentation fault, it seems.
>  Strange.  Very strange.
>
>  Grégoire, it would help tremendously if you could come up with a test
>  case.  The description you gave did not lead to something
>  reproducible here.

I don't know what's wrong but I can't manage to reproduce the segfault, 
I'm using the master branch on git.git plus my patches, and with CFLAGS 
containing -DUSE_CURL_MULTI, nothing more nothing less.
Is the test case I described above is enough for you to make another test?
What kind of additional information would you need ?

I will resubmit this patch today with a more detailled commit message 
including the way to reproduce the issue.
BTW you'll be interested to look at one of the "patches" I will repost 
today, since it's related to this one (the patch subject is "http-push: 
fail when info/refs exists and is already locked").

-- 
Grégoire Barbier - gb à gbarbier.org - +33 6 21 35 73 49

Re: [PATCH] http-push: fix webdav lock leak.

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 646 bytes --]

Hi,

On Sat, 19 Jan 2008, Grégoire Barbier wrote:

> Johannes Schindelin a écrit :
>
> >  After playing around for a while, all of a sudden, I got a
> >  segmentation fault:
> > 
> >  Waiting for
> > 
> > http://dscho@127.0.0.1/test.git/objects/56/5e84516c1c6dca168be1715b45aeae70b24d13_36e8d912-4841-455a-bbd9-69e54d00db99
> > Segmentation fault (core dumped)
> > 
> >  Unfortunately, this is with _and_ without this patch.

Looking at it again in more depth, it seems that this failure is indeed 
independent of your patch.

But I would still feel better if the fixes were kept minimal for now 
(codepath-wise, not only code-wise).

Ciao,
Dscho

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Johannes Schindelin]

Hi,

On Sat, 12 Jan 2008, Mark Levedahl wrote:

> The argument against my approach of explicitly naming the server rests 
> upon the premise that hiding a half-dozen servers, all different and 
> with those differences being important, under the single universal name 
> "origin", makes things easier.

No, that was not _at all_ my argument.

I said that hiding it under a different name _that you have to look up, 
too_ does _not_ make things easier.

I might even add that it makes misconfigurations even worse.

Ciao,
Dscho

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Mark Levedahl]

Johannes Schindelin wrote:
>
> No, that was not _at all_ my argument.
>
> I said that hiding it under a different name _that you have to look up, 
> too_ does _not_ make things easier.
>
>   
Granted, *IF* we had to look it up, but we don't. In fact, we use the 
convention
    servername.foo.bar
has nickname
    servername

So, we need to know the server name we are using, and that server name 
is the nickname. So, no confusion and no extra lookup step. (Our server 
names are unique without the domain suffixes, so this works well for us).

Mark

Re: [PATCH] Teach remote machinery about remotes.default config variable

[Johannes Schindelin]

Hi,

On Sat, 12 Jan 2008, Mark Levedahl wrote:

> Johannes Schindelin wrote:
> > 
> > No, that was not _at all_ my argument.
> > 
> > I said that hiding it under a different name _that you have to look 
> > up, too_ does _not_ make things easier.
> > 
> >   
> Granted, *IF* we had to look it up, but we don't. In fact, we use the 
> convention
>    servername.foo.bar
> has nickname
>    servername
> 
> So, we need to know the server name we are using, and that server name 
> is the nickname. So, no confusion and no extra lookup step. (Our server 
> names are unique without the domain suffixes, so this works well for 
> us).

How do you know _which_ default remote name your current repository uses? 
Exactly: you have to look it up.  So your whole *IF* argument is bogus.

And if you already have to look something up, and the user fiddled with 
her setup, you can no longer be sure that nickname servername points to 
servername.foo.bar, and you are in even more trouble.

That is why I maintain that your solution does not make things better.

Hth,
Dscho

[PATCH] Teach remote machinery about core.origin config variable

[Mark Levedahl]

This introduces a new configuration variable, core.origin, that
defines the name of the default remote to be used. Traditionally, this
is "origin", and could be overridden for a given branch. This change
introduces a way to redefine the default as desired and have that honored
regardless of the currently checked out head (e.g., core.origin is
used when on a detached head or any other non-tracking branch).

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
 Documentation/config.txt |    6 ++++++
 git-parse-remote.sh      |    5 +++--
 remote.c                 |   11 ++++++++++-
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1b6d6d6..a0bdf14 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -291,6 +291,12 @@ core.editor::
 	`GIT_EDITOR` environment, `core.editor`, `VISUAL` and
 	`EDITOR` environment variables and then finally `vi`.
 
+core.origin::
+	The name of the remote used by default for fetch / pull. If unset,
+	origin is assumed. This value is used whenever the current branch
+	has no corresponding branch.<name>.remote, such as when working on
+	a detached head.
+
 core.pager::
 	The command that git will use to paginate output.  Can be overridden
 	with the `GIT_PAGER` environment variable.
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 695a409..c7ac7c7 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -56,8 +56,9 @@ get_remote_url () {
 
 get_default_remote () {
 	curr_branch=$(git symbolic-ref -q HEAD | sed -e 's|^refs/heads/||')
-	origin=$(git config --get "branch.$curr_branch.remote")
-	echo ${origin:-origin}
+	git config --get "branch.$curr_branch.remote" ||
+	git config --get "core.origin" ||
+	echo origin
 }
 
 get_remote_default_refs_for_push () {
diff --git a/remote.c b/remote.c
index 0e00680..302d499 100644
--- a/remote.c
+++ b/remote.c
@@ -10,6 +10,7 @@ static int allocated_branches;
 
 static struct branch *current_branch;
 static const char *default_remote_name;
+static const char *core_origin;
 
 #define BUF_SIZE (2048)
 static char buffer[BUF_SIZE];
@@ -233,6 +234,11 @@ static int handle_config(const char *key, const char *value)
 			add_merge(branch, xstrdup(value));
 		return 0;
 	}
+	if (!strcmp(key, "core.origin")) {
+		if (value)
+			core_origin = xstrdup(value);
+		return 0;
+	}
 	if (prefixcmp(key,  "remote."))
 		return 0;
 	name = key + 7;
@@ -291,7 +297,6 @@ static void read_config(void)
 	int flag;
 	if (default_remote_name) // did this already
 		return;
-	default_remote_name = xstrdup("origin");
 	current_branch = NULL;
 	head_ref = resolve_ref("HEAD", sha1, 0, &flag);
 	if (head_ref && (flag & REF_ISSYMREF) &&
@@ -300,6 +305,10 @@ static void read_config(void)
 			make_branch(head_ref + strlen("refs/heads/"), 0);
 	}
 	git_config(handle_config);
+	if (!default_remote_name) {
+		default_remote_name = core_origin ?
+		core_origin : xstrdup("origin");
+	}
 }
 
 struct refspec *parse_ref_spec(int nr_refspec, const char **refspec)
-- 
1.5.4.rc2.98.g1f3d5

[PATCH] git-remote - Unset core.origin when deleting the default remote

[Mark Levedahl]

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
 git-remote.perl |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/git-remote.perl b/git-remote.perl
index d13e4c1..75d2371 100755
--- a/git-remote.perl
+++ b/git-remote.perl
@@ -328,6 +328,11 @@ sub rm_remote {
 
 	$git->command('config', '--remove-section', "remote.$name");
 
+	my $defremote = $git->config("core.origin");
+	if (defined $defremote && $defremote eq $name) {
+	       $git->command("config", "--unset", "core.origin");
+	}
+
 	eval {
 	    my @trackers = $git->command('config', '--get-regexp',
 			'branch.*.remote', $name);
-- 
1.5.4.rc2.98.g1f3d5

[PATCH] git-clone - Set remotes.origin config variable

[Mark Levedahl]

This records the users choice of default remote name (by default "origin")
as given by the -o option.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
 Documentation/git-clone.txt |    3 ++-
 git-clone.sh                |    1 +
 2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index fdccbd4..6c15fa4 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -95,7 +95,8 @@ OPTIONS
 --origin <name>::
 -o <name>::
 	Instead of using the remote name 'origin' to keep track
-	of the upstream repository, use <name> instead.
+	of the upstream repository, use <name> instead. The name
+	is recorded in the core.origin config variable.
 
 --upload-pack <upload-pack>::
 -u <upload-pack>::
diff --git a/git-clone.sh b/git-clone.sh
index b4e858c..7208d68 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -242,6 +242,7 @@ fi &&
 export GIT_DIR &&
 GIT_CONFIG="$GIT_DIR/config" git-init $quiet ${template+"$template"} || usage
 
+git config core.origin $origin
 if test -n "$bare"
 then
 	GIT_CONFIG="$GIT_DIR/config" git config core.bare true
-- 
1.5.4.rc2.98.g1f3d5

[PATCH] git-submodule - Possibly inherit parent's default remote on init/clone

[Mark Levedahl]

For submodules defined relative to their parent, it is likely that the
parent's defined default remote is correct for the child as well. This
allows use of remote names other than "origin", important as managed
submodules are typically checked out on a detached head and therefore
submodule-update invokes git-fetch using the default remote. Without this
change, submodules effectively had to have a default remote of "origin."

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
 Documentation/git-submodule.txt |    8 +++++---
 git-submodule.sh                |   19 +++++++++++++------
 2 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index cffc6d4..440e234 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -36,9 +36,11 @@ status::
 
 init::
 	Initialize the submodules, i.e. register in .git/config each submodule
-	name and url found in .gitmodules. The key used in .git/config is
-	`submodule.$name.url`. This command does not alter existing information
-	in .git/config.
+	name and url found in .gitmodules, along with the default remote origin.
+	For submodules using a relative url, the default remote is inherited
+	from the parent project, for absolute urls the default "origin" is used.
+	The key used in .git/config is submodule.$name.url`. This command does
+	not alter existing information in .git/config.
 
 update::
 	Update the registered submodules, i.e. clone missing submodules and
diff --git a/git-submodule.sh b/git-submodule.sh
index ad9fe62..42be4b9 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -7,6 +7,7 @@
 USAGE='[--quiet] [--cached] [add <repo> [-b branch]|status|init|update] [--] [<path>...]'
 OPTIONS_SPEC=
 . git-sh-setup
+. git-parse-remote
 require_work_tree
 
 add=
@@ -43,9 +44,7 @@ get_repo_base() {
 # Resolve relative url by appending to parent's url
 resolve_relative_url ()
 {
-	branch="$(git symbolic-ref HEAD 2>/dev/null)"
-	remote="$(git config branch.${branch#refs/heads/}.remote)"
-	remote="${remote:-origin}"
+	remote="$(get_default_remote)"
 	remoteurl="$(git config remote.$remote.url)" ||
 		die "remote ($remote) does not have a url in .git/config"
 	url="$1"
@@ -95,6 +94,7 @@ module_clone()
 {
 	path=$1
 	url=$2
+	origin=${3:-origin}
 
 	# If there already is a directory at the submodule path,
 	# expect it to be empty (since that is the default checkout
@@ -110,7 +110,7 @@ module_clone()
 	test -e "$path" &&
 	die "A file already exist at path '$path'"
 
-	git-clone -n "$url" "$path" ||
+	git-clone -n -o "$origin" "$url" "$path" ||
 	die "Clone of '$url' into submodule path '$path' failed"
 }
 
@@ -130,9 +130,11 @@ module_add()
 		usage
 	fi
 
+	origin=origin
 	case "$repo" in
 	./*|../*)
 		# dereference source url relative to parent's url
+		origin=$(get_default_remote)
 		realrepo="$(resolve_relative_url $repo)" ;;
 	*)
 		# Turn the source into an absolute path if
@@ -157,7 +159,7 @@ module_add()
 	git ls-files --error-unmatch "$path" > /dev/null 2>&1 &&
 	die "'$path' already exists in the index"
 
-	module_clone "$path" "$realrepo" || exit
+	module_clone "$path" "$realrepo" "$origin" || exit
 	(unset GIT_DIR; cd "$path" && git checkout -q ${branch:+-b "$branch" "origin/$branch"}) ||
 	die "Unable to checkout submodule '$path'"
 	git add "$path" ||
@@ -189,12 +191,15 @@ modules_init()
 		die "No url found for submodule path '$path' in .gitmodules"
 
 		# Possibly a url relative to parent
+		origin=origin
 		case "$url" in
 		./*|../*)
 			url="$(resolve_relative_url "$url")"
+			origin=$(get_default_remote)
 			;;
 		esac
 
+		git config submodule."$name".origin "$origin" &&
 		git config submodule."$name".url "$url" ||
 		die "Failed to register url for submodule path '$path'"
 
@@ -222,10 +227,12 @@ modules_update()
 			say "Submodule path '$path' not initialized"
 			continue
 		fi
+		origin=$(git config submodule."$name".origin)
+		origin=${origin:-origin}
 
 		if ! test -d "$path"/.git
 		then
-			module_clone "$path" "$url" || exit
+			module_clone "$path" "$url" "$origin" || exit
 			subsha1=
 		else
 			subsha1=$(unset GIT_DIR; cd "$path" &&
-- 
1.5.4.rc2.98.g1f3d5

Re: Allowing override of the default "origin" nickname

[Johannes Schindelin]

Hi,

On Thu, 10 Jan 2008, Mark Levedahl wrote:

> git's current support for remote nicknames other than
> "origin" is restricted to tracking branches where
> branch.<name>.remote is defined.

IIUC your patch only replaces the term "origin" by something 
user-specifiable.  I fail to see the use of it; care to explain what 
workflow is easier with your patches than without?

Ciao,
Dscho

Re: Allowing override of the default "origin" nickname

[Mark Levedahl]

On Jan 11, 2008 7:03 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> IIUC your patch only replaces the term "origin" by something
> user-specifiable.  I fail to see the use of it; care to explain what
> workflow is easier with your patches than without?
>
> Ciao,
> Dscho

Consider a project with several servers, each of which is *supposed*
is host the same project but due to lags in mirroring across airgaps,
etc., are never quite in sync. Now, we get on a teleconference and
discuss issues, find differences, and everyone reports that "origin"
has x, but in fact "origin" means different servers to almost
everyone. Also consider that only a small subset of the group really
understands git, most just follow cook-book recipes to get their work
done and don't understand what is going on.

This is my problem: "origin" is an abstraction that hides the
different server names in use and makes communication difficult,
having everyone use nicknames related to their particular upstream
server reduces the confusion.

Mark

Re: Allowing override of the default "origin" nickname

[Johannes Schindelin]

Hi,

On Fri, 11 Jan 2008, Mark Levedahl wrote:

> On Jan 11, 2008 7:03 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > IIUC your patch only replaces the term "origin" by something 
> > user-specifiable.  I fail to see the use of it; care to explain what 
> > workflow is easier with your patches than without?
> 
> Consider a project with several servers, each of which is *supposed* is 
> host the same project but due to lags in mirroring across airgaps, etc., 
> are never quite in sync. Now, we get on a teleconference and discuss 
> issues, find differences, and everyone reports that "origin" has x, but 
> in fact "origin" means different servers to almost everyone. Also 
> consider that only a small subset of the group really understands git, 
> most just follow cook-book recipes to get their work done and don't 
> understand what is going on.

Okay, I now understand your intention much better than before.

> This is my problem: "origin" is an abstraction that hides the different 
> server names in use and makes communication difficult, having everyone 
> use nicknames related to their particular upstream server reduces the 
> confusion.

Unfortunately, I think this will just lead to even more confusion.  
Because those people following recipes without thinking will now use a 
name that does not even say the role, let alone the server.

IOW I think that your patch worsens the situation you describe.

IMHO you should optimise the communication by agreeing on one origin, 
or alternatively not talk about a server at all (which is made easy by the 
global uniqueness of commit names; just say "my tip is ac9b7192").

Ciao,
Dscho

Re: Allowing override of the default "origin" nickname

[Mark Levedahl]

On Jan 11, 2008 8:52 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> IMHO you should optimise the communication by agreeing on one origin,
> or alternatively not talk about a server at all (which is made easy by the
> global uniqueness of commit names; just say "my tip is ac9b7192").
>

We *cannot* agree on one definition of "origin": there is no single
server accessible by all, but use of submodules currently *requires*
that each repo's upstream be given the nickname "origin". With this
change, I can enforce that each server has a unique nickname and that
one unique nickname per server is used across the program. Absent
this, I cannot and end up having to have everyone translate "origin"
into what it means for them.

SHA-1's are absolutely unique, but what do you do when "origin" does
not have  acdc101? I want to know that server-x@joe.com doesn't have
it, while server-y@mary.org does. This is the frequent problem in
conversation, and is the reason we have to be able to talk about the
particular upstream server.

This change does not eliminate the ability to obscure multiple
different server names using "origin" for those who think that is the
best way to do things, it just eliminates the requirement for doing
so.

Mark

Re: Allowing override of the default "origin" nickname

[Johannes Schindelin]

Hi,

On Fri, 11 Jan 2008, Mark Levedahl wrote:

> On Jan 11, 2008 8:52 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > IMHO you should optimise the communication by agreeing on one origin, 
> > or alternatively not talk about a server at all (which is made easy by 
> > the global uniqueness of commit names; just say "my tip is ac9b7192").
> 
> We *cannot* agree on one definition of "origin": there is no single 
> server accessible by all, but use of submodules currently *requires* 
> that each repo's upstream be given the nickname "origin". With this 
> change, I can enforce that each server has a unique nickname and that 
> one unique nickname per server is used across the program. Absent this, 
> I cannot and end up having to have everyone translate "origin" into what 
> it means for them.
> 
> SHA-1's are absolutely unique, but what do you do when "origin" does not 
> have acdc101? I want to know that server-x@joe.com doesn't have it, 
> while server-y@mary.org does. This is the frequent problem in 
> conversation, and is the reason we have to be able to talk about the 
> particular upstream server.

Okay, so with your change the user has to either remember or lookup which 
is the default remote.  Without your change, the user has to either 
remember or lookup where origin points to.

I still think your change does not help.

Ciao,
Dscho

Re: Allowing override of the default "origin" nickname

[Mark Levedahl]

On Jan 11, 2008 10:03 AM, Johannes Schindelin >
> Okay, so with your change the user has to either remember or lookup which
> is the default remote.  Without your change, the user has to either
> remember or lookup where origin points to.
>
> I still think your change does not help.

That's a theoretical argument: my *experience* with trying to make the
current workflow operate was sufficiently bad and troublesome that it
caused me to write code and fix it to enable the new workflow. Also,
absent submodules the new workflow is fully supported by
branch.<name>.remote: are you advocating the elimination of that
existing feature?

Mark

Re: Allowing override of the default "origin" nickname

[Björn Steinbrink]

On 2008.01.11 11:39:48 -0500, Mark Levedahl wrote:
> On Jan 11, 2008 10:03 AM, Johannes Schindelin >
> > Okay, so with your change the user has to either remember or lookup which
> > is the default remote.  Without your change, the user has to either
> > remember or lookup where origin points to.
> >
> > I still think your change does not help.
> 
> That's a theoretical argument: my *experience* with trying to make the
> current workflow operate was sufficiently bad and troublesome that it
> caused me to write code and fix it to enable the new workflow. Also,
> absent submodules the new workflow is fully supported by
> branch.<name>.remote: are you advocating the elimination of that
> existing feature?

AFAICT your main point is that you can do:
git config --get remotes.default

and get an unique _symbolic_ name, right? So while you still need to
lookup the value of remotes.default, you get e.g. "myremote" instead of
"git://myremote/foo.git" which you get from "git remote show origin". At
least that's how I interpreted it. Your argumentation wasn't that clear
on what you actually want to achieve/improve and why just looking up
"origin" isn't enough, IMHO.

A different approach, which feels more in-line with the current state of
things, might be to allow remote aliases. "origin" would be an alias of
"myremote", and "git remote show origin" might say "origin is an alias
for myremote" followed by the details of "myremote". So that would give
you the same benefit, but "origin" would keep its meaning, and you would
not get different behaviour depending on some configuration setting (so
the poor folks on #git can just assume that "origin" is the default for
everyone).

Admittedly, I don't see any use-case for aliases except for that origin
thing, but maybe someone else does?

Björn

Re: Allowing override of the default "origin" nickname

[Jakub Narebski]

Björn Steinbrink <B.Steinbrink@gmx.de> writes:

> A different approach, which feels more in-line with the current state of
> things, might be to allow remote aliases. "origin" would be an alias of
> "myremote", and "git remote show origin" might say "origin is an alias
> for myremote" followed by the details of "myremote". So that would give
> you the same benefit, but "origin" would keep its meaning, and you would
> not get different behaviour depending on some configuration setting (so
> the poor folks on #git can just assume that "origin" is the default for
> everyone).
> 
> Admittedly, I don't see any use-case for aliases except for that origin
> thing, but maybe someone else does?

Aliases for remotes can address current deficiency in git, namely that
you cannot have push and pull under the same remote if they use different
URLs. One could use such alias to have the same name for pull and for push.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Allowing override of the default "origin" nickname

[Jakub Narebski]

"Mark Levedahl" <mlevedahl@gmail.com> writes:

> On Jan 11, 2008 8:52 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > IMHO you should optimise the communication by agreeing on one origin,
> > or alternatively not talk about a server at all (which is made easy by the
> > global uniqueness of commit names; just say "my tip is ac9b7192").
> >
> 
> We *cannot* agree on one definition of "origin": there is no single
> server accessible by all, but use of submodules currently *requires*
> that each repo's upstream be given the nickname "origin". With this
> change, I can enforce that each server has a unique nickname and that
> one unique nickname per server is used across the program. Absent
> this, I cannot and end up having to have everyone translate "origin"
> into what it means for them.
> 
> SHA-1's are absolutely unique, but what do you do when "origin" does
> not have  acdc101? I want to know that server-x@joe.com doesn't have
> it, while server-y@mary.org does. This is the frequent problem in
> conversation, and is the reason we have to be able to talk about the
> particular upstream server.
> 
> This change does not eliminate the ability to obscure multiple
> different server names using "origin" for those who think that is the
> best way to do things, it just eliminates the requirement for doing
> so.

Dscho, although I can agree that more flexibility is not always a good
thing, I think that in this situation it is a good thing. I especially
like that git-clone remembers what name it used for upstream repository
(git clone --origin <name>).

Mark, if this change is mainly about the fact that git doesn't allow
to specify default remote to fetch for detached HEAD (and submodules
use detached HEAD), why not provide "branch.HEAD.remote" etc., which
would be used _only_ if we are on detached HEAD (i.e. branch has no
name).

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Allowing override of the default "origin" nickname

[Mark Levedahl]

On Jan 11, 2008 10:25 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>
> Mark, if this change is mainly about the fact that git doesn't allow
> to specify default remote to fetch for detached HEAD (and submodules
> use detached HEAD), why not provide "branch.HEAD.remote" etc., which
> would be used _only_ if we are on detached HEAD (i.e. branch has no
> name).
>
Practically speaking, this would just change the name of the config
variable (from remotes.default to branch.HEAD.remote). However, this
value is used *whenever* the current branch does not have
corresponding branch.<name>.remote, and that is not restricted to
detached heads, it applies anytime the current HEAD is not a tracking
branch. So, I believe remotes.default better reflects this generality
than does branch.HEAD.remote.

Mark

Re: Allowing override of the default "origin" nickname

[Johannes Schindelin]

Hi,

On Fri, 11 Jan 2008, Mark Levedahl wrote:

> On Jan 11, 2008 10:25 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> >
> > Mark, if this change is mainly about the fact that git doesn't allow 
> > to specify default remote to fetch for detached HEAD (and submodules 
> > use detached HEAD), why not provide "branch.HEAD.remote" etc., which 
> > would be used _only_ if we are on detached HEAD (i.e. branch has no 
> > name).
>
> Practically speaking, this would just change the name of the config 
> variable (from remotes.default to branch.HEAD.remote). However, this 
> value is used *whenever* the current branch does not have corresponding 
> branch.<name>.remote, and that is not restricted to detached heads, it 
> applies anytime the current HEAD is not a tracking branch. So, I believe 
> remotes.default better reflects this generality than does 
> branch.HEAD.remote.

Practically speaking, I have enough experience to _know_ that your 
solution will not help very much.  It will just add to confusion.

You stated quite clearly -- _after_ I asked -- what your problem is, and I 
am quite certain that you _still_ have to look up _something_ (as I 
remarked in the email you responded to).

So it is still _utterly_ unclear to me how your patch helps anything.

Ciao,
Dscho

Re: Allowing override of the default "origin" nickname

[Daniel Barkalow]

I'm not sure if this is actually relevant to your situation, but I've got 
a patch (which I'll probably send post-1.5.4) to allow configuration of 
aliases for URLs, such that git will rewrite (for example) 
master.kernel.org:/pub/... to git://git.kernel.org/pub/...; if you're 
reading a discussion between kernel.org users on the linux-kernel mailing 
list and you don't have a kernel.org account, and you want to try things, 
this patch makes it a lot easier (cut-and-paste the URL you can't actually 
use, and it uses the variant you prefer without making you deal with it 
for each URL).

If, for each person, there's a single best access method to the data, but 
there's no single access method that works for all of the participants, 
they could use this patch, and use per-user configuration to replace all 
of the other possible names with the one they have to use.

	-Daniel
*This .sig left intentionally blank*