[RFC 1/2] Use remote information in .git/config

[RFC 1/2] Use remote information in .git/config

[Johannes Schindelin]

This patch allows to store shortcuts for fetch/pull into the config:

	[remote.junio]
		url = http://www.kernel.org/pub/scm/git/git.git
		pull = master:junio
		pull = todo:todo
		pull = +pu:pu

Note that there is only one pair per "pull" line, to allow for spaces
(urgh!) in the branch names.

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

---

	The different pull/push lines are identified by their branch name. 
	So, to update the pull line for "todo" to force fast forward, do

		git-config-set remote.junio.pull +todo:todo '^todo:'

 git-parse-remote.sh |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

applies-to: 25c461c5c50b9d8c6cd836ca6a9df12f03f29621
b0542d077b7bf6ee8b45854e47dcba73170c1e9a
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index aea7b0e..cd976da 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -22,6 +22,9 @@ get_data_source () {
 		elif test -f "$GIT_DIR/branches/$1"
 		then
 			echo branches
+		elif test "$(git-config-set --get remote.$1.url)"
+		then
+			echo config
 		else
 			echo ''
 		fi ;;
@@ -46,6 +49,9 @@ get_remote_url () {
 		url=$(sed -e 's/#.*//' "$GIT_DIR/branches/$token")
 		echo "$url/$remainder"
 		;;
+	config)
+		git-config-set --get remote.$1.url
+		;;
 	*)
 		die "internal error: get-remote-url $1" ;;
 	esac
@@ -60,6 +66,8 @@ get_remote_default_refs_for_push () {
 		sed -ne '/^Push: */{
 			s///p
 		}' "$GIT_DIR/remotes/$1" ;;
+	config)
+		git-config-set --get-all remote.$1.push ;;
 	*)
 		die "internal error: get-remote-default-ref-for-push $1" ;;
 	esac
@@ -124,6 +132,8 @@ get_remote_default_refs_for_fetch () {
 						s///p
 					}' "$GIT_DIR/remotes/$1")
 		;;
+	config)
+		git-config-set --get-all remote.$1.pull ;;
 	*)
 		die "internal error: get-remote-default-ref-for-push $1" ;;
 	esac
---
0.99.9.GIT

Re: [RFC 1/2] Use remote information in .git/config

[Junio C Hamano]

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

> This patch allows to store shortcuts for fetch/pull into the config:
>
> 	[remote.junio]
> 		url = http://www.kernel.org/pub/scm/git/git.git
> 		pull = master:junio
> 		pull = todo:todo
> 		pull = +pu:pu
>
> Note that there is only one pair per "pull" line, to allow for spaces
> (urgh!) in the branch names.

I think "allow for spaces" nonsense can be removed by now.  I
did it initially that way before making the ref name validation
tighter with check-ref-format.  And if I understand what you
wrote about multivalues correctly, your intent is that "orders
do not matter"; with pull refspecs, orders do matter, so it
probably is a good idea to allow only a single line.

Personally I do not mind moving remotes/branches information
there, except that I suspect the git-config-set interface makes
it cumbersome to (1) find out what remotes I defined (i.e. an
equivalent of "ls .git/remotes") and (2) remove a single remote
when I do not want it anymore (--unset-all would remove the keys
but would leave the empty section).

I am unsure if putting everything in .git/config file is the
right approach, though.  What will we put there next?  ls-files
ignore patterns?  grafts?  alternates?  We should be able to
even get rid of .git/refs directory hierarchy and replace that
with something like this:

	[refs]
        	head = ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234	for master
        	head = ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234	for pu
		tag = ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234 for v1.0rc1
	...

Where will we stop, and why?

I am worried about people later asking "why do we have X in
config but not Y"?

Re: [RFC 1/2] Use remote information in .git/config

[Johannes Schindelin]

Hi,

On Mon, 21 Nov 2005, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > Note that there is only one pair per "pull" line, to allow for spaces
> > (urgh!) in the branch names.
> 
> I think "allow for spaces" nonsense can be removed by now.  I
> did it initially that way before making the ref name validation
> tighter with check-ref-format.  And if I understand what you
> wrote about multivalues correctly, your intent is that "orders
> do not matter"; with pull refspecs, orders do matter, so it
> probably is a good idea to allow only a single line.

Okay. (I also wondered how git-config-set could be used to replace the 
first pair, which is what gets merged when pulling).

> Personally I do not mind moving remotes/branches information
> there, except that I suspect the git-config-set interface makes
> it cumbersome to (1) find out what remotes I defined (i.e. an
> equivalent of "ls .git/remotes") and (2) remove a single remote
> when I do not want it anymore (--unset-all would remove the keys
> but would leave the empty section).

(1) git-var -l | grep '^remote\.'

(2) I would add --remove-section for that. (Though I'll wait to implement 
that until I know if people want it.)

