* Re: VCS comparison table
From: Sean @ 2006-10-17 10:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: bazaar-ng, git
In-Reply-To: <Pine.LNX.4.63.0610171229160.14200@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 17 Oct 2006 12:30:27 +0200 (CEST)
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> It would also make things slow as hell. How do you deal with something
> like annotate in such a setup?
Some commands like annotate might not make any sense in such a set up.
But one way to get the same (perhaps even better) feature into git
would be to support shallow clones, in which case even annotate would
continue to work even if somewhat crippled by the lack of a complete
history.
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-17 10:23 UTC (permalink / raw)
To: Aaron Bentley; +Cc: bazaar-ng, git, Johannes Schindelin, Jakub Narebski
In-Reply-To: <4534656B.7080105@utoronto.ca>
On Tue, 17 Oct 2006 01:08:59 -0400
Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
> I can use the 'bzr missing' command to check whether my branch is in
> sync with a remote branch. Or I can use the 'pull' command to update my
> branch to a given revno in a remote branch.
The "bzr missing" command sounds like a handy one.
Someone on the xorg mailing list was recently lamenting that git does not
have an easy way to compare a local branch to a remote one. While this
turns out to not be a big problem in git, it might be nice to have such
a command.
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-17 10:23 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Linus Torvalds, bazaar-ng, git, Jakub Narebski
In-Reply-To: <45345AEF.6070107@utoronto.ca>
On Tue, 17 Oct 2006 00:24:15 -0400
Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
> The key thing about a checkout is that it's stored in a different
> location from its repository. This provides a few benefits:
>
> - - you can publish a repository without publishing its working tree,
> possibly using standard mirroring tools like rsync.
Yeah, even in git you typically don't publish your working tree when
making it available for cloning. In fact the native git network
protocol doesn't even have a way to transfer working trees.
> - - you can have working trees on local systems while having the
> repository on a remote system. This makes it easy to work on one
> logical branch from multiple locations, without getting out of sync.
That is a very nice feature. Git would be improved if it could
support that mode of operation as well.
> - - you can use a checkout to maintain a local mirror of a read-only
> branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).
I'm not sure what you mean here. A bzr checkout doesn't have any history
does it? So it's not a mirror of a branch, but just a checkout of the
branch head?
If so, Git can export a tarball of a branch (actually a snapshot as at
any given commit) which can be mirrored out.
Sean
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-17 10:01 UTC (permalink / raw)
To: Robert Collins; +Cc: bazaar-ng, git, Jakub Narebski
In-Reply-To: <1161077866.9020.69.camel@localhost.localdomain>
On Tue, 17 Oct 2006 19:37:45 +1000
Robert Collins <robertc@robertcollins.net> wrote:
> Precisely how does this rebase operate in git ?
> Does it preserve revision ids for the existing work, or do they all
> change?
>
> bzr has a graft plugin which walks one branch applying all its changes
> to another preserving the users metadata but changing the uuids for
> revisions.
git rebase does exactly the same as you describe, including changing
the sha1 for each commit it moves.
Sean
^ permalink raw reply
* Re: [PATCH] Don't use $author_name undefined when $from contains no /\s</.
From: Junio C Hamano @ 2006-10-20 7:52 UTC (permalink / raw)
To: Paul Eggert; +Cc: git
In-Reply-To: <87pscnj29t.fsf@penguin.cs.ucla.edu>
Paul Eggert <eggert@CS.UCLA.EDU> writes:
> Since git uses diff -u format, it would make sense to git to work with
> the upcoming POSIX spec for diff -u, either by adjusting the spec or
> by adjusting git.
It is not quite fair to talk as if I still have a choice.
Apparently a version of GNU diff that generates new format is
already in the wild (I've received such a patch which was where
this thread started). Whether I like your change or not, the
damage is already done and its output needs to be dealt with, so
that we do not break users.
Coding a workaround is not a big deal; the change is simple and
trivial. It's just I am somewhat unhappy, having to do a .1
release immediately after v1.4.3 which took about two months to
stabilize, although that's not your fault. Sorry for venting.
^ permalink raw reply
* Re: VCS comparison table
From: Lachlan Patrick @ 2006-10-20 7:47 UTC (permalink / raw)
To: bazaar-ng; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610192202340.3962@g5.osdl.org>
Linus Torvalds wrote:
>
> On Thu, 19 Oct 2006, Aaron Bentley wrote:
>> I understand your argument now. It's nothing to do with numbers per se,
>> and all about per-branch namespaces. Correct?
>
> I don't know if that is what Carl's problem is, but yes, to somebody from
> the git world, it's totally insane to have the _same_ commit have ten
> different names just depending on which branch is was in.
>
> In git-land, the name of a commit is the same in every branch.
I've been following the git-vs-bzr discussion, and I'd like to ask a
question (being new to both bzr and git). How does git disambiguate SHA1
hash collisions? I think git has an alternative way to name revisions
(can someone please explain it in more detail, I've seen <ref>~<n>
mentioned only in passing in this thread). It seems to me collisions are
a good argument in favour of having two independent naming schemes, so
that you're not solely relying on hashes being unique.
A strong argument is that a global namespace based on hashes of data is
ideal because the names are generated from the data being named, and
therefore are immutable. Same data => same name for that data, always
and forever, which is desirable when merging named data from many
sources. But the converse isn't true: one name does not necessarily map
to only that data. Have I misunderstood? Is this a problem?
Ta,
Loki
^ permalink raw reply
* hooks--pre-commit: chomp() in cygwin perl does not strip "\r"
From: Liu Yubao @ 2006-10-20 6:14 UTC (permalink / raw)
To: git
perl v5.8.7 built for cygwin-thread-multi-64int, its chomp() doesn't strip
trailing "\r" so that pre-commit reports "trailing whitespace" for every line.
ActiveState Perl v5.8.8 can strip "\r" and "\n" properly.
Changing
if (/\s$/) {
to
if (/[:blank:]$/) {
is also ok.
diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit
index 723a9ef..6a55612
--- a/templates/hooks--pre-commit
+++ b/templates/hooks--pre-commit
@@ -54,7 +54,7 @@ perl -e '
}
if (s/^\+//) {
$lineno++;
- chomp;
+ s/[\r\n]+$//;
if (/\s$/) {
bad_line("trailing whitespace", $_);
}
^ permalink raw reply related
* Re: Alternate revno proposal (Was: Re: VCS comparison table)
From: Jan Hudec @ 2006-10-20 5:38 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: Robert Collins, Petr Baudis, bazaar-ng, git
In-Reply-To: <200610200209.k9K29ncC006935@laptop13.inf.utfsm.cl>
On Thu, Oct 19, 2006 at 11:09:49PM -0300, Horst H. von Brand wrote:
> Jan Hudec <bulb@ucw.cz> wrote:
>
> [...]
>
> > Reading this thread I came to think, that the revnos should be assigned
> > to _all_ revisions _available_, in order of when they entered the
> > repository (there are some possible variations I will mention below)
> >
> > - Such revnos would be purely local, but:
> > - Current revnos are not guaranteed to be the same in different
> > branches either.
> > - They could be done so that mirror has the same revnos as the
> > master.
>
> Then they are almost useless (except for people working alone). You need to
> be able to talk about a particular commit with others working independently.
As they currently are you can't either. Because currently it is
guaranteed that the revnos will be the same in two branches with the
same current revision. But when the current revisions differ, the
numbers may as well.
Moreover currently they can change for the same branch over time, while
with the alternate proposal they would not, so you could reliably say
revision 567 on foo.
> > - They would be easier to use than the dotted ones. What (at least as
> > far as I understand) makes revnos easier to use than revids is, that
> > you can remember few of them for short time while composing some
> > operation. Ie. look up 2 or 3 revisions in the log and than do some
> > command on them. And a 4 to 5-digit number like 10532 is easier to
> > remember than something like 3250.2.45.86.
>
> Probably. In git you can (mostly) get away with partial SHA-1's, BTW.
1) Partial sha-1 is still longer (starts being useful at 6 digits,
usually you need 8)
2) Decimal numbers are easier to remember than hexadecimal ones.
3) The hashes are not oredered.
> > - Their ordering would be an (arbitrary) superset of the partial
> > ordering by descendance, ie. if revision A is ancestor of B, it would
> > always have lower revno.
> > - The intuition that lower revno means older revision would be always
> > valid for related revisions and approximately valid for unrelated
> > ones.
> > - They would be *localy stable*. That is once assigned the revno would
> > always mean the same revision in given branch (as determined by
> > location, not tip).
>
> Tip-relative is extremely useful: I wouldn't normally remember the current
> revision, but I'll probably often be talking about "the change before this
> one" and so on.
That's however separate issue. Negative numbers are tip-relative and
there are various prefixes in bzr (like before:, ancestor: etc.) for
relative revision addressing.
> > - This is more than the current scheme can give, since now pull can
> > renumber revisions.
>
> Urgh. Get an update, and all your bearings change?
Currently yes. Currently pull changes the branch to be a mirror of the
pulled-from branch, including the way they are numbered.
> > - They wouldn't make any branch special, so the objections Linus raised
> > does not apply.
>
> But the original branch /is/ special?
Some branches are usually special, but which they are may not
necessarily coincide with the left-parent lineage.
> > - They would be the same as subversion and svk, and IIRC mercurial as
> > well, use, so:
> > - They would already be familiar to users comming from those systems.
> > - They are known to be useful that way. In fact for svk it's the only
> > way to refer to revisions and seem to work satisfactorily (though
> > note that svk is not really suitable to ad-hoc topologies).
>
> SVN is /centralized/, there it does make sense talking about (the one and
> only) history. In a distributed system, potentially each has a different
Did you notice that I also said svk and mercurial? They both *ARE*
distributed (well, svk has it's limitations, but mercurial really very
similar to git).
> history, and they are intertwined.
>
> Not at all useful.
There are no global persistent revision numbers in a distributed system.
There can't be. But numbers with limited scope can still be really
useful. The question is what that scope should be.
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@ucw.cz>
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-20 5:05 UTC (permalink / raw)
To: Aaron Bentley
Cc: Andreas Ericsson, Carl Worth, bazaar-ng, git, Jakub Narebski
In-Reply-To: <45382120.9060702@utoronto.ca>
On Thu, 19 Oct 2006, Aaron Bentley wrote:
>
> I understand your argument now. It's nothing to do with numbers per se,
> and all about per-branch namespaces. Correct?
I don't know if that is what Carl's problem is, but yes, to somebody from
the git world, it's totally insane to have the _same_ commit have ten
different names just depending on which branch is was in.
In git-land, the name of a commit is the same in every branch.
Do you have something like
gitk --all
in your graphical viewers? That one shows _all_ the branches of a
repository, and how they relate to each other in git. How do you name your
commits in such a viewer, since every branch has a _different_ name for
the same commit?
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-20 4:05 UTC (permalink / raw)
To: Tim Webster
Cc: Christian MICHON, Andreas Ericsson, bazaar-ng, git, Matthieu Moy
In-Reply-To: <72877ab10610192014o3a7f66c6v79f94f48615e08f4@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tim Webster wrote:
> On 10/19/06, Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
>> I believe SVN supports recording arbitrary file properties, so it's just
>> a matter of applying those properties to the tree.
>
> yes svn has arbitrary properties which can be manipulated.
> They are not really intended for permissions, ownership, and acl.
> To use the svn properties for this requires adding scm tools.
Agreed. I think it's okay to require extra work to set the scm up to
handle configurations.
> Also svn does not allow files in the same directory to live in
> multiple repos
It would surprise me if many SCMs that support atomic commit also
support intermixing files from multiple repos in the same directory.
>> You mean multiple merge sources?
>
> yes, Multiple merge sources is handy for collaborative document editing
That's something I'd like for software development, too.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFOEsO0F+nu1YWqI0RAo+6AJ9lzF0+O1I8rgkyCOdhsir1gjo0NQCfXEVV
EIsDmS+eR/7cHKQfmnPJRA4=
=g5jk
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: VCS comparison table
From: Tim Webster @ 2006-10-20 3:40 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Christian MICHON, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <vpq7iyw2sg9.fsf@ecrins.imag.fr>
On 10/20/06, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> "Tim Webster" <tdwebste@gmail.com> writes:
>
> > First I want to say every SCM I know of sucks when it comes to tracking
> > configurations, simply because they don't record or restore file metadata,
> > like perms, ownership, and acl.
>
> That's not a simple matter.
>
> Tracking ownership hardly makes sense as soon as you have two
> developers on the same project. What does it mean to checkout a file
> belonging to user foo and group bar on a system not having such user
> and group?
.
> That said, it can be interesting to have it, but disabled by default.
Yes I agree it should be disabled by default. And enabled based on the
local settings.
^ permalink raw reply
* Re: [PATCH 2/2] Remove unused index tracking code.
From: Nicolas Pitre @ 2006-10-20 3:36 UTC (permalink / raw)
To: Jan Harkes; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <20061020022723.GE7162@delft.aura.cs.cmu.edu>
On Thu, 19 Oct 2006, Jan Harkes wrote:
> If we see a complete object it will remain complete. If we find a delta,
> and we have the base in the current repository it will be expanded to a
> complete object.
> When we get a delta that doesn't have a base in the
> current repository it will remain unresolved and is written out as a
> delta.
But the point of the whole exercice is actually to avoid unresolved
deltas. And you know if you have unresolved deltas only when the whole
pack has been processed.
If the base object is not in the repository but it is in the pack
_after_ the delta that needs it, you won't have resolved it. If this is
a thin pack with missing base objects for whatever reason you're
screwed.
If the delta has its base object in both the repository _and_ in the
pack but after the delta then you will have expanded the delta
needlessly.
So your solution is suboptimal.
The optimal solution really consists of appending missing base objects
to a thin pack in order to make it complete, or error out if those
cannot be found.
Nicolas
^ permalink raw reply
* Re: VCS comparison table
From: Tim Webster @ 2006-10-20 3:14 UTC (permalink / raw)
To: Aaron Bentley
Cc: Matthieu Moy, Christian MICHON, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <45379A02.1010105@utoronto.ca>
On 10/19/06, Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tim Webster wrote:
> > First I want to say every SCM I know of sucks when it comes to tracking
> > configurations, simply because they don't record or restore file metadata,
> > like perms, ownership, and acl.
>
> Arch supports that kind of metadata.
>
> I believe SVN supports recording arbitrary file properties, so it's just
> a matter of applying those properties to the tree.
yes svn has arbitrary properties which can be manipulated.
They are not really intended for permissions, ownership, and acl.
To use the svn properties for this requires adding scm tools.
Also svn does not allow files in the same directory to live in
multiple repos
>
> > Somethings I like the SCM tools to handle. Personally I would like the
> > Collaborative document editing and white boarding are other requirements.
> > odf and svg are xml file formats. I would like to see an efficient
> > xml diff as part of the SCM core. Using mime types SCM tools can unzip
> > files, bundles, and use mime type information to the SCM core xml
> > diff, plain diff
> > as required.
>
> An XML diff/patch or merge will not handle ODF properly. There's too
> much extra semantic information.
I have only experiment with xml diffs on odf files.
From my experience xml diffs work fine on svg files.
For more information, please refer to
http://www.unibw.de/inf2/OO_VCS/oo_rcs_api.html
> > I think it is essential that the SCM core include
> > previsions for multiple
> > repo partners.
>
> You mean multiple merge sources?
yes, Multiple merge sources is handy for collaborative document editing
^ permalink raw reply
* Re: VCS comparison table
From: James Henstridge @ 2006-10-20 2:53 UTC (permalink / raw)
To: Carl Worth
Cc: Aaron Bentley, Linus Torvalds, Andreas Ericsson, bazaar-ng, git,
Jakub Narebski
In-Reply-To: <87ods727pn.wl%cworth@cworth.org>
On 20/10/06, Carl Worth <cworth@cworth.org> wrote:
> On Thu, 19 Oct 2006 19:01:58 -0400, Aaron Bentley wrote:
> > I don't think this is true. The abandoned mainline does not need to be
> > destroyed. It can be kept at the same location that it always was, with
> > the numbers that it always had. So the number + URL combo stays
> > meaningful.
>
> Sure that's possible, but it gets rather unwieldy the more
> repositories you have involved. I've been arguing that bzr really does
> encourage centralized, not distributed development, and you were having
> trouble seeing how I came to that conclusion. Do you see how "maintain
> an independent URL namespace for every distributed branch" doesn't
> encourage much distributed development?
>
> > Additionally, the new mainline can keep a mirror of the
> > abandoned mainline in its repository, because there are virtually no
> > additional storage requirements to doing so.
>
> And this part I don't understand. I can understand the mainline
> storing the revisions, but I don't understand how it could make them
> accessible by the published revision numbers of the "abandoned"
> line. And that's the problem.
With this sort of setup, I would publish my branches in a directory
tree like this:
/repo
/branch1
/branch2
I make "/repo" a Bazaar repository so that it stores the revision data
for all branches contained in the directory (the tree contents,
revision meta data, etc).
The "/repo/branch1" essentially just contains a list of mainline
revision IDs that identify the branch. This could probably be just
store the head revision ID, but there are some optimisations that make
use of the linear history here.
If the ancestry of "/repo/branch2" is a subset of branch1 (as it might
be if the in the case of forked then merged projects), then all its
revision data will already be in the repository when branch1 was
imported. The only cost of keeping the branch around (and publishing
it) is the list of revision IDs in its mainline history.
For similar reasons, the cost of publishing 20 related Bazaar branches
on my web server is generally not 20 times the cost of publishing a
single branch.
I understand that you get similar benefits by a GIT repository with
multiple head revisions.
> > > But for these communications, revision numbers will not provide
> > > historically stable values that can be used.
> >
> > They certainly can.
> >
> > The coder says "I've put up a branch at http://example.com/bzr/feature.
> > In revision 5, I started work on feature A. I finished work in
> > revision 6. But then I had to fix a related bug in revision 7."
>
> "I've put this branch up" isn't historically stable...
With the repository structure mentioned above, the cost of publishing
multiple branches is quite low. If I continue to work on the project,
then there is no particular bandwidth or disk space reasons for me to
cut off access to my old branches.
For similar reasons, it doesn't cost me much to mirror other people's
related branches if I really care about them.
> > As long as that coder is active
>
> ...which is what you just said there yourself.
>
> On the other hand, git names really do live forever, regardless of
> where the code is hosted or how it moves around. When I'm talking
> about historical stability, I'm talking about being able to publish
> numbers that live forever.
>
> It sounds like bzr has numbers like this inside it, (but not nearly as
> simple as the ones that git has), but that users aren't in the
> practice of communicating with them. Instead, users communicate with
> the unstable numbers. And that's a shame from an historical
> perspective.
If you need that level of stability then you want the revision
identifier in both the GIT and Bazaar cases.
As for simplicity, note that Bazaar doesn't extract any special
meaning from the "$email-$date-$random" format of the revision
identifiers. The only property it cares about is that they are
globally unique. For example, revision identifiers generated by the
Arch -> Bazaar importer have a different format and are handled the
same.
> > This is true, but his code is likely to all land in the mainline at
> > once. Since his own revnos are more fine-grained, he's not likely want
> > to use the mainline revnos.
>
> What I'd like to be able to do, is advertise a temporary repository,
> and while using it, publish names for revisions that will still be
> valid when the code gets pushed out to the mainline. That is
> supporting distributed development, and everything I'm hearing says
> that the bzr revision numbers don't support that.
That is correct. The revision numbers assigned to particular
revisions in the context of one branch won't necessarily be the same
as the numbers in another branch.
> > I felt that you were mischaracterizing my _statement_ that "it's
> > exceedingly uncommon for [revnos] to change" as an _argument_ "it's
> > exceedingly uncommon for [revnos] to change". The reality is that we
> > keep saying revnos don't change because git users keep saying "but what
> > if the revnos change?".
>
> OK.
>
> The original claim that sparked the discussion was that bzr has a
> "simple namespace" while git does not. We've been talking for quite a
> while here, and I still don't fully understand how these numbers are
> generated or what I can expect to happen to the numbers associated
> with a given revision as that revision moves from one repository to
> another. It's really not a simple scheme.
I can't say anything about the dotted revision numbers that have been
recently introduced to Bazaar, but I have definitely found the simple
numeric revision numbers for mainline revisions useful when using
Bazaar. The revisions with these short revision numbers are generally
the ones I am most interested in when working on that branch.
It hasn't ever seemed a problem those revisions no longer had short
revision numbers assigned to them when someone else merged my branch.
> Meanwhile, I have been arguing that the "simple" revision numbers that
> bzr advertises have restrictions on their utility, (they can only be
> used with reference to a specific repository, or with reference to
> another that treats it as canonical). I _think_ I understand the
> numbers well enough to say that still.
Using Bazaar terminology, the revision numbers are specific to a
particular _branch_. If I copy a branch from one repository to
another, its revision numbers will stay the same. And conversely, two
branches in the same repository can have different revision numbers.
> Compare that with the git names. The scheme really is easy to
> understand, (either the new user already understands cryptographic
> hashes, or else it's as easy as "a long string of digits that git
> assigns as the name"). The names have universal utility in time and
> space, (for definitions of the the universe larger than I will ever be
> able to observe anyway). And the natural inclination to abbreviate the
> a name when repeating it, (note the recent post with bzr UUIDs
> exhibiting the same inclination), doesn't make the names any less
> useful since the abbreviation alone will work most always.
>
> The naming in git really is beautiful and beautifully simple.
I don't think anyone is saying that universally unique names are bad.
But I also don't see a problem with using shorter names that only have
meaning in a local scope.
I've noticed some people using abbreviated SHA1 sums with GIT. Isn't
that also a case of trading potential global uniqueness for
convenience when working in a local scope?
James.
^ permalink raw reply
* Re: [PATCH 2/2] Remove unused index tracking code.
From: Jan Harkes @ 2006-10-20 2:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Linus Torvalds, git
In-Reply-To: <7vd58nra64.fsf@assigned-by-dhcp.cox.net>
On Thu, Oct 19, 2006 at 07:30:27PM -0700, Junio C Hamano wrote:
> Jan Harkes <jaharkes@cs.cmu.edu> writes:
>
> > I guess I'll grep through the mailinglists to try to figure out what
> > these OFS and REF deltas are and why they behave so differently
> > depending on their order in the pack.
>
> It's been cooking in "next" branch for quite a while.
Ah yes, just went through the thread about the git-index-pack breaking on
64-bit systems and the back and forth about the possible complexity of
the new code.
> It is really simple:
>
> - if the found union content matches with a reference union initialized
> through the sha1 member then deltas[j].obj->type == OBJ_REF_DELTA
> must be true.
>
> - if the found union content matches with a reference union initialized
> through the sha1 member then deltas[j].obj->type == OBJ_OFS_DELTA
> must be true.
...
I guess one of these must be false.
But clearly this patch breaks those offset based delta's when we expand
random deltas in place.
Jan
^ permalink raw reply
* Re: [PATCH 2/2] Remove unused index tracking code.
From: Junio C Hamano @ 2006-10-20 2:30 UTC (permalink / raw)
To: Jan Harkes; +Cc: Nicolas Pitre, Linus Torvalds, git
In-Reply-To: <20061020022723.GE7162@delft.aura.cs.cmu.edu>
Jan Harkes <jaharkes@cs.cmu.edu> writes:
> I guess I'll grep through the mailinglists to try to figure out what
> these OFS and REF deltas are and why they behave so differently
> depending on their order in the pack.
It's been cooking in "next" branch for quite a while.
^ permalink raw reply
* Re: [PATCH 2/2] Remove unused index tracking code.
From: Jan Harkes @ 2006-10-20 2:27 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610192058130.1971@xanadu.home>
On Thu, Oct 19, 2006 at 09:11:10PM -0400, Nicolas Pitre wrote:
> This patch impose an ordering on REF_DELTA objects that doesn't need to
> exist. Say for example that an OFS_DELTA depends on an object which is
> a REF_DELTA object. With this patch any pack with the base for that
> REF_DELTA stored after the OFS_DELTA object will be broken.
I don't see where it imposes any ordering.
If we see a complete object it will remain complete. If we find a delta,
and we have the base in the current repository it will be expanded to a
complete object. When we get a delta that doesn't have a base in the
current repository it will remain unresolved and is written out as a
delta.
So the output pack will always contain fewer deltas as the input.
btw. I don't really know what OFS_DELTA and REF_DELTA objects are, I
grepped the source and found no references to either. I can only find
an OBJ_DELTA.
But if any of the deltas depend on an object that is not in the thin
pack, the base has to be available in the current repository and as such
it will be expanded to a full object, replacing the possibly external
delta reference with an internal base object. If the base is not found
in the current repository the base has to be another object in the
original thin pack so we can write out the delta as is.
There is no before or after decision here. We don't look back in the
thin pack, and we don't have to look forward either. So I don't
understand why your example would break or not depending on if the base
object happens to be before or after the OFS_DELTA.
> And to really do thin pack fixing properly we really want to just append
> missing base objects at the end of the pack which falls in the broken
> case above.
I guess I'll grep through the mailinglists to try to figure out what
these OFS and REF deltas are and why they behave so differently
depending on their order in the pack.
Jan
^ permalink raw reply
* Re: Alternate revno proposal (Was: Re: VCS comparison table)
From: Horst H. von Brand @ 2006-10-20 2:09 UTC (permalink / raw)
To: Jan Hudec; +Cc: Robert Collins, Petr Baudis, bazaar-ng, git
In-Reply-To: <20061018214623.GA32725@artax.karlin.mff.cuni.cz>
Jan Hudec <bulb@ucw.cz> wrote:
[...]
> Reading this thread I came to think, that the revnos should be assigned
> to _all_ revisions _available_, in order of when they entered the
> repository (there are some possible variations I will mention below)
>
> - Such revnos would be purely local, but:
> - Current revnos are not guaranteed to be the same in different
> branches either.
> - They could be done so that mirror has the same revnos as the
> master.
Then they are almost useless (except for people working alone). You need to
be able to talk about a particular commit with others working independently.
> - They would be easier to use than the dotted ones. What (at least as
> far as I understand) makes revnos easier to use than revids is, that
> you can remember few of them for short time while composing some
> operation. Ie. look up 2 or 3 revisions in the log and than do some
> command on them. And a 4 to 5-digit number like 10532 is easier to
> remember than something like 3250.2.45.86.
Probably. In git you can (mostly) get away with partial SHA-1's, BTW.
> - Their ordering would be an (arbitrary) superset of the partial
> ordering by descendance, ie. if revision A is ancestor of B, it would
> always have lower revno.
> - The intuition that lower revno means older revision would be always
> valid for related revisions and approximately valid for unrelated
> ones.
> - They would be *localy stable*. That is once assigned the revno would
> always mean the same revision in given branch (as determined by
> location, not tip).
Tip-relative is extremely useful: I wouldn't normally remember the current
revision, but I'll probably often be talking about "the change before this
one" and so on.
> - This is more than the current scheme can give, since now pull can
> renumber revisions.
Urgh. Get an update, and all your bearings change?
> - They wouldn't make any branch special, so the objections Linus raised
> does not apply.
But the original branch /is/ special?
> - They would be the same as subversion and svk, and IIRC mercurial as
> well, use, so:
> - They would already be familiar to users comming from those systems.
> - They are known to be useful that way. In fact for svk it's the only
> way to refer to revisions and seem to work satisfactorily (though
> note that svk is not really suitable to ad-hoc topologies).
SVN is /centralized/, there it does make sense talking about (the one and
only) history. In a distributed system, potentially each has a different
history, and they are intertwined.
Not at all useful.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* Re: [PATCH 2/2] Remove unused index tracking code.
From: Junio C Hamano @ 2006-10-20 1:35 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610192058130.1971@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> This patch in particular creates additional restrictions on pack
> files that were not present before. And I don't think this is a good
> thing.
>
> This patch impose an ordering on REF_DELTA objects that doesn't need to
> exist. Say for example that an OFS_DELTA depends on an object which is
> a REF_DELTA object. With this patch any pack with the base for that
> REF_DELTA stored after the OFS_DELTA object will be broken.
>
> And to really do thin pack fixing properly we really want to just append
> missing base objects at the end of the pack which falls in the broken
> case above.
>
> So this is a NAK from me.
I agree.
By the way, it is rather rare for us to see a NAK on this list.
I'd welcome to see more of them ;-).
^ permalink raw reply
* Re: [PATCH 2/2] Remove unused index tracking code.
From: Nicolas Pitre @ 2006-10-20 1:11 UTC (permalink / raw)
To: Jan Harkes; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <20061020002048.GC7162@delft.aura.cs.cmu.edu>
On Thu, 19 Oct 2006, Jan Harkes wrote:
> Tracking the offsets is not that hard, but calculating the sha1 for the
> deltas is tricky, we may have already seen and written out the base we
> need. So it is actually easier to avoid the complexity altogether and
> rely on git-index-pack to rebuild the index. The indexing step is also a
> useful validation whether the final pack contains a base for every delta.
>
> Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>
I don't think it is a good idea.
After looking at the problem for a while I should side with Linus.
unpack-objects is not the proper tool for the job. The way to go is to
make input to index-pack streamable.
This patch in particular creates additional restrictions on pack
files that were not present before. And I don't think this is a good
thing.
This patch impose an ordering on REF_DELTA objects that doesn't need to
exist. Say for example that an OFS_DELTA depends on an object which is
a REF_DELTA object. With this patch any pack with the base for that
REF_DELTA stored after the OFS_DELTA object will be broken.
And to really do thin pack fixing properly we really want to just append
missing base objects at the end of the pack which falls in the broken
case above.
So this is a NAK from me.
> ---
> builtin-unpack-objects.c | 57 +++++++++++-----------------------------------
> 1 files changed, 14 insertions(+), 43 deletions(-)
>
> diff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c
> index b95c93c..3df7938 100644
> --- a/builtin-unpack-objects.c
> +++ b/builtin-unpack-objects.c
> @@ -89,29 +89,6 @@ static void *get_data(unsigned long size
> }
>
> static struct sha1file *pack_file;
> -static unsigned long pack_file_offset;
> -
> -struct index_entry {
> - unsigned long offset;
> - unsigned char sha1[20];
> -};
> -
> -static unsigned int index_nr, index_alloc;
> -static struct index_entry **index_array;
> -
> -static void add_pack_index(unsigned char *sha1)
> -{
> - struct index_entry *entry;
> - int nr = index_nr;
> - if (nr >= index_alloc) {
> - index_alloc = (index_alloc + 64) * 3 / 2;
> - index_array = xrealloc(index_array, index_alloc * sizeof(*index_array));
> - }
> - entry = xmalloc(sizeof(*entry));
> - entry->offset = pack_file_offset;
> - hashcpy(entry->sha1, sha1);
> - index_array[nr++] = entry;
> -}
>
> static void write_pack_delta(const unsigned char *base, const void *delta, unsigned long delta_size)
> {
> @@ -122,11 +99,9 @@ static void write_pack_delta(const unsig
> sha1write(pack_file, header, hdrlen);
> sha1write(pack_file, base, 20);
> datalen = sha1write_compressed(pack_file, delta, delta_size);
> -
> - pack_file_offset += hdrlen + 20 + datalen;
> }
>
> -static void write_pack_object(const char *type, const unsigned char *sha1, const void *buf, unsigned long size)
> +static void write_pack_object(const void *buf, unsigned long size, const char *type, const unsigned char *sha1)
> {
> unsigned char header[10];
> unsigned hdrlen, datalen;
> @@ -134,8 +109,6 @@ static void write_pack_object(const char
> hdrlen = encode_header(string_to_type(type, sha1), size, header);
> sha1write(pack_file, header, hdrlen);
> datalen = sha1write_compressed(pack_file, buf, size);
> -
> - pack_file_offset += hdrlen + datalen;
> }
>
> struct delta_info {
> @@ -160,22 +133,21 @@ static void add_delta_to_list(unsigned c
>
> static void added_object(unsigned char *sha1, const char *type, void *data, unsigned long size);
>
> -static void write_object(void *buf, unsigned long size, const char *type,
> - unsigned char *base, void *delta, unsigned long delta_size)
> +static void write_object(void *buf, unsigned long size, const char *type)
> {
> unsigned char sha1[20];
>
> if (pack_file) {
> if (hash_sha1_file(buf, size, type, sha1) < 0)
> die("failed to compute object hash");
> - add_pack_index(sha1);
> - if (0 && base)
> - write_pack_delta(base, delta, delta_size);
> - else
> - write_pack_object(type, sha1, buf, size);
> - } else if (write_sha1_file(buf, size, type, sha1) < 0)
> - die("failed to write object");
> - added_object(sha1, type, buf, size);
> +
> + write_pack_object(buf, size, type, sha1);
> + } else {
> + if (write_sha1_file(buf, size, type, sha1) < 0)
> + die("failed to write object");
> +
> + added_object(sha1, type, buf, size);
> + }
> }
>
> static void resolve_delta(const char *type, unsigned char *base_sha1,
> @@ -190,7 +162,7 @@ static void resolve_delta(const char *ty
> &result_size);
> if (!result)
> die("failed to apply delta");
> - write_object(result, result_size, type, base_sha1, delta, delta_size);
> + write_object(result, result_size, type);
> free(delta);
> free(result);
> }
> @@ -225,7 +197,7 @@ static void unpack_non_delta_entry(enum
> default: die("bad type %d", kind);
> }
> if (!dry_run && buf)
> - write_object(buf, size, type, NULL, NULL, 0);
> + write_object(buf, size, type);
> free(buf);
> }
>
> @@ -334,12 +306,11 @@ static void unpack_all(const char *repac
> newhdr.hdr_signature = htonl(PACK_SIGNATURE);
> newhdr.hdr_version = htonl(PACK_VERSION);
> newhdr.hdr_entries = htonl(nr_objects);
> -
> +
> pack_file = sha1create("%s.pack", repack);
> sha1write(pack_file, &newhdr, sizeof(newhdr));
> - pack_file_offset = sizeof(newhdr);
> }
> -
> +
>
> use(sizeof(struct pack_header));
> for (i = 0; i < nr_objects; i++)
> --
> 1.4.2.1
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Nicolas
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-20 1:06 UTC (permalink / raw)
To: Carl Worth
Cc: Linus Torvalds, Jakub Narebski, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <87ods727pn.wl%cworth@cworth.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Carl Worth wrote:
> On Thu, 19 Oct 2006 19:01:58 -0400, Aaron Bentley wrote:
> Do you see how "maintain
> an independent URL namespace for every distributed branch" doesn't
> encourage much distributed development?
I understand your argument now. It's nothing to do with numbers per se,
and all about per-branch namespaces. Correct?
>> Additionally, the new mainline can keep a mirror of the
>> abandoned mainline in its repository, because there are virtually no
>> additional storage requirements to doing so.
>
> And this part I don't understand. I can understand the mainline
> storing the revisions, but I don't understand how it could make them
> accessible by the published revision numbers of the "abandoned"
> line. And that's the problem.
I meant that the active branch and a mirror of the abandoned branch
could be stored in the same repository, for ease of access.
Bazaar encourages you to stick lots and lots of branches in your
repository. They don't even have to be related. For example, my repo
contains branches of bzr, bzrtools, Meld, and BazaarInspect.
> It sounds like bzr has numbers like this inside it, (but not nearly as
> simple as the ones that git has), but that users aren't in the
> practice of communicating with them. Instead, users communicate with
> the unstable numbers. And that's a shame from an historical
> perspective.
I can see where you're coming from, but to me, the trade-off seems
worthwhile. Because historical data gets less and less valuable the
older it gets. By the time the URL for a branch goes dark, there's
unlikely to be any reason to refer to one of its revisions at all.
> The original claim that sparked the discussion was that bzr has a
> "simple namespace" while git does not. We've been talking for quite a
> while here, and I still don't fully understand how these numbers are
> generated or what I can expect to happen to the numbers associated
> with a given revision as that revision moves from one repository to
> another. It's really not a simple scheme.
When you create a new branch from scratch, the number starts at zero.
If you copy a branch, you copy its number, too.
Every time you commit, the number is incremented. If you pull, your
numbers are adjusted to be identical to those of the branch you pulled from.
Is that really complicated?
> Meanwhile, I have been arguing that the "simple" revision numbers that
> bzr advertises have restrictions on their utility, (they can only be
> used with reference to a specific repository, or with reference to
> another that treats it as canonical). I _think_ I understand the
> numbers well enough to say that still.
Sure. It's the "favors centralization" thing that I don't agree with,
but I now understand your argument.
> Compare that with the git names. The scheme really is easy to
> understand, (either the new user already understands cryptographic
> hashes, or else it's as easy as "a long string of digits that git
> assigns as the name").
In my experience, users who don't understand distributed systems don't
understand why UUIDS must be used as identifiers.
> The naming in git really is beautiful and beautifully simple.
Well, you've got to admit that those names are at least superficially ugly.
> It's not monotonically increasing from one revision to the next, but
> I've never found that to be an issue. Of course, we do still use our
> own "simple" names for versioning the releases and snapshots of
> software we manage with git, and that's where being able to easily
> determine "newer" or "older" by simple numerical examination is
> important. I've honestly never encountered a situation where I was
> handed two git sha1 sums and wished that I could do the same thing.
What's nice is being able see the revno 753 and knowing that "diff -r
752..753" will show the changes it introduced. Checking the revo on a
branch mirror and knowing how out-of-date it is.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFOCEf0F+nu1YWqI0RAhgtAJwK4jkWFjjF2iHJb1VyXqgszsHElACff2U7
olZJiAED80tIS6kgkqFsJps=
=BkRZ
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] git-svnimport.perl: copying directory from original SVN place
From: Sasha Khapyorsky @ 2006-10-20 0:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthias Urlichs
In-Reply-To: <7vmz7rrg1a.fsf@assigned-by-dhcp.cox.net>
On 17:23 Thu 19 Oct , Junio C Hamano wrote:
> Sasha Khapyorsky <sashak@voltaire.com> writes:
>
> > Hi guys,
> >
> > On 23:31 Sun 08 Oct , Sasha Khapyorsky wrote:
> >>
> >> When copying whole directory, if source directory is not in already
> >> imported tree, try to get it from original SVN location. This happens
> >> when source directory is not matched by provided 'trunk' and/or
> >> 'tags/branches' templates or when it is not part of specified SVN
> >> sub-project.
> >
> > Any news with it?
>
> I've pushed it out in "master" after 1.4.3, to see if anybody
> cares about git-svnimport would scream. If we do not hear from
> anybody about breakage that would be a good sign, otherwise we
> would get a fix so that is good as well ;-).
Cool. Thanks.
Sasha
^ permalink raw reply
* Re: [PATCH] git-svnimport.perl: copying directory from original SVN place
From: Junio C Hamano @ 2006-10-20 0:23 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: git, Matthias Urlichs
In-Reply-To: <20061020002219.GF24676@sashak.voltaire.com>
Sasha Khapyorsky <sashak@voltaire.com> writes:
> Hi guys,
>
> On 23:31 Sun 08 Oct , Sasha Khapyorsky wrote:
>>
>> When copying whole directory, if source directory is not in already
>> imported tree, try to get it from original SVN location. This happens
>> when source directory is not matched by provided 'trunk' and/or
>> 'tags/branches' templates or when it is not part of specified SVN
>> sub-project.
>
> Any news with it?
I've pushed it out in "master" after 1.4.3, to see if anybody
cares about git-svnimport would scream. If we do not hear from
anybody about breakage that would be a good sign, otherwise we
would get a fix so that is good as well ;-).
^ permalink raw reply
* [PATCH 2/2] Remove unused index tracking code.
From: Jan Harkes @ 2006-10-20 0:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610190936440.3962@g5.osdl.org>
Tracking the offsets is not that hard, but calculating the sha1 for the
deltas is tricky, we may have already seen and written out the base we
need. So it is actually easier to avoid the complexity altogether and
rely on git-index-pack to rebuild the index. The indexing step is also a
useful validation whether the final pack contains a base for every delta.
Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>
---
builtin-unpack-objects.c | 57 +++++++++++-----------------------------------
1 files changed, 14 insertions(+), 43 deletions(-)
diff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c
index b95c93c..3df7938 100644
--- a/builtin-unpack-objects.c
+++ b/builtin-unpack-objects.c
@@ -89,29 +89,6 @@ static void *get_data(unsigned long size
}
static struct sha1file *pack_file;
-static unsigned long pack_file_offset;
-
-struct index_entry {
- unsigned long offset;
- unsigned char sha1[20];
-};
-
-static unsigned int index_nr, index_alloc;
-static struct index_entry **index_array;
-
-static void add_pack_index(unsigned char *sha1)
-{
- struct index_entry *entry;
- int nr = index_nr;
- if (nr >= index_alloc) {
- index_alloc = (index_alloc + 64) * 3 / 2;
- index_array = xrealloc(index_array, index_alloc * sizeof(*index_array));
- }
- entry = xmalloc(sizeof(*entry));
- entry->offset = pack_file_offset;
- hashcpy(entry->sha1, sha1);
- index_array[nr++] = entry;
-}
static void write_pack_delta(const unsigned char *base, const void *delta, unsigned long delta_size)
{
@@ -122,11 +99,9 @@ static void write_pack_delta(const unsig
sha1write(pack_file, header, hdrlen);
sha1write(pack_file, base, 20);
datalen = sha1write_compressed(pack_file, delta, delta_size);
-
- pack_file_offset += hdrlen + 20 + datalen;
}
-static void write_pack_object(const char *type, const unsigned char *sha1, const void *buf, unsigned long size)
+static void write_pack_object(const void *buf, unsigned long size, const char *type, const unsigned char *sha1)
{
unsigned char header[10];
unsigned hdrlen, datalen;
@@ -134,8 +109,6 @@ static void write_pack_object(const char
hdrlen = encode_header(string_to_type(type, sha1), size, header);
sha1write(pack_file, header, hdrlen);
datalen = sha1write_compressed(pack_file, buf, size);
-
- pack_file_offset += hdrlen + datalen;
}
struct delta_info {
@@ -160,22 +133,21 @@ static void add_delta_to_list(unsigned c
static void added_object(unsigned char *sha1, const char *type, void *data, unsigned long size);
-static void write_object(void *buf, unsigned long size, const char *type,
- unsigned char *base, void *delta, unsigned long delta_size)
+static void write_object(void *buf, unsigned long size, const char *type)
{
unsigned char sha1[20];
if (pack_file) {
if (hash_sha1_file(buf, size, type, sha1) < 0)
die("failed to compute object hash");
- add_pack_index(sha1);
- if (0 && base)
- write_pack_delta(base, delta, delta_size);
- else
- write_pack_object(type, sha1, buf, size);
- } else if (write_sha1_file(buf, size, type, sha1) < 0)
- die("failed to write object");
- added_object(sha1, type, buf, size);
+
+ write_pack_object(buf, size, type, sha1);
+ } else {
+ if (write_sha1_file(buf, size, type, sha1) < 0)
+ die("failed to write object");
+
+ added_object(sha1, type, buf, size);
+ }
}
static void resolve_delta(const char *type, unsigned char *base_sha1,
@@ -190,7 +162,7 @@ static void resolve_delta(const char *ty
&result_size);
if (!result)
die("failed to apply delta");
- write_object(result, result_size, type, base_sha1, delta, delta_size);
+ write_object(result, result_size, type);
free(delta);
free(result);
}
@@ -225,7 +197,7 @@ static void unpack_non_delta_entry(enum
default: die("bad type %d", kind);
}
if (!dry_run && buf)
- write_object(buf, size, type, NULL, NULL, 0);
+ write_object(buf, size, type);
free(buf);
}
@@ -334,12 +306,11 @@ static void unpack_all(const char *repac
newhdr.hdr_signature = htonl(PACK_SIGNATURE);
newhdr.hdr_version = htonl(PACK_VERSION);
newhdr.hdr_entries = htonl(nr_objects);
-
+
pack_file = sha1create("%s.pack", repack);
sha1write(pack_file, &newhdr, sizeof(newhdr));
- pack_file_offset = sizeof(newhdr);
}
-
+
use(sizeof(struct pack_header));
for (i = 0; i < nr_objects; i++)
--
1.4.2.1
^ permalink raw reply related
* [PATCH 1/2] Pass through unresolved deltas when writing a pack
From: Jan Harkes @ 2006-10-20 0:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610190936440.3962@g5.osdl.org>
The resulting pack should be correct if we have the base somewhere else in
the received pack, if we didn't have the base the received pack would be
faulty and can't be unpacked as loose objects either.
The internal pack index information is not updated correctly anymore.
Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>
---
builtin-unpack-objects.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c
index f139308..b95c93c 100644
--- a/builtin-unpack-objects.c
+++ b/builtin-unpack-objects.c
@@ -246,7 +246,10 @@ static void unpack_delta_entry(unsigned
}
if (!has_sha1_file(base_sha1)) {
- add_delta_to_list(base_sha1, delta_data, delta_size);
+ if (pack_file)
+ write_pack_delta(base_sha1, delta_data, delta_size);
+ else
+ add_delta_to_list(base_sha1, delta_data, delta_size);
return;
}
base = read_sha1_file(base_sha1, type, &base_size);
--
1.4.2.1
^ permalink raw reply related
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