* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-17 22:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64.0610171448150.3962@g5.osdl.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Linus Torvalds wrote:
>
> On Tue, 17 Oct 2006, Aaron Bentley wrote:
>>>> Interesting. We don't do 'fast-forward' in that case.
>>> Fast-forward is a really good idea. Perhaps you could implement it,
>>> if it is not hidden under different name?
>> We support it as 'pull', but merge doesn't do it automatically, because
>> we'd rather have merge behave the same all the time, and because 'pull'
>> throws away your local commit ordering.
>
> Excuse me? What does that "throws away your local commit ordering" mean?
Say this is the ordering in branch A:
a
|
b
|
c
Say this is the ordering in branch B:
a
|
b
|\
d c
|/
e
When A pulls B, it gets the same ordering as B has. If B did not have e
and c, the pull would fail.
> So generating an extra "merge" commit would be actively wrong, and adds
> "history" that is not history at all.
It's not a tree change, but it records the fact that one branch merged
the other.
> It also means that if people merge back and forth from each other, you get
> into an endless loop of useless merge commits.
You can pull if you don't want that. We haven't found that people are
very fussed about it.
> There's no reason _ever_ to not just fast-forward if one repository is a
> strict superset of the other.
Maybe not in Git.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNV7u0F+nu1YWqI0RAhGtAJwOlWpl088pbl63EHyF04qQCYlXBgCfW0Tm
cfXuE0vqeWelfFbpzffiCNI=
=McQ2
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-17 22:44 UTC (permalink / raw)
To: Sean; +Cc: Jakub Narebski, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <BAYC1-PASMTP07AB11A64250AAF683424DAE0E0@CEZ.ICE>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sean wrote:
> On Tue, 17 Oct 2006 17:27:44 -0400
> Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
>
>> Bzr has plugin autoloading, Protocol plugins, Repository format plugins,
>> and more. Because Python supports monkey-patching, a plugin can change
>> absolutely anything.
>
> But really why does any of that matter? This is the open source world.
> We don't need plugins to extend features, we just add the feature to
> the source.
That can lead to feature bloat. Some plugins are not useful to
everyone, e.g. Mercurial repository support. Some plugins introduce
additional dependencies that we don't want to have in the core (e.g. the
rsync, baz-import and graph-ancestry commands).
Plugins also don't have a Bazaar's rigid release cycle, testing
requirements and coding conventions, so they are a convenient way to try
out an idea, before committing to the effort of getting it merged into
the core.
> The example I asked about earlier is a case in point.
> Apparently in bzr "bisect" was implemented as a plugin, yet in Git it
> was implemented as a command without any issue at all, no plugins
> needed, and its compiled and runs at machine speed.
The bisect plugin is just as performant as any other bzr command. (The
whole VCS is in Python.) Most people don't use it, so we don't ship it
as part of the base install, but anyone who wants it can have it.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNVy70F+nu1YWqI0RAnlxAJ9+ZXryG/KJxi6hjpz+U/gU3y06MQCdH2Ez
cFlnxwWksB+q2b1dXI3cfwo=
=HAy6
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-17 22:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Andreas Ericsson, bazaar-ng, git
In-Reply-To: <200610172351.17377.jnareb@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jakub Narebski wrote:
> Aaron Bentley wrote:
>> What is the bad side of using merge in this situation?
>
> We want linear history, not polluted by merges. For example you cannot
> send merge commit via email.
Oh. Bazaar supports sending merge commits by email.
> Another problem is that you want to
> send _series_ of patches, string of commits (revisions), creating feature
> part by part, with clean history; with merge you get _final result_
> which will apply cleanly, with rebase you would get that series
> of patches will apply cleanly.
Yes, that's something that I'd heard about the kernel development
methodology-- that a series of small patches is preferred to one patch
that makes the whole change.
That's not the way we operate. We like to review all the changes at
once. But because bundles are applied with a 'merge' command, not a
'patch' command, an old bundle will tend to apply more cleanly than an
old patch would.
> I smell yet another terminology conflict (although this time fault is
> on the git side), namely that in git terminology "pull" is "fetch"
> (i.e. getting changes done in remote repository since laste "fetch"
> or since "clone") followed by merge. pull = fetch + merge.
I guess so, since git merge will do fast-forward after a fetch.
>> and more. Because Python supports monkey-patching, a plugin can change
>> absolutely anything.
>
> Which is _not_ a good idea. Git is created in such way, that the repository
> is abstracted away (introduction of pack format, and improving pack format
> can and was done "behind the scenes", not changing any porcelanish (user)
> commands), but we don't want any chage that would change this abstraction.
I'm not sure what you think Bazaar does. In Bazaar, a repository format
plugin implements the same API that a native repository format does.
This is how bzr supports Subversion, Mercurial and Git repositories.
> Changing repository format is not a good idea for "dumb" protocols;
I can't parse this. Repository formats and protocols are different
things, right?
> native
> protocol is quite extensible
I was meaning dumb protocol extension. I can't say how extensible the
bzr native protocol is.
> Adding
> cURL based FTP read-only support to existing HTTP support was a matter
> of few lines, if I remember correctly.
We support read and write over native, ftp and WebDAV (a plugin). We
also have readonly http support.
> Besides, if monkey-patching is something akin to advices, I guess that
> performance might suffer.
No, monkey-patched code executes at the same speed as unpatched code.
There are arguments against monkey-patching, but speed is not one of them.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNVkM0F+nu1YWqI0RAjCaAJwOcWSUdVy7RpUZROJVxAC9aj/V/wCfUg0T
uHkdc9k6i+v0QnhEvTXdszM=
=YO8G
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: VCS comparison table
From: Robert Collins @ 2006-10-17 22:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: bazaar-ng, git, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0610170921540.3962@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]
On Tue, 2006-10-17 at 09:41 -0700, Linus Torvalds wrote:
>
> On Tue, 17 Oct 2006, Robert Collins wrote:
>
> > On Tue, 2006-10-17 at 11:20 +0200, Jakub Narebski wrote:
> > >
> > > ---- time --->
> > >
> > > --*--*--*--*--*--*--*--*--*-- <branch>
> > > \ /
> > > \-*--X--*--/
> > >
> > > The branch it used to be on is gone...
> >
> > In bzr 0.12 this is :
> > 2.1.2
> >
> > (assuming the first * is numbered '1'.)
> >
> > These numbers are fairly stable
>
> And here, by "fairly stable", you really mean "totally idiotic", don't
> you?
>
> Guys, let's be blunt here, and just say you're wrong. The fact is, I've
> used a system that uses the same naming bzr does, and I've used it likely
> longer and with a bigger project than anybody has likely _ever_ used bzr
> for.
>
> It sounds like bzr is doing _exactly_ what bitkeeper did.
>
> Those "simple" numbers are totally idiotic. And when I say "totally
> idiotic", please go back up a few sentences, and read those again. I know
> what I'm talking about. I know probably better than anybody in the bzr
> camp.
Be as blunt as you want. You're expressing an opinion, and thats fine. I
happen to think that we're right : users appear to really appreciate
this bit of the UI, and I've not yet seen any evidence of confusion
about it - though I will admit there is the possibility of that
occurring.
I think its completely ok that git and bzr have made different choices
in this regard, but I *dont* think our choice is in any regard 'totally
idiotic'.
[snip examples that are clearly predicated on how bk worked, not on how
bzr works].
-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH] nice ftplugin for vim, that shows the commited diff in a split'ed buffer.
From: Junio C Hamano @ 2006-10-17 22:04 UTC (permalink / raw)
To: Christian MICHON; +Cc: git, Pierre Habouzit
In-Reply-To: <46d6db660610171448h53de5e40wf55f19d6458127ef@mail.gmail.com>
"Christian MICHON" <christian.michon@gmail.com> writes:
> On 10/17/06, Pierre Habouzit <madcoder@debian.org> wrote:
>> and that time, I'll send that to the git contrib/vim maintainer so that
>> I won't bother the list too much :)
>>
>
> so there is a contrib/vim maintainer ? Sorry I'm new on git list
> (though Pierre gave me some hints already with git/vim).
If you have git sources, check contrib/README please.
What I asked Pierre was to CC the patch to Jeff King who did
contrib/vim -- it was "send it to him too", and not "do not send
it to me". I do not actively use vim myself so I am a wrong
person to judge patches to that part of the source tree.
Apparently Pierre seems to have thought that I thought patches
to the contrib/ part is "bothering the list", but that was not
my intention. I believe showing your patches for review by
wider audiences is a good thing.
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-17 22:03 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Jakub Narebski, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <45354AD0.1020107@utoronto.ca>
On Tue, 17 Oct 2006, Aaron Bentley wrote:
>
> >>Interesting. We don't do 'fast-forward' in that case.
> >
> > Fast-forward is a really good idea. Perhaps you could implement it,
> > if it is not hidden under different name?
>
> We support it as 'pull', but merge doesn't do it automatically, because
> we'd rather have merge behave the same all the time, and because 'pull'
> throws away your local commit ordering.
Excuse me? What does that "throws away your local commit ordering" mean?
A fast-forward does no such thing. It leaves the local commit ordering
alone, it just appends other things on top of it. It's the only sane thing
you can do, since the work you merged was already based on your top
commit.
So generating an extra "merge" commit would be actively wrong, and adds
"history" that is not history at all.
It also means that if people merge back and forth from each other, you get
into an endless loop of useless merge commits. What's the point? They only
clutter up the history, and they mean that you can never agree on a common
state.
There's no reason _ever_ to not just fast-forward if one repository is a
strict superset of the other.
You must be doing something wrong. Is it just that people want to pee in
the snow and leave their mark?
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Sean @ 2006-10-17 22:00 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Jakub Narebski, Andreas Ericsson, bazaar-ng, git
In-Reply-To: <45354AD0.1020107@utoronto.ca>
On Tue, 17 Oct 2006 17:27:44 -0400
Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
> Bzr has plugin autoloading, Protocol plugins, Repository format plugins,
> and more. Because Python supports monkey-patching, a plugin can change
> absolutely anything.
But really why does any of that matter? This is the open source world.
We don't need plugins to extend features, we just add the feature to
the source. The example I asked about earlier is a case in point.
Apparently in bzr "bisect" was implemented as a plugin, yet in Git it
was implemented as a command without any issue at all, no plugins
needed, and its compiled and runs at machine speed.
Sean
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Junio C Hamano @ 2006-10-17 21:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Sergey Vlasov, git
In-Reply-To: <Pine.LNX.4.64.0610171339030.3962@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 17 Oct 2006, Nicolas Pitre wrote:
>> On Tue, 17 Oct 2006, Sergey Vlasov wrote:
>> >
>> > Yes, on x86_64 this is 24 because of 8-byte alignment for longs:
>>
>> Ah bummer. Then this is most likely the cause. And here's a simple
>> fix (Junio please confirm):
>
> Why do you use "unsigned long" in the first place?
>
> For some structure like this, it sounds positively wrong. Pack-files
> should be architecture-neutral, which means that they shouldn't depend on
> word-size, and they should be in some neutral byte-order.
This is an in-core structure if I am not mistaken, and is never
written out in the resulting pack file. The program is reading
from .pack and building .idx that corresponds to it. I agree
that it is ugly, but I do not hink using neutral byte-order in
this part of the processing buys us anything in this particular
case.
> In contrast, the new union introduced in "next" is just horrid. There's
> not even any way to know which member to use, except apparently that it
> expects that a SHA1 is never zero in the last 12 bytes. Which is probably
> true, but still - that's some ugly stuff.
Again I agree with the ugliness objection, and I raised the
"expecting no collision" issue which Nico refuted later. The
code is probably safe (not just safe in practice but safe in
theory as well), although that would not change the fact that it
is ugly X-<.
Nico, could we have an un-uglied version please?
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-17 21:51 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Andreas Ericsson, bazaar-ng, git
In-Reply-To: <45354AD0.1020107@utoronto.ca>
Aaron Bentley wrote:
> Jakub Narebski wrote:
>>>Ah, now I see what you mean, and the "graft" plugin mentioned by others
>>>fills that role. I've never used it, though.
>>
>> Very useful as a kind of poor-man's-Quilt (or StGit). You develop some
>> feature step by step, commit by commit in your repository cooking it
>> in topic branch. Then before sending it to mailing list or maintainer
>> as a series of patches (using git-format-patch and git-send-email)
>> you rebase it on top of current work (current state), to ensure that
>> it would apply cleanly.
>
> What is the bad side of using merge in this situation?
We want linear history, not polluted by merges. For example you cannot
send merge commit via email. Another problem is that you want to
send _series_ of patches, string of commits (revisions), creating feature
part by part, with clean history; with merge you get _final result_
which will apply cleanly, with rebase you would get that series
of patches will apply cleanly.
>>>Interesting. We don't do 'fast-forward' in that case.
>>
>> Fast-forward is a really good idea. Perhaps you could implement it,
>> if it is not hidden under different name?
>
> We support it as 'pull', but merge doesn't do it automatically, because
> we'd rather have merge behave the same all the time, and because 'pull'
> throws away your local commit ordering.
I smell yet another terminology conflict (although this time fault is
on the git side), namely that in git terminology "pull" is "fetch"
(i.e. getting changes done in remote repository since laste "fetch"
or since "clone") followed by merge. pull = fetch + merge.
>>>So it sounds to me like git is extensible, though not as thoroughly as bzr.
>>
>>
>> I think having good API for C, shell and Perl (and to lesser extent for any
>> scripting language) means that it is extensible more.
>
> I guess it's a value judgement on which is more important to extensibility:
>
> Git has more language support.
>
> Bzr has plugin autoloading, Protocol plugins, Repository format plugins,
> and more. Because Python supports monkey-patching, a plugin can change
> absolutely anything.
Which is _not_ a good idea. Git is created in such way, that the repository
is abstracted away (introduction of pack format, and improving pack format
can and was done "behind the scenes", not changing any porcelanish (user)
commands), but we don't want any chage that would change this abstraction.
Changing repository format is not a good idea for "dumb" protocols; native
protocol is quite extensible (for example there was introduced multi-ack
extension for better downloading of multiple branches with lesser number
of object in the pack sent; even earlier there were intoduced thin packs),
and does a kind of feature detection between client and server. Adding
cURL based FTP read-only support to existing HTTP support was a matter
of few lines, if I remember correctly.
Besides, if monkey-patching is something akin to advices, I guess that
performance might suffer.
To make perhaps not that good analogy. In git adding new commands is
like adding new filesystem to Linux kernel using existing VFS interface,
or existing FUSE/LUFS interface. In Bazaar adding new command is like
writing new filesystem support (plugin) in mikrokernel like L4/Mach.
(And please take note for what project git was created for :-))
--
Jakub Narebski
ShadeHawk on #git
Poland
^ permalink raw reply
* Re: [PATCH] nice ftplugin for vim, that shows the commited diff in a split'ed buffer.
From: Christian MICHON @ 2006-10-17 21:48 UTC (permalink / raw)
To: git
In-Reply-To: <200610171304.39131.madcoder@debian.org>
On 10/17/06, Pierre Habouzit <madcoder@debian.org> wrote:
> and that time, I'll send that to the git contrib/vim maintainer so that
> I won't bother the list too much :)
>
so there is a contrib/vim maintainer ? Sorry I'm new on git list
(though Pierre gave me some hints already with git/vim).
I'm interested in testing more of these goodies. Because I
actually use git now on a daily basis for tcl/verilog/EDA
together with (g)vim.
I'd like particularly to know if a git-explorer type of plugin makes
sense for (g)vim and would like in this case be part of the team
developping it... using git of course :)
--
Christian
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Linus Torvalds @ 2006-10-17 21:46 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Sergey Vlasov, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610171706260.1971@xanadu.home>
On Tue, 17 Oct 2006, Nicolas Pitre wrote:
>
> Because offsets into packs are expressed as unsigned long everywhere
> else (except in the current pack index on-disk format).
Until your work, that "unsigned long" was totally just an internal thing
that didn't actually bleed into anything else.
> > For some structure like this, it sounds positively wrong. Pack-files
> > should be architecture-neutral, which means that they shouldn't depend on
> > word-size, and they should be in some neutral byte-order.
>
> But they do. Please consider this code:
Right. The pack-file itself. But the code that actually _generates_ it
mixes things in alarming ways.
> > In contrast, the new union introduced in "next" is just horrid. There's
> > not even any way to know which member to use, except apparently that it
> > expects that a SHA1 is never zero in the last 12 bytes. Which is probably
> > true, but still - that's some ugly stuff.
>
> This union should be looked at just like a sortable hash pointing to a
> base object so that deltas with the same base object can be sorted
> together.
.. and it sorts _differently_ on a big-endian vs little-endian thing,
doesn't it?
So now the sort order depends on endianness and/or wordsize. That just
sounds really really wrong.
Linus
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-17 21:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Andreas Ericsson, bazaar-ng, git
In-Reply-To: <200610172301.27101.jnareb@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jakub Narebski wrote:
>>Ah, now I see what you mean, and the "graft" plugin mentioned by others
>>fills that role. I've never used it, though.
>
>
> Very useful as a kind of poor-man's-Quilt (or StGit). You develop some
> feature step by step, commit by commit in your repository cooking it
> in topic branch. Then before sending it to mailing list or maintainer
> as a series of patches (using git-format-patch and git-send-email)
> you rebase it on top of current work (current state), to ensure that
> it would apply cleanly.
What is the bad side of using merge in this situation?
>>Interesting. We don't do 'fast-forward' in that case.
>
>
> Fast-forward is a really good idea. Perhaps you could implement it,
> if it is not hidden under different name?
We support it as 'pull', but merge doesn't do it automatically, because
we'd rather have merge behave the same all the time, and because 'pull'
throws away your local commit ordering.
>>So it sounds to me like git is extensible, though not as thoroughly as bzr.
>
>
> I think having good API for C, shell and Perl (and to lesser extent for any
> scripting language) means that it is extensible more.
I guess it's a value judgement on which is more important to extensibility:
Git has more language support.
Bzr has plugin autoloading, Protocol plugins, Repository format plugins,
and more. Because Python supports monkey-patching, a plugin can change
absolutely anything.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFFNUrP0F+nu1YWqI0RAizXAJ0Wnf2ZoIRpaba3mX2L4pN9XcWDPQCePtg/
G/W6Oxm+kd8SzhGEEfLAxL8=
=VqC7
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Nicolas Pitre @ 2006-10-17 21:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Sergey Vlasov, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610171339030.3962@g5.osdl.org>
On Tue, 17 Oct 2006, Linus Torvalds wrote:
>
>
> On Tue, 17 Oct 2006, Nicolas Pitre wrote:
> > On Tue, 17 Oct 2006, Sergey Vlasov wrote:
> > >
> > > Yes, on x86_64 this is 24 because of 8-byte alignment for longs:
> >
> > Ah bummer. Then this is most likely the cause. And here's a simple
> > fix (Junio please confirm):
>
> Why do you use "unsigned long" in the first place?
Because offsets into packs are expressed as unsigned long everywhere
else (except in the current pack index on-disk format).
> For some structure like this, it sounds positively wrong. Pack-files
> should be architecture-neutral, which means that they shouldn't depend on
> word-size, and they should be in some neutral byte-order.
But they do. Please consider this code:
case OBJ_OFS_DELTA:
memset(delta_base, 0, sizeof(*delta_base));
c = pack_base[pos++];
base_offset = c & 127;
while (c & 128) {
base_offset += 1;
if (!base_offset || base_offset & ~(~0UL >> 7))
bad_object(offset, "offset value overflow for delta base object");
if (pos >= pack_limit)
bad_object(offset, "object extends past end of pack");
c = pack_base[pos++];
base_offset = (base_offset << 7) + (c & 127);
}
delta_base->offset = offset - base_offset;
if (delta_base->offset >= offset)
bad_object(offset, "delta base offset is out of bound");
break;
Do you see anything inerently wrong in this code? The above is already
64-bit ready such that it'll just work on 64-bit archs and will display
a sensible message if a 32-bit arch encounter a pack larger than 4GB.
But the on-disk pack format has no limitation what so ever.
> Quite frankly, this all makes me go "Eww..". The original pack-file (well,
> v2) format was well-defined and had none of these issues. In contrast, the
> new code in 'next' is just _ugly_.
I beg to differ. Please reconsider in light of the above.
> And maybe it's just me, but I consider unions to be bug-prone on their
> own. The "master" branch has exactly two unions: the "grep_expr" structure
> contains one (where the union member is clearly defined by the node type
> in that structure), and object.c has a "union any_object" that _literally_
> exists as purely an allocation size issue (ie it is used _only_ to
> allocate the maximum size of any of the possible structures).
>
> In contrast, the new union introduced in "next" is just horrid. There's
> not even any way to know which member to use, except apparently that it
> expects that a SHA1 is never zero in the last 12 bytes. Which is probably
> true, but still - that's some ugly stuff.
This union should be looked at just like a sortable hash pointing to a
base object so that deltas with the same base object can be sorted
together. And the field to use is well defined of course: deltas with
sha1 to base use the sha1 member, deltas with offset to base use the
offset member. This hash, together with the delta type, constitute a
tuple guaranteed to be unique so there can't be any confusion.
> Is this something you want to bet a big project on?
I don't see why not.
Nicolas
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-17 21:01 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Andreas Ericsson, bazaar-ng, git
In-Reply-To: <453536AE.6060601@utoronto.ca>
Aaron Bentley wrote:
> Andreas Ericsson wrote:
>> Aaron Bentley wrote:
>>> Ah. Bazaar uses negative numbers to refer to <n>th parents, and
>>> positive numbers to refer to the number of commits that have been made
>>> since the branch was initialized.
>>>
>>
>> What do you do once a branch has been thrown away, or has had 20 other
>> branches merged into it? Does the offset-number change for the revision
>> then, or do you track branch-points explicitly?
>
> We always track the number of parents since the initial commit in the
> project. Sorry, I don't think I said that clearly before.
While this I think is quite reliable (there was idea to store "generation
number" with each commit, e.g. using not implemented "note" header, or
commit-id to generation number "database" as a better heuristic than
timestamp for revision ordering in git-rev-list output), and probably
independent on repository (it is global property of commit history,
and commit history is included in sha1 of its parents), numbering branching
points is unreliable, as is relying on branch names.
>>> If I understand correctly, in Bazaar, you'd just merge the current work
>>> into 'xx/topic'.
>>>
>>
>> merge != rebase though, although they are indeed similar. Let's take the
>> example of a 'master' branch and topic branch topicA. If you rebase
>> topicA onto 'master', development will appear to have been serial.
>
> Ah, now I see what you mean, and the "graft" plugin mentioned by others
> fills that role. I've never used it, though.
Very useful as a kind of poor-man's-Quilt (or StGit). You develop some
feature step by step, commit by commit in your repository cooking it
in topic branch. Then before sending it to mailing list or maintainer
as a series of patches (using git-format-patch and git-send-email)
you rebase it on top of current work (current state), to ensure that
it would apply cleanly.
>> If
>> you instead merge them, it will either register as a real merge or, if
>> the branch tip of 'master' is the branch start-point of topicA, it will
>> result in a "fast-forward" where 'master' is just updated to the
>> branch-tip of 'topicA'.
>
> Interesting. We don't do 'fast-forward' in that case.
Fast-forward is a really good idea. Perhaps you could implement it,
if it is not hidden under different name?
>>> I'm not sure what you mean by API, unless you mean the commandline. If
>>> that's what you mean, surely all unix commands are extensible in that
>>> regard.
>>>
>>
>> I'm fairly certain he's talking about the API in the sense it's being
>> talked about in every other application. Extensive work has been made to
>> libify a lot of the git code, which means that most git commands are
>> made up of less than 400 lines of C code, where roughly 80% of the code
>> is command-specific (i.e., argument parsing and presentation).
>
> Ah, okay.
>
> So it sounds to me like git is extensible, though not as thoroughly as bzr.
I think having good API for C, shell and Perl (and to lesser extent for any
scripting language) means that it is extensible more. Git is not as of yet
libified; when it would be we could think about bindings for other
programming languages (there is preliminary Java binding/interface).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Linus Torvalds @ 2006-10-17 20:51 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Sergey Vlasov, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610171615340.1971@xanadu.home>
On Tue, 17 Oct 2006, Nicolas Pitre wrote:
> On Tue, 17 Oct 2006, Sergey Vlasov wrote:
> >
> > Yes, on x86_64 this is 24 because of 8-byte alignment for longs:
>
> Ah bummer. Then this is most likely the cause. And here's a simple
> fix (Junio please confirm):
Why do you use "unsigned long" in the first place?
For some structure like this, it sounds positively wrong. Pack-files
should be architecture-neutral, which means that they shouldn't depend on
word-size, and they should be in some neutral byte-order.
Quite frankly, this all makes me go "Eww..". The original pack-file (well,
v2) format was well-defined and had none of these issues. In contrast, the
new code in 'next' is just _ugly_.
And the thing about "ugly" is that it also tends to mean "fragile" and
"buggy" and "hard to extend later".
And maybe it's just me, but I consider unions to be bug-prone on their
own. The "master" branch has exactly two unions: the "grep_expr" structure
contains one (where the union member is clearly defined by the node type
in that structure), and object.c has a "union any_object" that _literally_
exists as purely an allocation size issue (ie it is used _only_ to
allocate the maximum size of any of the possible structures).
In contrast, the new union introduced in "next" is just horrid. There's
not even any way to know which member to use, except apparently that it
expects that a SHA1 is never zero in the last 12 bytes. Which is probably
true, but still - that's some ugly stuff.
Is this something you want to bet a big project on?
Linus
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Nicolas Pitre @ 2006-10-17 20:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sergey Vlasov
In-Reply-To: <7vy7reitzm.fsf@assigned-by-dhcp.cox.net>
On Tue, 17 Oct 2006, Junio C Hamano wrote:
> Sergey Vlasov <vsu@altlinux.ru> writes:
>
> > On Tue, 17 Oct 2006 14:47:16 -0400 (EDT) Nicolas Pitre wrote:
> >
> >> Is it possible that sizeof(union delta_base) might not be equal to 20
> >> for you?
> >
> > Yes, on x86_64 this is 24 because of 8-byte alignment for longs:
>
> Enough eyeballs made this bug shallow ;-) Thanks.
>
> diff --git a/index-pack.c b/index-pack.c
> index fffddd2..49b6efe 100644
> --- a/index-pack.c
> +++ b/index-pack.c
> @@ -166,6 +166,7 @@ static void *unpack_raw_entry(unsigned l
> case OBJ_REF_DELTA:
> if (pos + 20 >= pack_limit)
> bad_object(offset, "object extends past end of pack");
> + memset(delta_base, 0, sizeof(*delta_base));
> hashcpy(delta_base->sha1, pack_base + pos);
Yeah.... but this is a bit wasteful since (especially on 32-bit archs)
you just write to the same memory twice in a row.
Nicolas
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Nicolas Pitre @ 2006-10-17 20:23 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: Junio C Hamano, git
In-Reply-To: <20061017233630.72a0aae5.vsu@altlinux.ru>
On Tue, 17 Oct 2006, Sergey Vlasov wrote:
> On Tue, 17 Oct 2006 14:47:16 -0400 (EDT) Nicolas Pitre wrote:
>
> > Is it possible that sizeof(union delta_base) might not be equal to 20
> > for you?
>
> Yes, on x86_64 this is 24 because of 8-byte alignment for longs:
Ah bummer. Then this is most likely the cause. And here's a simple
fix (Junio please confirm):
diff --git a/index-pack.c b/index-pack.c
index fffddd2..56c590e 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -23,6 +23,12 @@ union delta_base {
unsigned long offset;
};
+/*
+ * Even if sizeof(union delta_base) == 24 on 64-bit archs, we really want
+ * to memcmp() only the first 20 bytes.
+ */
+#define UNION_BASE_SZ 20
+
struct delta_entry
{
struct object_entry *obj;
@@ -211,7 +217,7 @@ static int find_delta(const union delta_
struct delta_entry *delta = &deltas[next];
int cmp;
- cmp = memcmp(base, &delta->base, sizeof(*base));
+ cmp = memcmp(base, &delta->base, UNION_BASE_SZ);
if (!cmp)
return next;
if (cmp < 0) {
@@ -232,9 +238,9 @@ static int find_delta_childs(const union
if (first < 0)
return -1;
- while (first > 0 && !memcmp(&deltas[first - 1].base, base, sizeof(*base)))
+ while (first > 0 && !memcmp(&deltas[first - 1].base, base, UNION_BASE_SZ))
--first;
- while (last < end && !memcmp(&deltas[last + 1].base, base, sizeof(*base)))
+ while (last < end && !memcmp(&deltas[last + 1].base, base, UNION_BASE_SZ))
++last;
*first_index = first;
*last_index = last;
@@ -312,7 +318,7 @@ static int compare_delta_entry(const voi
{
const struct delta_entry *delta_a = a;
const struct delta_entry *delta_b = b;
- return memcmp(&delta_a->base, &delta_b->base, sizeof(union delta_base));
+ return memcmp(&delta_a->base, &delta_b->base, UNION_BASE_SZ);
}
static void parse_pack_objects(void)
Nicolas
^ permalink raw reply related
* Re: heads-up: git-index-pack in "next" is broken
From: Junio C Hamano @ 2006-10-17 20:10 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Sergey Vlasov
In-Reply-To: <20061017233630.72a0aae5.vsu@altlinux.ru>
Sergey Vlasov <vsu@altlinux.ru> writes:
> On Tue, 17 Oct 2006 14:47:16 -0400 (EDT) Nicolas Pitre wrote:
>
>> Is it possible that sizeof(union delta_base) might not be equal to 20
>> for you?
>
> Yes, on x86_64 this is 24 because of 8-byte alignment for longs:
Enough eyeballs made this bug shallow ;-) Thanks.
diff --git a/index-pack.c b/index-pack.c
index fffddd2..49b6efe 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -166,6 +166,7 @@ static void *unpack_raw_entry(unsigned l
case OBJ_REF_DELTA:
if (pos + 20 >= pack_limit)
bad_object(offset, "object extends past end of pack");
+ memset(delta_base, 0, sizeof(*delta_base));
hashcpy(delta_base->sha1, pack_base + pos);
pos += 20;
break;
@@ -290,6 +291,7 @@ static void resolve_delta(struct delta_e
bad_object(obj->offset, "failed to apply delta");
sha1_object(result, result_size, type, obj->sha1);
+ memset(&delta_base, 0, sizeof(delta_base));
hashcpy(delta_base.sha1, obj->sha1);
if (!find_delta_childs(&delta_base, &first, &last)) {
for (j = first; j <= last; j++)
@@ -365,6 +367,7 @@ static void parse_pack_objects(void)
if (obj->type == OBJ_REF_DELTA || obj->type == OBJ_OFS_DELTA)
continue;
+ memset(&base, 0, sizeof(base));
hashcpy(base.sha1, obj->sha1);
ref = !find_delta_childs(&base, &ref_first, &ref_last);
memset(&base, 0, sizeof(base));
^ permalink raw reply related
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-17 20:01 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jakub Narebski, bazaar-ng, git
In-Reply-To: <45349162.90001@op5.se>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andreas Ericsson wrote:
> Aaron Bentley wrote:
>> Ah. Bazaar uses negative numbers to refer to <n>th parents, and
>> positive numbers to refer to the number of commits that have been made
>> since the branch was initialized.
>>
>
> What do you do once a branch has been thrown away, or has had 20 other
> branches merged into it? Does the offset-number change for the revision
> then, or do you track branch-points explicitly?
We always track the number of parents since the initial commit in the
project. Sorry, I don't think I said that clearly before.
>> If I understand correctly, in Bazaar, you'd just merge the current work
>> into 'xx/topic'.
>>
>
> merge != rebase though, although they are indeed similar. Let's take the
> example of a 'master' branch and topic branch topicA. If you rebase
> topicA onto 'master', development will appear to have been serial.
Ah, now I see what you mean, and the "graft" plugin mentioned by others
fills that role. I've never used it, though.
> If
> you instead merge them, it will either register as a real merge or, if
> the branch tip of 'master' is the branch start-point of topicA, it will
> result in a "fast-forward" where 'master' is just updated to the
> branch-tip of 'topicA'.
Interesting. We don't do 'fast-forward' in that case.
>> I'm not sure what you mean by API, unless you mean the commandline. If
>> that's what you mean, surely all unix commands are extensible in that
>> regard.
>>
>
> I'm fairly certain he's talking about the API in the sense it's being
> talked about in every other application. Extensive work has been made to
> libify a lot of the git code, which means that most git commands are
> made up of less than 400 lines of C code, where roughly 80% of the code
> is command-specific (i.e., argument parsing and presentation).
Ah, okay.
So it sounds to me like git is extensible, though not as thoroughly as bzr.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFFNTat0F+nu1YWqI0RAn9aAJ9WzMrM72be+3SlwCpvJXQ/X2Y3nQCfeYk3
NTIJuZSze9URUaAsiO4Hu5o=
=9nvr
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-17 19:51 UTC (permalink / raw)
To: Sean; +Cc: Linus Torvalds, Jakub Narebski, bazaar-ng, git
In-Reply-To: <BAYC1-PASMTP08A746E5FA6B87BC65BD37AE0E0@CEZ.ICE>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sean wrote:
> On Tue, 17 Oct 2006 00:24:15 -0400
> Aaron Bentley <aaron.bentley@utoronto.ca> wrote:
>>- - 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?
By default, they do. You must use a flag to get a checkout with no history.
> So it's not a mirror of a branch, but just a checkout of the
> branch head?
It's a mirror of a branch, and a copy of the branch's working tree.
> If so, Git can export a tarball of a branch (actually a snapshot as at
> any given commit) which can be mirrored out.
Sure, and so can bzr. But using a checkout of the branch head means:
- - No one has to do anything special to provide a working tree of a given
revision
- - I can still run any readonly operations I desire
- - I can update to the latest version of bzr.dev with one command.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFFNTRc0F+nu1YWqI0RAsL2AKCCG0bP8m01WVllfPMzCdFZjmgEgACfeToz
57HERFJ6ZkkS3VrxLRnVPAs=
=3CX7
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-17 19:44 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Linus Torvalds, Jakub Narebski, bazaar-ng, git
In-Reply-To: <4534F133.1090003@op5.se>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andreas Ericsson wrote:
>> In Bazaar, a revision id always refers to the same logical entity, but
>> it may be stored in different formats in different repositories.
>>
>
> This I don't understand. Let's say Alice has revision-154 in her repo,
> located at alice.example.com. Let's say that commit is accessible with
> the url "alice.example.com:revision-154". Bob pulls from her repo into
> his own, which is located at bob.example.com.
>
> Lots of questions here, so I'll split them up. Feel free to delete the
> non-applicable ones.
>
> Will the commit in Bob's repo be accessible at
> "bob.example.com:revision-154"?
bzr differentiates between pull and merge. Pull is a mirroring command.
So with pull, yes revision-154 will be accessible at
bob.example.com:revision-154.
With merge, it won't. Bob can refer to it as "154:alice.example.com",
though.
> If it's not, how can you backtrack from old bugreports and find the
> error being discussed?
Refer to it as 'alice.example.com revno 154' or by its revision-id.
> If it is, how does that work if Bob suddenly wants to commit things
> before Alice is done working with her changes?
I don't see how this applies. You can always commit in a branch. If
alice and bob both commit, then they are diverged and can't pull. If
alice merges bob, then they converge and bob can pull alice.
> Also, suppose they both push to a master-repo where Caesar has pushed
> his changes and nicked the slot for revision-154. Does the master repo
> re-organize everything and then invalidate Bob's and Alice's changes, or
> does it tell Alice and Bob that they need to update and then reorganize
> their repos before they're allowed to push?
They must merge from the master-repo before they can push to it.
>> In our terminology, if it can diverge from the original, it's a branch,
>> not a checkout.
>>
>
> This clears things up immensely. bazaar checkout != git checkout.
> I still fail to see how a local copy you can't commit to is useful
My bzr is run from a local copy I can't commit to. To get the latest
changes from http://bazaar-vcs.org, I can run "bzr update ~/bzr/dev".
To merge the latest changes into my branch, I can run
"bzr merge ~/bzr/dev". It's also convenient for applying other peoples'
patches to.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFFNTKl0F+nu1YWqI0RAhRkAJ0d5KyRElEiFm/m5iRrTIk00RyqywCfe2IY
dhW46SYWm+FTQpN30VY5tPs=
=6SFm
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Sergey Vlasov @ 2006-10-17 19:36 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610171437250.1971@xanadu.home>
[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]
On Tue, 17 Oct 2006 14:47:16 -0400 (EDT) Nicolas Pitre wrote:
> On Tue, 17 Oct 2006, Junio C Hamano wrote:
>
> > Nicolas Pitre <nico@cam.org> writes:
> >
> > > Could you instrument the code at the end of
> > > index-pack.c:parse_pack_objects() to display how many deltas were
> > > actually resolved and how many were not? IOW is it a case of all or
> > > nothing, or is there an isolated case of corruption lurking somewhere?
> >
> > fatal: packfile 'pack-ec0c3491753e115e1775256f6b7bd1bce4dea7cd.pack' has
> > 18915 unresolved ref-deltas and 0 ofs-deltas among 21205
>
> Hmmm.... Interesting.
>
> Is it possible that sizeof(union delta_base) might not be equal to 20
> for you?
Yes, on x86_64 this is 24 because of 8-byte alignment for longs:
$ echo 'unsigned x = sizeof(union{unsigned char sha1[20]; long offset;});' | gcc -S -x c -m64 -o - - | grep long
.long 24
$ echo 'unsigned x = sizeof(union{unsigned char sha1[20]; long offset;});' | gcc -S -x c -m32 -o - - | grep long
.long 20
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-17 19:12 UTC (permalink / raw)
To: git
In-Reply-To: <20061017185225.GE2867@fieldses.org>
J. Bruce Fields wrote:
> On Mon, Oct 16, 2006 at 11:23:53PM -0700, Junio C Hamano wrote:
>> Aaron Bentley <aaron.bentley@utoronto.ca> writes:
>>
>> > Johannes Schindelin wrote:
>> >
>> >>> You'll note we referred to that bevhavior on the page. We don't think
>> >>> what Git does is the same as supporting renames. AIUI, some Git users
>> >>> feel the same way.
>> >>
>> >> Oh, we start another flamewar again?
>> >
>> > I'd hope not. It sounds as though you feel that supporting renames in
>> > the data representation is *wrong*, and therefore it should be an insult
>> > to you if we said that Git fully supported renames.
>>
>> Not recording and not supporting are quite different things.
>
> Yes. There's a risk of confusing a feature with an implementation
> detail. From http://bazaar-vcs.org/RcsComparisons:
>
> "If a user can rename a file in the RCS without loosing the RCS
> history for a file, then renames are considered supported. If
> the operation resultes in a delete/add (aka "DA pair"), then
> renames are not considered supported. If the operation results
> in a copy/delete pair, renames are considered "somewhat"
> supported. The problem with copy support is that it is hard to
> define sane merge semantics for copies."
>
> The first sentence sounds like a description of a user-visible feature.
> The rest of it sounds like implementation.
The proper description would be: if we get history of file up to rename
unrelated to the history of file before rename ("DA pair"), where
"unrelated" means that SCM doesn't store this relation (or equivalent
information), renames are not considered supported. If we get full
history of file under new name, and unrelated history of file up to rename
("CD pair"), renames are not considered supported ;-)
> And git probably has some deficiencies here, but it'd be more useful to
> identify them in terms of things a user can't do.
For example:
* if we rename (or delete) file on one branch, and then merge changes
with other branch where such rename didn't make place, do merge do
the correct thing.
* can we get whole history of file, before and after rename. Can we do
this automatically, in one go.
* do renames are (can be) marked as such in diff output.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's in git.git
From: Andy Whitcroft @ 2006-10-17 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v64eikdp2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> There's two things to note about this:
>>
>> - the libxdiff dependencies are broken, so it's likely that you need to
>> do a "make clean; make" to actually see the result of this.
>
> Eh, stupid-and-obvious like this perhaps.
>
> ---
>
> diff --git a/Makefile b/Makefile
> index 2c7c338..3fed480 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -237,6 +237,7 @@ PYMODULES = \
>
> LIB_FILE=libgit.a
> XDIFF_LIB=xdiff/lib.a
> +$(XDIFF_LIB): $(wildcard xdiff/*.[ch])
To combine your more succinct style with my previous patch, its the link
between the .o's and the .h's thats missing.
$(XDIFF_OBJS): $(wildcard xdiff/*.h)
-apw
^ permalink raw reply
* Re: What's in git.git
From: Linus Torvalds @ 2006-10-17 18:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64eikdp2.fsf@assigned-by-dhcp.cox.net>
On Tue, 17 Oct 2006, Junio C Hamano wrote:
>
> Eh, stupid-and-obvious like this perhaps.
I'm not convinced that is enough. You need to make the individual
xdiff/*.c files depend on the xdiff/*.h files, because otherwise it will
think that the *.o files are up-to-date and just re-link the archive.
The kernel does automatic dependency generation for all the *.c files, and
it's _really_ nice. Having to do dependencies by hand is just always going
to suck. But the kernel can depend on more things (in particular, the
kernel can depend on gcc, and use things like "-MD,$(depfile)" to generate
lists of dependencies while building, so that any object file _always_ has
the things it depended upn explicitly listed).
But in the absense of those kinds of really clever and powerful tricks, it
might be worthwhile to even just have a "mkdepend" scrupt thing and
include the end result into the Makefile (we do already depend on GNU
make).
That would allow us to get the real dependencies (and minimal! right now
we sometimes compile too _much_ just because some of our dependencies are
so screwed up and lazy).
Linus
^ 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