On Thu, 11 May 2006, Martin Langhoff wrote:

quoted text
>

> Apologies -- I didn't want to know it, but I do wonder what the gain

> behind the change is.

I think we can do better in a few pretty important regards:
 - having the information in one place. I agree that the multi-file

   approach works fine for shell scripts (although I disagree that the new

   one would be harder - you just use git-repo-config instead), but I

   think it's quite confusing from a new user perspective.
   I bet that even without any tools, new users can be told to just open

   ".git/config", and guess how hard a time they would have to add a new

   branch, if they already had one that said
	[branch "origin"]

		remote = git://git.kernel.org/pub/scm/git/git.git

		branch master
   which would tell you that the local branch "origin" is really branch

   "master" at that remote git repository.
   Yeah, I'm not sure what the actual config rules would be, but think it

   would be a hell of a lot more intuitive than what we have now. 
   What we have now _works_. It works really well. No question about that.

   It's just pretty hard to explain. The above syntax wouldn't even need

   any explanation. You could just tell people to look into their config

   files.
 - I think we'll have a much easier time (from a purely technical angle)

   to add special attributes to the local branches. Add a "read-only"

   specifier? It's _obvious_:
	[branch "origin"]

		remote = git://git.kernel.org/pub/scm/git/git.git

		branch master

		readonly
   and it's absolutely trivial to parse. And part of the important thing

   is that this all makes 100% sense EVEN IF IT'S NOT A REMOTE REPO!
   So imagine that it's a purely local branch, but you want to protect it.

   Solution?
	[branch "July Snapshot"]

		readonly
   and you're done. In contrast, even if you ended up just extending the

   file format for the .git/remotes/July\ Snapshot file, and just added a

   "readonly" line to it, it wouldn't make _sense_. Whaa? "remotes"? In

   contrast, in the .git/config file, it makes a ton of sense, and in fact

   it's totally obvious.
   (Actually, we should probably have the .git/config file syntax separate

   local branches like "master" from remote branches like "origin", so it

   might be more like
	[remote "origin"]

		url = git://git.kernel.org/pub/scm/git/git.git
    which just tells that the _word_ "origin" corresponds to a

    shorthand for a particular remote repository
	[branch "origin"]

		remote = origin

		branch = master
   or something to show that your _local_ branch named "origin"

   corresponds to a particular remote (which could be a shorthand like the

   above, or just spelled out), and a particular branch _at_ that remote

   repository)
   Anyway, the point is, I think our current .git/remotes/xyzzy files

   actually mix two different concepts, and they also end up doing it

   pretty badly. They _work_, but because of the mix-ups, they aren't all

   that they could be, and it's fundamentally impossible to make them so,

   because the mixup really is that "origin" means TWO DIFFERENT THINGS

   (the local branch, and the remote that it corresponds to)
 - Finally, I think it opens the possibility for some other things. For

   example, once you accept that different branches might want attributes

   like "readonly", you realize that some other attributes also make

   sense. Like adding the default pull source per local branch, etc.
Again, I'm not saying that we can't work with the .git/remotes/ files. But

I think it gets increasingly ugly, and the confusion gets increasingly

worse.
> But it is a bit of a loss for perl/shell porcelains, and for users

quoted text
> that abuse the contents of .git directly on a regular basis...

I really disagree. 
The .git/config file is _easier_ to edit by hand than the remotes. It's

easier to copy-paste within one file than it is to work with two different

files (and let's face it, copy-paste is usually what at least I would do

for something like this). And it's _easier_ to just always open one file,

and search within that one, than try to remember what file it was.
Now, C programs can very easily use the config library, and shell programs

can equally easily query the variables with "git repo-config". I really

doubt it's very hard for perl either, but I'm not a perl person, so maybe

I don't see why this is hard.
		Linus

-

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