* Re: [PATCH] git-fetch: more terse fetch output
From: Linus Torvalds @ 2007-11-03 22:48 UTC (permalink / raw)
To: Mike Hommey
Cc: Nicolas Pitre, Junio C Hamano, git, Shawn O. Pearce, Jeff King
In-Reply-To: <20071103210321.GA25685@glandium.org>
On Sat, 3 Nov 2007, Mike Hommey wrote:
>
> How many grams in a kilogram ? How many meters in a kilometer ? How many
> joule in a kilojoule ? ... How many bytes in a kilobyte ? Oh wait...
How many 'u's in the word "colour"?
Oh, wait - it depends on context, doesn't it?
kB is 1024 bytes. The fact that "k" means something else in other contexts
is simply irrelevant.
Linus
^ permalink raw reply
* Re: [PATCH] git-fetch: more terse fetch output
From: Linus Torvalds @ 2007-11-03 22:45 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Mike Hommey, Junio C Hamano, git, Shawn O. Pearce, Jeff King
In-Reply-To: <alpine.LFD.0.9999.0711031645350.21255@xanadu.home>
On Sat, 3 Nov 2007, Nicolas Pitre wrote:
>
> Yes, to me, 1MB is 1024 KB. Always been, until those idiotic hard disk
> manufacturers decided to redefine the common interpretation of what
> everyone else used to consider what a MB is just to boost their
> marketing claims.
Actually, they just lost even that in a lawsuit (yeah, they "settled").
The fact is, 1MB = 1024kB = 1048576 bytes.
Anybody who claims anything else is a lying piece of pondscum, trying to
just fool people into paying more for less.
Which is why you should *not* use MiB and KiB - it only validates the
pondscum.
Linus
^ permalink raw reply
* Re: [PATCH] Implement selectable group ownership in git-init
From: Junio C Hamano @ 2007-11-03 22:31 UTC (permalink / raw)
To: Francesco Pretto; +Cc: git
In-Reply-To: <7vabpvx8uu.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I suspect this is good only for init-db. When normal codepaths
> create a new file under .git/ and call adjust_shared_perm(), who
> initializes owner_group and to what value with your patch?
>
> The way the world works is that adjust_shared_perm() relies on a
> new directory and/or file in .git/ being created in the same
> group as its parent directory .git/ ways the case).
sorry, did not finish editing before sending.
s| \.git.*.$|.|;
^ permalink raw reply
* Re: [PATCH] Implement selectable group ownership in git-init
From: Junio C Hamano @ 2007-11-03 22:27 UTC (permalink / raw)
To: Francesco Pretto; +Cc: git
In-Reply-To: <472CC676.3000603@gmail.com>
Francesco Pretto <ceztkoml@gmail.com> writes:
> Rationale: continuing the *nix tradition, git is very tied to fs ...
> ... please review it.
It is impossible to read, let alone comment on, your proposed
commit log message with such a looooooong line. Please split
the lines to reasonable length, as all other people do.
I wonder if "--group" is given, wouldn't it make sense to
default to "shared_repository = group" even without --shared
(alternatively, if only --group is given without --shared, you
could error out).
> diff --git a/builtin-init-db.c b/builtin-init-db.c
> index 763fa55..c8bed1e 100644
> --- a/builtin-init-db.c
> +++ b/builtin-init-db.c
> @@ -376,6 +380,20 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
> /*
> + * Complain if the repository is shared and no owner group have
> + * been selected.
> + */
> + if (shared_repository && !grouped_repository)
> + printf("WARNING: You haven't selected any owner group!\n");
> +
I think it is wrong to give this warning when --group is not
given, and it is doubly wrong to give the warning to stdout.
> + /*
> + * Catch the error early if the group provided doesn't exist
> + */
No need to make this into three lines.
> + if (getgrnam(owner_group) == NULL)
> + die("The group '%s' doesn't esist",
> + owner_group);
No need to split this into two lines.
> @@ -417,11 +435,15 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
> git_config_set("receive.denyNonFastforwards", "true");
> }
>
> - if (!quiet)
> + if (!quiet) {
> printf("%s%s Git repository in %s/\n",
> reinit ? "Reinitialized existing" : "Initialized empty",
> shared_repository ? " shared" : "",
> git_dir);
> + if (shared_repository)
> + printf("Put the commit users in the '%s' group\n",
> + grouped_repository ? owner_group : getgrgid(getgid())->gr_name);
> + }
Only useful for the first time users; iow, too verbose for
common usage.
> diff --git a/environment.c b/environment.c
> index b5a6c69..a518619 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -23,6 +23,8 @@ int repository_format_version;
> const char *git_commit_encoding;
> const char *git_log_output_encoding;
> int shared_repository = PERM_UMASK;
> +int grouped_repository = 0;
> +const char *owner_group = NULL;
Initialization to 0 and NULL should be left out, both for
readability and to keep these variables in BSS.
> const char *apply_default_whitespace;
> int zlib_compression_level = Z_BEST_SPEED;
> int core_compression_level;
> diff --git a/path.c b/path.c
> index 4260952..1ec1379 100644
> --- a/path.c
> +++ b/path.c
> @@ -286,6 +286,9 @@ int adjust_shared_perm(const char *path)
> mode |= S_ISGID;
> if ((mode & st.st_mode) != mode && chmod(path, mode) < 0)
> return -2;
> + if (grouped_repository)
> + if (chown(path, getuid(), getgrnam(owner_group)->gr_gid) < 0 )
> + return -3;
> return 0;
> }
I suspect this is good only for init-db. When normal codepaths
create a new file under .git/ and call adjust_shared_perm(), who
initializes owner_group and to what value with your patch?
The way the world works is that adjust_shared_perm() relies on a
new directory and/or file in .git/ being created in the same
group as its parent directory .git/ ways the case). So it is
just the matter of:
$ mkdir myproject.git
$ chgrp projectgroup myproject.git
$ GIT_DIR=myproject.git git init --shared
I think what the patch attempts to achieve may be good, but only
to reduce a few keystrokes of doing the "chgrp". Is it really
worth it, I have to wonder...
^ permalink raw reply
* Re: [PATCH] git-fetch: more terse fetch output
From: Jakub Narebski @ 2007-11-03 22:02 UTC (permalink / raw)
To: git
In-Reply-To: <20071103210321.GA25685@glandium.org>
Mike Hommey wrote:
> On Sat, Nov 03, 2007 at 04:50:54PM -0400, Nicolas Pitre wrote:
>> [ heh, I knew someone would say something ]
>>
>> Yes, to me, 1MB is 1024 KB. Always been, until those idiotic hard disk
>> manufacturers decided to redefine the common interpretation of what
>> everyone else used to consider what a MB is just to boost their
>> marketing claims.
>
> How many grams in a kilogram ? How many meters in a kilometer ? How many
> joule in a kilojoule ? ... How many bytes in a kilobyte ? Oh wait...
>
> And you know what ? It's not only a matter of hard disk manufacturers.
>
> How fast is gigabit ethernet ? Yep, 1000000000 bits/s
> How big would people say a 44000000 bytes file is ? 44MB or 42MB ?
> And my favourite: How many bytes in a 1.44MB floppy disk ? 1474560, that
> is, 1.44 * 1024000.
>
> Those who made this big mess are the ones who decided a KB was 1024
> bytes, not the others.
No, the problem is that in _computer science_ kB (or KB) was 1024 bytes,
and MB was 1024 kilobytes, because 1024 is a power of 2, and for example
naturally the memory which can be adressed comes as a power of 2.
Now in other parts of science k means 1000, and M means 1000000. To make
the computer sciences meaning of kB explicit SI introduced ki and Mi prefix.
And manufacturers claiming HDD size x GB in the SI meaning took part...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] gitweb : disambiguate heads and tags withs the same name
From: Guillaume Seguin @ 2007-11-03 21:40 UTC (permalink / raw)
To: pasky; +Cc: git
In-Reply-To: <7v3avsmpmj.fsf@gitster.siamese.dyndns.org>
Avoid wrong disambiguation that would link logs/trees of tags and heads which
share the same name to the same page, leading to a disambiguation that would
prefer the tag, thus making it impossible to access the corresponding
head log and tree without hacking the url by hand.
Signed-off-by: Guillaume Seguin <guillaume@segu.in>
---
gitweb/gitweb.perl | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 48e21da..f918c00 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3534,6 +3534,7 @@ sub git_tags_body {
for (my $i = $from; $i <= $to; $i++) {
my $entry = $taglist->[$i];
my %tag = %$entry;
+ my $name = "refs/tags/$tag{'name'}";
my $comment = $tag{'subject'};
my $comment_short;
if (defined $comment) {
@@ -3570,8 +3571,8 @@ sub git_tags_body {
"<td class=\"link\">" . " | " .
$cgi->a({-href => href(action=>$tag{'reftype'}, hash=>$tag{'refid'})}, $tag{'reftype'});
if ($tag{'reftype'} eq "commit") {
- print " | " . $cgi->a({-href => href(action=>"shortlog", hash=>$tag{'name'})}, "shortlog") .
- " | " . $cgi->a({-href => href(action=>"log", hash=>$tag{'name'})}, "log");
+ print " | " . $cgi->a({-href => href(action=>"shortlog", hash=>$name)}, "shortlog") .
+ " | " . $cgi->a({-href => href(action=>"log", hash=>$name)}, "log");
} elsif ($tag{'reftype'} eq "blob") {
print " | " . $cgi->a({-href => href(action=>"blob_plain", hash=>$tag{'refid'})}, "raw");
}
@@ -3597,6 +3598,7 @@ sub git_heads_body {
for (my $i = $from; $i <= $to; $i++) {
my $entry = $headlist->[$i];
my %ref = %$entry;
+ my $name = "refs/heads/$ref{'name'}";
my $curr = $ref{'id'} eq $head;
if ($alternate) {
print "<tr class=\"dark\">\n";
@@ -3606,13 +3608,13 @@ sub git_heads_body {
$alternate ^= 1;
print "<td><i>$ref{'age'}</i></td>\n" .
($curr ? "<td class=\"current_head\">" : "<td>") .
- $cgi->a({-href => href(action=>"shortlog", hash=>$ref{'name'}),
+ $cgi->a({-href => href(action=>"shortlog", hash=>$name),
-class => "list name"},esc_html($ref{'name'})) .
"</td>\n" .
"<td class=\"link\">" .
- $cgi->a({-href => href(action=>"shortlog", hash=>$ref{'name'})}, "shortlog") . " | " .
- $cgi->a({-href => href(action=>"log", hash=>$ref{'name'})}, "log") . " | " .
- $cgi->a({-href => href(action=>"tree", hash=>$ref{'name'}, hash_base=>$ref{'name'})}, "tree") .
+ $cgi->a({-href => href(action=>"shortlog", hash=>$name)}, "shortlog") . " | " .
+ $cgi->a({-href => href(action=>"log", hash=>$name)}, "log") . " | " .
+ $cgi->a({-href => href(action=>"tree", hash=>$name, hash_base=>$name)}, "tree") .
"</td>\n" .
"</tr>";
}
--
1.5.3.4.395.g85b0
^ permalink raw reply related
* Re: [PATCH] git-fetch: more terse fetch output
From: Pierre Habouzit @ 2007-11-03 21:46 UTC (permalink / raw)
To: Mike Hommey
Cc: Nicolas Pitre, Linus Torvalds, Junio C Hamano, git,
Shawn O. Pearce, Jeff King
In-Reply-To: <20071103210321.GA25685@glandium.org>
[-- Attachment #1: Type: text/plain, Size: 450 bytes --]
On Sat, Nov 03, 2007 at 09:03:21PM +0000, Mike Hommey wrote:
> Those who made this big mess are the ones who decided a KB was 1024
> bytes, not the others.
Oooh noes, we already had that discussion on debian-devel@ a few month
ago, could we _please_ spare it :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-svn questions: how to clone/init non-standard layout branches/tags?
From: Luke Lu @ 2007-11-03 21:26 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Benoit SIGOURE, git
In-Reply-To: <8c5c35580711031352n3396807fm3004ebe8f86110ed@mail.gmail.com>
On Nov 3, 2007, at 1:52 PM, Lars Hjemli wrote:
> On Nov 3, 2007 9:41 PM, Luke Lu <git@vicaya.com> wrote:
>> On Nov 3, 2007, at 1:32 PM, Lars Hjemli wrote:
>>> On Nov 3, 2007 9:01 PM, Luke Lu <git@vicaya.com> wrote:
>>>> I did try to add a "fetch" line for the production branch like
>>>> this:
>>>>
>>>> [svn-remote "svn"]
>>>> url = svn+ssh://host/svn/project
>>>> fetch = production:refs/remotes/svn-prod
>>>> fetch = trunk:refs/remotes/git-svn
>>>>
>>>> which is modeled after http://lists-archives.org/git/420712-git-
>>>> svn-
>>>> remote-tracking-branch-question.html
>>>>
>>> Did you forget to run 'git svn fetch' after modifying your .git/
>>> config?
>>
>> Yes, I did. It didn't seem to do anything.
>
> Hmm, it works for me, I've been adding and removing branches like this
> for months, but my .git/config is slightly different:
>
> [svn-remote "svn"]
> url = svn://example.org
> fetch = project/trunk:refs/remotes/svn/trunk
> fetch = project/branches/topic:refs/remotes/svn/topic
>
> I don't know if this difference is important, though...
I tried to test this on a local repository like file:///path/project.
It seems to work and get everything properly upon git svn fetch.
However it doesn't work for the production branch. If I modify the
fetch line a bit to svn/prod instead of svn-prod and try git svn
fetch again. It would hang for about 2 minutes and return 0 and show
nothing in progress. A .git/svn/svn/prod directory is created but
it's empty.
One thing that might be special for this branch is that it gets
deleted and recreated/copied all the time from trunk. I wonder if git-
svn use some kind of heuristics to determine if there is anything to
fetch and silently failing...
__Luke
^ permalink raw reply
* Re: [PATCH] git-fetch: more terse fetch output
From: Mike Hommey @ 2007-11-03 21:03 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Linus Torvalds, Junio C Hamano, git, Shawn O. Pearce, Jeff King
In-Reply-To: <alpine.LFD.0.9999.0711031645350.21255@xanadu.home>
On Sat, Nov 03, 2007 at 04:50:54PM -0400, Nicolas Pitre wrote:
> [ heh, I knew someone would say something ]
>
> Yes, to me, 1MB is 1024 KB. Always been, until those idiotic hard disk
> manufacturers decided to redefine the common interpretation of what
> everyone else used to consider what a MB is just to boost their
> marketing claims.
How many grams in a kilogram ? How many meters in a kilometer ? How many
joule in a kilojoule ? ... How many bytes in a kilobyte ? Oh wait...
And you know what ? It's not only a matter of hard disk manufacturers.
How fast is gigabit ethernet ? Yep, 1000000000 bits/s
How big would people say a 44000000 bytes file is ? 44MB or 42MB ?
And my favourite: How many bytes in a 1.44MB floppy disk ? 1474560, that
is, 1.44 * 1024000.
Those who made this big mess are the ones who decided a KB was 1024
bytes, not the others.
Mike
^ permalink raw reply
* Re: git-svn questions: how to clone/init non-standard layout branches/tags?
From: Lars Hjemli @ 2007-11-03 20:52 UTC (permalink / raw)
To: Luke Lu; +Cc: Benoit SIGOURE, git
In-Reply-To: <8644CD78-25F0-42C4-A163-BD88528594F3@vicaya.com>
On Nov 3, 2007 9:41 PM, Luke Lu <git@vicaya.com> wrote:
> On Nov 3, 2007, at 1:32 PM, Lars Hjemli wrote:
> > On Nov 3, 2007 9:01 PM, Luke Lu <git@vicaya.com> wrote:
> >> I did try to add a "fetch" line for the production branch like this:
> >>
> >> [svn-remote "svn"]
> >> url = svn+ssh://host/svn/project
> >> fetch = production:refs/remotes/svn-prod
> >> fetch = trunk:refs/remotes/git-svn
> >>
> >> which is modeled after http://lists-archives.org/git/420712-git-svn-
> >> remote-tracking-branch-question.html
> >>
> > Did you forget to run 'git svn fetch' after modifying your .git/
> > config?
>
> Yes, I did. It didn't seem to do anything.
Hmm, it works for me, I've been adding and removing branches like this
for months, but my .git/config is slightly different:
[svn-remote "svn"]
url = svn://example.org
fetch = project/trunk:refs/remotes/svn/trunk
fetch = project/branches/topic:refs/remotes/svn/topic
I don't know if this difference is important, though...
--
larsh
^ permalink raw reply
* Re: [PATCH] git-fetch: more terse fetch output
From: Nicolas Pitre @ 2007-11-03 20:50 UTC (permalink / raw)
To: Mike Hommey
Cc: Linus Torvalds, Junio C Hamano, git, Shawn O. Pearce, Jeff King
In-Reply-To: <20071103204000.GA24959@glandium.org>
On Sat, 3 Nov 2007, Mike Hommey wrote:
> On Sat, Nov 03, 2007 at 04:30:27PM -0400, Nicolas Pitre wrote:
> > On Sat, 3 Nov 2007, Linus Torvalds wrote:
> >
> > >
> > >
> > > On Sat, 3 Nov 2007, Nicolas Pitre wrote:
> > > >
> > > > Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.
> > >
> > > I mostly like this, but can we please just use "MB/kB" instead of
> > > "MiB/KiB"?
> > >
> > > I hope it was some kind of joke on crazy EU bureaucrats that just wasn't
> > > caught in time.
> >
> > I don't care either ways. In fact my own preference is for MB/kB, but
> > if I had used that first I'm sure someone else would have asked for the
> > purist notations.
>
> As far as you don't claim 1MB is 1024KB, it's okay.
[ heh, I knew someone would say something ]
Yes, to me, 1MB is 1024 KB. Always been, until those idiotic hard disk
manufacturers decided to redefine the common interpretation of what
everyone else used to consider what a MB is just to boost their
marketing claims.
Nicolas
^ permalink raw reply
* Re: [PATCH] git-fetch: more terse fetch output
From: Mike Hommey @ 2007-11-03 20:40 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Linus Torvalds, Junio C Hamano, git, Shawn O. Pearce, Jeff King
In-Reply-To: <alpine.LFD.0.9999.0711031627000.21255@xanadu.home>
On Sat, Nov 03, 2007 at 04:30:27PM -0400, Nicolas Pitre wrote:
> On Sat, 3 Nov 2007, Linus Torvalds wrote:
>
> >
> >
> > On Sat, 3 Nov 2007, Nicolas Pitre wrote:
> > >
> > > Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.
> >
> > I mostly like this, but can we please just use "MB/kB" instead of
> > "MiB/KiB"?
> >
> > I hope it was some kind of joke on crazy EU bureaucrats that just wasn't
> > caught in time.
>
> I don't care either ways. In fact my own preference is for MB/kB, but
> if I had used that first I'm sure someone else would have asked for the
> purist notations.
As far as you don't claim 1MB is 1024KB, it's okay.
Mike
^ permalink raw reply
* Re: git-svn questions: how to clone/init non-standard layout branches/tags?
From: Luke Lu @ 2007-11-03 20:41 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Benoit SIGOURE, git
In-Reply-To: <8c5c35580711031332y4018dba6y5d24965ebf2fbefb@mail.gmail.com>
On Nov 3, 2007, at 1:32 PM, Lars Hjemli wrote:
> On Nov 3, 2007 9:01 PM, Luke Lu <git@vicaya.com> wrote:
>> On Nov 3, 2007, at 6:59 AM, Lars Hjemli wrote:
>>> On Nov 3, 2007 11:56 AM, Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:
>>>> On Nov 3, 2007, at 9:19 AM, Luke Lu wrote:
>>>>> 2. Is there a way to add a new svn branch like that (say
>>>>> production
>>>>> or some_branch) to an existing git-svn repository that has trunk
>>>>> cloned?
>>>>
>>>> I don't know, but that'd be great indeed.
>>>>
>>>
>>> You can simply add "fetch" lines to the relevant "svn-remote"
>>> section
>>> in .git/config.
>>
>> I did try to add a "fetch" line for the production branch like this:
>>
>> [svn-remote "svn"]
>> url = svn+ssh://host/svn/project
>> fetch = production:refs/remotes/svn-prod
>> fetch = trunk:refs/remotes/git-svn
>>
>> which is modeled after http://lists-archives.org/git/420712-git-svn-
>> remote-tracking-branch-question.html
>>
>> But when I try to checkout the production branch like this:
>>
>> git checkout -b prod remotes/svn-prod
>>
>> I got this:
>> git checkout: updating paths is incompatible with switching branches/
>> forcing
>> Did you intend to checkout 'remotes/svn-prod' which can not be
>> resolved as commit?
>
> Did you forget to run 'git svn fetch' after modifying your .git/
> config?
Yes, I did. It didn't seem to do anything. $? is 0. the master/trunk
is up-to-date but the production branch has never been fetched. If
this is supposed to work, the fetch might be triggered upon next
update in trunk?
__Luke
^ permalink raw reply
* Re: git-svn questions: how to clone/init non-standard layout branches/tags?
From: Lars Hjemli @ 2007-11-03 20:32 UTC (permalink / raw)
To: Luke Lu; +Cc: Benoit SIGOURE, git
In-Reply-To: <C81F0AB6-ED04-405F-AA29-CD72816FB7B9@vicaya.com>
On Nov 3, 2007 9:01 PM, Luke Lu <git@vicaya.com> wrote:
> On Nov 3, 2007, at 6:59 AM, Lars Hjemli wrote:
> > On Nov 3, 2007 11:56 AM, Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:
> >> On Nov 3, 2007, at 9:19 AM, Luke Lu wrote:
> >>> 2. Is there a way to add a new svn branch like that (say production
> >>> or some_branch) to an existing git-svn repository that has trunk
> >>> cloned?
> >>
> >> I don't know, but that'd be great indeed.
> >>
> >
> > You can simply add "fetch" lines to the relevant "svn-remote" section
> > in .git/config.
>
> I did try to add a "fetch" line for the production branch like this:
>
> [svn-remote "svn"]
> url = svn+ssh://host/svn/project
> fetch = production:refs/remotes/svn-prod
> fetch = trunk:refs/remotes/git-svn
>
> which is modeled after http://lists-archives.org/git/420712-git-svn-
> remote-tracking-branch-question.html
>
> But when I try to checkout the production branch like this:
>
> git checkout -b prod remotes/svn-prod
>
> I got this:
> git checkout: updating paths is incompatible with switching branches/
> forcing
> Did you intend to checkout 'remotes/svn-prod' which can not be
> resolved as commit?
Did you forget to run 'git svn fetch' after modifying your .git/config?
--
larsh
^ permalink raw reply
* Re: [PATCH] git-fetch: more terse fetch output
From: Nicolas Pitre @ 2007-11-03 20:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git, Shawn O. Pearce, Jeff King
In-Reply-To: <alpine.LFD.0.999.0711031229470.15101@woody.linux-foundation.org>
On Sat, 3 Nov 2007, Linus Torvalds wrote:
>
>
> On Sat, 3 Nov 2007, Nicolas Pitre wrote:
> >
> > Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.
>
> I mostly like this, but can we please just use "MB/kB" instead of
> "MiB/KiB"?
>
> I hope it was some kind of joke on crazy EU bureaucrats that just wasn't
> caught in time.
I don't care either ways. In fact my own preference is for MB/kB, but
if I had used that first I'm sure someone else would have asked for the
purist notations.
Nicolas
^ permalink raw reply
* Re: git-svn questions: how to clone/init non-standard layout branches/tags?
From: Luke Lu @ 2007-11-03 20:01 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Benoit SIGOURE, git
In-Reply-To: <8c5c35580711030659x203f8ae8s40366c493a3eeae6@mail.gmail.com>
On Nov 3, 2007, at 6:59 AM, Lars Hjemli wrote:
> On Nov 3, 2007 11:56 AM, Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:
>> On Nov 3, 2007, at 9:19 AM, Luke Lu wrote:
>>> 2. Is there a way to add a new svn branch like that (say production
>>> or some_branch) to an existing git-svn repository that has trunk
>>> cloned?
>>
>> I don't know, but that'd be great indeed.
>>
>
> You can simply add "fetch" lines to the relevant "svn-remote" section
> in .git/config.
I did try to add a "fetch" line for the production branch like this:
[svn-remote "svn"]
url = svn+ssh://host/svn/project
fetch = production:refs/remotes/svn-prod
fetch = trunk:refs/remotes/git-svn
which is modeled after http://lists-archives.org/git/420712-git-svn-
remote-tracking-branch-question.html
But when I try to checkout the production branch like this:
git checkout -b prod remotes/svn-prod
I got this:
git checkout: updating paths is incompatible with switching branches/
forcing
Did you intend to checkout 'remotes/svn-prod' which can not be
resolved as commit?
Can you shed some light on this? (git version is 1.5.3.4)
Thanks!
__Luke
^ permalink raw reply
* Re: [PATCH 1/2] Reuse previous annotation when overwriting a tag
From: Mike Hommey @ 2007-11-03 19:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlk9fxj1r.fsf@gitster.siamese.dyndns.org>
On Sat, Nov 03, 2007 at 11:47:44AM -0700, Junio C Hamano wrote:
(...)
> But in this case, as the variable "sp" is never used before it
> is reassigned, I can easily say "drop the useless assignment to
> sp there". ;-)
You got me here ;)
(...)
> When prev is not NULL but points at a null_sha1 nobody writes
> anything out. Is this intended?
>
> In fact, the calling site always passes prev which is
> prev[] in cmd_tag() and cannot be non-NULL.
Damn, I overlooked this, and since the test suite doesn't do anything
on that, that got through. Indeed either the test can be removed, since
write_tag_body does the is_null_sha1() test, or the is_null_sha1() test
can be moved here.
> Why is there "else" in the first place? Even if you start with
> the previous tag's message, you are launching the editor for the
> user to further edit it, and you would want to give some
> instructions, wouldn't you?
Well, it could be true if the text was more verbose than "Write a tag
message". Anyways, as the test is now, the text is not going to appear.
:(
I'll fix this and will try to enhance the test suite to catch these
problems.
Mike
^ permalink raw reply
* Re: [REPLACEMENT PATCH 2/2] Add "--early-output" log flag for interactive GUI use
From: Marco Costalba @ 2007-11-03 19:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Paul Mackerras, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0711031103340.3342@woody.linux-foundation.org>
On 11/3/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> Try it out, with
>
> git log --early-output=2
>
> and look at what happens
It works for me! tomorrow I will try to teach qgit to play with this new toy.
BTW there are some warning around that disappear adding
extern void sort_in_topological_order(struct commit_list ** list, int lifo);
somewhere in commit.h
Marco
^ permalink raw reply
* Re: [PATCH] git-svn: sort the options in the --help message.
From: Eric Wong @ 2007-11-03 19:42 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: git, gitster
In-Reply-To: <1194116014-13964-1-git-send-email-tsuna@lrde.epita.fr>
Benoit Sigoure <tsuna@lrde.epita.fr> wrote:
> * git-svn.perl (&usage): Sort the various options.
>
> Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
> ---
> It always annoys me when I read the output of git svn <cmd> --help that the
> options are printed in no particular order.
The above sentence belongs in the commit message.
Thanks,
Acked-by: Eric Wong <normalperson@yhbt.net>
> git-svn.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 22bb47b..4900f57 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -252,7 +252,7 @@ Usage: $0 <command> [options] [arguments]\n
> next if $cmd && $cmd ne $_;
> next if /^multi-/; # don't show deprecated commands
> print $fd ' ',pack('A17',$_),$cmd{$_}->[1],"\n";
> - foreach (keys %{$cmd{$_}->[2]}) {
> + foreach (sort keys %{$cmd{$_}->[2]}) {
> # mixed-case options are for .git/config only
> next if /[A-Z]/ && /^[a-z]+$/i;
> # prints out arguments as they should be passed:
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Implement selectable group ownership in git-init
From: Francesco Pretto @ 2007-11-03 19:36 UTC (permalink / raw)
To: git
In-Reply-To: <472CC676.3000603@gmail.com>
2007/11/3, Francesco Pretto <ceztkoml@gmail.com>:
> Rationale ...
Just to point, I wrote this patch for usability purpose and because i
think git still need a strong imprinting about its correct usage
pattern (i've read around that people using it with shared
repositories are already having problems with file permissions,
wrongly thinking it's inflexible for their needs). If you stand with
my reasoning, please help me to integrate this patch :-), I have other
ideas following this. NB: i'm not a C developer (that was my first
patch in pure C), have mercy...
The function adjust_shared_perm is used in other places: is there
other git commands that maybe needs to create files/dirs of a specific
group (not being in a g+sx dir)? Hopefully not, but i don't know git
source much. These are the occurrences (with the exclusion of
builtin-init-db.c):
refs.c: adjust_shared_perm(log_file);
refs.c: if (adjust_shared_perm(git_HEAD)) {
..
builtin-pack-objects.c: return adjust_shared_perm(path);
...
builtin-rerere.c: (mkdir(rr_cache, 0777) ||
adjust_shared_perm(rr_cache)))
...
lockfile.c: if (adjust_shared_perm(lk->filename))
...
sha1_file.c: else if (adjust_shared_perm(path)) {
^ permalink raw reply
* Re: [PATCH] git-fetch: more terse fetch output
From: Linus Torvalds @ 2007-11-03 19:34 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git, Shawn O. Pearce, Jeff King
In-Reply-To: <alpine.LFD.0.9999.0711030101340.21255@xanadu.home>
On Sat, 3 Nov 2007, Nicolas Pitre wrote:
>
> Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.
I mostly like this, but can we please just use "MB/kB" instead of
"MiB/KiB"?
I hope it was some kind of joke on crazy EU bureaucrats that just wasn't
caught in time.
I also get the glitch, ie
remote: Total 118 (delta 86), reused 112 (delta 86)iB/s
where that "iB/s" remains as garbage from the previous line: we use
hardcoded vt100 sequences for colorization, and nobody has complained yet,
so maybe we should just do the same for "reset and clear to end of line"?
Or maybe just add a few spaces. Using kB/MB instead of KiB/MiB will make
it a few less characters to overwrite too.
Linus
^ permalink raw reply
* [PATCH] Implement selectable group ownership in git-init
From: Francesco Pretto @ 2007-11-03 19:05 UTC (permalink / raw)
To: git
Rationale: continuing the *nix tradition, git is very tied to fs permissions. Groups ownership of git repositories can in fact perfectly resemble projects work groups.
The problem came when sysadmins or git admins create shared repositories: it does not have sense to create repositories with :root group ownership, if you have to put users in the root group to let them use it (!). But the same stands for the administrative git:git user (if you have one): having all the commit users in the git group means that it's impossible to selectively give (or prevent) access to users to different projects. For this reason, git-init should give the possibility to create shared repositories of a selectable group. Moreover, it should warn the user if no specific group is provided, just to warn the user in the case of wrong usage pattern (like :root or :git repositories). The following patch implements this possibility (and the warning), please review it.
---
builtin-init-db.c | 26 ++++++++++++++++++++++++--
cache.h | 2 ++
environment.c | 2 ++
path.c | 3 +++
4 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 763fa55..c8bed1e 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -321,7 +321,7 @@ static void guess_repository_type(const char *git_dir)
}
static const char init_db_usage[] =
-"git-init [-q | --quiet] [--template=<template-directory>] [--shared]";
+"git-init [-q | --quiet] [--template=<template-directory>] [--shared] [--group=<project-group>]";
/*
* If you want to, you can share the DB area with any number of branches.
@@ -346,6 +346,10 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
shared_repository = PERM_GROUP;
else if (!prefixcmp(arg, "--shared="))
shared_repository = git_config_perm("arg", arg+9);
+ else if (!prefixcmp(arg, "--group=")) {
+ owner_group = arg+8;
+ grouped_repository = 1;
+ }
else if (!strcmp(arg, "-q") || !strcmp(arg, "--quiet"))
quiet = 1;
else
@@ -376,6 +380,20 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
}
/*
+ * Complain if the repository is shared and no owner group have
+ * been selected.
+ */
+ if (shared_repository && !grouped_repository)
+ printf("WARNING: You haven't selected any owner group!\n");
+
+ /*
+ * Catch the error early if the group provided doesn't exist
+ */
+ if (getgrnam(owner_group) == NULL)
+ die("The group '%s' doesn't esist",
+ owner_group);
+
+ /*
* Set up the default .git directory contents
*/
git_dir = getenv(GIT_DIR_ENVIRONMENT);
@@ -417,11 +435,15 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
git_config_set("receive.denyNonFastforwards", "true");
}
- if (!quiet)
+ if (!quiet) {
printf("%s%s Git repository in %s/\n",
reinit ? "Reinitialized existing" : "Initialized empty",
shared_repository ? " shared" : "",
git_dir);
+ if (shared_repository)
+ printf("Put the commit users in the '%s' group\n",
+ grouped_repository ? owner_group : getgrgid(getgid())->gr_name);
+ }
return 0;
}
diff --git a/cache.h b/cache.h
index bfffa05..282b0f6 100644
--- a/cache.h
+++ b/cache.h
@@ -306,6 +306,8 @@ extern int prefer_symlink_refs;
extern int log_all_ref_updates;
extern int warn_ambiguous_refs;
extern int shared_repository;
+extern int grouped_repository;
+extern const char *owner_group;
extern const char *apply_default_whitespace;
extern int zlib_compression_level;
extern int core_compression_level;
diff --git a/environment.c b/environment.c
index b5a6c69..a518619 100644
--- a/environment.c
+++ b/environment.c
@@ -23,6 +23,8 @@ int repository_format_version;
const char *git_commit_encoding;
const char *git_log_output_encoding;
int shared_repository = PERM_UMASK;
+int grouped_repository = 0;
+const char *owner_group = NULL;
const char *apply_default_whitespace;
int zlib_compression_level = Z_BEST_SPEED;
int core_compression_level;
diff --git a/path.c b/path.c
index 4260952..1ec1379 100644
--- a/path.c
+++ b/path.c
@@ -286,6 +286,9 @@ int adjust_shared_perm(const char *path)
mode |= S_ISGID;
if ((mode & st.st_mode) != mode && chmod(path, mode) < 0)
return -2;
+ if (grouped_repository)
+ if (chown(path, getuid(), getgrnam(owner_group)->gr_gid) < 0 )
+ return -3;
return 0;
}
^ permalink raw reply related
* Re: [PATCH] git-format-patch: Number patches when there are more than one
From: Samuel Tardieu @ 2007-11-03 18:56 UTC (permalink / raw)
To: git
In-Reply-To: <472CA29F.3090701@op5.se>
>>>>> "Andreas" == Andreas Ericsson <ae@op5.se> writes:
>> Does it make sense to turn it off ?
Andreas> Sometimes, yes. I frequently gather several small fixes on a
Andreas> branch and then send all of them at once. They rarely depend
Andreas> on each other, and apply order is usually not important, so
Andreas> it doesn't make sense to order them.
So do I. I prefer the auto-numbering to be off by default as it is now.
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ permalink raw reply
* [PATCH] git-svn: sort the options in the --help message.
From: Benoit Sigoure @ 2007-11-03 18:53 UTC (permalink / raw)
To: git; +Cc: gitster, normalperson, Benoit Sigoure
* git-svn.perl (&usage): Sort the various options.
Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
---
It always annoys me when I read the output of git svn <cmd> --help that the
options are printed in no particular order.
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 22bb47b..4900f57 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -252,7 +252,7 @@ Usage: $0 <command> [options] [arguments]\n
next if $cmd && $cmd ne $_;
next if /^multi-/; # don't show deprecated commands
print $fd ' ',pack('A17',$_),$cmd{$_}->[1],"\n";
- foreach (keys %{$cmd{$_}->[2]}) {
+ foreach (sort keys %{$cmd{$_}->[2]}) {
# mixed-case options are for .git/config only
next if /[A-Z]/ && /^[a-z]+$/i;
# prints out arguments as they should be passed:
--
1.5.3.4.398.g859b
^ permalink raw reply related
* Re: [PATCH 1/2] Reuse previous annotation when overwriting a tag
From: Junio C Hamano @ 2007-11-03 18:47 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <1194095285-18651-1-git-send-email-mh@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> +static void write_tag_body(int fd, const unsigned char *sha1)
> +{
> ...
> + sp = buf = read_sha1_file(sha1, &type, &size);
> + if (!buf)
> + return;
> + /* skip header */
> + sp = strstr(buf, "\n\n");
I was relieved to see this second assignment to "sp" here.
Why?
Because I wanted to say something about the first assignment to
it, that is done this way:
> + sp = buf = read_sha1_file(sha1, &type, &size);
The original git codebase, as it came from Linus, tends to avoid
assignment to multiple variables in a single statement like this
(and that style is written down in the kernel coding style
document). As I do not have a strong opinion against that
coding style, I've tried to follow it myself. However, I do not
personaly have a strong argument to support enforcing the style
to others.
But in this case, as the variable "sp" is never used before it
is reassigned, I can easily say "drop the useless assignment to
sp there". ;-)
> +
> + if (!sp || !size || type != OBJ_TAG) {
> + free(buf);
> + return;
> + }
> + sp += 2; /* skip the 2 CRs */
You are not skipping carriage returns. You are skipping line
feeds (i.e. s/CRs/LFs/).
> @@ -282,7 +313,11 @@ static void create_tag(const unsigned char *object, const char *tag,
> if (fd < 0)
> die("could not create file '%s': %s",
> path, strerror(errno));
> - write_or_die(fd, tag_template, strlen(tag_template));
> +
> + if (prev)
> + write_tag_body(fd, prev);
> + else
> + write_or_die(fd, tag_template, strlen(tag_template));
> close(fd);
When prev is not NULL but points at a null_sha1 nobody writes
anything out. Is this intended?
In fact, the calling site always passes prev which is
prev[] in cmd_tag() and cannot be non-NULL.
Why is there "else" in the first place? Even if you start with
the previous tag's message, you are launching the editor for the
user to further edit it, and you would want to give some
instructions, wouldn't you?
^ 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