Get rid of .git/branches/ and .git/remotes/?

Get rid of .git/branches/ and .git/remotes/?

[Johannes Schindelin]

Hi,

I just had a crazy idea. Since we have a framework in place to read/write 
.git/config, I thought that maybe it would be a nice thing to move the 
information which is in .git/branches or .git/remotes into the config.

Advantages:

- it would be easy to copy your private configuration by copying just one 
  file,

- it would be easy to add a switch to git-fetch/git-pull to actually
  store/update the URL and head mapping under a certain nick,

- we could get rid of some parsing code, and

- it would arguably be more consistent.

Disadvantage:

- I know, I know, yet another change to the location of this 
  information...

- (very lame) you could not find out which nicks you have stored with "ls"

Comments?

Ciao,
Dscho

P.S.: I did not yet say anything about .git/info/, did I?

Re: Get rid of .git/branches/ and .git/remotes/?

[Linus Torvalds]

On Sun, 20 Nov 2005, Johannes Schindelin wrote:
> 
> I just had a crazy idea. Since we have a framework in place to read/write 
> .git/config, I thought that maybe it would be a nice thing to move the 
> information which is in .git/branches or .git/remotes into the config.

I considered it, but thee thing is, it really wants "nested names", ie 
having multi-level base-names for the variables. At the same time, I 
absolutely _abhor_ horrible crap like XML, which make nesting a 
fundamental part of their structure.

XML may be "logical", but it has absolutely zero to do with being 
human-readable and clean. In short, XML is total and absolute CRAP (in 
fact, the "X" in "XML" stands for "Crap", but the XML designers were also 
incredibly bad spellers).

So while the basic notion of the git ini file does support nesting (we 
could just make variable names be "base.level1.final" or any number of 
levels deep), I don't know what a sane format would be. I have one 
suggestion that in my opinion "fits" the .ini file syntax (see below), but 
people may well hate it.

Basically I've considered saying that one or more '.' characters at the 
start of a section name would mean "re-use the previous one", so we could 
have (this is a really bad example, just to show the implications):

	[core]
		[.values]
			fixed = true
			nested = fine
			[..example]
				test = Hell yes
		[.other]
			example = strange
		[.]
			name = hi

	[section]
		example = yet another

and that would result in a parse of

	core.values.fixed = true
	core.values.nested = fine
	core.values.example.test = Hell yes
	core.other.example = strange
	core.name = hi
	secontion.example = yet another

and that seems reasonably clean. I'd also allow explicit 
multi-level section names:

	[core.values]
		fixed = true

so you could always write the above config file in an alternate format:

	[core.values] fixed = true
	[core.values] nested = fine
	[core.values.example] test = Hell yes
	[core.other] example = strange
	[core] name = hi
	[section] example = yet another

instead, using no implicit nesting at all (or, indeed, even re-using 
sections like "core.values").

That would allow things like

	[branches]
		[.origin]
			url = master.kernel.org:/pub/scm/git/git.git
			pull = master:origin
		[.mine]
			url = my.domain.com:/other/repo
			pull = master:mine

