* 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
* gitweb.cgi feature request: project list "last change" column to display last change of all heads.
From: Pierre Marc Dumuid @ 2006-10-15 9:16 UTC (permalink / raw)
To: git
Hi,
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".
2nd feature request it the ability to browse to the next / previous
commit when looking at a commitdiff...
^ permalink raw reply
* Re: [PATCH] pack-objects: use of version 3 delta is now optional.
From: Jakub Narebski @ 2006-10-15 9:09 UTC (permalink / raw)
To: git
In-Reply-To: <7virim10rb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> This introduces a new configuration item, pack.deltaversion, to
> control whether pack-objects is allowed to use version 3 delta.
Documentation, please?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* I've tagged 1.4.3-rc3 but there is a last-minute monkey wrench...
From: Junio C Hamano @ 2006-10-15 8:04 UTC (permalink / raw)
To: git
Changes since -rc2 are mostly fixes:
- Christian Couder fixed the tracing facility so that
"GIT_TRACE= git-foo" and "unset GIT_TRACE; git-foo" to
behave the same;
- Assorted git-svn fixes from Eric Wong;
- Johannes fixed "diff -w -b";
- Also Johannes has two fixes to cvsserver;
- http-fetch transport does not use webdav to discover remote
refs anymore;
- breakage in generating RPM (perl-Git) has been fixed;
- "git-apply --numstat -z" did not terminate line with NUL -- fixed;
- Martin Waitz made "git diff" to run pager by default;
- Nicolas Pitre made sideband remote messages to be written out
with single write(2) to prevent them from being broken up;
- Rene Scharfe has a good API clean-up: hash_sha1_file();
- Yasushi SHOJI noticed and fixed that "git-clone" did not
correctly handle the origin repository specified as a
relative directory; it treated it relative to the new
repository not the directory the command was started from.
But there is already one commit that is rather important on the
"master" branch after -rc3. It is needed so that we do not
break git older than v1.2.0 (Feb 12, 2006).
I am still hoping we can declare v1.4.3 on coming Wednesday,
unless it is eaten by my day job (which is unfortunately not so
unusual for me these days), in which case we would have to defer
it until next weekend.
^ permalink raw reply
* [PATCH] pack-objects: use of version 3 delta is now optional.
From: Junio C Hamano @ 2006-10-15 7:44 UTC (permalink / raw)
To: git; +Cc: Nicolas Pitre, Linus Torvalds
In-Reply-To: <7v4pu62ite.fsf@assigned-by-dhcp.cox.net>
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>
---
* Nico, I'd really appreciate it if you can eyeball this
patch. For the upcoming v1.4.3, we'd at least want to
revert:
commit 16854571aae6302f457c5fbee41ac64669b09595
Author: Nicolas Pitre <nico@cam.org>
Date: Thu Sep 21 00:11:59 2006 -0400
move pack creation to version 3
It's been quite a while now that GIT is able to read version 3 packs.
Let's create them at last.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
but I'd like to allow people to explicitly tell what version
is to be created by default per repository to avoid future
problems.
For now it would be advised to leave this configuration empty
in public repositories, which would cause them to have
version 2 packs. People who know their repositories are only
used with git v1.2.0 or newer can use the configuration to
allow version 3 packs.
We should later add a command line override to pack-objects
to explicitly say which delta version to be used, so that
pack protocol can negotiate the allowed delta version between
client and the server and pass that command line option when
upload-pack runs pack-objects.
builtin-pack-objects.c | 16 ++++++++++++----
cache.h | 1 +
delta.h | 2 ++
diff-delta.c | 15 +++++++++++++--
environment.c | 3 +++
sha1_file.c | 1 +
6 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 96c069a..4d2147b 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -456,7 +456,7 @@ static void write_pack_file(void)
fprintf(stderr, "Writing %d objects.\n", nr_result);
hdr.hdr_signature = htonl(PACK_SIGNATURE);
- hdr.hdr_version = htonl(PACK_VERSION);
+ hdr.hdr_version = htonl(delta_version);
hdr.hdr_entries = htonl(nr_result);
sha1write(f, &hdr, sizeof(hdr));
offset = sizeof(hdr);
@@ -914,12 +914,15 @@ static void check_object(struct object_e
/* Check if it is delta, and the base is also an object
* we are going to pack. If so we will reuse the existing
* delta.
+ *
+ * Also make sure that we do not reuse delta from an existing
+ * pack that uses higher delta version than allowed.
*/
if (!no_reuse_delta &&
entry->in_pack_type == OBJ_DELTA &&
(base_entry = locate_object_entry(base)) &&
- (!base_entry->preferred_base)) {
-
+ (!base_entry->preferred_base) &&
+ entry->in_pack->pack_version <= delta_version) {
/* Depth value does not matter - find_deltas()
* will never consider reused delta as the
* base object to deltify other objects
@@ -1326,10 +1329,15 @@ static void setup_progress_signal(void)
static int git_pack_config(const char *k, const char *v)
{
- if(!strcmp(k, "pack.window")) {
+ if (!strcmp(k, "pack.window")) {
window = git_config_int(k, v);
return 0;
}
+ if (!strcmp(k, "pack.deltaversion")) {
+ delta_version = git_config_int(k, v);
+ if (!pack_version_ok(htonl(delta_version)))
+ die("value %s for '%s' not allowed", v, k);
+ }
return git_default_config(k, v);
}
diff --git a/cache.h b/cache.h
index c354701..724c09a 100644
--- a/cache.h
+++ b/cache.h
@@ -337,6 +337,7 @@ extern struct packed_git {
unsigned int pack_last_used;
unsigned int pack_use_cnt;
int pack_local;
+ int pack_version;
unsigned char sha1[20];
/* something like ".git/objects/pack/xxxxx.pack" */
char pack_name[FLEX_ARRAY]; /* more */
diff --git a/delta.h b/delta.h
index 7b3f86d..55af3d2 100644
--- a/delta.h
+++ b/delta.h
@@ -1,6 +1,8 @@
#ifndef DELTA_H
#define DELTA_H
+extern int delta_version;
+
/* opaque object for delta index */
struct delta_index;
diff --git a/diff-delta.c b/diff-delta.c
index fa16d06..2f6dcfb 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -253,10 +253,13 @@ create_delta(const struct delta_index *i
int inscnt;
const unsigned char *ref_data, *ref_top, *data, *top;
unsigned char *out;
+ unsigned int ref_size_limit;
if (!trg_buf || !trg_size)
return NULL;
+ ref_size_limit = (delta_version > 2) ? 0xffffff : 0x10000;
+
outpos = 0;
outsize = 8192;
if (max_size && outsize >= max_size)
@@ -308,8 +311,8 @@ create_delta(const struct delta_index *i
continue;
if (ref_size > top - src)
ref_size = top - src;
- if (ref_size > 0x10000)
- ref_size = 0x10000;
+ if (ref_size > ref_size_limit)
+ ref_size = ref_size_limit;
if (ref_size <= msize)
break;
while (ref_size-- && *src++ == *ref)
@@ -318,6 +321,8 @@ create_delta(const struct delta_index *i
/* this is our best match so far */
msize = ref - entry->ptr;
moff = entry->ptr - ref_data;
+ if (delta_version > 2 && msize >= 0x10000)
+ break; /* this is good enough */
}
}
@@ -381,6 +386,12 @@ create_delta(const struct delta_index *i
if (msize & 0xff) { out[outpos++] = msize; i |= 0x10; }
msize >>= 8;
if (msize & 0xff) { out[outpos++] = msize; i |= 0x20; }
+ if (delta_version > 2) {
+ msize >>= 8;
+ if (msize & 0xff) {
+ out[outpos++] = msize; i |= 0x40;
+ }
+ }
*op = i;
}
diff --git a/environment.c b/environment.c
index 63b1d15..e266f83 100644
--- a/environment.c
+++ b/environment.c
@@ -8,6 +8,7 @@
* are.
*/
#include "cache.h"
+#include "pack.h"
char git_default_email[MAX_GITNAME];
char git_default_name[MAX_GITNAME];
@@ -25,6 +26,8 @@ const char *apply_default_whitespace;
int zlib_compression_level = Z_DEFAULT_COMPRESSION;
int pager_in_use;
int pager_use_color = 1;
+/* by default we allow 2 but up to PACK_VERSION is allowed */
+int delta_version = 2;
static const char *git_dir;
static char *git_object_dir, *git_index_file, *git_refs_dir, *git_graft_file;
diff --git a/sha1_file.c b/sha1_file.c
index d111be7..6653182 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -527,6 +527,7 @@ int use_packed_git(struct packed_git *p)
p->pack_size - 20)) {
die("packfile %s does not match index.", p->pack_name);
}
+ p->pack_version = ntohl(hdr->hdr_version);
}
p->pack_last_used = pack_used_ctr++;
p->pack_use_cnt++;
--
1.4.3.rc3.ga5ce
^ permalink raw reply related
* Recent and near future backward incompatibilities
From: Junio C Hamano @ 2006-10-15 6:29 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Stephen Hemminger
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).
The older version of git did not know anything about version 3
delta (which can express larger copies from source when
computing a delta) before d60fc1c8, and barfs if it is fed a
pack that contains such a delta. We have generated only version
2 delta for quite a while until very recently post v1.4.2.3.
The thing is, I made a mistake to repack my public repository
with more recent git (I work with "next" usually, and with
"master" after we go into -rcX cycle to prepare for the
release). Although the version of git that kernel.org runs is
still v1.4.2.3 which means its pack-objects does not produce
version 3 delta by itself, the problem is that the delta reuse
logic happily copies out whatever delta is in existing packs.
I already repacked the public repository with an older git,
v1.4.2.3, using 'git-repack -a -d -f' to fix this problem.
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. I
am not sure how to resolve this issue efficiently right now;
we need a bit of thinking.
- so instead we could just say a public repository that needs
to interoperate with older clients should not keep packs with
version 3 delta, at least for now. deltifying from loose
objects are done afresh every time pack-objects is run, and
it is easier to control.
- git-pack-objects needs to be updated so that we can control
whether we generate version 2 or version 3 delta.
- 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".
- the on-the-wire protocol between fetch-pack and upload-pack
needs to be updated so that the server side can tell if the
client side is prepared to handle version 3 delta in the
pack, and this needs to be passed to pack-objects to control
its operation. This part I can see how to fix.
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.
^ permalink raw reply
* Re: [PATCH] clone: the given repository dir should be relative to $PWD
From: Yasushi SHOJI @ 2006-10-15 3:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7iz274zy.fsf@assigned-by-dhcp.cox.net>
At Sat, 14 Oct 2006 18:16:33 -0700,
Junio C Hamano wrote:
>
> Yasushi SHOJI <yashi@atmark-techno.com> writes:
>
> > the repository argument for git-clone should be relative to $PWD
> > instead of the given target directory. The old behavior gave us
> > surprising success and you need a few minute to know why it worked.
> >
> > GIT_DIR is already exported so no need to cd into $D. And this makes
> > $PWD for git-fetch-pack, which is the actual command to take the given
> > repository dir, the same as git-clone.
> >
> > Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
> > ---
> >
> > While I'm not sure this is a feature we rely on or not, and I don't
> > want to change the way people work, IMHO the old behaviour isn't
> > appropriate for such higher level porcelain.
> >
> > The patch should be for post 1.4.3.
>
> Well spotted. I am fairly sure that this "clone from repository
> relative to the target" is not intended behaviour. I'd say we
> should fix this before 1.4.3.
OK. if the behavior isn't intended and there ain't much user for it,
I don't have any reason not to. my last sentence was more like a
question to you rather than my statement.
let's fix it before 1.4.3.
> ... or are there any valid reason to keep the current behaviour
> that I missed?
I don't think so. I personally consider the behavior a bug. I just
thought that we don't want to have user saying "hey, v1.4.3 doesn't
work any more!" report, given that we are already in -rc2.
--
yashi
^ permalink raw reply
* RE: git-svn and u-boot broken.
From: Joakim Tjernlund @ 2006-10-15 2:10 UTC (permalink / raw)
To: 'Eric Wong'; +Cc: git
In-Reply-To: <20061015014800.GJ27128@hand.yhbt.net>
>
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > >
> > > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > > > > > Also, which version of git-svn are you running?
> Also, which
> > > > > > version of
> > > > > > Subversion (client library, and server (if possible) are
> > > > > you running?
> > > > >
> > > > > git 1.4.2.3
> > > > > subversion 1.3.2-r1
> > > > >
> > > > > I will try upgrading to newer subverison.
> > > >
> > > > subversion 1.4.0 didn't help
> > > >
> > > > PS.
> > > >
> > > > I can't find the dcommit command in git-cvs, has it
> been removed?
> > > > if so, then the docs need an update.
> > >
> > > You mean git-svn, right? No, 'dcommit' has not been removed
> > > and I have
> > > no plans to remove it.
> >
> > hmm, its it not released yet then? I don't have it in git 1.4.2.3
>
> Hm... guess not. I track master on git.git. 1.4.3 should be released
> pretty soon, and should have dcommit.
OK, please add some examples on how to use dcommit.
Also, consider adding what options are supported for each command
in the COMMAND section.
>
> > Also, I have difficulties to follow the docs on
> > http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
>
> The most-up-to-date documentation is available here:
>
> http://git-svn.bogomips.org/git-svn.html
>
> > 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?
>
> > 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
* Re: git-svn and u-boot broken.
From: Eric Wong @ 2006-10-15 1:48 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: git
In-Reply-To: <00fa01c6eff2$5d7f8480$1267a8c0@Jocke>
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> >
> > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > > > > Also, which version of git-svn are you running? Also, which
> > > > > version of
> > > > > Subversion (client library, and server (if possible) are
> > > > you running?
> > > >
> > > > git 1.4.2.3
> > > > subversion 1.3.2-r1
> > > >
> > > > I will try upgrading to newer subverison.
> > >
> > > subversion 1.4.0 didn't help
> > >
> > > PS.
> > >
> > > I can't find the dcommit command in git-cvs, has it been removed?
> > > if so, then the docs need an update.
> >
> > You mean git-svn, right? No, 'dcommit' has not been removed
> > and I have
> > no plans to remove it.
>
> hmm, its it not released yet then? I don't have it in git 1.4.2.3
Hm... guess not. I track master on git.git. 1.4.3 should be released
pretty soon, and should have dcommit.
> Also, I have difficulties to follow the docs on
> http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
The most-up-to-date documentation is available here:
http://git-svn.bogomips.org/git-svn.html
> 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.
> 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.
--
Eric Wong
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-15 1:44 UTC (permalink / raw)
To: Jon Smirl; +Cc: Jakub Narebski, git
In-Reply-To: <9e4733910610141734h581afdc9r4d330d6a5a5bd1aa@mail.gmail.com>
On Sat, 14 Oct 2006 20:34:22 -0400
"Jon Smirl" <jonsmirl@gmail.com> wrote:
> That is possible but I wish git had tools supporting this. What do you
> do about core developers that want the full repo syncing to other
> developers that only have a partial copy?
I don't think that will be an issue at all.
As an example, take the current Linux kernel repo maintained by Linus,
and one of the repos containing old historic kernel data imported into
Git. Graft in the old historic data into your clone of Linus' repo,
and you're done. Anyone can pull from you even if they don't have the
historic data themselves.
With a little work you could do the same thing with the Mozilla data.
After you decide where to make the split, you'd have to rewrite the
commit history for the "current" repository, so that it terminates
at an initial commit rather than having a direct connection to the
historic data. After that, the repos could be used just as described
above, separately or graphed together.
As far as I know though, there is still no way to use the git protocol
for the initial pull of such a combined repository. You have to pull
both repos separately and graft them together locally. This sounds
harder than it is though and can be scripted easily.
Sean
^ permalink raw reply
* Re: [PATCH] clone: the given repository dir should be relative to $PWD
From: Junio C Hamano @ 2006-10-15 1:16 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: git
In-Reply-To: <87ac3zqebs.wl@mail2.atmark-techno.com>
Yasushi SHOJI <yashi@atmark-techno.com> writes:
> the repository argument for git-clone should be relative to $PWD
> instead of the given target directory. The old behavior gave us
> surprising success and you need a few minute to know why it worked.
>
> GIT_DIR is already exported so no need to cd into $D. And this makes
> $PWD for git-fetch-pack, which is the actual command to take the given
> repository dir, the same as git-clone.
>
> Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
> ---
>
> While I'm not sure this is a feature we rely on or not, and I don't
> want to change the way people work, IMHO the old behaviour isn't
> appropriate for such higher level porcelain.
>
> The patch should be for post 1.4.3.
Well spotted. I am fairly sure that this "clone from repository
relative to the target" is not intended behaviour. I'd say we
should fix this before 1.4.3.
... or are there any valid reason to keep the current behaviour
that I missed?
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-15 0:53 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910610141606g749d268eudd85791620e1363a@mail.gmail.com>
Jon Smirl wrote:
> On 10/14/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> * It would be nice to have tool to exchange commits between SCM and CVS,
>> be it like Tailor/git-svn, or via incremental import and exporting
>> commits to CVS like git-cvsexportcommit. This would ease changing SCM,
>> as both new SCM and CVS could be deployed in parallel, for a short time
>> of course.
>
> From what Brendan wrote they are looking to continue 1.9 in CVS and
> start 2.0 in a new SCM. This pretty much mandates tracking CVS into
> the new SCM for a long period of time. Possibly as much as two years.
> There does not appear to be a need to push 2.0 back into CVS.
That of course limits what we can do in 1.9 to what CVS supports.
> > * It would be nice to have CVS emulation like git-cvsserver, so users
> > accustomed to CVS could still use it.
>
> This can also solve some of the problems with Windows support.
Well, git-cvsserver (perhaps with some improvements) could also serve as
CVS server for 1.9.
> > 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.
One way to reduce repository size would be to split fairly independent
subprojects (inependent = independently testable) into separate repositories,
and perhaps use some kind of "super-repository" (common repository) to join
all the project in one single entity. The split can be done using
git-splitrepo (or something like that) which was posted on git mailing list
(most probably by some member of X.Org), or just cg-admin-rewritehist.
While at it we could split repository into current work and historical repo;
and clean up current work repository from the cruft accumulated (e.g. dead
branches, broken tags etc.).
Another way is to use grafts.
Linux kernel has it's current repository (starting somewhere 2.6.x),
and it's historical repository. I don't remember how they arrived at it
(and don't want to check KernelTrap articles), if the seed for current
work repository was simply project import at some state, or (very slow)
import of BitKeeper history. But if I remember correctly it was born split.
You can join both repositories into one (wrt. log and diff for example)
using grafts.
I'm not sure what happens if you pull from repository which has graft
file "cauterizing" history; would you get graft file and history up to
cutoff point? What would happen if your repository, repository you pull to
has cauterization graft file; would it get cut history? Of course
the problem (and the source of proposal and troubles with implementing
of shallow/sparse/lazy clone) lies if someone branches (in public repo)
from below cutoff point. But that is a matter of policy.
But it is true that the size of Mozilla repository is a challenge.
BTW. do you perchance know how other SCM dels with the repository
of that size?
--
Jakub Narebski
ShadeHawk on #git
Poland
^ permalink raw reply
* RE: git-svn and u-boot broken.
From: Joakim Tjernlund @ 2006-10-15 0:39 UTC (permalink / raw)
To: 'Eric Wong'; +Cc: git
In-Reply-To: <20061014210920.GD29149@localdomain>
>
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > > > Also, which version of git-svn are you running? Also, which
> > > > version of
> > > > Subversion (client library, and server (if possible) are
> > > you running?
> > >
> > > git 1.4.2.3
> > > subversion 1.3.2-r1
> > >
> > > I will try upgrading to newer subverison.
> >
> > subversion 1.4.0 didn't help
> >
> > PS.
> >
> > I can't find the dcommit command in git-cvs, has it been removed?
> > if so, then the docs need an update.
>
> You mean git-svn, right? No, 'dcommit' has not been removed
> and I have
> no plans to remove it.
hmm, its it not released yet then? I don't have it in git 1.4.2.3
Also, I have difficulties to follow the docs on http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
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?
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.
Jocke
^ permalink raw reply
* Re: VCS comparison table
From: Jon Smirl @ 2006-10-15 0:34 UTC (permalink / raw)
To: Sean; +Cc: Jakub Narebski, git
In-Reply-To: <BAYC1-PASMTP08F9B6EA71E7C83DD93E8DAE080@CEZ.ICE>
On 10/14/06, Sean <seanlkml@sympatico.ca> wrote:
> On Sat, 14 Oct 2006 19:06:10 -0400
> "Jon Smirl" <jonsmirl@gmail.com> wrote:
>
> > Top two git issues effecting Mozilla choosing it
> > 1) some way to avoid the initial 450MB download
>
> Why not split the repository up after you import it? Break it into
> two repositories, last year or two, and then everything else.
That is possible but I wish git had tools supporting this. What do you
do about core developers that want the full repo syncing to other
developers that only have a partial copy?
>
> > 2) better windows support
>
> Hard to imagine native windows support existing in time to be used by
> the Mozilla folks, maybe in time for 3.0 :o)
>
> Sean
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-15 0:03 UTC (permalink / raw)
To: Jon Smirl; +Cc: Jakub Narebski, git
In-Reply-To: <9e4733910610141606g749d268eudd85791620e1363a@mail.gmail.com>
On Sat, 14 Oct 2006 19:06:10 -0400
"Jon Smirl" <jonsmirl@gmail.com> wrote:
> Top two git issues effecting Mozilla choosing it
> 1) some way to avoid the initial 450MB download
Why not split the repository up after you import it? Break it into
two repositories, last year or two, and then everything else.
> 2) better windows support
Hard to imagine native windows support existing in time to be used by
the Mozilla folks, maybe in time for 3.0 :o)
Sean
^ permalink raw reply
* RE: git-svn and u-boot broken.
From: Joakim Tjernlund @ 2006-10-14 23:54 UTC (permalink / raw)
To: 'Eric Wong'; +Cc: git
In-Reply-To: <20061014224636.GA12565@soma>
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> >
> > > -----Original Message-----
> > > From: Eric Wong [mailto:normalperson@yhbt.net]
> > > Sent: den 14 oktober 2006 08:28
> > > To: Joakim Tjernlund
> > > Cc: 'Randal L. Schwartz'; git@vger.kernel.org
> > > Subject: Re: git-svn and u-boot broken.
> > >
> > > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Randal L. Schwartz [mailto:merlyn@stonehenge.com]
> > > > > Sent: den 13 oktober 2006 21:40
> > > > > To: Joakim Tjernlund
> > > > > Cc: git@vger.kernel.org
> > > > > Subject: Re: git-svn and u-boot broken.
> > > > >
> > > > > >>>>> "Joakim" == Joakim Tjernlund
> > > > > <joakim.tjernlund@transmode.se> writes:
> > > > >
> > > > > Joakim> First, I had to change this (from memory) in git-svn:
> > > > > Joakim> my $got = SVN::TxDelta::send_stream($fh, @$atd,
> > > > > $self->{pool});
> > > > > Joakim> to
> > > > > Joakim> my $got;
> > > > > Joakim> if ( $got ) {
> > > > > Joakim> $got = SVN::TxDelta::send_stream($fh, @$atd,
> > > > > $self->{pool});
> > > > > Joakim> } else {
> > > > > Joakim> $got = $exp
> > > > > Joakim> }
> > > > > Joakim> I am no perl programmer so please change as
> you se fit.
> > >
> > > With your correction following merlyn's comments, it could
> > > work[1]. I'm
> > > curious as to what change git-svn printed right before
> > > hitting an error
> >
> > from memory:
> > Usage: svn_txdelta_send_stream(x,y,z,m)
>
> > > here, and would like to see the files (before and after) that were
> > > printed by git-svn.
> >
> > Sorry, don't have that hande ATM
>
> Could you publish your git repository for u-boot and also the
> exact commands (if you have them) you used to attempt the import
> into SVN? Thanks.
The git repo is a bit complicated as I don't have have anywhere
to put it. However I don't think you need it, just clone DENX u-boot repo
at git://www.denx.de/git/u-boot.git, it bails out before it gets to my
changes.
Here is the script I use to test with
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"
# without --squash one gets a SVN repo with lots of small commits(2)
git pull . initial-uboot
git-svn commit -q remotes/git-svn..svn-branch
(2)
This fails currently with
git-svn commit -q remotes/git-svn..svn-branch
diff-tree 9030f4be0b324cb312cfecd86d4a7da04ffa99ee 8e9655f863246db60c51140153186acc2afdc855
Inappropriate ioctl for device at /usr/bin/git-svn line 1462
6400 at /usr/bin/git-svn line 1462
6400 at /usr/bin/git-svn line 547
main::commit_lib('8e9655f863246db60c51140153186acc2afdc855', 'ef04a0aa2676738847bd69914cadac0b96d6e731',
'4d03a21f2329bb13a9661a23742ac0b77a7a76d5', 'f190c11b1f22ff766e046588e5a7bb55f28ae305', '182e10691f378987b53c64ee0347d542e4924ef6',
'527b5a511c804074eebfc08c9ae7860b6717da85', 'ea339205a94706d8b9170bbd89e8c1373df9a92f', '3ada834e30a0742991209140049035c626ccea85',
'feaedfcf84c92599c0b805f66cc8a628d82411f0', ...) called at /usr/bin/git-svn line 457
main::commit('remotes/git-svn..svn-branch') called at /usr/bin/git-svn line 149
>
> > > I'm not sure what change would show up in git but cause
> > > apply_textdelta
> > > to return undef...
> > >
> > > [1] - I am tempted to apply a change based on yours, but this
> > > could just
> > > be working around another bug somewhere else (either in git-svn or
> > > subversion).
> > >
> > > > > That doesn't make any sense. You'll never run the if-true
> > > > > branch there.
> > > > > The value of $got immediately following "my $got;" is
> > > always undef.
> > > >
> > > > git-pull --squash seems to do what I want but know I
> get this when
> > > > committing to svn:
> > > > git-svn commit remotes/git-svn..svn-branch
> > > > ...
> > > > A cpu/mpc824x/drivers/i2c_export.h
> > > > A cpu/mpc824x/drivers/i2o.h
> > > > A cpu/mpc824x/drivers/i2o/Makefile
> > > > A cpu/mpc824x/drivers/i2o/Makefile_pc
> > > > Cannot allocate memory at /usr/bin/git-svn line 1462
> > > > 3072 at /usr/bin/git-svn line 547
> > > >
> > > main::commit_lib('2ff9bcb7908d2752f643695ab3a28f9ababfafab')
> > > called at /usr/bin/git-svn line 457
> > > > main::commit('remotes/git-svn..svn-branch') called
> > > at /usr/bin/git-svn line 149
> > >
> > > How large is the changeset you're committing?
> > > (git show --stat 2ff9bcb7908d2752f643695ab3a28f9ababfafab)
> >
> > That gives me a huge listing that ends in:
> > 4306 files changed, 1194819 insertions(+), 0 deletions(-)
>
> Yikes, that's a huge commit. git-svn memory usage was bounded
> for the size of each changeset, so yes, this could get nasty.
> Patch coming in a reply to this message.
Thanks, will try that patch next.
Jocke
^ permalink raw reply
* Re: On blame/pickaxe
From: Junio C Hamano @ 2006-10-14 23:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vwt739org.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Junio C Hamano <junkio@cox.net> writes:
>
>> 4. Passing more blame.
>>
>> Instead of taking responsibility for the remainder, there are
>> other ways to find other people to pass blame on. That's what
>> the "NEEDSWORK" comment in pass_blame() is about.
>
> I've spent a few hours tonight to further work (eh, "have fun")
> on this. The version at the tip of "pu" implements detection of
> a case like this:
> ...
> You can use the pickaxe on its source itself, like this:
>
> git pickaxe -n master..pu builtin-pickaxe.c
>
> If you compare this with output from:
>
> git log --pretty=short -p master..pu builtin-pickaxe.c
>
> you will notice the line-movement detection in action.
>
> During the course of development, I had to move quite a few
> static functions around so that they are defined before their
> first call site. This is partly because I am very bad at
> initial planning (who is?) and this still being in experimental
> stage I did not bother declaring static functions upfront as
> forward declarations.
>
> For example, commit db3f0f2 introduces find_last_in_target()
> function, but it was moved up by commit b5c0e4f (near the tip of
> "pu"). pickaxe blames the implementation of it to db3f0f20, and
> also notices that the bulk of its logic was actually copied from
> the implementation of pass_blame_to_parent() function in commit
> b14dc9ef (the initial commit that introduced builtin-pickaxe.c).
>
> What _ought_ to come next is to detect line movement across
> files, but I'll go to bed for now.
And this implements it. After testing it some more, I'll have
it near the tip of "pu" sometime tonight.
I have to admit that I am becoming quite fond of the name
"pickaxe", by the way.
I consider that the "following the changed lines and see where
it came from" you described in the ancient message:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
the holy grail of software archaeology. Once we have it, I
would feel I am pretty much _done_ with git. It will have
everything I want it to do.
My "diff -S" (where the "pickaxe" name started) was a crude
first step to achieve that goal. The way I envisioned it was
that you would feed the lines 50-89 as a single -S parameter to
"git whatchanged" and the tool finds the commit that touched
that area, and the Porcelain would either figure out what the
corresponding lines in the previous commit look like or ask the
user to highlight what to dig deeper interactively, and restart
another "whatchanged" with adjusted value for -S. Unfortunately
nobody wrote such a Porcelain command.
I think the command with this patch gets us closer to that goal;
although it still does not have a way to detect "oh these five
copies were consolidated into one" (I'd imagine we _could_ do
that in find_copy_in_parent() function if we really wanted to --
but that would be a tad expensive). In any case, I think this
is going in the right direction.
Before anybody asks, the example Daniel Barkalow gave on date.c
is far trickier and even this version would not catch it. It
requires digging random, distant, ancestors in order to look for
lines that were lost by an earlier removal.
-- >8 --
git-pickaxe: blame cut-and-paste lines.
This completes the initial round of git-pickaxe. In addition to
the line movement the previous round implements, this finds new
lines that were created by moving or cutting-and-pasting lines
from different path in the parent.
With this,
git pickaxe -f -n v1.4.0 -- revision.c
finds that major part of that file actually came from rev-list.c
when Linus split the latter at commit ae563642 and blames them
to earlier commits that touches rev-list.c.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
builtin-pickaxe.c | 71 +++++++++++++++++++++++++++++++++++------------------
1 files changed, 47 insertions(+), 24 deletions(-)
diff --git a/builtin-pickaxe.c b/builtin-pickaxe.c
index 3f9f679..1124919 100644
--- a/builtin-pickaxe.c
+++ b/builtin-pickaxe.c
@@ -638,39 +638,16 @@ static int find_copy_in_blob(struct scor
return 0;
}
-static int find_copy_in_parent(struct scoreboard *sb,
- struct origin *target,
- struct commit *parent,
- struct origin *porigin)
-{
- int last_in_target;
-
- last_in_target = find_last_in_target(sb, target);
- if (last_in_target < 0)
- return 1; /* nothing remains for this target */
-
- /* NEEDSWORK: run diff-tree between target->commit with parent
- * to find the paths that were modified from parent, and find
- * copies in the parent; if we find any we can pass blame to it.
- * We have checked path in porigin so do not bother checking it
- * again (but porigin might be NULL).
- */
-
- return 0;
-}
-
static int find_move_in_parent(struct scoreboard *sb,
struct origin *target,
struct origin *parent)
{
- int last_in_target;
struct blame_entry *ent;
mmfile_t file_p;
char type[10];
char *blob_p;
- last_in_target = find_last_in_target(sb, target);
- if (last_in_target < 0)
+ if (find_last_in_target(sb, target) < 0)
return 1; /* nothing remains for this target */
blob_p = read_sha1_file(parent->blob_sha1, type,
@@ -690,6 +667,52 @@ static int find_move_in_parent(struct sc
return 0;
}
+static int find_copy_in_parent(struct scoreboard *sb,
+ struct origin *target,
+ struct commit *parent,
+ struct origin *porigin)
+{
+ struct diff_options diff_opts;
+ const char *paths[1];
+ int no_more, i;
+
+ if (find_last_in_target(sb, target) < 0)
+ return 1; /* nothing remains for this target */
+
+ diff_setup(&diff_opts);
+ diff_opts.recursive = 1;
+ diff_opts.output_format = DIFF_FORMAT_NO_OUTPUT;
+
+ /* Try "find copies harder" on new path */
+ if (!porigin || strcmp(target->path, porigin->path)) {
+ diff_opts.detect_rename = DIFF_DETECT_COPY;
+ diff_opts.find_copies_harder = 1;
+ }
+ paths[0] = NULL;
+ diff_tree_setup_paths(paths, &diff_opts);
+ if (diff_setup_done(&diff_opts) < 0)
+ die("diff-setup");
+ diff_tree_sha1(parent->tree->object.sha1,
+ target->commit->tree->object.sha1,
+ "", &diff_opts);
+ diffcore_std(&diff_opts);
+
+ for (i = no_more = 0; !no_more && i < diff_queued_diff.nr; i++) {
+ struct diff_filepair *p = diff_queued_diff.queue[i];
+ struct origin *new_porigin;
+ if (!DIFF_FILE_VALID(p->one))
+ continue; /* does not exist in parent */
+ if (porigin && !strcmp(p->one->path, porigin->path))
+ continue; /* find_move already checked this path */
+
+ new_porigin = find_origin(sb, parent, p->one->path);
+ no_more = find_move_in_parent(sb, target, new_porigin);
+ }
+ diff_flush(&diff_opts);
+
+ return no_more;
+}
+
#define MAXPARENT 16
static void pass_blame(struct scoreboard *sb, struct origin *origin)
{
--
1.4.3.rc2.g195ab
^ permalink raw reply related
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-14 23:34 UTC (permalink / raw)
To: git
In-Reply-To: <9e4733910610141606g749d268eudd85791620e1363a@mail.gmail.com>
Jon Smirl wrote:
> Top two git issues effecting Mozilla choosing it
> 1) some way to avoid the initial 450MB download
Give out CDs with Mozilla's git repository (and use alternates) ;-)
Just kidding...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: Jon Smirl @ 2006-10-14 23:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <egrgqe$1i9$1@sea.gmane.org>
On 10/14/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Jon Smirl wrote:
>
> > I was reading Brendan's blog post about Mozilla 2
> > http://weblogs.mozillazine.org/roadmap/archives/2006/10/mozilla_2.html
>
> You mean:
> "Oh, and isn't it time that we get off of CVS? The best way to do that
> without throwing 1.9 into an uproar is to develop Mozilla 2 using a new
> Version Control System (VCS) that can merge with CVS (since we will want
> to track changes to files not being revamped at first, or at all; and
> we'll probably find bugs whose fixes should flow back into 1.9). The
> problem with VCSes is that there are too many to choose from now.
> Nevertheless, looking for mostly green columns in that chart should help
> us make a quick decision. We don't need "the best" or the "newest", but we
> do need better merging, branching, and renaming support."
>
> 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.
There is no existing CVS importer that will correctly import the
Mozilla CVS. I have tried them all.
> By the way, I'd rather use SCM comparison table on neutral site, not on SCM
> site.
>
>
> I think that Mozilla project should come with it's own set of requirements
> and weights for best SCM _for Mozilla project_.
>
> 1. Converting existing CVS repository. This should be without data loss...
> well, beside data loss that stems from using CVS in first place. "Best" SCM
> would have:
> * Tool to convert CVS repository, which can then incrementally import
> changes.
> * It would be nice to have tool to exchange commits between SCM and CVS,
> be it like Tailor/git-svn, or via incremental import and exporting
> commits to CVS like git-cvsexportcommit. This would ease changing SCM,
> as both new SCM and CVS could be deployed in parallel, for a short time
> of course.
>From what Brendan wrote they are looking to continue 1.9 in CVS and
start 2.0 in a new SCM. This pretty much mandates tracking CVS into
the new SCM for a long period of time. Possibly as much as two years.
There does not appear to be a need to push 2.0 back into CVS.
> * It would be nice to have CVS emulation like git-cvsserver, so users
> accustomed to CVS could still use it.
This can also solve some of the problems with Windows support.
>
> 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.
>
> 3. Good support for the workflow used in the project. Is it exchanging
> patches via email (hello, Git!), having ssh access to some central
> repository with central repository to push changes to or net/mesh of
> repositories exchanging information, posting patches on some bug tracking
> software integrated with SCM. Is it using many branches (topic branches),
> or is it using few branches and merging.
>
> But it is equally important to realize what would be the best workflow to
> use, not constraining itself to the workflow imposed by limitations of CVS.
A big problem for Mozilla is outside companies doing major work in a
local CVS. Since CVS is not decentralized these local repos drift away
from the main one over time making things hard to merge. Any new SCM
will have to be distributed.
> 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.
>
> 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.
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.
Top two git issues effecting Mozilla choosing it
1) some way to avoid the initial 450MB download
2) better windows support
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] git-svn: reduce memory usage for large commits
From: Eric Wong @ 2006-10-14 22:48 UTC (permalink / raw)
To: Junio C Hamano, Joakim Tjernlund; +Cc: git
In-Reply-To: <20061014224636.GA12565@soma>
apply_textdelta and send_stream can use a separate pool from the
rest of the editor interface, so we'll use a separate SVN::Pool
for them and clear the pool after each file is sent to SVN.
This drastically reduces memory usage per-changeset committed,
and makes large commits (and initial imports) of several
thousand files possible.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 0f968c8..54d2356 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3354,9 +3354,11 @@ sub chg_file {
seek $fh, 0, 0 or croak $!;
my $exp = $md5->hexdigest;
- my $atd = $self->apply_textdelta($fbat, undef, $self->{pool});
- my $got = SVN::TxDelta::send_stream($fh, @$atd, $self->{pool});
+ my $pool = SVN::Pool->new;
+ my $atd = $self->apply_textdelta($fbat, undef, $pool);
+ my $got = SVN::TxDelta::send_stream($fh, @$atd, $pool);
die "Checksum mismatch\nexpected: $exp\ngot: $got\n" if ($got ne $exp);
+ $pool->clear;
close $fh or croak $!;
}
--
1.4.3.rc2.ge931
^ permalink raw reply related
* Re: git-svn and u-boot broken.
From: Eric Wong @ 2006-10-14 22:46 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: git
In-Reply-To: <00f301c6ef76$62172060$1267a8c0@Jocke>
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>
> > -----Original Message-----
> > From: Eric Wong [mailto:normalperson@yhbt.net]
> > Sent: den 14 oktober 2006 08:28
> > To: Joakim Tjernlund
> > Cc: 'Randal L. Schwartz'; git@vger.kernel.org
> > Subject: Re: git-svn and u-boot broken.
> >
> > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Randal L. Schwartz [mailto:merlyn@stonehenge.com]
> > > > Sent: den 13 oktober 2006 21:40
> > > > To: Joakim Tjernlund
> > > > Cc: git@vger.kernel.org
> > > > Subject: Re: git-svn and u-boot broken.
> > > >
> > > > >>>>> "Joakim" == Joakim Tjernlund
> > > > <joakim.tjernlund@transmode.se> writes:
> > > >
> > > > Joakim> First, I had to change this (from memory) in git-svn:
> > > > Joakim> my $got = SVN::TxDelta::send_stream($fh, @$atd,
> > > > $self->{pool});
> > > > Joakim> to
> > > > Joakim> my $got;
> > > > Joakim> if ( $got ) {
> > > > Joakim> $got = SVN::TxDelta::send_stream($fh, @$atd,
> > > > $self->{pool});
> > > > Joakim> } else {
> > > > Joakim> $got = $exp
> > > > Joakim> }
> > > > Joakim> I am no perl programmer so please change as you se fit.
> >
> > With your correction following merlyn's comments, it could
> > work[1]. I'm
> > curious as to what change git-svn printed right before
> > hitting an error
>
> from memory:
> Usage: svn_txdelta_send_stream(x,y,z,m)
> > here, and would like to see the files (before and after) that were
> > printed by git-svn.
>
> Sorry, don't have that hande ATM
Could you publish your git repository for u-boot and also the
exact commands (if you have them) you used to attempt the import
into SVN? Thanks.
> > I'm not sure what change would show up in git but cause
> > apply_textdelta
> > to return undef...
> >
> > [1] - I am tempted to apply a change based on yours, but this
> > could just
> > be working around another bug somewhere else (either in git-svn or
> > subversion).
> >
> > > > That doesn't make any sense. You'll never run the if-true
> > > > branch there.
> > > > The value of $got immediately following "my $got;" is
> > always undef.
> > >
> > > git-pull --squash seems to do what I want but know I get this when
> > > committing to svn:
> > > git-svn commit remotes/git-svn..svn-branch
> > > ...
> > > A cpu/mpc824x/drivers/i2c_export.h
> > > A cpu/mpc824x/drivers/i2o.h
> > > A cpu/mpc824x/drivers/i2o/Makefile
> > > A cpu/mpc824x/drivers/i2o/Makefile_pc
> > > Cannot allocate memory at /usr/bin/git-svn line 1462
> > > 3072 at /usr/bin/git-svn line 547
> > >
> > main::commit_lib('2ff9bcb7908d2752f643695ab3a28f9ababfafab')
> > called at /usr/bin/git-svn line 457
> > > main::commit('remotes/git-svn..svn-branch') called
> > at /usr/bin/git-svn line 149
> >
> > How large is the changeset you're committing?
> > (git show --stat 2ff9bcb7908d2752f643695ab3a28f9ababfafab)
>
> That gives me a huge listing that ends in:
> 4306 files changed, 1194819 insertions(+), 0 deletions(-)
Yikes, that's a huge commit. git-svn memory usage was bounded
for the size of each changeset, so yes, this could get nasty.
Patch coming in a reply to this message.
> got some entries that look like this:
> board/MAI/bios_emulator/scitech/makedefs/qnxnto.mk | 157
> .../bios_emulator/scitech/makedefs/rules/bc16.mk | 69
> .../bios_emulator/scitech/makedefs/rules/bc3.mk
>
> whats the ... for?
Long filename that couldn't fit on the (80 char width?) diffstat prints
out.
--
Eric Wong
^ permalink raw reply
* Re: git-svn and u-boot broken.
From: Eric Wong @ 2006-10-14 21:09 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: git
In-Reply-To: <00f701c6ef92$88b84840$1267a8c0@Jocke>
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > > Also, which version of git-svn are you running? Also, which
> > > version of
> > > Subversion (client library, and server (if possible) are
> > you running?
> >
> > git 1.4.2.3
> > subversion 1.3.2-r1
> >
> > I will try upgrading to newer subverison.
>
> subversion 1.4.0 didn't help
>
> PS.
>
> I can't find the dcommit command in git-cvs, has it been removed?
> if so, then the docs need an update.
You mean git-svn, right? No, 'dcommit' has not been removed and I have
no plans to remove it.
--
Eric Wong
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-14 20:20 UTC (permalink / raw)
To: git
In-Reply-To: <9e4733910610140807p633f5660q49dd2d2111c9f5fe@mail.gmail.com>
Jon Smirl wrote:
> I was reading Brendan's blog post about Mozilla 2
> http://weblogs.mozillazine.org/roadmap/archives/2006/10/mozilla_2.html
You mean:
"Oh, and isn't it time that we get off of CVS? The best way to do that
without throwing 1.9 into an uproar is to develop Mozilla 2 using a new
Version Control System (VCS) that can merge with CVS (since we will want
to track changes to files not being revamped at first, or at all; and
we'll probably find bugs whose fixes should flow back into 1.9). The
problem with VCSes is that there are too many to choose from now.
Nevertheless, looking for mostly green columns in that chart should help
us make a quick decision. We don't need "the best" or the "newest", but we
do need better merging, branching, and renaming support."
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
By the way, I'd rather use SCM comparison table on neutral site, not on SCM
site.
I think that Mozilla project should come with it's own set of requirements
and weights for best SCM _for Mozilla project_.
1. Converting existing CVS repository. This should be without data loss...
well, beside data loss that stems from using CVS in first place. "Best" SCM
would have:
* Tool to convert CVS repository, which can then incrementally import
changes.
* It would be nice to have tool to exchange commits between SCM and CVS,
be it like Tailor/git-svn, or via incremental import and exporting
commits to CVS like git-cvsexportcommit. This would ease changing SCM,
as both new SCM and CVS could be deployed in parallel, for a short time
of course.
* It would be nice to have CVS emulation like git-cvsserver, so users
accustomed to CVS could still use it.
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.
3. Good support for the workflow used in the project. Is it exchanging
patches via email (hello, Git!), having ssh access to some central
repository with central repository to push changes to or net/mesh of
repositories exchanging information, posting patches on some bug tracking
software integrated with SCM. Is it using many branches (topic branches),
or is it using few branches and merging.
But it is equally important to realize what would be the best workflow to
use, not constraining itself to the workflow imposed by limitations of CVS.
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.
5. ....
and probably few more
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Fix tracing when GIT_TRACE is set to an empty string.
From: Christian Couder @ 2006-10-14 19:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodseahty.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> > Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> > ---
> > trace.c | 3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/trace.c b/trace.c
> > index f9efc91..495e5ed 100644
> > --- a/trace.c
> > +++ b/trace.c
> > @@ -55,7 +55,8 @@ static int get_trace_fd(int *need_close)
> > {
> > char *trace = getenv("GIT_TRACE");
> >
> > - if (!trace || !strcmp(trace, "0") || !strcasecmp(trace, "false"))
> > + if (!trace || !strcmp(trace, "") ||
> > + !strcmp(trace, "0") || !strcasecmp(trace, "false"))
> > return 0;
> > if (!strcmp(trace, "1") || !strcasecmp(trace, "true"))
> > return STDERR_FILENO;
> > --
> > 1.4.3.rc2.gadba
>
> This means that
>
> GIT_TRACE= git-foo
> and
> unset GIT_TRACE ; git-foo
>
> should behave the same way, right?
Yes, that's the goal of this patch.
> If so that sounds sensible.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH 1/2] diff --stat: use asymptotic scaling in graph
From: Junio C Hamano @ 2006-10-14 19:06 UTC (permalink / raw)
To: apodtele; +Cc: git
In-Reply-To: <d620685f0610130656u55079a1fkc2c98a82f3aa4a33@mail.gmail.com>
apodtele <apodtele@gmail.com> writes:
> Before my patch is completely forgotten, let me critique the current
> approach. Currently everything is great and beautiful unless one
> particular change adds a couple of hundred lines, say, to a man page.
> With large changes in play, small changes are squashed to a single
> character. Would you argue that this scenario correctly represent
> importance of man pages? Would you say, that it's not misleading that
> 1-, 2-, and 5-liners all look the same as long as a man page is
> prominently shown? Moreover, 1-, 2-, and 5- liners may look different
> depending on the size of that man page. The current approach is not
> invariant; it is, however, normalized as needed. "Normalized" is good,
> "as needed" is bad.
One thing that mildly irritates me has been:
git log --stat v2.6.17..
which, as you correctly point out, shows the bad effect of
scaling per commit. "Normalized as needed" is good. What's bad
is "not normalizing across things we show".
Even with your non-linear scaling, you would need to make sure
every commit gets the same graph width; I do not think they
currently do, due to name part scaling.
People are used to seeing the traditional diffstat output, so
any improvement you make that is different from it (including
e.g. "being able to show differences between 1- and 2- liner
patch when a monster 800- liner happens to be in the same patch
set", which is a worthwhile goal) will look bizarre and/or
misleading to them and they would not like it.
With the change to align things in the middle, it might become
easier to accept, because then it is _so_ obviously different
from traditional diffstat, it is very clear to people that the
output is different but still they can easily figure out that
longer bars are for larger changes.
And this new output needs to be an option.
^ 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