* Re: [EGIT PATCH] Convert author and comment on demand.
From: Shawn Pearce @ 2006-12-03 2:16 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200612030145.09576.robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> This sppeds up reading commits a lot by only store the byte
> array data when reading commits.
Thanks. I was working on something similar but did not have
a chance to finish it. I've applied your patch instead.
> + try {
> + BufferedReader br=new BufferedReader(new InputStreamReader(new
> ByteArrayInputStream(raw)));
> + String n=br.readLine();
Something's wrong with your mail client... the patch was mangled.
--
^ permalink raw reply
* Re: [PATCH 2/3] git-svn: documentation updates
From: Eric Wong @ 2006-12-03 2:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd571yccv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > Both push and pull are git/bk/hg(?)-specific terms; most SVN users are
> > not accustomed to them. Using 'pull' with git-svn has already been
> > discouraged for a while (since the introduction of dcommit); and
> > having a 'push' without a 'pull' would be very confusing.
>
> I am not sure how 'push' side should be integrated, but I wish
> people could simply update a branch that is managed by foreign
> SCM interfaces such as git-svn and git-cvsimport with 'git fetch'
> by saying that the remote URL points at a non-git "repository"
> in remotes/ (or corresponding config).
Ack on being able to use 'git fetch'.
> git-cvsimport builds the git objects from the changeset without
> using the working tree, and it would be very natural and simple
> to integrate it into 'git fetch', pretending as if it is just a
> funny transport.
>
> If the interface uses the working tree to update the state from
> foreign SCM, then integrating with git-fetch would be
> inpractical. I guess git-svn works that way?
git-svn only needs a working tree (hidden away in .git/svn/ and the user
should never see it) when it uses the command-line svn client. If the
SVN:: libraries are available, then git-svn just uses an alternative
index like cvsimport.
--
^ permalink raw reply
* Thoughts about memory requirements in traversals [Was: Re: [RFC] Submodules in GIT]
From: Josef Weidendorfer @ 2006-12-03 2:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Waitz, sf, git
In-Reply-To: <Pine.LNX.4.64.0612021252380.3476@woody.osdl.org>
On Saturday 02 December 2006 22:22, Linus Torvalds wrote:
> So operations like "git-rev-list --objects" (or, these days, more commonly
> anything that just does the equivalent of that internally using the
> library interfaces - ie "git pack-objects" and friends) VERY FUNDAMENTALLY
> have to hold on to the object flags for the whole lifetime of the whole
> operation.
>
> [...]
>
> So this really isn't a memory management issue. You could somewhat work
> around it by adding a "caching layer" on top of git, and allow that
> caching layer to modify their cache of old objects (so that they can
> contain back-pointers), but for 99% of all users that would actually make
> performance MUCH WORSE, and it would also be a serious problem for
> coherency issues (one of the things that immutable objects cause is that
> there are basically never any race conditions, while a "caching layer"
> like this would have some serious issues about serialization).
Thinking about this...
You have to make very sure to always update the caching layer containing
the backlinks on every addition of a further object. You can do this
because you always reached this new object by some other object, which
exactly is the backpointer.
Now let us suppose we are able to do this.
What does this give us?
Take a look at object traversal:
We have to store the flag "already visited" for objects we could reach
again in the traversal. But with the backlinks, we can see that most
of the objects can only be reached via one path, and therefore, there
is no need to store the flag, as it never will be queried in the
further traversal.
(Similar for objects with two paths: When you have visited the object
two times, you can throw away the flag, as it is not queried any more).
Regarding the caching layer and object traversal, it would have been
enough to only store "is this object reachable via more than 1 path?".
For this, the "cache" could be the set of objects reachable with
more than one path.
And such a set stored in a file should be quite managable, and be
quite small, relative to the size of the object database.
In fact, this "cache" can be created with a usual object traversal
(which has the original memory requirement), but as long as we do
not add objects to the database, further traversals would only need
a fraction of memory.
When only adding a small number of objects, it should be easy to
update the cache; while with big actions like fetching/pulling,
we simply should remove the file with the backlink information.
> problem. In fact, O(n) is pretty damn good, especially since the constant
> is pretty small (basically 28 bytes per object - and 20 of those bytes
> are the SHA1 that you simply cannot avoid).
Again only some thoughts...
Pack files are fully self-contained object stores, yes?
So in the scope of a single pack file, the offset of this object is enough
as object identification.
If we could make sure that in any given algorithm touching objects, like
commit traversal, we always have the offset available when we need to do
an object lookup, then, it should be enough to store object flags only
indexed by the offset of this object in the pack.
The translation SHA1 -> offset can be done with the pack index.
As you usually have multiple packs, a (pack number / offset) tuple should
be enough as object ID.
Thinking even one step further:
Would it make sense to define an encoding format for the content of
commit and tree objects inside of packs, where the SHA1 is replaced by the
offset of the object in this pack?
As exactly the SHA1 is the least compressable thing, this could promise
quite a benefit.
AFAIK, we currently only use these offsets for referencing objects in
delta chains.
More about the original topic of this thread (and off-topic to the
new subject):
> But it does mean that supermodules really should NOT be so seamless that
> doing a "git clone" on a supermodule does one _large_ clone. Because it's
> simply going to be better to:
>
> - when you clone the supermodule, track the commits you need on all
> submodules (this _may_ be a reason in itself for the "link" object,
> just so that you can traverse the supermodule object dependencies and
> know what subobject you are looking at even _without_ having to look at
> the path you got there from)
>
> - clone submodules one-by-one, using the list of objects you gathered.
Without submodule identities, we would have to clone path-by-path, as
we can not distinguish different submodules apart from there location.
^ permalink raw reply
* Re: [PATCH 2/3] git-svn: documentation updates
From: Junio C Hamano @ 2006-12-03 1:52 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061203013955.GD1369@localdomain>
Eric Wong <normalperson@yhbt.net> writes:
> Both push and pull are git/bk/hg(?)-specific terms; most SVN users are
> not accustomed to them. Using 'pull' with git-svn has already been
> discouraged for a while (since the introduction of dcommit); and
> having a 'push' without a 'pull' would be very confusing.
I am not sure how 'push' side should be integrated, but I wish
people could simply update a branch that is managed by foreign
SCM interfaces such as git-svn and git-cvsimport with 'git fetch'
by saying that the remote URL points at a non-git "repository"
in remotes/ (or corresponding config).
git-cvsimport builds the git objects from the changeset without
using the working tree, and it would be very natural and simple
to integrate it into 'git fetch', pretending as if it is just a
funny transport.
If the interface uses the working tree to update the state from
foreign SCM, then integrating with git-fetch would be
inpractical. I guess git-svn works that way?
^ permalink raw reply
* Re: [PATCH 2/3] git-svn: documentation updates
From: Eric Wong @ 2006-12-03 1:49 UTC (permalink / raw)
To: Seth Falcon; +Cc: git
In-Reply-To: <m2wt5es0r3.fsf@ziti.fhcrc.org>
Seth Falcon <sethfalcon@gmail.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
> > I've been considering something along those lines. I'm interested in
> > renaming the current 'commit' command to something else (it still has
> > its uses), but I haven't figured out what to call it...
>
> I think this would be a sensible change and will help new users get
> started with git-svn.
>
> > Also, something that can wrap (git commit && git svn dcommit) into one
> > step would be nice.
>
> For my workflow, that wouldn't be all that useful. I find that I
> accumulate a few commits locally and then send them all to svn. For
> this workflow, what would be useful is if dcommit could understand a
> command like:
>
> git svn dcommit remotes/git-svn..HEAD~2
>
> Sometimes I realize I should have sent a stack of commits to svn, but
> now have some newer commits that aren't quite ready on the head of my
> branch.
>
> While the workaround is easy (create a new branch and dcommit from
> it), I think there is a usability argument in that when one
> sees an example like dcommit foo..bar, one expects all
> the other magic to work. I feel for this and accidentally committed a
> few commits I didn't want to send. If nothing else, perhaps git-svn
> could error out and say, "hey, I don't do that".
Aded to my ever-growing git-svn todo list. Patches welcome :)
--
^ permalink raw reply
* Re: git-svn and empty directories in svn (was: [PATCH 1.2/2 (fixed)] git-svn: fix output reporting from the delta fetcher)
From: Eric Wong @ 2006-12-03 1:47 UTC (permalink / raw)
To: Seth Falcon; +Cc: Pazu, git
In-Reply-To: <m2slg2rzzj.fsf_-_@ziti.fhcrc.org>
Seth Falcon <sethfalcon@gmail.com> wrote:
> Hi Eric, and list,
>
> Eric Wong <normalperson@yhbt.net> writes:
> > Seth Falcon <sethfalcon@gmail.com> wrote:
> >> I think that presently git-svn does not create empty dirs when pulling
> >> from svn. It would be nice to have such directories created since
> >> some projects will expect the empty dir to be there (no need to track
> >> it in git, IMO).
> >
> > Git itself cannot easily track empty directories (at least as far as
> > update-index and checkout) goes.
> >
> > What I *can* do is run mktree and to force the creation of tree objects
> > with a 4b825dc642cb6eb9a060e54bf8d69288fbee4904 (empty) sub tree and run
> > commit-tree on it, but checkout/checkout-index would still need to be
> > modified to support it.
> >
> > Is that something the git community wants?
>
> I recently encountered a situation where code wasn't working for me
> because git-svn didn't create an empty dir that is present in svn.
>
> I'm not trying to argue for the sense/anti-sense of tracking empty
> dirs in an scm, but I think this is an issue worth addressing in some
> fashion. Here's why.
>
> I think there are many potential git users out there who are currently
> svn users. And git-svn is a really nice way to get started, but this
> sort of stumbling block could really turn people off. For example, it
> made me look pretty dumb when I carelessly complained to my colleague
> about his code not working and then it turns out to be because my
> super-advanced scm tool "messed things up".
>
> One simple thing (I think it would be simple) is that git-svn could
> issue a loud warning when it encounters an empty directory that it is
> going to ignore.
>
> I don't understand the implications adding the tracking of empty dirs
> to git. I suspect it has been discussed before, but haven't yet gone
> fishing in the list archives. I imagine it would make the argument
> easier for folks wanting to switch a project from svn to git if this
> wasn't one of the differences. For good or bad, I've often heard this
> svn feature as a motivator to switch from cvs.
I agree that missing empty directories when tracking foreign SVN repos
is annoying. I've looked into this a bit more; but ended up
trying to reinvent the index :x
Since git-svn misses some other stuff (many property settings,
externals) I'll be working on an internal logging format that can help
track those things. It'd be nice to have a command like git svn
checkout which works like git checkout; but empty directories are
created.
--
^ permalink raw reply
* Re: [PATCH 2/3] git-svn: documentation updates
From: Eric Wong @ 2006-12-03 1:39 UTC (permalink / raw)
To: Pazu; +Cc: git
In-Reply-To: <loom.20061129T133305-813@post.gmane.org>
Pazu <pazu@pazu.com.br> wrote:
> Eric Wong <normalperson <at> yhbt.net> writes:
>
> > Also, something that can wrap (git commit && git svn dcommit) into one
> > step would be nice.
>
> What I'd like to see is foreign systems integration for git pull/push. If git
> had to use git-svn behind the curtains, so be it would be -very- nice if the
> user could just use git pull/push.
Both push and pull are git/bk/hg(?)-specific terms; most SVN users are
not accustomed to them. Using 'pull' with git-svn has already been
discouraged for a while (since the introduction of dcommit); and
having a 'push' without a 'pull' would be very confusing.
I am interested in putting the .git/svn/*/info/url information into
.git/config, however (like modern remotes).
--
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Jakub Narebski @ 2006-12-03 1:31 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200612030224.50592.robin.rosenberg.lists@dewire.com>
Dnia niedziela 3. grudnia 2006 02:24, Robin Rosenberg napisał:
> lördag 02 december 2006 21:16 skrev Jakub Narebski:
> > The problem with submodule as separate git repository is that if you
> > move submodule (subproject) somewhere else in the repository (or just
> > rename it), you have to update alternates file... and this happens not
> > only on move itself, but also on checkout and reset. But that can be
> > managed by having in alternates all possible places the submodule ends
> > into. I don't know if it is truly a problem.
>
> A nasty problem with separate repositories for submodules is that when you
> screw up and git complains about everything you try do do, you previously
> could do rm -rf *; git reset --hard and retry whatever you were trying to do.
> With separate repositories your submodules will be resting in /dev/null,
> unless you're very, very careful.
Actually, rm -rf * is not needed for "git reset --hard" or
"git checkout -f" to succeed.
--
Jakub Narebski
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Robin Rosenberg @ 2006-12-03 1:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eksmrf$c33$1@sea.gmane.org>
lördag 02 december 2006 21:16 skrev Jakub Narebski:
> The problem with submodule as separate git repository is that if you
> move submodule (subproject) somewhere else in the repository (or just
> rename it), you have to update alternates file... and this happens not
> only on move itself, but also on checkout and reset. But that can be
> managed by having in alternates all possible places the submodule ends
> into. I don't know if it is truly a problem.
A nasty problem with separate repositories for submodules is that when you
screw up and git complains about everything you try do do, you previously
could do rm -rf *; git reset --hard and retry whatever you were trying to do.
With separate repositories your submodules will be resting in /dev/null,
unless you're very, very careful.
^ permalink raw reply
* problem in unpack-trees.c
From: Roman Zippel @ 2006-12-03 1:21 UTC (permalink / raw)
To: git
Hi,
Git currently fails to succeed the tests as you can see here:
http://buildd.debian.org/fetch.cgi?&pkg=git-core&ver=1%3A1.4.4-2&arch=m68k&stamp=1164303729&file=log
I looked into it and the problem is during the "git-read-tree --reset"
step and it seems that the local df_conflict_entry variable of
unpack_trees() survives past that function. If you check in
add_cache_entry() it's called with this variable and only because
verify_path() fails it's not added to the tree on the other archs, but on
m68k the data on the stack is a bit different and thus verify_path()
succeeds and the stack variable is added to the tree and later saved.
Using the patch below, you can simulate what's happing on m68k and now I
need some help fixing this properly, as I'm not that familiar with the
internals.
Thanks.
bye, Roman
diff -ur git-core-1.4.4.1/unpack-trees.c git-core-1.4.4.1/unpack-trees.c
--- git-core-1.4.4.1/unpack-trees.c 2006-11-23 03:38:07.000000000 +0100
+++ git-core-1.4.4.1/unpack-trees.c 2006-12-03 01:54:04.000000000 +0100
@@ -370,7 +370,10 @@
int i;
struct object_list *posn = trees;
struct tree_entry_list df_conflict_list;
- struct cache_entry df_conflict_entry;
+ static struct {
+ struct cache_entry entry;
+ char name[4];
+ } df_conflict_entry;
memset(&df_conflict_list, 0, sizeof(df_conflict_list));
df_conflict_list.next = &df_conflict_list;
@@ -382,7 +385,8 @@
o->merge_size = len;
memset(&df_conflict_entry, 0, sizeof(df_conflict_entry));
- o->df_conflict_entry = &df_conflict_entry;
+ o->df_conflict_entry = &df_conflict_entry.entry;
+ df_conflict_entry.entry.name[0] = 'x';
if (len) {
posns = xmalloc(len * sizeof(struct tree_entry_list *));
@@ -399,6 +403,7 @@
die("Merge requires file-level merging");
check_updates(active_cache, active_nr, o);
+ memset(&df_conflict_entry, 0x11, sizeof(df_conflict_entry));
return 0;
}
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Josef Weidendorfer @ 2006-12-03 1:11 UTC (permalink / raw)
To: Martin Waitz; +Cc: Linus Torvalds, sf, Git Mailing List, Andy Parkins
In-Reply-To: <20061202205853.GW18810@admingilde.org>
On Saturday 02 December 2006 21:58, Martin Waitz wrote:
> So I was not against the link object itself (initially I wanted to do it
> this way, too), only agains the information which was proposed to be
> stored there. Up to now I haven't found anything which makes sense to
> store next to the submodule commit to define the identity of the
> submodule.
Isn't it enough reason that a porcelain probably wants to store meta
information for a given submodule, giving the need to put a name/identity
to it?
Josef
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Josef Weidendorfer @ 2006-12-03 1:02 UTC (permalink / raw)
To: Martin Waitz; +Cc: Andy Parkins, git
In-Reply-To: <20061202204350.GV18810@admingilde.org>
On Saturday 02 December 2006 21:43, Martin Waitz wrote:
> On Sat, Dec 02, 2006 at 02:50:45PM +0100, Josef Weidendorfer wrote:
> > On Saturday 02 December 2006 11:04, Andy Parkins wrote:
> > > > So what do you do with deleted submodules?
> > > > You wouldn't want them to still sit around in your working directory,
> > > > but you still have to preserve them.
> > >
> > > Now that is a tricky one. Mind you, I think that problem exists for any
> > > implementation. I haven't got a good answer for that.
> >
> > That suggests that it is probably better to separate submodule repositories
> > from their checked out working trees. Why not put the GITDIRs of the submodules
> > in subdirectories of the supermodules GITDIR instead?
>
> Why not simply use a shared object database instead?
Sure. I have no problem with this.
But can we go one step further?
AFAICS your submodules store the .git/ directories of submodules directly
at submodule position in the working tree - but you have a link .git/objects
into the object database of the supermodule.
When the user wants to delete the submodule, he would remove this .git/ directory,
too. So you loose the .git/refs of the submodule etc. I would suggest to put
the submodule .git dirs into the .git dir of the supermodule.
^ permalink raw reply
* EGIT unpackedreadr problem
From: Robin Rosenberg @ 2006-12-03 1:00 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
Subject: [PATCH] Utility to show a log.
This program shows commit information for a commit.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
The main reason for this patch is not the program itself. The new code to
read really fast but doesn't always work.
Try the supplied program. I get no parents and the treeid
is wrong. An interesting thing is that if you look in the debugger the author
and commit messag is actually correct. Only the tree id and parent are wrong.
Not sure what's going on. The UnpackedReader "looks" like it does
the equivalent of what it did before,but apparently it isn't.
Reading commits from packs works fine. It's the unpacked reader that's bad.
-- robin
# java -Xmx100m -cp /home/me/SW/EGIT/org.spearce.jgit/bin org.spearce.jgit.pgm.Log c1ad80df56ff5f9d945eac8ac905b8009de30081
commit c1ad80df56ff5f9d945eac8ac905b8009de30081
tree 7ba4b782c23bb35b0cb7dbc46cfc09a6e887e19d
author PersonIdent[Shawn O. Pearce, spearce@spearce.org, Wed Nov 29 21:02:45 CET 2006]
Misc. code formatting cleanups.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
# git cat-file -p c1ad80df56ff5f9d945eac8ac905b8009de30081
tree a7ba4b7f1824763f182b6d45288e52fceece3c65b
parent 82c23bb35b0cb7dbc46cfc09a6e887e19dfb20f9
author Shawn O. Pearce <spearce@spearce.org> 1164830576 -0500
committer Shawn O. Pearce <spearce@spearce.org> 1164830576 -0500
Misc. code formatting cleanups.
[...]
org.spearce.jgit/src/org/spearce/jgit/pgm/Log.java | 23 ++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/pgm/Log.java b/org.spearce.jgit/src/org/spearce/jgit/pgm/Log.java
new file mode 100644
index 0000000..9598792
--- /dev/null
+++ b/org.spearce.jgit/src/org/spearce/jgit/pgm/Log.java
@@ -0,0 +1,23 @@
+ package org.spearce.jgit.pgm;
+
+ import java.io.File;
+ import java.io.IOException;
+import java.util.Iterator;
+
+import org.spearce.jgit.lib.Commit;
+import org.spearce.jgit.lib.Repository;
+
+ public class Log {
+ public static void main(String[] args) throws IOException {
+ Repository db = new Repository(new File(".git"));
+ Commit commit = db.mapCommit(args[0]);
+ System.out.println("commit "+commit.getCommitId());
+ System.out.println("tree "+commit.getTreeId());
+ for (Iterator ci=commit.getParentIds().iterator(); ci.hasNext(); ) {
+ System.out.println("parent "+ci.next());
+ }
+ System.out.println("author "+commit.getAuthor());
+ System.out.println();
+ System.out.println(commit.getMessage());
+ }
+ }
--
1.4.4.gf05d
^ permalink raw reply related
* Re: [RFC] Submodules in GIT
From: Josef Weidendorfer @ 2006-12-03 0:55 UTC (permalink / raw)
To: Martin Waitz; +Cc: Linus Torvalds, sf, git
In-Reply-To: <20061202202428.GT18810@admingilde.org>
On Saturday 02 December 2006 21:24, Martin Waitz wrote:
> On Sat, Dec 02, 2006 at 12:17:44AM +0100, Josef Weidendorfer wrote:
> > After some thinking, a submodule namespace even is important for checking
> > out only parts of a supermodule, exactly because the root of a submodule
> > potentially can change at every commit.
>
> have you ever thought about the idea that the location may be an
> important thing to consider for your decision.
Which decision, for what? Sorry, I do not understand.
Do you want to say that relative submodule root paths should be kept fix
the whole lifetime of a supermodule?
Ie. a submodule "identity" is bound to its relative path, and when we
move it, it should be seen as deleting at and creating a totally new,
different submodule?
That's fine.
But you have to handle submodule creation/deletion neverless. And while
you are at a commit which has a given submodule deleted, you have to
keep the submodule data somewhere - referencing it with a name.
I do not speak here about the object database, that could be combined;
but about all the other files in .git/ of the currently not checked out
submodule.
> Perhaps the submodule is now used for something else (this is why it was
> moved) and that now you'd like to keep it?
Can you give a usage szenario? What do you mean here?
> Anyway, you can just create several supermodules or implement generic
> partial tree support for git. I do not see any reason to special case
> submodules here.
What should such a general partial tree support look like? I suppose you
want to configure paths which should not be checked out. As long as you
say that a given submodule always has to exist at a given path, you are
right: then, you can say: "Please, do not check out this submodule" which
is the same as "Do not check out this path".
But I think it is quite restrictive to not allow to move submodules around.
When the supermodule upstream decides to move a submodule, your partial
tree config to not check out a submodule will be lost.
But more important, if you made changes to a given submodule, and pull from
upstream which changed the submodule position in-between, your changes will
be not taken over to the new position, as the move is seen as creation of
a totally independent submodule.
^ permalink raw reply
* [PATCH] Oops, get the commit first, then the tree.
From: Robin Rosenberg @ 2006-12-03 0:45 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
This made the eclipse plugin unable to connect to Git.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../src/org/spearce/jgit/lib/Repository.java | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
index bfdcd3e..2344817 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
@@ -168,7 +168,8 @@ public class Repository {
}
public Tree mapTree(final String revstr) throws IOException {
- final ObjectId id = resolve(revstr);
+ Commit commit = mapCommit(revstr);
+ final ObjectId id = commit.getTreeId();
return id != null ? mapTree(id) : null;
}
--
1.4.4.gf05d
^ permalink raw reply related
* [EGIT PATCH] Convert author and comment on demand.
From: Robin Rosenberg @ 2006-12-03 0:45 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
This sppeds up reading commits a lot by only store the byte
array data when reading commits. For the eclipse plugin I only
need the tree to filter out which commits to display and I can
take the cost of converting the comments to string for the
very few commits to display. Only the displayed commits are actually
converted so this results in convertig author and comment information
for about five commits rather than 20,000 (in my repo).
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../src/org/spearce/jgit/lib/Commit.java | 73 +++++++++++++------
1 files changed, 50 insertions(+), 23 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Commit.java
b/org.spearce.jgit/src/org/spearce/jgit/lib/Commit.java
index 4e03a5a..14fa602 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Commit.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Commit.java
@@ -16,10 +16,16 @@
*/
package org.spearce.jgit.lib;
+import java.io.BufferedReader;
+import java.io.ByteArrayInputStream;
import java.io.IOException;
+import java.io.InputStreamReader;
+import java.nio.charset.Charset;
import java.util.ArrayList;
+import java.util.Arrays;
import java.util.List;
+import org.spearce.jgit.errors.CorruptObjectException;
import org.spearce.jgit.errors.MissingObjectException;
public class Commit implements Treeish {
@@ -39,6 +45,8 @@ public class Commit implements Treeish {
private Tree treeObj;
+ private byte[] raw;
+
public Commit(final Repository db) {
objdb = db;
parentIds = new ArrayList(2);
@@ -58,29 +66,7 @@ public class Commit implements Treeish {
rawPtr += 48;
}
- //
- // if (n == null || !n.startsWith("author ")) {
- // throw new CorruptObjectException(commitId, "no author");
- // }
- // author = new PersonIdent(n.substring("author ".length()));
- //
- // n = br.readLine();
- // if (n == null || !n.startsWith("committer ")) {
- // throw new CorruptObjectException(commitId, "no committer");
- // }
- // committer = new PersonIdent(n.substring("committer ".length()));
- //
- // n = br.readLine();
- // if (n == null || !n.equals("")) {
- // throw new CorruptObjectException(commitId, "malformed header");
- // }
- //
- // tempMessage = new StringBuffer();
- // readBuf = new char[128];
- // while ((readLen = br.read(readBuf)) > 0) {
- // tempMessage.append(readBuf, 0, readLen);
- // }
- // message = tempMessage.toString();
+ this.raw = raw;
}
public ObjectId getCommitId() {
@@ -119,6 +105,7 @@ public class Commit implements Treeish {
}
public PersonIdent getAuthor() {
+ decode();
return author;
}
@@ -127,6 +114,7 @@ public class Commit implements Treeish {
}
public PersonIdent getCommitter() {
+ decode();
return committer;
}
@@ -139,9 +127,48 @@ public class Commit implements Treeish {
}
public String getMessage() {
+ decode();
return message;
}
+ private void decode() {
+ if (raw!=null) {
+ try {
+ BufferedReader br=new BufferedReader(new InputStreamReader(new
ByteArrayInputStream(raw)));
+ String n=br.readLine();
+ if (n == null || !n.startsWith("tree ")) {
+ throw new CorruptObjectException(commitId, "no tree");
+ }
+ while ((n = br.readLine())!=null && n.startsWith("parent "))
+ ;
+ if (n == null || !n.startsWith("author ")) {
+ throw new CorruptObjectException(commitId, "no author");
+ }
+ author = new PersonIdent(n.substring("author ".length()));
+ n = br.readLine();
+ if (n == null || !n.startsWith("committer ")) {
+ throw new CorruptObjectException(commitId, "no
committer");
+ }
+ committer = new
PersonIdent(n.substring("committer ".length()));
+ n = br.readLine();
+ if (n == null || !n.equals("")) {
+ throw new CorruptObjectException(commitId, "malformed
header");
+ }
+ StringBuffer tempMessage = new StringBuffer();
+ char[] readBuf = new char[2048];
+ int readLen;
+ while ((readLen = br.read(readBuf)) > 0) {
+ tempMessage.append(readBuf, 0, readLen);
+ }
+ message = tempMessage.toString();
+ } catch (IOException e) {
+ e.printStackTrace();
+ } finally {
+ raw = null;
+ }
+ }
+ }
+
public void setMessage(final String m) {
message = m;
}
--
1.4.4.gf05d
^ permalink raw reply related
* [PATCH] git-svn: avoid fetching files twice in the same revision
From: Eric Wong @ 2006-12-03 0:19 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <20061202223419.GA7057@localdomain>
SVN is not entirely consistent in returning log information and
sometimes returns file information when adding subdirectories,
and sometimes it does not (only returning information about the
directory that was added). This caused git-svn to occasionally
add a file to the list of files to be fetched twice. Now we
change the data structure to be hash to avoid repeated fetches.
As of now (in master), this only affects repositories fetched
without deltas enabled (file://, and when manually overriden
with GIT_SVN_DELTA_FETCH=0); so this bug mainly affects users of
1.4.4.1 and maint.
Thanks to Florian Weimer for reporting this bug.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 3891122..d0bd0bd 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2982,7 +2982,7 @@ sub libsvn_fetch_delta {
sub libsvn_fetch_full {
my ($last_commit, $paths, $rev, $author, $date, $msg) = @_;
open my $gui, '| git-update-index -z --index-info' or croak $!;
- my @amr;
+ my %amr;
my $p = $SVN->{svn_path};
foreach my $f (keys %$paths) {
my $m = $paths->{$f}->action();
@@ -3001,7 +3001,7 @@ sub libsvn_fetch_full {
my $t = $SVN->check_path($f, $rev, $pool);
if ($t == $SVN::Node::file) {
if ($m =~ /^[AMR]$/) {
- push @amr, [ $m, $f ];
+ $amr{$f} = $m;
} else {
die "Unrecognized action: $m, ($f r$rev)\n";
}
@@ -3009,13 +3009,13 @@ sub libsvn_fetch_full {
my @traversed = ();
libsvn_traverse($gui, '', $f, $rev, \@traversed);
foreach (@traversed) {
- push @amr, [ $m, $_ ]
+ $amr{$_} = $m;
}
}
$pool->clear;
}
- foreach (@amr) {
- libsvn_get_file($gui, $_->[1], $rev, $_->[0]);
+ foreach (keys %amr) {
+ libsvn_get_file($gui, $_, $rev, $amr{$_});
}
close $gui or croak $?;
return libsvn_log_entry($rev, $author, $date, $msg, [$last_commit]);
--
1.4.4.1.gdf6b
^ permalink raw reply related
* Re: [PATCH 1/2] move Git.pm build instructions into perl/Makefile
From: Junio C Hamano @ 2006-12-02 23:46 UTC (permalink / raw)
To: Alex Riesen; +Cc: Alex Riesen, git
In-Reply-To: <81b0412b0611300827h64722fa0i7e32808994a97a51@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
>
> ---
>
> This is the first patch, just rebased upon current master.
> The ActiveState-related parts follow
Huh?
Ah, attachment that is not inline.
diff --git a/perl/.gitignore b/perl/.gitignore
index e990cae..98b2477 100644
--- a/perl/.gitignore
+++ b/perl/.gitignore
@@ -1,4 +1,5 @@
-Makefile
+perl.mak
+perl.mak.old
blib
blibdirs
pm_to_blib
This, and perl/Makefile not cleaning perl.mak.old, are wrong.
"make && make clean" after a fresh checkout should leave the
working tree the same state is it were.
^ permalink raw reply related
* Re: git-svn: File added multiple times?
From: Florian Weimer @ 2006-12-02 22:41 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <87u00dord9.fsf@mid.deneb.enyo.de>
* Florian Weimer:
> * Eric Wong:
>
>>> Is this expected?
>>> It's somewhat counter-intuitive, at least. This is with Debian's
>>> git-core 1.4.4.1-1 package, and the SVN:: Perl modules are installed.
>>
>> No it's not expected. Is this on a public SVN repo I can look at?
>> Thanks.
>
> This is the svn://mlton.org/mlton/trunk repository. The second commit
> shows this behavior, but it's a bit large.
It also occurs with r2048, which is smaller:
[...]
A mlton/trunk/doc/examples/finalizable/cons.c
A mlton/trunk/doc/examples/finalizable/cons.c
[...]
^ permalink raw reply
* Re: [PATCH] git-svn: correctly access repos when only given partial read permissions
From: Sam Vilain @ 2006-12-02 22:40 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <20061202222433.GA21171@localdomain>
Eric Wong wrote:
>> I now get this error:
>>
>> Filesystem has no item: File not found: revision 8514, path
>> '/mirror/fai/tags/mirror/fai/tags' at /home/samv/src/git/git-svn line 3236
>
> This should be fixed in 1ca7558dd838e82f6f6b8611b981654fa4ecde2b in
> Junio's master: "git-svn: fix multi-init".
Ah, so it did. Silly me for running on ancient version of git-svn ;)
>> (next, I'll make git-svn correctly look at the svm:* revprops to get the
>> upstream repo URL and revision number for the commit message)
>
> Cool. While you're at it, would you mind looking into supporting some
> of the merge revprops that I've heard about, too? Thanks.
Great idea, I'll certainly do that. Of course, they are relative to the
*local* repository...
^ permalink raw reply
* Re: git-svn: File added multiple times?
From: Florian Weimer @ 2006-12-02 22:38 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061202223419.GA7057@localdomain>
* Eric Wong:
>> Is this expected?
>> It's somewhat counter-intuitive, at least. This is with Debian's
>> git-core 1.4.4.1-1 package, and the SVN:: Perl modules are installed.
>
> No it's not expected. Is this on a public SVN repo I can look at?
> Thanks.
This is the svn://mlton.org/mlton/trunk repository. The second commit
shows this behavior, but it's a bit large.
> This is (or only seems to be) a UI reporting error and the actual data
> imported should be correct.
I think it might download the data multiple times as well (at least
the timing suggests that). The generated repository seems to be fine,
though. The import is still running, so I haven't done any
^ permalink raw reply
* Re: git-svn: File added multiple times?
From: Eric Wong @ 2006-12-02 22:34 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87psb2ou6f.fsf@mid.deneb.enyo.de>
Florian Weimer <fw@deneb.enyo.de> wrote:
> Is this expected?
>
> $ sort /tmp/git-svn-output | uniq -c | sort -rn | head
> 4 A mlton/trunk/doc/web/papers/index.html
> 4 A mlton/trunk/doc/web/papers/01-icfp.ps.gz
> 4 A mlton/trunk/doc/web/papers/00-esop.ps.gz
> 4 A mlton/trunk/doc/examples/save-world/save-world.sml
> 4 A mlton/trunk/doc/examples/save-world/Makefile
> 4 A mlton/trunk/doc/examples/profiling/profiling.sml
> 4 A mlton/trunk/doc/examples/profiling/Makefile
> 4 A mlton/trunk/doc/examples/ffi/Makefile
> 4 A mlton/trunk/doc/examples/ffi/main.sml
> 4 A mlton/trunk/doc/examples/ffi/ffi.h
> $
>
> It's somewhat counter-intuitive, at least. This is with Debian's
> git-core 1.4.4.1-1 package, and the SVN:: Perl modules are installed.
No it's not expected. Is this on a public SVN repo I can look at?
Thanks.
git-svn 1.4.4.1 always cat-ed the entire file (this code was stolen from
git-svnimport, the version in master can transfer deltas).
This is (or only seems to be) a UI reporting error and the actual data
imported should be correct.
--
^ permalink raw reply
* Re: [RFC] Introduce "git stage" (along with some heresy)
From: Wink Saville @ 2006-12-02 22:33 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87slfzfri7.wl%cworth@cworth.org>
Carl Worth wrote:
>
> Without staging
> ---------------
> add Add a file to be managed by git
>
> rm Remove a file to no longer be managed by git
>
> diff Show the changes in the working tree compared to the
> latest commit, (or compared to staged content, if any)
>
> commit Commit the current state of all git-managed files
>
> commit files... Commit the current state of the specified files
>
As a newbie like this entire proposal and especially the above.
Wink Saville
^ permalink raw reply
* Re: [PATCH] git-svn: correctly access repos when only given partial read permissions
From: Eric Wong @ 2006-12-02 22:24 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, git
In-Reply-To: <4571F6E7.4050809@vilain.net>
Sam Vilain <sam@vilain.net> wrote:
> Eric Wong wrote:
> > Sometimes users are given only read access to a subtree inside a
> > repository, and git-svn could not read log information (and thus
> > fetch commits) when connecting a session to the root of the
> > repository. We now start an SVN::Ra session with the full URL
> > of what we're tracking, and not the repository root as before.
> >
> > This change was made much easier with a cleanup of
> > repo_path_split() usage as well as improving the accounting of
> > authentication batons.
>
> This broke mirroring file:/// URIs;
>
> eg, if I have ~/.svk/local as a SVN repository, which has a complete
> mirror of a URL under mirror/fai, and I want to copy the revisions into
> git using git-svn, I use:
>
> perl ~/src/git/git-svn multi-init -t tags -T trunk \
> file:///home/samv/.svk/local/mirror/fai
>
> I now get this error:
>
> Filesystem has no item: File not found: revision 8514, path
> '/mirror/fai/tags/mirror/fai/tags' at /home/samv/src/git/git-svn line 3236
This should be fixed in 1ca7558dd838e82f6f6b8611b981654fa4ecde2b in
Junio's master: "git-svn: fix multi-init".
> (next, I'll make git-svn correctly look at the svm:* revprops to get the
> upstream repo URL and revision number for the commit message)
Cool. While you're at it, would you mind looking into supporting some
of the merge revprops that I've heard about, too? Thanks.
--
^ permalink raw reply
* Re: [PATCH] git-svn: correctly access repos when only given partial read permissions
From: Sam Vilain @ 2006-12-02 21:57 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <11644366982320-git-send-email-normalperson@yhbt.net>
Eric Wong wrote:
> Sometimes users are given only read access to a subtree inside a
> repository, and git-svn could not read log information (and thus
> fetch commits) when connecting a session to the root of the
> repository. We now start an SVN::Ra session with the full URL
> of what we're tracking, and not the repository root as before.
>
> This change was made much easier with a cleanup of
> repo_path_split() usage as well as improving the accounting of
> authentication batons.
This broke mirroring file:/// URIs;
eg, if I have ~/.svk/local as a SVN repository, which has a complete
mirror of a URL under mirror/fai, and I want to copy the revisions into
git using git-svn, I use:
perl ~/src/git/git-svn multi-init -t tags -T trunk \
file:///home/samv/.svk/local/mirror/fai
I now get this error:
Filesystem has no item: File not found: revision 8514, path
'/mirror/fai/tags/mirror/fai/tags' at /home/samv/src/git/git-svn line 3236
(next, I'll make git-svn correctly look at the svm:* revprops to get the
upstream repo URL and revision number for the commit message)
^ 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