(which could also be written as

	[branches.origin]
		url = master.kernel.org:/pub/scm/git/git.git
		pull = master:origin

	[branches.mine]
		url = my.domain.com:/other/repo
		pull = master:mine

and the following mixed-indentation usage would be technically correct, 
but perhaps crazy:

	[branches.origin]
		url = master.kernel.org:/pub/scm/git/git.git
		pull = master:origin

	    [.mine]
		url = my.domain.com:/other/repo
		pull = master:mine

Basically, right now we only allow alphanumeric characters in the base 
name, and a new section name completely clears the old one. The above 
would be a very simple extension of that: we would allow '.' in addition 
to alphanumerics, and any initial '.' characters would _keep_ that many 
levels of the old name.

I dunno. That seems a nice extension, and it would make these things 
very unambiguous. But how do other .ini-file-like things do this?

And I'm not 100% convinced that putting these branches in the config file 
has any real advantages over keeping them as separate files. Having 
everything in one place is nice, of course, and being able to copy just 
one file around might be convenient, but it _does_ make the config file 
more complicated.

Anyway, if you want to play with this, here's a trivial patch that may or 
may not work.

		Linus

----
diff --git a/config.c b/config.c
index 915bb97..3b9f300 100644
--- a/config.c
+++ b/config.c
@@ -136,6 +136,19 @@ static int get_base_var(char *name)
 			return -1;
 		if (c == ']')
 			return baselen;
+		if (c == '.') {
+			if (!baselen || name[baselen-1] == '.') {
+				for (;;) {
+					if (!name[baselen])
+						return -1;
+					if (name[baselen++] == '.')
+						break;
+				}
+				continue;
+			}
+			name[baselen++] = c;
+			continue;
+		}
 		if (!isalnum(c))
 			return -1;
 		if (baselen > MAXNAME / 2)

Re: Get rid of .git/branches/ and .git/remotes/?

[Sven Verdoolaege]

On Sun, Nov 20, 2005 at 10:09:50AM -0800, Linus Torvalds wrote:
> and that would result in a parse of
> 
> 	core.values.fixed = true
> 	core.values.nested = fine
> 	core.values.example.test = Hell yes
> 	core.other.example = strange
> 	core.name = hi
> 	secontion.example = yet another
> 

[..]

> I dunno. That seems a nice extension, and it would make these things 
> very unambiguous. But how do other .ini-file-like things do this?

Not sure if this falls in the ".ini-file-like" category, but
YAML (www.yaml.org) does nesting based on indentation.
Your example would look like

core:
  values:
    fixed: true
    nested: fine
    example:
      test: Hell yes
  other:
    example: strange
  name: hi
secontion:
  example: yet another

or

core:
  values: { fixed: true, nested: fine, example: { test: Hell yes } }
  other: { example: strange }
  name: hi
secontion: { example: 'yet another' }

skimo

Re: Get rid of .git/branches/ and .git/remotes/?

[Linus Torvalds]

On Sun, 20 Nov 2005, Sven Verdoolaege wrote:
> 
> Not sure if this falls in the ".ini-file-like" category, but
> YAML (www.yaml.org) does nesting based on indentation.

The main reason I don't like indentation is that it tends to have strange 
rules for "tab". Some people (incorrectly, of course) think that tabs are 
not at fixed 8-byte things, so deciding the indentation of a tab often 
ends up either disallowing tabs altogether (bad) or having other strange 
rules (disallowing spaces).

So I'm not religiously opposed to it, but I find it to be less than 
optimal.

I'd rather have just _pure_ braces, but while that is natural to 
programmers, it's not very natural to most users, I think.

		Linus

Re: Get rid of .git/branches/ and .git/remotes/?

[Andreas Ericsson]

Linus Torvalds wrote:
> 
> I'd rather have just _pure_ braces, but while that is natural to 
> programmers, it's not very natural to most users, I think.
> 

Sysadmins should be used to braces too (xinetd, dhcpd, named...).

How many office clerks do you expect to use git?

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

Re: Get rid of .git/branches/ and .git/remotes/?

[Johannes Schindelin]

Hi,

On Sun, 20 Nov 2005, Linus Torvalds wrote:

> 	[branches.origin]
> 		url = master.kernel.org:/pub/scm/git/git.git
> 		pull = master:origin
> 
> 	[branches.mine]
> 		url = my.domain.com:/other/repo
> 		pull = master:mine

I like this approach best. In fact, that was my idea on how to go about 
implementing that feature.

However, 

> 	[branches.origin]
> 		url = master.kernel.org:/pub/scm/git/git.git
> 		pull = master:origin
> 
> 	    [.mine]
> 		url = my.domain.com:/other/repo
> 		pull = master:mine

I don't like this. Usually, data in ini files is not dependent on its 
position in the file, with the notable exception of section names. I never 
ran across nested sections (probably for all the reasons XML is 
unreadable). And the sections should be exchangable, just for clarities 
sake.

> And I'm not 100% convinced that putting these branches in the config file 
> has any real advantages over keeping them as separate files. Having 
> everything in one place is nice, of course, and being able to copy just 
> one file around might be convenient, but it _does_ make the config file 
> more complicated.

And it _does_ make finding the information for less savvy git users more 
easy.

I'm not 100% convinced, either, but it could be a better concept than 
different files in different places and different formats basically doing 
the same.

But my thinking went like this: if Pasky and Junio can not agree on one 
location and format, and therefore none of the two is deprecated, how 
about giving them a way out they both might be able to agree to?

Ciao,
Dscho

P.S.: Anybody noticed that I did not use 0xb4 in five days?

Re: Get rid of .git/branches/ and .git/remotes/?

[Josef Weidendorfer]

On Sunday 20 November 2005 19:09, Linus Torvalds wrote:
> 	[branches.origin]
> 		url = master.kernel.org:/pub/scm/git/git.git
> 		pull = master:origin

Two things:
* base names are case insensitive. Repository shortcuts are case
sensitive (and head names, too)
* to get rid of .git/branches/XXX, XXX has to be allowed as
base name. But XXX can contain anything a head name can (including ".").

Not really a problem. Use the ' for ' syntax:

[remotes]
	url = master.kernel.org:/pub/scm/git/git.git for origin
	pull = master:origin for origin

Not really nice. We can not have "for" as head name.

Josef

Re: Get rid of .git/branches/ and .git/remotes/?

[Johannes Schindelin]

Hi,

On Mon, 21 Nov 2005, Josef Weidendorfer wrote:

> On Sunday 20 November 2005 19:09, Linus Torvalds wrote:
> > 	[branches.origin]
> > 		url = master.kernel.org:/pub/scm/git/git.git
> > 		pull = master:origin
> 
> Two things:
> * base names are case insensitive. Repository shortcuts are case
> sensitive (and head names, too)
> * to get rid of .git/branches/XXX, XXX has to be allowed as
> base name. But XXX can contain anything a head name can (including ".").

Is it that important that nicks can be case sensitive or contain spaces or 
dots? I.e. is it sensible to make a difference between

	git pull Weidendorfer

and

	git pull weidendorfer
???

Also, I'd rather write

	git pull josef

than

	git pull "Josef Weidendorfer, III"

> Not really a problem. Use the ' for ' syntax:
> 
> [remotes]
> 	url = master.kernel.org:/pub/scm/git/git.git for origin
> 	pull = master:origin for origin
> 
> Not really nice. We can not have "for" as head name.

Not really nice. Looks ugly. Violates DRY. ("for blabla" would not need to 
be a problem; just enforce quotes around the name.)

Ciao,
Dscho

Re: Get rid of .git/branches/ and .git/remotes/?

[linux]

> The main reason I don't like indentation is that it tends to have strange 
> rules for "tab". Some people (incorrectly, of course) think that tabs are 
> not at fixed 8-byte things, so deciding the indentation of a tab often 
> ends up either disallowing tabs altogether (bad) or having other strange 
> rules (disallowing spaces).
> 
> So I'm not religiously opposed to it, but I find it to be less than 
> optimal.

Actually, most indentation-sensitive languages have a simpler solution:
they don't try to convert whitespace strings to a number like "horizontal
position"; they just compare strings.

Each line must either have the same indentation string as some active
scope, or its indentation must have the current innermost scope as a
prefix, in which case it introduces a new scope.

This allows anything except for

foo		# No prefix
    bar		# 4 spaces prefix
	baz	# tab prefix: illegal!

The "baz" line would have to begin with 4 spaces to be legal.
They could be followed by 4 more spaces, or a tab, or any other
whitespace pattern.

It's also possible to combine the two, as Haskell does.  Haskell inserts
open braces automatically if there is no such punctuation between two
lines with differing indentation, but if you supply a brace explicitly,
you can do whatever indentation you like.  (And the close brace must be
explicit if the open brace is, of course.)

Re: Get rid of .git/branches/ and .git/remotes/?

[Linus Torvalds]

On Mon, 21 Nov 2005, linux@horizon.com wrote:
> 
> Actually, most indentation-sensitive languages have a simpler solution:
> they don't try to convert whitespace strings to a number like "horizontal
> position"; they just compare strings.

Yes, but that doesn't really change the problem: you can't _visually_ see 
what is wrong in most editors (some editors end up showing tabs as 
something that isn't quite whitespace, but that's also really irritating).

This is like Makefiles: if you have spaces in the wrong place, it may all 
_look_ fine, but the Makefile just doesn't work. Really irritating.

And obviously using the file will show the problem (the parser will 
complain with a nice line number and readable error, hopefully), but I 
personally find that to just be too damn late. By then, you're already 
irritated.

So I like the notion of depending on indentation, but I just feel it falls 
down in practice. 

Of course, since I believe that tabs are always exactly 8 characters, I'd 
also be perfectly happy to just declare that anybody who disagrees with me 
is a moron and deserves to die (*).

		Linus

(*) That's obviously true of _anything_ that people disagree with me on,
but at the same time, I have this nagging suspicion that it's just better 
to not depend on indentation.

Re: Get rid of .git/branches/ and .git/remotes/?

[linux]

> This is like Makefiles: if you have spaces in the wrong place, it may all 
> _look_ fine, but the Makefile just doesn't work. Really irritating.

Makefiles are more annoying because spaces instead of tabs can cause
them to work *differently*.  It's hard to write syntax that will
actually do that, but the parser ahs to go past the problem a bit to
really figure it out, so it can't print a nice error message.

With the strict prefix convention, the parser can produce excellent
error messages.

> And obviously using the file will show the problem (the parser will 
> complain with a nice line number and readable error, hopefully), but I 
> personally find that to just be too damn late. By then, you're already 
> irritated.
>
> So I like the notion of depending on indentation, but I just feel it falls 
> down in practice. 

So you're a crotchety old fart already, unable to learn new things?

It irritates you the first few times until you learn to do it right in 
first place, just like it irritates most beginning C programmers that the
compiler keeps complaining about missing semicolons.

Computers will be annoying about syntax until they learn to do what
I want them to do rather than what I tell them to do, at which point
they'll be smart enough to start being annoying by doing what they want
to to instead of what I want them to do.

> Of course, since I believe that tabs are always exactly 8 characters, I'd 
> also be perfectly happy to just declare that anybody who disagrees with me 
> is a moron and deserves to die (*).

I agree on the One True Tab Spacing, but I fear I heretically
disagree with you about the whole NO_IRQ thing, so I guess I'll just
have to take your advice and start stalking you with eugenic intent.

[Briefly: what hardware conventions are, and particularly how many
of those hardware devices exist in the world, is irrelevant.  We have
existence proofs of hardware that uses 0 for "no IRQ" and hardware that
accepts 0 as a valid IRQ.  dev->irq is a freaking *software convention*.
What matters is the development and maintenance burden of translating
that convention into all the different hardware out there.  And frankly
converting between "0 is valid" and "0 is invalid" affects a lot more
code paths than converting between "0 is invalid" and "-1 is invalid"
for a couple of specific hardware devices.  Particularly if you
want various kernel messages and /proc/interrupts to look right.

Hell, I could argue that having the most common hardware exercise the
longest code paths is a good thing, because that puts the code that
needs the most testing where it'll get it.]


Seriously, you could always have it print warning messages but try to
keep going by assuming 8 space tabs so that at least you can postpone
fixing the problem until your current train of thought has pulled into
the station.

Re: Get rid of .git/branches/ and .git/remotes/?

[Andreas Ericsson]

linux@horizon.com wrote:
> Actually, most indentation-sensitive languages have a simpler solution:
> they don't try to convert whitespace strings to a number like "horizontal
> position"; they just compare strings.
> 
> Each line must either have the same indentation string as some active
> scope, or its indentation must have the current innermost scope as a
> prefix, in which case it introduces a new scope.
> 
> This allows anything except for
> 
> foo		# No prefix
>     bar		# 4 spaces prefix
> 	baz	# tab prefix: illegal!
> 
> The "baz" line would have to begin with 4 spaces to be legal.
> They could be followed by 4 more spaces, or a tab, or any other
> whitespace pattern.
> 

So, would this be considered legal or would it barf on baz?

foo		# No prefix
	bar	# tab prefix
        baz     # 8 spaces prefix

Most people have tabsize at 8. Some don't. Some editors insert spaces
instead of tabs while others don't. If we just match strings we'll
end up with users sending bug-reports by cut'n pasting their perfectly
valid-looking config which mixes tabs and spaces just because it's
been edited by people using different editors.

Real fun would be if the mta sends tabs as spaces. Then there'd
be no way at all of telling if the config *is* valid or not.

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

Re: Get rid of .git/branches/ and .git/remotes/?

[Andreas Ericsson]

linux@horizon.com wrote:
>>This is like Makefiles: if you have spaces in the wrong place, it may all 
>>_look_ fine, but the Makefile just doesn't work. Really irritating.
> 
> 
> Makefiles are more annoying because spaces instead of tabs can cause
> them to work *differently*.  It's hard to write syntax that will
> actually do that, but the parser ahs to go past the problem a bit to
> really figure it out, so it can't print a nice error message.
> 
> With the strict prefix convention, the parser can produce excellent
> error messages.
> 

Excellent error messages aren't good enough. It's ok for Python, since 
that's a programming language. We can expect infinitely more from 
programmers than we can from users.

> It irritates you the first few times until you learn to do it right in 
> first place, just like it irritates most beginning C programmers that the
> compiler keeps complaining about missing semicolons.
> 

If I'm trying out some new stuff that annoys me three times without me 
seeing an obvious error on my part (in the editor of my choice) I 
usually write it down as broken and move on.

> Computers will be annoying about syntax until they learn to do what
> I want them to do rather than what I tell them to do, at which point
> they'll be smart enough to start being annoying by doing what they want
> to to instead of what I want them to do.
> 

That's not the point. If everything looks good it should work good, 
regardless of which editor or tab-setting one's using.

> 
>>Of course, since I believe that tabs are always exactly 8 characters, I'd 
>>also be perfectly happy to just declare that anybody who disagrees with me 
>>is a moron and deserves to die (*).
> 
> 
> Seriously, you could always have it print warning messages but try to
> keep going by assuming 8 space tabs so that at least you can postpone
> fixing the problem until your current train of thought has pulled into
> the station.


There used to be $TABSIZE (or some such). Check it if you implement 
this. Or just skip it entirely. I would prefer the latter.

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

Re: Get rid of .git/branches/ and .git/remotes/?

[linux]

> So, would this be considered legal or would it barf on baz?
> 
> foo		# No prefix
> 	bar	# tab prefix
>         baz     # 8 spaces prefix

It would barf on baz.  "\t" is not a prefix of "        ".

> Most people have tabsize at 8. Some don't. Some editors insert spaces
> instead of tabs while others don't. If we just match strings we'll
> end up with users sending bug-reports by cut'n pasting their perfectly
> valid-looking config which mixes tabs and spaces just because it's
> been edited by people using different editors.

> Real fun would be if the mta sends tabs as spaces. Then there'd
> be no way at all of telling if the config *is* valid or not.

We have this problem already with whitespace damage in the "before"
parts of patches.  Are you suggesting that the user will be confused
because some third party edited their config using an editor that
messed up the leading whitespace and then just left it broken?

There's a certain level of "evil gremlins came in during the night and
added bugs to my code" that I bloody well expect to be confusing!

You might have problems inserting a line that suffers mailer damage,
mailer sends you, but if you had sent it as a context diff, the patch
process would have choked on the whitespace anyway.

I'm not particularly agitating for an indent-based syntax, but it
is moderately popular and successful, and anyone criticising it should
at least know how it works.

The standard interpretation of leading whitespace accepts basically
that subset of "looks right" that is insensitive to tab setting.

> Excellent error messages aren't good enough. It's ok for Python, since 
> that's a programming language. We can expect infinitely more from 
> programmers than we can from users.

We're talking about git users here, right?
More specifically, we're talking about git users who are pulling from
multiple remote trees, no?

Perhaps you could clarify how this set of people is not a strict
subset of the set of programmers...

>> It irritates you the first few times until you learn to do it right in 
>> first place, just like it irritates most beginning C programmers that the
>> compiler keeps complaining about missing semicolons.

> If I'm trying out some new stuff that annoys me three times without me 
> seeing an obvious error on my part (in the editor of my choice) I 
> usually write it down as broken and move on.

What part of something like:
	Can't figure out nesting level on line 232.  Its leading
	whitespace ("        ", all spaces), is not a prefix or
	extension of the whitespace on the preceding line 230
	("\t", all tabs).
makes the error non-obvious?

If you refuse to read the error message at all, you can get confused,
but you'll also be confused by perfectly valid code producing diagnostics
like "error: dereferencing pointer to incomplete type" if you forget to
#include the right header 200 lines before the location of your error.

>> Computers will be annoying about syntax until they learn to do what
>> I want them to do rather than what I tell them to do, at which point
>> they'll be smart enough to start being annoying by doing what they want
>> to to instead of what I want them to do.

> That's not the point. If everything looks good it should work good, 
> regardless of which editor or tab-setting one's using.

Unfortunately, that's provably impossible, because it will look
different to different people.

Proof by example:

header1
    header2	# 4 spaces
        body3	# 8 spaces
	body4	# one tab

That looks good to me, with 8-space tabs:

header1 {
    header2 {
        body3
        body4
    }
}

But it also looks great to someone with 4-space tabs:

header1 {
    header2 {
        body3
    }
    body4
}

Too bad it doesn't work the same.

The standard whitespace-parsing algorithm rejects "body4" on the grounds
that it's ambiguous.  Simple, robust, and no making guesses that lead
to an error message 20 lines beyond the actual problem.  It just says
"Hey!  Fix line 4!"

>> Seriously, you could always have it print warning messages but try to
>> keep going by assuming 8 space tabs so that at least you can postpone
>> fixing the problem until your current train of thought has pulled into
>> the station.

> There used to be $TABSIZE (or some such). Check it if you implement 
> this. Or just skip it entirely. I would prefer the latter.

Fine with me.  It's a fallback heuristic anyway.

Re: Get rid of .git/branches/ and .git/remotes/?

[Andreas Ericsson]

linux@horizon.com wrote:
>>So, would this be considered legal or would it barf on baz?
>>
>>foo		# No prefix
>>	bar	# tab prefix
>>        baz     # 8 spaces prefix
> 
> 
> It would barf on baz.  "\t" is not a prefix of "        ".
> 

But to the human eye they are the same. This is just a backwards way of 
making the computer think it's smart by recognizing a difference that, 
for all human purposes, aren't there. Like Linus said some posts ago; 
software should conform to humans. Not the other way around.

> 
>>Real fun would be if the mta sends tabs as spaces. Then there'd
>>be no way at all of telling if the config *is* valid or not.
> 
> 
> We have this problem already with whitespace damage in the "before"
> parts of patches.  Are you suggesting that the user will be confused
> because some third party edited their config using an editor that
> messed up the leading whitespace and then just left it broken?
> 

This is supposed to be edited by git config-set (or at least editable). 
When that breaks or when someone finds it inconvenient people will start 
using their editors. The logical way for a user to align new text to 
text 8 spaces away is to use the tab key. Depending on the editor (and 
the settings of that editor), the user will seem to have made perfectly 
correct changes that git will barf on, which brings us back to "software 
should conform to humans".

In short; This proposed format is just one step above a binary-format 
config file from the user-friendliness perspective.


> There's a certain level of "evil gremlins came in during the night and
> added bugs to my code" that I bloody well expect to be confusing!
> 

Can't help you there. I only do the cuddly mogwais.

> You might have problems inserting a line that suffers mailer damage,
> mailer sends you, but if you had sent it as a context diff, the patch
> process would have choked on the whitespace anyway.
> 

git only does unified diffs (but doesn't allow any fuzz, so it would 
break those too).

> I'm not particularly agitating for an indent-based syntax, but it
> is moderately popular and successful, and anyone criticising it should
> at least know how it works.
> 
> The standard interpretation of leading whitespace accepts basically
> that subset of "looks right" that is insensitive to tab setting.
> 
> 
>>Excellent error messages aren't good enough. It's ok for Python, since 
>>that's a programming language. We can expect infinitely more from 
>>programmers than we can from users.
> 
> 
> We're talking about git users here, right?
> More specifically, we're talking about git users who are pulling from
> multiple remote trees, no?
> 
> Perhaps you could clarify how this set of people is not a strict
> subset of the set of programmers...
> 

Package maintainers, tech-doc writers. Not really suits, but with a hint 
of tie nonetheless.

> 
>>That's not the point. If everything looks good it should work good, 
>>regardless of which editor or tab-setting one's using.
> 
> 
> Unfortunately, that's provably impossible, because it will look
> different to different people.
> 
> Proof by example:
> 
> header1
>     header2	# 4 spaces
>         body3	# 8 spaces
> 	body4	# one tab
> 
> That looks good to me, with 8-space tabs:
> 
> header1 {
>     header2 {
>         body3
>         body4
>     }
> }
> 
> But it also looks great to someone with 4-space tabs:
> 
> header1 {
>     header2 {
>         body3
>     }
>     body4
> }
> 
> Too bad it doesn't work the same.
> 
> The standard whitespace-parsing algorithm rejects "body4" on the grounds
> that it's ambiguous.


What I conclude from these examples are that;
1. Any brace-parsing algorithm does the right thing for every case.
2. Indentation-level parsing doesn't, so it's less robust.

Indentation-level parsing is nice-ish in a programming language because 
it enforces strong typing so others that read your program can easily do 
so. I personally disagree with that, but I can see the point.

How important is it that others can easily read your configuration file?

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

Re: Get rid of .git/branches/ and .git/remotes/?

[Josef Weidendorfer]

On Monday 21 November 2005 00:26, Josef Weidendorfer wrote:
> On Sunday 20 November 2005 19:09, Linus Torvalds wrote:
> > 	[branches.origin]
> > 		url = master.kernel.org:/pub/scm/git/git.git
> > 		pull = master:origin
> 
> Two things:
> * base names are case insensitive. Repository shortcuts are case
> sensitive (and head names, too)
> * to get rid of .git/branches/XXX, XXX has to be allowed as
> base name. But XXX can contain anything a head name can (including ".").
> 
> Not really a problem. Use the ' for ' syntax:
> 
> [remotes]
> 	url = master.kernel.org:/pub/scm/git/git.git for origin
> 	pull = master:origin for origin
> 
> Not really nice. We can not have "for" as head name.

What about another syntax for multivalue vars?
Proposed syntax:

  [remote:origin]
    url = master.kernel.org:/pub/scm/git/git.git
    pull = master:origin

For this, the parser could return
    remote.url = master.kernel.org:/pub/scm/git/git.git for origin
    remote.pull = master:origin for origin

By introducing such a scheme, multi-value vars would fit perfectly
for use for .git/remotes or .git/branches.

Josef

Re: Get rid of .git/branches/ and .git/remotes/?

[Johannes Schindelin]

Hi,

On Tue, 22 Nov 2005, Josef Weidendorfer wrote:

>   [remote:origin]
>     url = master.kernel.org:/pub/scm/git/git.git
>     pull = master:origin
> 
> For this, the parser could return
>     remote.url = master.kernel.org:/pub/scm/git/git.git for origin
>     remote.pull = master:origin for origin
> 
> By introducing such a scheme, multi-value vars would fit perfectly
> for use for .git/remotes or .git/branches.

I don't know if you missed it, but hierarchical config keys were 
introduced by b17e659dd4007cb1d3eb5ac32b524c0c5ab59601:

[remote.origin]
	url = master.kernel.org:/pub/scm/git/git.git
	pull = master:origin

is parsable by

	git-config-set --get remote.origin.url

now.

Hth,
Dscho

Re: Get rid of .git/branches/ and .git/remotes/?

[Nikolai Weibull]

Andreas Ericsson wrote:

> Excellent error messages aren't good enough. It's ok for Python, since
> that's a programming language. We can expect infinitely more from
> programmers than we can from users.

A semi-related question: who is the target audience of git?  I get the
feeling that most users will be programmers, so that's kind of a
non-argument (even though I agree with your standpoint).

Furthermore, does it really matter what format .git/config has now that
we have git-config-set?  Shouldn't all access go through that command,
so that we can change to some other format (YAML, XML, STUPIDABBR) if we
so desire without breaking anything?

Finally, a plain-text easy-to-edit format is great, and that's a good
enough argument not to use indentation (as has already been pointed out,
indentation is not always what it seems).

        nikolai

-- 
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

Re: Get rid of .git/branches/ and .git/remotes/?

[Andreas Ericsson]

Johannes Schindelin wrote:
> 
> 	git-config-set --get remote.origin.url
> 

So... "git-config-set" is used for both getting and setting? Why not 
just "git-config --set" and "git-config --get" to make things a bit less 
confusing?

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

Re: Get rid of .git/branches/ and .git/remotes/?

[Adrien Beau]

On 11/22/05, Nikolai Weibull <mailing-lists.git@rawuncut.elitemail.org> wrote:
>
> who is the target audience of git?  I get the
> feeling that most users will be programmers, so that's kind of a
> non-argument (even though I agree with your standpoint).

If Git is successful, then there will also be a lot of bleeding-edge
users, people who want to be able to:

* Get the latest and greatest (and build it and run it)
* Browse the repository (with gitk or gitweb)
* Maybe (very occasionnally) create a simple patch

This is already the case with CVS, plenty of people know (or are
instructed to do) cvs checkout, cvs update, and nothing more. That's
not much, but they're CVS users, nevertheless.

Re: Get rid of .git/branches/ and .git/remotes/?

[Josef Weidendorfer]

On Tuesday 22 November 2005 18:56, Johannes Schindelin wrote:
> On Tue, 22 Nov 2005, Josef Weidendorfer wrote:
> >   [remote:origin]
> >     url = master.kernel.org:/pub/scm/git/git.git
> >     pull = master:origin

> I don't know if you missed it, but hierarchical config keys were 
> introduced by b17e659dd4007cb1d3eb5ac32b524c0c5ab59601:
> 
> [remote.origin]
> 	url = master.kernel.org:/pub/scm/git/git.git
> 	pull = master:origin

I know. My suggestion complements hierarchical keys:

 [myporcelain.headproperties: my/head.name]
    merge.candidates = my/other.head
    merge.default = your/master

would be the same as

 [myporcelain.headproperties]
    merge.candidates = my/other.head for my/head.name
    merge.default = your/master for my/head.name

It is about specifying the same " for "-part for multiple keys.
The idea is to use everything after a ":\s*" in a section name
to use as prefix for any " for "-part of keys values given in
this section.

Josef

Re: Get rid of .git/branches/ and .git/remotes/?

[Johannes Schindelin]

Hi,

On Wed, 23 Nov 2005, Josef Weidendorfer wrote:

> My suggestion complements hierarchical keys:
> 
>  [myporcelain.headproperties: my/head.name]
>     merge.candidates = my/other.head
>     merge.default = your/master
> 
> would be the same as
> 
>  [myporcelain.headproperties]
>     merge.candidates = my/other.head for my/head.name
>     merge.default = your/master for my/head.name

Okay. What about this config file?

-- snip --
	[myporcelain.headproperties: my/head.name]
		merge.candidates = my/other.head
	[myporcelain.headproperties]
		merge.candidates = blabla for my/head.name
-- snap --

I am not totally opposed to what you are trying, but I think it 
contradicts the KISS principle. (Note: the restriction that key names must
not start with a digit is also a contradiction to that.)

Ciao,
Dscho

Re: Get rid of .git/branches/ and .git/remotes/?

[Johannes Schindelin]

Hi,

On Tue, 22 Nov 2005, Andreas Ericsson wrote:

> Johannes Schindelin wrote:
> > 
> > 	git-config-set --get remote.origin.url
> > 
> 
> So... "git-config-set" is used for both getting and setting? Why not just
> "git-config --set" and "git-config --get" to make things a bit less confusing?

I tried to do this more like a proof of a concept (Yeah, famous last 
words...) and tried to be not so intrusive. There is already a config.c, 
and to keep with the naming, this would have to move to config-lib.c to 
make space for config.c which really is the source for git-config$(X).

Should we rename config.c to config-lib.c, and config-set.c to config.c? 
Personally, I think it too intrusive, but what the heck.

Ciao,
Dscho

Re: Get rid of .git/branches/ and .git/remotes/?

[Josef Weidendorfer]

On Wednesday 23 November 2005 15:53, Johannes Schindelin wrote:
> Okay. What about this config file?
> 
> -- snip --
> 	[myporcelain.headproperties: my/head.name]
> 		merge.candidates = my/other.head
> 	[myporcelain.headproperties]
> 		merge.candidates = blabla for my/head.name
> -- snap --

I am not sure you want to show here. Your example gives

 myporcelain.headproperties.merge.candidates = my/other.head for my/head.name
 myporcelain.headproperties.merge.candidates = blabla for my/head.name

I.e. 2 values for the same variable with the same "for" specification.
This is perfectly valid.

Are you talking about the multiple representations for the same thing?
Then hierarchical config keys already introduce this:

 [myporcelain]
    headproperties.merge.candidates = blabla

is the same as

 [myprocelain.headproperties.merge]
    candidates = blabla
 
> I am not totally opposed to what you are trying, but I think it 
> contradicts the KISS principle.

This suggestion is about easier reading of config files; IMHO far easier
with some use cases; but yes, it is arguable if it's worth an added
complexity of config.c/config-set.c.

And of course this is no issue if config files are only to be written
by git-config-set. But I do not think this was the goal of the config
format.

Josef

> (Note: the restriction that key names must 
> not start with a digit is also a contradiction to that.)
> 
> Ciao,
> Dscho
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: Get rid of .git/branches/ and .git/remotes/?

[Johannes Schindelin]

Hi,

On Wed, 23 Nov 2005, Josef Weidendorfer wrote:

>  [myporcelain]
>     headproperties.merge.candidates = blabla

With such a config file, git complains loudly. Key names are only allowed 
to be alphanumerical, and the first letter cannot even be a digit. No 
dots.

> This suggestion is about easier reading of config files; IMHO far easier
> with some use cases; but yes, it is arguable if it's worth an added
> complexity of config.c/config-set.c.

Well, I'll be glad to help the implementation of whatever we agree on.

Ciao,
Dscho

Re: Get rid of .git/branches/ and .git/remotes/?

[Junio C Hamano]

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

>> So... "git-config-set" is used for both getting and setting? Why not just
>> "git-config --set" and "git-config --get" to make things a bit less confusing?
>
> I tried to do this more like a proof of a concept (Yeah, famous last 
> words...) and tried to be not so intrusive. There is already a config.c, 
> and to keep with the naming, this would have to move to config-lib.c to 
> make space for config.c which really is the source for git-config$(X).
>
> Should we rename config.c to config-lib.c, and config-set.c to config.c? 
> Personally, I think it too intrusive, but what the heck.

I do not think that change is intrusive.  We've renamed source
files number of times ;-).

I somehow get a very funny feeling to see "git-XXXX --get"
command that reports different things in different repositories
(for obvious reasons) called git-config, and not
git-repository-config.  But it probably is just me.

Anyway, the whole "remote specification in config file" is not a
very high priority for me right now.

Re: Get rid of .git/branches/ and .git/remotes/?

[Andreas Ericsson]

Junio C Hamano wrote:
> 
> I somehow get a very funny feeling to see "git-XXXX --get"
> command that reports different things in different repositories
> (for obvious reasons) called git-config, and not
> git-repository-config.  But it probably is just me.
> 

git-repo-config is way friendlier for us poor lazy folks. That last 'y' 
in "repository" really breaks the flow.

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

Re: Get rid of .git/branches/ and .git/remotes/?

[Johannes Schindelin]

Hi,

On Thu, 24 Nov 2005, Andreas Ericsson wrote:

> git-repo-config is way friendlier for us poor lazy folks. That last 'y' in
> "repository" really breaks the flow.

How about "git-local-config"?

Ciao,
Dscho

Re: Get rid of .git/branches/ and .git/remotes/?

[Andreas Ericsson]

Johannes Schindelin wrote:
> Hi,
> 
> On Thu, 24 Nov 2005, Andreas Ericsson wrote:
> 
> 
>>git-repo-config is way friendlier for us poor lazy folks. That last 'y' in
>>"repository" really breaks the flow.
> 
> 
> How about "git-local-config"?
> 

Nah. It would really mess things up if there's ever such a thing as a 
real local config (ie, ~/.gitrc).

git-config-set handles configuration for a particular repo, so 
git-repo-config is better, IMO.

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

Re: Get rid of .git/branches/ and .git/remotes/?

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

> git-config-set handles configuration for a particular repo, so 
> git-repo-config is better, IMO.

Ok, so git-repo-config that is.  Johannes?

[PATCH] Rename git-config-set to git-repo-config

[Johannes Schindelin]

... and adjust all references.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>

---

	On Thu, 24 Nov 2005, Junio C Hamano wrote:
	
	> Andreas Ericsson <ae@op5.se> writes:
	> 
	> > git-config-set handles configuration for a particular repo, so
	> > git-repo-config is better, IMO.
	> 
	> Ok, so git-repo-config that is.  Johannes?

	Sorry, git-mv did not work on my system. I can now confirm that
	there is *at least* one perl 5.6 version out there which does not
	like lists in open statements at all. Grmpf.

	Further grpmf: Is it intended behaviour that git-diff *detects* 
	renames, while git-format-patch *doesn't*?

 .gitignore                        |    2 +
 Documentation/git-repo-config.txt |   36 +++++++++++++-------------
 Documentation/git.txt             |    6 ++--
 Makefile                          |    2 +
 repo-config.c                     |    2 +
 t/t1300-repo-config.sh            |   52 +++++++++++++++++++------------------
 6 files changed, 50 insertions(+), 50 deletions(-)

diff --git a/.gitignore b/.gitignore
index 074ebe9..0876525 100644
--- a/.gitignore
+++ b/.gitignore
@@ -17,7 +17,6 @@ git-clone
 git-clone-pack
 git-commit
 git-commit-tree
-git-config-set
 git-convert-objects
 git-count-objects
 git-cvsexportcommit
@@ -77,6 +76,7 @@ git-receive-pack
 git-relink
 git-rename
 git-repack
+git-repo-config
 git-request-pull
 git-reset
 git-resolve
diff --git a/Documentation/git-config-set.txt b/Documentation/git-repo-config.txt
similarity index 82%
rename from Documentation/git-config-set.txt
rename to Documentation/git-repo-config.txt
index bfbd421..92b9156 100644
--- a/Documentation/git-config-set.txt
+++ b/Documentation/git-repo-config.txt
@@ -1,19 +1,19 @@
-git-config-set(1)
+git-repo-config(1)
 ===============
 
 NAME
 ----
-git-config-set - Set options in .git/config.
+git-repo-config - Get and set options in .git/config.
 
 
 SYNOPSIS
 --------
-'git-config-set' name [value [value_regex]]
-'git-config-set' --replace-all name [value [value_regex]]
-'git-config-set' --get name [value_regex]
-'git-config-set' --get-all name [value_regex]
-'git-config-set' --unset name [value_regex]
-'git-config-set' --unset-all name [value_regex]
+'git-repo-config' name [value [value_regex]]
+'git-repo-config' --replace-all name [value [value_regex]]
+'git-repo-config' --get name [value_regex]
+'git-repo-config' --get-all name [value_regex]
+'git-repo-config' --unset name [value_regex]
+'git-repo-config' --unset-all name [value_regex]
 
 DESCRIPTION
 -----------
@@ -89,7 +89,7 @@ Given a .git/config like this:
 you can set the filemode to true with
 
 ------------
-% git config-set core.filemode true
+% git repo-config core.filemode true
 ------------
 
 The hypothetic proxy command entries actually have a postfix to discern
@@ -97,7 +97,7 @@ to what URL they apply. Here is how to c
 to "ssh".
 
 ------------
-% git config-set proxy.command '"ssh" for kernel.org' 'for kernel.org$'
+% git repo-config proxy.command '"ssh" for kernel.org' 'for kernel.org$'
 ------------
 
 This makes sure that only the key/value pair for kernel.org is replaced.
@@ -105,7 +105,7 @@ This makes sure that only the key/value 
 To delete the entry for renames, do
 
 ------------
-% git config-set --unset diff.renames
+% git repo-config --unset diff.renames
 ------------
 
 If you want to delete an entry for a multivar (like proxy.command above),
@@ -114,45 +114,45 @@ you have to provide a regex matching the
 To query the value for a given key, do
 
 ------------
-% git config-set --get core.filemode
+% git repo-config --get core.filemode
 ------------
 
 or
 
 ------------
-% git config-set core.filemode
+% git repo-config core.filemode
 ------------
 
 or, to query a multivar:
 
 ------------
-% git config-set --get proxy.command "for kernel.org$"
+% git repo-config --get proxy.command "for kernel.org$"
 ------------
 
 If you want to know all the values for a multivar, do:
 
 ------------
-% git config-set --get-all proxy.command
+% git repo-config --get-all proxy.command
 ------------
 
 If you like to live dangerous, you can replace *all* proxy.commands by a
 new one with
 
 ------------
-% git config-set --replace-all proxy.command ssh
+% git repo-config --replace-all proxy.command ssh
 ------------
 
 However, if you really only want to replace the line for the default proxy,
 i.e. the one without a "for ..." postfix, do something like this:
 
 ------------
-% git config-set proxy.command ssh '! for '
+% git repo-config proxy.command ssh '! for '
 ------------
 
 To actually match only values with an exclamation mark, you have to
 
 ------------
-% git config-set section.key value '[!]'
+% git repo-config section.key value '[!]'
 ------------
 
 
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 694fee8..a518249 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -84,9 +84,6 @@ gitlink:git-checkout-index[1]::
 gitlink:git-commit-tree[1]::
 	Creates a new commit object
 
-gitlink:git-config-set[1]::
-	Set options in .git/config.
-
 gitlink:git-hash-object[1]::
 	Computes the object ID from a file.
 
@@ -111,6 +108,9 @@ gitlink:git-prune-packed[1]::
 gitlink:git-read-tree[1]::
 	Reads tree information into the directory index
 
+gitlink:git-repo-config[1]::
+	Get and set options in .git/config.
+
 gitlink:git-unpack-objects[1]::
 	Unpacks objects out of a packed archive.
 
diff --git a/Makefile b/Makefile
index 53bba2f..c47eeec 100644
--- a/Makefile
+++ b/Makefile
@@ -134,7 +134,7 @@ PROGRAMS = \
 	git-unpack-objects$X git-update-index$X git-update-server-info$X \
 	git-upload-pack$X git-verify-pack$X git-write-tree$X \
 	git-update-ref$X git-symbolic-ref$X git-check-ref-format$X \
-	git-name-rev$X git-pack-redundant$X git-config-set$X git-var$X
+	git-name-rev$X git-pack-redundant$X git-repo-config$X git-var$X
 
 # what 'all' will build and 'install' will install.
 ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS) git$X