> I am unsure if putting everything in .git/config file is the
> right approach, though.  What will we put there next?  ls-files
> ignore patterns?  grafts?  alternates?  We should be able to
> even get rid of .git/refs directory hierarchy and replace that
> with something like this:
> 
> 	[refs]
>         	head = ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234	for master
>         	head = ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234	for pu
> 		tag = ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234 for v1.0rc1
> 	...
> 
> Where will we stop, and why?

Ahh! I have a clear picture of what *I* would put into it: all interesting 
static data about that particular repository which I would not like to 
version.

For that matter, .gitignore would stay where it is, though I'd also like 
to version grafts, i.e. move the location from .git/info/grafts to 
.gitgrafts (which would effectively end another thread on this list).

I would not like to version refs, evidently, or alternates. But the refs 
would not be static (they *want* to change often), while the alterates 
would be.

But I will not be a bugger about it. If things stay where they are 
(including .git/remotes), I will not be sad. There was just this crazy 
idea in my head (not the tip of the development branch, but the object my 
eyes are in), and I wanted to discuss it with you guys, just in case...

Ciao,
Dscho

Re: [RFC 1/2] Use remote information in .git/config

[Junio C Hamano]

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

>> I am unsure if putting everything in .git/config file is the
>> right approach, though.  What will we put there next?  ls-files
>> ignore patterns?  grafts?  alternates?  We should be able to
>> even get rid of .git/refs directory hierarchy and replace that
>> with something like this:
>> ...
>> Where will we stop, and why?
>
> Ahh! I have a clear picture of what *I* would put into it: all interesting 
> static data about that particular repository which I would not like to 
> version.

There are certain things that _might_ benefit from the third
kind we currently do not support: developer opt-in.

Currently, .gitignore and friends (what you call versioned) are
project-wide.  Anybody who follows git.git uses _the_ .gitignore
that is from the respository, although they can override with
their own .git/info/exclude, which might be a good candidate for
"core.gitignore = ...".  But certain people might want to share
their forked .gitignore without going through hassles to
integrate that to project-wide copy.  ".gitignore" might be a
bad example, and grafts may be better.  People interested in
Linux archaeology might want to share grafts to let them go back
from tip of 2.6 all the way down to 2.4.0 (or before) while
majority of users do not share that interest.

Obviously, user.name is private to you, but you would still want
to use the same across your repositories.

Once we start thinking about allowing the template mechansim to
give default "config" information to newly created repositories,
having everything in one file may make things a bit awkward to
handle.  When you managed to make your colleage interested in
git development, you can let her copy your remotes/junio.  Once
you moved remotes/ to .git/config file, while you would not want
her to use copy of your .git/config verbatim without updating at
least user.name, you would want to have her use other pieces in
the .git/config, including [remote.jnio] bits.

The following comments are not about your patch but I am having
a feeling that we ended up having too much flexibility.  It may
not necessarily be a bad thing when we view git as pure
plumbing, but it makes things confusing to have too many "you
could do it this way if you want to gain XXX, as long as you are
careful about YYY".

For example, we do not define how checked-out tree, repository
and object database _should_ work together.  The officially
recommended way is to have one object database at .git/objects/,
possibly borrowing from somebody via objects/info/alternates,
which hangs under one repository (.git), and the repository can
have one checked-out tree associated with it.

However, it is possible to symlink .git/objects to somewhere
else, to share an object database between two repositories, as
long as you are careful when pruning (you can lose objects the
refs in other repository points at but you do not).

Even worse (or better), you could symlink everything except the
HEAD and index file to somewhere else to have one repository
with multiple checked-out trees (I believe Daniel does this), as
long as you are careful when pulling/fetching (fetching into a
branch that another working tree has checked out will move the
head commit there without updating the index).

Another example is the assumption we place on completeness of
the refs.  We pretty much declares that if there are some
objects you cannot reach starting from your refs, your
repository is corrupt (incomplete). But such an incomplete
repository can be useful in certain situations, and some things
work properly but not others.  I think using commit-walkers
without -a option can easily create such an incomplete
repository.

The recent "should commit be always utf-8" thread probably falls
into this category.  We all know things should be in utf-8, but
other things are possible as long as people understand
boundaries.

Most of the time, what we recommend are the BCP, but
knowledgeable users can deviate from that, to gain some
advantage (e.g. reduced disk space using an incomplete
repository, convenience of having more than one checked-out
trees at the same time, not having to migrate to all UTF-8
system) over the BCP if they are willing to sacrifice something
else or their use pattern is not affected negatively by what
they are losing (e.g. can live without an access to ancient
history, be very careful when pruning and fetching, do not have
people whose names cannot be spelled in KOI-8).

Re: [RFC 1/2] Use remote information in .git/config

[Johannes Schindelin]

Hi,

On Mon, 21 Nov 2005, Junio C Hamano wrote:

> Once we start thinking about allowing the template mechansim to
> give default "config" information to newly created repositories,
> having everything in one file may make things a bit awkward to
> handle.  When you managed to make your colleage interested in
> git development, you can let her copy your remotes/junio.  Once
> you moved remotes/ to .git/config file, while you would not want
> her to use copy of your .git/config verbatim without updating at
> least user.name, you would want to have her use other pieces in
> the .git/config, including [remote.jnio] bits.

