* 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: 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] 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: 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: 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: [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: [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: 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: 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: 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: 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
* [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: 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
* 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] 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] 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] 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: Mike Hommey @ 2007-11-03 23:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: Nicolas Pitre, Junio C Hamano, git, Shawn O. Pearce, Jeff King
In-Reply-To: <alpine.LFD.0.999.0711031546110.15101@woody.linux-foundation.org>
On Sat, Nov 03, 2007 at 03:48:42PM -0700, Linus Torvalds wrote:
>
>
> 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.
What about the fact that "kB" means different things depending whether it's
used for bandwidth or memory capacity ?
Does your brain have base 2 hard-coded so that you instantly know 50000000
bytes are 47.68MB ? Are people unable to do so pondscum ?
Mike
^ permalink raw reply
* [RFC PATCH] Make gitk use --early-output
From: Paul Mackerras @ 2007-11-03 23:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
This makes gitk use the --early-output flag on the git log command.
When gitk sees the "Final output:" line from git log, it goes into a
mode where it basically just checks that it is getting the commits
again in the same order as before. If they are, well and good; if
not, it truncates its internal list at the point of difference and
proceeds to read in the commits in the new order from there on, and
re-does the graph layout if necessary.
This gives a much more immediate feel to the startup; gitk shows its
window with the first screenful of commits displayed very quickly this
way.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/gitk b/gitk
index 1da0b0a..7d9a2f2 100755
--- a/gitk
+++ b/gitk
@@ -84,25 +84,27 @@ proc start_rev_list {view} {
global commfd leftover tclencoding datemode
global viewargs viewfiles commitidx viewcomplete vnextroot
global showlocalchanges commitinterest mainheadid
- global progressdirn progresscoords proglastnc curview
+ global progressdirn progresscoords proglastnc curview rereading
set startmsecs [clock clicks -milliseconds]
set commitidx($view) 0
set viewcomplete($view) 0
set vnextroot($view) 0
- set order "--topo-order"
+ set order "--early-output=50"
if {$datemode} {
- set order "--date-order"
+ lappend order "--date-order"
}
if {[catch {
- set fd [open [concat | git log --no-color -z --pretty=raw $order --parents \
- --boundary $viewargs($view) "--" $viewfiles($view)] r]
+ set fd [open [concat | git log --no-color -z --pretty=raw \
+ $order --parents --boundary \
+ $viewargs($view) "--" $viewfiles($view)] r]
} err]} {
error_popup "Error executing git rev-list: $err"
exit 1
}
set commfd($view) $fd
set leftover($view) {}
+ set rereading($view) -1
if {$showlocalchanges} {
lappend commitinterest($mainheadid) {dodiffindex}
}
@@ -161,6 +163,7 @@ proc getcommitlines {fd view} {
global parentlist children curview hlview
global vparentlist vdisporder vcmitlisted
global ordertok vnextroot idpending
+ global rereading nullid nullid2
set stuff [read $fd 500000]
# git log doesn't terminate the last commit with a null...
@@ -236,6 +239,15 @@ proc getcommitlines {fd view} {
}
set start [expr {$i + 1}]
set j [string first "\n" $cmit]
+ if {$j >= 0 && [string match "Final output:*" $cmit]} {
+ set rereading($view) 0
+ set cmit [string range $cmit [expr {$j + 1}] end]
+ set j [string first "\n" $cmit]
+ if {$view == $curview} {
+ layoutmore
+ update
+ }
+ }
set ok 0
set listed 1
if {$j >= 0 && [string match "commit *" $cmit]} {
@@ -255,6 +267,7 @@ proc getcommitlines {fd view} {
break
}
}
+ set cmit [string range $cmit [expr {$j + 1}] end]
}
if {!$ok} {
set shortcmit $cmit
@@ -265,13 +278,31 @@ proc getcommitlines {fd view} {
exit 1
}
set id [lindex $ids 0]
+ if {$rereading($view) >= 0} {
+ set r $rereading($view)
+ set oldid [lindex $displayorder $r]
+ while {$oldid eq $nullid || $oldid eq $nullid2} {
+ set oldid [lindex $displayorder [incr r]]
+ }
+ if {$oldid eq $id} {
+ # commits are still in the same order; just skip to the next
+ set rereading($view) [expr {$r + 1}]
+ continue
+ }
+ if {$r < $commitidx($view)} {
+ # commits are in a different order now;
+ # truncate the list and redisplay
+ truncate_view $view $r
+ }
+ set rereading($view) -1
+ }
if {![info exists ordertok($view,$id)]} {
set otok "o[strrep $vnextroot($view)]"
incr vnextroot($view)
set ordertok($view,$id) $otok
} else {
set otok $ordertok($view,$id)
- unset idpending($view,$id)
+ catch {unset idpending($view,$id)}
}
if {$listed} {
set olds [lrange $ids 1 end]
@@ -301,7 +332,7 @@ proc getcommitlines {fd view} {
if {![info exists children($view,$id)]} {
set children($view,$id) {}
}
- set commitdata($id) [string range $cmit [expr {$j + 1}] end]
+ set commitdata($id) $cmit
set commitrow($view,$id) $commitidx($view)
incr commitidx($view)
if {$view == $curview} {
@@ -323,7 +354,7 @@ proc getcommitlines {fd view} {
}
if {$gotsome} {
run chewcommits $view
- if {$view == $curview} {
+ if {0 && $view == $curview} {
# update progress bar
global progressdirn progresscoords proglastnc
set inc [expr {($commitidx($view) - $proglastnc) * 0.0002}]
@@ -354,6 +385,43 @@ proc getcommitlines {fd view} {
return 2
}
+proc truncate_view {view row} {
+ global curview commitidx displayorder parentlist commitlisted
+ global vdisporder vparentlist vcmitlisted commitrow children
+ global numcommits localfrow localirow
+
+ set rm1 [expr {$row - 1}]
+ if {$view == $curview} {
+ set disporder $displayorder
+ set displayorder [lrange $disporder 0 $rm1]
+ set parents $parentlist
+ set parentlist [lrange $parents 0 $rm1]
+ set commitlisted [lrange $commitlisted 0 $rm1]
+ } else {
+ set disporder $vdisporder($view)
+ set vdisporder($view) [lrange $disporder 0 $rm1]
+ set parents $vparentlist($view)
+ set vparentlist($view) [lrange $parents 0 $rm1]
+ set vcmitlisted($view) [lrange $vcmitlisted($view) 0 $rm1]
+ }
+ for {set r $commitidx($view)} {[incr r -1] >= $row} {} {
+ set id [lindex $disporder $r]
+ foreach p [lindex $parents $r] {
+ if {[lindex $children($view,$p) end] eq $id} {
+ set children($view,$p) [lrange $children($view,$p) 0 end-1]
+ }
+ }
+ unset commitrow($view,$id)
+ }
+ set commitidx($view) $row
+ if {$view == $curview} {
+ truncate_localchanges $row
+ if {$row < $numcommits} {
+ undolayout $row
+ }
+ }
+}
+
proc chewcommits {view} {
global curview hlview viewcomplete
global selectedline pending_select
@@ -2843,6 +2911,20 @@ proc dohidelocalchanges {} {
incr lserial
}
+proc truncate_localchanges {row} {
+ global localfrow localirow
+
+ if {$localfrow >= $row} {
+ set localfrow -1
+ }
+ if {$localirow >= $row} {
+ set localirow -1
+ }
+ if {$localfrow == $row - 1 || $localirow == $row - 1} {
+ dohidelocalchanges
+ }
+}
+
# spawn off a process to do git diff-index --cached HEAD
proc dodiffindex {} {
global localirow localfrow lserial showlocalchanges
@@ -3840,6 +3922,23 @@ proc drawcommits {row {endrow {}}} {
}
}
+proc undolayout {row} {
+ global uparrowlen mingaplen downarrowlen
+ global rowidlist rowisopt rowfinal need_redisplay
+
+ set r [expr {$row - ($uparrowlen + $mingaplen + $downarrowlen)}]
+ if {$r < 0} {
+ set r 0
+ }
+ if {[llength $rowidlist] > $r} {
+ set rowidlist [lrange $rowidlist 0 $r]
+ set rowfinal [lrange $rowfinal 0 $r]
+ set rowisopt [lrange $rowisopt 0 $r]
+ set need_redisplay 1
+ run drawvisible
+ }
+}
+
proc drawfrac {f0 f1} {
global canv linespc
^ permalink raw reply related
* [PATCH 2/2] Add tests for git tag
From: Mike Hommey @ 2007-11-04 0:11 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1194135075-28706-1-git-send-email-mh@glandium.org>
These tests check whether git-tag properly sends a comment into the
editor, and whether it reuses previous annotation when overwriting
an existing tag.
Signed-off-by: Mike Hommey <mh@glandium.org>
---
t/t7004-tag.sh | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 0d07bc3..096fe33 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1004,4 +1004,20 @@ test_expect_failure \
'verify signed tag fails when public key is not present' \
'git-tag -v signed-tag'
+test_expect_success \
+ 'message in editor has initial comment' '
+ GIT_EDITOR=cat git tag -a initial-comment > actual || true &&
+ test $(sed -n "/^\(#\|\$\)/p" actual | wc -l) -gt 0
+'
+
+get_tag_header reuse $commit commit $time >expect
+echo "An annotation to be reused" >> expect
+test_expect_success \
+ 'overwriting an annoted tag should use its previous body' '
+ git tag -a -m "An annotation to be reused" reuse &&
+ GIT_EDITOR=true git tag -f -a reuse &&
+ get_tag_msg reuse >actual &&
+ git diff expect actual
+'
+
test_done
--
1.5.3.5
^ permalink raw reply related
* [PATCH 1/2] Reuse previous annotation when overwriting a tag
From: Mike Hommey @ 2007-11-04 0:11 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vlk9fxj1r.fsf@gitster.siamese.dyndns.org>
When forcing to overwrite an annotated tag, there are good chances one
wants to keep the old annotation, or modify it, not start from scratch.
This is obviously only triggered for annotated tagging (-a or -s).
Signed-off-by: Mike Hommey <mh@glandium.org>
---
You are free to remove the else that makes the tag template not show up
in the editor, but I'm not convinced it is any useful. Maybe a new
template for this annotation reuse would be sensible.
builtin-tag.c | 38 +++++++++++++++++++++++++++++++++++---
1 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index 66e5a58..566d123 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -247,9 +247,37 @@ static int git_tag_config(const char *var, const char *value)
return git_default_config(var, value);
}
+static void write_tag_body(int fd, const unsigned char *sha1)
+{
+ unsigned long size;
+ enum object_type type;
+ char *buf, *sp, *eob;
+ size_t len;
+
+ buf = read_sha1_file(sha1, &type, &size);
+ if (!buf)
+ return;
+ /* skip header */
+ sp = strstr(buf, "\n\n");
+
+ if (!sp || !size || type != OBJ_TAG) {
+ free(buf);
+ return;
+ }
+ sp += 2; /* skip the 2 LFs */
+ eob = strstr(sp, "\n" PGP_SIGNATURE "\n");
+ if (eob)
+ len = eob - sp;
+ else
+ len = buf + size - sp;
+ write_or_die(fd, sp, len);
+
+ free(buf);
+}
+
static void create_tag(const unsigned char *object, const char *tag,
struct strbuf *buf, int message, int sign,
- unsigned char *result)
+ unsigned char *prev, unsigned char *result)
{
enum object_type type;
char header_buf[1024];
@@ -282,7 +310,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 (!is_null_sha1(prev))
+ write_tag_body(fd, prev);
+ else
+ write_or_die(fd, tag_template, strlen(tag_template));
close(fd);
launch_editor(path, buf);
@@ -419,7 +451,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
die("tag '%s' already exists", tag);
if (annotate)
- create_tag(object, tag, &buf, message, sign, object);
+ create_tag(object, tag, &buf, message, sign, prev, object);
lock = lock_any_ref_for_update(ref, prev, 0);
if (!lock)
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH] git-format-patch: Number patches when there are more than one
From: Johannes Schindelin @ 2007-11-04 0:25 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Mike Hommey, git, spearce
In-Reply-To: <472CA301.50508@op5.se>
Hi,
On Sat, 3 Nov 2007, Andreas Ericsson wrote:
> Every piece of DWIM can be translated as "do what I didn't say". If you
> had to say it, it wouldn't be DWIM after all.
At some point, though, it becomes a "Do what _I_ (and nobody else does, or
at least what a substantial part of the rest of the world did not) mean",
and that point is reached here and now.
Wow. I did not think I had to explain _that_.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/2] History replay support
From: Paul Mackerras @ 2007-11-04 0:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Marco Costalba, git
In-Reply-To: <alpine.LFD.0.999.0711021809060.3342@woody.linux-foundation.org>
Linus Torvalds writes:
> It's disgusting. But it avoids the unnecessary data transfer - except for
> just the first 100 commits that get sent twice. And it gets what *I* look
> for, namely that "immediate" feel to the initial pop-up of the history.
Yes. And it avoids the need for gitk to have to do any re-ordering of
the commits that it gets from git log. In the case where the first
commits come out in a different order in the final list, gitk can just
truncate its list at the point of difference and re-read from there,
which is a lot less time-consuming than having to make a decision
for every commit about where it should go in the list.
I have actually been trying to come up with a decent way to generate
the list incrementally without using --topo-order for months now. One
of the problems is that while Tcl can append things to the end of a
long list efficiently, and can index long lists efficiently, inserting
things into the middle of a long list is slow. That makes any
insertion-sort type of algorithm unbearably slow. And it's not just
when we get parents before children that I have to insert into the
middle of the list -- reordering a date-order list into one where we
see the string of commits that were merged immediately after a merge
commit requires a lot of insertions.
I do have an approach that I'm thinking about that builds up the list
as a series of "arcs", each of which is a string of commits with
exactly one parent and one child. Each new commit from git log
(without --topo-order) then either gets appended to an arc (there can
be several arcs that are still growing at any given point), or it is a
merge or a branch point, which means it terminates some arc(s) and/or
starts new arc(s). The final list of commits is then composed by
concatenating the arcs in a suitable order. That avoids doing
insertions but does make things more complex for the consumers of the
list (the layout algorithm and the search function), and it
potentially makes it much slower to go from a row number to the commit
displayed on that row.
However, for now I think that using --early-output is a good
compromise solution that makes the startup much faster (or at least
*appear* to be much faster :) without adding much complexity.
Regards,
Paul.
^ permalink raw reply
* Advanced aliases with arguments (?)
From: Mike Hommey @ 2007-11-04 0:40 UTC (permalink / raw)
To: git
Hi,
I read on http://git.or.cz/gitwiki/Aliases that
Starting with version 1.5.3, git supports appending the
arguments to commands prefixed with "!", too. If you need to
perform a reordering, or to use an argument twice, you can use
this trick:
[alias]
example = !sh -c "ls $1 $0"
AFAICT, it doesn't work with the 1.5.3.5 I use. Is it false advertising
or was there some regression ?
Mike
^ permalink raw reply
* Re: Advanced aliases with arguments (?)
From: Mike Hommey @ 2007-11-04 0:45 UTC (permalink / raw)
To: git
In-Reply-To: <20071104004020.GA30487@glandium.org>
On Sun, Nov 04, 2007 at 01:40:20AM +0100, Mike Hommey wrote:
> Hi,
>
> I read on http://git.or.cz/gitwiki/Aliases that
>
> Starting with version 1.5.3, git supports appending the
> arguments to commands prefixed with "!", too. If you need to
> perform a reordering, or to use an argument twice, you can use
> this trick:
>
> [alias]
> example = !sh -c "ls $1 $0"
>
>
> AFAICT, it doesn't work with the 1.5.3.5 I use. Is it false advertising
> or was there some regression ?
Aaaah it does work, but you need to use single quotes, not double
quotes.
Mike
^ 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