* git tag -s: TAG_EDITMSG should not be deleted upon failures
From: Christian Jaeger @ 2008-12-03 15:53 UTC (permalink / raw)
To: Git Mailing List
Before I've now set my default signing key id in my ~/.gitconfig, I've
run at least half a dozen times into the case where I'm running "git tag
-s $tagname", carefully preparing a tag message, saving the file &
exiting from the editor, only to be greeted with an error message that
no key could be found for my (deliberately host-specific) email address,
and my message gone. If it would keep the TAG_EDITMSG file (like git
commit seems to be doing with COMMIT_EDITMSG anyway), I could rescue the
message from there. I relentlessly assume that this small change would
also make a handful of other people happier.
Christian.
^ permalink raw reply
* Buggy (or undocumented) handling of terminal \r in .gitignore patterns
From: Aaron Harnly @ 2008-12-03 15:46 UTC (permalink / raw)
To: git
This is with git 1.5.6.3 on Ubuntu and Mac OS X.
Overview: .gitignore patterns ending in \r do not work as expected, apparently
because the terminal \r is assumed to be part of the newline.
Steps to Reproduce:
(NB ^M is the control-M sequence, not a literal caret-M)
1. Create an empty repository.
2. Create a file named Icon\r (aka Icon^M).
3. Add the following pattern to the .gitignore:
Icon^M
Expected behavior:
The file is ignored.
Actual behavior:
The file is not ignored.
Discussion:
It appears that the parsing of .gitignore files tries to be graceful in allowing
the file to have CRLF endings, or indeed mixed LF / CRLF endings.
This is well and good, but poses a bit of a problem for ignoring files whose
name ends in \r. In particular, Mac OS X's icon files are named Icon\r. Yes,
this is sick and annoying on the part of Apple.
I understand the rationale for this behavior, but it probably should be
documented somewhere. In the meantime, a workaround that does allow the ignoring
of these files is the pattern:
Icon^M^M
where again, the terminal \r seems to be ignored as part of the newline, but the
penultimate \r gets picked up as part of the pattern.
Any thoughts on whether:
1. this behavior should be left as it is
2. there is actually documentation somewhere that I didn't see
3. terminal \r in an otherwise all-LF file should be assumed to be part of the
pattern
4. some other alternative?
cheers,
~aaron
^ permalink raw reply
* Re: [PATCH] gitweb: Optional grouping of projects by category
From: Sébastien Cevey @ 2008-12-03 14:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano, Petr Baudis, Gustavo Sverzut Barbieri
In-Reply-To: <200812030036.13562.jnareb@gmail.com>
At Wed, 3 Dec 2008 00:36:12 +0100, Jakub Narebski wrote:
Hello,
> > This adds the GITWEB_GROUP_CATEGORIES option which, if enabled, will
> > result in grouping projects by category on the project list page.
>
> Should this really be build time configuration (to set default value)?
Probably not, I removed it. I corrected my patch using all your other
comments and sent it again in another email.
> Unfortunately it looks like you hit the edge of feature freeze again.
Damn, time is always against me :-)
Hope it's gonna be included eventually!
> By the way, there was alternate patch series by Gustavo Sverzut Barbieri
> on 29 July 2008 adding categories support to gitweb:
> http://thread.gmane.org/gmane.comp.version-control.git/90553
> with live demo at http://staff.get-e.org/
Right, I saw that in July but it's not exactly the same feature
(arbitrary category in config vs repository path). I think both are
useful independently.. If both get supported, there should be a way to
do it modularly to reuse code though.
Btw you can see a demo of my patch here: http://inso.cc/git
> Here is and important issue when adding categories support: how division
> into categories interplays with sorting of projects.
I kept it how it was but added a comment in the commitlog.
> Another issue is how categories interplay with limiting number of
> projects displayed. Currently it is no issue, because projects list
> page is not divided into pages, but I think you didn't address this
> in your patch.
I think it's now better in v2, I added support for $from/$to also in
the categorized project list.
Thanks for your in depth comments, and I hope this patch will get
applied in the near future!
--
Sébastien Cevey / inso.cc
" The question of whether a computer can think is no more
interesting than the question of whether a submarine can swim. "
Edsger W. Dijkstra
^ permalink raw reply
* Re: git-p4 submit, Can't clobber writable file
From: Jing Xue @ 2008-12-03 14:24 UTC (permalink / raw)
To: Gary Yang; +Cc: git
In-Reply-To: <410584.87710.qm@web37905.mail.mud.yahoo.com>
(Just a friendly reminder - I believe the convention on this list is "no
top-post.")
On Tue, Dec 02, 2008 at 10:04:20PM -0800, Gary Yang wrote:
>
> --- On Tue, 12/2/08, Jing Xue <jingxue@digizenstudio.com> wrote:
>
> > You might want to clone to a git working dir different than
> > the p4
> > working dir.
> >
> > For instance, if your p4 workspace has the working dir set
> > to
> > build_scripts/, try 'git p4 clone //build/scripts
> > build_scripts.git'.
> >
> > You would then normally work under build_scripts.git/.
> > build_scripts/
> > would only be used by git-p4 at submission time.
>
> So, I have to keep two copies of source tree at my home directory. One
> is for Perforce build_scripts workspace, another is for Git
> build_scripts.git. I normally work at build_scripts.git. But, when I
> need to submit changes to Perforce, I have to copy changed code from
> build_scripts.git to build_scripts.
You don't have to do that, not manually. That's git-p4's job. When you
do 'git p4 submit', it basically:
1. calls 'p4 sync' in the p4 working dir,
2. generates patches from p4/master..HEAD,
3. for each of the patches, applies it in the p4 working dir, and 'p4
submit' it as one changelist.
> Then, p4 submit code into
> Perforce. Is this the only way of using git-p4? Note: I cannot use
> git-p4 submit at build_scripts. It claims "Cannot clobber writable
> file". Is it a bug of git-p4 or the instruction is not correct?
Git-p4.txt does mention this (although briefly) in the "Submitting"
section:
"git-p4 has support for submitting changes from a git repository back to the
Perforce depot. This requires a Perforce checkout separate from your git
repository..."
Cheers.
--
Jing Xue
^ permalink raw reply
* [PATCH v2] gitweb: Optional grouping of projects by category
From: Sébastien Cevey @ 2008-12-03 14:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano, Petr Baudis, Gustavo Sverzut Barbieri
In-Reply-To: <200812030036.13562.jnareb@gmail.com>
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, only the categories with
projects in the chosen subset are displayed.
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>
---
Version 2 of the patch including corrections based on Jakub's comment,
notably removed the build time configuration variable, added more doc,
improved CSS look, cleaned some code and added support for displaying
a subset of all the projects (using $from/$to).
gitweb/README | 16 +++++
gitweb/gitweb.css | 7 ++
gitweb/gitweb.perl | 190 +++++++++++++++++++++++++++++++++++++---------------
3 files changed, 158 insertions(+), 55 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 933e137..5b11b66 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";
@@ -2001,18 +2009,31 @@ 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_project_config_or_file {
+ 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_project_config_or_file('description', $path);
+}
+
+sub git_get_project_category {
+ my $path = shift;
+ return git_get_project_config_or_file('category', $path);
}
sub git_get_project_ctags {
@@ -3907,8 +3928,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) = @_;
@@ -3931,6 +3953,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$//) &&
@@ -3948,6 +3975,19 @@ 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 = shift;
+ my %categories;
+
+ for my $pr (@$projlist) {
+ 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 {
@@ -3964,16 +4004,71 @@ 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 ($projects, $from, $to, $check_forks, $show_ctags) = @_;
+
+ $from = 0 unless defined $from;
+ $to = $#$projects if (!defined $to || $#$projects < $to);
+
+ my $alternate = 1;
+ my $tagfilter = $cgi->param('by_tag');
+ for (my $i = $from; $i <= $to; $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/
+ and not $pr->{'descr_long'} =~ /$searchtext/;
+ # Weed out forks or non-matching entries of search
+ if ($check_forks) {
+ my $forkbase = $project; $forkbase ||= ''; $forkbase =~ s#\.git$#/#;
+ $forkbase="^$forkbase" if $forkbase;
+ next if not $searchtext and not $tagfilter and $show_ctags
+ and $pr->{'path'} =~ m#$forkbase.*/.*#; # regexp-safe
+ }
+
+ if ($alternate) {
+ print "<tr class=\"dark\">\n";
+ } else {
+ print "<tr class=\"light\">\n";
+ }
+ $alternate ^= 1;
+ if ($check_forks) {
+ print "<td>";
+ if ($pr->{'forks'}) {
+ print "<!-- $pr->{'forks'} -->\n";
+ print $cgi->a({-href => href(project=>$pr->{'path'}, action=>"forks")}, "+");
+ }
+ print "</td>\n";
+ }
+ print "<td>" . $cgi->a({-href => href(project=>$pr->{'path'}, action=>"summary"),
+ -class => "list"}, esc_html($pr->{'path'})) . "</td>\n" .
+ "<td>" . $cgi->a({-href => href(project=>$pr->{'path'}, action=>"summary"),
+ -class => "list", -title => $pr->{'descr_long'}},
+ esc_html($pr->{'descr'})) . "</td>\n" .
+ "<td><i>" . chop_and_escape_str($pr->{'owner'}, 15) . "</i></td>\n";
+ print "<td class=\"". age_class($pr->{'age'}) . "\">" .
+ (defined $pr->{'age_string'} ? $pr->{'age_string'} : "No commits") . "</td>\n" .
+ "<td class=\"link\">" .
+ $cgi->a({-href => href(project=>$pr->{'path'}, action=>"summary")}, "summary") . " | " .
+ $cgi->a({-href => href(project=>$pr->{'path'}, action=>"shortlog")}, "shortlog") . " | " .
+ $cgi->a({-href => href(project=>$pr->{'path'}, action=>"log")}, "log") . " | " .
+ $cgi->a({-href => href(project=>$pr->{'path'}, action=>"tree")}, "tree") .
+ ($pr->{'forks'} ? " | " . $cgi->a({-href => href(project=>$pr->{'path'}, action=>"forks")}, "forks") : '') .
+ "</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;
- $from = 0 unless defined $from;
- $to = $#projects if (!defined $to || $#projects < $to);
my %order_info = (
project => { key => 'path', type => 'str' },
@@ -4013,53 +4108,38 @@ sub git_project_list_body {
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];
- next if $tagfilter and $show_ctags and not grep { lc $_ eq lc $tagfilter } keys %{$pr->{'ctags'}};
- next if $searchtext and not $pr->{'path'} =~ /$searchtext/
- and not $pr->{'descr_long'} =~ /$searchtext/;
- # Weed out forks or non-matching entries of search
- if ($check_forks) {
- my $forkbase = $project; $forkbase ||= ''; $forkbase =~ s#\.git$#/#;
- $forkbase="^$forkbase" if $forkbase;
- next if not $searchtext and not $tagfilter and $show_ctags
- and $pr->{'path'} =~ m#$forkbase.*/.*#; # regexp-safe
- }
+ if ($projects_list_group_categories) {
+ # only display categories with projects in the $from-$to window
+ my %categories = build_projlist_by_category(\@projects);
+ foreach my $cat (sort keys %categories) {
+ my $num_cats = @{$categories{$cat}};
- if ($alternate) {
- print "<tr class=\"dark\">\n";
- } else {
- print "<tr class=\"light\">\n";
- }
- $alternate ^= 1;
- if ($check_forks) {
- print "<td>";
- if ($pr->{'forks'}) {
- print "<!-- $pr->{'forks'} -->\n";
- print $cgi->a({-href => href(project=>$pr->{'path'}, action=>"forks")}, "+");
+ # out of the window to display, done
+ last if defined $to and $to < 0;
+
+ # in the window to display
+ if (!defined $from or $from < $num_cats) {
+ 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}, $from, $to, $check_forks, $show_ctags);
}
- print "</td>\n";
+
+ # adjust $from/$to offset, keep $from positive
+ $from = ($from > $num_cats) ? $from - $num_cats : 0 if defined $from;
+ $to -= $num_cats if defined $to;
}
- print "<td>" . $cgi->a({-href => href(project=>$pr->{'path'}, action=>"summary"),
- -class => "list"}, esc_html($pr->{'path'})) . "</td>\n" .
- "<td>" . $cgi->a({-href => href(project=>$pr->{'path'}, action=>"summary"),
- -class => "list", -title => $pr->{'descr_long'}},
- esc_html($pr->{'descr'})) . "</td>\n" .
- "<td><i>" . chop_and_escape_str($pr->{'owner'}, 15) . "</i></td>\n";
- print "<td class=\"". age_class($pr->{'age'}) . "\">" .
- (defined $pr->{'age_string'} ? $pr->{'age_string'} : "No commits") . "</td>\n" .
- "<td class=\"link\">" .
- $cgi->a({-href => href(project=>$pr->{'path'}, action=>"summary")}, "summary") . " | " .
- $cgi->a({-href => href(project=>$pr->{'path'}, action=>"shortlog")}, "shortlog") . " | " .
- $cgi->a({-href => href(project=>$pr->{'path'}, action=>"log")}, "log") . " | " .
- $cgi->a({-href => href(project=>$pr->{'path'}, action=>"tree")}, "tree") .
- ($pr->{'forks'} ? " | " . $cgi->a({-href => href(project=>$pr->{'path'}, action=>"forks")}, "forks") : '') .
- "</td>\n" .
- "</tr>\n";
+ } else {
+ 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
* Re: git-p4 submit, Can't clobber writable file
From: Arafangion @ 2008-12-03 11:07 UTC (permalink / raw)
To: garyyang6; +Cc: Jing Xue, git
In-Reply-To: <410584.87710.qm@web37905.mail.mud.yahoo.com>
I would argue that's a bug with git-p4, however that is a warning given
by perforce, thus, you should be able to work around it by changing the
clientspec, change the clientspec so that it will clobber such files,
you will need to refer to the perforce docs for info about that.
On Tue, 2008-12-02 at 22:04 -0800, Gary Yang wrote:
> So, I have to keep two copies of source tree at my home directory. One is for Perforce build_scripts workspace, another is for Git build_scripts.git. I normally work at build_scripts.git. But, when I need to submit changes to Perforce, I have to copy changed code from build_scripts.git to build_scripts. Then, p4 submit code into Perforce. Is this the only way of using git-p4?
> Note: I cannot use git-p4 submit at build_scripts. It claims "Cannot clobber writable file". Is it a bug of git-p4 or the instruction is not correct?
>
>
> --- On Tue, 12/2/08, Jing Xue <jingxue@digizenstudio.com> wrote:
>
> > From: Jing Xue <jingxue@digizenstudio.com>
> > Subject: Re: git-p4 submit, Can't clobber writable file
> > To: "Gary Yang" <garyyang6@yahoo.com>
> > Cc: git@vger.kernel.org
> > Date: Tuesday, December 2, 2008, 7:07 PM
> > On Tue, Dec 02, 2008 at 02:30:51PM -0800, Gary Yang wrote:
> > >
> > > I followed the instructions at
> > http://modular.math.washington.edu/home/mhansen/git-1.5.5.1/contrib/fast-import/git-p4.txt
> > >
> > > But, I am not able to git-p4 submit. Any idea?
> > >
> > > git-p4 clone //build/scripts build_scripts
> > > cd build_scripts
> > > vi foo.h
> > > git commit foo.h
> > > git-p4 rebase
> > > git-p4 submit
> > >
> > > from sets import Set;
> > > Perforce checkout for depot path //build/scripts/
> > located at /home/gyang/workspace/build_scripts/
> > > Syncronizing p4 checkout...
> > > //build/scripts/foo.h#1 - added as
> > /home/gyang/workspace/build_scripts/foo.h
> > > Can't clobber writable file
> > /home/gyang/workspace/build_scripts/foo.h
> > > //build/scripts/foo.c#1 - added as
> > /home/gyang/workspace/build_scripts/foo.c
> > > Can't clobber writable file
> > /user/home/gyang/workspace/build_scripts/foo.c
> > > ......
> > > command failed: p4 sync ...
> >
> > You might want to clone to a git working dir different than
> > the p4
> > working dir.
> >
> > For instance, if your p4 workspace has the working dir set
> > to
> > build_scripts/, try 'git p4 clone //build/scripts
> > build_scripts.git'.
> >
> > You would then normally work under build_scripts.git/.
> > build_scripts/
> > would only be used by git-p4 at submission time.
> >
> > Cheers.
> > --
> > Jing Xue
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Multiple SVN Repos Inside A Git Repo
From: Michael J Gruber @ 2008-12-03 13:57 UTC (permalink / raw)
To: Tim Sally; +Cc: git
In-Reply-To: <4753154c0812021222t2886f986id2b775f90d4ea7f@mail.gmail.com>
Tim Sally venit, vidit, dixit 02.12.2008 21:22:
> Using git-svn, it is possible to have different parts of a git repo
> correspond to a specific svn repo? From my understanding after reading
> the documentation, you need one git repository per svn. My example is
> that I'm trying to set up a git repo to version control everything
> from my classes, but each class has a separate svn repo. Also, the
> number of git repos I can create is limited, and I'd rather not
> clutter everything up with many separate git-svn repos.
>
> Example structure:
>
> class/
> .......... systems/
> .......... algorithms/
> .......... physics/
>
> class is one central git repository, and systems, algorithms, and
> physics contain data from three svn repositories. Ideally, you could
> commit/update to/from each svn repo individually, or all at once.
>
> Tim
You can have as many git svn configurations in a single git repo as you
want (see the "-R" argument to git svn). They will all correspond to
different remote branches. By checking out the branches (or a
corresponding tracking branch) you can switch between the branches, i.e.
between classes.
I don't think a layout as above is possible given your requirements that
- you (basically) want a single git repo and
- you want to be able to commit back.
They exclude using submodules resp. subtree merge.
Michael
^ permalink raw reply
* Re: Ad: fast-import problem importing dos format files under cygwin
From: Jan Hudec @ 2008-12-03 13:43 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jan Hudec, git
In-Reply-To: <49367909.8070605@viscovery.net>
Dne 3 Prosinec 2008, 13:18, Johannes Sixt napsal(a):
> Jan Hudec schrieb:
>> On 3 December 2008, 08:51, Jan Hudec wrote:
>>> Hello folks,
>>>
>>> I have been playing with fast-import in cygwin and I have problems
>>> importing files with CR/LF line-endings. The size in data command is
>>> calculated including the CRs and than the file is copied binary to the
>>> fast-import input stream. However fast-import skips the CRs when
>>> reading,
>>> overreads by that number of bytes and fails when it tries to read the
>>> next command from the middle.
>
> Do you happen to have core.autocrlf set in some way and could it make a
> difference for fast-import? I have it unset.
I have it set to false explicitly in global config. Tried with not having
it set at all and gives the same problem. Since the previous version of
MSys Git worked for me, I suspect it's somehow cygwin-related.
--
- Jan Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: Is there a way to control the number of revisions will be saved by git
From: Miklos Vajna @ 2008-12-03 13:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Johannes Sixt, Tzury Bar Yochay, git
In-Reply-To: <m3ljuxifer.fsf@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 406 bytes --]
On Wed, Dec 03, 2008 at 04:58:40AM -0800, Jakub Narebski <jnareb@gmail.com> wrote:
> Or just use shallow clone
>
> git clone --depth <depth> <repository>
>
> to have new copy (clone) of <repository> to have only <depth> commits
> back. See man git-commit; but it might be not what you want.
You mean man git-clone?
This trick can be used only once, since you can't clone a shallow clone.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH 5/5] submodule: use git rev-parse -q
From: Miklos Vajna @ 2008-12-03 13:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1228310570.git.vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
git-submodule.sh | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 220d94e..2f47e06 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -413,7 +413,7 @@ cmd_summary() {
test $summary_limit = 0 && return
- if rev=$(git rev-parse --verify "$1^0" 2>/dev/null)
+ if rev=$(git rev-parse -q --verify "$1^0")
then
head=$rev
shift
@@ -464,11 +464,11 @@ cmd_summary() {
missing_dst=
test $mod_src = 160000 &&
- ! GIT_DIR="$name/.git" git-rev-parse --verify $sha1_src^0 >/dev/null 2>&1 &&
+ ! GIT_DIR="$name/.git" git-rev-parse -q --verify $sha1_src^0 >/dev/null &&
missing_src=t
test $mod_dst = 160000 &&
- ! GIT_DIR="$name/.git" git-rev-parse --verify $sha1_dst^0 >/dev/null 2>&1 &&
+ ! GIT_DIR="$name/.git" git-rev-parse -q --verify $sha1_dst^0 >/dev/null &&
missing_dst=t
total_commits=
--
1.6.0.4
^ permalink raw reply related
* [PATCH 1/5] filter-branch: use git rev-parse -q
From: Miklos Vajna @ 2008-12-03 13:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1228310570.git.vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
git-filter-branch.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 81392ad..c106f45 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -256,7 +256,7 @@ while read commit parents; do
*)
# The commit may not have the subdirectory at all
err=$(git read-tree -i -m $commit:"$filter_subdir" 2>&1) || {
- if ! git rev-parse --verify $commit:"$filter_subdir" 2>/dev/null
+ if ! git rev-parse -q --verify $commit:"$filter_subdir"
then
rm -f "$GIT_INDEX_FILE"
else
--
1.6.0.4
^ permalink raw reply related
* [PATCH 4/5] rebase: use git rev-parse -q
From: Miklos Vajna @ 2008-12-03 13:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1228310570.git.vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
git-rebase.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 023a6dc..ea7720d 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -365,10 +365,10 @@ case "$#" in
switch_to="$2"
if git show-ref --verify --quiet -- "refs/heads/$2" &&
- branch=$(git rev-parse --verify "refs/heads/$2" 2>/dev/null)
+ branch=$(git rev-parse -q --verify "refs/heads/$2")
then
head_name="refs/heads/$2"
- elif branch=$(git rev-parse --verify "$2" 2>/dev/null)
+ elif branch=$(git rev-parse -q --verify "$2")
then
head_name="detached HEAD"
else
--
1.6.0.4
^ permalink raw reply related
* [PATCH 2/5] lost-found: use git rev-parse -q
From: Miklos Vajna @ 2008-12-03 13:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1228310570.git.vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
git-lost-found.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-lost-found.sh b/git-lost-found.sh
index 9cedaf8..0b3e8c7 100755
--- a/git-lost-found.sh
+++ b/git-lost-found.sh
@@ -20,7 +20,7 @@ while read dangling type sha1
do
case "$dangling" in
dangling)
- if git rev-parse --verify "$sha1^0" >/dev/null 2>/dev/null
+ if git rev-parse -q --verify "$sha1^0" >/dev/null
then
dir="$laf/commit"
git show-branch "$sha1"
--
1.6.0.4
^ permalink raw reply related
* [PATCH 3/5] pull: use git rev-parse -q
From: Miklos Vajna @ 2008-12-03 13:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1228310570.git.vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
git-pull.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 1cac898..2c7f432 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -121,13 +121,13 @@ test true = "$rebase" && {
test -z "$origin" && origin=$(get_default_remote)
reflist="$(get_remote_refs_for_fetch "$@" 2>/dev/null |
sed "s|refs/heads/\(.*\):|\1|")" &&
- oldremoteref="$(git rev-parse --verify \
- "refs/remotes/$origin/$reflist" 2>/dev/null)"
+ oldremoteref="$(git rev-parse -q --verify \
+ "refs/remotes/$origin/$reflist")"
}
-orig_head=$(git rev-parse --verify HEAD 2>/dev/null)
+orig_head=$(git rev-parse -q --verify HEAD)
git fetch $verbosity --update-head-ok "$@" || exit 1
-curr_head=$(git rev-parse --verify HEAD 2>/dev/null)
+curr_head=$(git rev-parse -q --verify HEAD)
if test -n "$orig_head" && test "$curr_head" != "$orig_head"
then
# The fetch involved updating the current branch.
--
1.6.0.4
^ permalink raw reply related
* [PATCH 0/5] More "use rev-parse -q" patches
From: Miklos Vajna @ 2008-12-03 13:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi,
I'm sending these as separate patches as they touch completely unrelated
parts of Git, but feel free to squash them together you think that's
better.
All of them is about using rev-parse -q instead of rev-parse 2>/dev/null.
Miklos Vajna (5):
filter-branch: use git rev-parse -q
lost-found: use git rev-parse -q
pull: use git rev-parse -q
rebase: use git rev-parse -q
submodule: use git rev-parse -q
git-filter-branch.sh | 2 +-
git-lost-found.sh | 2 +-
git-pull.sh | 8 ++++----
git-rebase.sh | 4 ++--
git-submodule.sh | 6 +++---
5 files changed, 11 insertions(+), 11 deletions(-)
^ permalink raw reply
* [PATCH] gitk: Ensure that "Reset branch" menu entry is enabled
From: Johannes Sixt @ 2008-12-03 12:43 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List, Johannes Sixt
Consider this sequence of events:
1. Detach HEAD and fire up gitk
2. Call the context menu on some commit. Notice that the last menu entry
says "Detached HEAD: can't reset" and it is disabled.
3. Now checkout some regular branch (e.g. 'master') using the context menu.
4. Call the context menu again on some commit.
Previously, at this point the last menu entry said "Reset master branch
to here", but it was still disabled. With this fix it is now enabled again.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
gitk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index f7f1776..6c4022a 100755
--- a/gitk
+++ b/gitk
@@ -7950,7 +7950,7 @@ proc rowmenu {x y id} {
if {$id ne $nullid && $id ne $nullid2} {
set menu $rowctxmenu
if {$mainhead ne {}} {
- $menu entryconfigure 7 -label [mc "Reset %s branch to here" $mainhead]
+ $menu entryconfigure 7 -label [mc "Reset %s branch to here" $mainhead] -state normal
} else {
$menu entryconfigure 7 -label [mc "Detached head: can't reset" $mainhead] -state disabled
}
--
1.6.1.rc1
^ permalink raw reply related
* Re: [RFCv2 1/2] gitweb: add patch view
From: Giuseppe Bilotta @ 2008-12-03 13:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git, Petr Baudis
In-Reply-To: <200812031400.50980.jnareb@gmail.com>
On Wed, Dec 3, 2008 at 2:00 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Wed, 3 Dec 2008, Giuseppe Bilotta wrote:
>> On Wed, Dec 3, 2008 at 12:19 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>
>>> Perhaps this configuration should also be a feature defined in %feature,
>>> overridable by each repository? If you default it to "disabled" (as any
>>> new feature typically does), you do not have to yank a random number such
>>> as 100 out of thin air.
>>
>> I thought about it, but then I thought it was way too useful for
>> single patches to disable the feature a priori. I'd rather make the
>> default limit much smaller (like the original 16 commits I had in
>> mind, or even less).
>
> Perhaps %feature can be used to configure _maximum_ number of patches
> in 'patch' / 'format_patch' view (gitweb_get_feature... well, sort of
> as gitweb_check_feature would work too), rather than checking if it
> is enabled or disabled?
The way it's implemented in v2, you just need to set $patch_max in
your local or system config file (e.g. /etc/gitweb.conf). I'm not sure
about the benefit we would gain in going through %feature.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: Is there a way to control the number of revisions will be saved by git
From: Jean-Luc Herren @ 2008-12-03 13:04 UTC (permalink / raw)
To: Arafangion; +Cc: Tzury Bar Yochay, git
In-Reply-To: <1228304226.23167.8.camel@therock.nsw.bigpond.net.au>
Arafangion wrote:
> On Wed, 2008-12-03 at 13:01 +0200, Tzury Bar Yochay wrote:
> <snip>
>> Say I wish to save only 100 generations back (per branch).
>> Is it possible to configure git so it will save only N records back.
>
> What would be the advantage in doing that?
That would be a shallow repository, as is already supported by
"git clone --depth 100". It can be useful for a number of things,
for example developing simple patches on top of HEAD and sending
them somewhere.
What the OP might want is a way to convert a full repository into
a shallow one (can be done by cloning and deleting the original),
and then be able to make it shallower from time to time, to limit
it to 100 revisions; not sure if that is possible.
jlh
^ permalink raw reply
* Re: [RFCv2 1/2] gitweb: add patch view
From: Jakub Narebski @ 2008-12-03 13:00 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Junio C Hamano, git, Petr Baudis
In-Reply-To: <cb7bb73a0812030333n2cfdc745m3a910d2e8677e7fe@mail.gmail.com>
On Wed, 3 Dec 2008, Giuseppe Bilotta wrote:
> On Wed, Dec 3, 2008 at 12:19 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>>
>>> We thus create a new view that can be fed to git-am directly by exposing
>>> the output of git format-patch directly. This allows patch exchange and
>>> submission via gitweb. A hard limit (configurable, defaults to 100) is
>>> imposed on the number of commits which will be included in a patchset,
>>> to prevent DoS attacks on the server.
>>
>> Hmm, I would imagine that "snapshot" would be a much more effective way to
>> do such an attack, and notice the way we prevent it is to selectively
>> enable the feature per repository.
>>
>> Perhaps this configuration should also be a feature defined in %feature,
>> overridable by each repository? If you default it to "disabled" (as any
>> new feature typically does), you do not have to yank a random number such
>> as 100 out of thin air.
>
> I thought about it, but then I thought it was way too useful for
> single patches to disable the feature a priori. I'd rather make the
> default limit much smaller (like the original 16 commits I had in
> mind, or even less).
Perhaps %feature can be used to configure _maximum_ number of patches
in 'patch' / 'format_patch' view (gitweb_get_feature... well, sort of
as gitweb_check_feature would work too), rather than checking if it
is enabled or disabled?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Is there a way to control the number of revisions will be saved by git
From: Jakub Narebski @ 2008-12-03 12:58 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Tzury Bar Yochay, git
In-Reply-To: <49366C03.5080506@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Tzury Bar Yochay schrieb:
> > Say I wish to save only 100 generations back (per branch).
> > Is it possible to configure git so it will save only N records back.
Why would you want that, by the way?
> No.
>
> > If git cannot be configured for that, Is there a way to shrink the
> > repository manually so it will contain the last N generations?
>
> Yes:
>
> $ git rev-parse HEAD~$N >> .git/info/grafts
> $ git filter-branch HEAD
>
> This assumes that your history is strictly linear and you do not have
> tags. It also rewrites the $N commits so that they now have different
> SHA1s. For this reason, don't share this repository with anyone - it leads
> to confusion.
Or just use shallow clone
git clone --depth <depth> <repository>
to have new copy (clone) of <repository> to have only <depth> commits
back. See man git-commit; but it might be not what you want.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Is there a way to control the number of revisions will be saved by git
From: Tzury Bar Yochay @ 2008-12-03 12:47 UTC (permalink / raw)
To: git
In-Reply-To: <2f5ea7490812030301p29e944fw5f59943dc352cd09@mail.gmail.com>
Thanks for your answers.
love git
^ permalink raw reply
* Re: Ad: fast-import problem importing dos format files under cygwin
From: Johannes Sixt @ 2008-12-03 12:18 UTC (permalink / raw)
To: Jan Hudec; +Cc: git
In-Reply-To: <43270.194.138.12.144.1228295417.squirrel@artax.karlin.mff.cuni.cz>
Jan Hudec schrieb:
> On 3 December 2008, 08:51, Jan Hudec wrote:
>> Hello folks,
>>
>> I have been playing with fast-import in cygwin and I have problems
>> importing files with CR/LF line-endings. The size in data command is
>> calculated including the CRs and than the file is copied binary to the
>> fast-import input stream. However fast-import skips the CRs when reading,
>> overreads by that number of bytes and fails when it tries to read the
>> next command from the middle.
>
> One addition:
>
> I have tried with MSYS version 1.5.6.1.1071.g76fb and it imported the
> test, as it was, except it didn't like 'refs/heads/master' as branchname
> (and accepted bare 'master', but that created '.git/master').
With my current version of MinGW git the import is successful after I
edited test1.gfi to match your description (it had CR on all lines; I
removed all except on lines 15 and 16). The repository content is as one
would it expect given the input. master is
b8ad21c3dc271d43a6e43c261909d6be725fa5b8.
Do you happen to have core.autocrlf set in some way and could it make a
difference for fast-import? I have it unset.
-- Hannes
^ permalink raw reply
* Re: [RFCv2 1/2] gitweb: add patch view
From: Giuseppe Bilotta @ 2008-12-03 11:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <7vbpvtecb6.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 3, 2008 at 12:19 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
>> We thus create a new view that can be fed to git-am directly by exposing
>> the output of git format-patch directly. This allows patch exchange and
>> submission via gitweb. A hard limit (configurable, defaults to 100) is
>> imposed on the number of commits which will be included in a patchset,
>> to prevent DoS attacks on the server.
>
> Hmm, I would imagine that "snapshot" would be a much more effective way to
> do such an attack, and notice the way we prevent it is to selectively
> enable the feature per repository.
>
> Perhaps this configuration should also be a feature defined in %feature,
> overridable by each repository? If you default it to "disabled" (as any
> new feature typically does), you do not have to yank a random number such
> as 100 out of thin air.
I thought about it, but then I thought it was way too useful for
single patches to disable the feature a priori. I'd rather make the
default limit much smaller (like the original 16 commits I had in
mind, or even less).
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: Is there a way to control the number of revisions will be saved by git
From: Arafangion @ 2008-12-03 11:37 UTC (permalink / raw)
To: Tzury Bar Yochay; +Cc: git
In-Reply-To: <2f5ea7490812030301p29e944fw5f59943dc352cd09@mail.gmail.com>
On Wed, 2008-12-03 at 13:01 +0200, Tzury Bar Yochay wrote:
<snip>
> Say I wish to save only 100 generations back (per branch).
> Is it possible to configure git so it will save only N records back.
What would be the advantage in doing that? Git is designed so that you
have all your history available, and saves data in such a way that it
really doesn't take much space.
How would git be able to perform a merge from one branch to another if
it didn't have this history available?
That said, you could probably chop off the history you don't want by
doing tricks with grafting, and rewriting all your history, but this
would likely use more disk space because your branches wouldn't have
anything in common, and also make it very difficult to merge in the
future.
^ permalink raw reply
* Re: Is there a way to control the number of revisions will be saved by git
From: Johannes Sixt @ 2008-12-03 11:22 UTC (permalink / raw)
To: Tzury Bar Yochay; +Cc: git
In-Reply-To: <2f5ea7490812030301p29e944fw5f59943dc352cd09@mail.gmail.com>
Tzury Bar Yochay schrieb:
> Hello Happy Gitters,
>
> Say I wish to save only 100 generations back (per branch).
> Is it possible to configure git so it will save only N records back.
No.
> If git cannot be configured for that, Is there a way to shrink the repository
> manually so it will contain the last N generations?
Yes:
$ git rev-parse HEAD~$N >> .git/info/grafts
$ git filter-branch HEAD
This assumes that your history is strictly linear and you do not have
tags. It also rewrites the $N commits so that they now have different
SHA1s. For this reason, don't share this repository with anyone - it leads
to confusion.
-- Hannes
^ 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