Well, obviously I would patch git-fetch/-pull/-push to have an option 
("--store") to store the current parameters under a certain nick name in 
the config ;-)

Or add a little option (which is easy) to generate commands which can be 
piped into a little script (think "xmodmap -pke").

> The following comments are not about your patch but I am having
> a feeling that we ended up having too much flexibility.  It may
> not necessarily be a bad thing when we view git as pure
> plumbing, but it makes things confusing to have too many "you
> could do it this way if you want to gain XXX, as long as you are
> careful about YYY".

I wouldn't be so sad about the flexibility. It is an open source project, 
and the strength therein lies in many people having many (yes, even 
stupid) ideas, and trying to get them in. In the long run, the dumb ideas 
are thrown out, but what remains is a collection of gems.

So, it might be confusing for a noobee, but that's what we have 
Documentation/tutorial for.

> Most of the time, what we recommend are the BCP, but
> knowledgeable users can deviate from that, to gain some
> advantage (e.g. reduced disk space using an incomplete
> repository, convenience of having more than one checked-out
> trees at the same time, not having to migrate to all UTF-8
> system) over the BCP if they are willing to sacrifice something
> else or their use pattern is not affected negatively by what
> they are losing (e.g. can live without an access to ancient
> history, be very careful when pruning and fetching, do not have
> people whose names cannot be spelled in KOI-8).

'xactly. For example, I can do

	ln -s .gitgrafts .git/info/grafts

and have the effect that Linus just called "nasty". Point is, if I choose 
to do so, I can. Easily.

Ciao,
Dscho

Re: [RFC 1/2] Use remote information in .git/config

[Ben Clifford]

On 22 Nov 2005, at 05:29, Junio C Hamano wrote:

>
> Personally I do not mind moving remotes/branches information
> there, except that I suspect the git-config-set interface makes
> it cumbersome to (1) find out what remotes I defined (i.e. an
> equivalent of "ls .git/remotes")

(1) is useful to be able to do in a very lightweight way when doing  
tab completion on remotes. Having heads, tags, remotes in nicely  
named separate files makes that pretty straightforward; I don't know  
if using a git-config- accessor would make this noticeably worse,  
though, as I haven't tried anything out there yet.

-- 
Ben • ベン • Бэн • 벤 • 班明
http://www.hawaga.org.uk/ben/
My email is high latency but best way to contact me. Alternatively,  
SMS number(s) at above URL.

Re: [RFC 1/2] Use remote information in .git/config

[Johannes Schindelin]

Hi,

On Fri, 25 Nov 2005, Ben Clifford wrote:

> On 22 Nov 2005, at 05:29, Junio C Hamano wrote:
> 
> > Personally I do not mind moving remotes/branches information
> > there, except that I suspect the git-config-set interface makes
> > it cumbersome to (1) find out what remotes I defined (i.e. an
> > equivalent of "ls .git/remotes")
> 
> (1) is useful to be able to do in a very lightweight way when doing tab
> completion on remotes. Having heads, tags, remotes in nicely named separate
> files makes that pretty straightforward; I don't know if using a git-config-
> accessor would make this noticeably worse, though, as I haven't tried anything
> out there yet.

	 git-var -l | sed -n "s/^remote\.\([A-Za-z0-9]*\)\.url=.*$/\1/p"

Hth,
Dscho

Re: [RFC 1/2] Use remote information in .git/config

[Petr Baudis]

Dear diary, on Fri, Nov 25, 2005 at 02:08:46AM CET, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Fri, 25 Nov 2005, Ben Clifford wrote:
> 
> > On 22 Nov 2005, at 05:29, Junio C Hamano wrote:
> > 
> > > Personally I do not mind moving remotes/branches information
> > > there, except that I suspect the git-config-set interface makes
> > > it cumbersome to (1) find out what remotes I defined (i.e. an
> > > equivalent of "ls .git/remotes")
> > 
> > (1) is useful to be able to do in a very lightweight way when doing tab
> > completion on remotes. Having heads, tags, remotes in nicely named separate
> > files makes that pretty straightforward; I don't know if using a git-config-
> > accessor would make this noticeably worse, though, as I haven't tried anything
> > out there yet.
> 
> 	 git-var -l | sed -n "s/^remote\.\([A-Za-z0-9]*\)\.url=.*$/\1/p"

All right, I've asked about this functionality in the other thread, and
something like this seems to cut it (although I would just /\([^.=]*\)/
instead of restricting the remote name).

However, it's a nice example of horrible interface. And confusing one
at it, too.

Why git-var -l?! That makes no sense to me. git-var's function is to
"print the git users identity" (no matter that it is grammatically
wrong, that's what the synopsis says). This is something totally else,
and I can't see what bussiness does this have in the git-var command.
This should belong into git-repo-config, which manages the rest of the
config-related stuff.

C'mon people, git's interface is inconsistent enough as it is now,
no need to make it even worse. ;-)

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