* Re: Unresolved issues #2
From: Junio C Hamano @ 2006-05-08 2:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e3km6q$f7p$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> char *value; /* "existence" bool may have NULL,
>> * otherwise probably a string "= value"
>> */
>
> Probably " = value" to preserve whitespace (e.g. justify on equal sign in
> hand crafted config file).
Probably even better is to remove the separate *value_comment,
and make this thing point at the entire " = value ; this is the
comment for the value\n" thing.
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: sean @ 2006-05-08 2:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqu9i6zl.fsf@assigned-by-dhcp.cox.net>
On Sun, 07 May 2006 19:29:50 -0700
Junio C Hamano <junkio@cox.net> wrote:
> Not at all. Whatever Porcelain that runs repo-config to record
> the branch name needs to spell that branch name with proper
> quoting, like:
Okay. It just seems nuts to require quoting because you happen
to use an uppercase character. People are used to quoting
special characters like * and $, not uppercase letters.
> I _do_ want to keep my slashes intact and also dots; mangling
> them is not very nice to me X-<.
You're right.
We should just relax the config file rules for legal characters,
in identifiers, at least [a-zA-Z0-9_/-].
Sean.
^ permalink raw reply
* Re: Unresolved issues #2 (shallow clone again)
From: Linus Torvalds @ 2006-05-08 2:42 UTC (permalink / raw)
To: Theodore Tso; +Cc: git
In-Reply-To: <20060508022432.GA26076@thunk.org>
On Sun, 7 May 2006, Theodore Tso wrote:
>
> That brings up an interesting question though --- why not skip
> compressing files that are under 4k (or whatever the filesystem
> blocksize happens to be) if they are unpacked? It burns CPU time;
> maybe not enough to be human-noticeable, but it's still not buying you
> anything.
Well, other filesystems don't have 4kB issues. Reiser can do smaller
things iirc, and you might obviously have a ext3 filesystem with a 1kB
blocksize too. And with tails on FFS, you might have a filesystem with a
8kB blocksize, but despite that it might lay out <1kB files well.
Anyway, packing makes all this basically a non-issue. There are no block
boundaries in a pack-file, and you only use a single inode. And you'd
obviously want to pack for other reasons anyway (ie the delta compression
will makea huge difference over time).
Linus
^ permalink raw reply
* Re: [PATCH] Release config lock if the regex is invalid
From: Junio C Hamano @ 2006-05-08 2:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605080229220.32508@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 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:
except that many places you already close(fd) and
unlink(lock_file).
Somehow it vaguely reminds me of recent "kernel in C++" thread
in the other mailing list, which I do not want people to start
talking about here, but moving all the clean-up code to exit
path indeed makes things simpler to read.
How about doing something like this?
-- >8 --
diff --git a/config.c b/config.c
index 11d65f8..adb5ce4 100644
--- a/config.c
+++ b/config.c
@@ -420,7 +420,7 @@ int git_config_set_multivar(const char*
const char* value_regex, int multi_replace)
{
int i;
- int fd, in_fd;
+ int fd = -1, in_fd;
int ret;
char* config_filename = strdup(git_path("config"));
char* lock_file = strdup(git_path("config.lock"));
@@ -478,15 +478,11 @@ int git_config_set_multivar(const char*
if ( ENOENT != errno ) {
error("opening %s: %s", config_filename,
strerror(errno));
- close(fd);
- unlink(lock_file);
ret = 3; /* same as "invalid config file" */
goto out_free;
}
/* if nothing to unset, error out */
if (value == NULL) {
- close(fd);
- unlink(lock_file);
ret = 5;
goto out_free;
}
@@ -514,8 +510,6 @@ 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;
}
@@ -551,8 +545,6 @@ int git_config_set_multivar(const char*
/* if nothing to unset, or too many matches, error out */
if ((store.seen == 0 && value == NULL) ||
(store.seen > 1 && multi_replace == 0)) {
- close(fd);
- unlink(lock_file);
ret = 5;
goto out_free;
}
@@ -601,8 +593,6 @@ int git_config_set_multivar(const char*
unlink(config_filename);
}
- close(fd);
-
if (rename(lock_file, config_filename) < 0) {
fprintf(stderr, "Could not rename the lock file?\n");
ret = 4;
@@ -612,10 +602,14 @@ int git_config_set_multivar(const char*
ret = 0;
out_free:
+ if (0 <= fd)
+ 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: Implementing branch attributes in git config
From: Junio C Hamano @ 2006-05-08 2:29 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP0334B471C6908E4E40BFD2AEA80@CEZ.ICE>
sean <seanlkml@sympatico.ca> writes:
> 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" ?
Not at all. Whatever Porcelain that runs repo-config to record
the branch name needs to spell that branch name with proper
quoting, like:
>> 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]
I _do_ want to keep my slashes intact and also dots; mangling
them is not very nice to me X-<.
^ permalink raw reply
* Re: Unresolved issues #2 (shallow clone again)
From: Theodore Tso @ 2006-05-08 2:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605071853290.3718@g5.osdl.org>
On Sun, May 07, 2006 at 07:04:48PM -0700, Linus Torvalds wrote:
> Is that without compression?
Yes, without compression. So yes, that probably explains the
difference between your numbers and mine.
That brings up an interesting question though --- why not skip
compressing files that are under 4k (or whatever the filesystem
blocksize happens to be) if they are unpacked? It burns CPU time;
maybe not enough to be human-noticeable, but it's still not buying you
anything.
- Ted
^ permalink raw reply
* Re: Unresolved issues #2 (shallow clone again)
From: Linus Torvalds @ 2006-05-08 2:04 UTC (permalink / raw)
To: Theodore Tso; +Cc: git
In-Reply-To: <20060508012632.GD17138@thunk.org>
On Sun, 7 May 2006, Theodore Tso wrote:
>
> 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.
Is that without compression?
git objects are compressed, and common types (trees) tend to be smaller
than your normal C file.
So git objects tend to be _smaller_ than the regular files. By about 30%.
In addition, the non-blob git objects themselves tend to be smaller still.
So for example, right now I have just 58 unpacked objects (I repack pretty
often). But of those 58 objects, exactly _fifty_ are smaller than 2kB, and
38 are smaller than 1kB. The median size is 771 bytes.
On master.kernel.org, I've not repacked as recently, so I've got 2268
unpacked objects. But the median size there is 773 bytes, so it looks like
the numbers are statistically pretty stable.
Linus
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Pavel Roskin @ 2006-05-08 1:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.63.0605080327490.13794@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, 2006-05-08 at 03:27 +0200, Johannes Schindelin wrote:
> > 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$'
No, it doesn't remove "for netdev". What I really don't like is that
git-repo-config treats it as "not my problem".
git-repo-config places extremely tight limitations of the names of the
sections and the keys. But sometimes a relationship between two loosely
defined strings needs to be presented. It's a real need. And
git-repo-config doesn't address this need.
I believe git-repo-config should allow direct retrieval of data from any
depth, and the syntax should be explicit rather than fuzzy. A dot is
more explicit than "for", especially if the dot appears after a name
that may not contain dots.
Another question is how we want to group the data. Do we want to have
all descriptions together or in separate sections? Whatever the answer,
git-repo-config should provide means to extract all data in one command,
without need for postprocessing.
So I understand arguing where to place the branch name. But what I
don't like is the desire to offload part of the processing on the
callers.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: sean @ 2006-05-08 1:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605080344480.14008@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, 8 May 2006 03:45:47 +0200 (CEST)
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 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?
>
I don't care either way, just think we should be consistent. Currently
we support case sensitivity in branch names and let people get
totally confused. But in practice people don't really get confused
by the linux filesystem which is case sensitive.
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
* 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: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: 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: 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: 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: 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: 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: 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
* 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: 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
* 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: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: 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: 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: 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
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