* 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
* 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: 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: 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: 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: 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: [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: 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: 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
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: Unresolved issues #2 (shallow clone again)
From: Junio C Hamano @ 2006-05-08 2:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e3ksoq$is$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Wouldn't it be easier (sorry, no code yet) to have the following:
>
> I WANT to have these
> I HAVE these
> These are GRAFT PARENTLESS
>
> with the target side sending list of all parentless commits in the
> ... The source side will then do the grafting 'in memory' and
> send the packs like normal, only with those cauterizing grafts in place.
I think that is essentially the outline of shallow clone
proposal, except that you have to be careful and take not just
"parentless" but other grafts (e.g. one that removes one parent
from a merge commit to pretend that a side branch did not exist)
into account as well. I do not remember if I already coded it
or not -- I might have.
^ permalink raw reply
* Re: Unresolved issues #2 (shallow clone again)
From: Jakub Narebski @ 2006-05-08 4:02 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7xdgram.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Wouldn't it be easier (sorry, no code yet) to have the following:
>>
>> I WANT to have these
>> I HAVE these
>> These are GRAFT PARENTLESS
>>
>> with the target side sending list of all parentless commits in the
>> ... The source side will then do the grafting 'in memory' and
>> send the packs like normal, only with those cauterizing grafts in place.
>
> I think that is essentially the outline of shallow clone
> proposal, except that you have to be careful and take not just
> "parentless" but other grafts (e.g. one that removes one parent
> from a merge commit to pretend that a side branch did not exist)
> into account as well. I do not remember if I already coded it
> or not -- I might have.
Having grafts file being used for both joining history and cauterizing
history makes re-cauterizing (e.g. changing depth of clone) difficult at
best...
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Unresolved issues #2 (shallow clone again)
From: Jakub Narebski @ 2006-05-08 4:24 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7xdgram.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Wouldn't it be easier (sorry, no code yet) to have the following:
>>
>> I WANT to have these
>> I HAVE these
>> These are GRAFT PARENTLESS
>>
>> with the target side sending list of all parentless commits in the
>> ... The source side will then do the grafting 'in memory' and
>> send the packs like normal, only with those cauterizing grafts in place.
>
> I think that is essentially the outline of shallow clone
> proposal, except that you have to be careful and take not just
> "parentless" but other grafts (e.g. one that removes one parent
> from a merge commit to pretend that a side branch did not exist)
> into account as well. I do not remember if I already coded it
> or not -- I might have.
So, let it be all grafts removing some or all parents from commit.
And that proposal would work I think also for the fetch, not only clone.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Unresolved issues #2 (shallow clone again)
From: Jeff King @ 2006-05-08 4:24 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0605070802590.16343@g5.osdl.org>
On Sun, May 07, 2006 at 08:27:02AM -0700, Linus Torvalds wrote:
> factor for a lot of things for many "common" filesystem setups. You
> probably didn't even account for the size of inodes in your "du" setup.
My numbers came from git-count-objects, which uses the st_blocks sum for
all objects. The actual du numbers showing space wasted by block
boundaries are:
du -c ??: 1429216
du -c --apparent-size ??: 792277
So it's about 45% wasted space.
On Sun, May 07, 2006 at 08:33:38PM -0400, 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. Most of the savings is probably coming from
> the compression and delta packing.
As Linus indicated, that assumes a uniform distribution of file sizes
(and my numbers above show that it is, in fact, somewhat higher). FYI,
the mean and median of usage of the final 4K block in the linux-2.6
repository are 1309 and 912 bytes, respectively.
-Peff
^ permalink raw reply
* Re: Implementing branch attributes in git config
From: Junio C Hamano @ 2006-05-08 9:00 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1147053329.17371.52.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> 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".
Stating what you do not like about something is a good first
step to improve that something. It should not be too hard to
extend the parser to grok:
repo-config --get branchdata.description '\(.*\) for netdev$'
and when the value_regex has a capture return what matches
instead of the entire value. I think that would do what you
want.
^ permalink raw reply
* Re: Locking a branch
From: Catalin Marinas @ 2006-05-08 10:45 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1146970243.24434.77.camel@dv>
Pavel Roskin <proski@gnu.org> wrote:
> I see there is an active discussion about branch attributes. It
> would be nice to have an attribute to prevent git from changing the
> branch head in any way. The reason is that it interferes with StGIT
> on StGIT managed branches. If StGIT is fine with the change, it
> would remove or override the lock temporarily. StGIT could also
> unlock the branch permanently if there are no applied patches.
I'm fine with this. At the moment, StGIT does extra checking before
some of the commands to ensure that HEAD is the same as the top of the
stack (i.e. no commits were generated outside stg commands). While
I'll probably still keep this check, the addition would be useful for
people mixing GIT and StGIT commands (I personally try to stay with
StGIT commands as much as possible).
--
Catalin
^ permalink raw reply
* Re: [patch] munmap-before-rename, cygwin need
From: Yakov Lerner @ 2006-05-08 10:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslnlk04v.fsf@assigned-by-dhcp.cox.net>
On 5/8/06, Junio C Hamano <junkio@cox.net> wrote:
> "Yakov Lerner" <iler.ml@gmail.com> writes:
>
> > I found that mmap() works on cygwin, but needs a patch.
> > On Cygwin, rename() fails if target file has active mmap().
> > The patch below adds munmap() before rename().
>
> This is interesting in three counts.
>
> - I from time to time test Cygwin version on my day-job machine
> (W2K) and my wife's machine (XP); on both machines I usually
> have less than two weeks old Cygwin installation, and I have
> not seen the breakage. I wonder how reproducible this is.
> Also previously people reported mmap() works for some and
> fake mmap is needed for others. Would this patch make things
> work for everybody?
>
> - The part you patched is commit_index_file(). This typically
> is called just before program exit, but some callers, like
> apply.c, may want to still look at the index after calling
> it, fully aware that the changes after commit_index will not
> be written out. Although I haven't traced the codepath fully
> in apply.c yet, unmapping would break the access to the index
> (i.e. active_cache[]). Does apply still work with your
> patch?
I am checking this. I am trying different options and different
scenarios.
Yakov
^ 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