* Re: gitweb.cgi feature request: project list "last change" column to display last change of all heads.
From: Junio C Hamano @ 2006-10-15 10:28 UTC (permalink / raw)
To: Pierre Marc Dumuid; +Cc: git
In-Reply-To: <4531FC77.6010004@adelaide.edu.au>
Pierre Marc Dumuid <pierre.dumuid@adelaide.edu.au> writes:
> The annoying thing is that in our mirrored personal repositories, we
> switch from head to head and push new features in different head, and
> then wait for the other developers to review. At the moment, the
> getweb.cgi script only shows the "Last Change" for the current branch,
> and not all branches, (i.e. it's currently showing "13 days ago" for
> cinelerra-pmdumuid, whilst if you click the summary, you'll see I
> actually extended one of the branches only "24 hours ago".
It is fairly expensive to do without recent core-side support,
but if the site runs version of git from the "next" branch,
you should be able to do something like this.
I'll queue this to "next".
-- >8 --
gitweb: use for-each-ref to show the latest activity across branches
The project list page shows last change from the HEAD branch but
often people would want to view activity on any branch.
Unfortunately that is fairly expensive without the core-side
support. for-each-ref was invented exactly for that.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e4ebce6..a78c8db 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1009,6 +1009,24 @@ sub parse_tag {
return %tag
}
+sub git_get_last_activity {
+ my ($path) = @_;
+ my $fd;
+
+ $git_dir = "$projectroot/$path";
+ open($fd, "-|", git_cmd(), 'for-each-ref',
+ '--format=%(refname) %(committer)',
+ '--sort=-committerdate',
+ 'refs/heads') or return;
+ my $most_recent = <$fd>;
+ close $fd or return;
+ if ($most_recent =~ / (\d+) [-+][01]\d\d\d$/) {
+ my $timestamp = $1;
+ my $age = time - $timestamp;
+ return ($age, age_string($age));
+ }
+}
+
sub parse_commit {
my $commit_id = shift;
my $commit_text = shift;
@@ -2258,16 +2276,11 @@ sub git_project_list {
die_error(undef, "No projects found");
}
foreach my $pr (@list) {
- my $head = git_get_head_hash($pr->{'path'});
- if (!defined $head) {
- next;
- }
- $git_dir = "$projectroot/$pr->{'path'}";
- my %co = parse_commit($head);
- if (!%co) {
+ my (@aa) = git_get_last_activity($pr->{'path'});
+ unless (@aa) {
next;
}
- $pr->{'commit'} = \%co;
+ ($pr->{'age'}, $pr->{'age_string'}) = @aa;
if (!defined $pr->{'descr'}) {
my $descr = git_get_project_description($pr->{'path'}) || "";
$pr->{'descr'} = chop_str($descr, 25, 5);
@@ -2317,7 +2330,7 @@ sub git_project_list {
"</th>\n";
}
if ($order eq "age") {
- @projects = sort {$a->{'commit'}{'age'} <=> $b->{'commit'}{'age'}} @projects;
+ @projects = sort {$a->{'age'} <=> $b->{'age'}} @projects;
print "<th>Last Change</th>\n";
} else {
print "<th>" .
@@ -2339,8 +2352,8 @@ sub git_project_list {
-class => "list"}, esc_html($pr->{'path'})) . "</td>\n" .
"<td>" . esc_html($pr->{'descr'}) . "</td>\n" .
"<td><i>" . chop_str($pr->{'owner'}, 15) . "</i></td>\n";
- print "<td class=\"". age_class($pr->{'commit'}{'age'}) . "\">" .
- $pr->{'commit'}{'age_string'} . "</td>\n" .
+ print "<td class=\"". age_class($pr->{'age'}) . "\">" .
+ $pr->{'age_string'} . "</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") . " | " .
^ permalink raw reply related
* [PATCH 1/2] Make write_sha1_file_prepare() void
From: Rene Scharfe @ 2006-10-15 12:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Move file name generation from write_sha1_file_prepare() to the one
caller that cares and make it a void function.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
sha1_file.c | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index d111be7..66cc767 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1347,9 +1347,9 @@ void *read_object_with_reference(const u
}
}
-static char *write_sha1_file_prepare(void *buf, unsigned long len,
- const char *type, unsigned char *sha1,
- unsigned char *hdr, int *hdrlen)
+static void write_sha1_file_prepare(void *buf, unsigned long len,
+ const char *type, unsigned char *sha1,
+ unsigned char *hdr, int *hdrlen)
{
SHA_CTX c;
@@ -1361,8 +1361,6 @@ static char *write_sha1_file_prepare(voi
SHA1_Update(&c, hdr, *hdrlen);
SHA1_Update(&c, buf, len);
SHA1_Final(sha1, &c);
-
- return sha1_file_name(sha1);
}
/*
@@ -1521,7 +1519,8 @@ int write_sha1_file(void *buf, unsigned
/* Normally if we have it in the pack then we do not bother writing
* it out into .git/objects/??/?{38} file.
*/
- filename = write_sha1_file_prepare(buf, len, type, sha1, hdr, &hdrlen);
+ write_sha1_file_prepare(buf, len, type, sha1, hdr, &hdrlen);
+ filename = sha1_file_name(sha1);
if (returnsha1)
hashcpy(returnsha1, sha1);
if (has_sha1_file(sha1))
--
1.4.3.rc2.gdce3
^ permalink raw reply related
* [PATCH 2/2] Replace open-coded version of hash_sha1_file()
From: Rene Scharfe @ 2006-10-15 12:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
sha1_file.c | 8 +-------
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 66cc767..716aef3 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -671,14 +671,8 @@ static void reprepare_packed_git(void)
int check_sha1_signature(const unsigned char *sha1, void *map, unsigned long size, const char *type)
{
- char header[100];
unsigned char real_sha1[20];
- SHA_CTX c;
-
- SHA1_Init(&c);
- SHA1_Update(&c, header, 1+sprintf(header, "%s %lu", type, size));
- SHA1_Update(&c, map, size);
- SHA1_Final(real_sha1, &c);
+ hash_sha1_file(map, size, type, real_sha1);
return hashcmp(sha1, real_sha1) ? -1 : 0;
}
--
1.4.3.rc2.gdce3
^ permalink raw reply related
* Re: gitweb.cgi feature request: project list "last change" column to display last change of all heads.
From: Jakub Narebski @ 2006-10-15 12:17 UTC (permalink / raw)
To: git
In-Reply-To: <4531FC77.6010004@adelaide.edu.au>
Pierre Marc Dumuid wrote:
> I am working with the Cinelerra-CV group (cvs.cinelerra.org) and we are
> starting to use git to develop new patches. Someone has offered to
> mirror our git branches to share amongst ourselves at
> http://www.pipapo.org/gitweb.
>
> The annoying thing is that in our mirrored personal repositories, we
> switch from head to head and push new features in different head, and
> then wait for the other developers to review. At the moment, the
> getweb.cgi script only shows the "Last Change" for the current branch,
> and not all branches, (i.e. it's currently showing "13 days ago" for
> cinelerra-pmdumuid, whilst if you click the summary, you'll see I
> actually extended one of the branches only "24 hours ago".
This feature is planned (even if I forgot to mention it in the latest
"[RFC] gitweb wishlist and TODO list"[*1*] thread), but for performance
reasons it waits for git-for-each-ref to be in released version of git, as
it should be used for projects list to not be generated too slow.
But we could add it (although git is now in freezer before 1.4.3 release).
I was thinking about using
$feature{'lastchange'}{'default'} = HEAD | <branchname> | undef
where undef means search all branches for latest commit.
> 2nd feature request it the ability to browse to the next / previous
> commit when looking at a commitdiff...
First, merges can have more than one parent, so "previous" (or rather
"parent") can be ambiguous. Well, we could use first parent... But even
now it is fairly easy to go to the parent commitdiff: click on "commit"
link in the top navigation bar, or on the subject of commit; then click
on the "parent" link in the commit view; then click on "commitdiff" link
in the top navigation bar, or on the subject of commit.
Git philosophy and design precludes any kind of "next" link. Commit object
has only links to parents, never to children. If one really, really need
"next" link, one would need to save branch and where on branch we are
(in the git-name-rev way, e.g. b=HEAD~10) and pray somebody didn't update
the branch.
It should be quite easy to add commit+commitdiff view, though.
[*1*] http://marc.theaimsgroup.com/?t=115082282700003&r=1&w=2
Msg-Id: <egdge3$t12$1@sea.gmane.org>
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Recent and near future backward incompatibilities
From: Horst H. von Brand @ 2006-10-15 14:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds, Stephen Hemminger
In-Reply-To: <7v4pu62ite.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> It was brought to my attention that the public git.git
> repository cannot be cloned with older versions of git. [...]
There seem to be a bunch of incompatible changes comming up... how about
scheduling them for a 2.0 version, soon(ish)?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* [RFC] Ideas for new "stats" view in gitweb
From: Jakub Narebski @ 2006-10-15 15:17 UTC (permalink / raw)
To: git
In-Reply-To: <egj1g6$bk6$1@sea.gmane.org>
Jakub Narebski wrote:
> Jakub Narebski wrote:
>
>> * Graph of number of changed files in given branch; probably should be
>> cached.
>
> See for example StatCVS and FishEye
> http://www-128.ibm.com/developerworks/java/library/j-statcvs/
> http://statcvs.sourceforge.net/statcvs-stats/
>
> http://fisheye.codehaus.org/browse/activecluster
See also StatCVS-XML (http://statcvs-xml.berlios.de) and SvnStat
(http://svnstat.sourceforge.net), both derivatives of StatCVS, with
a few plots/charts added. If you know other graphical SCM statistics
tools, please mention them.
Would additional "stats" view help? Does some bit of stats help (well,
besides diffstat in commitdiff; perhaps later graphical diffstat in
gitweb)?
For example all (I think) above projects include plot of "size" (usually in
lines of code) of repository versus time, sometimes split into few top
authors or few top subdirectories; sometimes limited to some subdirectory or
even to some file only, together with the plot of "commit volume" (usually
number of commits per unit, e.g. number of commits per day, but it could be
numbers of files changed and/or number of lines added/deleted) vs time.
Tags are marked on the time scale. This supposedly helps to realize if
project/part of project/individual file is in development, refactoring or
maintenace stage. And graph with different top authors plotted using
different lines visualises which were active during which point of project
history. I'm not sure what "commit volume" plot tells us.
Next there are various tables and plots gathering statistics about authors:
lines of code + percentage, numbers of changes (commits) + percentage,
average number of lines per change, ratio of modifications to adding new
code. Git has git-shortlog for creating similar summary. That probably
helps to realize who takes what part in development of project. And there
can be similar tables, charts and plots but with module/subdirectory/file
instead of author. For example top files with respect to size, changes,
or number of revisions in history.
Then there are IMVHO not very useful (except for satisfying idle curiosity)
histograms of activity (either number of commits, or number of changed
lines) per hour of day, or per day of week, or per month of year (in older
projects).
There are some other plots, charts, tables, graphs... Please do tell which
ones would be good to have in gitweb.
BTW. we most certainly would have to use some cache I guess... and we have
just removed the need for temporary files for creating diffs...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Recent and near future backward incompatibilities
From: Nicolas Pitre @ 2006-10-15 15:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds, Stephen Hemminger
In-Reply-To: <7v4pu62ite.fsf@assigned-by-dhcp.cox.net>
On Sat, 14 Oct 2006, Junio C Hamano wrote:
> It was brought to my attention that the public git.git
> repository cannot be cloned with older versions of git. More
> precisely, packs generated with post 16854571 (NOT contained in
> v1.4.2.3 but in the current "master" and more importantly in
> v1.4.3-rc3 which I tagged tonight) can contain deltas that are
> not compatible with the version of git before d60fc1c8, which
> means that v1.1.6 and older (v1.2.0 and later are Ok).
Ahhhhhh. DAMN !
> One thing we can and should immediately do is to revert 16854571
> for now until we decide how to resolve this issue cleanly.
>
> These are what needs to happen but one of them is quite tricky:
>
> - the reusing of delta is what makes pack-objects practical,
> and it is expensive to look into existing delta to see if it
> is version 2 or version 3 before deciding to reuse each delta
> data, so even if we update pack-objects so that we can tell
> it to generate a pack that contains only version 2 deltas, it
> would be very expensive to do so and may not be practical.
Why not? After all users of GIT versions that don't understand pack
version 3 should be a very small minority by now.
> am not sure how to resolve this issue efficiently right now;
> we need a bit of thinking.
Actually it doesn't have to be that expensive to convert deltas v2 to
deltas v3 on the fly. They can be inflated, parsed, the copy ops that
exceed 0x10000 converted into multiple ops of smaller copy blocks, then
deflated. This is certainly much less costly than rematching deltas
from scratch.
Well I'd say you just revert pack v3 generation patch for now and
release v1.4.3 without it. Pack v3 generation can wait a bit longer
until we implement the above or users of GIT that can read packs v2 only
are so few that we shouldn't care anymore and tell them to use an
intermediate version of GIT in order to clone the latest. It is not
like if that makes such a big difference on pack size anyway (much less
than delta with offsets to base actually).
> - we need to add .git/config item that tells pack-objects to
> never generate version 3 delta for that particular
> repository. This is similar to the way we would need to
> control the use of delta-base-offset representation currently
> cooking in "next".
This is different. The delta-base-offset representation is decided at
run time every time a pack is generated and regardless if delta data is
being reused from another pack or regenerated afresh, and so with no
cost. So this is no issue for users of old GIT versions since the
native GIT protocol already handle it in a backward compatible manner.
The only issue here concerns users that don't use the native GIT
protocol. But in this case they have two options: either they switch to
the native protocol, or they upgrade to the latest GIT version which
can always be pulled with the native GIT protocol.
> We may have a similar issue when enabling generation of loose
> objects with new style headers. This is already controlled with
> the core.legacyheaders configuration item.
Sure, but those are never passed through the native GIT protocol which
makes it a much less critical issue.
Not being able to upgrade to the latest GIT in order to actually cope
with the new format because the primary GIT repository started to feed
old GIT versions with that new format unconditionally really is a
problem though.
I think we should not bend backward too much with repository
compatibility issues as long as there is no interoperability issues at
the protocol level. But the GIT protocol must always remain
interoperable with whatever GIT version still in use.
Nicolas
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-15 15:37 UTC (permalink / raw)
To: git
In-Reply-To: <9e4733910610141606g749d268eudd85791620e1363a@mail.gmail.com>
Jon Smirl wrote:
> The three most complex repositories are the kernel, gcc and Mozilla.
> Gcc is in SVN now. Mozilla CVS and the kernel git.
>
> There are much larger repositories around for some of the distros, but
> they are doing things like checking ISO images in to the repo which
> just makes it big,, not complex.
I guess that one of the important thinkgs is the _size_ of the repository;
for example 12GB (if I remember correctly value for Subversion/SVK) vs 500MB
for git...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] pack-objects: use of version 3 delta is now optional.
From: Nicolas Pitre @ 2006-10-15 15:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7virim10rb.fsf@assigned-by-dhcp.cox.net>
On Sun, 15 Oct 2006, Junio C Hamano wrote:
> This introduces a new configuration item, pack.deltaversion, to
> control whether pack-objects is allowed to use version 3 delta.
> By default, we keep generating version 2 delta (and version 2
> packfile format) to be compatible with git earlier than v1.2.0.
>
> This configuration affects the command in the following ways:
>
> - the resulting packfile will have the specified version;
>
> - when generating delta, larger copies are allowed only when
> deltaversion is 3;
>
> - the logic to reuse delta from existing packs refuses to reuse
> delta from packs that uses delta version 3 when the
> configuration is set to 2.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
I'd suggest to drop this altogether. See my previous email for my
reasoning on this issue. I think this should be done another way.
If anything, maybe this patch can be added before v1.4.3 is released:
diff --git a/fetch-pack.c b/fetch-pack.c
index 7d23a80..1688417 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -165,9 +165,10 @@ static int find_common(int fd[2], unsign
continue;
}
- packet_write(fd[1], "want %s%s%s\n", sha1_to_hex(remote),
+ packet_write(fd[1], "want %s%s%s%s\n", sha1_to_hex(remote),
(multi_ack ? " multi_ack" : ""),
- (use_thin_pack ? " thin-pack" : ""));
+ (use_thin_pack ? " thin-pack" : ""),
+ " packv3");
fetching++;
}
packet_flush(fd[1]);
diff --git a/upload-pack.c b/upload-pack.c
index 979e583..8e57316 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -218,7 +218,7 @@ static int receive_needs(void)
static int send_ref(const char *refname, const unsigned char *sha1)
{
- static char *capabilities = "multi_ack thin-pack";
+ static char *capabilities = "multi_ack thin-pack packv3";
struct object *o = parse_object(sha1);
if (!o)
This way pack v3 could be fed to GIT v1.4.3 and above whenever we add
back pack v3 generation, and a pack converted to v2 from any v3 on the
fly when that capability is not present.
Nicolas
^ permalink raw reply related
* svn revision id in git commit?
From: Anand Kumria @ 2006-10-15 16:59 UTC (permalink / raw)
To: git
Hi,
I'm using git-svnimport with great success; generally when I do a merge
from the subversion (via git-svnimport) I tag the revision number I merge
up to.
It'd be very helpful if git-svnimport stored the revision number that
caused a particular commit to be generated -- is this possible? Would this
be a 'note' field in a git commit? Has anyone else done work on
git-svnimport to store this?
If not, I'll probably give it a go shortly.
Thanks,
Anand
^ permalink raw reply
* Re: [PATCH] pack-objects: use of version 3 delta is now optional.
From: Junio C Hamano @ 2006-10-15 18:10 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0610151135110.17085@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Sun, 15 Oct 2006, Junio C Hamano wrote:
>
>> This introduces a new configuration item, pack.deltaversion, to
>> control whether pack-objects is allowed to use version 3 delta.
>> By default, we keep generating version 2 delta (and version 2
>> packfile format) to be compatible with git earlier than v1.2.0.
>...
> I'd suggest to drop this altogether. See my previous email for my
> reasoning on this issue. I think this should be done another way.
I'll think about it a bit.
> If anything, maybe this patch can be added before v1.4.3 is released:
>...
> This way pack v3 could be fed to GIT v1.4.3 and above whenever we add
> back pack v3 generation, and a pack converted to v2 from any v3 on the
> fly when that capability is not present.
I think that is sensible. I also was thinking that we should
call the current one packv3 and the one with delta-base-offset
packv4.
^ permalink raw reply
* Re: Recent and near future backward incompatibilities
From: Junio C Hamano @ 2006-10-15 18:14 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Linus Torvalds, Stephen Hemminger
In-Reply-To: <Pine.LNX.4.64.0610151133450.17085@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> Actually it doesn't have to be that expensive to convert deltas v2 to
> deltas v3 on the fly. They can be inflated, parsed, the copy ops that
> exceed 0x10000 converted into multiple ops of smaller copy blocks, then
> deflated. This is certainly much less costly than rematching deltas
> from scratch.
True, when I think about it.
>> - we need to add .git/config item that tells pack-objects to
>> never generate version 3 delta for that particular
>> repository. This is similar to the way we would need to
>> control the use of delta-base-offset representation currently
>> cooking in "next".
>
> This is different. The delta-base-offset representation is decided at
> run time every time a pack is generated and regardless if delta data is
> being reused from another pack or regenerated afresh, and so with no
> cost. So this is no issue for users of old GIT versions since the
> native GIT protocol already handle it in a backward compatible manner.
>
> The only issue here concerns users that don't use the native GIT
> protocol. But in this case they have two options: either they switch to
> the native protocol, or they upgrade to the latest GIT version which
> can always be pulled with the native GIT protocol.
True again. Thanks.
^ permalink raw reply
* Re: [PATCH] pack-objects: use of version 3 delta is now optional.
From: Jakub Narebski @ 2006-10-15 18:18 UTC (permalink / raw)
To: git
In-Reply-To: <7vac3xzbze.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I think that is sensible. I also was thinking that we should
> call the current one packv3 and the one with delta-base-offset
> packv4.
Just curious: what was the difference between packv1 and packv2,
and packv3 and packv4?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-15 18:23 UTC (permalink / raw)
To: Jon Smirl; +Cc: Jakub Narebski, git
In-Reply-To: <9e4733910610141606g749d268eudd85791620e1363a@mail.gmail.com>
Dear diary, on Sun, Oct 15, 2006 at 01:06:10AM CEST, I got a letter
where Jon Smirl <jonsmirl@gmail.com> said that...
> On 10/14/06, Jakub Narebski <jnareb@gmail.com> wrote:
> >There is work by Jon Smirl and Shawn Pearce on CVS to Git importer which
> >can
> >manage large and complicated (read: f*cked-up) Mozilla CVS repository.
> > http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#cvs2git
>
> I am still working with the developers of the cvs2svn import tool to
> fix things so that Mozilla CVS can be correctly imported. There are
> still outstanding bugs in cvs2svn preventing a correct import. MozCVS
> can be imported, but the resulting repository is not entirely correct.
>
> Once they get the base cvs2svn fixed I'll port my patches to turn it
> into cvs2git again.
So what exactly is the cvs2git status now? AFAIU, there's a tool that
parses the CVS repository and that is then "piped" to git-fastimport?
git-fastimport is available somewhere (perhaps it would be interesting
to publish it at repo.or.cz or something), is the current cvs2git
version available as well?
> >2. Good support for system which most important developers use, and good
> >support for system which most contributors use. If MS Windows is included
> >in those, then Git perhaps wouldn't be the best choice.
>
> Better Windows support is needed to make git the first choice among
> the various SCMs.
And this is probably not likely to happen soon.
Well, I'm enlisted in a "Programming in Windows" course at my university
now and I had this kind of thoughts, but I really can't promise
anything. :-)
> >4. Good support for _large_ project, with large history. Namely, that
> >developer wouldn't need to download many megabytes and/or wouldn't need
> >megabytes of working area. How that is solved, be it partial checkouts,
> >lazy/shallow/sparse clone, subprojects, splitting into
> >projects/repositories and having some superproject or build-time
> >superproject, splitting repository into current and historical... that of
> >course depends on SCM.
>
> git has issues here. The smallest Mozilla download we have built so
> far is 450MB for the initial checkout.
(BTW, yes, grafting the old history could help this time, but it is a
hack and not a good long-term solution - it is just putting the real
solution away until the project history will re-grew. Periodical
regrafting is even worse hack, since at that moment you break
fast-forwarding and this kind of "restarting the history" breaks deep
into the Git distributiveness.)
> >5. ....
> >
> >and probably few more
>
>
> The three most complex repositories are the kernel, gcc and Mozilla.
> Gcc is in SVN now. Mozilla CVS and the kernel git.
I believe OpenOffice CVS probably beats all three hands down very
easily. KDE is also very big, and I don't think NetBSD is just ISO
images either (if it contains any at all).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] pack-objects: use of version 3 delta is now optional.
From: Nicolas Pitre @ 2006-10-15 18:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vac3xzbze.fsf@assigned-by-dhcp.cox.net>
On Sun, 15 Oct 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > If anything, maybe this patch can be added before v1.4.3 is released:
> >...
> > This way pack v3 could be fed to GIT v1.4.3 and above whenever we add
> > back pack v3 generation, and a pack converted to v2 from any v3 on the
> > fly when that capability is not present.
>
> I think that is sensible. I also was thinking that we should
> call the current one packv3 and the one with delta-base-offset
> packv4.
I think we should not. The pack version should be tied to incompatible
pack data to prevent older GIT versions from misinterpreting newer
packs. The delta block copy encoding is a perfect example of that where
a bit changed meaning.
The delta-base-offset case included a new object type that wasn't used
before hence there is no room for confusion, and yet that new delta
object could be encoded according to pack version 2 or pack version 3
which makes it orthogonal to the pack version itself.
Nicolas
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-15 18:39 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jon Smirl, Jakub Narebski, git
In-Reply-To: <20061015182303.GW20017@pasky.or.cz>
On Sun, 15 Oct 2006 20:23:03 +0200
Petr Baudis <pasky@suse.cz> wrote:
> (BTW, yes, grafting the old history could help this time, but it is a
> hack and not a good long-term solution - it is just putting the real
> solution away until the project history will re-grew. Periodical
> regrafting is even worse hack, since at that moment you break
> fast-forwarding and this kind of "restarting the history" breaks deep
> into the Git distributiveness.)
But is there a better practical solution he can use today? I don't think
there is. And the experience of the Linux kernel has shown that it's not
really all that big a problem. You even made a nice script to help people
do it! ;o)
It's probably not the solution that should be used _next_ time the repository
grows too big, but it sure seems like the correct solution this time around.
Not many people will want all that old history anyway (10+ years as i recall?).
Sean
^ permalink raw reply
* Re: [PATCH] pack-objects: use of version 3 delta is now optional.
From: Nicolas Pitre @ 2006-10-15 18:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <egtu1r$813$1@sea.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1310 bytes --]
On Sun, 15 Oct 2006, Jakub Narebski wrote:
> Junio C Hamano wrote:
>
> > I think that is sensible. I also was thinking that we should
> > call the current one packv3 and the one with delta-base-offset
> > packv4.
>
> Just curious: what was the difference between packv1 and packv2,
> and packv3 and packv4?
Pack v1 was really short-lived (one day or two). It used a different
encoding for object size and delta size than what exists today. When
the current encoding was adopted the pack version was bumped to 2 to
make sure anyone, if any, who might have started to rely upon packs in
those early days would not end up trying to use incompatible pack data.
Backward compatibility was not a concern at all back then of course.
So for all practical purposes just consider that pack version 1 never
existed.
Pack version 3 simply redefined one bit in the delta encoding that was
never used. The former definition of the bit was implemented in the
decode part, but attempts to use it in the encode part turned up to be
way too costly for really really poor benefits. for details just have a
look at commit d60fc1c8649f80c006b9f493c542461e81608d4b.
As for pack v4... My opinion is that nothing justifies it so far. So if
I can convince Junio there shouldn't be any v4 just yet.
Nicolas
^ permalink raw reply
* Re: [PATCH] pack-objects: use of version 3 delta is now optional.
From: Linus Torvalds @ 2006-10-15 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vac3xzbze.fsf@assigned-by-dhcp.cox.net>
On Sun, 15 Oct 2006, Junio C Hamano wrote:
>
> I think that is sensible. I also was thinking that we should
> call the current one packv3 and the one with delta-base-offset
> packv4.
Quite frankly, I wonder if the pure "copy size extension" (aka "v3") thing
is really worth it at all.
I mean, seriously, how much does it buy us? A couple of bytes per every
64kB of delta copied? And the downside is that you can't re-use the deltas
with old clients and/or you have to re-create a "v2" delta at run-time
from a v3 delta by inflating, fixing and deflating it.
So I would suggest:
- call the delta-base-offset thing the "v3" pack format.
- forget about the current "v3 delta" entirely. We might as well continue
to support reading it, but there's no point in actually ever generating
it.
In other words, I think the current situation in top-of-master is the
right situation. There's simply no point in adding code to convert v3 to
v2 on the fly - even if it's not rocket science, it's just not _worth_ it.
(You could also have the extended copy deltas in v3-only, and only send it
to clients that you know supports it. However, the "convert to v2" format
issue still rears its ugly head, and as a result I just don't think it's
_ever_ worth it).
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-15 19:24 UTC (permalink / raw)
To: Sean; +Cc: Jon Smirl, Jakub Narebski, git
In-Reply-To: <20061015143956.86db3a8b.seanlkml@sympatico.ca>
On Sun, Oct 15, 2006 at 08:39:56PM CEST, Sean wrote:
> On Sun, 15 Oct 2006 20:23:03 +0200
> Petr Baudis <pasky@suse.cz> wrote:
>
> > (BTW, yes, grafting the old history could help this time, but it is a
> > hack and not a good long-term solution - it is just putting the real
> > solution away until the project history will re-grew. Periodical
> > regrafting is even worse hack, since at that moment you break
> > fast-forwarding and this kind of "restarting the history" breaks deep
> > into the Git distributiveness.)
>
> But is there a better practical solution he can use today? I don't think
> there is. And the experience of the Linux kernel has shown that it's not
> really all that big a problem. You even made a nice script to help people
> do it! ;o)
>
> It's probably not the solution that should be used _next_ time the repository
> grows too big, but it sure seems like the correct solution this time around.
> Not many people will want all that old history anyway (10+ years as i recall?).
Well I'm not saying it's the incorrect solution today, only that we
won't get around the problem by suggesting grafting forever. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] pack-objects: use of version 3 delta is now optional.
From: A Large Angry SCM @ 2006-10-15 19:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git, Linus Torvalds
In-Reply-To: <7vac3xzbze.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
[...]
>
> I think that is sensible. I also was thinking that we should
> call the current one packv3 and the one with delta-base-offset
> packv4.
+1
^ permalink raw reply
* Re: VCS comparison table
From: Jon Smirl @ 2006-10-15 19:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, git
In-Reply-To: <20061015182303.GW20017@pasky.or.cz>
On 10/15/06, Petr Baudis <pasky@suse.cz> wrote:
> > I am still working with the developers of the cvs2svn import tool to
> > fix things so that Mozilla CVS can be correctly imported. There are
> > still outstanding bugs in cvs2svn preventing a correct import. MozCVS
> > can be imported, but the resulting repository is not entirely correct.
> >
> > Once they get the base cvs2svn fixed I'll port my patches to turn it
> > into cvs2git again.
>
> So what exactly is the cvs2git status now? AFAIU, there's a tool that
> parses the CVS repository and that is then "piped" to git-fastimport?
> git-fastimport is available somewhere (perhaps it would be interesting
> to publish it at repo.or.cz or something), is the current cvs2git
> version available as well?
cvs2git is a set of patches that get applied to cvs2svn. The patches
modify cvs2svn to output things in a format that git-fastimport can
consume.
The problem is that there are issues with cvs2svn and how it converts
CVS into change sets that are not getting fixed. These issues are
annoying for SVN users but they are fatal for git. The exact problem
is a bug in the way CVS symbol dependencies are dealt with in cvs2svn.
The bug results in most branches and symbols being based off from 5-7
different change sets instead of a single change set. SVN then copies
from the 5-7 change sets to build the branch base or symbol base.
Copying from the 5-7 change sets is addressing the symptoms of the bug
instead of fixing the underlying problem which is incorrect ordering
of the base change sets.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] pack-objects: use of version 3 delta is now optional.
From: A Large Angry SCM @ 2006-10-15 20:00 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0610151422510.17085@xanadu.home>
Nicolas Pitre wrote:
> On Sun, 15 Oct 2006, Junio C Hamano wrote:
>
>> Nicolas Pitre <nico@cam.org> writes:
>>
>>> If anything, maybe this patch can be added before v1.4.3 is released:
>>> ...
>>> This way pack v3 could be fed to GIT v1.4.3 and above whenever we add
>>> back pack v3 generation, and a pack converted to v2 from any v3 on the
>>> fly when that capability is not present.
>> I think that is sensible. I also was thinking that we should
>> call the current one packv3 and the one with delta-base-offset
>> packv4.
>
> I think we should not. The pack version should be tied to incompatible
> pack data to prevent older GIT versions from misinterpreting newer
> packs. The delta block copy encoding is a perfect example of that where
> a bit changed meaning.
>
> The delta-base-offset case included a new object type that wasn't used
> before hence there is no room for confusion, and yet that new delta
> object could be encoded according to pack version 2 or pack version 3
> which makes it orthogonal to the pack version itself.
It's not a new object type. It's a new object _encoding_ method.
^ permalink raw reply
* Re: svn revision id in git commit?
From: Robin Rosenberg @ 2006-10-15 20:25 UTC (permalink / raw)
To: Anand Kumria; +Cc: git
In-Reply-To: <egtpe4$i8v$1@sea.gmane.org>
söndag 15 oktober 2006 18:59 skrev Anand Kumria:
> Hi,
>
> I'm using git-svnimport with great success; generally when I do a merge
> from the subversion (via git-svnimport) I tag the revision number I merge
> up to.
The -r flags adds the subversion revision to the commit message. It's in the
man page.
BTW, you may want to look at git-svn if you are shadowing a subversion repo.
It adds then subversion revision by default. Neither creates a tag though.
-- robin
^ permalink raw reply
* [PATCH] git-fetch: Understand the branch property remote="."
From: Santi Béjar @ 2006-10-15 21:16 UTC (permalink / raw)
To: git
It extends the branch property "remote" to understand that "." is the local
repository.
With this, for example, in git.git you could have:
[branch "next"]
remote="."
merge=master
so the default merge in the next branch is the master branch in the
local repository.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
git-parse-remote.sh | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 679f73c..617d022 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -187,6 +187,15 @@ get_remote_refs_for_push () {
}
get_remote_refs_for_fetch () {
+ if [ "$#,$1" = "1,." ] ;
+ then
+ curr_branch=$(git-symbolic-ref HEAD | sed -e 's|^refs/heads/||')
+ branch_remote=$(git-repo-config --get "branch.$curr_branch.remote")
+ if [ "$branch_remote" = "." ]
+ then
+ set . $(git-repo-config --get-all "branch.${curr_branch}.merge")
+ fi
+ fi
case "$#" in
0)
die "internal error: get-remote-refs-for-fetch." ;;
--
1.4.3.rc2.ga442
^ permalink raw reply related
* RE: git-svn and u-boot broken.
From: Joakim Tjernlund @ 2006-10-15 22:09 UTC (permalink / raw)
To: 'Eric Wong'; +Cc: git
> > > Any chance you can update it with more examples?
> > > Especially one that show how one can do one big initial
> > > commit then merge your own changes on top of that?
> >
> > Hmm.. large imports from git to svn can get confusing, and generally
> > aren't very useful on the svn side since history gets flattened.
> > So I generally don't recommend importing complete git histories into
> > svn.
>
> Yes, that's what I am trying to avoid below. Basically I want
> to commit to SVN the
> whole u-boot tree as one commit up to the point where I
> started to do my changes.
> Then I want my changes per commit on top of that. However I
> don't want to loose the
> ability to merge/pull in future updates from denx u-boot tree.
>
> I just don't know how to do it, the script below fails when
> it tries to
> pull the rest of the tree. Any ideas?
I really need some advice here, if you can share some ideas that would be great.
>
> >
> > > Something like this
> > > REPO="file:///tmp/SVNuboot"
> > > REPO_PATH="/tmp/SVNuboot"
> > > GIT_REPO="/tmp/mygituboot"
> > > ORG_REPO="/usr/local/src/u-boot"
> > > rm -rf "$REPO_PATH"
> > > rm -rf "$GIT_REPO"
> > > svnadmin create "$REPO_PATH"
> > > svn mkdir -m "initial repo layout" "$REPO"/trunk
> > "$REPO"/branches "$REPO"/tags
> > > mkdir -p "$GIT_REPO"
> > > cd "$GIT_REPO"
> > > git-svn init "$REPO"/trunk
> > > echo [user] >> .git/config
> > > echo name="jocke" >> .git/config
> > > echo email="Joakim.Tjernlund@transmode.se" >> .git/config
> > > git-svn fetch
> > > git checkout -b svn-branch remotes/git-svn
> > > git-fetch "$ORG_REPO" tmcu2:tmcu
> > > git-branch initial-uboot f5e0d03970409feb3c77ab0107d5dece6b7d45c9
> > > git pull . initial-uboot
> > > # --squash makes one large commit.
> > > git pull --squash . initial-uboot
> > > cg-commit -m "merge up to
> f5e0d03970409feb3c77ab0107d5dece6b7d45c9"
> > > git-svn commit -q remotes/git-svn..svn-branch
> > > git pull . tmcu # This doesn't work, I get merge conflicts
> > > git-svn commit -q remotes/git-svn..svn-branch
> > >
> > > Anyhow, I am glad to report that after applying your patch all my
> > > problems with went away, no more Too many open file desc, memory
> > > alloc failed or Inappropriate ioctl for device, Thanks a lot.
> >
> > Cool, good to know. It seems like the apply_textdelta
> returning undef
> > was a result of memory allocation failures, then.
>
> Or possibly the older subversion I used(1.3.2), now I am on 1.4.0
>
^ 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