diff --git a/config-set.c b/repo-config.c
similarity index 98%
rename from config-set.c
rename to repo-config.c
index d938f96..b2569b7 100644
--- a/config-set.c
+++ b/repo-config.c
@@ -2,7 +2,7 @@
 #include <regex.h>
 
 static const char git_config_set_usage[] =
-"git-config-set [--get | --get-all | --replace-all | --unset | --unset-all] name [value [value_regex]]";
+"git-repo-config [--get | --get-all | --replace-all | --unset | --unset-all] name [value [value_regex]]";
 
 static char* key = NULL;
 static char* value = NULL;
diff --git a/t/t1300-config-set.sh b/t/t1300-repo-config.sh
similarity index 81%
rename from t/t1300-config-set.sh
rename to t/t1300-repo-config.sh
index 7a5849a..5e994ff 100644
--- a/t/t1300-config-set.sh
+++ b/t/t1300-repo-config.sh
@@ -3,13 +3,13 @@
 # Copyright (c) 2005 Johannes Schindelin
 #
 
-test_description='Test git-config-set in different settings'
+test_description='Test git-repo-config in different settings'
 
 . ./test-lib.sh
 
 test -f .git/config && rm .git/config
 
-git-config-set core.penguin "little blue"
+git-repo-config core.penguin "little blue"
 
 cat > expect << EOF
 #
@@ -22,7 +22,7 @@ EOF
 
 test_expect_success 'initial' 'cmp .git/config expect'
 
-git-config-set Core.Movie BadPhysics
+git-repo-config Core.Movie BadPhysics
 
 cat > expect << EOF
 #
@@ -36,7 +36,7 @@ EOF
 
 test_expect_success 'mixed case' 'cmp .git/config expect'
 
-git-config-set Cores.WhatEver Second
+git-repo-config Cores.WhatEver Second
 
 cat > expect << EOF
 #
@@ -52,7 +52,7 @@ EOF
 
 test_expect_success 'similar section' 'cmp .git/config expect'
 
-git-config-set CORE.UPPERCASE true
+git-repo-config CORE.UPPERCASE true
 
 cat > expect << EOF
 #
@@ -70,10 +70,10 @@ EOF
 test_expect_success 'similar section' 'cmp .git/config expect'
 
 test_expect_success 'replace with non-match' \
-	'git-config-set core.penguin kingpin !blue'
+	'git-repo-config core.penguin kingpin !blue'
 
 test_expect_success 'replace with non-match (actually matching)' \
-	'git-config-set core.penguin "very blue" !kingpin'
+	'git-repo-config core.penguin "very blue" !kingpin'
 
 cat > expect << EOF
 #
@@ -106,7 +106,7 @@ EOF
 cp .git/config .git/config2
 
 test_expect_success 'multiple unset' \
-	'git-config-set --unset-all beta.haha'
+	'git-repo-config --unset-all beta.haha'
 
 cat > expect << EOF
 [beta] ; silly comment # another comment
@@ -122,7 +122,7 @@ test_expect_success 'multiple unset is c
 mv .git/config2 .git/config
 
 test_expect_success '--replace-all' \
-	'git-config-set --replace-all beta.haha gamma'
+	'git-repo-config --replace-all beta.haha gamma'
 
 cat > expect << EOF
 [beta] ; silly comment # another comment
@@ -136,7 +136,7 @@ EOF
 
 test_expect_success 'all replaced' 'cmp .git/config expect'
 
-git-config-set beta.haha alpha
+git-repo-config beta.haha alpha
 
 cat > expect << EOF
 [beta] ; silly comment # another comment
@@ -150,7 +150,7 @@ EOF
 
 test_expect_success 'really mean test' 'cmp .git/config expect'
 
-git-config-set nextsection.nonewline wow
+git-repo-config nextsection.nonewline wow
 
 cat > expect << EOF
 [beta] ; silly comment # another comment
@@ -165,8 +165,8 @@ EOF
 
 test_expect_success 'really really mean test' 'cmp .git/config expect'
 
-test_expect_success 'get value' 'test alpha = $(git-config-set beta.haha)'
-git-config-set --unset beta.haha
+test_expect_success 'get value' 'test alpha = $(git-repo-config beta.haha)'
+git-repo-config --unset beta.haha
 
 cat > expect << EOF
 [beta] ; silly comment # another comment
@@ -180,7 +180,7 @@ EOF
 
 test_expect_success 'unset' 'cmp .git/config expect'
 
-git-config-set nextsection.NoNewLine "wow2 for me" "for me$"
+git-repo-config nextsection.NoNewLine "wow2 for me" "for me$"
 
 cat > expect << EOF
 [beta] ; silly comment # another comment
@@ -196,18 +196,18 @@ EOF
 test_expect_success 'multivar' 'cmp .git/config expect'
 
 test_expect_success 'non-match' \
-	'git-config-set --get nextsection.nonewline !for'
+	'git-repo-config --get nextsection.nonewline !for'
 
 test_expect_success 'non-match value' \
-	'test wow = $(git-config-set --get nextsection.nonewline !for)'
+	'test wow = $(git-repo-config --get nextsection.nonewline !for)'
 
 test_expect_failure 'ambiguous get' \
-	'git-config-set --get nextsection.nonewline'
+	'git-repo-config --get nextsection.nonewline'
 
 test_expect_success 'get multivar' \
-	'git-config-set --get-all nextsection.nonewline'
+	'git-repo-config --get-all nextsection.nonewline'
 
-git-config-set nextsection.nonewline "wow3" "wow$"
+git-repo-config nextsection.nonewline "wow3" "wow$"
 
 cat > expect << EOF
 [beta] ; silly comment # another comment
@@ -222,15 +222,15 @@ EOF
 
 test_expect_success 'multivar replace' 'cmp .git/config expect'
 
-test_expect_failure 'ambiguous value' 'git-config-set nextsection.nonewline'
+test_expect_failure 'ambiguous value' 'git-repo-config nextsection.nonewline'
 
 test_expect_failure 'ambiguous unset' \
-	'git-config-set --unset nextsection.nonewline'
+	'git-repo-config --unset nextsection.nonewline'
 
 test_expect_failure 'invalid unset' \
-	'git-config-set --unset somesection.nonewline'
+	'git-repo-config --unset somesection.nonewline'
 
-git-config-set --unset nextsection.nonewline "wow3$"
+git-repo-config --unset nextsection.nonewline "wow3$"
 
 cat > expect << EOF
 [beta] ; silly comment # another comment
@@ -244,12 +244,12 @@ EOF
 
 test_expect_success 'multivar unset' 'cmp .git/config expect'
 
-test_expect_failure 'invalid key' 'git-config-set inval.2key blabla'
+test_expect_failure 'invalid key' 'git-repo-config inval.2key blabla'
 
-test_expect_success 'correct key' 'git-config-set 123456.a123 987'
+test_expect_success 'correct key' 'git-repo-config 123456.a123 987'
 
 test_expect_success 'hierarchical section' \
-	'git-config-set 1.2.3.alpha beta'
+	'git-repo-config 1.2.3.alpha beta'
 
 cat > expect << EOF
 [beta] ; silly comment # another comment

Re: [PATCH] Rename git-config-set to git-repo-config

[Junio C Hamano]

Thanks for the patch.  I unfortunately was doing the same,
because I wanted to get the repo-format-validation stuff into a
presentable shape, and I thought this would interfere with it
and wanted to do it first (fortunately it didn't).  They are
both in the proposed updates branch.  At a quick glance, I think
your patch is identical to what I did (there aren't that many
different ways to rename a command after all).

> 	Sorry, git-mv did not work on my system. I can now confirm that
> 	there is *at least* one perl 5.6 version out there which does not
> 	like lists in open statements at all. Grmpf.

Yeah, perl5.8delta says that is 5.8 feature.  As discussed on
the list with Merlyn, we have a fair amount of backporting, I
suspect.  At least we should work on 5.6, if not 5.5.

I do not use git-mv myself.  It does not work in subdirectories,
and typing Documentation/ twice to move just one file is a
chore, so I tend to just 'R' (rename) the file, move to the
renamed file, and '!' (run shell command on the specified path)
with 'git-add', all within a single Emacs dired buffer.

> 	Further grpmf: Is it intended behaviour that git-diff *detects* 
> 	renames, while git-format-patch *doesn't*?

I do not want to force all the kernel subsystem maintainers to
use git (namely, git-apply) to process e-mails, so format-patch
should not default to git specific renaming patches.

An option to git-format-patch _might_ make sense someday.  Maybe
after the world domination ;-).

Oh, wait.  It already can produce renaming patches, just does
not do it by default.

		Junio "again I forgot what I implemented before;
		sheesh I even used it myself to feed some patches
                to Linus" Hamano
 

Re: [PATCH] Rename git-config-set to git-repo-config

[Johannes Schindelin]

Hi,

On Thu, 24 Nov 2005, Junio C Hamano wrote:

