* Re: [PATCH] autodetect number of CPUs by default when using threads
From: Nicolas Pitre @ 2008-12-12 0:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v63lqcptn.fsf@gitster.siamese.dyndns.org>
On Thu, 11 Dec 2008, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > I've spent quite a while wondering why repacking in one repo was faster
> > than repacking in a clone of that repo on the same machine. So let's
> > display how many threads are actually used.
> >
> > We have comprehensive test in Makefile to determine if threads are
> > available, just to not use them by default. I think that code has
> > proven itself for long enough now not to let people benefit from it.
>
> Hmm, it does appear that distros compile with THREADED_DELTA_SEARCH turned
> on (I only checked Fedora and Debian), and I tend to agree with "long
> enough" but "proven itself" feels bit too strong a statement.
>
> I think defaulting to autodetect is a good change. I do not like to add
> new output to stderr deep in -rc, though.
>
> Can we park this in 'next' and move it to 'master' after 1.6.1?
Sure. This is probably best for next.
Nicolas
^ permalink raw reply
* Re: [PATCH v3 3/3] gitweb: Optional grouping of projects by category
From: Sébastien Cevey @ 2008-12-12 0:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano, Petr Baudis, Gustavo Sverzut Barbieri
In-Reply-To: <200812120113.47051.jnareb@gmail.com>
At Fri, 12 Dec 2008 01:13:45 +0100, Jakub Narebski wrote:
> I just tried, it works but we first need to sort @projects by
> category.
>
> I don't understand.
> [...]
> I propose to change it to:
Well in my previous iteration of the patch (v3), the printing of
projects with categories is done using:
foreach my $cat (sort keys %categories) {
So everything was already sorted by category (and then by whichever
property you picked inside each category). You seemed okay with it,
but requested that I documented that behaviour in the commit log.
To maintain the same result with your proposed change (which is what I
submitted in my patch), we need to sort by categories first (AFAIK
Perl sort retains the original order inside equivalence classes of
comparison key?), otherwise splice(projlist, from, to) doesn't return
the expected subset.
--
Sébastien Cevey / inso.cc
^ permalink raw reply
* Re: [PATCH v3] submodule: Allow tracking of the newest revision of a branch in a submodule
From: Lars Hjemli @ 2008-12-12 0:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fabian Franz, git, j.sixt
In-Reply-To: <7vbpvicuk2.fsf@gitster.siamese.dyndns.org>
On Thu, Dec 11, 2008 at 21:42, Junio C Hamano <gitster@pobox.com> wrote:
> I wonder if you can just set "assume unchanged" bit for the subproject
> gitlink in the index to achieve the same goal.
Using assume-unchanged works, in the sense that the modification to
the submodule is not detected in the containing repo. But running `git
submodule update` will checkout the sha1 recorded in HEAD, and I
suspect Fabian wants something like the hypothetical command `git
submodule update -b [branch]` which could do `(cd sub && git fetch &&
git reset --hard origin/$branch)`.
>
> Or is there more to it?
>
Something like this (probably mangled) patch is needed for 'submodule
status' to behave sensibly when the assume-unchanged bit is turned on
for a submodule path.
diff --git a/git-submodule.sh b/git-submodule.sh
index 2f47e06..375dfbf 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -588,21 +588,21 @@ cmd_status()
do
name=$(module_name "$path") || exit
url=$(git config submodule."$name".url)
+ orgsha1=$(git ls-tree HEAD "$path" | cut -d ' ' -f 3 | cut -f 1)
if test -z "$url" || ! test -d "$path"/.git -o -f "$path"/.git
then
say "-$sha1 $path"
continue;
fi
+ if test -z "$cached"
+ then
+ sha1=$(unset GIT_DIR; cd "$path" && git
rev-parse --verify HEAD)
+ fi
set_name_rev "$path" "$sha1"
- if git diff-files --quiet -- "$path"
+ if test "$sha1" = "$orgsha1"
then
say " $sha1 $path$revname"
else
- if test -z "$cached"
- then
- sha1=$(unset GIT_DIR; cd "$path" &&
git rev-parse --verify HEAD)
- set_name_rev "$path" "$sha1"
- fi
say "+$sha1 $path$revname"
fi
done
^ permalink raw reply related
* Re: [PATCH v3] submodule: Allow tracking of the newest revision of a branch in a submodule
From: Fabian Franz @ 2008-12-12 0:21 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: j.sixt, hjemli, git
In-Reply-To: <7vbpvicuk2.fsf@gitster.siamese.dyndns.org>
> Fabian Franz <git@fabian-franz.de> writes:
>
> > Submodules currently only allow tracking a specific revision
> > and each update in a submodule leads to a new commit in the
> > master repository. However some users may want to always track
> > the newest revision of a specific (named) tag or branch or HEAD.
> > For example the user might want to track a staging branch in all
> > submodules.
>
> I initially liked the direction this is going, but I think the above
> rationale and the change to use 0{40} have impedance mismatch. Your
> change is not a good way to go about "some users may want". I'll discuss
> more on this below.
I do agree. I did like the idea of HEAD.gitlink also better and I even more like the assume-unchanged version, which works.
> It seems to me that what you are really after is to let you change the
> state of the subproject checkout in whatever way and have "git commit -a"
> in the superproject ignore that change.
>
> I wonder if you can just set "assume unchanged" bit for the subproject
> gitlink in the index to achieve the same goal.
>
> Or is there more to it?
Nope, that is it. I just did not knew that flag.
> > However I have both cases: Stable development, where I need one special
> > version and "wild" development, where I always want the newest published
> > one.
>
> I do not think supporting both styles of development is a bad idea.
>
> However, use of 0{40} in the index and the resulting commit object in the
> superproject means that this is a project-wide decision, not your personal
> preference. It is not implausible that you would want to do a wild
> expeeriment in your own clone of a project that uses the "Stable
> development" approach (hence the upstream never would want to have 0{40}
> gitlink in its commits).
Yes, but at the same time I might want to record it permanently as a project decision or play at my own with it ...
So both styles should be supported.
> For example, suppose the project uses "Stable development" approach, and
> records the v1.0.0 of submodule at "sub/" in the superproject. You are a
> contributor to that project, and would want to help them futureproof the
> superproject code to be forward compatible with the upcoming v1.2.0
> release of the subproject. What would you do?
>
> * have a clone of superproject, with v1.0.0 submodule bound at "sub/";
>
> * go to "sub/", fetch and checkout v1.2.0-rc2;
>
> * go up, build using the updated submodule, see many failures in
> supermodule build;
>
> * fix them up in a way that can work with both v1.0.0 and v1.2.0 of the
> submodule, while making commits in logical steps, in the supermodule.
>
> And you do not want to record the fact that you used v1.2.0-rc2 of the
> submodule at "sub/" in the commits you make in the supermodule, as you
> would want to label these commits as "futureproof for upcoming submodule
> v1.2.0".
>
> But you cannot use your 0{40} trick, as sending that to the upstream of
> the superproject would break their "Stable development" policy.
>
> I wonder if you can just set "assume unchanged" bit for the subproject
> gitlink in the index to achieve the same goal. That would be a local
> operation, the gitlink would still point at v1.0.0 version of submodule,
> and "git commit -a" in the superproject won't make commits that flips
> everybody else's copy to use v1.2.0-rc2 of submodule.
Yes, that works. I tried it. I am now gonna change the patch to use this new approach and also re-think the workflow I want to support.
> > @@ -118,6 +118,10 @@ update::
> > If the submodule is not yet initialized, and you just want to use the
> > setting as stored in .gitmodules, you can automatically initialize the
> > submodule with the --init option.
> > ++
> > +If you used --track or set the "track" option in .gitmodules this will
> > +automatically pull the newest updates from remote instead of tracking a
> > +specific revision.
>
> "automatically pull" in the sense that it always goes to the remote, fetch
> and merge? That sounds horribly broken. You can never work disconnected?
Uhm, the same is already true for git submodule update. Before it checkouts the new branch it always does a fetch.
However I think what I really want (without) scripting via foreach is:
git checkout staging
In .gitmodules is from a personal (own branch) or project wide decision the fact documented that the submodules do track staging and one stable tag for example.
[module1]
track = staging
[module2]
track = staging
[module3]
track = stable-v1.0.0
And now I just do git submodule update and it fetches and afterwards checks out my local branch of staging and fast-forwards it.
However I do agree that in that workflow you always have to go online and that is not good.
But in my case I also want a developer to just be able to change to
[module1]
track = feature_1
[module2]
track = feature_1
[module3]
track = stable-v1.0.0
to work in a feature branch in two submodules at once.
So I am gonna rethink this design.
> > @@ -159,6 +163,10 @@ OPTIONS
> > --branch::
> > Branch of repository to add as submodule.
> >
> > +-t::
> > +--track::
> > + Branch/Tag/HEAD of repository to track in a submodule.
> > +
>
> How does the branch parameter to the --track option interact with the
> branch parameter to the --branch option? Does an end user typically set
> them to the same branch? Or would these parameters almost always point at
> different branchesof the remote repository? What are the reasons for the
> end user to choose one parameter value for the --branch option and a
> different parameter value for the --track option?
--branch is always checking out just the branch on the initial add and then the branch head is of course recorded as commit in the index.
However I found that option just helpful for creating a first initial commit already in a branch.
For later submodule init or updates this has no effect.
> > diff --git a/git-submodule.sh b/git-submodule.sh
> > index 2f47e06..16df528 100755
> > --- a/git-submodule.sh
> > +++ b/git-submodule.sh
> > ...
> > @@ -197,12 +203,14 @@ cmd_add()
> > (unset GIT_DIR; cd "$path" && git checkout -f -q ${branch:+-b
> "$branch" "origin/$branch"}) ||
> > die "Unable to checkout submodule '$path'"
> > fi
> > + test -n "$track" && printf '160000
> 0000000000000000000000000000000000000000\t%s\n' "$path" | git update-index --index-info
> >
>
> You have many overlong lines due to the 0{40} constant string in your
> patch. Have a
>
> null_sha1=0000000000000000000000000000000000000000
>
> at the beginning of the script, and rewrite the above like this:
>
> test -n "$track" &&
> printf '160000 %s\t%s\n' "$null_sha1" "$path" |
> git update-index --index-info
>
> or even like this:
>
> if test -n "$track"
> then
> printf '160000 %s\t%s\n' "$null_sha1" "$path" |
> git update-index --index-info
> fi
>
> Use of $null_sha1 throughout the script will make things easier to read
> and at the same time make it less error prone as well for "git submodule"
> developers.
Okay, thanks that is a good practice.
> > @@ -345,11 +357,29 @@ cmd_update()
> > then
> > force="-f"
> > fi
> > + pull=
> > + if [ "$sha1" = "0000000000000000000000000000000000000000" ]
> > + then
> > + track=$(git config submodule."$name".track)
> > + : ${track:="master"}
>
> In the v2 patch this used to point at "HEAD". What made you change your
> mind?
Because at the moment HEAD would be created as local branhc, which is horribly broken.
> > + # if the local branch does not yet exist, create it
> > + ( unset GIT_DIR; cd "$path"; git-show-ref --heads --tags -q
> "$track" || git branch --track "$track" "origin/$track" )
>
> No error checking?
>
> (
> unset GIT_DIR;
> cd "$path" &&
> git show-ref --heads --tags -q "$track" ||
> git branch --track "$track" "origin/$track"
> ) || barf
>
> The ';' after unset is intentional; some shells reports failure when you
> unset an unset variable.
Okay, thanks. I didn't know that.
>
> > + sha1="$track"
> > + pull=1
>
> I tend to prefer booleans in shell scripts spelled like boolean, e.g.
>
> pull=yes
Good idea.
>
> > + fi
> > +
> > (unset GIT_DIR; cd "$path" && git-fetch &&
> > git-checkout $force -q "$sha1") ||
> > die "Unable to checkout '$sha1' in submodule path '$path'"
> >
> > say "Submodule path '$path': checked out '$sha1'"
> > +
> > + if [ "$pull" = "1" ]
> > + then
> > + # Now pull new updates from origin
> > + ( unset GIT_DIR; cd "$path"; git-pull ) || die "Unable to pull in
> submodule path '$path'"
>
> No error checking?
In v3 there should be ... And I even see error checking in the above ...
>
> > + fi
> > +
> > fi
> > done
> > }
> > @@ -596,7 +626,8 @@ cmd_status()
> > set_name_rev "$path" "$sha1"
> > if git diff-files --quiet -- "$path"
> > then
> > - say " $sha1 $path$revname"
> > + track=$(git config submodule."$name".track)
> > + say " $sha1 $path$revname${track:+ (tracking "$track")}"
> > else
> > if test -z "$cached"
> > then
> > diff --git a/read-cache.c b/read-cache.c
> > index 8579663..0c14b68 100644
> > --- a/read-cache.c
> > +++ b/read-cache.c
> > @@ -137,6 +137,11 @@ static int ce_compare_gitlink(struct cache_entry
> *ce)
> > */
> > if (resolve_gitlink_ref(ce->name, "HEAD", sha1) < 0)
> > return 0;
> > +
> > + // To be able to track newest revision
> > + if (is_null_sha1(ce->sha1))
> > + return 0;
> > +
>
> I think the comment is wrong, as it is not about newness at all.
>
> /* ignore changes in the submodule path */
>
> would be more appropriate.
Yes, I do agree. I am now changing first to --assume-unchanged so this is made unnecessary.
I'll write a PATCH/RFC next.
Thank you for your detailed feedback,
Best Wishes,
Fabian
^ permalink raw reply
* Re: [PATCH v3 3/3] gitweb: Optional grouping of projects by category
From: Jakub Narebski @ 2008-12-12 0:13 UTC (permalink / raw)
To: Sébastien Cevey
Cc: git, Junio C Hamano, Petr Baudis, Gustavo Sverzut Barbieri
In-Reply-To: <878wqmz3pl.wl%seb@cine7.net>
On Fri, 12 Dec 2008, Sébastien Cevey wrote:
> At Fri, 5 Dec 2008 11:45:08 +0100, Jakub Narebski wrote:
>
>>>> Nice... but perhaps it would be better to simply pass $from / $to to
>>>> build_projlist_by_category function, and have in %categories only
>>>> projects which are shown...
>>>
>>> Ah you're right, we could do that, I hadn't thought of it. Sounds
>>> cleaner than the $from/$to dance I did in this patch.
>>
>> [...] we can simply pass $from and $to to
>> build_projlist_by_category(), and use loop $from..$to there.
>
> I just tried, it works but we first need to sort @projects by
> category.
I don't understand. You have the following code:
+# returns a hash of categories, containing the list of project
+# belonging to each category
+sub build_projlist_by_category {
+ my $projlist = shift;
+ my %categories;
+
+ for my $pr (@$projlist) {
+ push @{$categories{ $pr->{'category'} }}, $pr;
+ }
+
+ return %categories;
+}
I propose to change it to:
+# returns a hash of categories, containing the list of project
+# belonging to each category
+sub build_projlist_by_category {
+ my ($projlist, $from, $to) = shift; # <<<<<<<<<<<<<<<<<<<<<<<
+ $from = 0 unless defined $from; # +++++++++++++++++++++++
+ $to = $#$projlist if (!defined $to || $#$projlist < $to); # +++++++++++++++++++++++
+ my %categories;
+
+ for (my $i = $from; $i <= $to; $i++) { # <<<<<<<<<<<<<<<<<<<<<<<
+ $pr = $projlist->[$i]; # +++++++++++++++++++++++
+ push @{$categories{ $pr->{'category'} }}, $pr;
+ }
+
+ return %categories;
+}
And of course update callers to pass $from and $to parameters.
This code doesn't change _anything_ beside the fact that it can operate
only on part of @$projlist.
But as you have noticed some kinds of limiting shown project list size
make sense only if done _after_ dividing into categories. Some but not
all. For example page length limiting after sorting by name,
description, owner or age (sorting which takes place before dividing
into categories) makes sense if it is done _before_ categorization:
we want to show e.g. 100 freshest projects, and not up to 100 projects
from first categories, with last category showing maybe only freshest
projects in this category.
Besides making selection of projects to show operate on list of projects
instead of being done just before display is IMHO better, more flexible,
and more robust solution.
> I'm gonna re-send the three patches as a new version.
Thanks in advance.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Clarifying "invalid tag signature file" error message from git filter-branch (and others)
From: James Youngman @ 2008-12-11 23:59 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, Jim Meyering
In-Reply-To: <LhfS_uc2B_Gje7rXd1882RMsQfSRjOEsBT24Z1Yza_bWhgl9lI-ZhQ@cipher.nrlssc.navy.mil>
On Thu, Dec 11, 2008 at 11:13 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>> Before conversion:
>> $ git cat-file tag FINDUTILS-4_1-10
>> object ce25eb352de8dc53a9a7805ba9efc1c9215d28c2
>> type commit
>> tag FINDUTILS-4_1-10
>> tagger Kevin Dalley
>
> The tagger field is missing an email address, a timestamp, and a timezone. It
> should look something like:
>
> tagger Kevin Dalley <kevin.dalley@somewhere.com> 1229036026 -0800
>
> git-mktag prevents improperly formatted tags from being created by checking
> that these fields exist and are well formed.
>
> If you know the correct values for the missing fields, then you could
Yes for the email address. But as for the timestamp, it's not in
the tag file; that only contains the sha1.
There is a timestamp in the object being tagged, is that the timestamp
you are talking about?
$ git show --pretty=raw ce25eb352de8dc53a9a7805ba9efc1c9215d28c2
commit ce25eb352de8dc53a9a7805ba9efc1c9215d28c2
tree 752cca144d39bc55d05fbe304752b274ba22641c
parent 9a998755249b0c8c47e8657cff712fa506aa30fc
author Kevin Dalley <kevin@seti.org> 830638152 +0000
committer Kevin Dalley <kevin@seti.org> 830638152 +0000
*** empty log message ***
diff --git a/debian.Changelog b/debian.Changelog
index e3541eb..d0cd295 100644
--- a/debian.Changelog
+++ b/debian.Changelog
@@ -1,5 +1,7 @@
Sat Apr 27 12:29:06 1996 Kevin Dalley
<kevin@aplysia.iway.aimnet.com (Kevin Dalley)>
+ * find.info, find.info-1, find.info-2: updated to match find.texi
+
* debian.rules (debian): update debian revision to 10
* getline.c (getstr): verify that nchars_avail is *really* greater
> recreate the tags before doing the filter-branch. If they are unknown, it
> seems valid enough to use the values from the commit that the tag points
> to.
>
> i.e.
>
> tagger Kevin Dalley <kevin@seti.org> 830638152 -0000
>
> What tool was used to convert this repository to git? It should be corrected
> to produce valid annotated tags. Especially if it is a tool within git.
I don't know, Jim Meyering will know though, so I CC'ed him.
> The tag below was actually not converted. filter-branch bailed
> out during the conversion and so left it alone.
I see.
Thanks,
James.
^ permalink raw reply related
* git log --numstat disagrees with git apply --numstat
From: Shawn O. Pearce @ 2008-12-11 23:53 UTC (permalink / raw)
To: git
I've found a case where git apply --numstat and git log --numstat
produce different results for the same commit.
In egit (git://repo.or.cz/egit.git/):
$ git log --numstat -1 --pretty=o 9bda5ece6806cd797416eaa47c
9bda5ece6806cd797416eaa47c7b927cc6e9c3b2 Teach RevWalk about ...
8 0 org.spearce.jgit/src/org/spearce/jgit/revwalk/DateRevQueue.java
69 13 org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java
$ git log -p -1 --pretty=o 9bda5ece6806cd797416eaa47c | git apply --numstat
8 0 org.spearce.jgit/src/org/spearce/jgit/revwalk/DateRevQueue.java
68 12 org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java
I found this because I was writing a unit test for JGit that ran
through the JGit project history and compared the output of git
log --numstat against the output of JGit's "git apply --numstat"
implementation, after scraping the "git log -p" output.
I can't quite figure out why log --numstat is coming up with a +1
difference here for both added and removed, but it is. I haven't
dug into the Git code yet to figure out why. FWIW, JGit produces
the same result as "git apply --numstat" (the 68/12).
At this point JGit was able to successfully read and match 715 of
1211 commits before it found this difference, so its also somewhat
rare to occur I think...
--
Shawn.
^ permalink raw reply
* [PATCH v4 3/3] gitweb: Optional grouping of projects by category
From: Sebastien Cevey @ 2008-12-11 23:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Petr Baudis, Gustavo Sverzut Barbieri, seb
In-Reply-To: <874p1az3b1.wl%seb@cine7.net>
This adds the $projects_list_group_categories option which, if enabled,
will result in grouping projects by category on the project list page.
The category is specified for each project by the $GIT_DIR/category file
or the 'category' variable in its configuration file. By default, projects
are put in the $project_list_default_category category.
Note:
- Categories are always sorted alphabetically, with projects in
each category sorted according to the globally selected $order.
- When displaying a subset of all the projects (page limiting), the
category headers are only displayed for projects present on the page.
The feature is inspired from Sham Chukoury's patch for the XMMS2
gitweb, but has been rewritten for the current gitweb development
HEAD. The CSS for categories is inspired from Gustavo Sverzut Barbieri's
patch to group projects by path.
Thanks to Florian Ragwitz for Perl tips.
Signed-off-by: Sebastien Cevey <seb@cine7.net>
---
Simplified the patch according to Jakub's suggestion to filter
$from/$to for categories in build_projlist_by_category (requires
@projects to be sorted by category behorehand).
gitweb/README | 16 +++++++++++++
gitweb/gitweb.css | 7 ++++++
gitweb/gitweb.perl | 60 +++++++++++++++++++++++++++++++++++++++++++++++++--
3 files changed, 80 insertions(+), 3 deletions(-)
diff --git a/gitweb/README b/gitweb/README
index 825162a..f8f8872 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -188,6 +188,15 @@ not include variables usually directly set during build):
full description is available as 'title' attribute (usually shown on
mouseover). By default set to 25, which might be too small if you
use long project descriptions.
+ * $projects_list_group_categories
+ Enables the grouping of projects by category on the project list page.
+ The category of a project is determined by the $GIT_DIR/category
+ file or the 'gitweb.category' variable in its repository configuration.
+ Disabled by default.
+ * $project_list_default_category
+ Default category for projects for which none is specified. If set
+ to the empty string, such projects will remain uncategorized and
+ listed at the top, above categorized projects.
* @git_base_url_list
List of git base URLs used for URL to where fetch project from, shown
in project summary page. Full URL is "$git_base_url/$project".
@@ -269,6 +278,13 @@ You can use the following files in repository:
from the template during repository creation. You can use the
gitweb.description repo configuration variable, but the file takes
precedence.
+ * category (or gitweb.category)
+ Singe line category of a project, used to group projects if
+ $projects_list_group_categories is enabled. By default (file and
+ configuration variable absent), uncategorized projects are put in
+ the $project_list_default_category category. You can use the
+ gitweb.category repo configuration variable, but the file takes
+ precedence.
* cloneurl (or multiple-valued gitweb.url)
File with repository URL (used for clone and fetch), one per line.
Displayed in the project summary page. You can use multiple-valued
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index a01eac8..64f2a41 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -264,6 +264,13 @@ td.current_head {
text-decoration: underline;
}
+td.category {
+ background-color: #d9d8d1;
+ border-top: 1px solid #000000;
+ border-left: 1px solid #000000;
+ font-weight: bold;
+}
+
table.diff_tree span.file_status.new {
color: #008000;
}
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index a4bf874..3a58e3d 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -87,6 +87,14 @@ our $projects_list = "++GITWEB_LIST++";
# the width (in characters) of the projects list "Description" column
our $projects_list_description_width = 25;
+# group projects by category on the projects list
+# (enabled if this variable evaluates to true)
+our $projects_list_group_categories = 0;
+
+# default category if none specified
+# (leave the empty string for no category)
+our $project_list_default_category = "";
+
# default order of projects list
# valid values are none, project, descr, owner, and age
our $default_projects_order = "project";
@@ -2042,6 +2050,11 @@ sub git_get_project_description {
return git_get_file_or_project_config('description', $path);
}
+sub git_get_project_category {
+ my $path = shift;
+ return git_get_file_or_project_config('category', $path);
+}
+
sub git_get_project_ctags {
my $path = shift;
my $ctags = {};
@@ -3939,8 +3952,9 @@ sub git_patchset_body {
# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-# fills project list info (age, description, owner, forks) for each
-# project in the list, removing invalid projects from returned list
+# fills project list info (age, description, owner, category, forks)
+# for each project in the list, removing invalid projects from
+# returned list
# NOTE: modifies $projlist, but does not remove entries from it
sub fill_project_list_info {
my ($projlist, $check_forks) = @_;
@@ -3963,6 +3977,11 @@ sub fill_project_list_info {
if (!defined $pr->{'owner'}) {
$pr->{'owner'} = git_get_project_owner("$pr->{'path'}") || "";
}
+ if ($projects_list_group_categories && !defined $pr->{'category'}) {
+ my $cat = git_get_project_category($pr->{'path'}) ||
+ $project_list_default_category;
+ $pr->{'category'} = to_utf8($cat);
+ }
if ($check_forks) {
my $pname = $pr->{'path'};
if (($pname =~ s/\.git$//) &&
@@ -3980,6 +3999,23 @@ sub fill_project_list_info {
return @projects;
}
+# returns a hash of categories, containing the list of project
+# belonging to each category
+sub build_projlist_by_category {
+ my ($projlist, $from, $to) = @_;
+ my %categories;
+
+ $from = 0 unless defined $from;
+ $to = $#$projlist if (!defined $to || $#$projlist < $to);
+
+ for my $i ($from .. $to) {
+ my $pr = $projlist->[$i];
+ push @{$categories{ $pr->{'category'} }}, $pr;
+ }
+
+ return %categories;
+}
+
# print 'sort by' <th> element, generating 'sort by $name' replay link
# if that order is not selected
sub print_sort_th {
@@ -4101,7 +4137,25 @@ sub git_project_list_body {
"</tr>\n";
}
- print_project_rows(\@projects, $from, $to, $check_forks, $show_ctags);
+ if ($projects_list_group_categories) {
+ # only display categories with projects in the $from-$to window
+ @projects = sort {$a->{'category'} cmp $b->{'category'}} @projects;
+ my %categories = build_projlist_by_category(\@projects, $from, $to);
+ foreach my $cat (sort keys %categories) {
+ unless ($cat eq "") {
+ print "<tr>\n";
+ if ($check_forks) {
+ print "<td></td>\n";
+ }
+ print "<td class=\"category\" colspan=\"5\">$cat</td>\n";
+ print "</tr>\n";
+ }
+
+ print_project_rows($categories{$cat}, undef, undef, $check_forks, $show_ctags);
+ }
+ } else {
+ print_project_rows(\@projects, $from, $to, $check_forks, $show_ctags);
+ }
if (defined $extra) {
print "<tr>\n";
--
1.5.6.5
^ permalink raw reply related
* [PATCH v4 2/3] gitweb: Split git_project_list_body in two functions
From: Sebastien Cevey @ 2008-12-11 23:42 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Petr Baudis, Gustavo Sverzut Barbieri, seb
In-Reply-To: <8763lqz3dr.wl%seb@cine7.net>
Extract the printing of project rows on the project page into a
separate print_project_rows function. This makes it easier to reuse
the code to print different subsets of the whole project list.
The row printing code is merely moved into a separate function, but
note that $projects is passed as a reference now.
Signed-off-by: Sebastien Cevey <seb@cine7.net>
---
Fixed the patch to apply cleanly on the current HEAD.
gitweb/gitweb.perl | 103 +++++++++++++++++++++++++++++-----------------------
1 files changed, 57 insertions(+), 46 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index f7dc337..a4bf874 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3996,59 +3996,19 @@ sub print_sort_th {
}
}
-sub git_project_list_body {
+# print a row for each project in the given list, using the given
+# range and extra display options
+sub print_project_rows {
# actually uses global variable $project
- my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
-
- my $check_forks = gitweb_check_feature('forks');
- my @projects = fill_project_list_info($projlist, $check_forks);
+ my ($projects, $from, $to, $check_forks, $show_ctags) = @_;
- $order ||= $default_projects_order;
$from = 0 unless defined $from;
- $to = $#projects if (!defined $to || $#projects < $to);
-
- my %order_info = (
- project => { key => 'path', type => 'str' },
- descr => { key => 'descr_long', type => 'str' },
- owner => { key => 'owner', type => 'str' },
- age => { key => 'age', type => 'num' }
- );
- my $oi = $order_info{$order};
- if ($oi->{'type'} eq 'str') {
- @projects = sort {$a->{$oi->{'key'}} cmp $b->{$oi->{'key'}}} @projects;
- } else {
- @projects = sort {$a->{$oi->{'key'}} <=> $b->{$oi->{'key'}}} @projects;
- }
+ $to = $#$projects if (!defined $to || $#$projects < $to);
- my $show_ctags = gitweb_check_feature('ctags');
- if ($show_ctags) {
- my %ctags;
- foreach my $p (@projects) {
- foreach my $ct (keys %{$p->{'ctags'}}) {
- $ctags{$ct} += $p->{'ctags'}->{$ct};
- }
- }
- my $cloud = git_populate_project_tagcloud(\%ctags);
- print git_show_project_tagcloud($cloud, 64);
- }
-
- print "<table class=\"project_list\">\n";
- unless ($no_header) {
- print "<tr>\n";
- if ($check_forks) {
- print "<th></th>\n";
- }
- print_sort_th('project', $order, 'Project');
- print_sort_th('descr', $order, 'Description');
- print_sort_th('owner', $order, 'Owner');
- print_sort_th('age', $order, 'Last Change');
- print "<th></th>\n" . # for links
- "</tr>\n";
- }
my $alternate = 1;
my $tagfilter = $cgi->param('by_tag');
for (my $i = $from; $i <= $to; $i++) {
- my $pr = $projects[$i];
+ my $pr = $projects->[$i];
next if $tagfilter and $show_ctags and not grep { lc $_ eq lc $tagfilter } keys %{$pr->{'ctags'}};
next if $searchtext and not $pr->{'path'} =~ /$searchtext/
@@ -4092,6 +4052,57 @@ sub git_project_list_body {
"</td>\n" .
"</tr>\n";
}
+}
+
+sub git_project_list_body {
+ my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
+
+ my ($check_forks) = gitweb_check_feature('forks');
+ my @projects = fill_project_list_info($projlist, $check_forks);
+
+ $order ||= $default_projects_order;
+
+ my %order_info = (
+ project => { key => 'path', type => 'str' },
+ descr => { key => 'descr_long', type => 'str' },
+ owner => { key => 'owner', type => 'str' },
+ age => { key => 'age', type => 'num' }
+ );
+ my $oi = $order_info{$order};
+ if ($oi->{'type'} eq 'str') {
+ @projects = sort {$a->{$oi->{'key'}} cmp $b->{$oi->{'key'}}} @projects;
+ } else {
+ @projects = sort {$a->{$oi->{'key'}} <=> $b->{$oi->{'key'}}} @projects;
+ }
+
+ my $show_ctags = gitweb_check_feature('ctags');
+ if ($show_ctags) {
+ my %ctags;
+ foreach my $p (@projects) {
+ foreach my $ct (keys %{$p->{'ctags'}}) {
+ $ctags{$ct} += $p->{'ctags'}->{$ct};
+ }
+ }
+ my $cloud = git_populate_project_tagcloud(\%ctags);
+ print git_show_project_tagcloud($cloud, 64);
+ }
+
+ print "<table class=\"project_list\">\n";
+ unless ($no_header) {
+ print "<tr>\n";
+ if ($check_forks) {
+ print "<th></th>\n";
+ }
+ print_sort_th('project', $order, 'Project');
+ print_sort_th('descr', $order, 'Description');
+ print_sort_th('owner', $order, 'Owner');
+ print_sort_th('age', $order, 'Last Change');
+ print "<th></th>\n" . # for links
+ "</tr>\n";
+ }
+
+ print_project_rows(\@projects, $from, $to, $check_forks, $show_ctags);
+
if (defined $extra) {
print "<tr>\n";
if ($check_forks) {
--
1.5.6.5
^ permalink raw reply related
* [PATCH v4 1/3] gitweb: Modularized git_get_project_description to be more generic
From: Sebastien Cevey @ 2008-12-11 23:41 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Petr Baudis, Gustavo Sverzut Barbieri, seb
Introduce a git_get_file_or_project_config utility function to
retrieve a repository variable either from a plain text file in the
$GIT_DIR or else from 'gitweb.$variable' in the repository config
(e.g. 'description').
Signed-off-by: Sebastien Cevey <seb@cine7.net>
---
Sorry, screwed up the previous email trying to keep that From line in
the header..
This patch (1/3) is still identical to previous version (v3).
gitweb/gitweb.perl | 24 ++++++++++++++++--------
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6eb370d..f7dc337 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2020,18 +2020,26 @@ sub git_get_path_by_hash {
## ......................................................................
## git utility functions, directly accessing git repository
-sub git_get_project_description {
- my $path = shift;
+# get the value of a config variable either from a file with the same
+# name in the repository, or the gitweb.$name value in the repository
+# config file.
+sub git_get_file_or_project_config {
+ my ($name, $path) = @_;
$git_dir = "$projectroot/$path";
- open my $fd, "$git_dir/description"
- or return git_get_project_config('description');
- my $descr = <$fd>;
+ open my $fd, "$git_dir/$name"
+ or return git_get_project_config($name);
+ my $conf = <$fd>;
close $fd;
- if (defined $descr) {
- chomp $descr;
+ if (defined $conf) {
+ chomp $conf;
}
- return $descr;
+ return $conf;
+}
+
+sub git_get_project_description {
+ my $path = shift;
+ return git_get_file_or_project_config('description', $path);
}
sub git_get_project_ctags {
--
1.5.6.5
^ permalink raw reply related
* Re: [RFC] cgit in git?
From: Lars Hjemli @ 2008-12-11 23:37 UTC (permalink / raw)
To: Junio C Hamano, Seth Vidal; +Cc: Git Mailing List
In-Reply-To: <7vwse6bart.fsf@gitster.siamese.dyndns.org>
On Thu, Dec 11, 2008 at 23:35, Junio C Hamano <gitster@pobox.com> wrote:
> "Lars Hjemli" <hjemli@gmail.com> writes:
>
>> 2) the cgit release tarballs includes the needed git sources
>>
>> Option 2 is doable but still requires the fedora project to support
>> two git packages (but now the 'git-for-cgit' package is hidden inside
>> the cgit source tree). The good thing about this option is that it
>> only requires some minor modifications to the cgit releases.
>
> I do not understand why this is any extra work for fedora.
I imagined that it could have a ripple-effect on package dependencies,
i.e. the git release used by cgit could have subtle
'incompatibilities' with the real git package, but I really don't know
the first thing about packaging so this is just a guess.
> Instead of
> running "make get-git" and then running your build procedure, they need to
> just run your build procedure because you now ship your source with the
> matching version of the git source, which sounds like the right thing to
> me. You do not install anything from the contained git.git area (we do
> not do shared objects, nor public header files) to the end product, right?
Right.
> Doesn't cgit bind git.git as a subproject at the source level? I would
> expect that the most natural release tarball for such a project would be a
> single tarball that has both the superproject itself _and_ the submodules
> it contains already extracted, iow, the state of your tree after you run
> "make get-git".
Your expectation makes sense to me, thanks for elaborating.
Seth: would such a self-contained tarball solve the problems on your end?
--
larsh
^ permalink raw reply
* Re: [PATCH v3 3/3] gitweb: Optional grouping of projects by category
From: Sébastien Cevey @ 2008-12-11 23:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano, Petr Baudis, Gustavo Sverzut Barbieri
In-Reply-To: <200812051145.09732.jnareb@gmail.com>
At Fri, 5 Dec 2008 11:45:08 +0100, Jakub Narebski wrote:
> > > Nice... but perhaps it would be better to simply pass $from / $to to
> > > build_projlist_by_category function, and have in %categories only
> > > projects which are shown...
> >
> > Ah you're right, we could do that, I hadn't thought of it. Sounds
> > cleaner than the $from/$to dance I did in this patch.
>
> [...] we can simply pass $from and $to to
> build_projlist_by_category(), and use loop $from..$to there.
I just tried, it works but we first need to sort @projects by
category.
> Somehow I couldn't apply second patch in series:
>
> $ git am -3 -u "[PATCH v3 2_3] gitweb: Split git_project_list_body in two functions.txt"
> Applying: gitweb: Split git_project_list_body in two functions
> error: patch failed: gitweb/gitweb.perl:3972
> error: gitweb/gitweb.perl: patch does not apply
> fatal: sha1 information is lacking or useless (gitweb/gitweb.perl).
> Repository lacks necessary blobs to fall back on 3-way merge.
> Cannot fall back to three-way merge.
> Patch failed at 0001.
Where does it find the reference to the "necessary blobs"? Could it
be because I didn't leave the From OBJECTID DATE line in my email
header?
Seems like there was a recent change on the line
my $check_forks = gitweb_check_feature('forks');
so I had to update my patch to apply cleanly on the current master
HEAD.
I'm gonna re-send the three patches as a new version.
--
Sébastien Cevey / inso.cc
^ permalink raw reply
* Re: Clarifying "invalid tag signature file" error message from git filter-branch (and others)
From: Brandon Casey @ 2008-12-11 23:13 UTC (permalink / raw)
To: James Youngman; +Cc: git
In-Reply-To: <c5df85930812111434m879f1faq80c64286714c3a1f@mail.gmail.com>
James Youngman wrote:
> On Thu, Dec 11, 2008 at 9:06 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>> James Youngman wrote:
>>> What do the errors "error: char88: malformed tagger field" and "fatal:
>>> invalid tag signature file" and "Could not create new tag object for
>>> FINDUTILS-4_1-10" signify in the session below?
>> It means the tagger field in the tag does not follow the correct form.
>> Specifically the testing in git-mktag (called by filter-branch) does:
>>
>> * Check for correct form for name and email
>> * i.e. " <" followed by "> " on _this_ line
>> * No angle brackets within the name or email address fields.
>> * No spaces within the email address field.
>>
>> What does 'git cat-file tag FINDUTILS-4_1-10' show you?
>
> Before conversion:
> $ git cat-file tag FINDUTILS-4_1-10
> object ce25eb352de8dc53a9a7805ba9efc1c9215d28c2
> type commit
> tag FINDUTILS-4_1-10
> tagger Kevin Dalley
The tagger field is missing an email address, a timestamp, and a timezone. It
should look something like:
tagger Kevin Dalley <kevin.dalley@somewhere.com> 1229036026 -0800
git-mktag prevents improperly formatted tags from being created by checking
that these fields exist and are well formed.
If you know the correct values for the missing fields, then you could
recreate the tags before doing the filter-branch. If they are unknown, it
seems valid enough to use the values from the commit that the tag points
to.
i.e.
tagger Kevin Dalley <kevin@seti.org> 830638152 -0000
What tool was used to convert this repository to git? It should be corrected
to produce valid annotated tags. Especially if it is a tool within git.
The tag below was actually not converted. filter-branch bailed
out during the conversion and so left it alone.
> The conversion:
>
> After conversion:
> $ git cat-file tag FINDUTILS-4_1-10
> object ce25eb352de8dc53a9a7805ba9efc1c9215d28c2
> type commit
> tag FINDUTILS-4_1-10
> tagger Kevin Dalley
>
> This is in the repo at
> http://git.savannah.gnu.org/gitweb/?p=findutils.git;a=commit;h=ce25eb352de8dc53a9a7805ba9efc1c9215d28c2
-brandon
^ permalink raw reply
* Re: fatal output from git-show really wants a terminal
From: Junio C Hamano @ 2008-12-11 23:03 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Jeff King, Johannes Schindelin, git
In-Reply-To: <200812111645.10067.bss03@volumehost.net>
"Boyd Stephen Smith Jr." <bss03@volumehost.net> writes:
>> $ git log >foo.out
>>
>>and start a pager, which makes no sense.
>
> Good point, I'll try and consider that while I investgate the history of the
> issue.
Isn't the issue about 61b8050 (sending errors to stdout under $PAGER,
2008-02-16)? With that commit, we changed things so that when we send the
standard output to the $PAGER, we dup stderr to the $PAGER as well,
because otherwise any output to stderr will be wiped out by whatever the
pager does and the user will not notice the breakage. E.g.
$ git log
will just show reams of output, and you won't see any errors and warnings
even if there were any encountered during the process.
Unfortunately we did it unconditionally. There is no reason to dup stderr
to the $PAGER if the command line was:
$ git log 2>error.log
in which case you would want to view the normal output in your $PAGER and
you are keeping the log of the error output in a separate file.
^ permalink raw reply
* Re: fatal output from git-show really wants a terminal
From: Jeff King @ 2008-12-11 22:59 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Johannes Schindelin, git
In-Reply-To: <200812111645.10067.bss03@volumehost.net>
On Thu, Dec 11, 2008 at 04:45:05PM -0600, Boyd Stephen Smith Jr. wrote:
> I did see a commit message mentioning some unusual settings for PAGER, but in
> general, pagers are interactive. I'd think the default behavior would
> be "interactive <-> pager", with a config option to turn the pager always off
> or always on. From there, I would reason the test for interactivity should
> be the POSIX test.
Right, but then that leads to the case I mentioned before. I think you
want to say "this is interactive _and_ our stdout is going to the
interactive spot". Which by your definition would be isatty() on stdin,
stderr, and stdout.
And maybe that is a better test, but I think it would be helpful to
provide a concrete example where that behavior works and the current
behavior doesn't.
> It looks like this test have have been attempting to follow the behavior
> of --color=auto to GNU less and GNU grep (and possibly others). This
> certainly makes some sense as well, and may be less surprising.
Yes. You'll see we use a similar test for git's "auto" color.
> >And FWIW, I don't recall this ever being discussed before, but then I
> >have not been involved with git since the very beginning.
>
> Google should be able to find it. And worst-case, I can tell wget to spider
> the archives and then run some sort of find/html2txt/grep on them.
I have the complete archive, and I couldn't find anything useful. ;)
Let me know if you want a copy (or you can pull it straight from gmane,
but it is somewhat slow IIRC).
-Peff
^ permalink raw reply
* Re: fatal output from git-show really wants a terminal
From: Boyd Stephen Smith Jr. @ 2008-12-11 22:45 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20081211215554.GA11565@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 2328 bytes --]
On Thursday 2008 December 11 15:55:55 Jeff King wrote:
>On Thu, Dec 11, 2008 at 10:51:15AM -0600, Boyd Stephen Smith Jr. wrote:
>> Initially, I was looking for 'stdout' or 'stderr', and found many
>> unrelated commits. I then figured it was part of the PAGER support, and
>> began
>
>Try looking for isatty, which takes the numeric fd. I think the behavior
>you asked about would be this:
Thanks, this will be plenty of context for me to be able to crawl the archives
and the actual history thinking about better behavior and considering old
discussions.
>We are not talking about
>interactivity, but rather about where the output is going. So your test
>would consider this interactive:
>
> $ git log >foo.out
>
>and start a pager, which makes no sense.
Good point, I'll try and consider that while I investgate the history of the
issue.
>Now if you proposed checking stderr and stdin _in addition_ to stdout,
>that might make more sense, but I haven't thought too hard about any
>implications.
I did see a commit message mentioning some unusual settings for PAGER, but in
general, pagers are interactive. I'd think the default behavior would
be "interactive <-> pager", with a config option to turn the pager always off
or always on. From there, I would reason the test for interactivity should
be the POSIX test.
It looks like this test have have been attempting to follow the behavior
of --color=auto to GNU less and GNU grep (and possibly others). This
certainly makes some sense as well, and may be less surprising.
>And FWIW, I don't recall this ever being discussed before, but then I
>have not been involved with git since the very beginning.
Google should be able to find it. And worst-case, I can tell wget to spider
the archives and then run some sort of find/html2txt/grep on them.
I'll go back to "the stacks" and read the discussions and commits. If my
well-informed self still thinks the behavior should change, I'll write a
patch and open up the discussion again.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss03@volumehost.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.org/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC] cgit in git?
From: Johan Herland @ 2008-12-11 22:40 UTC (permalink / raw)
To: git; +Cc: Lars Hjemli, Junio C Hamano, Seth Vidal
In-Reply-To: <8c5c35580812111348iceaf30dyb55183017cff5b1d@mail.gmail.com>
On Thursday 11 December 2008, Lars Hjemli wrote:
> Background: I've been asked by the fedora project how to package cgit.
> The problem is basically that cgit is designed to be statically linked
> with a specific git release (i.e. libgit.a and xdiff/lib.a).
>
> When manually building cgit from a tarball this isn't a problem:
> 'make get-git' will download the required git sources from kernel.org.
> But the buildsystem/policy used by the fedora project does not allow
> network access during package builds, and since it is quite unlikely
> that the git package always will match the exact release needed by the
> cgit package, I only see four options:
> 1) the fedora project makes a 'git-for-cgit' package containing the
> needed release of the git sources
> 2) the cgit release tarballs includes the needed git sources
> 3) the cgit sources are subtree-merged into git
> 4) cgit is modified to link against libgit2
>
> Option 1 seems unlikely to happen since such a 'git-for-cgit' package
> would basically require the fedora project to support two git
> packages.
>
> Option 2 is doable but still requires the fedora project to support
> two git packages (but now the 'git-for-cgit' package is hidden inside
> the cgit source tree). The good thing about this option is that it
> only requires some minor modifications to the cgit releases.
>
> Option 3 would solve the problem for the fedora project but is not for
> me to decide - it might become an extra maintenance burden on the git
> maintainer and community.
>
> Option 4 is the correct solution but not a very practical one; it's
> currently hard to predict when libgit2 will be ready for general
> (c)git use.
>
> Personally I'd love for option 3 to happen, hence this rfc.
Option 5: Include cgit as a submodule in git.git. Then it's available to
those who want it, but not cloned/built by default.
If that doesn't pan out, I also support option #3.
I've been a happy cgit user for a number of months, and have yet to find a
single issue where cgit is not better than or equal to gitweb. I have
nothing bad to say about gitweb per se, but cgit simply offers me a better
user experience, not least because of its blazing speed.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [RFC] cgit in git?
From: Junio C Hamano @ 2008-12-11 22:35 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Seth Vidal, Git Mailing List
In-Reply-To: <8c5c35580812111348iceaf30dyb55183017cff5b1d@mail.gmail.com>
"Lars Hjemli" <hjemli@gmail.com> writes:
> 2) the cgit release tarballs includes the needed git sources
>
> Option 2 is doable but still requires the fedora project to support
> two git packages (but now the 'git-for-cgit' package is hidden inside
> the cgit source tree). The good thing about this option is that it
> only requires some minor modifications to the cgit releases.
I do not understand why this is any extra work for fedora. Instead of
running "make get-git" and then running your build procedure, they need to
just run your build procedure because you now ship your source with the
matching version of the git source, which sounds like the right thing to
me. You do not install anything from the contained git.git area (we do
not do shared objects, nor public header files) to the end product, right?
Doesn't cgit bind git.git as a subproject at the source level? I would
expect that the most natural release tarball for such a project would be a
single tarball that has both the superproject itself _and_ the submodules
it contains already extracted, iow, the state of your tree after you run
"make get-git".
^ permalink raw reply
* Re: Clarifying "invalid tag signature file" error message from git filter-branch (and others)
From: James Youngman @ 2008-12-11 22:34 UTC (permalink / raw)
To: Brandon Casey; +Cc: git
In-Reply-To: <P7E-5meNX4tXFurN9mnRguFHdJG1jaZYTn6WxFFpECSJ68KyYT3wqQ@cipher.nrlssc.navy.mil>
On Thu, Dec 11, 2008 at 9:06 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
> James Youngman wrote:
>> What do the errors "error: char88: malformed tagger field" and "fatal:
>> invalid tag signature file" and "Could not create new tag object for
>> FINDUTILS-4_1-10" signify in the session below?
>
> It means the tagger field in the tag does not follow the correct form.
> Specifically the testing in git-mktag (called by filter-branch) does:
>
> * Check for correct form for name and email
> * i.e. " <" followed by "> " on _this_ line
> * No angle brackets within the name or email address fields.
> * No spaces within the email address field.
>
> What does 'git cat-file tag FINDUTILS-4_1-10' show you?
Before conversion:
$ git cat-file tag FINDUTILS-4_1-10
object ce25eb352de8dc53a9a7805ba9efc1c9215d28c2
type commit
tag FINDUTILS-4_1-10
tagger Kevin Dalley
The conversion:
After conversion:
$ git cat-file tag FINDUTILS-4_1-10
object ce25eb352de8dc53a9a7805ba9efc1c9215d28c2
type commit
tag FINDUTILS-4_1-10
tagger Kevin Dalley
This is in the repo at
http://git.savannah.gnu.org/gitweb/?p=findutils.git;a=commit;h=ce25eb352de8dc53a9a7805ba9efc1c9215d28c2
>> Are any of those errors correctable (I can re-run the tree rewrite
>> script as many times as needed, I'm just using it on a test repository
>> for now).
>
> If there are only a few, then you can manually retag with a corrected
> tagger field, and then run your script.
>
> Of course, depending on the output of the cat-file call above, the
> testing in git-mktag may need to be relaxed.
>
> -brandon
>
^ permalink raw reply
* Re: [RFC/PATCH 4/3] gitweb: Incremental blame (proof of concept)
From: Jakub Narebski @ 2008-12-11 22:34 UTC (permalink / raw)
To: git; +Cc: Petr Baudis, Fredrik Kuivinen
In-Reply-To: <m3r64ehba7.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> New features (in short):
> * 3-coloring of lines with blame data during incremental blaming
> * Adding author initials below shortened SHA-1 of a commit
> (if there is place for it, i.e. if group has more than 1 row)
> * progress indicator: progress info and progress bar
> * information about how long it took to run 'blame_data',
> and how long it took to run JavaScript script
* handling server ('blame_data') errors, i.e. status != 200.
(I needed that to debug blame.js when I entered URL incorrectly).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] cgit in git?
From: Jakub Narebski @ 2008-12-11 22:28 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, Seth Vidal, Git Mailing List
In-Reply-To: <8c5c35580812111348iceaf30dyb55183017cff5b1d@mail.gmail.com>
"Lars Hjemli" <hjemli@gmail.com> writes:
> But the buildsystem/policy used by the fedora project does not allow
> network access during package builds, and since it is quite unlikely
> that the git package always will match the exact release needed by the
> cgit package, I only see four options:
> 1) the fedora project makes a 'git-for-cgit' package containing the
> needed release of the git sources
> 2) the cgit release tarballs includes the needed git sources
2b) make cgit .spec use _two_ tarballs as a source, one with cgit
sources, one with git sources. This assumes that you always use
released git version as a base.
This is immediate solution.
> 3) the cgit sources are subtree-merged into git
I wonder how likely this would be.
> 4) cgit is modified to link against libgit2
Option 4) would be probably best in long term, but libgit2 doesn't
exists yet.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] autodetect number of CPUs by default when using threads
From: Junio C Hamano @ 2008-12-11 22:25 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0812111524370.14328@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> I've spent quite a while wondering why repacking in one repo was faster
> than repacking in a clone of that repo on the same machine. So let's
> display how many threads are actually used.
>
> We have comprehensive test in Makefile to determine if threads are
> available, just to not use them by default. I think that code has
> proven itself for long enough now not to let people benefit from it.
Hmm, it does appear that distros compile with THREADED_DELTA_SEARCH turned
on (I only checked Fedora and Debian), and I tend to agree with "long
enough" but "proven itself" feels bit too strong a statement.
I think defaulting to autodetect is a good change. I do not like to add
new output to stderr deep in -rc, though.
Can we park this in 'next' and move it to 'master' after 1.6.1?
^ permalink raw reply
* Re: [RFC] cgit in git?
From: Miklos Vajna @ 2008-12-11 22:15 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, Seth Vidal, Git Mailing List
In-Reply-To: <8c5c35580812111348iceaf30dyb55183017cff5b1d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 834 bytes --]
On Thu, Dec 11, 2008 at 10:48:45PM +0100, Lars Hjemli <hjemli@gmail.com> wrote:
> 2) the cgit release tarballs includes the needed git sources
> 3) the cgit sources are subtree-merged into git
> 4) cgit is modified to link against libgit2
>
> Option 1 seems unlikely to happen since such a 'git-for-cgit' package
> would basically require the fedora project to support two git
> packages.
>
> Option 2 is doable but still requires the fedora project to support
> two git packages (but now the 'git-for-cgit' package is hidden inside
> the cgit source tree). The good thing about this option is that it
> only requires some minor modifications to the cgit releases.
I don't say 2) is the ideal solution (probably 4) will be), but that's
what we choosed for Frugalware and I think Fedora could live with it as
well.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: fatal output from git-show really wants a terminal
From: Jeff King @ 2008-12-11 21:55 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Johannes Schindelin, git
In-Reply-To: <200812111051.20322.bss03@volumehost.net>
On Thu, Dec 11, 2008 at 10:51:15AM -0600, Boyd Stephen Smith Jr. wrote:
> Initially, I was looking for 'stdout' or 'stderr', and found many unrelated
> commits. I then figured it was part of the PAGER support, and began
Try looking for isatty, which takes the numeric fd. I think the behavior
you asked about would be this:
diff --git a/pager.c b/pager.c
index aa0966c..19f8856 100644
--- a/pager.c
+++ b/pager.c
@@ -42,7 +42,7 @@ void setup_pager(void)
{
const char *pager = getenv("GIT_PAGER");
- if (!isatty(1))
+ if (!isatty(0) || !isatty(2))
return;
if (!pager) {
if (!pager_program)
which is what is mentioned in POSIX:
http://www.opengroup.org/onlinepubs/009695399/utilities/sh.html
But I don't think that makes sense here. We are not talking about
interactivity, but rather about where the output is going. So your test
would consider this interactive:
$ git log >foo.out
and start a pager, which makes no sense.
Now if you proposed checking stderr and stdin _in addition_ to stdout,
that might make more sense, but I haven't thought too hard about any
implications.
And FWIW, I don't recall this ever being discussed before, but then I
have not been involved with git since the very beginning.
-Peff
^ permalink raw reply related
* [RFC] cgit in git?
From: Lars Hjemli @ 2008-12-11 21:48 UTC (permalink / raw)
To: Junio C Hamano, Seth Vidal, Git Mailing List
Background: I've been asked by the fedora project how to package cgit.
The problem is basically that cgit is designed to be statically linked
with a specific git release (i.e. libgit.a and xdiff/lib.a).
When manually building cgit from a tarball this isn't a problem:
'make get-git' will download the required git sources from kernel.org.
But the buildsystem/policy used by the fedora project does not allow
network access during package builds, and since it is quite unlikely
that the git package always will match the exact release needed by the
cgit package, I only see four options:
1) the fedora project makes a 'git-for-cgit' package containing the
needed release of the git sources
2) the cgit release tarballs includes the needed git sources
3) the cgit sources are subtree-merged into git
4) cgit is modified to link against libgit2
Option 1 seems unlikely to happen since such a 'git-for-cgit' package
would basically require the fedora project to support two git
packages.
Option 2 is doable but still requires the fedora project to support
two git packages (but now the 'git-for-cgit' package is hidden inside
the cgit source tree). The good thing about this option is that it
only requires some minor modifications to the cgit releases.
Option 3 would solve the problem for the fedora project but is not for
me to decide - it might become an extra maintenance burden on the git
maintainer and community.
Option 4 is the correct solution but not a very practical one; it's
currently hard to predict when libgit2 will be ready for general
(c)git use.
Personally I'd love for option 3 to happen, hence this rfc.
--
larsh
^ 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