* [PATCH 7/8] Make O(n) algorithm the default implementation of --bisect [rev 2]
From: Jon Seymour @ 2005-07-02 5:38 UTC (permalink / raw)
To: git; +Cc: torvalds, jon.seymour
This patch makes the O(n) the default implementation of the git-rev-list
--bisect switch.
The original O(n^2) algorithm is still available as --bisect-orig.
It is left around to provide a quick and simple way to verify the
accuracy of the O(n) algorithm.
A subsequent patch is supplied to remove support for --bisect-orig
completely.
Signed-off: Jon Seymour <jon.seymour@gmail.com>
---
Linus: you may choose to defer application of this patch if you are
not confident that the O(n) algorithm is good.
[rev 2]
* included necessary change to t/t6002... that was accidentally
ommitted on the first attempt.
The patch series to be applied is now:
[PATCH 1/8] Factor out useful test case infrastructure from t/t6001... into t/t6000-lib.sh
[PATCH 2/8] Introduce unit tests for git-rev-list --bisect
[PATCH 3/8] Add a topological sort procedure to commit.c [rev 3]
[PATCH 4/8] This patch introduces a O(n) bisection algorithm to git.
[PATCH 5/8] Removes DEBUG code from rev-list.c and -DDEBUG from Makefile
[PATCH 6/8] Move bisection algorithms into commit.c
[PATCH 7/8] Make O(n) algorithm the default implementation of --bisect [rev 2]
[PATCH 8/8] Removes support for O(n^2) algorithm from git-rev-list completely [rev 2]
[PATCH] Change the sed seperator in t/t6000-lib.sh
---
rev-list.c | 5 +++--
t/t6002-rev-list-bisect.sh | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
203e690e7d7a2aa75f0336744dc6b4455ad51844
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -16,6 +16,7 @@ static const char rev_list_usage[] =
" --min-age=epoch\n"
" --header\n"
" --pretty\n"
+ " --bisect\n"
" --merge-order [ --show-breaks ]";
static int bisect_list = 0;
@@ -365,11 +366,11 @@ int main(int argc, char **argv)
show_parents = 1;
continue;
}
- if (!strcmp(arg, "--bisect-by-cut")) {
+ if (!strcmp(arg, "--bisect")) {
bisect_by_cut_option = 1;
continue;
}
- if (!strcmp(arg, "--bisect")) {
+ if (!strcmp(arg, "--bisect-orig")) {
bisect_list = 1;
continue;
}
diff --git a/t/t6002-rev-list-bisect.sh b/t/t6002-rev-list-bisect.sh
--- a/t/t6002-rev-list-bisect.sh
+++ b/t/t6002-rev-list-bisect.sh
@@ -241,7 +241,7 @@ EOF
}
test_sequence "--bisect"
-test_sequence "--bisect-by-cut"
+test_sequence "--bisect-orig"
#
#
------------
^ permalink raw reply
* Re: "git-send-pack"
From: H. Peter Anvin @ 2005-07-02 4:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Mike Taht, Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0507012119360.3019@ppc970.osdl.org>
Linus Torvalds wrote:
>
> On Fri, 1 Jul 2005, H. Peter Anvin wrote:
>
>>Any reason not to simply append objects to an existing packfile?
>
>
> What happens when somebody screws up in the middle?
>
> The one thing I care about more than anything else is consistency. We are
> careful about writing objects in the right order, and we can re-create the
> state from the originator etc. But if we start appending stuff and
> something goes wrong in the middle, I'm just not going to touch it. A
> "truncate and hope for the best" algorithm?
>
> Besides, the result is not a valid git archive any more.
>
It's a log. It's a standard technique to append entries to a log. The
requirements for this to always be consistent is that a) it's possible
to know when the entry/entries at the end are inconsistent and b) it's
always possible to roll back the log to a consistent state.
This is normally done with commit records (write data - fdatasync -
write commit record - fdatasync), but in the case of git, the commit
record isn't required because each git record is self-validating. This
is an incredibly powerful property.
If the log is written in topological sort order, then even a truncated
log file is a valid (subset) git object store.
-hpa
^ permalink raw reply
* Re: "git-send-pack"
From: Linus Torvalds @ 2005-07-02 4:22 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Mike Taht, Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <42C61351.10306@zytor.com>
On Fri, 1 Jul 2005, H. Peter Anvin wrote:
>
> Any reason not to simply append objects to an existing packfile?
What happens when somebody screws up in the middle?
The one thing I care about more than anything else is consistency. We are
careful about writing objects in the right order, and we can re-create the
state from the originator etc. But if we start appending stuff and
something goes wrong in the middle, I'm just not going to touch it. A
"truncate and hope for the best" algorithm?
Besides, the result is not a valid git archive any more.
Linus
^ permalink raw reply
* Re: "git-send-pack"
From: H. Peter Anvin @ 2005-07-02 4:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Mike Taht, Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0507011831060.2977@ppc970.osdl.org>
Linus Torvalds wrote:
>
> Also, the number of people involved isn't _that_ big. We're talking a few
> thousand people who actively would update their trees for a big project,
> and many smaller projects have anything from a couple to maybe a hundred.
> A few mirrors, and you don't have any problem.
>
> So I think that the problem is actually not that big, and we just need to
> find an acceptable format. Quite frankly, it might be perfectly acceptable
> for kernel.org to run a simple packing script once a week which packs
> everything into one single file, and even if that means that the mirrors
> will have to re-get everything once a week, that actually sounds
> acceptable.
>
> It's obviously a _stupid_ way to handle the rsync problem, so there's
> bound to be some cleaner solution, but the point is that we can probably
> make mirroring acceptable even with a really really stupid approach. I'd
> be a bit ashamed of just how ugly it is, but it would likely _work_ fine.
> You'd create 52 pack-files in a year, but each pack-file is likely just
> ten megabytes each.
>
Any reason not to simply append objects to an existing packfile? It
really seems like an easy solutions, and should have relatively good I/O
patterns to boot simply because it naturally creates a topological sort
of the objects.
-hpa
^ permalink raw reply
* Re: "git-send-pack"
From: Linus Torvalds @ 2005-07-02 1:56 UTC (permalink / raw)
To: Mike Taht; +Cc: H. Peter Anvin, Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <42C5D553.80905@timesys.com>
On Fri, 1 Jul 2005, Mike Taht wrote:
>
> You are getting closer and closer to where something like bitTorrent or
> a multicast protocol makes sense. The problem isn't just the number of
> outstanding commit objects but the number of machines and developers
> that want to grab those commits at the same time.
I don't think so. First off, I don't think the decision is kernel-
specific, in the sense that I at least use git for sparse and git itself
too, so the solution should make sense for small projects as well.
Also, even for the kernel, the total dataset right now (after three months
or whatever) is a 60MB pack. It's not like we're sending DVD's or even
CD's worth of data around - we're sending the equivalent of 20MB per
_month_. That's really not a lot of data. You could easily keep up with a
slow modem.
Also, the number of people involved isn't _that_ big. We're talking a few
thousand people who actively would update their trees for a big project,
and many smaller projects have anything from a couple to maybe a hundred.
A few mirrors, and you don't have any problem.
So I think that the problem is actually not that big, and we just need to
find an acceptable format. Quite frankly, it might be perfectly acceptable
for kernel.org to run a simple packing script once a week which packs
everything into one single file, and even if that means that the mirrors
will have to re-get everything once a week, that actually sounds
acceptable.
It's obviously a _stupid_ way to handle the rsync problem, so there's
bound to be some cleaner solution, but the point is that we can probably
make mirroring acceptable even with a really really stupid approach. I'd
be a bit ashamed of just how ugly it is, but it would likely _work_ fine.
You'd create 52 pack-files in a year, but each pack-file is likely just
ten megabytes each.
Oh, each pack-file should also be associated with the list of "refs" that
were used to generate that pack-file, so make that 104 files per project
year (but the list of "refs" would usually be something small, like
refs/heads/master 4a89a04f1ee21a7c1f4413f1ad7dcfac50ff9b63
refs/tags/v2.6.11 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c
refs/tags/v2.6.11-tree 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c
refs/tags/v2.6.12 26791a8bcf0e6d33f43aef7682bdb555236d56de
refs/tags/v2.6.12-rc2 9e734775f7c22d2f89943ad6c745571f1930105f
refs/tags/v2.6.12-rc3 0397236d43e48e821cce5bbe6a80a1a56bb7cc3a
refs/tags/v2.6.12-rc4 ebb5573ea8beaf000d4833735f3e53acb9af844c
refs/tags/v2.6.12-rc5 06f6d9e2f140466eeb41e494e14167f90210f89d
refs/tags/v2.6.12-rc6 701d7ecec3e0c6b4ab9bb824fd2b34be4da63b7e
refs/tags/v2.6.13-rc1 733ad933f62e82ebc92fed988c7f0795e64dea62
which was trivially generated from my current tree with
for i in refs/*/*; do echo -ne $i"\t"; cat $i; done
so now you can use the refs associated with the previous pack-file as the
list of refs you're _not_ interested in, and the current list of refs as
the list you _are_ interested in, and generate the new pack-file.
Generating the pack-file would literally be something like
obj=$(git-rev-parse $(cut -f2 new-list) --not $(cut -f2 old-list))
git-rev-list $obj | git-pack-objects --stdin > new-pack
so a few one-liners like this, run from a cron-job once a week, should
just do it.
Linus
^ permalink raw reply
* Re: "git-send-pack"
From: H. Peter Anvin @ 2005-07-02 0:07 UTC (permalink / raw)
To: Mike Taht; +Cc: Linus Torvalds, Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <42C5D553.80905@timesys.com>
Mike Taht wrote:
>
> You are getting closer and closer to where something like bitTorrent or
> a multicast protocol makes sense. The problem isn't just the number of
> outstanding commit objects but the number of machines and developers
> that want to grab those commits at the same time.
>
Not really.
-hpa
^ permalink raw reply
* Re: Tags
From: H. Peter Anvin @ 2005-07-02 0:06 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Linus Torvalds, Daniel Barkalow, Git Mailing List, Junio C Hamano,
ftpadmin
In-Reply-To: <m1ll4qf7mg.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
>
> If I really care what developer xyz tagged I will pull from them,
> or a mirror I trust. And since developer xyz doesn't pull his
> own global tags from other repositories that should be sufficient.
>
You're missing something totally and utterly fundamental here: I'm
talking about creating an infrastructure (think sourceforge) where there
is only one git repository for the whole system, period, full stop, end
of story.
-hpa
^ permalink raw reply
* Re: "git-send-pack"
From: Mike Taht @ 2005-07-01 23:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: H. Peter Anvin, Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0506301656570.14331@ppc970.osdl.org>
Linus Torvalds wrote:
> Also, note that the server is usually _more_ ahead than the client is, and
> the server is the one that potentially has lots of commits that the
> client doesn't have. Not the other way around. So if the client makes a
> list of it's top commits, it almost certainly won't have to make a very
> long list until the server can tell it "ok, stop, I've seen it".
>
> Yeah, maybe we want to limit the "burst" to 70 sha1's, since that will fit
> in a regular-sized ethernet packet, but whatever - you'd burst out your
> commits "latest first", so you'd never even get to the current 4040 unless
> you've literally done the kind of work we've done in the git tree for the
> last 3 months _and_you've_not_pulled_from_that_server_in_the_whole_time_.
You are getting closer and closer to where something like bitTorrent or
a multicast protocol makes sense. The problem isn't just the number of
outstanding commit objects but the number of machines and developers
that want to grab those commits at the same time.
Mike Taht
PostCards From The Bleeding Edge
http://the-edge.blogspot.com "Tempel 1 worth 2.2 million trillion bux"
^ permalink raw reply
* Re: Tags
From: Daniel Barkalow @ 2005-07-01 23:22 UTC (permalink / raw)
To: Eric W. Biederman
Cc: H. Peter Anvin, Linus Torvalds, Git Mailing List, Junio C Hamano,
ftpadmin
In-Reply-To: <m1ll4qf7mg.fsf@ebiederm.dsl.xmission.com>
On Fri, 1 Jul 2005, Eric W. Biederman wrote:
> Plus if you pull from a spoofed tag somewhere further along
> when you merge your code the merge will fail because what
> you thought was a common ancestor isn't. And you will
> also likely get an error when you have the same tag
> coming from 2 different sources with different values.
Actually, I think it would be beneficial to support multiple tags with the
same name in any case: if people are going to use local private tags like
"broken", either we need to support having refs/tags/broken being a list
of hashes, or any particular user can only have one broken version.
I don't see any major problems with having refs/ files contain potentially
multiple hashes (limited by what makes sense to be multiple; i.e., heads/*
should have only one value), and this lets the users check the content of
the tag objects to figure out what they care about, and either specify
things in more detail or discard things they don't like (or, when
appropriate, use all values). The main issue I see is that rsync wouldn't
merge them usefully.
(And it would be useful to have a structure to support keeping a simple
piece of information about a set of objects.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Tags
From: Eric W. Biederman @ 2005-07-01 23:07 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Daniel Barkalow, Git Mailing List, Junio C Hamano,
ftpadmin
In-Reply-To: <42C5C75F.4040100@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Eric W. Biederman wrote:
>> There is a question of how bad is this. For releases you certainly
>> need some kind of signature that people can verify and we
>> already have that but I think we can keep spoofing tags
>> down to the same level as spoofing patches.
>> Basically all this takes is to make your global namespace
>> the committer email address and you have the rule that
>> you can only tag your own commits. Then when you merge
>> tags you never automatically add tags to your own tag namespace.
>>
>
> Doesn't work. You can trivially generate a key with someone else's address. It
> would require a full PKI.
I'm not saying it's provable correct. I'm simply saying it is as
correct as the rest of the git repository.
If I really care what developer xyz tagged I will pull from them,
or a mirror I trust. And since developer xyz doesn't pull his
own global tags from other repositories that should be sufficient.
Plus if you pull from a spoofed tag somewhere further along
when you merge your code the merge will fail because what
you thought was a common ancestor isn't. And you will
also likely get an error when you have the same tag
coming from 2 different sources with different values.
So all I am really arguing is that using the committer
email address is simply sufficient to prevent non-malicious
conflicts between developers, and it makes it enough
that to get a malicious conflict isn't completely trivial.
So I think it is good enough.
But for releases and things lots of people must trust yes you want
a full PKI infrastructure but I don't see a reason any of that
should be inherently tied to tags.
Eric
^ permalink raw reply
* Re: Tags
From: Petr Baudis @ 2005-07-01 22:59 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Eric W. Biederman, Linus Torvalds, Daniel Barkalow,
Git Mailing List, Junio C Hamano, ftpadmin
In-Reply-To: <42C5BB33.5010304@zytor.com>
Dear diary, on Fri, Jul 01, 2005 at 11:52:51PM CEST, I got a letter
where "H. Peter Anvin" <hpa@zytor.com> told me that...
> You're missing the whole point of the discussion. Right now the only
> thing that makes a global object store impossible is the potential for a
> tag conflict, either intentional or accidental.
Ok, I was arguing about something a bit different here, sorry.
The point of refs/tags/ should be to just indicate tags which we have in
the current head (remember that this structure comes from the times
before Dave, when the repository:"master branch" mapping was 1:1), since
that are usually the only objects you have in _your_ repository. What's
the point of having tag linux-1.0.4-ac128 when you don't have the
linux-1.0.4-ac branch whatsoever? The distinction of "public" vs
"private" tags here is really only that the "public" tags should be
propagated to your head when you merge the remote head. This way, each
head will have its own set of tags, and it will be only tags which
actually reference objects relevant to the head.
Now that we can have many branches in a repository, each with its own
set of tags, we should probably extend the tags hierarchy to
refs/tags/<head>/<tagname>. And see, you can actually have that in the
global object store, as long as the head names are unique. But heads
don't propagate in any way so that's a purely administrative issue on
the global store side.
BTW, I don't think many (most?) heads named "master" are big issue.
That's how the head is called locally, and noone says that's how the
head should be known at the other side too. It's fine to have a head
called "master" in your repository and when pushing to the global object
store call it "pasky/linux-l33t" over there. (If you are using Cogito,
you can add that branch using a URL
proto://global/obj/store#pasky/linux-l33t.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: Tags
From: H. Peter Anvin @ 2005-07-01 22:44 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Linus Torvalds, Daniel Barkalow, Git Mailing List, Junio C Hamano,
ftpadmin
In-Reply-To: <m1u0jef8z9.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
>
> There is a question of how bad is this. For releases you certainly
> need some kind of signature that people can verify and we
> already have that but I think we can keep spoofing tags
> down to the same level as spoofing patches.
>
> Basically all this takes is to make your global namespace
> the committer email address and you have the rule that
> you can only tag your own commits. Then when you merge
> tags you never automatically add tags to your own tag namespace.
>
Doesn't work. You can trivially generate a key with someone else's
address. It would require a full PKI.
-hpa
^ permalink raw reply
* Re: Tags
From: Eric W. Biederman @ 2005-07-01 22:38 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Daniel Barkalow, Git Mailing List, Junio C Hamano,
ftpadmin
In-Reply-To: <42C5714A.1020203@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Eric W. Biederman wrote:
>> "H. Peter Anvin" <hpa@zytor.com> writes:
>>
> Unless you have an authentication mechanism and *enforce* it (you can do that
> with GPG signatures if *and only if* your disambiguation includes your GPG
> signature fingerprint) you still have a problem with someone introducing fake
> tags as a DoS attack.
There is a question of how bad is this. For releases you certainly
need some kind of signature that people can verify and we
already have that but I think we can keep spoofing tags
down to the same level as spoofing patches.
Basically all this takes is to make your global namespace
the committer email address and you have the rule that
you can only tag your own commits. Then when you merge
tags you never automatically add tags to your own tag namespace.
I think that is enough to make global tags usable in practice.
And for those who are typing challenged if all you ever
look at are your own tags the you should never need to
specify a fully qualified tag name as git should be able
to find the committer email address through other means.
Eric
^ permalink raw reply
* Re: Tags
From: Daniel Barkalow @ 2005-07-01 22:27 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Petr Baudis, Eric W. Biederman, Linus Torvalds, Git Mailing List,
Junio C Hamano, ftpadmin
In-Reply-To: <42C5BB33.5010304@zytor.com>
On Fri, 1 Jul 2005, H. Peter Anvin wrote:
> You're missing the whole point of the discussion. Right now the only
> thing that makes a global object store impossible is the potential for a
> tag conflict, either intentional or accidental.
Is there some issue remaining with having a global *object* store,
symlinked from multiple repositories, each with its own tags and
such? (I'd think that, in the refs, there would be more contention over
the heads than the tags, in any case; refs/heads/master is kind of
popular)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Tags
From: H. Peter Anvin @ 2005-07-01 21:52 UTC (permalink / raw)
To: Petr Baudis
Cc: Eric W. Biederman, Linus Torvalds, Daniel Barkalow,
Git Mailing List, Junio C Hamano, ftpadmin
In-Reply-To: <20050701214230.GA22003@pasky.ji.cz>
Petr Baudis wrote:
>
> I doubt that's really useful either. Rather artificial mechanisms for
> protection of the namespace would have to be deployed, and again, what
> would it be good for anyway? If you are tagging linux-2.m.n, you are
> probably whoever you should be - David, Alan, Marcelo, Linus, or whoever
> else, while if you are tagging linux-2.m.n-cki, you are likely Con
> Kolivas. I don't believe there is any (or much) potential for "natural"
> conflicts and if you are malicious, you will just fake the namespace;
> but frequently what's interesting about the tags is not the author at
> all - I would consider it confusing to have to suddenly dive to another
> namespace when Linus hands maintenance of linux-2.m to someone else.
>
> The only significant value I can therefore see in the namespaces is
> prevention of user mistakes, but I think the successful strategy here
> would be just "upstream will notice", and make sure the upstream will be
> noticed properly (perhaps even interactively) about any new tags it
> gets.
>
> Ok, I admit that it boils down to me being lazy and that "it'd be more
> typing!"... ;-)
>
You're missing the whole point of the discussion. Right now the only
thing that makes a global object store impossible is the potential for a
tag conflict, either intentional or accidental.
-hpa
^ permalink raw reply
* Re: Tags
From: Petr Baudis @ 2005-07-01 21:42 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Eric W. Biederman, Linus Torvalds, Daniel Barkalow,
Git Mailing List, Junio C Hamano, ftpadmin
In-Reply-To: <42C58D83.9060107@zytor.com>
Dear diary, on Fri, Jul 01, 2005 at 08:37:55PM CEST, I got a letter
where "H. Peter Anvin" <hpa@zytor.com> told me that...
> Petr Baudis wrote:
> >Dear diary, on Fri, Jul 01, 2005 at 03:56:06PM CEST, I got a letter
> >where "Eric W. Biederman" <ebiederm@xmission.com> told me that...
> >
> >>"H. Peter Anvin" <hpa@zytor.com> writes:
> >>
> >>
> >>>In the end, it might be that the right thing to do for git on kernel.org
> >>>is to
> >>>have a single, unified object store which isn't accessible by anything
> >>>other
> >>>than git-specific protocols. There would have to be some way of dealing
> >>>with,
> >>>for example, conflicting tags that apply to different repositories,
> >>>though.
> >>
> >>As far as I can tell public distributed tags are not that hard and if
> >>you are going to be synching them it is probably worth working on.
> >>
> >>The basic idea is that instead of having one global tag of
> >>'linux-2.6.13-rc1' you have a global tag of
> >>'torvalds@osdl.org/linux-2.6.13-rc1'.
> >>
> >>The important part is that the tag namespace is made hierarchical
> >>with at least 2 levels. Where the top level is a globally
> >>unique tag owner id and the bottom level is the actual tag. This
> >>prevents collisions when merging trees because two peoples
> >>tags are never in the same namespace, as least when
> >>people are not actively hostile :)
> >
> >
> >I don't know, I don't consider this very appealing myself. I'd rather
> >prefer the private tags to be per-repository rather than per-user, since
> >those ugly "merged-here", "broken" etc. tags aren't very useful on
> >larger scope than of a repository. OTOH, what tags would be per-user,
> >not per-repository and not global?
> >
>
> He's talking about global tags, just using a "globally unique"
> namespace. Which of course only works right if only genuinely can't
> create tags outside your assigned namespace.
I doubt that's really useful either. Rather artificial mechanisms for
protection of the namespace would have to be deployed, and again, what
would it be good for anyway? If you are tagging linux-2.m.n, you are
probably whoever you should be - David, Alan, Marcelo, Linus, or whoever
else, while if you are tagging linux-2.m.n-cki, you are likely Con
Kolivas. I don't believe there is any (or much) potential for "natural"
conflicts and if you are malicious, you will just fake the namespace;
but frequently what's interesting about the tags is not the author at
all - I would consider it confusing to have to suddenly dive to another
namespace when Linus hands maintenance of linux-2.m to someone else.
The only significant value I can therefore see in the namespaces is
prevention of user mistakes, but I think the successful strategy here
would be just "upstream will notice", and make sure the upstream will be
noticed properly (perhaps even interactively) about any new tags it
gets.
Ok, I admit that it boils down to me being lazy and that "it'd be more
typing!"... ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: Tags
From: Matthias Urlichs @ 2005-07-01 21:20 UTC (permalink / raw)
To: git
In-Reply-To: <42C58D83.9060107@zytor.com>
Hi, H. Peter Anvin wrote:
> Which of course only works right if only genuinely can't
> create tags outside your assigned namespace.
I'd rather say that you can't *push* the tags to the central server if
their namspace is wrong, but nothing would prevent you from *creating*
arbitrary tags in your own repository.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Habit is habit, and not to be flung out of the window by any man, but coaxed
down-stairs a step at a time.
-- Mark Twain
^ permalink raw reply
* Re: Tags
From: H. Peter Anvin @ 2005-07-01 18:37 UTC (permalink / raw)
To: Petr Baudis
Cc: Eric W. Biederman, Linus Torvalds, Daniel Barkalow,
Git Mailing List, Junio C Hamano, ftpadmin
In-Reply-To: <20050701180944.GA14375@pasky.ji.cz>
Petr Baudis wrote:
> Dear diary, on Fri, Jul 01, 2005 at 03:56:06PM CEST, I got a letter
> where "Eric W. Biederman" <ebiederm@xmission.com> told me that...
>
>>"H. Peter Anvin" <hpa@zytor.com> writes:
>>
>>
>>>In the end, it might be that the right thing to do for git on kernel.org is to
>>>have a single, unified object store which isn't accessible by anything other
>>>than git-specific protocols. There would have to be some way of dealing with,
>>>for example, conflicting tags that apply to different repositories, though.
>>
>>As far as I can tell public distributed tags are not that hard and if
>>you are going to be synching them it is probably worth working on.
>>
>>The basic idea is that instead of having one global tag of
>>'linux-2.6.13-rc1' you have a global tag of
>>'torvalds@osdl.org/linux-2.6.13-rc1'.
>>
>>The important part is that the tag namespace is made hierarchical
>>with at least 2 levels. Where the top level is a globally
>>unique tag owner id and the bottom level is the actual tag. This
>>prevents collisions when merging trees because two peoples
>>tags are never in the same namespace, as least when
>>people are not actively hostile :)
>
>
> I don't know, I don't consider this very appealing myself. I'd rather
> prefer the private tags to be per-repository rather than per-user, since
> those ugly "merged-here", "broken" etc. tags aren't very useful on
> larger scope than of a repository. OTOH, what tags would be per-user,
> not per-repository and not global?
>
He's talking about global tags, just using a "globally unique"
namespace. Which of course only works right if only genuinely can't
create tags outside your assigned namespace.
-hpa
^ permalink raw reply
* Re: Tags
From: Petr Baudis @ 2005-07-01 18:09 UTC (permalink / raw)
To: Eric W. Biederman
Cc: H. Peter Anvin, Linus Torvalds, Daniel Barkalow, Git Mailing List,
Junio C Hamano, ftpadmin
In-Reply-To: <m13bqyk4uh.fsf_-_@ebiederm.dsl.xmission.com>
Dear diary, on Fri, Jul 01, 2005 at 03:56:06PM CEST, I got a letter
where "Eric W. Biederman" <ebiederm@xmission.com> told me that...
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
> > In the end, it might be that the right thing to do for git on kernel.org is to
> > have a single, unified object store which isn't accessible by anything other
> > than git-specific protocols. There would have to be some way of dealing with,
> > for example, conflicting tags that apply to different repositories, though.
>
> As far as I can tell public distributed tags are not that hard and if
> you are going to be synching them it is probably worth working on.
>
> The basic idea is that instead of having one global tag of
> 'linux-2.6.13-rc1' you have a global tag of
> 'torvalds@osdl.org/linux-2.6.13-rc1'.
>
> The important part is that the tag namespace is made hierarchical
> with at least 2 levels. Where the top level is a globally
> unique tag owner id and the bottom level is the actual tag. This
> prevents collisions when merging trees because two peoples
> tags are never in the same namespace, as least when
> people are not actively hostile :)
I don't know, I don't consider this very appealing myself. I'd rather
prefer the private tags to be per-repository rather than per-user, since
those ugly "merged-here", "broken" etc. tags aren't very useful on
larger scope than of a repository. OTOH, what tags would be per-user,
not per-repository and not global?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: Tags
From: H. Peter Anvin @ 2005-07-01 16:37 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Linus Torvalds, Daniel Barkalow, Git Mailing List, Junio C Hamano,
ftpadmin
In-Reply-To: <m13bqyk4uh.fsf_-_@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>
>>In the end, it might be that the right thing to do for git on kernel.org is to
>>have a single, unified object store which isn't accessible by anything other
>>than git-specific protocols. There would have to be some way of dealing with,
>>for example, conflicting tags that apply to different repositories, though.
>
>
> As far as I can tell public distributed tags are not that hard and if
> you are going to be synching them it is probably worth working on.
>
> The basic idea is that instead of having one global tag of
> 'linux-2.6.13-rc1' you have a global tag of
> 'torvalds@osdl.org/linux-2.6.13-rc1'.
>
> The important part is that the tag namespace is made hierarchical
> with at least 2 levels. Where the top level is a globally
> unique tag owner id and the bottom level is the actual tag. This
> prevents collisions when merging trees because two peoples
> tags are never in the same namespace, as least when
> people are not actively hostile :)
>
> Still being a complete git dummy I think the trivial mapping is
> to put tags in:
> .git/refs/tags/user@domain/tag
> and then have a symlink at:
> .git/TAGS
> that points to your default directory of tags.
>
Unless you have an authentication mechanism and *enforce* it (you can do
that with GPG signatures if *and only if* your disambiguation includes
your GPG signature fingerprint) you still have a problem with someone
introducing fake tags as a DoS attack.
-hpa
^ permalink raw reply
* Re: [PATCH] Trivial sed fix up in t/t6001
From: Jon Seymour @ 2005-07-01 15:51 UTC (permalink / raw)
To: Mark Allen; +Cc: torvalds, git
In-Reply-To: <20050701135516.87892.qmail@web41208.mail.yahoo.com>
On 7/1/05, Mark Allen <mrallen1@yahoo.com> wrote:
> Change the sed seperator in t/t6001.
>
> This trivial patch removes the semicolon as the sed seperator in the t/t6001 test script
> and replaces it with white space. This makes BSD sed(1) much happier.
>
> Signed-off-by: Mark Allen <mrallen1@yahoo.com>
>
> ===
>
> Jon,
>
> If you could ack this patch or incorporate it into your tree, I'd be very obliged.
>
> Thanks,
>
> --Mark
Ack'd. I have also re-applied it to the code I moved into
t/t6000-lib.sh in my recent patch series, so it is fit to go in one
way or another!
jon.
^ permalink raw reply
* Re: [PATCH] pack-objects: emit base before delta.
From: Junio C Hamano @ 2005-07-01 15:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507010821140.14331@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> So I like this from an unpacking standpoint, but at the same
LT> time I don't actually think it's correct from an access
LT> pattern standpoint.
My faulty logic, when I did the patch, was "we would jump around
on random access anyway, so forcing the runtime to go backwards
even when we know that these 40 objects are followed in this
exact order to resolve delta is also OK." It is not.
Please drop the patch.
^ permalink raw reply
* Re: [PATCH] pack-objects: emit base before delta.
From: Linus Torvalds @ 2005-07-01 15:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbr5nxe38.fsf@assigned-by-dhcp.cox.net>
On Thu, 30 Jun 2005, Junio C Hamano wrote:
>
> This micro-optimizes the order of objects in a pack. By
> emitting base objects before deltified ones, unpack-objects do
> not keep items on delta_list.
So I like this from an unpacking standpoint, but at the same time I don't
actually think it's correct from an access pattern standpoint.
When using a pack file as a run-time object store, the current packing
order means that we generally traverse the pack-file in a nice forward
direction. We don't jump backwards in the file very much, which should be
good both for CPU and disk caches (both of them tend to have prefetch
logic that often works better for nice access patterns). So I was actually
pretty happy with the fact that we packed "optimally" in this sense: if
the object was an important delta (ie an early one), we'd basically end up
always walking forward until we hit the object it was a delta against.
I dunno. Maybe it doesn't matter. Our other heuristics to pack recent
objects before later one might mean that we tend to have mainly
backwards-going deltas (both in history _and_ in pack file layout).
The expense of keeping track of delta objects isn't that high, and the
"pending delta" logic in unpack-objects isn't that complicated, so ..
Do you have some other reason you want to do this?
Linus
^ permalink raw reply
* [PATCH] Change the sed seperator in t/t6000-lib.sh.
From: Jon Seymour @ 2005-07-01 15:02 UTC (permalink / raw)
To: git; +Cc: torvalds, jon.seymour
This trivial patch removes the semicolon as the sed seperator in the t/t6000-lib.sh test script
and replaces it with white space. This makes BSD sed(1) much happier.
Signed-off-by: Mark Allen <mrallen1@yahoo.com>
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
I've applied this to the code that was moved from t/t6001... into t/t6000-lib.sh
---
t/t6000-lib.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
d88e09bab26e42f0777b4244a62b21c37c01ceea
diff --git a/t/t6000-lib.sh b/t/t6000-lib.sh
--- a/t/t6000-lib.sh
+++ b/t/t6000-lib.sh
@@ -28,7 +28,9 @@ save_tag()
[ -n "$_tag" ] || error "usage: save_tag tag commit-args ..."
shift 1
"$@" >.git/refs/tags/$_tag
- sed_script="s/$(tag $_tag)/$_tag/g${sed_script+;}$sed_script"
+
+ sed_script="s/$(tag $_tag)/$_tag/g
+$sed_script"
}
# Replace unhelpful sha1 hashses with their symbolic equivalents
------------
^ permalink raw reply
* Re: OOPS: unnumbered patch series
From: Jon Seymour @ 2005-07-01 14:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vvf3vvwkh.fsf@assigned-by-dhcp.cox.net>
On 7/1/05, Junio C Hamano <junkio@cox.net> wrote:
> >>>>> "JS" == Jon Seymour <jon.seymour@gmail.com> writes:
>
> JS> Junio: this is an example where the special case would be good.
>
> I do not think -n would number [PATCH 1/1]. Please try it and
> complain loudly if that does not work for you.
>
Apologises loudly :-)
jon.
^ 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