On Thu, 11 May 2006, Martin Langhoff wrote:
>
> 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
> 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
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html