* Re: [PATCH] gitweb: fixes to gitweb feature check code
From: Jakub Narebski @ 2008-11-17 9:28 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <cb7bb73a0811162210iadb7511rc3474272c8e60c59@mail.gmail.com>
Dnia poniedziałek 17. listopada 2008 07:10, Giuseppe Bilotta napisał:
> On Mon, Nov 17, 2008 at 2:02 AM, Jakub Narebski <jnareb@gmail.com> wrote:
[...]
> > First, you forgot the signoff, but you have addressed that already.
> >
> >
> > Second, I thought at first that it would be good for the patch to also
> > simplify %feature hash, using "'default' => 1" instead of current bit
> > convoluted "'default' => [1]", at the cost of bit more code for
> > defensive programming. But now I think that if it is to be done,
> > it should be put as separate patch.
>
> Is this an ACK? 8-D
I'm sorry. Yes, it is.
Acked-by: Jakub Narebski <jnareb@gmail.com>
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 2/2] git-remote: add verbose mode
From: crquan @ 2008-11-17 9:12 UTC (permalink / raw)
To: git
In-Reply-To: <1226913150-26088-1-git-send-email-crquan@gmail.com>
From: Denis ChengRq <crquan@gmail.com>
Signed-off-by: Cheng Renquan <crquan@gmail.com>
---
builtin-remote.c | 19 +++++++++++++------
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index d032f25..8a9f4b5 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -14,7 +14,7 @@ static const char * const builtin_remote_usage[] = {
"git remote rm <name>",
"git remote show [-n] <name>",
"git remote prune [-n | --dry-run] <name>",
- "git remote update [group]",
+ "git remote update [-v | --verbose] [group]",
NULL
};
@@ -40,10 +40,13 @@ static int opt_parse_track(const struct option *opt, const char *arg, int not)
return 0;
}
-static int fetch_remote(const char *name)
+static int fetch_remote(const char *name, const char *url)
{
const char *argv[] = { "fetch", name, NULL };
- printf("Updating %s\n", name);
+ if (verbose)
+ printf("Updating %s (%s)\n", name, url);
+ else
+ printf("Updating %s\n", name);
if (run_command_v_opt(argv, RUN_GIT_CMD))
return error("Could not fetch %s", name);
return 0;
@@ -117,7 +120,7 @@ static int add(int argc, const char **argv)
return 1;
}
- if (fetch && fetch_remote(name))
+ if (fetch && fetch_remote(name, url))
return 1;
if (master) {
@@ -769,8 +772,12 @@ static int prune(int argc, const char **argv)
static int get_one_remote_for_update(struct remote *remote, void *priv)
{
struct string_list *list = priv;
+
if (!remote->skip_default_update)
- string_list_append(xstrdup(remote->name), list);
+ string_list_append(remote->name, list)->util =
+ remote->url_nr > 0
+ ? (void *)remote->url[remote->url_nr-1] : NULL;
+
return 0;
}
@@ -818,7 +825,7 @@ static int update(int argc, const char **argv)
result = for_each_remote(get_one_remote_for_update, &list);
for (i = 0; i < list.nr; i++)
- result |= fetch_remote(list.items[i].string);
+ result |= fetch_remote(list.items[i].string, list.items[i].util);
/* all names were strdup()ed or strndup()ed */
list.strdup_strings = 1;
--
1.6.0.2
^ permalink raw reply related
* [PATCH 1/2] remote short help message updated
From: crquan @ 2008-11-17 9:12 UTC (permalink / raw)
To: git
From: Cheng Renquan <crquan@gmail.com>
Synced from git help remote.
Signed-off-by: Cheng Renquan <crquan@gmail.com>
---
builtin-remote.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index 71696b5..d032f25 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -8,12 +8,12 @@
#include "refs.h"
static const char * const builtin_remote_usage[] = {
- "git remote",
- "git remote add <name> <url>",
+ "git remote [-v | --verbose]",
+ "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>",
"git remote rename <old> <new>",
"git remote rm <name>",
- "git remote show <name>",
- "git remote prune <name>",
+ "git remote show [-n] <name>",
+ "git remote prune [-n | --dry-run] <name>",
"git remote update [group]",
NULL
};
--
1.6.0.2
^ permalink raw reply related
* [PATCH] request-pull: make usage string match manpage
From: Stefan Naewe @ 2008-11-17 8:57 UTC (permalink / raw)
To: git; +Cc: Stefan Naewe
The usage string of 'git request-pull' differs from he manpage
which gives the correct 'synopsis'.
Signed-off-by: Stefan Naewe <stefan.naewe@atlas-elektronik.com>
---
git-request-pull.sh | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index 073a314..9088019 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -4,9 +4,9 @@
# This file is licensed under the GPL v2, or a later version
# at the discretion of Linus Torvalds.
-USAGE='<commit> <url> [<head>]'
-LONG_USAGE='Summarizes the changes since <commit> to the standard output,
-and includes <url> in the message generated.'
+USAGE='<start> <url> [<end>]'
+LONG_USAGE='Summarizes the changes between two commits to the standard output,
+and includes the given URL in the generated summary.'
SUBDIRECTORY_OK='Yes'
OPTIONS_SPEC=
. git-sh-setup
--
1.5.6.5
^ permalink raw reply related
* [PATCH] gitweb: fix encode handling for site_{header,footer}
From: Tatsuki Sugiura @ 2008-11-17 7:53 UTC (permalink / raw)
To: git
All non-ASCII chars of site_{header,footer} will be broken
by perl IO layer without decoding to utf8.
Here is a fix to just call to_utf8 for inputs from these files.
Signed-off-by: Tatsuki Sugiura <sugi@nemui.org>
---
gitweb/gitweb.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 933e137..79ca5c2 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2929,7 +2929,7 @@ EOF
if (-f $site_header) {
open (my $fd, $site_header);
- print <$fd>;
+ print map {to_utf8($_)} <$fd>;
close $fd;
}
@@ -3018,7 +3018,7 @@ sub git_footer_html {
if (-f $site_footer) {
open (my $fd, $site_footer);
- print <$fd>;
+ print map {to_utf8($_)} <$fd>;
close $fd;
}
--
1.5.6.5
^ permalink raw reply related
* Re: git to libgit2 code relicensing
From: Andreas Ericsson @ 2008-11-17 7:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Christian Couder, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0811162159280.30769@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Sun, 16 Nov 2008, Andreas Ericsson wrote:
>
>> With the current list of ok's 73.09% of the code in git.git seems to be
>> relicenseable for the purpose of libgit2. That will provide quite a
>> kickstart.
>
> I doubt it. Most of that code was written with the execute-once
> mentality. And with the we-have-posix mentality.
>
"Copy-rewrite", naturally. Being able to lift much of the data-munging code
is a great benefit. It's basically just the revision traversal (which is
heavy on state-dependant code) that I haven't quite figured out how to do
yet, but I believe Shawn's idea of using revision pools is most likely the
way to go. Each application has to make sure a pool isn't modified by more
than one thread, but each application can have as many pools as it likes.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: publish since current state?
From: Andreas Ericsson @ 2008-11-17 7:21 UTC (permalink / raw)
To: Gennady Kushnir; +Cc: git
In-Reply-To: <96ed5eac0811161242o4c800e37u7c96872a9a4351ef@mail.gmail.com>
Gennady Kushnir wrote:
> Hello list.
> I'm going to publish my work into online public repository.
> I have several months of previous history in my local git repo. And I
> don't want to make it all public.
> Is it possible to publish just a shallow copy of my repository storing
> my current tree?
Yes. Look for 'grafts' in the documentation. You'll have to create a
new repository containing only the most recent code first, and then
create the grafts-file in that repository and copy the object database
from the old repository into the new one.
> I'd also like to keep my local history private but push new commits
> from it into that online repo.
>
The grafts solution will work like that, assuming you don't publish
your grafts-file.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: GIT and SCC
From: Andreas Ericsson @ 2008-11-17 7:05 UTC (permalink / raw)
To: Jan Hudec
Cc: Theodore Tso, Martin Terreni, Mike Ralphson, Shawn O. Pearce, git
In-Reply-To: <20081116215134.GA4719@efreet.light.src>
Jan Hudec wrote:
> On Wed, Nov 05, 2008 at 14:38:25 -0500, Theodore Tso wrote:
>> On Wed, Nov 05, 2008 at 09:23:55PM +0200, Martin Terreni wrote:
>>> http://en.wikipedia.org/wiki/SCC_compliant
>>>
>>> It is probably not much, but this is what I could find in a minute. many
>>> VC system have a SCC complaint API (apart of the native). This protocol
>>> was created by M$ is used by many systems so they are not bound to a
>>> specific VC tool.
>> It's a closed-source, undocumented API that you can only get access to
>> by signing a Microsoft NDA. From the WinMerge API:
>>
>> SCC API is closed API (no public documentation available) some
>> IDE's (e.g. Visual Studio) use. There apparently have couple
>> of reverse-engineered free implementations for SCC API. Status
>> of those are unknown.
>>
>> WARNING: Be very sure you are not submitting any code behing
>> NDA for WinMerge. WinMerge is Open Source so it is not legal
>> to do. And what is worse it would prevent anybody reading that
>> code working with SCC (and perhaps also VCS) support.
>>
>
> I don't really know what this interface is about, but:
> - For VS6 and newer, source control plugin can be implemented by creating
> a dll exporting particular set of controls. This is documented in help
> files that come with VS2005 SDK which is freely downloadable from M$ web,
> so I don't think that would be under NDA.
> - For VS2003 and newer (ie. the .NET based versions), plugins can be
> implemented for almost anything, including source control, by creating
> .net assembly exporting classes that implement some particular interfaces.
> These interfaces are documented in the abovementioned SDK, so again no NDA
> needed.
> I actually started writing such plugin some months back, but since I can only
> work on it at $work (don't have Windooze at ~, not to mention VS2005 license
> -- the SDK is free to download, but requires full, non-express, studio) and
> since it does not look like I could get them use Git at $work anytime soon,
> I didn't work on it too much. Still I could share the basic skeleton and
> the knowledge I have if somebody wanted to move that somewhere.
>
I'm interested. Please email me off-list. I'll pass it on to the monodevelop
people and see what happens. Hopefully they can reuse the same interface so
that mono plugins all of a sudden work everywhere.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] gitweb: fixes to gitweb feature check code
From: Giuseppe Bilotta @ 2008-11-17 6:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200811170202.27893.jnareb@gmail.com>
On Mon, Nov 17, 2008 at 2:02 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sat, 15 Nov 2008, Giuseppe Bilotta wrote:
>
>> The gitweb_check_feature routine was being used for two different
>> purposes: retrieving the actual feature value (such as the list of
>> snapshot formats or the list of additional actions), and to check if a
>> feature was enabled.
>>
>> For the latter use, since all features return an array, it led to either
>> clumsy code or subtle bugs, with disabled features appearing enabled
>> because (0) evaluates to 1.
>>
>> We fix these bugs, and simplify the code, by separating feature (list)
>> value retrieval (gitweb_get_feature) from boolean feature check (i.e.
>> retrieving the first/only item in the feature value list). Usage of
>> gitweb_check_feature across gitweb is replaced by the appropriate call
>> wherever needed.
>> ---
>
> First, you forgot the signoff, but you have addressed that already.
>
>
> Second, I thought at first that it would be good for the patch to also
> simplify %feature hash, using "'default' => 1" instead of current bit
> convoluted "'default' => [1]", at the cost of bit more code for
> defensive programming. But now I think that if it is to be done,
> it should be put as separate patch.
Is this an ACK? 8-D
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: purging unwanted history
From: Geoff Russell @ 2008-11-17 3:03 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20081117022714.GC3911@atjola.homenet>
On Mon, Nov 17, 2008 at 12:57 PM, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> On 2008.11.17 03:24:12 +0100, Björn Steinbrink wrote:
>> On 2008.11.17 10:56:23 +1030, Geoff Russell wrote:
>> > I have a repository with 5 years worth of history, I only want to keep
>> > 1 year, so I want to purge the first 4 years. As it happens, the
>> > repository only has a single branch which should simplify the problem.
>>
>> Use filter-branch to drop the parents on the first commit you want to
>> keep, and then drop the old cruft.
>>
>> Let's say $drop is the hash of the latest commit you want to drop. To
>> keep things sane and simple, make sure the first commit you want to
>> keep, ie. the child of $drop, is not a merge commit. Then you can use:
>>
>> git filter-branch --parent-filter "sed -e 's/-p $drop//'" \
>> --tag-name-filter cat -- \
>> --all ^$drop
>>
>> The above rewrites the parents of all commits that come "after" $drop.
>>
>> Check the results with gitk.
>>
>>
>> Then, to clean out all the old cruft.
>>
>> First, the backup references from filter-branch:
>>
>> git for-each-ref --format='%(refname)' refs/original | \
>> while read ref
>> do
>> git update-ref -d "$ref"
>> done
>>
>> Then clean your reflogs:
>> git reflog expire --expire=0 --all
>>
>> And finally, repack and drop all the old unreachable objects:
>> git repack -ad
>> git prune # For objects that repack -ad might have left around
>>
>> At that point, everything leading up to and including $drop should be
>> gone.
>
> Hm, on second thought, if you have tags referencing some of the old
> history, they'll still be around, I think. Just delete those before you
> start the rewriting.
>
> And of course do the above with a copy of your repo. Just in case.
>
> Björn
>
Great, I've just tested this and it is exactly what I want. I'm still
getting my head around
why, but understanding will arrive with a little more thought.
Many thanks,
Geoff
--
6 Fifth Ave,
St Morris, S.A. 5068
Australia
Ph: 041 8805 184 / 08 8332 5069
^ permalink raw reply
* Re: purging unwanted history
From: Björn Steinbrink @ 2008-11-17 2:27 UTC (permalink / raw)
To: Geoff Russell; +Cc: git
In-Reply-To: <20081117022412.GB3911@atjola.homenet>
On 2008.11.17 03:24:12 +0100, Björn Steinbrink wrote:
> On 2008.11.17 10:56:23 +1030, Geoff Russell wrote:
> > I have a repository with 5 years worth of history, I only want to keep
> > 1 year, so I want to purge the first 4 years. As it happens, the
> > repository only has a single branch which should simplify the problem.
>
> Use filter-branch to drop the parents on the first commit you want to
> keep, and then drop the old cruft.
>
> Let's say $drop is the hash of the latest commit you want to drop. To
> keep things sane and simple, make sure the first commit you want to
> keep, ie. the child of $drop, is not a merge commit. Then you can use:
>
> git filter-branch --parent-filter "sed -e 's/-p $drop//'" \
> --tag-name-filter cat -- \
> --all ^$drop
>
> The above rewrites the parents of all commits that come "after" $drop.
>
> Check the results with gitk.
>
>
> Then, to clean out all the old cruft.
>
> First, the backup references from filter-branch:
>
> git for-each-ref --format='%(refname)' refs/original | \
> while read ref
> do
> git update-ref -d "$ref"
> done
>
> Then clean your reflogs:
> git reflog expire --expire=0 --all
>
> And finally, repack and drop all the old unreachable objects:
> git repack -ad
> git prune # For objects that repack -ad might have left around
>
> At that point, everything leading up to and including $drop should be
> gone.
Hm, on second thought, if you have tags referencing some of the old
history, they'll still be around, I think. Just delete those before you
start the rewriting.
And of course do the above with a copy of your repo. Just in case.
Björn
^ permalink raw reply
* Re: purging unwanted history
From: Björn Steinbrink @ 2008-11-17 2:24 UTC (permalink / raw)
To: Geoff Russell; +Cc: git
In-Reply-To: <93c3eada0811161626h69929cd7va3fa4007a2341bae@mail.gmail.com>
On 2008.11.17 10:56:23 +1030, Geoff Russell wrote:
> I have a repository with 5 years worth of history, I only want to keep
> 1 year, so I want to purge the first 4 years. As it happens, the
> repository only has a single branch which should simplify the problem.
Use filter-branch to drop the parents on the first commit you want to
keep, and then drop the old cruft.
Let's say $drop is the hash of the latest commit you want to drop. To
keep things sane and simple, make sure the first commit you want to
keep, ie. the child of $drop, is not a merge commit. Then you can use:
git filter-branch --parent-filter "sed -e 's/-p $drop//'" \
--tag-name-filter cat -- \
--all ^$drop
The above rewrites the parents of all commits that come "after" $drop.
Check the results with gitk.
Then, to clean out all the old cruft.
First, the backup references from filter-branch:
git for-each-ref --format='%(refname)' refs/original | \
while read ref
do
git update-ref -d "$ref"
done
Then clean your reflogs:
git reflog expire --expire=0 --all
And finally, repack and drop all the old unreachable objects:
git repack -ad
git prune # For objects that repack -ad might have left around
At that point, everything leading up to and including $drop should be
gone.
HTH
Björn
^ permalink raw reply
* Re: Re: git rev-list ordering
From: Johannes Schindelin @ 2008-11-17 1:35 UTC (permalink / raw)
To: Ian Hilt; +Cc: sverre, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811162001550.28544@sys-0.hiltweb.site>
Hi,
On Sun, 16 Nov 2008, Ian Hilt wrote:
> On Sun, 16 Nov 2008, Johannes Schindelin wrote:
>
> > On Sat, 15 Nov 2008, Ian Hilt wrote:
> >
> > > On Sat, 15 Nov 2008, Sverre Rabbelier wrote:
> > > > The --reverse is applied after the --max-count, so you are seeing
> > > > the reverse of one commit ;). For comparison, have a look at:
> > > >
> > > > $ git rev-list --reverse --max-count=2
> > >
> > > Ah, I see. So if you didn't want the sorting to take a long time
> > > for many commits, you would limit the output to n commits, then sort
> > > the output. Is this the logic behind this design?
> >
> > Yes. It is by design, since the guy who wrote the initial --reverse
> > support cannot think of an interesting situation where you need to
> > list the oldest n commits.
>
> I see. Well, the situation in which I found this to be needed was while
> trying to figure out how to find the next commit on branch X while on a
> detached head from that branch without counting how many commits back I
> was. In other words,
>
> $ git checkout X~4
> $ # now I want X~3 without using a number or carets
> $ git checkout $(git rev-list --reverse ..X | head -1)
> -- or --
> $ git checkout $(git rev-list ..X | tail -1)
This could break down horribly when there was branching going on.
However, in case you are certain there is only one child of X~4, I'd
suggest doing this:
$ git checkout $(git rev-list --parents --all ^HEAD |
sed -n "s/ .*$(git rev-parse HEAD).*$//p")
IOW I would list all revisions with parents, and filter out all which do
not have the current one as parent.
Hth,
Dscho
^ permalink raw reply
* Re: git-bugzilla
From: Jakub Narebski @ 2008-11-17 1:23 UTC (permalink / raw)
To: Steve Frécinaux; +Cc: git
In-Reply-To: <492089EA.60205@gmail.com>
Steve Frécinaux <nudrema@gmail.com> writes:
> Here is a chunk of code I wrote a few time ago, to post patches to
> bugzilla, modelled mostly after git-format-patch/git-send-email.
>
> You can find it there:
> http://code.istique.net/?p=git-bugzilla.git
>
> It is written in perl and requires WWW::Mechanize.
[...]
Added to http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
Thanks.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git rev-list ordering
From: Ian Hilt @ 2008-11-17 1:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: sverre, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0811162215370.30769@pacific.mpi-cbg.de>
On Sun, 16 Nov 2008, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 15 Nov 2008, Ian Hilt wrote:
>
> > On Sat, 15 Nov 2008, Sverre Rabbelier wrote:
> > > The --reverse is applied after the --max-count, so you are seeing the
> > > reverse of one commit ;). For comparison, have a look at:
> > >
> > > $ git rev-list --reverse --max-count=2
> >
> > Ah, I see. So if you didn't want the sorting to take a long time for
> > many commits, you would limit the output to n commits, then sort the
> > output. Is this the logic behind this design?
>
> Yes. It is by design, since the guy who wrote the initial --reverse
> support cannot think of an interesting situation where you need to list
> the oldest n commits.
I see. Well, the situation in which I found this to be needed was while
trying to figure out how to find the next commit on branch X while on a
detached head from that branch without counting how many commits back I
was. In other words,
$ git checkout X~4
$ # now I want X~3 without using a number or carets
$ git checkout $(git rev-list --reverse ..X | head -1)
-- or --
$ git checkout $(git rev-list ..X | tail -1)
So maybe there's a better way to do this. I don't know. If the commits
were reversed _then_ limited I wouldn't need to use the pipe to
head/tail. Not that that is a problem, it just seemed like it should
work with reverse and max-count.
^ permalink raw reply
* Re: [PATCHv3 2/4] gitweb: git_get_heads_list accepts an optional list of refs.
From: Jakub Narebski @ 2008-11-17 1:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Giuseppe Bilotta, git, Petr Baudis
In-Reply-To: <7vod0f37gr.fsf@gitster.siamese.dyndns.org>
On Sun, 16 Nov 2008, Junio C Hamano wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
> > git_get_heads_list(limit, class1, class2, ...) can now be used to retrieve
> > refs/class1, refs/class2 etc. Defaults to ('heads') or ('heads', 'remotes')
> > depending on the remote_heads option.
> >
> > Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> > ---
> > gitweb/gitweb.perl | 11 +++++++----
> > 1 files changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> > index e1f81f6..0512020 100755
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -2681,15 +2681,18 @@ sub parse_from_to_diffinfo {
> > ## parse to array of hashes functions
> >
> > sub git_get_heads_list {
> > - my $limit = shift;
> > + my ($limit, @class) = @_;
> > + unless (defined @class) {
> > + my $remote_heads = gitweb_check_feature('remote_heads');
> > + @class = ('heads', $remote_heads ? 'remotes' : undef);
> > + }
> > + my @refs = map { "refs/$_" } @class;
>
> Makes sense, except that I'd suggest passing a hash of "refs/$path" =>
> $class as I illustrated in my comments to [1/4], instead of passing a list
> of ("head", "remote"), because that will later allow you to have
> multi-level $path that does not necessarily limited to a $class that is a
> substring of $path, and doing so does not make the code any more complex.
> There is another reason to do so I'll mention in I comment on [3/4].
By the way, with %head_class hash passed as reference git_get_head_list
could be done in such way, that you can write
git_get_heads_list(\%head_class);
instead of longer
git_get_heads_list(undef, \%head_class);
when there is no limit(er).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] gitweb: fixes to gitweb feature check code
From: Jakub Narebski @ 2008-11-17 1:02 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1226759165-6894-1-git-send-email-giuseppe.bilotta@gmail.com>
On Sat, 15 Nov 2008, Giuseppe Bilotta wrote:
> The gitweb_check_feature routine was being used for two different
> purposes: retrieving the actual feature value (such as the list of
> snapshot formats or the list of additional actions), and to check if a
> feature was enabled.
>
> For the latter use, since all features return an array, it led to either
> clumsy code or subtle bugs, with disabled features appearing enabled
> because (0) evaluates to 1.
>
> We fix these bugs, and simplify the code, by separating feature (list)
> value retrieval (gitweb_get_feature) from boolean feature check (i.e.
> retrieving the first/only item in the feature value list). Usage of
> gitweb_check_feature across gitweb is replaced by the appropriate call
> wherever needed.
> ---
First, you forgot the signoff, but you have addressed that already.
Second, I thought at first that it would be good for the patch to also
simplify %feature hash, using "'default' => 1" instead of current bit
convoluted "'default' => [1]", at the cost of bit more code for
defensive programming. But now I think that if it is to be done,
it should be put as separate patch.
--
Jakub Narebski
Poland
^ permalink raw reply
* purging unwanted history
From: Geoff Russell @ 2008-11-17 0:26 UTC (permalink / raw)
To: git
I have a repository with 5 years worth of history, I only want to keep
1 year, so I want to purge the
first 4 years. As it happens, the repository only has a single branch
which should
simplify the problem.
Cheers,
Geoff Russell
P.S. Apologies, but I've asked this question before but didn't get an
answer which
I understood or which worked, so perhaps my description of the problem
was faulty. This
is a second attempt.
^ permalink raw reply
* Re: "secret key not available". "unable to sign the tag".
From: Linus Torvalds @ 2008-11-17 0:16 UTC (permalink / raw)
To: Jeff King; +Cc: Gary Yang, git
In-Reply-To: <20081115035743.GA19633@coredump.intra.peff.net>
On Fri, 14 Nov 2008, Jeff King wrote:
>
> You need to tell git who you are, since it is unable to deduce it from
> doing host lookups. Try:
>
> git config --global user.email garyyang6@yahoo.com
>
> or whatever email address you used when you created the key, and then
> gpg should find it appropriately.
Side note: sometimes you might want to use a different key than the one
you use for authorship. Then you can use
[user]
SigningKey = key
(or "git config user.signingkey xyz" if you don't want to edit the
config file manually).
This can be especially useful if you use different keys for different
projects, even if you want to be known under the same name in both. Or
because you want to have the local hostname in your commit logs, but your
gpg key is using some externally visible "official" email address.
Linus
^ permalink raw reply
* [ANN] codeswarm.rb v1.0
From: Felipe Contreras @ 2008-11-16 23:29 UTC (permalink / raw)
To: Ruby Talk, git list; +Cc: Peter Burns
Hi,
codeswarm.rb is a rewrite of Michael Ogawa's code_swarm in ruby using cairo.
For an example see:
http://www.youtube.com/watch?v=PxjLbj8oT1k
For the original code:
http://code.google.com/p/codeswarm
The format of the events xml file is compatible with code_swarm's one,
and the physics engine is basically the same.
The code is less than 500 lines of code, so it should be fairly hackable.
http://github.com/felipec/codeswarm.rb
Enjoy :)
--
Felipe Contreras
^ permalink raw reply
* Re: [EGIT PATCH 4/7 v3] Handle peeling of loose refs.
From: Shawn O. Pearce @ 2008-11-16 22:37 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1226705099-18066-4-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> For packed refs we got peeling automatically from packed-refs,
> but for loose tags we have to follow the tags and get the leaf
> object in order to comply with the documentation.
I merged your series, but I squashed the following into the patch
I am replying to:
.../src/org/spearce/jgit/lib/Repository.java | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
index 5088150..c953531 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
@@ -942,13 +942,17 @@ public String getBranch() throws IOException {
}
/**
- * Peel a possibly unpeeled ref and updates it. If the ref cannot be peeled
- * the peeled id is set to {@link ObjectId#zeroId()}
+ * Peel a possibly unpeeled ref and updates it.
+ * <p>
+ * If the ref cannot be peeled (as it does not refer to an annotated tag)
+ * the peeled id stays null, but {@link Ref#isPeeled()} will be true.
*
* @param ref
* The ref to peel
- * @return The same, an updated ref with peeled info or a new instance with
- * more information
+ * @return <code>ref</code> if <code>ref.isPeeled()</code> is true; else a
+ * new Ref object representing the same data as Ref, but isPeeled()
+ * will be true and getPeeledObjectId will contain the peeled object
+ * (or null).
*/
public Ref peel(final Ref ref) {
return refs.peel(ref);
--
1.6.0.4.969.g58a38
--
Shawn.
^ permalink raw reply related
* [PATCH v2] gitk: Highlight commit/comment text only if search type is "containing:".
From: Mark Burton @ 2008-11-16 22:18 UTC (permalink / raw)
To: git
Highlighting the text in the commit list and comments that matches the
current find string is useful when the search type is "containing:". When
the search type is "touching paths:" or "adding/removing string:" the
highlight doesn't help so this patch suppresses the highlighting for
those search types.
Signed-off-by: Mark Burton <markb@ordern.com>
---
Patch same as before - just made the commit message a bit clearer.
gitk-git/gitk | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 3353f4a..dea8bc8 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -4302,6 +4302,7 @@ proc askfindhighlight {row id} {
global nhighlights commitinfo iddrawn
global findloc
global markingmatches
+ global gdttype
if {![info exists commitinfo($id)]} {
getcommit $id
@@ -4326,7 +4327,7 @@ proc askfindhighlight {row id} {
bolden_name $row mainfontbold
}
}
- if {$markingmatches} {
+ if {$markingmatches && $gdttype eq [mc "containing:"]} {
markrowmatches $row $id
}
}
@@ -5565,6 +5566,7 @@ proc drawcmitrow {row} {
global filehighlight fhighlights findpattern nhighlights
global hlview vhighlights
global highlight_related rhighlights
+ global gdttype
if {$row >= $numcommits} return
@@ -5595,7 +5597,7 @@ proc drawcmitrow {row} {
set iddrawn($id) 1
incr nrows_drawn
}
- if {$markingmatches} {
+ if {$markingmatches && $gdttype eq [mc "containing:"]} {
markrowmatches $row $id
}
}
@@ -6227,7 +6229,8 @@ proc findselectline {l} {
set markingmatches 1
set findcurline $l
selectline $l 1
- if {$findloc == [mc "All fields"] || $findloc == [mc "Comments"]} {
+ if {$gdttype eq [mc "containing:"] &&
+ ($findloc == [mc "All fields"] || $findloc == [mc "Comments"])} {
# highlight the matches in the comments
set f [$ctext get 1.0 $commentend]
set matches [findmatches $f]
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] Documentation: New GUI configuration and command-line options.
From: Shawn O. Pearce @ 2008-11-16 22:05 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Junio C Hamano, Paul Mackerras
In-Reply-To: <200811132028.49450.angavrilov@gmail.com>
Alexander Gavrilov <angavrilov@gmail.com> wrote:
> Add information on new git-gui and gitk command-line options,
> configuration variables, and the encoding attribute.
>
> Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> Documentation/config.txt | 24 ++++++++++++++++++++++++
> Documentation/git-gui.txt | 19 +++++++++++++++++++
> Documentation/gitattributes.txt | 17 +++++++++++++++++
> Documentation/gitk.txt | 5 +++++
> 4 files changed, 65 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 965ed74..2223dc4 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -796,6 +796,14 @@ gui.diffcontext::
> Specifies how many context lines should be used in calls to diff
> made by the linkgit:git-gui[1]. The default is "5".
>
> +gui.encoding::
> + Specifies the default encoding to use for displaying of
> + file contents in linkgit:git-gui[1] and linkgit:gitk[1].
> + It can be overridden by setting the 'encoding' attribute
> + for relevant files (see linkgit:gitattributes[5]).
> + If this option is not set, the tools default to the
> + locale encoding.
> +
> gui.matchtrackingbranch::
> Determines if new branches created with linkgit:git-gui[1] should
> default to tracking remote branches with matching names or
> @@ -818,6 +826,22 @@ gui.spellingdictionary::
> the linkgit:git-gui[1]. When set to "none" spell checking is turned
> off.
>
> +gui.fastcopyblame::
> + If true, 'git gui blame' uses '-C' instead of '-C -C' for original
> + location detection. It makes blame significantly faster on huge
> + repositories at the expense of less thorough copy detection.
> +
> +gui.copyblamethreshold::
> + Specifies the theshold to use in 'git gui blame' original location
> + detection, measured in alphanumeric characters. See the
> + linkgit:git-blame[1] manual for more information on copy detection.
> +
> +gui.blamehistoryctx::
> + Specifies the radius of history context in days to show in
> + linkgit:gitk[1] for the selected commit, when the `Show History
> + Context` menu item is invoked from 'git gui blame'. If this
> + variable is set to zero, the whole history is shown.
> +
> help.browser::
> Specify the browser that will be used to display help in the
> 'web' format. See linkgit:git-help[1].
> diff --git a/Documentation/git-gui.txt b/Documentation/git-gui.txt
> index 0e650f4..d0bc98b 100644
> --- a/Documentation/git-gui.txt
> +++ b/Documentation/git-gui.txt
> @@ -65,9 +65,28 @@ git gui blame v0.99.8 Makefile::
> example the file is read from the object database and not
> the working directory.
>
> +git gui blame --line=100 Makefile::
> +
> + Loads annotations as described above and automatically
> + scrolls the view to center on line '100'.
> +
> git gui citool::
>
> Make one commit and return to the shell when it is complete.
> + This command returns a non-zero exit code if the window was
> + closed in any way other than by making a commit.
> +
> +git gui citool --amend::
> +
> + Automatically enter the 'Amend Last Commit' mode of
> + the interface.
> +
> +git gui citool --nocommit::
> +
> + Behave as normal citool, but instead of making a commit
> + simply terminate with a zero exit code. It still checks
> + that the index does not contain any unmerged entries, so
> + you can use it as a GUI version of linkgit:git-mergetool[1]
>
> git citool::
>
> diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
> index eb64841..e02899f 100644
> --- a/Documentation/gitattributes.txt
> +++ b/Documentation/gitattributes.txt
> @@ -495,6 +495,23 @@ in the file. E.g. the string `$Format:%H$` will be replaced by the
> commit hash.
>
>
> +Viewing files in GUI tools
> +~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +`encoding`
> +^^^^^^^^^^
> +
> +The value of this attribute specifies the character encoding that should
> +be used by GUI tools (e.g. linkgit:gitk[1] and linkgit:git-gui[1]) to
> +display the contents of the relevant file. Note that due to performance
> +considerations linkgit:gitk[1] does not use this attribute unless you
> +manually enable per-file encodings in its options.
> +
> +If this attribute is not set or has an invalid value, the value of the
> +`gui.encoding` configuration variable is used instead
> +(See linkgit:git-config[1]).
> +
> +
> USING ATTRIBUTE MACROS
> ----------------------
>
> diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
> index ae29a00..317f631 100644
> --- a/Documentation/gitk.txt
> +++ b/Documentation/gitk.txt
> @@ -56,6 +56,11 @@ frequently used options.
> Use this instead of explicitly specifying <revs> if the set of
> commits to show may vary between refreshes.
>
> +--select-commit=<ref>::
> +
> + Automatically select the specified commit after loading the graph.
> + Default behavior is equivalent to specifying '--select-commit=HEAD'.
> +
> <revs>::
>
> Limit the revisions to show. This can be either a single revision
> --
> 1.6.0.3.15.gb8d36
--
Shawn.
^ permalink raw reply
* git-gui translators - 0.12 coming soon
From: Shawn O. Pearce @ 2008-11-16 21:58 UTC (permalink / raw)
To: git
git-gui 0.12 will be coming soon. Some new strings have entered
the project, so I'd like to ask everyone to update their .po with
new translations. I'm freezing new features, so we can focus on
translation activity and bug fixing during the git 1.6.1 rc period.
Thanks!
--
Shawn.
^ permalink raw reply
* Re: [PATCH] gitweb: fixes to gitweb feature check code
From: Giuseppe Bilotta @ 2008-11-16 21:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <7vwsf31ima.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 16, 2008 at 10:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
>> The gitweb_check_feature routine was being used for two different
>> purposes: retrieving the actual feature value (such as the list of
>> snapshot formats or the list of additional actions), and to check if a
>> feature was enabled.
>
>> +# check if a given feature is enabled or not, returning the first (and only)
>> +# value of the feature. Comfort code, allowing the use of
>> +# my $bool_feat = gitweb_check_feature('bool_feat');
>> +# or
>> +# gitweb_check_feature('bool_feat') or somecode;
>> +# instead of
>> +# my ($bool_feat) = gitweb_git_feature('bool_feat');
>> +# or
>> +# (gitweb_check_feature('bool_feat'))[0] or somecode;
>> +# respectively
>
> What's "Comfort code"?
Code that provides comfort? 8-D
> I'd agree that introduction of gitweb_get_feature() may help avoiding
> mistakes at the call sites for Perl illiterates like myself.
>> - my ($use_pathinfo) = gitweb_check_feature('pathinfo');
>> + my $use_pathinfo = gitweb_check_feature('pathinfo');
>
> ... I do not think changes like these are warranted. They have been using
> the function _correctly_ by calling it in the list context and I think
> they will continue to work with your patch.
Because the returned scalar value gets properly promoted to array?
Maybe, but I would say that keeping the () is confusing and
inconsistent. After all, the purpose of the patch is to _eliminate_
(the need for) such constructs.
--
Giuseppe "Oblomov" Bilotta
^ 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