* Re: Unresolved issues #2 (shallow clone again)
From: Martin Langhoff @ 2006-05-07 23:27 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: Junio C Hamano, git
In-Reply-To: <20060507120149.40e9f749.vsu@altlinux.ru>
On 5/7/06, Sergey Vlasov <vsu@altlinux.ru> wrote:
> For linux v2.6.16:
>
> 7,3M commits-b41b04a36afebdba3b70b74f419fc7d97249bd7f.pack
> 24M commits_trees-8397f1c2a885527acd07e2caa8c95df626451493.pack
> 97M full-c7b2747a674ff55cb4a59dabebe419f191e360df.pack
With this pack arrangement, do you get any noticeable difference in
walking commits? How about walking commits+trees with git-log <path> ?
I wonder whether segregating packs by object type would make things better...
cheers,
martin
^ permalink raw reply
* Re: Unresolved issues #2 (shallow clone again)
From: Junio C Hamano @ 2006-05-07 23:35 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90605071627i6a335f61lf5e35291bfbe340c@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> On 5/7/06, Sergey Vlasov <vsu@altlinux.ru> wrote:
>> For linux v2.6.16:
>>
>> 7,3M commits-b41b04a36afebdba3b70b74f419fc7d97249bd7f.pack
>> 24M commits_trees-8397f1c2a885527acd07e2caa8c95df626451493.pack
>> 97M full-c7b2747a674ff55cb4a59dabebe419f191e360df.pack
>
> With this pack arrangement, do you get any noticeable difference in
> walking commits? How about walking commits+trees with git-log <path> ?
>
> I wonder whether segregating packs by object type would make things better...
It shouldn't. The existing packfile is designed to make "git
log" very efficient, by making it cheap to look only at the
commit message and ancestry information.
The objects are sorted first by type in the pack with the
existing code already, and commits come first. Try this.
git repack -a -d
git show-index <.git/objects/pack/pack-*.idx |
sort -n |
while read offset objectname
do
git cat-file -t "$objectname"
done
^ permalink raw reply
* Re: [PATCH] Release config lock if the regex is invalid
From: Junio C Hamano @ 2006-05-07 23:37 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <20060507213612.27887.28600.stgit@dv.roinet.com>
Thanks.
^ permalink raw reply
* Re: Unresolved issues #2 (shallow clone again)
From: Martin Langhoff @ 2006-05-07 23:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vveshif1i.fsf@assigned-by-dhcp.cox.net>
On 5/8/06, Junio C Hamano <junkio@cox.net> wrote:
> It shouldn't. The existing packfile is designed to make "git
> log" very efficient, by making it cheap to look only at the
> commit message and ancestry information.
>
> The objects are sorted first by type in the pack with the
> existing code already, and commits come first. Try this.
Thanks for the explanation! My ignorance in the pre-coffee stage of
Monday is... exemplary. I should know better than assume that there
are trivial optimizations for git that I can come up with ;-)
I guess I should get more into the pack stuff and educate myself --
everyone's having fun with it... grumble, will have to brush up my C
to get to play.
cheers,
martin
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Linus Torvalds @ 2006-05-08 0:05 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1147037659.25090.25.camel@dv>
On Sun, 7 May 2006, Pavel Roskin wrote:
>
> I think a good implementation should allow any characters in the keys,
> even "=", because the key can be quoted. Section names may disallow
> square brackets and dots.
That wouldn't help. The thing is designed to not only need no quoting
(except for the _value_), it also is designed to have both section and key
names ignore case. So you really aren't supposed to put things like branch
names (which are potentially case-sensitive, depending on filesystem) in
either.
And we depend on that (and I think it's important - users normally should
_not_ care about capitalization)
So you'd need to literally create a different syntax if you want unquoted
section naming.
> Such limitations make it unpractical to use branch names in section or
> key names. I'd like to have it fixed.
Here's a possible syntax/patch. I actually think the quoting makes more
sense in the section name, since you'll usually want several keys under
each branch, so it makes sense to make the _branch_ be the section.
It basically makes it a special case if you have the section name be
marked with quotes, like
["XyZZy"]
and in that case it turns the _real_ section name into the string
"branch.XyZZy", where the important part is that it does this without
changing case or limiting the character set (but it will _not_ allow a
newline) in any way.
So you could have something like
["Origin"]
URL = ...
fetch = master
and it would just turn it into
branch.Origin.url = ...
branch.Origin.fetch = master
etc.
No, I'm not sure this is the best possible syntax. It's just a suggestion.
And it's certainly simple enough.
The downside is that if you start using config files like this, you
literally can't go back to older git versions. They'll refuse to touch
such a config file (rather than just ignoring the new entries) and will
exit with nasty messages. That might be unacceptable.
Instead of quoting with double-quotes, it might be ok to use some
alternate syntax line "[:$branchname:]" which looks visually reasonable,
and has the potential advantage that ':' is already an invalid character
in a branch name, so you don't actually even need any quoting logic at all
at that point.
I think the
["branch"]
...
syntax looks reasonably readable and clean.
Linus
----
diff --git a/config.c b/config.c
index 41066e4..802e326 100644
--- a/config.c
+++ b/config.c
@@ -134,9 +134,44 @@ static int get_value(config_fn_t fn, cha
return fn(name, value);
}
+static int get_branch_name(char *name)
+{
+ int baselen = 7;
+ int quote = 0;
+
+ memcpy(name, "branch.", 7);
+ for (;;) {
+ int c = get_next_char();
+ if (c == EOF)
+ return -1;
+ if (c == '\n')
+ return -1;
+ if (!quote) {
+ if (c == '"')
+ break;
+ if (c == ']')
+ return -1;
+ if (c == '\\') {
+ quote = 1;
+ continue;
+ }
+ }
+ name[baselen++] = c;
+ if (baselen > MAXNAME / 2)
+ return -1;
+ }
+ if (get_next_char() != ']')
+ return -1;
+ return baselen;
+}
+
static int get_base_var(char *name)
{
int baselen = 0;
+ int c = get_next_char();
+
+ if (c == '"')
+ return get_branch_name(name);
for (;;) {
int c = get_next_char();
^ permalink raw reply related
* Re: Implementing branch attributes in git config
From: Linus Torvalds @ 2006-05-08 0:18 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605071629080.3718@g5.osdl.org>
On Sun, 7 May 2006, Linus Torvalds wrote:
>
> And it's certainly simple enough.
Well, simple enough to be buggy.
> static int get_base_var(char *name)
> {
> int baselen = 0;
> + int c = get_next_char();
> +
> + if (c == '"')
> + return get_branch_name(name);
>
> for (;;) {
> int c = get_next_char();
You also need to move the "int c = get_next_char()" in the for() loop down
to the end of the loop (removing the "int", of course).
So here's the fixed thing in case people care (and this time I actually
looked at whether it might even work, not just compile ;)
Linus
---
diff --git a/config.c b/config.c
index 41066e4..69d451a 100644
--- a/config.c
+++ b/config.c
@@ -134,12 +134,46 @@ static int get_value(config_fn_t fn, cha
return fn(name, value);
}
+static int get_branch_name(char *name)
+{
+ int baselen = 7;
+ int quote = 0;
+
+ memcpy(name, "branch.", 7);
+ for (;;) {
+ int c = get_next_char();
+ if (c == EOF)
+ return -1;
+ if (c == '\n')
+ return -1;
+ if (!quote) {
+ if (c == '"')
+ break;
+ if (c == ']')
+ return -1;
+ if (c == '\\') {
+ quote = 1;
+ continue;
+ }
+ }
+ name[baselen++] = c;
+ if (baselen > MAXNAME / 2)
+ return -1;
+ }
+ if (get_next_char() != ']')
+ return -1;
+ return baselen;
+}
+
static int get_base_var(char *name)
{
int baselen = 0;
+ int c = get_next_char();
+
+ if (c == '"')
+ return get_branch_name(name);
for (;;) {
- int c = get_next_char();
if (c == EOF)
return -1;
if (c == ']')
@@ -149,6 +183,7 @@ static int get_base_var(char *name)
if (baselen > MAXNAME / 2)
return -1;
name[baselen++] = tolower(c);
+ c = get_next_char();
}
}
^ permalink raw reply related
* Re: Implementing branch attributes in git config
From: Linus Torvalds @ 2006-05-08 0:25 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605071629080.3718@g5.osdl.org>
On Sun, 7 May 2006, Linus Torvalds wrote:
>
> The downside is that if you start using config files like this, you
> literally can't go back to older git versions. They'll refuse to touch
> such a config file (rather than just ignoring the new entries) and will
> exit with nasty messages. That might be unacceptable.
Side note: with this syntax, the _users_ will all just basically do
if (!strncmp(name, "branch.", 7)) {
branch = name + 7;
dot = strchr(branch, '.');
if (!dot)
return -1;
*dot++ = 0;
.. we now have the branchname in "branc",
and the rest in "dot" ..
and if your branch names are purely alphabetical and lower-case, you can
now write
[branch.origin]
remote = true
url = git://git.kernel.org/...
fetch = master
[branch.master]
pull = origin
and it will be parsed _exactly_ the same as
["origin"]
remote = true
url = git://git.kernel.org/...
fetch = master
["master"]
pull = origin
while the [branch.origin] syntax allows old versions of git to happily
ignore it. So that would be a kind of cheesy work-around: the new
double-quoted format is only _required_ for any branch-names that have
special characters in it.
Linus
^ permalink raw reply
* Re: [PATCH] Release config lock if the regex is invalid
From: Johannes Schindelin @ 2006-05-08 0:32 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <20060507213612.27887.28600.stgit@dv.roinet.com>
Hi,
On Sun, 7 May 2006, Pavel Roskin wrote:
> @@ -516,6 +516,8 @@ int git_config_set_multivar(const char*
> fprintf(stderr, "Invalid pattern: %s\n",
> value_regex);
> free(store.value_regex);
> + close(fd);
> + unlink(lock_file);
> ret = 6;
> goto out_free;
> }
>
This is not enough. There are quite a few exit paths. Notice the "goto
out_free"? That is where this must go.
This patch is totally untested but obviously correct:
diff --git a/config.c b/config.c
index 30effe3..d8fd94d 100644
--- a/config.c
+++ b/config.c
@@ -445,7 +445,7 @@ int git_config_set_multivar(const char*
const char* value_regex, int multi_replace)
{
int i;
- int fd;
+ int fd = -1;
int ret;
char* config_filename = strdup(git_path("config"));
char* lock_file = strdup(git_path("config.lock"));
@@ -619,10 +619,14 @@ int git_config_set_multivar(const char*
ret = 0;
out_free:
+ if (fd > 0)
+ close(fd);
if (config_filename)
free(config_filename);
- if (lock_file)
+ if (lock_file) {
+ unlink(lock_file);
free(lock_file);
+ }
return ret;
}
^ permalink raw reply related
* Re: Unresolved issues #2 (shallow clone again)
From: Theodore Tso @ 2006-05-08 0:33 UTC (permalink / raw)
To: git
In-Reply-To: <20060507075631.GA24423@coredump.intra.peff.net>
On Sun, May 07, 2006 at 03:56:31AM -0400, Jeff King wrote:
> On Sun, May 07, 2006 at 06:08:03PM +1200, Martin Langhoff wrote:
>
> > >> And in any case commits and trees are lightweight and compress well...
> > >Commit maybe, but is this based on a hard fact?
> > No hard facts here :( but I think it's reasonable to assume that the
> > trees delta/compress reasonably well, as a given commit will change
> > just a few entries in each tree.
>
> A few hard facts (using Linus' linux-2.6 tree):
> - original packsize: 120996 kilobytes
> - unpacked: 233338 objects, 1417476 kilobytes
> This is an 11.7:1 compression ratio (of course, much of this is
> wasted space from the 4k block size in the filesystem)
If there are 233338 objects, then the average wasted space due to
internal fragmentation is 233338 * 2k, or 466676 kilobytes, or only
36% of the wasted space. Most of the savings is probably coming from
the compression and delta packing.
- Ted
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Pavel Roskin @ 2006-05-08 0:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605071629080.3718@g5.osdl.org>
Hello, Linus!
On Sun, 2006-05-07 at 17:05 -0700, Linus Torvalds wrote:
> The downside is that if you start using config files like this, you
> literally can't go back to older git versions. They'll refuse to touch
> such a config file (rather than just ignoring the new entries) and will
> exit with nasty messages. That might be unacceptable.
You code faster that I write e-mails :-)
I like your approach, even though it breaks compatibility. I understand
we are going to more .git/remotes to the config, so compatibility will
be broken anyways.
I'm only concerned that we would be hardcoding the word "branch". We
could need fancy section names for other things in the future.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: sean @ 2006-05-08 0:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: proski, git
In-Reply-To: <Pine.LNX.4.64.0605071629080.3718@g5.osdl.org>
On Sun, 7 May 2006 17:05:26 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:
> So you could have something like
>
> ["Origin"]
> URL = ...
> fetch = master
>
> and it would just turn it into
>
> branch.Origin.url = ...
> branch.Origin.fetch = master
>
Having magic sections that prepend "branch." seems a bit suspect;
why not just be explicit:
[branch.Origin]
URL = ...
fetch = master
Wouldn't it be reasonable for git to impose modest restrictions on
branch names; such as restricting them to [a-zA-Z0-9] characters?
Then we just have to make section names case sensitve within the
config file; keys could still be case insensitive.
Actually it would be nice if we were consistent. If case matters to
git then the config file should be case sensitive. If case doesn't
matter to git, then it should consider "Branch", "branch" and "BrAnCh"
as the same in all contexts (eg. git branch -b BrAnCh). It seems
silly for us to say people are too dumb to handle case sensitivity
in a config file, but it's perfectly acceptable everywhere else.
Sean
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Johannes Schindelin @ 2006-05-08 0:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pavel Roskin, git
In-Reply-To: <7v4q01jwwg.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 7 May 2006, Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
>
> > In particular, git-repo-config leaves the config file locked in the
> > regex is wrong:
> >
> > $ git-repo-config branch.fetch "master:origin" +
> > Invalid pattern: +
> > $ git-repo-config branch.fetch "master:origin" +
> > could not lock config file
> >
> > To fix it, just add "close(fd); unlink(lock_file);" after "Invalid
> > pattern" in config.c.
>
> I'd give Johannes the first refusal right to deal with this and
> not touch repo-config.c myself for now, since I suspect I
> tempted him enough to restructure it ;-).
Thanks. Yes, you tempted me real hard :-) Unfortunately, the restructuring
will have to wait a little, because I really should work for my day job
these days... :-(
> > I don't quite understand what pattern is needed to add an entry. "foo"
> > seems to work fine, I don't know why.
>
> I think the value regexp is "replace the ones that match this",
> and the convention he came up with is to use "^$" to append (see
> some examples in t/t1300-repo-config.sh).
>
> In any case, Documentation/git-repo-config.txt mentions
> value_regex without explaining what the semantics is. This
> needs to be fixed, probably like the attached patch.
>
> > That problem with multiple values is that they are quite fragile and
> > require special options to access them. Since regex is used, dots in
> > the branch names need to be escaped. Probably more escapes are needed.
>
> I have a suspicion that using regex while is more powerful and
> expressive might be a mistake and it would be easier for users
> (both Porcelain and end-users) to use fnmatch() patterns.
I did not know about fnmatch()... It is probably better than regular
expressions. After all, what I use it for most often is
git-repo-config --get-all remote.*url
which -- magically -- will continue to work with fnmatch()!
> [branch]
> defaultremote = origin for master
> defaultremote = private for test
FWIW I like that syntax much better. But then, somebody called me weird
because of how I order the arguments of a comparison... tsk, tsk.
> @@ -23,10 +23,11 @@ You can query/set/replace/unset options
> actually the section and the key separated by a dot, and the value will be
> escaped.
>
> -If you want to set/unset an option which can occur on multiple lines, you
> -should provide a POSIX regex for the value. If you want to handle the lines
> -*not* matching the regex, just prepend a single exclamation mark in front
> -(see EXAMPLES).
> +If you want to set/unset an option which can occur on multiple
> +lines, a POSIX regexp `value_regex` needs to be given. Only the
> +existing values that match the regexp are updated or unset. If
> +you want to handle the lines that do *not* match the regex, just
> +prepend a single exclamation mark in front (see EXAMPLES).
I would actually prefer to go with your suggestion of using shell patterns
instead of regular expressions. They are not needed, and most users tend
to positively hate regular expressions.
Thoughts?
Ciao,
Dscho
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Linus Torvalds @ 2006-05-08 0:43 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1147048587.17371.13.camel@dv>
On Sun, 7 May 2006, Pavel Roskin wrote:
>
> I'm only concerned that we would be hardcoding the word "branch". We
> could need fancy section names for other things in the future.
Fair enough. We could have used some fake section name that you can't
generate any other way (in fact, "Branch.$branchname" would be that), but
the upside of using "branch" is exactly that you _can_ generate it with
the old-style syntax that is acceptable to older git versions too.
So the common case (all-lowercase, no special characters branch names)
wouldn't need to break.
Now, backwards competibility for the .git/config file isn't likely a huge
issue, but it does matter if you want to do things like "git bisect" to
bisect a totally unrelated bug, and part of the bisection is actually to
install the older git version that you're testing for the bug..
(Which is probably an insane thing to do anyway - you should be able to
test any bugs _without_ actually having to install the git version you're
testing. But whatever..)
Linus
^ permalink raw reply
* Re: Unresolved issues #2 (shallow clone again)
From: Linus Torvalds @ 2006-05-08 0:50 UTC (permalink / raw)
To: Theodore Tso; +Cc: git
In-Reply-To: <20060508003338.GB17138@thunk.org>
On Sun, 7 May 2006, Theodore Tso wrote:
>>
> If there are 233338 objects, then the average wasted space due to
> internal fragmentation is 233338 * 2k, or 466676 kilobytes, or only
> 36% of the wasted space.
That's not necessarily true.
That assumes a randomly distributed filesize. File sizes are _not_ random,
and in particular if you have the distribution leaning towards <2kB being
common, you can actually get >50% fragmentation.
Btw, I hit this when some people argued that the page size should be made
64kB. The above (incorrect) logic implies that you waste 32kB on average
per file. That's not true, if a large fraction of your files are small, in
which case you may actually be wastign closer to 60kB on average from
using a big page-size, because about half of the kernel files are actually
smaller than 4kB (or something. I forget the exact statistics, I did them
with a script at some point).
Anyway, with inode overhead and a lot of objects being just a couple of
hundred bytes, I think I estimated at some point that you actually lost
closer to 3kB per object.
Many of the objects actually end up being smaller than the inode they end
up allocating ;(
Linus
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Linus Torvalds @ 2006-05-08 0:55 UTC (permalink / raw)
To: sean; +Cc: proski, git
In-Reply-To: <BAYC1-PASMTP08D42DA222BA9843352CC1AEA80@CEZ.ICE>
On Sun, 7 May 2006, sean wrote:
>
> Having magic sections that prepend "branch." seems a bit suspect;
> why not just be explicit:
>
> [branch.Origin]
> URL = ...
> fetch = master
Exactly because section (and key) names are normally not case sensitive.
Even the documentation actually talks about "core.fileMode" and "[imap]
Folders".
Linus
^ permalink raw reply
* Software
From: Quadrilling E. Skiers @ 2006-05-08 14:03 UTC (permalink / raw)
To: Git
cheap oem soft shipping worldwide
P0pular software at low low price.
New software on our site:
Freehand MX 11 - $69.95
Office 2000 Premium Edition PE (2CD) - $59.95
Freehand MX 11 - $69.95
Visual Studio .NET Architect Edition (8CD) - $139.95
Plus! XP - $59.95
Photoshop Elements 3.0 Windows - $59.95
Director MX 2004 - $69.95
Photo Painter 8 - $59.95
Flash MX 2004 - $69.95
Encarta Encyclopedia Delux 2004 (3CD) - $89.95
Borland Delphi 7 Enterprise Edition (2CD) - $69.95
Photoshop CS with ImageReady CS - $99.95
Photoshop 7 - $69.95
Office 2000 Premium Edition PE (2CD) - $59.95
Our site:
http://uyinipho0khpvucpzccphcuc.shroudge.com/
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Pavel Roskin @ 2006-05-08 1:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: sean, git
In-Reply-To: <Pine.LNX.4.64.0605071751050.3718@g5.osdl.org>
On Sun, 2006-05-07 at 17:55 -0700, Linus Torvalds wrote:
>
> On Sun, 7 May 2006, sean wrote:
> >
> > Having magic sections that prepend "branch." seems a bit suspect;
> > why not just be explicit:
> >
> > [branch.Origin]
> > URL = ...
> > fetch = master
>
> Exactly because section (and key) names are normally not case sensitive.
>
> Even the documentation actually talks about "core.fileMode" and "[imap]
> Folders".
Make it ["branch.Origin"]
No hardcoded "branch" prepending needed. The case sensitive name is
still protected by quotes. This extends trivially to ["user.Linus"] or
["path./src/git.c"] or whatever.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Johannes Schindelin @ 2006-05-08 1:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Pavel Roskin, git
In-Reply-To: <Pine.LNX.4.64.0605071718440.3718@g5.osdl.org>
Hi,
On Sun, 7 May 2006, Linus Torvalds wrote:
> [...]
>
> and if your branch names are purely alphabetical and lower-case, you can
> now write
>
> [branch.origin]
> remote = true
> url = git://git.kernel.org/...
> fetch = master
>
> [branch.master]
> pull = origin
>
> and it will be parsed _exactly_ the same as
>
> ["origin"]
> remote = true
> url = git://git.kernel.org/...
> fetch = master
>
> ["master"]
> pull = origin
>
> while the [branch.origin] syntax allows old versions of git to happily
> ignore it. So that would be a kind of cheesy work-around: the new
> double-quoted format is only _required_ for any branch-names that have
> special characters in it.
Eek.
The ["blablabla"] syntax fails the is-it-obvious-what-this-does test. What
*is* wrong with the " for " syntax? IIRC it was even proposed by you, and
it happens to be backward compatible.
Ciao,
Dscho
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: sean @ 2006-05-08 1:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: proski, git
In-Reply-To: <Pine.LNX.4.64.0605071751050.3718@g5.osdl.org>
On Sun, 7 May 2006 17:55:25 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:
> On Sun, 7 May 2006, sean wrote:
> >
> > Having magic sections that prepend "branch." seems a bit suspect;
> > why not just be explicit:
> >
> > [branch.Origin]
> > URL = ...
> > fetch = master
>
> Exactly because section (and key) names are normally not case sensitive.
Restore case sensitivity to config file parsing and the problem largely goes
away. Or go the other route and remove case sensitivity from all the other
bits (branches names etc..).
Sean
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Pavel Roskin @ 2006-05-08 1:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.63.0605080303410.13588@wbgn013.biozentrum.uni-wuerzburg.de>
Hello, Johannes!
On Mon, 2006-05-08 at 03:05 +0200, Johannes Schindelin wrote:
> The ["blablabla"] syntax fails the is-it-obvious-what-this-does test. What
> *is* wrong with the " for " syntax? IIRC it was even proposed by you, and
> it happens to be backward compatible.
Not trying to answer for Linus, here's my take.
The "for" syntax is one more layer in the config hierarchy. Adding
another layer is a more intrusive solution than relaxing the syntax of
the existing elements without changing their semantic.
git-repo-config is "for" agnostic. It doesn't parse "for" (as far as I
know).
"for" can be confusing in some contexts, or may force inversion of the
hierarchy to make the config file more readable. How would you
implement branch descriptions? See this:
[branchdata]
description = "netdev" for "Network device development"
and this
[branchdata]
description = "Network device development" for "netdev"
The later is closer to English. Or should we use the first approach and
"is" instead of "for"?
Now, how can I get a description for the "netdev" branch by one
git-repo-config command, without pipes?
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Unresolved issues #2 (shallow clone again)
From: Theodore Tso @ 2006-05-08 1:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605071744210.3718@g5.osdl.org>
On Sun, May 07, 2006 at 05:50:42PM -0700, Linus Torvalds wrote:
>
>
> On Sun, 7 May 2006, Theodore Tso wrote:
> >>
> > If there are 233338 objects, then the average wasted space due to
> > internal fragmentation is 233338 * 2k, or 466676 kilobytes, or only
> > 36% of the wasted space.
>
> That's not necessarily true.
>
> That assumes a randomly distributed filesize. File sizes are _not_ random,
> and in particular if you have the distribution leaning towards <2kB being
> common, you can actually get >50% fragmentation.
>
> Btw, I hit this when some people argued that the page size should be made
> 64kB. The above (incorrect) logic implies that you waste 32kB on average
> per file. That's not true, if a large fraction of your files are small, in
> which case you may actually be wastign closer to 60kB on average from
> using a big page-size, because about half of the kernel files are actually
> smaller than 4kB (or something. I forget the exact statistics, I did them
> with a script at some point).
>
> Anyway, with inode overhead and a lot of objects being just a couple of
> hundred bytes, I think I estimated at some point that you actually lost
> closer to 3kB per object.
I just ran the numbers on filesizes of a kernel tree I had handy,
which happened to be 2.6.16.11. With no object files, git files,
etc. the average loss was 2351 bytes --- not that far away from the
average of 2048 bytes. Granted, it may be there is more different
versions of small objects causing a skewing of the distributions of
git objects in the 2.6 tree, but I'm not familiar enough with the git
porcelain to be able to make it disgorge the sizes of the repository
to do the math.
- Ted
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Junio C Hamano @ 2006-05-08 1:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605071740550.3718@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sun, 7 May 2006, Pavel Roskin wrote:
>>
>> I'm only concerned that we would be hardcoding the word "branch". We
>> could need fancy section names for other things in the future.
>
> Fair enough. We could have used some fake section name that you can't
> generate any other way (in fact, "Branch.$branchname" would be that), but
> the upside of using "branch" is exactly that you _can_ generate it with
> the old-style syntax that is acceptable to older git versions too.
Sorry, I do not follow the old-style syntax part.
How about keeping the default syntax as it is (tokens are case
insensitive and alnums only, dot separates tokens into
sections), and when a token that violates that rule needs to be
spelled out, require quoting, so:
branch.foo BranCh.FoO branch.FOO
are the same (section "branch.foo"), and if I have js/fmt.patch
branch, I need to spell the configuration for that branch like
so:
branch."js/fmt.patch" or "branch.js/fmt.patch"
and the URL variable for that section is
$ git repo-config '"branch.js/fmt.patch".url'
(BTW, you could even have a variable with dots in it by quoting
the variable name, like "branch.js/fmt.patch"."fetch.option"; I
do not know if it is worth it).
My repository is full of topic branches that are named xx/yyyy.
It is very handy to be able to say "show-branch --topics master
'heads/??/*' next" which would not show my other branches like
"test", "throwaway", "rework", "temp", etc.
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Johannes Schindelin @ 2006-05-08 1:27 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Linus Torvalds, git
In-Reply-To: <1147051300.17371.32.camel@dv>
Hi,
On Sun, 7 May 2006, Pavel Roskin wrote:
> On Mon, 2006-05-08 at 03:05 +0200, Johannes Schindelin wrote:
> > The ["blablabla"] syntax fails the is-it-obvious-what-this-does test. What
> > *is* wrong with the " for " syntax? IIRC it was even proposed by you, and
> > it happens to be backward compatible.
>
> [branchdata]
> description = "netdev" for "Network device development"
>
> and this
>
> [branchdata]
> description = "Network device development" for "netdev"
The latter was how I recall the syntax proposed for proxies.
> Now, how can I get a description for the "netdev" branch by one
> git-repo-config command, without pipes?
git-repo-config --get branchdata.description ' for netdev$'
Hth,
Dscho
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: sean @ 2006-05-08 1:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: torvalds, git
In-Reply-To: <7vfyjli9vf.fsf@assigned-by-dhcp.cox.net>
On Sun, 07 May 2006 18:27:32 -0700
Junio C Hamano <junkio@cox.net> wrote:
> How about keeping the default syntax as it is (tokens are case
> insensitive and alnums only, dot separates tokens into
> sections), and when a token that violates that rule needs to be
> spelled out, require quoting, so:
>
> branch.foo BranCh.FoO branch.FOO
> are the same (section "branch.foo"),
Doesn't that mean you have to then prohibit creating mixed
case branches with "git branch" and "git checkout -b" ?
> and if I have js/fmt.patch
> branch, I need to spell the configuration for that branch like
> so:
>
> branch."js/fmt.patch" or "branch.js/fmt.patch"
>
> and the URL variable for that section is
>
> $ git repo-config '"branch.js/fmt.patch".url'
How about transforming slashes into dots? so the above would
be:
[branch.js.fmt.patch]
And could be accessed by either:
$ git repo-config branch.js.fmt.patch
$ git repo-config branch.js/fmt.patch
> (BTW, you could even have a variable with dots in it by quoting
> the variable name, like "branch.js/fmt.patch"."fetch.option"; I
> do not know if it is worth it).
Not worth it. Branch names should be alnums and imho should be
case sensitive too.
> My repository is full of topic branches that are named xx/yyyy.
> It is very handy to be able to say "show-branch --topics master
> 'heads/??/*' next" which would not show my other branches like
> "test", "throwaway", "rework", "temp", etc.
Very nice.
Sean
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Johannes Schindelin @ 2006-05-08 1:45 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP0334B471C6908E4E40BFD2AEA80@CEZ.ICE>
Hi,
On Sun, 7 May 2006, sean wrote:
> Not worth it. Branch names should be alnums and imho should be
> case sensitive too.
Why should they be case sensitive? So you have a branch "origin" and
another named "Origin" and get totally confused?
Ciao,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox