* Re: Tags
From: Petr Baudis @ 2005-07-02 22:14 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Eric W. Biederman, Daniel Barkalow,
Git Mailing List, Junio C Hamano, ftpadmin
In-Reply-To: <42C70A5B.9070606@zytor.com>
Dear diary, on Sat, Jul 02, 2005 at 11:42:51PM CEST, I got a letter
where "H. Peter Anvin" <hpa@zytor.com> told me that...
> Linus Torvalds wrote:
> >
> >Note that the fact that you use a common object store does not mean that
> >everything should be common.
\o/ Finally I have some hope that we don't end up with something
braindead w.r.t. the tags... ;-)
..snip..
> OK, so let me retell what I think I hear you say:
>
> - Store all the tags in the object store; they may conflict.
They may have the same "human-readable name", but they will have a
different hash.
> - Let each source user have a set of refs, and provide a method for the
> end user to select which refs to get.
>
> In other words, the only way (other than knowing what GPG keys to trust)
> to distinguish between your "v2.6.12" and J. Random Hacker's "v2.6.12"
> is that the former is referenced by *your* refs as opposed to JRH's
> refs.
After all, this is the best way to distinguish it, isn't it? Just "tag
name" without a name of the branch the tag concerns makes no sense -
that's the point I'm trying to get along. JRH's v2.6.12 wouldn't make
much sense to you if you use Linus' v2.6.12, since the object JRH's
v2.6.12 references simply may not be in the branch you use. Yes, JRH
could tag it somewhere in the common past, but that's kind of strange
and is likely some private JRH's stuff. If Linus merged JRH, he will
take his v2.6.12 if it makes sense in his branch - so the decision
is then up to the one who merges, which makes some sense too.
FYI, I'll teach Cogito about the refs/tags/<branch>/<tag> later today
(and totally offtopic, it already has some trivial cg-push now).
It will still fall back to refs/tags/<tag>.
> This also means the refs cannot be uniquely rebuilt from the
> object storage.
Why should they be, after all.
--
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: A Large Angry SCM @ 2005-07-02 22:02 UTC (permalink / raw)
To: Git Mailing List
Cc: H. Peter Anvin, Linus Torvalds, Eric W. Biederman,
Daniel Barkalow, Junio C Hamano, ftpadmin
In-Reply-To: <42C70A5B.9070606@zytor.com>
H. Peter Anvin wrote:
...
>
> OK, so let me retell what I think I hear you say:
>
> - Store all the tags in the object store; they may conflict.
> - Let each source user have a set of refs, and provide a method for the
> end user to select which refs to get.
>
> In other words, the only way (other than knowing what GPG keys to trust)
> to distinguish between your "v2.6.12" and J. Random Hacker's "v2.6.12"
> is that the former is referenced by *your* refs as opposed to JRH's
> refs. This also means the refs cannot be uniquely rebuilt from the
> object storage.
Why have tag objects at all?
^ permalink raw reply
* Re: Tags
From: H. Peter Anvin @ 2005-07-02 21:42 UTC (permalink / raw)
To: Linus Torvalds
Cc: Eric W. Biederman, Daniel Barkalow, Git Mailing List,
Junio C Hamano, ftpadmin
In-Reply-To: <Pine.LNX.4.58.0507021432370.8247@g5.osdl.org>
Linus Torvalds wrote:
>
> Note that the fact that you use a common object store does not mean that
> everything should be common.
>
> I still contend that tags and branches and things like that should be
> personal. A "gitforge" thing should _not_ try to unify tags. Instead, give
> people their own private area for keeping their own private references
> (you can limit it to just a few kilobytes per person, so you might as well
> just consider it to be part of their "user information" thing along with
> whatever other preferences they have).
>
> Then, they call all share the objects, and there's never any confusion
> about tags - everybody has their own tags, and you add a few simple
> operations like "copy user xxx's tag to my tag-space, and start a new
> branch from that".
>
> There're really no downsides. The only thing you need to have is some nice
> tag-browser (and some simple permission model where developers can say
> "others can read my tag" or "this tag is visible only to me" - the object
> store may be shared, but if nobody can see your pointers into the object
> store, you effectively have a totally private branch - which might be
> what some people want).
>
> There's really never any reason to make tags global. Even in the case of
> the kernel, people don't want to see a tag like "v2.6.12". They want to
> see what _I_ tagged v2.6.12, so implicit in that whole thing is very much
> that they want to see _my_ tags. Again, it's a _browsing_ issue, not a
> "tags should be global" issue. They should be visible and easily
> fetchable.
>
OK, so let me retell what I think I hear you say:
- Store all the tags in the object store; they may conflict.
- Let each source user have a set of refs, and provide a method for the
end user to select which refs to get.
In other words, the only way (other than knowing what GPG keys to trust)
to distinguish between your "v2.6.12" and J. Random Hacker's "v2.6.12"
is that the former is referenced by *your* refs as opposed to JRH's
refs. This also means the refs cannot be uniquely rebuilt from the
object storage.
-hpa
^ permalink raw reply
* Re: Tags
From: Linus Torvalds @ 2005-07-02 21:39 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Eric W. Biederman, Daniel Barkalow, Git Mailing List,
Junio C Hamano, ftpadmin
In-Reply-To: <42C7043C.9080904@zytor.com>
On Sat, 2 Jul 2005, H. Peter Anvin wrote:
>
> They're not using a single global object storage.
Note that the fact that you use a common object store does not mean that
everything should be common.
I still contend that tags and branches and things like that should be
personal. A "gitforge" thing should _not_ try to unify tags. Instead, give
people their own private area for keeping their own private references
(you can limit it to just a few kilobytes per person, so you might as well
just consider it to be part of their "user information" thing along with
whatever other preferences they have).
Then, they call all share the objects, and there's never any confusion
about tags - everybody has their own tags, and you add a few simple
operations like "copy user xxx's tag to my tag-space, and start a new
branch from that".
There're really no downsides. The only thing you need to have is some nice
tag-browser (and some simple permission model where developers can say
"others can read my tag" or "this tag is visible only to me" - the object
store may be shared, but if nobody can see your pointers into the object
store, you effectively have a totally private branch - which might be
what some people want).
There's really never any reason to make tags global. Even in the case of
the kernel, people don't want to see a tag like "v2.6.12". They want to
see what _I_ tagged v2.6.12, so implicit in that whole thing is very much
that they want to see _my_ tags. Again, it's a _browsing_ issue, not a
"tags should be global" issue. They should be visible and easily
fetchable.
Linus
^ permalink raw reply
* Re: Tags
From: H. Peter Anvin @ 2005-07-02 21:16 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Linus Torvalds, Daniel Barkalow, Git Mailing List, Junio C Hamano,
ftpadmin
In-Reply-To: <m1fyuxdpq4.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>
>>Eric W. Biederman wrote:
>>
>>>?? Isn't that what ssh is?
>>>To some extent a lot depends on how active you expect people to
>>>try and forge things. If there is an expectation of honesty
>>>you are fine.
>>
>>I can't afford to have that.
>
> So you are now your requirements are more stringent then sourceforge?
> Sourcefore limited things by reducing the scope of commits per
> project. But once you had commit access to a project you could do
> just about anything.
>
They're not using a single global object storage.
-hpa
^ permalink raw reply
* Re: Tags
From: Jan Harkes @ 2005-07-02 20:38 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: <42C5DA77.4030107@zytor.com>
On Fri, Jul 01, 2005 at 05:06:15PM -0700, H. Peter Anvin wrote:
> 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.
I'm not entirely sure what you are envisoning, but it is definitely
doable in a secure way.
- Assume that each developer will one or more private trees with one or
more branches on kernel.org, lets say all these private repositories
are stored under /scm/git/<user>/
- Now you create a single 'global repository' which is going to be the
publicly visible one that will be mirrored out,
- Then you run the following script (untested)
#!/bin/sh
GIT_DIR=$global_repo
for user in `(cd /scm/git ; ls)`; do
for tree in `find /scm/git/$user -name *.git` ; do
for ref in `find $tree/refs -type f` ; do
type=`echo $ref | sed 'sX^.*/refs/\([^/]*\)/.*$X\1X'`
name=`echo $ref | sed 'sX^.*/refs/[^/]*/\(.*\)$X\1X'`
git fetch /scm/git/$tree $branch
mkdir -p $GIT_DIR/refs/$type/$user/$name
cat $GIT_DIR/FETCH_HEAD > $GIT_DIR/refs/$type/$user/$name
done
done
done
- You can repack the global repository whenever you want.
- Finally, once a user knows that all his changes are available from the
global repository, he can remove any objects from his tree and use
GIT_ALTERNATE_OBJECT_DIRECTORIES=$global_repo/objects
(maybe there should be a flag for git prune to removes local objects
that are already available in the alternate object directories)
Jan
^ permalink raw reply
* Re: Tags
From: Matthias Urlichs @ 2005-07-02 19:55 UTC (permalink / raw)
To: git
In-Reply-To: <m1fyuxdpq4.fsf@ebiederm.dsl.xmission.com>
Hi, Eric W. Biederman wrote:
> So
> is there anything wrong with adding .git/refs/tags/tag-name.sign
> that is a traditional signature file?
The signature is already appended to the tag file itself (or can be).
See "git-tag-script".
--
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
- -
Democracy is that form of government where everybody gets what the majority
deserves.
-- James Dale Davidson
^ permalink raw reply
* Re: Tags
From: Linus Torvalds @ 2005-07-02 18:45 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Eric W. Biederman, Daniel Barkalow, Git Mailing List,
Junio C Hamano, ftpadmin
In-Reply-To: <42C6D5AD.9070304@zytor.com>
On Sat, 2 Jul 2005, H. Peter Anvin wrote:
>
> Well, you're wrong. Tags is the only part of git which cannot be
> protected by git's own self-validation system.
Well, you _can_ use the tag objects. That's what I do. The namespace isn't
the tag name you use ("v2.6.12"), it's the name of the tag itself (in this
case "26791a8bcf0e6d33f43aef7682bdb555236d56de"), and then it does
actually distribute fine. The symbolic name is encoded within the tag, but
isn't guaranteed to be unique in any way.
So no, it doesn't protect the tag _name_ per se. Anybody can create a tag
called "v2.6.12", and I don't think there's any way to handle clashes
sanely. But you can find the tag objects in a pack, and you could index
them separately. Then you'd need to let the users decide which ones they
trust or want to use.
Linus
^ permalink raw reply
* Re: Tags
From: Eric W. Biederman @ 2005-07-02 18:31 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Daniel Barkalow, Git Mailing List, Junio C Hamano,
ftpadmin
In-Reply-To: <42C6D5AD.9070304@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Eric W. Biederman wrote:
>> ?? Isn't that what ssh is?
>> To some extent a lot depends on how active you expect people to
>> try and forge things. If there is an expectation of honesty
>> you are fine.
>
> I can't afford to have that.
So you are now your requirements are more stringent then sourceforge?
Sourcefore limited things by reducing the scope of commits per
project. But once you had commit access to a project you could do
just about anything.
>> If you want to build one mondo repository with thousands of developers
>> having write access you need to be more careful. But as far as I know
>> none of that is specific to tags.
>
> Well, you're wrong. Tags is the only part of git which cannot be protected by
> git's own self-validation system.
Which is why I suggested having tags in sync with the committer
information, that way you are as valid as the commit record
in git. Although I suspect the multiple head solution is
probably better, and simply limiting the people who can commit
to an individual head will achieve what is necessary. One user
per head?
One thing arch has shown is that you can sucessfully move
authentication/permission checking to the underlying environment
if you structure things carefully.
I guess the problem is really we want to structure things so that
a user who has downloaded the code can verify they have the
release/tag is what they are looking for. You can detect
a spoofed file in objects by simply verifying the sha1 of the file.
For a file that you can't internally verify that way the traditional
way to handle that is to create a file with a gpg signature. So
is there anything wrong with adding .git/refs/tags/tag-name.sign
that is a traditional signature file? That will at least give
you an end to end consistency check. (Hmm. Why didn't I suggest
this before?)
If you don't want to mirror and propagate data you need to do
consistency checks earlier in the process, and I have probably had
some poor suggestions on how to implement those. But if everything
is setup so we can verify things once we have the code downloaded,
where you perform the checks is simply a matter of optimization.
Eric
^ permalink raw reply
* Re: "git-send-pack"
From: A Large Angry SCM @ 2005-07-02 18:12 UTC (permalink / raw)
To: git
In-Reply-To: <42C6D36D.4060006@zytor.com>
H. Peter Anvin wrote:
> Tony Luck wrote:
>>
...
>
> This is why I've been talking about a global object repository --
> including the problems associated with them. git as it currently stands
> permit a single global object store, *except* for the issue of duplicate
> tags.
So why not store just the git objects in the global repository and keep
all the things that reference an object (HEAD, branches/*, refs/*/*,
etc.) in a per project and/or contributor area like it is currently?
^ permalink raw reply
* Re: Tags
From: H. Peter Anvin @ 2005-07-02 17:58 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Linus Torvalds, Daniel Barkalow, Git Mailing List, Junio C Hamano,
ftpadmin
In-Reply-To: <m1k6k9drfk.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
>
> ?? Isn't that what ssh is?
>
> To some extent a lot depends on how active you expect people to
> try and forge things. If there is an expectation of honesty
> you are fine.
>
I can't afford to have that.
> If you want to build one mondo repository with thousands of developers
> having write access you need to be more careful. But as far as I know
> none of that is specific to tags.
Well, you're wrong. Tags is the only part of git which cannot be
protected by git's own self-validation system.
-hpa
^ permalink raw reply
* Re: Tags
From: Eric W. Biederman @ 2005-07-02 17:54 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Daniel Barkalow, Git Mailing List, Junio C Hamano,
ftpadmin
In-Reply-To: <42C6D318.8050108@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Eric W. Biederman wrote:
>> However all you have to do for your single system git repository is
>> to filter tags at creation time. So for a person to upload something
>> you need a git aware tool and you need authentication so you are certain
>> it is the right person creating the tag.
>
> That's complicated; it pretty much works out to having to have a PKI and a
> system of registered IDs, or some such. That's painful.
?? Isn't that what ssh is?
To some extent a lot depends on how active you expect people to
try and forge things. If there is an expectation of honesty
you are fine.
If you want to build one mondo repository with thousands of developers
having write access you need to be more careful. But as far as I know
none of that is specific to tags.
Eric
^ permalink raw reply
* Re: "git-send-pack"
From: H. Peter Anvin @ 2005-07-02 17:48 UTC (permalink / raw)
To: Tony Luck; +Cc: Linus Torvalds, Mike Taht, Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <12c511ca05070210441c0d3a33@mail.gmail.com>
Tony Luck wrote:
>
> At least part of the problem for kernel.org is that there around 50 repositories
> that are tracking the 2.6 kernel. All of them have 50,000 objects that are
> duplicates of each other ... and a few hundred 'unique' objects that belong
> to just one repo, or are minimally shared.
>
> If there was a way to specify an alternate repo, then a large GIT server like
> kernel.org could set up a "git-history"[1] repo which each of the hosted repos
> could point to. Then a cron job could look for duplicates, and move them
> off to the history area.
>
This is why I've been talking about a global object repository --
including the problems associated with them. git as it currently stands
permit a single global object store, *except* for the issue of duplicate
tags.
-hpa
^ permalink raw reply
* Re: Tags
From: H. Peter Anvin @ 2005-07-02 17:47 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Linus Torvalds, Daniel Barkalow, Git Mailing List, Junio C Hamano,
ftpadmin
In-Reply-To: <m1hdfdg0aa.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
>
> However all you have to do for your single system git repository is
> to filter tags at creation time. So for a person to upload something
> you need a git aware tool and you need authentication so you are certain
> it is the right person creating the tag.
>
That's complicated; it pretty much works out to having to have a PKI and
a system of registered IDs, or some such. That's painful.
-hpa
^ permalink raw reply
* Re: "git-send-pack"
From: Tony Luck @ 2005-07-02 17:44 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Mike Taht, Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0507021009580.3019@ppc970.osdl.org>
Here's another approach.
Teach the variants of git-pull to look for a file that names an
alternate repository
that should be used to get any object that is referenced in the repository, but
doesn't exist in it.
At least part of the problem for kernel.org is that there around 50 repositories
that are tracking the 2.6 kernel. All of them have 50,000 objects that are
duplicates of each other ... and a few hundred 'unique' objects that belong
to just one repo, or are minimally shared.
If there was a way to specify an alternate repo, then a large GIT server like
kernel.org could set up a "git-history"[1] repo which each of the hosted repos
could point to. Then a cron job could look for duplicates, and move them
off to the history area.
-Tony
[1] Different projects, like git and sparse, might never have any common
files with the Linux kernel ... but they can all share the same history.
^ permalink raw reply
* Re: "git-send-pack"
From: H. Peter Anvin @ 2005-07-02 17:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Mike Taht, Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0507021009580.3019@ppc970.osdl.org>
Linus Torvalds wrote:
>
> ..but that's not what we're looking for. I'm not looking for kernel.org to
> be my distributed backup tape.
>
> For it to be useful, it must do more than just log all activity and mirror
> it out via rsync. It must also be usable for people pulling on it. Which
> means that it has to be a valid git archive or at least easily
> incrementally unpackable, so that people can actually use the end result.
>
> A log of packs that are just incremented is certainly unpackable: you
> teach git-unpack-objects to just unpack several packs after each other.
> But since it's not seekable, you'd have to unpack a 100MB compressed
> archive just to get the last tip of it that you don't have unpacked yet.
>
Agreed, you also need an index file. The index file can be recreated
from the log file in case of corruption, but is what you'd use to seek
directly to an object.
-hpa
^ permalink raw reply
* Re: "git-send-pack"
From: Linus Torvalds @ 2005-07-02 17:16 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Mike Taht, Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <42C61818.30109@zytor.com>
On Fri, 1 Jul 2005, H. Peter Anvin wrote:
>
> It's a log.
..but that's not what we're looking for. I'm not looking for kernel.org to
be my distributed backup tape.
For it to be useful, it must do more than just log all activity and mirror
it out via rsync. It must also be usable for people pulling on it. Which
means that it has to be a valid git archive or at least easily
incrementally unpackable, so that people can actually use the end result.
A log of packs that are just incremented is certainly unpackable: you
teach git-unpack-objects to just unpack several packs after each other.
But since it's not seekable, you'd have to unpack a 100MB compressed
archive just to get the last tip of it that you don't have unpacked yet.
Also, it means that it's impossible to efficiently do a git-specific
thing. I want people to be able to do what we used to be able to do with
BK: just do a
git pull master.kernel.org:xxxx
and get something useful. And that means _not_ having to pull a 100MB blob
to get the last objects at the end.
And don't tell me "rsync can efficiently get just the end". That's true
for _mirrors_, but it's not true for users that don't have every single
archive on kernel.org. I don't have (and I don't want to have) a copy of
every single persons log that ever might want to push to me.
So no, a log simply isn't useful. It _has_ to be a valid git archive to be
useful. Thousands of objects satisfy that. Or a "few packs + few objects".
Not a log.
Linus
^ permalink raw reply
* Re: Tags
From: Matthias Urlichs @ 2005-07-02 16:00 UTC (permalink / raw)
To: git
In-Reply-To: <42C5C75F.4040100@zytor.com>
Hi, H. Peter Anvin wrote:
> Doesn't work. You can trivially generate a key with someone else's
> address. It would require a full PKI.
So you use the GPG key's fingerprint as the directory name, and add
a few strategically named symlinks for convenience. *Shrug*
Besides, what's wrong with requiring full PKI? Everybody who has
a kernel.org account should be in the strongly connected set...
--
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
- -
What I want is all of the power and none of the responsibility.
^ permalink raw reply
* [RESUBMITTED PATCH 1/2] Add --topo-order flag to git-rev-list [rev2]
From: Jon Seymour @ 2005-07-02 8:39 UTC (permalink / raw)
To: git; +Cc: torvalds, jon.seymour
Added a --topo-order flag to git-rev-list.
When this flag is specified, git-rev-list sorts its output
in topological order. That is:
a is reachable from b ==> ord(b) < ord(a)
This ordering invariant is weaker than the --merge-order invariant
but should be sufficient for tools just as gitk that only
need the minimum guarantee provided by --topo-order.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
Note: this patch assumes that my previous patch series that introduces
sort_in_topological_order() to commit.c has been applied.
A subsequent patch to gitk will make gitk use --topo-order instead
of --merge-order.
[rev2]
* this patch rescues the --topo-order patch that I withdrew
by recognizing that if limit_list is called, sort_commit_list
does not do a chronological sort
* ensures limit_list is called whenever a topological sort is
is required
* removed excess braces
---
rev-list.c | 29 +++++++++++++++++++++--------
1 files changed, 21 insertions(+), 8 deletions(-)
de8a7f7120581ae60b7e882b15b9099a6fce55dd
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -16,7 +16,7 @@ static const char rev_list_usage[] =
" --min-age=epoch\n"
" --header\n"
" --pretty\n"
- " --bisect\n"
+ " --bisect\n"
" --merge-order [ --show-breaks ]";
static int tag_objects = 0;
@@ -32,6 +32,7 @@ static int max_count = -1;
static enum cmit_fmt commit_format = CMIT_FMT_RAW;
static int merge_order = 0;
static int show_breaks = 0;
+static int topo_order=0;
static int stop_traversal = 0;
static int bisect_by_cut_option = 0;
@@ -373,11 +374,15 @@ int main(int argc, char **argv)
blob_objects = 1;
continue;
}
- if (!strncmp(arg, "--merge-order", 13)) {
+ if (!strcmp(arg, "--merge-order")) {
merge_order = 1;
continue;
}
- if (!strncmp(arg, "--show-breaks", 13)) {
+ if (!strcmp(arg, "--topo-order")) {
+ topo_order = 1;
+ continue;
+ }
+ if (!strcmp(arg, "--show-breaks")) {
show_breaks = 1;
continue;
}
@@ -396,14 +401,22 @@ int main(int argc, char **argv)
}
if (!merge_order) {
- if (limited)
+ if (limited || topo_order || bisect_by_cut_option) {
+ /*
+ * two expected side effects of calling
+ * limit_list are:
+ * * resulting list contains all the items to process
+ * * show_commit_list won't do a chronological
+ * sort
+ */
list = limit_list(list);
- if (!bisect_by_cut_option)
- show_commit_list(list);
- else {
+ }
+ if (bisect_by_cut_option || topo_order)
sort_in_topological_order(&list);
+ if (bisect_by_cut_option)
show_commit(bisect_by_cut(list));
- }
+ else
+ show_commit_list(list);
} else {
if (sort_list_in_merge_order(list, &process_commit)) {
die("merge order sort failed\n");
------------
^ permalink raw reply
* Re: [WITHDRAWN PATCH 1/2] Add --topo-order flag to git-rev-list
From: Jon Seymour @ 2005-07-02 7:56 UTC (permalink / raw)
To: git; +Cc: torvalds, jon.seymour, Paul Mackerras
In-Reply-To: <20050702060936.13011.qmail@blackcubes.dyndns.org>
Actually, I need to withdraw this patch.
The way show_commit_list works defeats the approach I was using to
perform a topological sort - since show_commit_list does more than
show the list, it also performs a chronological sort on the list,
thereby undoing the topological sort that is attempted.
jon.
^ permalink raw reply
* Re: Tags
From: Eric W. Biederman @ 2005-07-02 7:00 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Daniel Barkalow, Git Mailing List, Junio C Hamano,
ftpadmin
In-Reply-To: <42C5DA77.4030107@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> 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.
Could be I'm certainly not up to speed on git yet.
However all you have to do for your single system git repository is
to filter tags at creation time. So for a person to upload something
you need a git aware tool and you need authentication so you are certain
it is the right person creating the tag.
Since it is a shared repository you probably want rules like you can
only create tags that belong to yourself or are owned by people
who do not have accounts on the system.
Likewise in a system like sourceforge it is desirable to check all
of the committer information in commits as well, so you have a reasonable
audit trail, and it make sense to check little things like the file under
a sha1 key actually matches the sha1 key.
Downstream mirrors can happily rsync just fine. So long as they
verify the upstream source.
Tags that you mirror are of course suspect but they will always be.
The primary tags created by people with accounts should be reliable
though.
So in essence I see nothing with my proposal that is any worse than
any other part of git.
That being said, it sounds like there is a slightly more git
knowledgeable/native version suggested having to do with multiple
heads.
Eric
^ permalink raw reply
* [PATCH 1/2] Add --topo-order flag to git-rev-list
From: Jon Seymour @ 2005-07-02 6:09 UTC (permalink / raw)
To: git; +Cc: torvalds, jon.seymour
Added a --topo-order flag to git-rev-list.
When this flag is specified, git-rev-list sorts its output
in topological order. That is:
a is reachable from b ==> ord(b) < ord(a)
This ordering invariant is weaker than the --merge-order invariant
but should be sufficient for tools just as gitk that only
need the minimum guarantee provided by --topo-order.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
Note: this patch assumes that my previous patch series that introduces
sort_in_topological_order() to commit.c has been applied.
A subsequent patch to gitk will make gitk use --topo-order instead
of --merge-order.
---
rev-list.c | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
804e6b585e205ba119a9a43058d69c2ef914dc80
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -32,6 +32,7 @@ static int max_count = -1;
static enum cmit_fmt commit_format = CMIT_FMT_RAW;
static int merge_order = 0;
static int show_breaks = 0;
+static int topo_order=0;
static int stop_traversal = 0;
static int bisect_by_cut_option = 0;
@@ -373,11 +374,15 @@ int main(int argc, char **argv)
blob_objects = 1;
continue;
}
- if (!strncmp(arg, "--merge-order", 13)) {
+ if (!strcmp(arg, "--merge-order")) {
merge_order = 1;
continue;
}
- if (!strncmp(arg, "--show-breaks", 13)) {
+ if (!strcmp(arg, "--topo-order")) {
+ topo_order = 1;
+ continue;
+ }
+ if (!strcmp(arg, "--show-breaks")) {
show_breaks = 1;
continue;
}
@@ -398,9 +403,12 @@ int main(int argc, char **argv)
if (!merge_order) {
if (limited)
list = limit_list(list);
- if (!bisect_by_cut_option)
+ if (!bisect_by_cut_option) {
+ if (topo_order) {
+ sort_in_topological_order(&list);
+ }
show_commit_list(list);
- else {
+ } else {
sort_in_topological_order(&list);
show_commit(bisect_by_cut(list));
}
------------
^ permalink raw reply
* [PATCH 2/2] Change to gitk to make it use --topo-order rather than --merge-order
From: Jon Seymour @ 2005-07-02 6:09 UTC (permalink / raw)
To: git; +Cc: torvalds, jon.seymour
This patch make gitk use --topo-order rather than --merge-order.
There is no actual advantage in doing this as the git-rev-list
execution times are dwarfed by tcl/tk overheads so the 3-4 time
git-rev-list speedup is effectively invisible. Still, it
does demonstrate the use of the --topo-order flag.
One advantage of this patch would be to allow gitk to be used
in environments that don't have the ssl bignum library available
for some reason.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
This patch assumes that git has been patched to include support
for --topo-order.
Here's a chance to test merging a gitk patch from git back into
gitk :-)
---
gitk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
4deb99b73fd6fc8e4995b55e9e23988c8766f509
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -37,7 +37,7 @@ proc getcommits {rargs} {
set parsed_args $rargs
}
if [catch {
- set commfd [open "|git-rev-list --header --merge-order $parsed_args" r]
+ set commfd [open "|git-rev-list --header --topo-order $parsed_args" r]
} err] {
puts stderr "Error executing git-rev-list: $err"
exit 1
------------
^ permalink raw reply
* [PATCH 8/8] Removes support for O(n^2) algorithm from git-rev-list completely [rev 2]
From: Jon Seymour @ 2005-07-02 5:38 UTC (permalink / raw)
To: git; +Cc: torvalds, jon.seymour
This patch completely removes support for the O(n^2) bisection
algorithm from commit.c, commit.h and rev-list.c
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
Linus: I have included this patch to allow you to easily remove the O(n^2)
algorithm if that is your choice. I am not expecting you to do so.
[rev 2]
* re-issued to cope with re-issue of immediately preceding patch
---
commit.c | 31 -------------------------------
commit.h | 7 -------
rev-list.c | 7 -------
t/t6002-rev-list-bisect.sh | 1 -
4 files changed, 0 insertions(+), 46 deletions(-)
612b72335b99071c7f825b3633f241c4d12dfe6e
diff --git a/commit.c b/commit.c
--- a/commit.c
+++ b/commit.c
@@ -504,37 +504,6 @@ static void clear_distance(struct commit
}
}
-struct commit_list *find_bisection(struct commit_list *list)
-{
- int nr, closest;
- struct commit_list *p, *best;
-
- nr = 0;
- p = list;
- while (p) {
- nr++;
- p = p->next;
- }
- closest = 0;
- best = list;
-
- p = list;
- while (p) {
- int distance = count_distance(p);
- clear_distance(list);
- if (nr - distance < distance)
- distance = nr - distance;
- if (distance > closest) {
- best = p;
- closest = distance;
- }
- p = p->next;
- }
- if (best)
- best->next = NULL;
- return best;
-}
-
static inline struct bisect_by_cut_node * get_bisect_by_cut_node(struct commit * commit)
{
return (struct bisect_by_cut_node *)commit->object.util;
diff --git a/commit.h b/commit.h
--- a/commit.h
+++ b/commit.h
@@ -74,13 +74,6 @@ int count_parents(struct commit * commit
void sort_in_topological_order(struct commit_list ** list);
/*
- * Uses an O(n^2) algorithm to find the commit that bisects
- * the subgraph represented by the list of commits. The boundaries
- * of the subgraph are delimited by adjacent nodes that have
- */
-struct commit_list *find_bisection(struct commit_list *list);
-
-/*
* Uses O(n) to find the bisection of a list of commits
* which is already sorted in topological order.
*/
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -19,7 +19,6 @@ static const char rev_list_usage[] =
" --bisect\n"
" --merge-order [ --show-breaks ]";
-static int bisect_list = 0;
static int tag_objects = 0;
static int tree_objects = 0;
static int blob_objects = 0;
@@ -252,8 +251,6 @@ struct commit_list *limit_list(struct co
}
p = &commit_list_insert(commit, p)->next;
}
- if (bisect_list)
- newlist = find_bisection(newlist);
return newlist;
}
@@ -370,10 +367,6 @@ int main(int argc, char **argv)
bisect_by_cut_option = 1;
continue;
}
- if (!strcmp(arg, "--bisect-orig")) {
- bisect_list = 1;
- continue;
- }
if (!strcmp(arg, "--objects")) {
tag_objects = 1;
tree_objects = 1;
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,6 @@ EOF
}
test_sequence "--bisect"
-test_sequence "--bisect-orig"
#
#
------------
^ permalink raw reply
* [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
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