> Thanks for the patch.  I unfortunately was doing the same,
> because I wanted to get the repo-format-validation stuff into a
> presentable shape, and I thought this would interfere with it
> and wanted to do it first (fortunately it didn't).  They are
> both in the proposed updates branch.  At a quick glance, I think
> your patch is identical to what I did (there aren't that many
> different ways to rename a command after all).

Well, there are differences:

- I did not adjust the length of the "=====" line in the dox,

- I adjusted the punch line to "Get and set options in .git/config."
  (both in git-repo-config and git, but you have it in git, exchanged...), 
  and

- I did not rename the usage string in repo-config.c.

> At least we should work on 5.6, if not 5.5.

Agree. I don't find too many bad things about

	open F, 'git-ls-files -z |' or die 'blabla';

> I do not use git-mv myself.  It does not work in subdirectories,
> and typing Documentation/ twice to move just one file is a
> chore, so I tend to just 'R' (rename) the file, move to the
> renamed file, and '!' (run shell command on the specified path)
> with 'git-add', all within a single Emacs dired buffer.

Well, I don't use Emacs any longer, since it was such a hassle to install 
it on every machine. I still like it, though.

As for git-mv: looks like we need a "git-perl-setup.perl", right?

> An option to git-format-patch _might_ make sense someday.  Maybe
> after the world domination ;-).
> 
> Oh, wait.  It already can produce renaming patches, just does
> not do it by default.
> 
> 		Junio "again I forgot what I implemented before;
> 		sheesh I even used it myself to feed some patches
>                 to Linus" Hamano

*grin* Thanks for pointing that out, Oh Merciful Maintainer (OMM)!

Ciao,
Dscho "trying to find a place to put his flagellations which is hard in 
the absence of a last name in his typical signature"

Re: [PATCH] Rename git-config-set to git-repo-config

[Junio C Hamano]

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

> Well, there are differences:

Thanks; I took yours (big thanks to Tony for teaching us how
great topic branches are -- I can just blow my "hold/repoconfig"
branch which had only one patch away, apply yours to "master"
and merge with other topics), with one minor adjustment.

> - I did not adjust the length of the "=====" line in the dox,

In "make doc", asciidoc barfs if they do not match, so I
adjusted this.

> Well, I don't use Emacs any longer, since it was such a hassle to install 
> it on every machine. I still like it, though.

I do not encourge use of Emacs to others; I was using it as an
excuse for not debugging nor testing it personally myself ;-).

> As for git-mv: looks like we need a "git-perl-setup.perl", right?

Depends on what that git-$lang-setup.$lang does, but I am not
quite sure.  Currently, using git-sh-setup implies you run only
from toplevel, with fairly convoluted logic.

I was looking at git-sh-setup does for the last couple of days;
and it is really hard to decide what the best approach is to
make various pieces subdirectory safe.

Currently git C-level tools works like this:

 - Natively, they work only from the project toplevel.  Period.

 - GIT_DIR defaults to ".git".  GIT_OBJECT_DIRECTORY defaults
   to "$GIT_DIR/objects".

 - If GIT_DIR environment variable does not exist, tools that
   use setup_git_directory() try to find a directory that has a
   subdirectory that looks like a valid GIT_DIR, and chdir() to
   that directory.  They remember the relative path from the new
   cwd() to the original.  If you started from a subdirectory,
   they work at the toplevel, but know where it came from
   e.g. "Documentation/howto/".

   The users of setup_git_directory() are responsible for
   prepending that relative path to user supplied repository
   relative pathnames.  Two functions, prefix_path() and
   get_pathspec(), are supplied to help this process.

   If GIT_DIR environment variable exists, setup_git_directory()
   does not do any ".git/" discovery (there is no point doing so
   because the user told us where it is).  HOWEVER, as a side
   effect of having GIT_DIR, they cannot know where their
   current directory is relative to the project toplevel.  IOW,
   they require to be started at the project toplevel if GIT_DIR
   environment variable exists, and I think this behaviour is
   the only one that makes sense [*1*].

 - The ones that use enter_repo() takes user supplied path,
   chdir() to it and sets GIT_DIR=. environment.  They work in
   naked repository without associated working tree so this is a
   sane behaviour.

 - The ones that use neither assume that they are at the project
   toplevel if they need to access working tree.

Among the scripts, the ones that do _not_ use git-sh-setup but
can work in subdirectories work this way:

 - Do not do project toplevel discovery, do not do chdir.

 - Use only tools that use setup_git_directory().

 - If an access to ".git" is needed, find out where it is by
   running "git-rev-parse --git-dir", but _do_ _not_ export it
   as GIT_DIR; otherwise the tools that use
   setup_git_directory() would not work as expected.

 - They do _not_ work from subdirectory if the user has GIT_DIR
   environment set [*2*].

The ones that do use git-sh-setup can use GIT_DIR shell variable
given by git-sh-setup, but git-sh-setup does _not_ export it
(very important).  If GIT_DIR environment was given by the user,
the commands would not work from subdirectory because many
C-level tools they use have setup_git_directory() internally as
mentioned before.  Otherwise, GIT_DIR is set to .git by this
script, which means these commands can run from the toplevel
only.


[Footnote]

*1* This is because GIT_DIR can point at totally out-of-tree.
Your working tree can live in tmpfs filesystem and GIT_DIR on
safer location.  You may lose uncommitted changes in exchange
for etter filesystem performance this way.

We _could_ special case when GIT_DIR is set to "/some/path/.git"
and "/some/path/" is (grand)*parent directory of the current
directory (e.g. /some/path/Documentation/howto), and do the
usual chdir() + prefix, but I suspect this leads to more
confusion not less.  The rules when things work and do not in
subdirectories become too complex.

*2* This cannot be helped; see *1* above.

Re: [PATCH] Rename git-config-set to git-repo-config

[Johannes Schindelin]

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

Hi,

On Thu, 24 Nov 2005, Junio C Hamano wrote:

>  - Natively, they work only from the project toplevel.  Period.

How about changing *that*? Like, define a GIT_CWD_PREFIX, and checking in 
the C parts?

After all, the biggest problem with the scripts in a subdirectory is that 
they do not necessarily know which parameter means what, i.e. when to 
prefix it and when not.

A small helper a là git_path() should do, right?

Ciao,
Dscho

Re: [PATCH] Rename git-config-set to git-repo-config

[Junio C Hamano]

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

>>  - Natively, they work only from the project toplevel.  Period.
>
> How about changing *that*?

I once advocated for an environment to name the top of working
tree directory --- it might make sense to resurrect that one.

"natively" was a bad choice of word.  What I meant by the above
was that the core library part (what is in read-cache,
sha1_file, etc) works on canonical path, which is defined to be
project toplevel relative.  I do not think changing that is wise
nor necessary.

The setup_git_directory() interface is a good way to take path
arguments given by the end user and convert them into canonical
path form.  So instead of punting when GIT_DIR is specified that
we have no way knowing where the working tree top is, we could
use GIT_WORKING_TREE, if exists, and use that location as the
toplevel when we need to access the working tree.  That implies
we chdir() to that directory and do necessary prefix adjustments
before returning.  But I'd rather postpone that after 1.0.

Re: [PATCH] Rename git-config-set to git-repo-config

[Linus Torvalds]

On Fri, 25 Nov 2005, Junio C Hamano wrote:
>
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >>  - Natively, they work only from the project toplevel.  Period.
> >
> > How about changing *that*?
> 
> I once advocated for an environment to name the top of working
> tree directory --- it might make sense to resurrect that one.

Please don't. 

We should just make the scripts do it automatically instead.

"git-rev-parse" already has support for all of this, and you can do

	GIT_DIR=$(git-rev-parse --git-dir)
	GIT_PREFIX=$(git-rev-parse --show-prefix)

where the first one shows the GIT_DIR, and the second one shows where in a 
git directory we are (empty if we're at the root).

And most of the git commands written in C (where it makes sense) can 
already handle being inside a subdirectory. So can a number of the 
shell-scripts (for example, doing a "git log" inside a subdirectory 
already does the log for just that subdirectory).

In fact, I'd prefer if _every_ command just did the right thing inside a 
subdirectory. 

I sent out this patch a week or two ago - it still applies, and it still 
mostly does the right thing. It makes at least "gitk" work right inside a 
subdirectory, and might make things like "git commit" and friends do the 
same.

More testing still needed, but I think this is going in the right 
direction.

Comments? I got none the first time around.

		Linus

----

NOTE! This has some seriously far-reaching implications. One of them is 
that a few programs will automagically start working inside some random 
directories.

And probably others won't. Instead of saying "Not a git archive", they 
might run and do strange things.

The patch is definitely a big step in the right direction: it makes the 
shell scripts that include "git-sh-setup" act a lot more like the programs 
that automatically find the git directory. But everybody that includes 
git-sh-setup should be verified.

This fixes gitk to also work the same way, btw.

---
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index dbb9884..044b0b4 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -3,7 +3,7 @@
 # Set up GIT_DIR and GIT_OBJECT_DIRECTORY
 # and return true if everything looks ok
 #
-: ${GIT_DIR=.git}
+: ${GIT_DIR=$(git-rev-parse --git-dir)} || exit
 : ${GIT_OBJECT_DIRECTORY="$GIT_DIR/objects"}
 
 # Having this variable in your environment would break scripts because
diff --git a/gitk b/gitk
index a9d37d9..a934255 100755
--- a/gitk
+++ b/gitk
@@ -12,7 +12,7 @@ proc gitdir {} {
     if {[info exists env(GIT_DIR)]} {
 	return $env(GIT_DIR)
     } else {
-	return ".git"
+	return [exec git-rev-parse --git-dir]
     }
 }
 
diff --git a/setup.c b/setup.c
index c487d7e..96085dd 100644
--- a/setup.c
+++ b/setup.c
@@ -53,11 +53,10 @@ const char **get_pathspec(const char *pr
 	const char **p;
 	int prefixlen;
 
-	if (!prefix && !entry)
-		return NULL;
-
 	if (!entry) {
 		static const char *spec[2];
+		if (!prefix || !*prefix)
+			return NULL;
 		spec[0] = prefix;
 		spec[1] = NULL;
 		return spec;
@@ -120,9 +119,19 @@ const char *setup_git_directory(void)
 
 	if (offset == len)
 		return NULL;
-
 	/* Make "offset" point to past the '/', and add a '/' at the end */
 	offset++;
+
+	/*
+	 * If we're inside the ".git" directory, we have an empty prefix
+	 */
+	if (!strncmp(cwd + offset, ".git", 4)) {
+		switch (cwd[offset+4]) {
+		case '\0': case '/':
+			return "";
+		}
+	}
+
 	cwd[len++] = '/';
 	cwd[len] = 0;
 	return cwd + offset;

Re: [PATCH] Rename git-config-set to git-repo-config

[Linus Torvalds]

On Fri, 25 Nov 2005, Linus Torvalds wrote:
> 
> In fact, I'd prefer if _every_ command just did the right thing inside a 
> subdirectory. 

Side note: the thing I like best about the patch I just sent out is that 
it also makes things automagically work when you're inside the ".git" 
directory. So you should be able to do a "git log" inside a "raw" archive 
without setting GIT_DIR=. explicitly.

			Linus

Re: [PATCH] Rename git-config-set to git-repo-config

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> Please don't. 
>
> We should just make the scripts do it automatically instead.

Don't worry, we are in agreement about that goal.

> "git-rev-parse" already has support for all of this, and you can do
>
> 	GIT_DIR=$(git-rev-parse --git-dir)
> 	GIT_PREFIX=$(git-rev-parse --show-prefix)
>
> where the first one shows the GIT_DIR, and the second one shows where in a 
> git directory we are (empty if we're at the root).

Not in one case -- out-of-tree GIT_DIR.  That is what
GIT_WORKING_TREE is about.

> In fact, I'd prefer if _every_ command just did the right thing inside a 
> subdirectory. 

Of course.

The case your patch does not cover that I am worried about is
where GIT_DIR is totally out of the tree.  Something like
GIT_DIR=/home/torvalds/uemacs.git and working tree at
/tmp/uemacs.  There is currently no way for the tools to figure
out where the working tree toplevel is in such an arrangement,
and that is when GIT_WORKING_TREE becomes useful.

Under normal use pattern, with GIT_DIR not in such a funny place
but immediately under working tree root, you do not need GIT_DIR
nor GIT_WORKING_TREE.  We can figure things ourselves by
chdir()-up and looking for '.git/' directory.

> I sent out this patch a week or two ago - it still applies, and it still 
> mostly does the right thing. It makes at least "gitk" work right inside a 
> subdirectory, and might make things like "git commit" and friends do the 
> same.

I am afraid it needs more work --- as long as a script uses only
C-level that use setup_git_directory(), everything should work,
and in such a case you do not even need sh-setup --- asking
"git-rev-parse --git-dir" is enough, just like you did in
git-add.  If the script does not have to know where GIT_DIR is
(and I do not think gitk needs to know it, although it digs
there by hand), it does not even need to do that.  As you said,
git-log and git-whatchanged works without any funny trick and
are fine examples of that.

> More testing still needed, but I think this is going in the right 
> direction.
>
> Comments? I got none the first time around.

Among the ones I looked at that use git-sh-setup in
Documentation directory of git.git:

 - git-checkout nor git-reset do not work because git-read-tree
   does not use setup_git_directory(), and git-sh-setup does not
   export GIT_DIR.

   And exporting GIT_DIR from git-sh-setup is not a solution.
   To setup_git_directory(), existence of GIT_DIR environment
   currently means you cannot tell where your toplevel is
   anymore.  We could check GIT_DIR against getcwd() and if it
   is a grand*parent directory, do an appropriate thing
   including chdir("$GIT_DIR/..") and returning an adjusted
   prefix, but we don't.  And that would not work if GIT_DIR is
   really out-of-tree anyway.

   That is why I keep saying GIT_WORKING_TREE.  We could export
   both GIT_DIR and GIT_WORKING_TREE from git-sh-setup, and
   teach the C-level commands that need access to working tree
   to look at it, just like we default GIT_OBJECT_DIRECTORY from
   git-sh-setup.  People with out of tree GIT_DIR needs to
   export both GIT_DIR and GIT_WORKING_TREE to override both,
   just like people with object directory in nonstandard place
   need to export GIT_OBJECT_DIRECTORY.

   Maybe GIT_WORKING_TREE can default to "$GIT_DIR/..", just
   like GIT_OBJECT_DIRECTORY defaults to "$GIT_DIR/objects".

   Another obvious approach is to stop supporting out-of-tree
   GIT_DIR, but I suspect that probably means we should ignore
   GIT_DIR environment and always chdir()-up to find .git/
   (which is fine and sane but is probably an uncomfortably big
   change).

 - git-prune does not work because git-fsck-objects does not
   know where GIT_DIR is (again, GIT_DIR not exported).

 - git-tag works.


Here is a list of C-level and their subdirectory-readiness
status.


These do not look at .git at all -- automatically subdirectory
ready ;-):

	check-ref-format get-tar-commit-id git index-pack
	mailinfo mailsplit patch-id shell show-index stripspace
	verify-pack

Uses setup_git_directory() and subdirectory ready:

        cat-file config-set diff-files diff-index diff-stages
        diff-tree ls-files name-rev rev-list rev-parse
        show-branch symbolic-ref update-index update-ref var

Uses enter_repo() to work from the toplevel:

	daemon receive-pack upload-pack

Wants GIT_DIR to know where it is and working tree access is
always toplevel:

	apply checkout-index clone-pack commit-tree
	convert-objects fetch-pack fsck-objects hash-object
	http-fetch http-push init-db local-fetch ls-tree
	merge-base merge-index mktag pack-objects pack-redundant
	peek-remote prune-packed read-tree send-pack ssh-fetch
	ssh-upload tar-tree unpack-file unpack-objects
	update-server-info write-tree

[PATCH 0/8] Make C-level operable from subdirectories

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> On Fri, 25 Nov 2005, Junio C Hamano wrote:
>>
>> I once advocated for an environment to name the top of working
>> tree directory --- it might make sense to resurrect that one.
>
> Please don't. 
>
> We should just make the scripts do it automatically instead.

Here comes an 8-patch series.

  [PATCH 1/8] git-apply: work from subdirectory.
  [PATCH 2/8] peek-remote: honor proxy config even from subdirectory.
  [PATCH 3/8] fsck-objects: work from subdirectory.
  [PATCH 4/8] checkout-index: work from subdirectory.
  [PATCH 5/8] hash-object: work within subdirectory.
  [PATCH 6/8] ls-tree: work from subdirectory.
  [PATCH 7/8] Make networking commands to work from a subdirectory.
  [PATCH 8/8] Make the rest of commands work from a subdirectory.

[PATCH 1/8] git-apply: work from subdirectory.

[Junio C Hamano]

This adds three things:

 - prefix_filename() is like prefix_path() but can be used to
   name any file on the filesystem, not the files that might go
   into the index file.

 - git-apply uses setup_git_directory() to find out the GIT_DIR
   and reads configuration file.  Later this would allow us to
   affect the behaviour of the command from the configuration.

 - When git-apply is run from a subdirectory, it applies the
   given patch only to the files under the current directory and
   below.

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

---

 apply.c |   15 +++++++++++++++
 cache.h |    1 +
 setup.c |   15 +++++++++++++++
 3 files changed, 31 insertions(+), 0 deletions(-)

applies-to: 9ccf8849fa9b522a344645c2f28f12ab036e30d5
c20b8d006edfa964b3df5e4c5cc28cb93edcb240
diff --git a/apply.c b/apply.c
index 50be8f3..ae06d41 100644
--- a/apply.c
+++ b/apply.c
@@ -16,6 +16,9 @@
 //  --numstat does numeric diffstat, and doesn't actually apply
 //  --index-info shows the old and new index info for paths if available.
 //
+static const char *prefix;
+static int prefix_length;
+
 static int allow_binary_replacement = 0;
 static int check_index = 0;
 static int write_index = 0;
@@ -1706,6 +1709,12 @@ static int use_patch(struct patch *p)
 			return 0;
 		x = x->next;
 	}
+	if (prefix && *prefix) {
+		int pathlen = strlen(pathname);
+		if (pathlen <= prefix_length ||
+		    memcmp(prefix, pathname, prefix_length))
+			return 0;
+	}
 	return 1;
 }
 
@@ -1784,6 +1793,10 @@ int main(int argc, char **argv)
 	int i;
 	int read_stdin = 1;
 
+	prefix = setup_git_directory();
+	prefix_length = prefix ? strlen(prefix) : 0;
+	git_config(git_default_config);
+
 	for (i = 1; i < argc; i++) {
 		const char *arg = argv[i];
 		int fd;
@@ -1845,6 +1858,8 @@ int main(int argc, char **argv)
 			line_termination = 0;
 			continue;
 		}
+		arg = prefix_filename(prefix, prefix_length, arg);
+
 		fd = open(arg, O_RDONLY);
 		if (fd < 0)
 			usage(apply_usage);
diff --git a/cache.h b/cache.h
index 6ac94c5..62920ce 100644
--- a/cache.h
+++ b/cache.h
@@ -149,6 +149,7 @@ extern char *get_graft_file(void);
 extern const char **get_pathspec(const char *prefix, const char **pathspec);
 extern const char *setup_git_directory(void);
 extern const char *prefix_path(const char *prefix, int len, const char *path);
+extern const char *prefix_filename(const char *prefix, int len, const char *path);
 
 #define alloc_nr(x) (((x)+16)*3/2)
 
diff --git a/setup.c b/setup.c
index ab3c778..54f6a34 100644
--- a/setup.c
+++ b/setup.c
@@ -47,6 +47,21 @@ const char *prefix_path(const char *pref
 	return path;
 }
 
+/* 
+ * Unlike prefix_path, this should be used if the named file does
+ * not have to interact with index entry; i.e. name of a random file
+ * on the filesystem.
+ */
+const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
+{
+	static char path[PATH_MAX];
+	if (!pfx || !*pfx || arg[0] == '/')
+		return arg;
+	memcpy(path, pfx, pfx_len);
+	strcpy(path + pfx_len, arg);
+	return path;
+}
+
 const char **get_pathspec(const char *prefix, const char **pathspec)
 {
 	const char *entry = *pathspec;
---
0.99.9.GIT

[PATCH 2/8] peek-remote: honor proxy config even from subdirectory.

[Junio C Hamano]

Introduce setup_git_directory_gently() which does not die() if
called outside a git repository, and use it so that later
git_config() would work as expected even from a subdirectory,
without failing the whole command if run outside a git
repository.

Use it at the beginning of peek-remote so that git:// proxy can
be picked up from the configuration file.

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

---

 cache.h       |    1 +
 peek-remote.c |    3 +++
 setup.c       |   11 ++++++++---
 3 files changed, 12 insertions(+), 3 deletions(-)

applies-to: 6afe0a2dc5da18d1090e8d660e45e2c777bfeaaa
1fe3fae4e1dcd864af4010ee572a3bc6de996e95
diff --git a/cache.h b/cache.h
index 62920ce..13806d3 100644
--- a/cache.h
+++ b/cache.h
@@ -147,6 +147,7 @@ extern char *get_graft_file(void);
 #define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
 
 extern const char **get_pathspec(const char *prefix, const char **pathspec);
+extern const char *setup_git_directory_gently(int *);
 extern const char *setup_git_directory(void);
 extern const char *prefix_path(const char *prefix, int len, const char *path);
 extern const char *prefix_filename(const char *prefix, int len, const char *path);
diff --git a/peek-remote.c b/peek-remote.c
index ee49bf3..a90cf22 100644
--- a/peek-remote.c
+++ b/peek-remote.c
@@ -27,6 +27,9 @@ int main(int argc, char **argv)
 	char *dest = NULL;
 	int fd[2];
 	pid_t pid;
+	int nongit = 0;
+
+	setup_git_directory_gently(&nongit);
 
 	for (i = 1; i < argc; i++) {
 		char *arg = argv[i];
diff --git a/setup.c b/setup.c
index 54f6a34..b697bf9 100644
--- a/setup.c
+++ b/setup.c
@@ -107,7 +107,7 @@ static int is_toplevel_directory(void)
 	return 1;
 }
 
-static const char *setup_git_directory_1(void)
+const char *setup_git_directory_gently(int *nongit_ok)
 {
 	static char cwd[PATH_MAX+1];
 	int len, offset;
@@ -154,8 +154,13 @@ static const char *setup_git_directory_1
 			break;
 		chdir("..");
 		do {
-			if (!offset)
+			if (!offset) {
+				if (nongit_ok) {
+					*nongit_ok = 1;
+					return NULL;
+				}
 				die("Not a git repository");
+			}
 		} while (cwd[--offset] != '/');
 	}
 
@@ -171,6 +176,6 @@ static const char *setup_git_directory_1
 
 const char *setup_git_directory(void)
 {
-	const char *retval = setup_git_directory_1();
+	const char *retval = setup_git_directory_gently(NULL);
 	return retval;
 }
---
0.99.9.GIT

[PATCH 3/8] fsck-objects: work from subdirectory.

[Junio C Hamano]

Not much point making it work from subdirectory, but for a
consistency make it so.

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

---

 fsck-objects.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

applies-to: 802056c105a0cb936137f141a8e6e546224f3a07
1bd646921ec7278fad9a38281678227769046291
diff --git a/fsck-objects.c b/fsck-objects.c
index 0433a1d..90e638e 100644
--- a/fsck-objects.c
+++ b/fsck-objects.c
@@ -431,6 +431,8 @@ int main(int argc, char **argv)
 {
 	int i, heads;
 
+	setup_git_directory();
+
 	for (i = 1; i < argc; i++) {
 		const char *arg = argv[i];
 
---
0.99.9.GIT

[PATCH 4/8] checkout-index: work from subdirectory.

[Junio C Hamano]

With this, git-checkout-index from a subdirectory works as
expected.  Note that "git-checkout-index -a" checks out files
only in the current directory and under.

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

---

 checkout-index.c |   12 +++++++++++-
 1 files changed, 11 insertions(+), 1 deletions(-)

applies-to: 5609c84ffd98e1b253c4cb46523245c3be553624
556dc2ebd6566fc032444224a145d3cb422eecc4
diff --git a/checkout-index.c b/checkout-index.c
index dab3778..f1e716d 100644
--- a/checkout-index.c
+++ b/checkout-index.c
@@ -34,6 +34,9 @@
  */
 #include "cache.h"
 
+static const char *prefix;
+static int prefix_length;
+
 static struct checkout state = {
 	.base_dir = "",
 	.base_dir_len = 0,
@@ -69,6 +72,10 @@ static int checkout_all(void)
 		struct cache_entry *ce = active_cache[i];
 		if (ce_stage(ce))
 			continue;
+		if (prefix && *prefix &&
+		    ( ce_namelen(ce) <= prefix_length ||
+		      memcmp(prefix, ce->name, prefix_length) ))
+			continue;
 		if (checkout_entry(ce, &state) < 0)
 			errs++;
 	}
@@ -91,6 +98,9 @@ int main(int argc, char **argv)
 	int newfd = -1;
 	int all = 0;
 
+	prefix = setup_git_directory();
+	prefix_length = prefix ? strlen(prefix) : 0;
+
 	if (read_cache() < 0) {
 		die("invalid cache");
 	}
@@ -155,7 +165,7 @@ int main(int argc, char **argv)
 
 		if (all)
 			die("git-checkout-index: don't mix '--all' and explicit filenames");
-		checkout_file(arg);
+		checkout_file(prefix_path(prefix, prefix_length, arg));
 	}
 
 	if (all)
---
0.99.9.GIT

[PATCH 5/8] hash-object: work within subdirectory.

[Junio C Hamano]

When -w is given, it needs to find out where the .git directory
is, so run the setup_git_directory() when we see a -w.

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

---

 hash-object.c |   19 ++++++++++++++++---
 1 files changed, 16 insertions(+), 3 deletions(-)

applies-to: b0041c758e0fc01e5ec05bd0543d04d1a9cb17f5
61fdef6a50c99c98feebd71f499450cf97a8c169
diff --git a/hash-object.c b/hash-object.c
index c8c9adb..3075328 100644
--- a/hash-object.c
+++ b/hash-object.c
@@ -6,6 +6,9 @@
  */
 #include "cache.h"
 
+static const char *prefix;
+static int prefix_length = -1;
+
 static void hash_object(const char *path, const char *type, int write_object)
 {
 	int fd;
@@ -36,10 +39,20 @@ int main(int argc, char **argv)
 				die(hash_object_usage);
 			type = argv[i];
 		}
-		else if (!strcmp(argv[i], "-w"))
+		else if (!strcmp(argv[i], "-w")) {
+			if (prefix_length < 0) {
+				prefix = setup_git_directory();
+				prefix_length = prefix ? strlen(prefix) : 0;
+			}
 			write_object = 1;
-		else
-			hash_object(argv[i], type, write_object);
+		}
+		else {
+			char *arg = argv[i];
+			if (0 <= prefix_length)
+				arg = prefix_filename(prefix, prefix_length,
+						      arg);
+			hash_object(arg, type, write_object);
+		}
 	}
 	return 0;
 }
---
0.99.9.GIT

[PATCH 6/8] ls-tree: work from subdirectory.

[Junio C Hamano]

This makes ls-tree to work from subdirectory.  It defaults to
show the paths under the current subdirectory, and interprets
user-supplied paths as relative to the current subdirectory.

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

---

 ls-tree.c |   21 ++++++++++++++++-----
 1 files changed, 16 insertions(+), 5 deletions(-)

applies-to: 4e55e4796ee699c9361b3751a36a85ba282119a8
40af60bb52cd86e1f089eeb89b2d3d79531c55d1
diff --git a/ls-tree.c b/ls-tree.c
index d9f15e3..ed546a5 100644
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -8,6 +8,8 @@
 #include "tree.h"
 #include "quote.h"
 
+static const char *prefix;
+
 static int line_termination = '\n';
 #define LS_RECURSIVE 1
 #define LS_TREE_ONLY 2
@@ -204,7 +206,7 @@ static int list_one(const char *path)
 	return err;
 }
 
