* Re: git-svn failure when symlink added in svn
From: Alexander Klink @ 2007-05-01 20:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, Seth Falcon, Alexander Klink, git
In-Reply-To: <7vmz0qcuut.fsf@assigned-by-dhcp.cox.net>
On Sun, Apr 29, 2007 at 10:08:26PM -0700, Junio C Hamano wrote:
> -- >8 --
> [PATCH] Fix symlink handling in git-svn, related to PerlIO
>
[...]
> This attempts to fix the issue by using lower level sysseek and
> sysread instead of seek and read to bypass the stdio buffer.
Works fine here, too. Thanks again for the quick response ...
Regards,
Alex
^ permalink raw reply
* Re: svn:externals using git submodules
From: Chris Shoemaker @ 2007-05-01 20:23 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Shawn O. Pearce
In-Reply-To: <200705012048.04817.andyparkins@gmail.com>
On Tue, May 01, 2007 at 08:48:01PM +0100, Andy Parkins wrote:
> On Tuesday 2007, May 01, Chris Shoemaker wrote:
>
> > That's only true when the revision is not specified in the external.
> > The repo you track may not do that, but it's not uncommon to do so.
>
> It's been a while since I used subversion, and even longer since I used
> externals - is that a new feature?
I don't know, but I would guess that it's no newer than externals in
general, as it's not a particularly special case.
> I used subversion since before
> version 1.0, so I often missed new features when they arrived.
>
> > And, as I think you're pointing out, it's the only way to get any
> > sort of reliable information about the relationship between the
> > parent and the external.
>
> Does subversion automatically update that fixed attachment when you
> update the submodule? I would have found that quite useful back then.
No, you have to manage the revision in the svn:external property
manually.
> > I think it would probably be undesirable for git-svn to attempt to
> > convert "floating" externals into well-versioned submodules, since
> > they're not even well-versioned in the svn repo. However, handling
> > the "locked-down" externals is quite another thing.
>
> Absolutely. If the information is available, then git is certainly
> capable of recording it. It sounds like subversion has a facility I
> didn't know exist, so I've been bad mouthing it more than I should. Oh
> well :-)
>
Making git-svn handle svn:externals with specified revisions would be
_quite_ useful. There's a special-case of this that I use personally:
svn:externals that point to other paths (and other revisions) of the
parent repo.
I'm curious if people think that teaching git-svn to handle this
special case is more or less difficult than handling the general case.
-chris
^ permalink raw reply
* Re: [StGIT RFC PATCH] Don't use refs/bases/<branchname>
From: Marco Costalba @ 2007-05-01 19:59 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20070501185615.GA32727@diana.vm.bytemark.co.uk>
On 5/1/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-05-01 11:10:47 +0200, Marco Costalba wrote:
>
> > The only StGit data read directly are patches sha's; qgit walks
> > recursively all the files called "top" under directory tree
> >
> > <git dir>/patches/<current branch>
> >
> > to get sha list of each applied and unapplied patch in one go. This
> > is much faster then calling "stg id <patch name>" for all the
> > patches.
>
> Hmm. These are on my kill list too. :-)
>
> The patch tops are already recorded in
> refs/patches/<branch>/<patchname> to keep them from being garbage
> collected, so these top files are redundant. But it isn't _that_ bad,
> so if removing them would break qgit, I guess I could try to restrain
> myself. At least all the other metadata is fair game. :-)
>
> (But if I were you, I'd look for the patches under patches/refs
> anyway; they _have_ to be there to survive garbage collection, so no
> amount of stgit refactoring will break qgit.)
>
Well, I did. ;-)
Actually I pushed a patch few hours ago to read patches sha under refs/patches.
The problem is that the patch (for now) is pushed only for the new
development version of qgit, not the stable one and, worse, all the
currently released versions will break if you remove <git
dir>/patches/ directory.
So please, if possible deprecate <git dir>/patches/ directory but do
not remove for a while, so to let users to upgrade gracefully.
Thanks
Marco
^ permalink raw reply
* Re: svn:externals using git submodules
From: Andy Parkins @ 2007-05-01 19:48 UTC (permalink / raw)
To: git; +Cc: Chris Shoemaker, Shawn O. Pearce
In-Reply-To: <20070501191703.GA25287@pe.Belkin>
On Tuesday 2007, May 01, Chris Shoemaker wrote:
> That's only true when the revision is not specified in the external.
> The repo you track may not do that, but it's not uncommon to do so.
It's been a while since I used subversion, and even longer since I used
externals - is that a new feature? I used subversion since before
version 1.0, so I often missed new features when they arrived.
> And, as I think you're pointing out, it's the only way to get any
> sort of reliable information about the relationship between the
> parent and the external.
Does subversion automatically update that fixed attachment when you
update the submodule? I would have found that quite useful back then.
> I think it would probably be undesirable for git-svn to attempt to
> convert "floating" externals into well-versioned submodules, since
> they're not even well-versioned in the svn repo. However, handling
> the "locked-down" externals is quite another thing.
Absolutely. If the information is available, then git is certainly
capable of recording it. It sounds like subversion has a facility I
didn't know exist, so I've been bad mouthing it more than I should. Oh
well :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: svn:externals using git submodules
From: Chris Shoemaker @ 2007-05-01 19:17 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Shawn O. Pearce
In-Reply-To: <200705011936.14345.andyparkins@gmail.com>
On Tue, May 01, 2007 at 07:36:11PM +0100, Andy Parkins wrote:
> On Tuesday 2007, May 01, Chris Shoemaker wrote:
>
> > > Actually that is an interesting point that Chris makes. Isn't the
> > > svn:externals property revision controlled on the parent directory?
> > > So each change to it is actually recorded in the revision history
> > > of the parent project.
> >
> > Yes and yes.
>
> Yes and no. Think of svn:externals as a file in the parent repository;
> it contains
>
> directory-name URL
>
> Now, changes to that file _are_ tracked, in that if I changed the URL
> that change would be recorded in the parent repository. However,
> nowhere is the revision of the external recorded. Subversion always
> fetches the latest revision at that URL.
That's only true when the revision is not specified in the external.
The repo you track may not do that, but it's not uncommon to do so.
And, as I think you're pointing out, it's the only way to get any sort
of reliable information about the relationship between the parent and
the external.
I think it would probably be undesirable for git-svn to attempt to
convert "floating" externals into well-versioned submodules, since
they're not even well-versioned in the svn repo. However, handling
the "locked-down" externals is quite another thing.
>
> > > And if every svn:externals URL included the
> > > exact version of the other project to include, aren't svn:externals
> > > then more-or-less like the subproject link support, except they
> > > also include the URL?
> >
> > Just to clarify, my point was just that Andy's setup seems to assume
> > that the externals don't specify a revision. If they do, maybe
>
> They don't. If they did, they'd be just as useful as git's submodules.
>
> > git-svn can map the externals into subprojects. Is this what
> > you're thinking?
>
> Well, I'm thinking that that information /can/ be reconstructed from the
> revision date information - kind of - the problem is that there is no
> way to know when the parent updated the module. svn:externals really
> is just a quick way of doing
> $ cd submodule
> $ svn update
> That's it. That's all you get. We could guess that when the parent
> module was at date YYYY-MM-DD, that the submodule would be at that same
> date - but who knows?
svn users who want the externals to meaningfully define the version
relationship between the parent and the project already have to use
externals that specify a revision.
-chris
^ permalink raw reply
* Re: [PATCH 0/8] git-repack --max-pack-size
From: Junio C Hamano @ 2007-05-01 19:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, Andy Parkins, git
In-Reply-To: <Pine.LNX.4.64.0705011939590.4010@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Tue, 1 May 2007, Junio C Hamano wrote:
>
>> Nicolas Pitre <nico@cam.org> writes:
>>
>> > On Tue, 1 May 2007, Junio C Hamano wrote:
>> >
>> >> I was not sure if that is even a good idea, and I am now
>> >> inclined to think that keeping the failed attempt history is
>> >> probably better than potentially causing confusion to people who
>> >> follow 'next'. But it _is_ a possibility to reset 'next' to
>> >> 'master'.
>> >
>> > And what is the advantage of doing that, exactly?
>>
>> Not much and that is why I am not sure if that is a good idea,
>> but one thing is:
>>
>> $ git log master..next
>> $ git log --no-merges master..next
>>
>> would start showing what are still pending in next without
>> noise.
>
> Of course, you could graft a fake relationship there. Something like
>
> echo $(git rev-parse master master^ next) >> .git/info/grafts
>
> should do. And you can do it _locally_, since all you care about is the
> higher-level relationship that _you_ know about. And this is the way to
> teach Git about it.
In case you did not get it, making the above usable is not about _me_.
^ permalink raw reply
* Re: [StGIT RFC PATCH] Don't use refs/bases/<branchname>
From: Karl Hasselström @ 2007-05-01 18:56 UTC (permalink / raw)
To: Marco Costalba; +Cc: Catalin Marinas, git
In-Reply-To: <e5bfff550705010210i352ac9eej6ff7a78aae6535c9@mail.gmail.com>
On 2007-05-01 11:10:47 +0200, Marco Costalba wrote:
> On 5/1/07, Catalin Marinas <catalin.marinas@gmail.com> wrote:
>
> > I'm OK with this patch as long as tools like qgit don't rely on
> > this ref.
>
> It's OK for me. A recent qgit already filters out content of
> refs/bases to reduce visual 'noise'.
Good.
> The only StGit data read directly are patches sha's; qgit walks
> recursively all the files called "top" under directory tree
>
> <git dir>/patches/<current branch>
>
> to get sha list of each applied and unapplied patch in one go. This
> is much faster then calling "stg id <patch name>" for all the
> patches.
Hmm. These are on my kill list too. :-)
The patch tops are already recorded in
refs/patches/<branch>/<patchname> to keep them from being garbage
collected, so these top files are redundant. But it isn't _that_ bad,
so if removing them would break qgit, I guess I could try to restrain
myself. At least all the other metadata is fair game. :-)
(But if I were you, I'd look for the patches under patches/refs
anyway; they _have_ to be there to survive garbage collection, so no
amount of stgit refactoring will break qgit.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 4/8] git-repack --max-pack-size: add fixup_header_footer()
From: Nicolas Pitre @ 2007-05-01 18:39 UTC (permalink / raw)
To: Dana How; +Cc: Shawn O. Pearce, Junio C Hamano, Git Mailing List
In-Reply-To: <56b7f5510705011058y89e4aa4p8f8b7eccde30af78@mail.gmail.com>
On Tue, 1 May 2007, Dana How wrote:
> I was in the middle of creating pack-write.c at Shawn's suggestion. It
> will only contain fixup_header_footer(), to be called by fast-import.c
> and builtin-pack-object.c. index-pack.c also has
> readjust_pack_header_and_sha1(), which is compatible except it doesn't
> close the file. I was going to leave it alone for now. This new file
> should be the logical place to put other common pack-writing-related
> things. Please barf now if you don't think I should do this tiny
> refactoring at this point.
That's fine. Please go ahead.
Nicolas
^ permalink raw reply
* Re: svn:externals using git submodules
From: Andy Parkins @ 2007-05-01 18:39 UTC (permalink / raw)
To: git; +Cc: Chris Shoemaker, Shawn O. Pearce
In-Reply-To: <200705011936.14345.andyparkins@gmail.com>
On Tuesday 2007, May 01, Andy Parkins wrote:
> Now, changes to that file _are_ tracked, in that if I changed the URL
> that change would be recorded in the parent repository. However,
> nowhere is the revision of the external recorded. Subversion always
> fetches the latest revision at that URL.
I meant to add as well that this is absolutely NOT the thing that you
want to be tracked. There are any number of times while using
externals that I reorganised a directory only to have to change the
svn:externals in the parent. That change is then tracked, so if you
check out an earlier version not only do you not get a particular
revision you also don't get the right URL, so subverion doesn't even
fetch the current version. Gah!
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: svn:externals using git submodules
From: Andy Parkins @ 2007-05-01 18:36 UTC (permalink / raw)
To: git; +Cc: Chris Shoemaker, Shawn O. Pearce
In-Reply-To: <20070501153626.GA21182@pe.Belkin>
On Tuesday 2007, May 01, Chris Shoemaker wrote:
> > Actually that is an interesting point that Chris makes. Isn't the
> > svn:externals property revision controlled on the parent directory?
> > So each change to it is actually recorded in the revision history
> > of the parent project.
>
> Yes and yes.
Yes and no. Think of svn:externals as a file in the parent repository;
it contains
directory-name URL
Now, changes to that file _are_ tracked, in that if I changed the URL
that change would be recorded in the parent repository. However,
nowhere is the revision of the external recorded. Subversion always
fetches the latest revision at that URL.
> > And if every svn:externals URL included the
> > exact version of the other project to include, aren't svn:externals
> > then more-or-less like the subproject link support, except they
> > also include the URL?
>
> Just to clarify, my point was just that Andy's setup seems to assume
> that the externals don't specify a revision. If they do, maybe
They don't. If they did, they'd be just as useful as git's submodules.
> git-svn can map the externals into subprojects. Is this what
> you're thinking?
Well, I'm thinking that that information /can/ be reconstructed from the
revision date information - kind of - the problem is that there is no
way to know when the parent updated the module. svn:externals really
is just a quick way of doing
$ cd submodule
$ svn update
That's it. That's all you get. We could guess that when the parent
module was at date YYYY-MM-DD, that the submodule would be at that same
date - but who knows?
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: git-svn and local only topic branch
From: Andy Parkins @ 2007-05-01 18:29 UTC (permalink / raw)
To: git; +Cc: Guilhem Bonnefille
In-Reply-To: <8b65902a0705010940pb3bfb16u624d470068351624@mail.gmail.com>
On Tuesday 2007, May 01, Guilhem Bonnefille wrote:
> o--o--o--o (upstream, remotes/upstream)
> \
> o--o--o--o (topic)
>
> Is there a way to do what I want?
No. Subversion doesn't do merge tracking. What you're asking for would
require that. While git-svn is good, it cannot give subversion
abilities it doesn't have.
It's an easy trap to fall into because git makes it so easy that you can
forget that not everyone else can do it.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* [PATCH] Create pack-write.c for common pack writing code
From: Dana How @ 2007-05-01 18:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, danahow, Shawn O. Pearce, Nicolas Pitre
Include a generalized fixup_header_footer() in this new file.
Needed by git-repack --max-pack-size feature in a later patchset.
Signed-off-by: Dana L. How <danahow@gmail.com>
---
Makefile | 4 ++--
fast-import.c | 39 ++-------------------------------------
pack-write.c | 38 ++++++++++++++++++++++++++++++++++++++
pack.h | 3 +++
4 files changed, 45 insertions(+), 39 deletions(-)
diff --git a/Makefile b/Makefile
index 2fea115..e0a1308 100644
--- a/Makefile
+++ b/Makefile
@@ -301,8 +301,8 @@ LIB_OBJS = \
interpolate.o \
lockfile.o \
patch-ids.o \
- object.o pack-check.o patch-delta.o path.o pkt-line.o sideband.o \
- reachable.o reflog-walk.o \
+ object.o pack-check.o pack-write.o patch-delta.o path.o pkt-line.o \
+ sideband.o reachable.o reflog-walk.o \
quote.o read-cache.o refs.o run-command.o dir.o object-refs.o \
server-info.o setup.o sha1_file.o sha1_name.o strbuf.o \
tag.o tree.o usage.o config.o environment.o ctype.o copy.o \
diff --git a/fast-import.c b/fast-import.c
index b4cbcd9..276e0e0 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -651,42 +651,6 @@ static void start_packfile(void)
all_packs[pack_id] = p;
}
-static void fixup_header_footer(void)
-{
- static const int buf_sz = 128 * 1024;
- int pack_fd = pack_data->pack_fd;
- SHA_CTX c;
- struct pack_header hdr;
- char *buf;
-
- if (lseek(pack_fd, 0, SEEK_SET) != 0)
- die("Failed seeking to start: %s", strerror(errno));
- if (read_in_full(pack_fd, &hdr, sizeof(hdr)) != sizeof(hdr))
- die("Unable to reread header of %s", pack_data->pack_name);
- if (lseek(pack_fd, 0, SEEK_SET) != 0)
- die("Failed seeking to start: %s", strerror(errno));
- hdr.hdr_entries = htonl(object_count);
- write_or_die(pack_fd, &hdr, sizeof(hdr));
-
- SHA1_Init(&c);
- SHA1_Update(&c, &hdr, sizeof(hdr));
-
- buf = xmalloc(buf_sz);
- for (;;) {
- ssize_t n = xread(pack_fd, buf, buf_sz);
- if (!n)
- break;
- if (n < 0)
- die("Failed to checksum %s", pack_data->pack_name);
- SHA1_Update(&c, buf, n);
- }
- free(buf);
-
- SHA1_Final(pack_data->sha1, &c);
- write_or_die(pack_fd, pack_data->sha1, sizeof(pack_data->sha1));
- close(pack_fd);
-}
-
static int oecmp (const void *a_, const void *b_)
{
struct object_entry *a = *((struct object_entry**)a_);
@@ -802,7 +766,8 @@ static void end_packfile(void)
struct branch *b;
struct tag *t;
- fixup_header_footer();
+ fixup_header_footer(pack_data->pack_fd, pack_data->sha1,
+ pack_data->pack_name, object_count);
idx_name = keep_pack(create_index());
/* Register the packfile with core git's machinary. */
diff --git a/pack-write.c b/pack-write.c
new file mode 100644
index 0000000..e4c1408
--- /dev/null
+++ b/pack-write.c
@@ -0,0 +1,38 @@
+#include "cache.h"
+#include "pack.h"
+
+void fixup_header_footer(int pack_fd, unsigned char *pack_file_sha1,
+ const char *pack_name, uint32_t object_count)
+{
+ static const int buf_sz = 128 * 1024;
+ SHA_CTX c;
+ struct pack_header hdr;
+ char *buf;
+
+ if (lseek(pack_fd, 0, SEEK_SET) != 0)
+ die("Failed seeking to start: %s", strerror(errno));
+ if (read_in_full(pack_fd, &hdr, sizeof(hdr)) != sizeof(hdr))
+ die("Unable to reread header of %s", pack_name);
+ if (lseek(pack_fd, 0, SEEK_SET) != 0)
+ die("Failed seeking to start: %s", strerror(errno));
+ hdr.hdr_entries = htonl(object_count);
+ write_or_die(pack_fd, &hdr, sizeof(hdr));
+
+ SHA1_Init(&c);
+ SHA1_Update(&c, &hdr, sizeof(hdr));
+
+ buf = xmalloc(buf_sz);
+ for (;;) {
+ size_t n = xread(pack_fd, buf, buf_sz);
+ if (!n)
+ break;
+ if (n < 0)
+ die("Failed to checksum %s", pack_name);
+ SHA1_Update(&c, buf, n);
+ }
+ free(buf);
+
+ SHA1_Final(pack_file_sha1, &c);
+ write_or_die(pack_fd, pack_file_sha1, 20);
+ close(pack_fd);
+}
diff --git a/pack.h b/pack.h
index d4d412c..dc296cc 100644
--- a/pack.h
+++ b/pack.h
@@ -45,6 +45,9 @@ struct pack_idx_header {
extern int verify_pack(struct packed_git *, int);
+void fixup_header_footer(int pack_fd, unsigned char *pack_file_sha1,
+ const char *pack_name, uint32_t object_count);
+
#define PH_ERROR_EOF (-1)
#define PH_ERROR_PACK_SIGNATURE (-2)
#define PH_ERROR_PROTOCOL (-3)
--
1.5.2.rc0.789.gd951
^ permalink raw reply related
* Re: [PATCH 4/8] git-repack --max-pack-size: add fixup_header_footer()
From: Dana How @ 2007-05-01 17:58 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn O. Pearce, Junio C Hamano, Git Mailing List, danahow
In-Reply-To: <alpine.LFD.0.98.0705011318000.6574@xanadu.home>
On 5/1/07, Nicolas Pitre <nico@cam.org> wrote:
> On Tue, 1 May 2007, Shawn O. Pearce wrote:
> > Dana How <danahow@gmail.com> wrote:
> > > On 4/30/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> > > > Why not
> > > > refactor both to use the same implementation and stuff it away in
> > > > say pack-check.c (for lack of a better place), or start a new file
> > > > (pack-write.c)?
> > > Actually I didn't just copy it, I tried to rewrite it for my use
> > > as well as the fast-import.c use (note there is a 3rd copy
> > > in some *index*.c file which I didn't try to merge in yet).
> > > However I didn't yet put it in a new file or change fast-import.c
> > > to call it since I wanted to change as little as possible.
> > ...
> > > I agree with all your arguments. I had several reasons
> > > to avoid extra rearrangements/refactorings:
> > > (a) First patch to git, not previously known to me;
> > > (b) I prefer to separate new functionality from "clean-up" work;
> >
> > A really good reason. ;-)
> >
> > But I'd still rather see it done right the first time, then done
> > partially (copied) and wait for someone to clean it up later.
> > Sometimes that cleanup doesn't happen.
>
> Well I intended to do more cleanups in the pack code eventually. That
> included the index writing and pack header fixing. But I was expecting
> for the pack splitting changes to go in first as it is likely to impose
> some requirements of its own. It is then easier to have a proper
> interface common to all users after everything is in place.
I was in the middle of creating pack-write.c at Shawn's suggestion.
It will only contain fixup_header_footer(), to be called by fast-import.c
and builtin-pack-object.c. index-pack.c also has
readjust_pack_header_and_sha1(),
which is compatible except it doesn't close the file. I was going to leave it
alone for now. This new file should be the logical place to put other common
pack-writing-related things. Please barf now if you don't think I
should do this
tiny refactoring at this point.
> > > I'd have no problem submitting a follow-on patch later containing
> > > some clean-up work if you & NP clear it, so I know I won't have
> > > problems from (d). Note I had to completely rewrite this patch
> > > when NP submitted some of his pending stuff.
> >
> > Yea, hazard of working in this part of the code when Nico is
> > also active. My own sliding mmap stuff was written twice too,
> > for the same reason - Nico doing much needed improvements right in
> > the same spot as I was working, at the same time.
>
> Well well. OK I'm used to be considered as the bad guy anyway. ;-)
You *did* tell me about your upcoming patches as I recall ;-)
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: git-svn failure when symlink added in svn
From: Seth Falcon @ 2007-05-01 17:49 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <20070430154359.GD1800@untitled>
Eric Wong <normalperson@yhbt.net> writes:
> Seth Falcon <sethfalcon@gmail.com> wrote:
>> Eric Wong <normalperson@yhbt.net> writes:
>>
>> > Seth Falcon <sethfalcon@gmail.com> wrote:
>> >> Eric: is there any way to undo some of the svn revs that have been
>> >> retrieved using git-svn fetch and then refetch them?
>>
>> > Assuming you're not using something crazy like noMetadata, you can just
>> > use update-ref on the remote heads to the last known good revisions and
>> > remove the associated .rev_db files.
>> >
>> > Otherwise you'll have to delete entries from the .rev_db files, the
>> > format is one line per-revision, the revision is the line number of the
>> > file.
>>
>> Hmm, not sure I understood. Here's what I tried:
>>
>> I'm tracking two branches via git-svn. For each, I used git log
>> remotes/<branch> to find a revision that I expect to be ok and noted
>> the sha1. Then I did:
>>
>> git-update-ref remotes/git-svn a27b11c1
>
> You may need to specify "refs/": "refs/remotes/git-svn".
> Is there a .git/remotes/git-svn ref file now?
Yes. I removed those and redid the git-update-ref specifying
refs/remotes/git-svn and the branch I have.
>> Did I miss a step or misunderstand how to undo? What's strange is
>> that if I do git show 0f12c8c, I see a patch that is looks like it came
>> from a fetch using the my broken version of git-svn -- do I need to
>> clear out objects before refetching?
>
> I might have left some steps (I've been all over the place lately :/).
> You probably need to do all that and also need to edit
> .git/svn/.metadata and set the {branches,tags}-maxRev fields to the last
> known good revisions if you use globs.
I ran git-gc --prune. I also took a look at .git/svn/.metadata, but
all I have there is:
; This file is used internally by git-svn
; You should not have to edit it
[svn-remote "svn"]
uuid = 00db46b3-68df-0310-9c12-caf00c1e9a41
So I left that alone. I tried refetching and end up with the
following error after the rev dbs were rebuilt:
error: invalid object 67e31e0ada47e8e9d15547ff1a48298869b3907b
fatal: git-write-tree: error building trees
write-tree: command returned error: 128
I found a backup of this repository and will use that. Since I have a
backup, it isn't worth the effort. I think the obvious lesson is to
use a copy of a repos when testing git-svn so you can throw it away if
things go awry.
+ seth
^ permalink raw reply
* Re: [PATCH 4/8] git-repack --max-pack-size: add fixup_header_footer()
From: Nicolas Pitre @ 2007-05-01 17:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Dana How, Junio C Hamano, Git Mailing List
In-Reply-To: <20070501060340.GD5942@spearce.org>
On Tue, 1 May 2007, Shawn O. Pearce wrote:
> Dana How <danahow@gmail.com> wrote:
> > On 4/30/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> > >Why not
> > >refactor both to use the same implementation and stuff it away in
> > >say pack-check.c (for lack of a better place), or start a new file
> > >(pack-write.c)?
> > Actually I didn't just copy it, I tried to rewrite it for my use
> > as well as the fast-import.c use (note there is a 3rd copy
> > in some *index*.c file which I didn't try to merge in yet).
> > However I didn't yet put it in a new file or change fast-import.c
> > to call it since I wanted to change as little as possible.
> ...
> > I agree with all your arguments. I had several reasons
> > to avoid extra rearrangements/refactorings:
> > (a) First patch to git, not previously known to me;
> > (b) I prefer to separate new functionality from "clean-up" work;
>
> A really good reason. ;-)
>
> But I'd still rather see it done right the first time, then done
> partially (copied) and wait for someone to clean it up later.
> Sometimes that cleanup doesn't happen.
Well I intended to do more cleanups in the pack code eventually. That
included the index writing and pack header fixing. But I was expecting
for the pack splitting changes to go in first as it is likely to impose
some requirements of its own. It is then easier to have a proper
interface common to all users after everything is in place.
> > (d) Apparently you and Nicolas Pitre have a lot of pending changes
> > affecting the packing code.
>
> Yes, but Nico's work has also destroyed in pack v4 topic. Nico has
> promised to start working on porting some of that work over, but I
> don't know if he has been able to start doing so yet.
It shouldn't be too hard to port the existing code. Most of it is new
code that hooks into the existing code in a limited way.
> I personally have been too busy this past month and a half to really
> work on packv4, but I'm hoping to circle back to it before the end of
> May (if Nico doesn't beat me to it!).
While the current pack v4 branch is certainly valuable, I consider it
more as a proof of concept and a test bench. In practice it isn't
really efficient and it won't be able to show its full potential until
core code like tree walking is better abstracted seamless processing of
parallel tree representations.
But we're getting there slowly. My work on index v2 will make the pack
v4 changes much smaller in that area. My progress display rework was a
direct "huh!" reaction to the extra progress reporting the current pack
v4 code added. And the general pack-objects.c refactoring was made with
a look on better and easier pack v4 integration in the future.
So in my mind pack v4 already started to make its way in the main code
in subtle ways. ;-) But since I may do Git work only when I'm bored
progress doesn't happen as fast as one would have expected.
> > I'd have no problem submitting a follow-on patch later containing
> > some clean-up work if you & NP clear it, so I know I won't have
> > problems from (d). Note I had to completely rewrite this patch
> > when NP submitted some of his pending stuff.
>
> Yea, hazard of working in this part of the code when Nico is
> also active. My own sliding mmap stuff was written twice too,
> for the same reason - Nico doing much needed improvements right in
> the same spot as I was working, at the same time.
Well well. OK I'm used to be considered as the bad guy anyway. ;-)
Nicolas
^ permalink raw reply
* Re: [PATCH 0/8] git-repack --max-pack-size
From: Johannes Schindelin @ 2007-05-01 17:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Andy Parkins, git
In-Reply-To: <7vps5k5uzt.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 1 May 2007, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > On Tue, 1 May 2007, Junio C Hamano wrote:
> >
> >> I was not sure if that is even a good idea, and I am now
> >> inclined to think that keeping the failed attempt history is
> >> probably better than potentially causing confusion to people who
> >> follow 'next'. But it _is_ a possibility to reset 'next' to
> >> 'master'.
> >
> > And what is the advantage of doing that, exactly?
>
> Not much and that is why I am not sure if that is a good idea,
> but one thing is:
>
> $ git log master..next
> $ git log --no-merges master..next
>
> would start showing what are still pending in next without
> noise.
Of course, you could graft a fake relationship there. Something like
echo $(git rev-parse master master^ next) >> .git/info/grafts
should do. And you can do it _locally_, since all you care about is the
higher-level relationship that _you_ know about. And this is the way to
teach Git about it.
Ciao,
Dscho
^ permalink raw reply
* Re: git-svn and local only topic branch
From: Guilhem Bonnefille @ 2007-05-01 17:30 UTC (permalink / raw)
To: Adam Roben; +Cc: git
In-Reply-To: <0E0C5313-0DCA-4DE5-96C5-9AD74758B68A@apple.com>
On 5/1/07, Adam Roben <aroben@apple.com> wrote:
> On May 1, 2007, at 9:40 AM, Guilhem Bonnefille wrote:
> > I'm using Git as a SVN frontend (via git-svn). Recently, I made a
> > topic branch, I did some job on it and wish to "upload" my work (on
> > the SVN). But, I do not want "pushing" all commits, I only want to
> > create a single commit on the SVN, while keeping full commits on my
> > Git repo. But I did not find how to do this.
>
> If you just want to make a commit to Subversion containing all the
> changes on your branch, then you should be able to do this:
>
> git svn commit-diff upstream topic
>
> That will take the entire diff between upstream and your topic
> branch and make one commit to Subversion containing that diff.
Yes, I want to make a single commit on Subversion containing all the
changes of my topic branch. But I also want to keep track of this
"merge" in my local Git repo. So I want that the new commit on my
upstream branch store an ancestry with both upstream and topic
branches.
I fear that "commit-diff" will only produce a commit on SVN, that will
be stored as a single and normal commit on my (local) upstream branch.
--
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/
^ permalink raw reply
* Re: [PATCH 0/8] git-repack --max-pack-size
From: Nicolas Pitre @ 2007-05-01 17:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7vps5k5uzt.fsf@assigned-by-dhcp.cox.net>
On Tue, 1 May 2007, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > On Tue, 1 May 2007, Junio C Hamano wrote:
> >
> >> I was not sure if that is even a good idea, and I am now
> >> inclined to think that keeping the failed attempt history is
> >> probably better than potentially causing confusion to people who
> >> follow 'next'. But it _is_ a possibility to reset 'next' to
> >> 'master'.
> >
> > And what is the advantage of doing that, exactly?
>
> Not much and that is why I am not sure if that is a good idea,
> but one thing is:
>
> $ git log master..next
> $ git log --no-merges master..next
>
> would start showing what are still pending in next without
> noise.
If you do so, then please tag the branch before resetting it. I think
it contains valuable data that would get lost otherwise.
Nicolas
^ permalink raw reply
* Re: [PATCH 0/8] git-repack --max-pack-size
From: Junio C Hamano @ 2007-05-01 17:11 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Andy Parkins, git
In-Reply-To: <alpine.LFD.0.98.0705011044210.6574@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Tue, 1 May 2007, Junio C Hamano wrote:
>
>> I was not sure if that is even a good idea, and I am now
>> inclined to think that keeping the failed attempt history is
>> probably better than potentially causing confusion to people who
>> follow 'next'. But it _is_ a possibility to reset 'next' to
>> 'master'.
>
> And what is the advantage of doing that, exactly?
Not much and that is why I am not sure if that is a good idea,
but one thing is:
$ git log master..next
$ git log --no-merges master..next
would start showing what are still pending in next without
noise.
With the current 'next', the output of the former is almost
useless, and the latter is useful only until 'next' starts
diverging again from the master and if you are interested in
what will never merged to 'master'. Once 'next' starts growing
again, you will get mixture of what's cooking and what's killed;
the output from the latter would become useless again.
^ permalink raw reply
* Re: git-svn and local only topic branch
From: Adam Roben @ 2007-05-01 16:45 UTC (permalink / raw)
To: Guilhem Bonnefille; +Cc: git
In-Reply-To: <8b65902a0705010940pb3bfb16u624d470068351624@mail.gmail.com>
On May 1, 2007, at 9:40 AM, Guilhem Bonnefille wrote:
> Hi,
>
> I'm using Git as a SVN frontend (via git-svn). Recently, I made a
> topic branch, I did some job on it and wish to "upload" my work (on
> the SVN). But, I do not want "pushing" all commits, I only want to
> create a single commit on the SVN, while keeping full commits on my
> Git repo. But I did not find how to do this.
If you just want to make a commit to Subversion containing all the
changes on your branch, then you should be able to do this:
git svn commit-diff upstream topic
That will take the entire diff between upstream and your topic
branch and make one commit to Subversion containing that diff.
-Adam
^ permalink raw reply
* git-svn and local only topic branch
From: Guilhem Bonnefille @ 2007-05-01 16:40 UTC (permalink / raw)
To: git
Hi,
I'm using Git as a SVN frontend (via git-svn). Recently, I made a
topic branch, I did some job on it and wish to "upload" my work (on
the SVN). But, I do not want "pushing" all commits, I only want to
create a single commit on the SVN, while keeping full commits on my
Git repo. But I did not find how to do this.
Here my story.
Let's call "upstream" the local branch connected to the SVN, the raw
SVN mirror branch is remotes/upstream. Now, I create a branch "topic"
from "upstream" and I do job:
o--o--o (upstream, remotes/upstream)
\
o--o--o--o (topic)
I want the following result:
o--o--o-------------- o (upstream, remotes/upstream)
\ /
o--o--o--o (topic)
So I did "git-merge "Merge" upstream topic". But, the merge action
decided to do a fast-forward. It's not correct because I really don't
want to "pollute" the SVN with all my commits.
So I rewinded and I did "git-merge --squash "Merge" upstream topic".
This time, it seems to work as I obtained a single commit on upstream
branch. But this commit does not have ancestry link with the topic
branch. Here is it:
o--o--o--o (upstream, remotes/upstream)
\
o--o--o--o (topic)
Is there a way to do what I want?
--
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/
^ permalink raw reply
* Re: "Producting Open Source Software" book and distributed SCMs
From: Linus Torvalds @ 2007-05-01 16:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200704300120.42576.jnareb@gmail.com>
On Mon, 30 Apr 2007, Jakub Narebski wrote:
>
> Among others, author advocates using version control system as a basis
> for running a project. In "Choosing a Version Contol System" he writes:
>
> As of this writing, the version control system of choice in the free
> software world is the Concurrent Versions System or CVS.
Well, I actually personally suspect that the original Linux method of
"patches + tar-balls" is a perfectly valid method of source control
management, and in many ways preferable over CVS.
So no, I don't think using a version control system should be the _basis_
of running a project. Version control comes pretty far down the list, long
long after "good taste" and "willingness to do things rather than talk
about them", the latter of which tends to kill more hypothetical projects
than even CVS has ever done.
The _basis_ of an open source project is a good manager, a good idea, and
a realization that what matters most is _using_ the end result, rather
than the idea or discussions or "cool features".
The SCM becomes relevant only once you are far enough along that tar-balls
and patches really don't work, and that might well take years.
[ I'm really serious: I think a lot of the good practices that the kernel
project has gotten is exactly because of the "patches rule" mentality.
We now use real revision control, but I really *really* believe that
pushing patches around is a much better way of managing stuff than with
CVS or any other centralized model, because in the centralized model it
always ends up being about the "core team". In contrast, even if there
is a core team, if they just push patches around and discuss them as
such, non-core-team members are automatically basically all equal.
And avoiding the politics, and avoiding the "five people are special"
mentality is a *lot* more important than the limited and broken tracking
capabilities that CVS brings to the table.
So maybe I'm just in denial, but I really believe that the fact that the
kernel was basically maintained _without_ an SCM for a decade was
actually a *good* thing, considering the alternatives. ]
> Further on much of examples of managing project and managing volunteers
> revolves around the idea of "commit access", and it is assumed
> implicitely that version control system is centralized.
Karl Fogel is wrong.
It's an understandable mistake to do, since commit access is so important
in a centralized environment, and he probably has never used anything else
(even decentralized SCM's are often _used_ as centralized ones), but he's
still *wrong*. Fundamentally so:
> The distributed SCM is mentioned in footnote in section "Comitters" in
> Chapter 8, Managing Volunteers:
>
> http://producingoss.com/producingoss.html#ftn.id284130
>
> [22] Note that the commit access means something a bit different in
> decentralized version control systems, where anyone can set up a
> repository that is linked into the project, and give themselves commit
> access to that repository. Nevertheless, the concept of commit access
> still applies: "commit access" is shorthand for "the right to make
> changes to the code that will ship in the group's next release of the
> software." In centralized version control systems, this means having
> direct commit access; in decentralized ones, it means having one's
> changes pulled into the main distribution by default. It is the same
> idea either way; the mechanics by which it is realized are not
> terribly important.
That's just making excuses. Yes, you can use the same words, and say that
you call the two TOTALLY DIFFERENT things "commit access", and then,
because you've made two totally different things use the same term, you
claim that it's the same thing, and the differences aren't "terribly
important".
It's like saying that a distributed (or threaded, for that matter)
algorithm and a linear algorithm both result in the same result, so the
"mechanics" of the algorithm are not terribly relevant: they're both
algorithms.
Anybody who has ever done any distributed algorithms realizes that the
mechanichs are *hugely* important. The difference between a distributed
situation and a centralized one is absolutely humongous. It changes
literally everything.
Does the fact that you *can* run a distributed algorithm on one machine
make it the same? No. Does the fact that the end result is called the same
make the two the same? No. It's a totally different model, and they share
almost none of the issues.
When it comes to "commit access", not only is the term nonsensical in a
distributed environment, even if you want to use that term to describe the
notion of "gets pulled into the next release", it's not even TRUE.
People like Andrew, Ingo, and Davem have what Karl would probably call
"commit access". Andrew and Ingo have it even though they don't actually
even use git to synchronize with me. But no, they don't actually get
pulled into the next release by default _anyway_ - there's always a
conscious choice after the fact, rather than any implicit permission.
I quite often tell maintainers that I won't pull their stuff, simply
because the changes look too scary, and I'm too close to a release. Yes,
it happens less often than me just silently pulling it, but that's not a
sign of "commit access", that's a sign of the fact that the process
_works_ in the first place. If we spent all our time arguing about it, and
people didn't just "know" how to behave, we'd never get anything done.
So that "get pulled by default" has _nothing_ to do with commit access,
and everything to do with much higher-level process issues. And it's
something that distributed development makes _possible_ in a way that the
centralized model with "commit access" simply does not.
Miles and miles apart. And a very important distinction.
(Btw, I'll argue that it's really important inside companies too, even
when the source control in question is "controlled". When you do things
like validation, you shouldn't just allow "commit access" to the tree to
be validated. The validation group should maintain a tree that *they*
control, and getting things accepted into their tree should be just one
step on a "release schedule")
> Linus has said that fully distributed SCM improves forkability:
Yes. There's two issues to forkability:
- all real development happens as "micro-forks", and so you should make
that easy, whether it's an "inside" developer or somebody else who just
has a wild and crazy idea that might just work.
- all real _honesty_ comes from a belief that the code *can* be forked,
and that even the original developer and/or top maintainer cannot force
his world-view on anybody.
Both of these are important, but the latter is important not because it
should be the "normal case", but just because the _knowledge_ that a fork
can happen should keep people honest.
Big forks due to fundmanetal personality clashes (they are sometimes
about technology, but even when they are ostensibly about technology
issues, they are often very much about strong personal ideas about that
technology) are painful. But they should be painful not because of the SCM
in question, but simply because handling personality issues is inherently
painful.
The SCM shouldn't allow people to be a*-holes and control freaks.
And I think Karl Fogel agrees with me on that. When he says
.. the more serious the threat of a fork becomes, the more willing
people are to compromise to avoid it.
he's right on the money, and I _think_ he meant it in the good way
(compromise and trying to work with people is absolutely a _must_).
> Besides that, what are the differences between managing project using
> centralized SCM and one using distributed SCM? What is equivalent of
> committers, giving full and partial commit access, revoking commit
> access?
So here's what happens for the kernel:
- we simply don't *have* commit access
- there's no "partial", and there's not "revoking"
- there are people I trust, but I don't trust them implicitly in the
sense that I give them the keys to my repository. If they go crazy,
there's nothing to revoke. NOTHING. If they go crazy, I just don't pull
from them. It's really rhat easy!
- there are people I trust in certain areas, but that doesn't mean that
they can't make changes everywhere. It just means that I won't pull
unless I see that the changes are only to those areas.
And again, it's not an "up-front" decision: when people ask me to pull,
they tell me (by way of a diffstat) what they changed, and I can - and
actually do this, although mostly because it avoids mistakes - verify
it, because the pull always tells me what got changed.
- In fact, what happens occasionally is that I pull something, and tell
people "nope, that won't do" and just discard their changes. It doesn't
happen every day, but it happened yesterday - David Miller (who is one
of the top developers) sent me a fix, I fetched it and told him it was
incomplete and I wouldn't pull until it was fixed.
Notice? No partial commit access, no revoking, no granting. No politics.
No up-front "you have rights". Just a very basic issue: trust.
And the nice thing about this is that if some subsystem needs to make
trivial changes to another subsystem, they don't need to ask for
permission. They just do them, AND THEN THEY EXPLAIN THEM! And if they
really were trivial and obvious (and that's almost always the case), they
just get pulled normally. No special dispensation.
This is somethign that a centralized repository with commit access
fundamentally *cannot* do! If a maintainer who has partial commit access
needs to fix something else in order to make his subtree work, he's
basically screwed. He cannot commit his changes to *his* area, just
because they depend on a fix to another persons area, and he cannot commit
that.
Centralized SCM's are *fundamentally* broken. And the whole "commit
access" is very much part of that breakage. A distributed system doesn't
have it, doesn't need it, and is much much better off without it!
This is why I said Karl was totally off when he said that there's an
equivalent to "commit access" in a distributed system too. It's just not
true. Everything that people use "commit access" for just entirely goes
away!
> How good support for tagging and branching influences creating
> code and build procedure? Is distributed SCM better geared towards
> "benovolent dictator" model than "consensus-based democracy" model, as
> described in OSSbook?
I think branching is so fundamnetal to being distributed, that asking
whether good support for something like that is important for build
procedure is just not a valid question. It's like asking "How important is
water to your social life?" It's supremely important in the sense that
without water, you wouldn't have a social life, but that's because you
wouldn't _exist_ in the first place. But does that make water _directly_
important to your social life? Probably not, unless your life revolves
around playing water polo with your buddies.
Same goes for the benevolent dictator vs consensus-based model. I think
the distributed setup has advantages for both, and the advantages are much
more fundamental than anything direct. You can use distributed for either
model, and in both cases, the tools a distributed system gives you are
just different (and much better).
Linus
^ permalink raw reply
* Re: [RFC] Optimize diff-delta.c
From: Nicolas Pitre @ 2007-05-01 16:05 UTC (permalink / raw)
To: Martin Koegler; +Cc: git
In-Reply-To: <1178030967273-git-send-email-mkoegler@auto.tuwien.ac.at>
On Tue, 1 May 2007, Martin Koegler wrote:
> As the delta format only supports 32 bit offsets, the uncompressed
> blob size is limited to 4GB.
Right. I think it would be a good idea to extend the delta format as
well to allow for larger offsets in pack v4.
> The delta index has approximately the same size in memory as the
> uncompressed blob ((blob size)/16*(sizeof(index_entry)).
One thing that could be done with really large blobs is to create a
sparser index, i.e. have a larger step than 16. Because the delta match
loop scans backward after a match the sparse index shouldn't affect
compression that much on large blobs and the index could be
significantly smaller.
> I tried to speed up the delta generation by searching for a common
> prefix, as my blobs are mostly append only. I tested it with about
> less than 1000 big blobs. The time for finding the deltas decreased
> from 17 to 14 minutes cpu time.
I'm surprised that your patch makes so much of a difference. Normally
the first window should always match in the case you're trying to
optimize and the current code should already perform more or less the
same as your common prefix match does.
Ah, no, actually what your patch does is a pessimisation of the matching
code by not considering other and possibly better matches elsewhere in
the reference buffer whenever there is a match at the beginning of both
buffers. I don't think this is a good idea in general.
What you should try instead if you want to make the process faster is to
lower the treshold used to consider a match sufficiently large to stop
searching. That has the potential for even faster processing as the
"optimization" would then be effective throughout the buffer and not
only at the beginning.
Currently the treshold is implicit and equal to 65536. Please consider
this patch instead of yours for testing:
diff --git a/diff-delta.c b/diff-delta.c
index 9f998d0..755c0a9 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -315,6 +315,9 @@ create_delta(const struct delta_index *index,
/* this is our best match so far */
msize = ref - entry->ptr;
moff = entry->ptr - ref_data;
+ /* a sufficiently large match is good enough */
+ if (msize >= 4096)
+ break;
}
}
You could experiment with that value to determine the best speed vs size
compromize.
Nicolas
^ permalink raw reply related
* Re: git cvsimport fails
From: Thomas Hühn @ 2007-05-01 15:54 UTC (permalink / raw)
To: git
In-Reply-To: <87ejm0mtpy.fsf@mid.thomas-huehn.de>
Thomas Hühn <newsgroups@thomas-huehn.de> writes:
> I'm trying to import from a CVS repository and get this error message at
> the end:
>
> |Commit ID 076fd7d71925bb551320aa20aa8eec68bf218f45
> |DONE.
> |fatal: Needed a single revision
> |Can merge only exactly one commit into empty head
> |Could not merge origin into the current branch.
>
> Is my git repo broken, is the CVS repo broken, is it just a shortcoming
> of cvsimport? Any idea whether it is fixable?
Okay, should have looked further for suitable git commands. git-fsck
tells me that HEAD is not a symbolic ref.
HEAD contains "ref: refs/heads/master", but refs/heads contains no
"master", just other files.
Can I find out, which hash master should point at?
Thomas
^ permalink raw reply
* Re: [RFC] Optimize diff-delta.c
From: Johannes Schindelin @ 2007-05-01 15:51 UTC (permalink / raw)
To: Martin Koegler; +Cc: git, Nicolas Pitre
In-Reply-To: <1178030967273-git-send-email-mkoegler@auto.tuwien.ac.at>
Hi,
On Tue, 1 May 2007, Martin Koegler wrote:
> I tried to speed up the delta generation by searching for a common
> prefix, as my blobs are mostly append only. I tested it with about less
> than 1000 big blobs. The time for finding the deltas decreased from 17
> to 14 minutes cpu time.
The interesting timings, of course, would be of big blobs which are _not_
append-only, as they are more common, at least for me.
Since git.git contained next to no binary blobs, this is not a good test
case.
Ciao,
Dscho
^ 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