-static int list(char **path)
+static int list(const char **path)
 {
 	int i;
 	int err = 0;
@@ -216,11 +218,16 @@ static int list(char **path)
 static const char ls_tree_usage[] =
 	"git-ls-tree [-d] [-r] [-z] <tree-ish> [path...]";
 
-int main(int argc, char **argv)
+int main(int argc, const char **argv)
 {
-	static char *path0[] = { "", NULL };
-	char **path;
+	static const char *path0[] = { "", NULL };
+	const char **path;
 	unsigned char sha1[20];
+	int nongit = 0;
+
+	prefix = setup_git_directory_gently(&nongit);
+	if (prefix)
+		path0[0] = prefix;
 
 	while (1 < argc && argv[1][0] == '-') {
 		switch (argv[1][1]) {
@@ -244,7 +251,11 @@ int main(int argc, char **argv)
 	if (get_sha1(argv[1], sha1) < 0)
 		usage(ls_tree_usage);
 
-	path = (argc == 2) ? path0 : (argv + 2);
+	if (argc == 2)
+		path = path0;
+	else
+		path = get_pathspec(prefix, argv + 2);
+
 	prepare_root(sha1);
 	if (list(path) < 0)
 		die("list failed");
---
0.99.9.GIT

[PATCH 7/8] Make networking commands to work from a subdirectory.

[Junio C Hamano]

These are whole-tree operations and there is not much point
making them operable from within a subdirectory, but it is easy
to do so, and using setup_git_directory() upfront helps git://
proxy specification picked up from the correct place.

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

---

 clone-pack.c  |    2 ++
 fetch-pack.c  |    2 ++
 http-fetch.c  |    2 ++
 http-push.c   |    1 +
 local-fetch.c |    2 ++
 send-pack.c   |    1 +
 ssh-fetch.c   |    2 ++
 ssh-upload.c  |    3 +++
 8 files changed, 15 insertions(+), 0 deletions(-)

applies-to: 40288d9fe5f400d387e29cd7ec2fa4f1ee4eecca
e01beacec2b24cf1ca59bd8a0fdbe301119ab061
diff --git a/clone-pack.c b/clone-pack.c
index 9609219..a99a95c 100644
--- a/clone-pack.c
+++ b/clone-pack.c
@@ -271,6 +271,8 @@ int main(int argc, char **argv)
 	int fd[2];
 	pid_t pid;
 
+	setup_git_directory();
+
 	nr_heads = 0;
 	heads = NULL;
 	for (i = 1; i < argc; i++) {
diff --git a/fetch-pack.c b/fetch-pack.c
index 6565982..58ba209 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -424,6 +424,8 @@ int main(int argc, char **argv)
 	int fd[2];
 	pid_t pid;
 
+	setup_git_directory();
+
 	nr_heads = 0;
 	heads = NULL;
 	for (i = 1; i < argc; i++) {
diff --git a/http-fetch.c b/http-fetch.c
index 4353173..ad59f1c 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -922,6 +922,8 @@ int main(int argc, char **argv)
 	int arg = 1;
 	int rc = 0;
 
+	setup_git_directory();
+
 	while (arg < argc && argv[arg][0] == '-') {
 		if (argv[arg][1] == 't') {
 			get_tree = 1;
diff --git a/http-push.c b/http-push.c
index 76c7886..250a9b9 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1239,6 +1239,7 @@ int main(int argc, char **argv)
 	int rc = 0;
 	int i;
 
+	setup_git_directory();
 	setup_ident();
 
 	remote = xmalloc(sizeof(*remote));
diff --git a/local-fetch.c b/local-fetch.c
index 0931109..fa9e697 100644
--- a/local-fetch.c
+++ b/local-fetch.c
@@ -207,6 +207,8 @@ int main(int argc, char **argv)
 	char *commit_id;
 	int arg = 1;
 
+	setup_git_directory();
+
 	while (arg < argc && argv[arg][0] == '-') {
 		if (argv[arg][1] == 't')
 			get_tree = 1;
diff --git a/send-pack.c b/send-pack.c
index 3eeb18f..2a14b00 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -273,6 +273,7 @@ int main(int argc, char **argv)
 	int fd[2], ret;
 	pid_t pid;
 
+	setup_git_directory();
 	argv++;
 	for (i = 1; i < argc; i++, argv++) {
 		char *arg = *argv;
diff --git a/ssh-fetch.c b/ssh-fetch.c
index bf01fbc..4eb9e04 100644
--- a/ssh-fetch.c
+++ b/ssh-fetch.c
@@ -131,6 +131,8 @@ int main(int argc, char **argv)
 	prog = getenv("GIT_SSH_PUSH");
 	if (!prog) prog = "git-ssh-upload";
 
+	setup_git_directory();
+
 	while (arg < argc && argv[arg][0] == '-') {
 		if (argv[arg][1] == 't') {
 			get_tree = 1;
diff --git a/ssh-upload.c b/ssh-upload.c
index 603abcc..b675a0b 100644
--- a/ssh-upload.c
+++ b/ssh-upload.c
@@ -121,6 +121,9 @@ int main(int argc, char **argv)
 
 	prog = getenv(COUNTERPART_ENV_NAME);
 	if (!prog) prog = COUNTERPART_PROGRAM_NAME;
+
+	setup_git_directory();
+
 	while (arg < argc && argv[arg][0] == '-') {
 		if (argv[arg][1] == 'w')
 			arg++;
---
0.99.9.GIT

[PATCH 8/8] Make the rest of commands work from a subdirectory.

[Junio C Hamano]

These commands are converted to run from a subdirectory.

    commit-tree convert-objects merge-base merge-index mktag
    pack-objects pack-redundant prune-packed read-tree tar-tree
    unpack-file unpack-objects update-server-info write-tree

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

---

 commit-tree.c        |    2 ++
 convert-objects.c    |    2 ++
 merge-base.c         |    2 ++
 merge-index.c        |    1 +
 mktag.c              |    2 ++
 pack-objects.c       |    2 ++
 pack-redundant.c     |    2 ++
 prune-packed.c       |    2 ++
 read-tree.c          |    2 ++
 tar-tree.c           |    2 ++
 unpack-file.c        |    2 ++
 unpack-objects.c     |    2 ++
 update-server-info.c |    2 ++
 write-tree.c         |    5 ++++-
 14 files changed, 29 insertions(+), 1 deletions(-)

applies-to: 46e976598ab7b7822d7664fdcc88dc63d2e9cf7a
87a21588fb4f8ed433364716ccb90ef934a99585
diff --git a/commit-tree.c b/commit-tree.c
index b60299f..4634b50 100644
--- a/commit-tree.c
+++ b/commit-tree.c
@@ -91,6 +91,8 @@ int main(int argc, char **argv)
 	if (argc < 2 || get_sha1_hex(argv[1], tree_sha1) < 0)
 		usage(commit_tree_usage);
 
+	setup_git_directory();
+
 	check_valid(tree_sha1, "tree");
 	for (i = 2; i < argc; i += 2) {
 		char *a, *b;
diff --git a/convert-objects.c b/convert-objects.c
index a892013..d78a8b4 100644
--- a/convert-objects.c
+++ b/convert-objects.c
@@ -316,6 +316,8 @@ int main(int argc, char **argv)
 	unsigned char sha1[20];
 	struct entry *entry;
 
+	setup_git_directory();
+
 	if (argc != 2 || get_sha1(argv[1], sha1))
 		usage("git-convert-objects <sha1>");
 
diff --git a/merge-base.c b/merge-base.c
index 751c3c2..e73fca7 100644
--- a/merge-base.c
+++ b/merge-base.c
@@ -236,6 +236,8 @@ int main(int argc, char **argv)
 	struct commit *rev1, *rev2;
 	unsigned char rev1key[20], rev2key[20];
 
+	setup_git_directory();
+
 	while (1 < argc && argv[1][0] == '-') {
 		char *arg = argv[1];
 		if (!strcmp(arg, "-a") || !strcmp(arg, "--all"))
diff --git a/merge-index.c b/merge-index.c
index 727527f..024196e 100644
--- a/merge-index.c
+++ b/merge-index.c
@@ -102,6 +102,7 @@ int main(int argc, char **argv)
 	if (argc < 3)
 		usage("git-merge-index [-o] [-q] <merge-program> (-a | <filename>*)");
 
+	setup_git_directory();
 	read_cache();
 
 	i = 1;
diff --git a/mktag.c b/mktag.c
index 585677e..97e270a 100644
--- a/mktag.c
+++ b/mktag.c
@@ -111,6 +111,8 @@ int main(int argc, char **argv)
 	if (argc != 1)
 		usage("cat <signaturefile> | git-mktag");
 
+	setup_git_directory();
+
 	// Read the signature
 	size = 0;
 	for (;;) {
diff --git a/pack-objects.c b/pack-objects.c
index 8864a31..a62c9f8 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -473,6 +473,8 @@ int main(int argc, char **argv)
 	struct object_entry **list;
 	int i;
 
+	setup_git_directory();
+
 	for (i = 1; i < argc; i++) {
 		const char *arg = argv[i];
 
diff --git a/pack-redundant.c b/pack-redundant.c
index 793fa08..0a43278 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -600,6 +600,8 @@ int main(int argc, char **argv)
 	unsigned char *sha1;
 	char buf[42]; /* 40 byte sha1 + \n + \0 */
 
+	setup_git_directory();
+
 	for (i = 1; i < argc; i++) {
 		const char *arg = argv[i];
 		if(!strcmp(arg, "--")) {
diff --git a/prune-packed.c b/prune-packed.c
index 26123f7..d24b097 100644
--- a/prune-packed.c
+++ b/prune-packed.c
@@ -58,6 +58,8 @@ int main(int argc, char **argv)
 {
 	int i;
 
+	setup_git_directory();
+
 	for (i = 1; i < argc; i++) {
 		const char *arg = argv[i];
 
diff --git a/read-tree.c b/read-tree.c
index df156ea..e3b9c0d 100644
--- a/read-tree.c
+++ b/read-tree.c
@@ -629,6 +629,8 @@ int main(int argc, char **argv)
 	unsigned char sha1[20];
 	merge_fn_t fn = NULL;
 
+	setup_git_directory();
+
 	newfd = hold_index_file_for_update(&cache_file, get_index_file());
 	if (newfd < 0)
 		die("unable to create new cachefile");
diff --git a/tar-tree.c b/tar-tree.c
index 970c4bb..bacb23a 100644
--- a/tar-tree.c
+++ b/tar-tree.c
@@ -407,6 +407,8 @@ int main(int argc, char **argv)
 	void *buffer;
 	unsigned long size;
 
+	setup_git_directory();
+
 	switch (argc) {
 	case 3:
 		basedir = argv[2];
diff --git a/unpack-file.c b/unpack-file.c
index d4ac3a5..07303f8 100644
--- a/unpack-file.c
+++ b/unpack-file.c
@@ -29,6 +29,8 @@ int main(int argc, char **argv)
 	if (argc != 2 || get_sha1(argv[1], sha1))
 		usage("git-unpack-file <sha1>");
 
+	setup_git_directory();
+
 	puts(create_temp_file(sha1));
 	return 0;
 }
diff --git a/unpack-objects.c b/unpack-objects.c
index 8490895..cfd61ae 100644
--- a/unpack-objects.c
+++ b/unpack-objects.c
@@ -269,6 +269,8 @@ int main(int argc, char **argv)
 	int i;
 	unsigned char sha1[20];
 
+	setup_git_directory();
+
 	for (i = 1 ; i < argc; i++) {
 		const char *arg = argv[i];
 
diff --git a/update-server-info.c b/update-server-info.c
index e824f62..0b6c383 100644
--- a/update-server-info.c
+++ b/update-server-info.c
@@ -19,5 +19,7 @@ int main(int ac, char **av)
 	if (i != ac)
 		usage(update_server_info_usage);
 
+	setup_git_directory();
+
 	return !!update_server_info(force);
 }
diff --git a/write-tree.c b/write-tree.c
index 2b2c6b7..0aac32f 100644
--- a/write-tree.c
+++ b/write-tree.c
@@ -86,9 +86,12 @@ static int write_tree(struct cache_entry
 int main(int argc, char **argv)
 {
 	int i, funny;
-	int entries = read_cache();
+	int entries;
 	unsigned char sha1[20];
 	
+	setup_git_directory();
+
+	entries = read_cache();
 	if (argc == 2) {
 		if (!strcmp(argv[1], "--missing-ok"))
 			missing_ok = 1;
---
0.99.9.GIT

Re: [PATCH 0/8] Make C-level operable from subdirectories

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Linus Torvalds <torvalds@osdl.org> writes:
>
>> On Fri, 25 Nov 2005, Junio C Hamano wrote:
>>>
>>> I once advocated for an environment to name the top of working
>>> tree directory --- it might make sense to resurrect that one.
>>
>> Please don't. 
>>
>> We should just make the scripts do it automatically instead.
>
> Here comes an 8-patch series.
>
>   [PATCH 1/8] git-apply: work from subdirectory.
>   [PATCH 2/8] peek-remote: honor proxy config even from subdirectory.
>   [PATCH 3/8] fsck-objects: work from subdirectory.
>   [PATCH 4/8] checkout-index: work from subdirectory.
>   [PATCH 5/8] hash-object: work within subdirectory.
>   [PATCH 6/8] ls-tree: work from subdirectory.
>   [PATCH 7/8] Make networking commands to work from a subdirectory.
>   [PATCH 8/8] Make the rest of commands work from a subdirectory.

In case it was not obvious,...

I think your GIT_DIR=`git-rev-parse --git-dir` patch would make
things work better on top of these changes, while making many of
them silently do funny things as you warned.

For example, among the ones I mentioned in my previous message:

 - git-checkout with or without -b to switch branches work.
   This is because "git-read-tree -u" is not constrained by the
   current directory and operates on the whole working tree.

 - git-checkout <ent> <path>... works as expected.  It takes cwd
   relative paths and updates the index and working tree for
   only specified paths from the named ent.

 - git-checkout -f works in a confusing way; only the files
   under the current directory is updated.  This is because
   "git-checkout-index -a" behaves that way.  git-checkout -f to
   revert to the current HEAD is probably good to work this way,
   but doing this while switching branches is too confusing.

 - git-reset --hard also works in a funny way.  It leaves paths
   outside the current directory intact, because ls-tree reports
   only the files in the current directory while ls-files
   reports all.

 - git-prune works.  git-tag works as before.

It could be argued that it was a mistake that [PATCH 4/8] and
[PATCH 6/8] changed checkout-index and ls-tree to limit their
scope to the current directory, but that is consistent with what
rev-list (log and whatchanged) and diff do, and might be
debatably useful.  Which suggests that things like git-checkout
and git-reset whose normal mode of operation should be
whole-tree should chdir up and do the path prefixing to convert
original cwd relative paths to repository relative.

Re: [PATCH 1/8] git-apply: work from subdirectory.

[Linus Torvalds]

On Sat, 26 Nov 2005, Junio C Hamano wrote:
>
> This adds three things:
> 
>  - prefix_filename() is like prefix_path() but can be used to
>    name any file on the filesystem, not the files that might go
>    into the index file.
> 
>  - git-apply uses setup_git_directory() to find out the GIT_DIR
>    and reads configuration file.  Later this would allow us to
>    affect the behaviour of the command from the configuration.
> 
>  - When git-apply is run from a subdirectory, it applies the
>    given patch only to the files under the current directory and
>    below.
> 
> Signed-off-by: Junio C Hamano <junkio@cox.net>

This breaks git-apply when used to just do a "diffstat", or when used on a 
non-git repository.

For "git-apply --stat", we definitely don't want to force it inside a git 
directory. In fact, even _trying_ to find a git directory would be wrong.

The only case where we care about a git directory is the "--index" case. 
In all other cases we should happily apply it (or stat it).

		Linus

Re: [PATCH 6/8] ls-tree: work from subdirectory.

[Linus Torvalds]

On Sat, 26 Nov 2005, Junio C Hamano wrote:
> 
> --- a/ls-tree.c
> +++ b/ls-tree.c
> @@ -8,6 +8,8 @@
>  #include "tree.h"
>  #include "quote.h"
>  
> +static const char *prefix;
> +

No need to have this visible outside of "main()".

> +	prefix = setup_git_directory_gently(&nongit);
> +	if (prefix)
> +		path0[0] = prefix;
...
> +	if (argc == 2)
> +		path = path0;
> +	else
> +		path = get_pathspec(prefix, argv + 2);
> +

And this is just ugly.

git-ls-tree should be rewritten to use a pathspec the same way everybody 
else does. Right now it's the odd man out: if you do

	git-ls-tree HEAD divers/char drivers/

it will show the same files _twice_, which is not how pathspecs in general 
work.

How about this patch? It breaks some of the git-ls-tree tests, but it 
makes git-ls-tree work a lot more like other git pathspec commands, and it 
removes more than 150 lines by re-using the recursive tree traversal (but 
the "-d" flag is gone for good, so I'm not pushing this too hard).

		Linus

---
diff --git a/ls-tree.c b/ls-tree.c
index d9f15e3..598b729 100644
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -13,215 +13,32 @@ static int line_termination = '\n';
 #define LS_TREE_ONLY 2
 static int ls_options = 0;
 
-static struct tree_entry_list root_entry;
-
-static void prepare_root(unsigned char *sha1)
-{
-	unsigned char rsha[20];
-	unsigned long size;
-	void *buf;
-	struct tree *root_tree;
-
-	buf = read_object_with_reference(sha1, "tree", &size, rsha);
-	free(buf);
-	if (!buf)
-		die("Could not read %s", sha1_to_hex(sha1));
-
-	root_tree = lookup_tree(rsha);
-	if (!root_tree)
-		die("Could not read %s", sha1_to_hex(sha1));
-
-	/* Prepare a fake entry */
-	root_entry.directory = 1;
-	root_entry.executable = root_entry.symlink = 0;
-	root_entry.mode = S_IFDIR;
-	root_entry.name = "";
-	root_entry.item.tree = root_tree;
-	root_entry.parent = NULL;
-}
-
-static int prepare_children(struct tree_entry_list *elem)
-{
-	if (!elem->directory)
-		return -1;
-	if (!elem->item.tree->object.parsed) {
-		struct tree_entry_list *e;
-		if (parse_tree(elem->item.tree))
-			return -1;
-		/* Set up the parent link */
-		for (e = elem->item.tree->entries; e; e = e->next)
-			e->parent = elem;
-	}
-	return 0;
-}
-
-static struct tree_entry_list *find_entry(const char *path, char *pathbuf)
-{
-	const char *next, *slash;
-	int len;
-	struct tree_entry_list *elem = &root_entry, *oldelem = NULL;
-
-	*(pathbuf) = '\0';
-
-	/* Find tree element, descending from root, that
-	 * corresponds to the named path, lazily expanding
-	 * the tree if possible.
-	 */
-
-	while (path) {
-		/* The fact we still have path means that the caller
-		 * wants us to make sure that elem at this point is a
-		 * directory, and possibly descend into it.  Even what
-		 * is left is just trailing slashes, we loop back to
-		 * here, and this call to prepare_children() will
-		 * catch elem not being a tree.  Nice.
-		 */
-		if (prepare_children(elem))
-			return NULL;
-
-		slash = strchr(path, '/');
-		if (!slash) {
-			len = strlen(path);
-			next = NULL;
-		}
-		else {
-			next = slash + 1;
-			len = slash - path;
-		}
-		if (len) {
-			if (oldelem) {
-				pathbuf += sprintf(pathbuf, "%s/", oldelem->name);
-			}
-
-			/* (len == 0) if the original path was "drivers/char/"
-			 * and we have run already two rounds, having elem
-			 * pointing at the drivers/char directory.
-			 */
-			elem = elem->item.tree->entries;
-			while (elem) {
-				if ((strlen(elem->name) == len) &&
-				    !strncmp(elem->name, path, len)) {
-					/* found */
-					break;
-				}
-				elem = elem->next;
-			}
-			if (!elem)
-				return NULL;
-
-			oldelem = elem;
-		}
-		path = next;
-	}
-
-	return elem;
-}
-
-static const char *entry_type(struct tree_entry_list *e)
-{
-	return (e->directory ? "tree" : "blob");
-}
-
-static const char *entry_hex(struct tree_entry_list *e)
-{
-	return sha1_to_hex(e->directory
-			   ? e->item.tree->object.sha1
-			   : e->item.blob->object.sha1);
-}
-
-/* forward declaration for mutually recursive routines */
-static int show_entry(struct tree_entry_list *, int, char *pathbuf);
-
-static int show_children(struct tree_entry_list *e, int level, char *pathbuf)
-{
-	int oldlen = strlen(pathbuf);
-
-	if (e != &root_entry)
-		sprintf(pathbuf + oldlen, "%s/", e->name);
-
-	if (prepare_children(e))
-		die("internal error: ls-tree show_children called with non tree");
-	e = e->item.tree->entries;
-	while (e) {
-		show_entry(e, level, pathbuf);
-		e = e->next;
-	}
-
-	pathbuf[oldlen] = '\0';
-
-	return 0;
-}
+static const char ls_tree_usage[] =
+	"git-ls-tree [-d] [-r] [-z] <tree-ish> [path...]";
 
-static int show_entry(struct tree_entry_list *e, int level, char *pathbuf)
+static int show_tree(unsigned char *sha1, const char *base, int baselen, const char *pathname, unsigned mode, int stage)
 {
-	int err = 0; 
-
-	if (e != &root_entry) {
-		printf("%06o %s %s	",
-		       e->mode, entry_type(e), entry_hex(e));
-		write_name_quoted(pathbuf, e->name, line_termination, stdout);
-		putchar(line_termination);
-	}
+	const char *type = "blob";
+	int retval = 0;
 
-	if (e->directory) {
-		/* If this is a directory, we have the following cases:
-		 * (1) This is the top-level request (explicit path from the
-		 *     command line, or "root" if there is no command line).
-		 *  a. Without any flag.  We show direct children.  We do not 
-		 *     recurse into them.
-		 *  b. With -r.  We do recurse into children.
-		 *  c. With -d.  We do not recurse into children.
-		 * (2) We came here because our caller is either (1-a) or
-		 *     (1-b).
-		 *  a. Without any flag.  We do not show our children (which
-		 *     are grandchildren for the original request).
-		 *  b. With -r.  We continue to recurse into our children.
-		 *  c. With -d.  We should not have come here to begin with.
-		 */
-		if (level == 0 && !(ls_options & LS_TREE_ONLY))
-			/* case (1)-a and (1)-b */
-			err = err | show_children(e, level+1, pathbuf);
-		else if (level && ls_options & LS_RECURSIVE)
-			/* case (2)-b */
-			err = err | show_children(e, level+1, pathbuf);
+	if (S_ISDIR(mode)) {
+		type = "tree";
+		if (ls_options & LS_RECURSIVE)
+			retval = READ_TREE_RECURSIVE;
 	}
-	return err;
-}
 
-static int list_one(const char *path)
-{
-	int err = 0;
-	char pathbuf[MAXPATHLEN + 1];
-	struct tree_entry_list *e = find_entry(path, pathbuf);
-	if (!e) {
-		/* traditionally ls-tree does not complain about
-		 * missing path.  We may change this later to match
-		 * what "/bin/ls -a" does, which is to complain.
-		 */
-		return err;
-	}
-	err = err | show_entry(e, 0, pathbuf);
-	return err;
+	printf("%06o %s %s\t%.*s%s%c", mode, type, sha1_to_hex(sha1), baselen, base, pathname, line_termination);
+	return retval;
 }
 
-static int list(char **path)
+int main(int argc, const char **argv)
 {
-	int i;
-	int err = 0;
-	for (i = 0; path[i]; i++)
-		err = err | list_one(path[i]);
-	return err;
-}
-
-static const char ls_tree_usage[] =
-	"git-ls-tree [-d] [-r] [-z] <tree-ish> [path...]";
-
-int main(int argc, char **argv)
-{
-	static char *path0[] = { "", NULL };
-	char **path;
+	const char **path, *prefix;
 	unsigned char sha1[20];
+	char *buf;
+	unsigned long size;
 
+	prefix = setup_git_directory();
 	while (1 < argc && argv[1][0] == '-') {
 		switch (argv[1][1]) {
 		case 'z':
@@ -244,9 +61,11 @@ int main(int argc, char **argv)
 	if (get_sha1(argv[1], sha1) < 0)
 		usage(ls_tree_usage);
 
-	path = (argc == 2) ? path0 : (argv + 2);
-	prepare_root(sha1);
-	if (list(path) < 0)
-		die("list failed");
+	path = get_pathspec(prefix, argv + 2);
+	buf = read_object_with_reference(sha1, "tree", &size, NULL);
+	if (!buf)
+		die("not a tree object");
+	read_tree_recursive(buf, size, "", 0, 0, path, show_tree);
+
 	return 0;
 }
diff --git a/tree.c b/tree.c
index 8b42a07..043f032 100644
--- a/tree.c
+++ b/tree.c
@@ -9,9 +9,16 @@ const char *tree_type = "tree";
 
 static int read_one_entry(unsigned char *sha1, const char *base, int baselen, const char *pathname, unsigned mode, int stage)
 {
-	int len = strlen(pathname);
-	unsigned int size = cache_entry_size(baselen + len);
-	struct cache_entry *ce = xmalloc(size);
+	int len;
+	unsigned int size;
+	struct cache_entry *ce;
+
+	if (S_ISDIR(mode))
+		return READ_TREE_RECURSIVE;
+
+	len = strlen(pathname);
+	size = cache_entry_size(baselen + len);
+	ce = xmalloc(size);
 
 	memset(ce, 0, size);
 
@@ -67,9 +74,10 @@ static int match_tree_entry(const char *
 	return 0;
 }
 
-static int read_tree_recursive(void *buffer, unsigned long size,
-			       const char *base, int baselen,
-			       int stage, const char **match)
+int read_tree_recursive(void *buffer, unsigned long size,
+			const char *base, int baselen,
+			int stage, const char **match,
+			read_tree_fn_t fn)
 {
 	while (size) {
 		int len = strlen(buffer)+1;
@@ -86,6 +94,14 @@ static int read_tree_recursive(void *buf
 		if (!match_tree_entry(base, baselen, path, mode, match))
 			continue;
 
+		switch (fn(sha1, base, baselen, path, mode, stage)) {
+		case 0:
+			continue;
+		case READ_TREE_RECURSIVE:
+			break;;
+		default:
+			return -1;
+		}
 		if (S_ISDIR(mode)) {
 			int retval;
 			int pathlen = strlen(path);
@@ -106,22 +122,20 @@ static int read_tree_recursive(void *buf
 			retval = read_tree_recursive(eltbuf, eltsize,
 						     newbase,
 						     baselen + pathlen + 1,
-						     stage, match);
+						     stage, match, fn);
 			free(eltbuf);
 			free(newbase);
 			if (retval)
 				return -1;
 			continue;
 		}
-		if (read_one_entry(sha1, base, baselen, path, mode, stage) < 0)
-			return -1;
 	}
 	return 0;
 }
 
 int read_tree(void *buffer, unsigned long size, int stage, const char **match)
 {
-	return read_tree_recursive(buffer, size, "", 0, stage, match);
+	return read_tree_recursive(buffer, size, "", 0, stage, match, read_one_entry);
 }
 
 struct tree *lookup_tree(const unsigned char *sha1)
diff --git a/tree.h b/tree.h
index 9975e88..768e5e9 100644
--- a/tree.h
+++ b/tree.h
@@ -35,4 +35,13 @@ int parse_tree(struct tree *tree);
 /* Parses and returns the tree in the given ent, chasing tags and commits. */
 struct tree *parse_tree_indirect(const unsigned char *sha1);
 
+#define READ_TREE_RECURSIVE 1
+typedef int (*read_tree_fn_t)(unsigned char *, const char *, int, const char *, unsigned int, int);
+
+extern int read_tree_recursive(void *buffer, unsigned long size,
+			const char *base, int baselen,
+			int stage, const char **match,
+			read_tree_fn_t fn);
+
+
 #endif /* TREE_H */

Re: [PATCH 0/8] Make C-level operable from subdirectories

[Ryan Anderson]

On Sat, Nov 26, 2005 at 01:51:41AM -0800, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
> 
> > On Fri, 25 Nov 2005, Junio C Hamano wrote:
> >>
> >> I once advocated for an environment to name the top of working
> >> tree directory --- it might make sense to resurrect that one.
> >
> > Please don't. 
> >
> > We should just make the scripts do it automatically instead.
> 
> Here comes an 8-patch series.

Should the documentation get an update to mention that using GIT_DIR to
create a totally out-of-tree setup is supported, but not recommended?

-- 

Ryan Anderson
  sometimes Pug Majere

Re: [PATCH 1/8] git-apply: work from subdirectory.

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> The only case where we care about a git directory is the "--index" case. 
> In all other cases we should happily apply it (or stat it).

True.  We should do the same as peek-remote.

Re: Get rid of .git/branches/ and .git/remotes/?

[Petr Baudis]

Dear diary, on Sun, Nov 20, 2005 at 08:50:41PM CET, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > And I'm not 100% convinced that putting these branches in the config file 
> > has any real advantages over keeping them as separate files. Having 
> > everything in one place is nice, of course, and being able to copy just 
> > one file around might be convenient, but it _does_ make the config file 
> > more complicated.
> 
> And it _does_ make finding the information for less savvy git users more 
> easy.

Is that so?

I'm not 50% convinced, but if people are excited about it, I can live
with it; in that case I would like appropriately powerful
git-repo-config, though - so that I can say "list me all branch.*
section names". Surely I could play some ugly grep games, but ideally,
I would like to avoid peeking into the .git/config file directly
altogether in Cogito - call that proper layering. ;-)

> I'm not 100% convinced, either, but it could be a better concept than 
> different files in different places and different formats basically doing 
> the same.
> 
> But my thinking went like this: if Pasky and Junio can not agree on one 
> location and format, and therefore none of the two is deprecated, how 
> about giving them a way out they both might be able to agree to?

Now, those are just different concepts. Cogito's "branch" concept maps
single local head to a single remote head, 1:1. GIT's "remote" concept
maps (possibly not well-defined) bunch of local heads to a remote
repository (where they have same or different name) or a piece of it; to
accomplish this, it introduces a whole new rather complicated concept,
which nevertheless in part shares the namespace with heads (branches).

Surely, remotes are more flexible, but from the end-user perspective
they really act just as kind of "macros" compared to branches, except
that it's faster when you fetch multiple branches at once than when you
do it in sequence. I might add support for multibranch fetches to
Cogito, and I still intend to implement "readonly" remotes support for
the sake of compatibility with GIT, but I plan to stick to branches
otherwise. It's confusing enough to have remote and local heads, and
actually remotes make it even more confusing since you direct your
"direct touch" with the remote heads, now covered in some more abstract
entity.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: Get rid of .git/branches/ and .git/remotes/?

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

>> But my thinking went like this: if Pasky and Junio can not agree on one 
>> location and format, and therefore none of the two is deprecated, how 
>> about giving them a way out they both might be able to agree to?
>
> Now, those are just different concepts. Cogito's "branch" concept maps
> single local head to a single remote head, 1:1. GIT's "remote" concept
> maps (possibly not well-defined) bunch of local heads to a remote
> repository (where they have same or different name) or a piece of it...

I agree.  They are simply different things and serve different
audiences.

When you are asked to pull from somebody else (and when you are
playing an integrator role, not an individual developer role,
you will be asked to pull from different people) you may not
want to immediately pull into your master branch.  I usually
either do "git checkout -b throwaway master" and pull into it,
or run "git fetch remote master:throwaway" followed by "git diff
master throwaway" to see what I'll be getting.  When you set up
one "remotes" file is when you realize that you are pulling this
way from the same place number of times, to reduce future
typing.  So as Pasky says, it is exactly "macro" and not "per
branch configuration".  It is just "per remote shorthand".

Cogito "branch" matches very naturally to what an individual
developer might want to do.  You have one branch that you use to
do your work tracking one upstream.  You can of course have more
than one upstream and branch, but the most typical usage would
be traditional CVS style setup to get updates from the central
location (described in branches/* file), fetch and merge from
there and push your changes back.  It is very well designed to
support this pattern of usage.

It may not make much sense for an integrator-role person to have
branches/master file to configure his "master" branch that
points at the URL of only one of his subsystem maintainers.  An
integrator-role person does not need "per branch" configuration
in that sense.  On the other hand "remotes" may help if the
integrator-role person regularly pulls from the same set of
subsystem maintainers.

Of course, an individual developer can set up a single remotes
file that describes the single upstream, fetching
"master:origin" and merging into his "master"; what "remotes"
file used that way does not give us, unlike "branch" of Cogito,
is that it does not say on which local branch that fetching and
merging happens.

Re: [PATCH 1/8] git-apply: work from subdirectory.

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> This breaks git-apply when used to just do a "diffstat", or
> when used on a non-git repository.

You are right.  Something like this?


An off-topic note (that's why this message is CC'd to larsi).
People may notice messages in this thread have accumulated a
modest number of References: entries.  I read git list via
new.gmane.org NNTP server (running fetchnews locally to slurp
from there) and noticed droppage on my end --- whose cause turns
out to be that gmane NNTP server chops References: entries in
the middle and fetchnews rejects such messages, and I am sure I
am _not_ going to see this message on my local machine.  Has
anybody else noticed this problem?

-- >8 --
[PATCH] apply: only do GIT_DIR discovery when running with --index.
    
It does not have to be run in git repository unless we are
applying or checking the patch to the index file.

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

diff --git a/apply.c b/apply.c
index ae06d41..1742ab2 100644
--- a/apply.c
+++ b/apply.c
@@ -17,7 +17,7 @@
 //  --index-info shows the old and new index info for paths if available.
 //
 static const char *prefix;
-static int prefix_length;
+static int prefix_length = -1;
 
 static int allow_binary_replacement = 0;
 static int check_index = 0;
@@ -1709,7 +1709,7 @@ static int use_patch(struct patch *p)
 			return 0;
 		x = x->next;
 	}
-	if (prefix && *prefix) {
+	if (0 < prefix_length) {
 		int pathlen = strlen(pathname);
 		if (pathlen <= prefix_length ||
 		    memcmp(prefix, pathname, prefix_length))
@@ -1793,10 +1793,6 @@ int main(int argc, char **argv)
 	int i;
 	int read_stdin = 1;
 
-	prefix = setup_git_directory();
-	prefix_length = prefix ? strlen(prefix) : 0;
-	git_config(git_default_config);
-
 	for (i = 1; i < argc; i++) {
 		const char *arg = argv[i];
 		int fd;
@@ -1858,7 +1854,14 @@ int main(int argc, char **argv)
 			line_termination = 0;
 			continue;
 		}
-		arg = prefix_filename(prefix, prefix_length, arg);
+
+		if (check_index && prefix_length < 0) {
+			prefix = setup_git_directory();
+			prefix_length = prefix ? strlen(prefix) : 0;
+			git_config(git_default_config);
+		}
+		if (0 < prefix_length)
+			arg = prefix_filename(prefix, prefix_length, arg);
 
 		fd = open(arg, O_RDONLY);
 		if (fd < 0)

Re: [PATCH 6/8] ls-tree: work from subdirectory.

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> And this is just ugly.
>
> git-ls-tree should be rewritten to use a pathspec the same way everybody 
> else does. Right now it's the odd man out: if you do
>
> 	git-ls-tree HEAD divers/char drivers/
>
> it will show the same files _twice_, which is not how pathspecs in general 
> work.

True; that is more or less deliberate.  The behaviour is
modelled after what "/bin/ls -a" does.

> How about this patch? It breaks some of the git-ls-tree tests, but it 
> makes git-ls-tree work a lot more like other git pathspec commands, and it 
> removes more than 150 lines by re-using the recursive tree traversal (but 
> the "-d" flag is gone for good, so I'm not pushing this too hard).

I am all for it if it were just me, and all the more so for its
cleanup value.  I do not think anybody uses "-d" (none of
Cogito, StGIT nor gitweb seems to use it, and I have not seen
Jason McMullan, who wanted to have a way in ls-tree to see just
the object name of a subtree, on the list for a while); I
suspect that nobody would miss that option.

However, this patch changes its behaviour in another way, and
that could impact Porcelains more than the removal of the "-d"
option.  Currently, "git-ls-tree <tree> $dir" shows what
"/bin/ls -a -1 $dir" would show --- the tree for $dir itself and
its immediate children.  This patch changes it to show the tree
for $dir and nothing else.  In effect, "-d" becomes the default
that you cannot turn off, except using "-r" to allow it go all
the way down.

I do not think StGIT is affected; it does not use ls-tree at all.
gitweb is not affected either.  It does not use paths specifier.

Cogito might need a slight adjustment.

 - cg-admin-cat may want to use -r for the first one (${ARGS[@]}
   may name a directory), but that also would change the
   behaviour.  The current one shows only one level, instead of
   going all the way down.

 - cg-log:117 uses ls-tree without -r, but I have a feeling that
   it might be just a bug, even with the current ls-tree; I
   suspect the user would not see things in subdirectories.
   This is only for the initial commit so it may or may not
   matter much.

 - cg-restore already uses ls-tree -r so that would not be
   affected.

Re: [PATCH 6/8] ls-tree: work from subdirectory.

[Petr Baudis]

Dear diary, on Sun, Nov 27, 2005 at 10:21:53AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
>  - cg-admin-cat may want to use -r for the first one (${ARGS[@]}
>    may name a directory), but that also would change the
>    behaviour.  The current one shows only one level, instead of
>    going all the way down.

I think the current behaviour is nonsensical, since it cats all the
files in the subdirectory, instead of just listing it. Didn't
git-ls-tree already have the -d implicit sometime in the past? At any
rate, the change to git-ls-tree would fix this. :-)

>  - cg-log:117 uses ls-tree without -r, but I have a feeling that
>    it might be just a bug, even with the current ls-tree; I
>    suspect the user would not see things in subdirectories.
>    This is only for the initial commit so it may or may not
>    matter much.

Thanks, fixed. It uses -r now.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: [PATCH 1/8] git-apply: work from subdirectory.

[Lars Magne Ingebrigtsen]

Junio C Hamano <junkio@cox.net> writes:

> I read git list via new.gmane.org NNTP server (running fetchnews
> locally to slurp from there) and noticed droppage on my end ---
> whose cause turns out to be that gmane NNTP server chops References:
> entries in the middle and fetchnews rejects such messages, and I am
> sure I am _not_ going to see this message on my local machine.

No, news.gmane.org doesn't chop any references.  But if you happen to
use a news reader that takes rfc1036bis and rfc2822 seriously (like,
ahem, Gnus), it'll chop the References header to get the size under
1024 octets.

If this gives fetchnews problems, then, er, fetchnews has problems.
Serious problems.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: [PATCH 6/8] ls-tree: work from subdirectory.

[Linus Torvalds]

On Sun, 27 Nov 2005, Junio C Hamano wrote:
> 
> True; that is more or less deliberate.  The behaviour is
> modelled after what "/bin/ls -a" does.

Yes, I did realize, and maybe it's fine. It's just that right now, 
git-ls-tree doesn't work like git-ls-files, which is kind of sad.

I suspect not a lot of people use git-ls-tree, and that's probably why it 
never was updated to match anything else.

It would be nice (I think) if git-ls-tree matched git-ls-files the same 
way git-diff-tree matches git-diff-files: exact same behaviour, except one 
works on a tree and another on the index. And like the git-diff-*, the 
index would always default to "-r", while for the tree version you would 
have to specify it.

(Yeah, there are differences. git-ls-files has the "--others" etc logic, 
but I think there are more similarities than differences).

> However, this patch changes its behaviour in another way, and
> that could impact Porcelains more than the removal of the "-d"
> option.  Currently, "git-ls-tree <tree> $dir" shows what
> "/bin/ls -a -1 $dir" would show --- the tree for $dir itself and
> its immediate children.  This patch changes it to show the tree
> for $dir and nothing else.  In effect, "-d" becomes the default
> that you cannot turn off, except using "-r" to allow it go all
> the way down.

No, actually, it's even stranger than that.

If you use "-r", it acts the way you'd expect. If you _don't_ use "-r", it 
acts strangely, but very consistently with git-diff-tree: it only ever 
shows the _first_ part of a pathname. So

	git-ls-tree HEAD drivers/char/

should show just one entry: "drivers". While adding a "-r" should show all 
files under drivers (and the trees leading up to it).

And yes, you're right. That's a much bigger change by my suggested diff, 
and more likely to cause confusion.

			Linus

Re: [PATCH 6/8] ls-tree: work from subdirectory.

[Petr Baudis]

Dear diary, on Sun, Nov 27, 2005 at 07:01:37PM CET, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> If you use "-r", it acts the way you'd expect. If you _don't_ use "-r", it 
> acts strangely, but very consistently with git-diff-tree: it only ever 
> shows the _first_ part of a pathname. So
> 
> 	git-ls-tree HEAD drivers/char/
> 
> should show just one entry: "drivers". While adding a "-r" should show all 
> files under drivers (and the trees leading up to it).
> 
> And yes, you're right. That's a much bigger change by my suggested diff, 
> and more likely to cause confusion.

Ugh. That's really weird. Wouldn't a better approach be to fix
git-ls-files to behave more sanely? (That is, listing the entry for
drivers/char instead of drivers?)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: [PATCH 6/8] ls-tree: work from subdirectory.

[Linus Torvalds]

On Sun, 27 Nov 2005, Petr Baudis wrote:

> Dear diary, on Sun, Nov 27, 2005 at 07:01:37PM CET, I got a letter
> where Linus Torvalds <torvalds@osdl.org> said that...
> > If you use "-r", it acts the way you'd expect. If you _don't_ use "-r", it 
> > acts strangely, but very consistently with git-diff-tree: it only ever 
> > shows the _first_ part of a pathname. So
> > 
> > 	git-ls-tree HEAD drivers/char/
> > 
> > should show just one entry: "drivers". While adding a "-r" should show all 
> > files under drivers (and the trees leading up to it).
> > 
> > And yes, you're right. That's a much bigger change by my suggested diff, 
> > and more likely to cause confusion.
> 
> Ugh. That's really weird. Wouldn't a better approach be to fix
> git-ls-files to behave more sanely? (That is, listing the entry for
> drivers/char instead of drivers?)

Well, it's not actually confusing if you see a path spec for what it is: 
it's not a filename, it's a _pattern_.

So you should always do

	git-ls-tree -r pattern

(and yes, we could even hardcode "-r", because git-ls-tree without it 
really is a pretty strange thing).

The _real_ strangeness in "git-ls-tree" is that it shows the tree nodes at 
all, which no other git tool does when it recurses. 

To get more a "git-ls-files" approach, this trivial patch (on top of my 
previous one) enables recursion (and right now you can't disable it any 
way), and doesn't show partial trees.

I could make it work much more like git-ls-files, in that it could accept 
wildcards. Something like

	git-ls-tree HEAD '*.c'

would show all C files (recursively), the same way git-ls-files does for 
the index.

Hmm?

		Linus

----
diff --git a/ls-tree.c b/ls-tree.c
index 598b729..cf0dbbc 100644
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -11,7 +11,7 @@
 static int line_termination = '\n';
 #define LS_RECURSIVE 1
 #define LS_TREE_ONLY 2
-static int ls_options = 0;
+static int ls_options = LS_RECURSIVE;
 
 static const char ls_tree_usage[] =
 	"git-ls-tree [-d] [-r] [-z] <tree-ish> [path...]";
@@ -19,16 +19,15 @@ static const char ls_tree_usage[] =
 static int show_tree(unsigned char *sha1, const char *base, int baselen, const char *pathname, unsigned mode, int stage)
 {
 	const char *type = "blob";
-	int retval = 0;
 
 	if (S_ISDIR(mode)) {
-		type = "tree";
 		if (ls_options & LS_RECURSIVE)
-			retval = READ_TREE_RECURSIVE;
+			return READ_TREE_RECURSIVE;
+		type = "tree";
 	}
 
 	printf("%06o %s %s\t%.*s%s%c", mode, type, sha1_to_hex(sha1), baselen, base, pathname, line_termination);
-	return retval;
+	return 0;
 }
 
 int main(int argc, const char **argv)

Re: [PATCH 1/8] git-apply: work from subdirectory.

[Lars Magne Ingebrigtsen]

Junio C Hamano <junkio@cox.net> writes:

> It may be that news.gmane.org doesn't chop, but somebody between
> vger.kernel.org mailing list manager and what comes out of the
> newsserver does. 

Egads!  It's all my fault -- there's some code in the mail-to-news
script that's truncating long header lines, and nobody's noticed up
'till now.  I've now twiddled it slightly; it should stop mangling
References headers now...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: [PATCH 1/8] git-apply: work from subdirectory.

[Junio C Hamano]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Egads!  It's all my fault -- there's some code in the mail-to-news
> script that's truncating long header lines, and nobody's noticed up
> 'till now.  I've now twiddled it slightly; it should stop mangling
> References headers now...

Thanks, it looks good now --- checked with your message I am
responding to ;-).

Re: [PATCH 6/8] ls-tree: work from subdirectory.

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> On Sun, 27 Nov 2005, Petr Baudis wrote:
>> Ugh. That's really weird. Wouldn't a better approach be to fix
>> git-ls-files to behave more sanely? (That is, listing the entry for
>> drivers/char instead of drivers?)

It behaves sanely, just not in the way you are expecting.

> Well, it's not actually confusing if you see a path spec for
> what it is: it's not a filename, it's a _pattern_.

Well, that is confusing, although it may be sane.

> So you should always do
>
> 	git-ls-tree -r pattern
>
> (and yes, we could even hardcode "-r", because git-ls-tree without it 
> really is a pretty strange thing).

If you mean "in the presense of pathspec, default to -r", I
*might* agree, but I am not convinced yet.

Without pathspec, ls-tree is a pretty-printing version of
"git-cat-file tree", and that is how the command is used by the
git browsers like gitweb.  I have never looked at qgit source,
but I'd be surprised if it did not depend on the single-level
behaviour of ls-tree for that purpose.

It *is* "/bin/ls" after all, and you _would_ get annoyed if your
/bin/ls always recursed if you gave an argument.  Imagine going
to the kernel source and try "/bin/ls arch" with your version of
/bin/ls that always recurses, when you only wanted to get the
list of architectures you are supporting ;-).

> The _real_ strangeness in "git-ls-tree" is that it shows the tree nodes at 
> all, which no other git tool does when it recurses. 

Very true.  I do not think even git browsers need that but I may
be mistaken.

Having said all of the above, I do understand why we would
_also_ want the behaviour parallel to ls-files, not /bin/ls
behaviour.  Maybe we should have both?  Either rename the
current ls-tree to browse-tree, and make the one that parallels
ls-files the new ls-tree?

Re: [PATCH 6/8] ls-tree: work from subdirectory.

[Linus Torvalds]

On Sun, 27 Nov 2005, Junio C Hamano wrote:
> 
> Without pathspec, ls-tree is a pretty-printing version of
> "git-cat-file tree", and that is how the command is used by the
> git browsers like gitweb.  I have never looked at qgit source,
> but I'd be surprised if it did not depend on the single-level
> behaviour of ls-tree for that purpose.

You're right, we need to keep the "-r" behaviour. 

> Having said all of the above, I do understand why we would
> _also_ want the behaviour parallel to ls-files, not /bin/ls
> behaviour.  Maybe we should have both?  Either rename the
> current ls-tree to browse-tree, and make the one that parallels
> ls-files the new ls-tree?

If you take my last patch and make "ls_flags" default to 0 again, it 
should work correctly.

The way to traverse into directories (a la qgit/webgit) is to just give 
the SHA1 name of the directory. Ie

	git-ls-tree HEAD

gives us a single level, we see:

	...
	040000 tree b2d1264f85148d18c5ae9864d73d65737b0a1734    t
	...

and then we can just do

	git-ls-tree b2d1264f85148d18c5ae9864d73d65737b0a1734

to get that level. I assume that that is what qgit/webgit already does (I 
sure hope so, otherwise they're just wasting time, making the tools 
re-parse the trees over and over again for no gain).

			Linus

Re: [PATCH 6/8] ls-tree: work from subdirectory.

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> You're right, we need to keep the "-r" behaviour. 
> If you take my last patch and make "ls_flags" default to 0 again, it 
> should work correctly.

Maybe making "-r" the default and resurrecting "-d" to turn it
off would be the approach of least impact (-r becomes a
noiseword), if we take this "ls-tree should parallel ls-files"
idea.

The merge-recursive strategy uses ls-tree without -r with path
specifier to grab the sha1/mode of the three trees involved.
git-cvsexportcommit has the same assumption on how ls-tree
works.  It extracts a single SHA1 for the blob from the commit
object by "ls-tree $commit $blob_path".

With your two patches, they need to do this with "-r".

git-checkout and git-reset use -r to grab the whole tree, so
they are fine either way.  git-svnimport uses -r to read from a
tree (potentially a subtree) all the way down, so this one is
also fine.

So it probably is safer to default ls_options to LS_RECURSIVE,
and use "-d" to restrict it not to recurse.

But after seeing some more examples, I tend to think the current
one that models after how "/bin/ls -a" works in a way that is a
lot easier to understand.  For example, with your two patches
(defaulting to recursive)

	git-ls-tree HEAD

shows everything from the tree.  In order to get prettyprint of
HEAD tree (i.e. single level listing):

	git-ls-tree -d HEAD

is needed.  But there is no way to get the single level with
pathspec with these patches, so:

	cd Documentation && git-ls-tree -d HEAD

would not show the single level of Documentation tree, but just
a single line "tree" object of Documentation tree.  Which means
the way it works from the top and the way it works in a
subdirectory is quite different.

I'll throw in your two patches to the proposed updates branch so
that Porcelain/Browser people can play with it and decide.  I
really love the decrease of number of lines of code, but I am
afraid this would end up breaking things without real merit.

Re: [PATCH 6/8] ls-tree: work from subdirectory.

[Linus Torvalds]

On Sun, 27 Nov 2005, Junio C Hamano wrote:
> 
> So it probably is safer to default ls_options to LS_RECURSIVE,
> and use "-d" to restrict it not to recurse.

I have a patch that solves all the problems, I think.

It modifies the selection a bit, so that a pathspec that is a superset of 
a particular tree path will always cause it to recurse into that tree.

As an example, let's say that we do

	git-ls-tree HEAD drivers/char

_without_ the "-r". What will happen is that it will start out doing all 
the base tree, and for "drivers" it will notice that it's a proper subset 
of "drivers/char", so it will always recurse into _that_ tree (but not 
into other trees).

Then, it will not match anything else than "char" in that subdirectory, 
and because that's not a proper superset (it's an exact match), it will 
_not_ recurse into it, so you get:

	[torvalds@g5 linux]$ ~/git/git-ls-tree HEAD drivers/char
	040000 tree 9568cda453aae205bb58983747fa73b9696d9d51    drivers/char

which is what you got with the old git-ls-tree too.

But interestingly, if you add the slash, it will become a proper superset 
and it will recurse into _that_ subdirectory (but no deeper: so if you 
want all subdirectories _below_ drivers/char/, you still need to give 
"-r"):

	[torvalds@g5 linux]$ ~/git/git-ls-tree HEAD drivers/char/
	100644 blob 2b6b1d772ed776fff87927fc34adc2e40500218e    drivers/char/.gitignore
	100644 blob 56b8a2e76ab10a5c21787cb7068a846075cbaffd    drivers/char/ChangeLog
	100644 blob 970f70d498f4c814e1cf3362e33d7e23ac53c299    drivers/char/Kconfig
	...

See? This is on top of the previous two diffs, holler if you want a whole 
new "everything combined" version..

It hasn't gotten lots of testing, but it should work.

BTW! It fails a few of the tests, but it does so because now, with "-r", 
it will never show the tree entries, and because of the difference between

	git-ls-tree $tree path

and

	git-ls-tree $tree path/

that it didn't use to have (oh, and if you give multiple paths, it will 
now always consider them a "union pathspec", not an "iteration of paths"). 
But I _think_ the new behaviour is pretty useful and while not the same as 
"ls", it's perhaps still intuitive enough..

		Linus

---
diff --git a/ls-tree.c b/ls-tree.c
index cf0dbbc..4df5830 100644
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -11,7 +11,8 @@
 static int line_termination = '\n';
 #define LS_RECURSIVE 1
 #define LS_TREE_ONLY 2
-static int ls_options = LS_RECURSIVE;
+static int ls_options = 0;
+const char **pathspec;
 
 static const char ls_tree_usage[] =
 	"git-ls-tree [-d] [-r] [-z] <tree-ish> [path...]";
@@ -21,8 +22,29 @@ static int show_tree(unsigned char *sha1
 	const char *type = "blob";
 
 	if (S_ISDIR(mode)) {
+		const char **s;
 		if (ls_options & LS_RECURSIVE)
 			return READ_TREE_RECURSIVE;
+		s = pathspec;
+		if (s) {
+			for (;;) {
+				const char *spec = *s++;
+				int len, speclen;
+
+				if (!spec)
+					break;
+				if (strncmp(base, spec, baselen))
+					continue;
+				len = strlen(pathname);
+				spec += baselen;
+				speclen = strlen(spec);
+				if (speclen <= len)
+					continue;
+				if (memcmp(pathname, spec, len))
+					continue;
+				return READ_TREE_RECURSIVE;
+			}
+		}
 		type = "tree";
 	}
 
@@ -32,7 +54,7 @@ static int show_tree(unsigned char *sha1
 
 int main(int argc, const char **argv)
 {
-	const char **path, *prefix;
+	const char *prefix;
 	unsigned char sha1[20];
 	char *buf;
 	unsigned long size;
@@ -60,11 +82,11 @@ int main(int argc, const char **argv)
 	if (get_sha1(argv[1], sha1) < 0)
 		usage(ls_tree_usage);
 
-	path = get_pathspec(prefix, argv + 2);
+	pathspec = get_pathspec(prefix, argv + 2);
 	buf = read_object_with_reference(sha1, "tree", &size, NULL);
 	if (!buf)
 		die("not a tree object");
-	read_tree_recursive(buf, size, "", 0, 0, path, show_tree);
+	read_tree_recursive(buf, size, "", 0, 0, pathspec, show_tree);
 
 	return 0;
 }

Re: [PATCH 6/8] ls-tree: work from subdirectory.

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> BTW! It fails a few of the tests, but it does so because now, with "-r", 
> it will never show the tree entries, and because of the difference between
>
> 	git-ls-tree $tree path
>
> and
>
> 	git-ls-tree $tree path/
>
> that it didn't use to have (oh, and if you give multiple paths, it will 
> now always consider them a "union pathspec", not an "iteration of paths"). 
> But I _think_ the new behaviour is pretty useful and while not the same as 
> "ls", it's perhaps still intuitive enough..

The difference between path and path/ is very cute ;-).  I do
not do Porcelain myself, so I am OK with this change, but this
would involve some changes to the Porcelain.

So let's cook this for a while and have Porcelain people holler
if they find something lacking.  I'll put this in the proposed
updates tonight, and we will plan to push everything in the
proposed updates branch to the master branch on Wednesday, with
any fixes and updates necessary.

Re: [PATCH 6/8] ls-tree: work from subdirectory.

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> So let's cook this for a while and have Porcelain people holler
> if they find something lacking.  I'll put this in the proposed
> updates tonight, and we will plan to push everything in the
> proposed updates branch to the master branch on Wednesday, with
> any fixes and updates necessary.

OK, so I did some tests adjustments (they are in "pu").  Most
differences are easily explained but some are not.

Easy ones:

    - With -r, tree entries are not shown.

    - Unlike /bin/ls arguments, the paths are now filters, so
      no duplicates on the output, nor the output order does not
      depend on command line argument order.

    - "path" shows the tree if path corresponds to a directory;
      say "path/" to get its contents.

However I do not have an easy way to explain how these two work
the way they do.  Taken from t/t3101 test.

The first one has both path0/a/b/c and path0/a in the filter,
and path0/a tree entry itself is not shown because it "recurses
through it".

+# I am not so sure about this one after ls-tree doing pathspec match.
+# Having both path0/a and path0/a/b/c makes path0/a redundant, and
+# it behaves as if path0/a/b/c, path1/b/c, path2 and path3 are specified.
 test_expect_success \
     'ls-tree filter directories' \
     'git-ls-tree $tree path3 path2 path0/a/b/c path1/b/c path0/a >current &&
      cat >expected <<\EOF &&
-040000 tree X	path3
-100644 blob X	path3/1.txt
-100644 blob X	path3/2.txt
-040000 tree X	path2
-100644 blob X	path2/1.txt
 040000 tree X	path0/a/b/c
-100644 blob X	path0/a/b/c/1.txt
 040000 tree X	path1/b/c
-100644 blob X	path1/b/c/1.txt
-040000 tree X	path0/a
-040000 tree X	path0/a/b
+040000 tree X	path2
+040000 tree X	path3
 EOF
      test_output'

The second one is the same; since there is path3/, it recurses
through it and path3 itself is not shown but its contents are.
It is showing both path3/1.txt and path3/2.txt not because
path3/1.txt is specified but path3/ was specified.

+# Again, duplicates are filtered away so this is equivalent to
+# having 1.txt and path3/
 test_expect_success \
     'ls-tree filter odd names' \
     'git-ls-tree $tree 1.txt /1.txt //1.txt path3/1.txt /path3/1.txt //path3//1.txt path3 /path3/ path3// >current &&
      cat >expected <<\EOF &&
 100644 blob X	1.txt
-100644 blob X	1.txt
-100644 blob X	1.txt
-100644 blob X	path3/1.txt
-100644 blob X	path3/1.txt
-100644 blob X	path3/1.txt
-040000 tree X	path3
-100644 blob X	path3/1.txt
-100644 blob X	path3/2.txt
-040000 tree X	path3
-100644 blob X	path3/1.txt
-100644 blob X	path3/2.txt
-040000 tree X	path3
 100644 blob X	path3/1.txt
 100644 blob X	path3/2.txt
 EOF

[PATCH] ls-tree: Resurrect funny name quoting lost during rewrite.

[Junio C Hamano]

The rewrite to match ls-files/diff-tree behaviour accidentally
lost the name quoting.  I am not proud about this code, but this
would get the test going.

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

---

 ls-tree.c |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

applies-to: 4db95789ce3af40091ead2a97a72e75f9a0b8384
e7cdcbbbbd2fd2848244f998a0b92338fc68fe78
diff --git a/ls-tree.c b/ls-tree.c
index 4df5830..df3bcec 100644
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -48,7 +48,15 @@ static int show_tree(unsigned char *sha1
 		type = "tree";
 	}
 
-	printf("%06o %s %s\t%.*s%s%c", mode, type, sha1_to_hex(sha1), baselen, base, pathname, line_termination);
+	printf("%06o %s %s\t", mode, type, sha1_to_hex(sha1));
+	if (1) {
+		/* NEEDSWORK: */
+		char base_[baselen + 1];
+		memcpy(base_, base, baselen);
+		base_[baselen] = 0;
+		write_name_quoted(base_, pathname, line_termination, stdout);
+	}
+	putchar(line_termination);
 	return 0;
 }
 
---
0.99.9.GIT