* Re: [4/5] Add option for hardlinkable cache of extracted blobs
From: Daniel Barkalow @ 2005-04-17 20:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: Paul Jackson, git
In-Reply-To: <20050417195935.GI1461@pasky.ji.cz>
On Sun, 17 Apr 2005, Petr Baudis wrote:
> Dear diary, on Sun, Apr 17, 2005 at 09:25:17PM CEST, I got a letter
> where Paul Jackson <pj@sgi.com> told me that...
> > Petr wrote:
> > > BTW, I'd just use access(F_OK) instead of stat() it I don't care about
> >
> > I recommend _only_ using it when you require exactly the above real vs.
> > effective id behaviour.
>
> Does this distinction have any effect when doing F_OK?
Actually, the documentation I've got says:
"F_OK requests checking whether merely testing for the existence of the
file would be allowed (this depends on the permissions of the directories
in the path to the file, as given in path-name.)"
So it shouldn't complain about a filename which you're allowed to try to
stat, even if there's nothing there. And it would depend on the privs of
the wrong user in looking at the path.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [1/5] Parsing code in revision.h
From: Linus Torvalds @ 2005-04-17 20:06 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0504171253030.7211@ppc970.osdl.org>
On Sun, 17 Apr 2005, Linus Torvalds wrote:
>
> Yes. I'm not opposed to yours, I was just opposed to some of the things
> around it you did, so I wrote mine as a kind of place-holder. I'll happily
> take patches to turn it from a rally simple and stupid one into a more
> polished version.
Btw, before I forget - I did have another reason. I actually think that
the date is potentially a lot more important than "how many parents deep".
In particular, it's entirely possible that the top of my head might be a
veru recent merge that merges with a small fix relative to a very old
parent (making that old parent be just two hops away from the head), while
the thing I want to merge might also have that old parent (for similar
reasons) as a relatively "close" parent from a pure link-counting
standpoint.
The reason I bring this up is that quite often people end up basing their
work on a specific release version, so a merge (especially in specialized
areas) may thus bring such an old parent pretty close to the head, and it
can actually be quite possible (indeed probable) that such a parent ends
up being a common parent.
However, it can easily be a very _bad_ parent.
In ascii barfic:
----------------------- patch ---------
/ \
/ \
- old release -- ... lots of development .. -----HEAD
\ \
\ \
\ ---------------------patch-- MERGE-HEAD
\ /
.. lots of development .. /
it looks like "old release" is pretty close to both HEAD and MERGE-HEAD,
right?
But that's just an artifact of the fact that they both had a trivial merge
against some older code, and if the two "lots of development" things have
ever done an earlier merge, there's quite possibly a _much_ better common
parent there somewhere.
I dunno.
Linus
^ permalink raw reply
* Re: [4/5] Add option for hardlinkable cache of extracted blobs
From: Petr Baudis @ 2005-04-17 19:59 UTC (permalink / raw)
To: Paul Jackson; +Cc: barkalow, git
In-Reply-To: <20050417122517.4b12faea.pj@sgi.com>
Dear diary, on Sun, Apr 17, 2005 at 09:25:17PM CEST, I got a letter
where Paul Jackson <pj@sgi.com> told me that...
> Petr wrote:
> > BTW, I'd just use access(F_OK) instead of stat() it I don't care about
>
> I recommend _only_ using it when you require exactly the above real vs.
> effective id behaviour.
Does this distinction have any effect when doing F_OK?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Russell King @ 2005-04-17 20:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504171324340.7211@ppc970.osdl.org>
On Sun, Apr 17, 2005 at 01:26:27PM -0700, Linus Torvalds wrote:
>
>
> On Sun, 17 Apr 2005, Russell King wrote:
> >
> > It's trivial to change - it's either sort -n or sort -nr !
>
> Yes.
>
> Btw, it might make sense to do the "grep" before the sort, since the sort
> doesn't scale as nicely with lots of output. On the other hand, then the
> grep pattern needs to be a bit more complex (so that it doesn't pick up on
> things that have _parents_ with ":1"). I think the rev-tree output is
> obvious enough that it's pretty trivial to grep for..
sed works as well - in fact, we can use it to both select lines based
upon the :1 _and_ cut out the bulk of the stuff we're not interested in.
So:
rev-tree $to $prev | \
sort -nr | cut -d' ' -f2 | grep :1 | cut -d: -f1
becomes:
rev-tree $to $prev | \
sed -n 's,\([[:digit:]]\+\)[[:space:]]\+\([[:xdigit:]]\+\):1.*,\1 \2,p' | \
sort -nr | cut -d' ' -f2
(appologies to those who don't like regexps 8))
One thing to note about that sed expression though - using \+ is a GNU
extension - do we care about that? The portable way is to use \{1,\}
but that'd clutter it some more.
--
Russell King
^ permalink raw reply
* Re: [4/5] Add option for hardlinkable cache of extracted blobs
From: Petr Baudis @ 2005-04-17 20:18 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Paul Jackson, git
In-Reply-To: <Pine.LNX.4.21.0504171600310.30848-100000@iabervon.org>
Dear diary, on Sun, Apr 17, 2005 at 10:03:46PM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> On Sun, 17 Apr 2005, Petr Baudis wrote:
>
> > Dear diary, on Sun, Apr 17, 2005 at 09:25:17PM CEST, I got a letter
> > where Paul Jackson <pj@sgi.com> told me that...
> > > Petr wrote:
> > > > BTW, I'd just use access(F_OK) instead of stat() it I don't care about
> > >
> > > I recommend _only_ using it when you require exactly the above real vs.
> > > effective id behaviour.
> >
> > Does this distinction have any effect when doing F_OK?
>
> Actually, the documentation I've got says:
>
> "F_OK requests checking whether merely testing for the existence of the
> file would be allowed (this depends on the permissions of the directories
> in the path to the file, as given in path-name.)"
>
> So it shouldn't complain about a filename which you're allowed to try to
> stat, even if there's nothing there. And it would depend on the privs of
> the wrong user in looking at the path.
The documentation I've got says:
"R_OK, W_OK and X_OK request checking whether the file exists and has
read, write and execute permissions, respectively. F_OK just requests
checking for the existence of the file."
And IEEE1003.1 agrees:
http://www.opengroup.org/onlinepubs/009695399/functions/access.html
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Linus Torvalds @ 2005-04-17 20:26 UTC (permalink / raw)
To: Russell King; +Cc: Git Mailing List
In-Reply-To: <20050417211116.F13233@flint.arm.linux.org.uk>
On Sun, 17 Apr 2005, Russell King wrote:
>
> It's trivial to change - it's either sort -n or sort -nr !
Yes.
Btw, it might make sense to do the "grep" before the sort, since the sort
doesn't scale as nicely with lots of output. On the other hand, then the
grep pattern needs to be a bit more complex (so that it doesn't pick up on
things that have _parents_ with ":1"). I think the rev-tree output is
obvious enough that it's pretty trivial to grep for..
Linus
^ permalink raw reply
* Re: [1/5] Parsing code in revision.h
From: Daniel Barkalow @ 2005-04-17 20:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0504171254500.7211@ppc970.osdl.org>
On Sun, 17 Apr 2005, Linus Torvalds wrote:
> On Sun, 17 Apr 2005, Linus Torvalds wrote:
> >
> > Yes. I'm not opposed to yours, I was just opposed to some of the things
> > around it you did, so I wrote mine as a kind of place-holder. I'll happily
> > take patches to turn it from a rally simple and stupid one into a more
> > polished version.
>
> Btw, before I forget - I did have another reason. I actually think that
> the date is potentially a lot more important than "how many parents deep".
>
> In particular, it's entirely possible that the top of my head might be a
> veru recent merge that merges with a small fix relative to a very old
> parent (making that old parent be just two hops away from the head), while
> the thing I want to merge might also have that old parent (for similar
> reasons) as a relatively "close" parent from a pure link-counting
> standpoint.
>
> The reason I bring this up is that quite often people end up basing their
> work on a specific release version, so a merge (especially in specialized
> areas) may thus bring such an old parent pretty close to the head, and it
> can actually be quite possible (indeed probable) that such a parent ends
> up being a common parent.
>
> However, it can easily be a very _bad_ parent.
>
> In ascii barfic:
>
> ----------------------- patch ---------
> / \
> / \
> - old release -- ... lots of development .. -----HEAD
> \ \ /
> \ \ /
> \ --------------/------patch-- MERGE-HEAD
> \ / /
> .. lots of development .. /
(I added a merge line so there's another commit to discuss in the picture)
> it looks like "old release" is pretty close to both HEAD and MERGE-HEAD,
> right?
>
> But that's just an artifact of the fact that they both had a trivial merge
> against some older code, and if the two "lots of development" things have
> ever done an earlier merge, there's quite possibly a _much_ better common
> parent there somewhere.
>
> I dunno.
I think you're going to want multiple common ancestors being used in the
merge when this thing starts to happen; otherwise, you're going to have to
fix up conflicts for "patch" for all the trees you pull. (Also, you're
only going to see a parent for patch (that is, the old revision as an
ancestor of the application of patch) if the trees are merging it in via
git, in which case you'll also see a commit for patch, which will have a
recent date. So you'd see "just yesterday, we both merged a tiny
change; so that tree, which is very much like an ancient one, is more
recent that last weeks major merge".
I dunno either, but I hope we'll have 2+n-way-merge before there's a lot
of complex history to deal with.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: H. Peter Anvin @ 2005-04-17 20:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504161543590.7211@ppc970.osdl.org>
Linus Torvalds wrote:
> Ok, nobody really objected to the notion of leaving the kernel history
> behind for now, and in fact most people seemed to basically agree. So with
> that decided, the old kernel testing tree was actually perfectly ok,
> except it had been build up with the old-style commit date handling, which
> made me not want to use it as a base for any real work.
>
> So I re-created the dang thing (hey, it takes just a few minutes), and
> pushed it out, and there's now an archive on kernel.org in my public
> "personal" directory called "linux-2.6.git". I'll continue the tradition
> of naming git-archive directories as "*.git", since that really ends up
> being the ".git" directory for the checked-out thing.
>
> I'm not going to announce it on linux-kernel yet, because I don't think
> it's useful to anybody but a git person anyway. Besides, I don't actually
> know how happy the kernel.org people are about this distribution method
> and whether it ends up being a horrible disaster for the mirroring setup.
>
> Peter made some noises about /pub/scm, which makes sense, and would be a
> better place than my public tree. Apparently there are other places that
> are willing and able to host things too, so we'll see.
>
I would suggest something like /pub/scm/kernel/git/<people> on
kernel.org. This is easy to do, and being outside the "mirrored
worldwide" set shouldn't cause anyone any issues.
/pub/linux/... is mirrored worldwide and that might cause some
consternation.
If this is OK with everyone I'll try to set them up (I'm at LCA at the
moment, so I might have limited connectivity at any one particular
moment in time.)
-hpa
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Russell King @ 2005-04-17 20:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504171306360.7211@ppc970.osdl.org>
On Sun, Apr 17, 2005 at 01:08:51PM -0700, Linus Torvalds wrote:
> On Sun, 17 Apr 2005, Russell King wrote:
> > This will (and does) do exactly what I want. I'll also read into the
> > above a request that you want it in forward date order. 8)
>
> No, I actually don't _think_ I care. In many ways I'm more used to
> "reverse date order", because that's usually how you view a changelog
> (with a pager, and most recent changes at the top).
>
> Which one makes sense when asking me to merge? I don't know, and I don't
> think it really even matters, but maybe we can add a "for now" to whatever
> decision you end up coming to?
It's trivial to change - it's either sort -n or sort -nr !
I'll pick the reverse format so that we generate the changelog in the
order which people have come to expect from our previous set of tools.
Consistency with existing practises is a good thing at this point.
--
Russell King
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Linus Torvalds @ 2005-04-17 20:08 UTC (permalink / raw)
To: Russell King; +Cc: Git Mailing List
In-Reply-To: <20050417205149.E13233@flint.arm.linux.org.uk>
On Sun, 17 Apr 2005, Russell King wrote:
>
> This will (and does) do exactly what I want. I'll also read into the
> above a request that you want it in forward date order. 8)
No, I actually don't _think_ I care. In many ways I'm more used to
"reverse date order", because that's usually how you view a changelog
(with a pager, and most recent changes at the top).
Which one makes sense when asking me to merge? I don't know, and I don't
think it really even matters, but maybe we can add a "for now" to whatever
decision you end up coming to?
Linus
^ permalink raw reply
* Re: [3/5] Add http-pull
From: Petr Baudis @ 2005-04-17 19:59 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.21.0504171510120.30848-100000@iabervon.org>
Dear diary, on Sun, Apr 17, 2005 at 09:24:27PM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> On Sun, 17 Apr 2005, Petr Baudis wrote:
>
> > Dear diary, on Sun, Apr 17, 2005 at 08:49:11PM CEST, I got a letter
> > where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > > There's some trickiness for the history of commits thing for stopping at
> > > the point where you have everything, but also behaving appropriately if
> > > you try once, fail partway through, and then try again. It's on my queue
> > > of things to think about.
> >
> > Can't you just stop the recursion when you hit a commit you already
> > have?
>
> The problem is that, if you've fetched the final commit already, and then
> the server dies, and you try again later, you already have the last one,
> and so you think you've got everything.
Hmm, some kind of journaling? ;-)
> At this point, I also want to put off doing much further with recursion
> and commits until revision.h and such are sorted out.
Agreed.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [1/5] Parsing code in revision.h
From: Linus Torvalds @ 2005-04-17 19:54 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.21.0504171531180.30848-100000@iabervon.org>
On Sun, 17 Apr 2005, Daniel Barkalow wrote:
>
> Yours reads the whole commit history; I intentionally wrote mine to
> only read as far back as turns out to be necessary.
Yes. I'm not opposed to yours, I was just opposed to some of the things
around it you did, so I wrote mine as a kind of place-holder. I'll happily
take patches to turn it from a rally simple and stupid one into a more
polished version.
Linus
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Russell King @ 2005-04-17 19:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504171226530.7211@ppc970.osdl.org>
(Dropped HPA from the CC line - I think he was only copied for the
master.kernel.org issues.)
On Sun, Apr 17, 2005 at 12:33:22PM -0700, Linus Torvalds wrote:
> On Sun, 17 Apr 2005, Russell King wrote:
> > I still need to work out how to make my noddy script follow different
> > branches which may be present though. However, for my common work
> > flow, it fits what I require.
>
> The way to handle that is that you need to
>
> - remember (or re-fetch) what the latest HEAD was that you merged with in
> my tree.
>
> if you didn't remember, you can just get all my objects and do a
>
> merge-head $(cat .git/HEAD) $linus-current-head
>
> or something (using the current git archive that has a "merge-head"
> program. That gives you the most recent common head.
My script currently sends between two commit-ids, so...
> - use "rev-tree" to show reachability
>
> rev-tree $my-current-head $last-merge-head
> | sort -n # sort by date rather than sha1
> | cut -d' ' -f2 # get the sha1 + "flags" mask
> | grep :1 # show the ones that are only
> # reachable from $my-current-head
>
> and you now have a nice list of sha1's ordered by date.
This will (and does) do exactly what I want. I'll also read into the
above a request that you want it in forward date order. 8)
--
Russell King
^ permalink raw reply
* git-viz tool for visualising commit trees
From: Petr Baudis @ 2005-04-17 19:48 UTC (permalink / raw)
To: git; +Cc: oliv__a
Hi,
just FYI, Olivier Andrieu was kind enough to port his monotone-viz
tool to git (http://oandrieu.nerim.net/monotone-viz/ - use the one from
the monotone repository). The tool visualizes the history flow nicely;
see
http://rover.dkm.cz/~pasky/gitviz1.png
http://rover.dkm.cz/~pasky/gitviz2.png
http://rover.dkm.cz/~pasky/gitviz3.png
http://rover.dkm.cz/~pasky/gitviz4.png
http://rover.dkm.cz/~pasky/gitviz5.png
http://rover.dkm.cz/~pasky/gitviz6.png
http://rover.dkm.cz/~pasky/gitviz7.png
for some screenshots.
Kind regards,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [1/5] Parsing code in revision.h
From: Daniel Barkalow @ 2005-04-17 19:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0504171221130.7211@ppc970.osdl.org>
On Sun, 17 Apr 2005, Linus Torvalds wrote:
> On Sun, 17 Apr 2005, Petr Baudis wrote:
> >
> > Someone started the avalanche by adding date to the structure. Of
> > course, date is smaller, but it leads people (including me) out of the
> > way.
>
> Yeah, the naming and the structure comes from "rev-tree.c", so there's a
> bit of historical baggage already.
>
> Anyway, I don't think you should need it. I cleaned up things a bit, and
> wrote a really simple "merge-base" thing that does base the "best" hit on
> date, which ends up probably doing the right thing in practice.
Yours reads the whole commit history; I intentionally wrote mine to
only read as far back as turns out to be necessary. I think that looking
at the whole history is going to be impractical when you're trying to
merge in a bunch of patches against the latest release, even if you pull
the history out of a cache. When it's one step on one side and a dozen on
the other, it matters a whole lot if there's a year of history behind the
common ancestor(s).
So I still think it's best to have a non-recursive commit parser, and do
the recursion only as needed for the operation under consideration.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Linus Torvalds @ 2005-04-17 19:45 UTC (permalink / raw)
To: Russell King; +Cc: Git Mailing List, Peter Anvin
In-Reply-To: <Pine.LNX.4.58.0504171226530.7211@ppc970.osdl.org>
On Sun, 17 Apr 2005, Linus Torvalds wrote:
>
> - use "rev-tree" to show reachability
Btw, you don't even have to really remember the head you merged with. If
you have all my objects, you can just use the current head from whatever
my repository is, and the "rev-tree" will show all your commit objects
that aren't in my tree.
The only reason I said "remember the last head you merged" is that that
way you don't even have to download the objects from my tree, and you can
make the decision totally locally without looking at what I've done since.
Of course, at some point you want to get my updated objects _anyway_,
but..
Linus
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Linus Torvalds @ 2005-04-17 19:33 UTC (permalink / raw)
To: Russell King; +Cc: Git Mailing List, Peter Anvin
In-Reply-To: <20050417195742.D13233@flint.arm.linux.org.uk>
On Sun, 17 Apr 2005, Russell King wrote:
>
> I still need to work out how to make my noddy script follow different
> branches which may be present though. However, for my common work
> flow, it fits what I require.
The way to handle that is that you need to
- remember (or re-fetch) what the latest HEAD was that you merged with in
my tree.
if you didn't remember, you can just get all my objects and do a
merge-head $(cat .git/HEAD) $linus-current-head
or something (using the current git archive that has a "merge-head"
program. That gives you the most recent common head.
- use "rev-tree" to show reachability
rev-tree $my-current-head $last-merge-head
| sort -n # sort by date rather than sha1
| cut -d' ' -f2 # get the sha1 + "flags" mask
| grep :1 # show the ones that are only
# reachable from $my-current-head
and you now have a nice list of sha1's ordered by date.
Or something. I didn't test the above. Testing is for users.
Linus
^ permalink raw reply
* Re: [3/5] Add http-pull
From: Daniel Barkalow @ 2005-04-17 19:24 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050417190824.GF1461@pasky.ji.cz>
On Sun, 17 Apr 2005, Petr Baudis wrote:
> Dear diary, on Sun, Apr 17, 2005 at 08:49:11PM CEST, I got a letter
> where Daniel Barkalow <barkalow@iabervon.org> told me that...
>
> I'm not too kind at this. Either make it totally separate commands, or
> make a required switch specifying what to do. Otherwise it implies the
> switches would just modify what it does, but they make it do something
> completely different.
That's a good point. I'll require a -t for now, and add more later.
> -a would be fine too - basically a combination of -c and -t. I'd imagine
> that is what Linus would want to use, e.g.
Well, -c -t would give you the current tree and the whole commit log, but
not old trees. -a would additionally give you old trees.
> > There's some trickiness for the history of commits thing for stopping at
> > the point where you have everything, but also behaving appropriately if
> > you try once, fail partway through, and then try again. It's on my queue
> > of things to think about.
>
> Can't you just stop the recursion when you hit a commit you already
> have?
The problem is that, if you've fetched the final commit already, and then
the server dies, and you try again later, you already have the last one,
and so you think you've got everything.
At this point, I also want to put off doing much further with recursion
and commits until revision.h and such are sorted out.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [1/5] Parsing code in revision.h
From: Linus Torvalds @ 2005-04-17 19:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: Daniel Barkalow, git
In-Reply-To: <20050417183002.GE1461@pasky.ji.cz>
On Sun, 17 Apr 2005, Petr Baudis wrote:
>
> Someone started the avalanche by adding date to the structure. Of
> course, date is smaller, but it leads people (including me) out of the
> way.
Yeah, the naming and the structure comes from "rev-tree.c", so there's a
bit of historical baggage already.
Anyway, I don't think you should need it. I cleaned up things a bit, and
wrote a really simple "merge-base" thing that does base the "best" hit on
date, which ends up probably doing the right thing in practice.
It might be interesting to extend that to do the "five best" common
parents according to date (making sure to remove the trivial cases: a
parent of a common parent is always itself a common parent, but such a
common grandparent is obviously always uninteresting).
Then, for that small set of parents, doing something much more involved
(generation counting is fairly simple, but possibly not as good a
"goodness" match as tree-diff or something).
Linus
^ permalink raw reply
* Re: [4/5] Add option for hardlinkable cache of extracted blobs
From: Paul Jackson @ 2005-04-17 19:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: barkalow, git
In-Reply-To: <20050417174736.GA1461@pasky.ji.cz>
Petr wrote:
> BTW, I'd just use access(F_OK) instead of stat() it I don't care about
That's a bad habit to get into.
access(2) checks with the process's real uid and gid, rather than with
the effective ids as is done when actually attempting an operation.
This is to allow set-UID programs to easily determine the invoking
user's authority.
Using access(2) when it shouldn't be used is a common source of bugs.
I recommend _only_ using it when you require exactly the above real vs.
effective id behaviour.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* Re: [1/5] Parsing code in revision.h
From: Daniel Barkalow @ 2005-04-17 19:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0504171114020.7211@ppc970.osdl.org>
On Sun, 17 Apr 2005, Linus Torvalds wrote:
> On Sun, 17 Apr 2005, Daniel Barkalow wrote:
> >
> > --- 45f926575d2c44072bfcf2317dbf3f0fbb513a4e/revision.h (mode:100644 sha1:28d0de3261a61f68e4e0948a25a416a515cd2e83)
> > +++ 37a0b01b85c2999243674d48bfc71cdba0e5518e/revision.h (mode:100644 sha1:523bde6e14e18bb0ecbded8f83ad4df93fc467ab)
> > @@ -24,6 +24,7 @@
> > unsigned int flags;
> > unsigned char sha1[20];
> > unsigned long date;
> > + unsigned char tree[20];
> > struct parent *parent;
> > };
> >
>
> I think this is really wrong.
>
> The whole point of "revision.h" is that it's a generic framework for
> keeping track of relationships between different objects. And those
> objects are in no way just "commit" objects.
>
> For example, fsck uses this "struct revision" to create a full free of
> _all_ the object dependencies, which means that a "struct revision" can be
> any object at all - it's not in any way limited to commit objects, and
> there is no "tree" object that is associated with these things at all.
I entirely missed this. No wonder my fsck-cache conversion wasn't going
so well...
> Besides, why do you want the tree? There's really nothing you can do with
> the tree to a first approximation - you need to _first_ do the
> reachability analysis entirely on the commit dependencies, and then when
> you've selected a set of commits, you can just output those.
I actually want the tree for http-pull, not merging stuff. I was trying to
get a commit parser, not reachability at that point.
I think the right thing is to make a separate struct commit that has the
stuff I want in it, and probably do a struct tree at the same time.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [3/5] Add http-pull
From: Petr Baudis @ 2005-04-17 19:08 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.21.0504171412350.30848-100000@iabervon.org>
Dear diary, on Sun, Apr 17, 2005 at 08:49:11PM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> On Sun, 17 Apr 2005, Petr Baudis wrote:
> > > Index: http-pull.c
> > > ===================================================================
> > > --- /dev/null (tree:d662b707e11391f6cfe597fd4d0bf9c41d34d01a)
> > > +++ 157b46ce1d82b3579e2e1258927b0d9bdbc033ab/http-pull.c (mode:100644 sha1:106ca31239e6afe6784e7c592234406f5c149e44)
> > > + url = malloc(strlen(base) + 50);
> >
> > Off-by-one. What about the trailing NUL?
>
> I get length(base) + "object/"=8 + 40 SHA1 + 1 for '/' and 1 for NUL = 50.
Sorry, counted one '/' more. :-)
> > I think you should have at least two disjunct modes - either you are
> > downloading everything related to the given commit, or you are
> > downloading all commit records for commit predecessors.
> >
> > Even if you might not want all the intermediate trees, you definitively
> > want the intermediate commits, to keep the history graph contignuous.
> >
> > So in git pull, I'd imagine to do
> >
> > http-pull -c $new_head
> > http-pull -t $(tree-id $new_head)
> >
> > So, -c would fetch a given commit and all its predecessors until it hits
> > what you already have on your side. -t would fetch a given tree with all
> > files and subtrees and everything. http-pull shouldn't default on
> > either, since they are mutually exclusive.
> >
> > What do you think?
>
> I think I'd rather keep the current behavior and add a -c for getting the
> history of commits, and maybe a -a for getting the history of commits and
> their tress.
I'm not too kind at this. Either make it totally separate commands, or
make a required switch specifying what to do. Otherwise it implies the
switches would just modify what it does, but they make it do something
completely different.
-a would be fine too - basically a combination of -c and -t. I'd imagine
that is what Linus would want to use, e.g.
> There's some trickiness for the history of commits thing for stopping at
> the point where you have everything, but also behaving appropriately if
> you try once, fail partway through, and then try again. It's on my queue
> of things to think about.
Can't you just stop the recursion when you hit a commit you already
have?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Russell King @ 2005-04-17 18:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Peter Anvin
In-Reply-To: <Pine.LNX.4.58.0504170926410.7211@ppc970.osdl.org>
On Sun, Apr 17, 2005 at 09:36:09AM -0700, Linus Torvalds wrote:
> On Sun, 17 Apr 2005, Russell King wrote:
> > On Sat, Apr 16, 2005 at 04:01:45PM -0700, Linus Torvalds wrote:
> > > So I re-created the dang thing (hey, it takes just a few minutes), and
> > > pushed it out, and there's now an archive on kernel.org in my public
> > > "personal" directory called "linux-2.6.git". I'll continue the tradition
> > > of naming git-archive directories as "*.git", since that really ends up
> > > being the ".git" directory for the checked-out thing.
> >
> > We need to work out how we're going to manage to get our git changes to
> > you. At the moment, I've very little idea how to do that. Ideas?
>
> To me, merging is my highest priority. I suspect that once I have a tree
> from you (or anybody else) that I actually _test_ merging with, I'll be
> motivated as hell to make sure that my plumbing actually works.
Ok, I'll throw this tree onto master.kernel.org - how about
master.kernel.org:/home/rmk/linux-2.6-rmk.git ? I think it's in the
same format as your trees:
linux-2.6-rmk.git
|-- HEAD
`-- objects
where HEAD was copied from my .git/heads/master, and objects from
.git/objects.
> > However, I've made a start to generate the necessary emails. How about
> > this format?
> >
> > I'm not keen on the tree, parent, author and committer objects appearing
> > in this - they appear to clutter it up. What're your thoughts?
>
> Indeed. I'd almost drop the whole header except for the "author" line.
Done.
> Oh, and you need a separator between commits, right now your
> "Signed-off-by:" line ends up butting up with the header of the next
> commit ;)
Done.
> > I'd rather not have the FQDN of the machine where the commit happened
> > appearing in the logs.
>
> That's fine. Out short-logs have always tried to have just the real name
> in them, and I do want an email-like thing for tracking the developer, but
> yes, if you remove the email, that's fine. It should be easy enough to do
> with a simple
>
> sed 's/<.*>//'
>
> or similar.
Done.
> And if you replace "author" with "From:" and do the date conversion, it
> might look more natural.
Also done. 8)
I still need to work out how to make my noddy script follow different
branches which may be present though. However, for my common work
flow, it fits what I require.
Ok, how about this format:
Linus,
Please incorporate the latest ARM changes.
This will update the following files:
arch/arm/kernel/process.c | 15 +++++++++++----
arch/arm/kernel/traps.c | 8 ++------
arch/arm/lib/changebit.S | 11 ++---------
arch/arm/lib/clearbit.S | 13 ++-----------
arch/arm/lib/setbit.S | 11 ++---------
arch/arm/lib/testchangebit.S | 15 ++-------------
arch/arm/lib/testclearbit.S | 15 ++-------------
arch/arm/lib/testsetbit.S | 15 ++-------------
arch/arm/mach-footbridge/dc21285-timer.c | 4 ++--
arch/arm/mach-sa1100/h3600.c | 2 +-
include/asm-arm/arch-ebsa285/debug-macro.S | 7 +++++--
include/asm-arm/arch-rpc/debug-macro.S | 5 ++++-
include/asm-arm/ptrace.h | 5 +----
include/asm-arm/system.h | 3 +++
14 files changed, 41 insertions(+), 88 deletions(-)
through these ChangeSets:
Author: Russell King: Sun Apr 17 16:28:31 BST 2005
[PATCH] ARM: fix debug macros
Fix debug EBSA285 and RiscPC debugging macros to detect whether the
MMU is enabled.
Signed-off-by: Russell King
Author: Russell King: Sun Apr 17 15:51:02 BST 2005
[PATCH] ARM: bitops
Convert ARM bitop assembly to a macro. All bitops follow the same
format, so it's silly duplicating the code when only one or two
instructions are different.
Signed-off-by: Russell King
Author: Russell King: Sun Apr 17 15:50:36 BST 2005
[PATCH] ARM: showregs
Fix show_regs() to provide a backtrace. Provide a new __show_regs()
function which implements the common subset of show_regs() and die().
Add prototypes to asm-arm/system.h
Signed-off-by: Russell King
Author: Russell King: Sun Apr 17 15:40:46 BST 2005
[PATCH] ARM: h3600_irda_set_speed arguments
h3600_irda_set_speed() had the wrong type for the "speed" argument.
Fix this.
Signed-off-by: Russell King
Author: Russell King: Sun Apr 17 15:36:55 BST 2005
[PATCH] ARM: footbridge rtc init
The footbridge ISA RTC was being initialised before we had setup the
kernel timer. This caused a divide by zero error when the current
time of day is set. Resolve this by initialising the RTC after
the kernel timer has been initialised.
Signed-off-by: Russell King
--
Russell King
^ permalink raw reply
* [3.1/5] Add http-pull
From: Daniel Barkalow @ 2005-04-17 18:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <Pine.LNX.4.21.0504171127160.30848-100000@iabervon.org>
http-pull is a program that downloads from a (normal) HTTP server a commit
and all of the tree and blob objects it refers to (but not other commits,
etc.). Options could be used to make it download a larger or different
selection of objects.
Signed-Off-By: Daniel Barkalow <barkalow@iabervon.org>
Index: Makefile
===================================================================
--- 45f926575d2c44072bfcf2317dbf3f0fbb513a4e/Makefile (mode:100644 sha1:346e3850de026485802e41e16a1180be2df85e4a)
+++ 3eae85f66143160a26f5545d197862c89e2a8fb8/Makefile (mode:100644 sha1:0e84e3cd12f836602b420c197e08fabefe975493)
@@ -14,7 +17,7 @@
PROG= update-cache show-diff init-db write-tree read-tree commit-tree \
cat-file fsck-cache checkout-cache diff-tree rev-tree show-files \
- check-files ls-tree merge-base
+ check-files ls-tree http-pull merge-base
SCRIPT= parent-id tree-id git gitXnormid.sh gitadd.sh gitaddremote.sh \
gitcommit.sh gitdiff-do gitdiff.sh gitlog.sh gitls.sh gitlsobj.sh \
@@ -35,6 +38,7 @@
LIBS= -lssl -lz
+http-pull: LIBS += -lcurl
$(PROG):%: %.o $(COMMON)
$(CC) $(CFLAGS) -o $@ $^ $(LIBS)
Index: README
===================================================================
--- 45f926575d2c44072bfcf2317dbf3f0fbb513a4e/README (mode:100664 sha1:0170eafb60ad9009ca41c6536cecd6d1fdee5b86)
+++ 3eae85f66143160a26f5545d197862c89e2a8fb8/README (mode:100664 sha1:921d552d810394e665323ec82b4826914918689c)
@@ -120,7 +120,7 @@
diff, patch
libssl
rsync
-
+ curl (later than 7.7, according to the docs)
The "core GIT"
Index: http-pull.c
===================================================================
--- /dev/null (tree:45f926575d2c44072bfcf2317dbf3f0fbb513a4e)
+++ 3eae85f66143160a26f5545d197862c89e2a8fb8/http-pull.c (mode:100644 sha1:7ba4ad67f6dac34addb537ee147ae3de0550a484)
@@ -0,0 +1,139 @@
+#include <fcntl.h>
+#include <unistd.h>
+#include <string.h>
+#include <stdlib.h>
+#include "cache.h"
+#include "revision.h"
+#include <errno.h>
+#include <stdio.h>
+
+#include <curl/curl.h>
+#include <curl/easy.h>
+
+static CURL *curl;
+
+static char *base;
+
+static int fetch(unsigned char *sha1)
+{
+ char *hex = sha1_to_hex(sha1);
+ char *filename = sha1_file_name(sha1);
+
+ char *url;
+ char *posn;
+ FILE *local;
+
+ if (!access(filename, R_OK)) {
+ return 0;
+ }
+
+ local = fopen(filename, "w");
+
+ if (!local) {
+ return error("Couldn't open %s", filename);
+ }
+
+ curl_easy_setopt(curl, CURLOPT_FILE, local);
+
+ url = malloc(strlen(base) + 50);
+ strcpy(url, base);
+ posn = url + strlen(base);
+ strcpy(posn, "objects/");
+ posn += 8;
+ memcpy(posn, hex, 2);
+ posn += 2;
+ *(posn++) = '/';
+ strcpy(posn, hex + 2);
+
+ curl_easy_setopt(curl, CURLOPT_URL, url);
+
+ if (curl_easy_perform(curl)) {
+ fclose(local);
+ unlink(filename);
+ return error("Error downloading %s from %s",
+ sha1_to_hex(sha1), url);
+ }
+
+ fclose(local);
+
+ return 0;
+}
+
+static int process_tree(unsigned char *sha1)
+{
+ void *buffer;
+ unsigned long size;
+ char type[20];
+
+ buffer = read_sha1_file(sha1, type, &size);
+ if (!buffer)
+ return error("Couldn't read %s.",
+ sha1_to_hex(sha1));
+ if (strcmp(type, "tree"))
+ return error("Expected %s to be a tree, but was a %s.",
+ sha1_to_hex(sha1), type);
+ while (size) {
+ int len = strlen(buffer) + 1;
+ unsigned char *sha1 = buffer + len;
+ unsigned int mode;
+ int retval;
+
+ if (size < len + 20 || sscanf(buffer, "%o", &mode) != 1)
+ return error("Invalid tree object");
+
+ buffer = sha1 + 20;
+ size -= len + 20;
+
+ retval = fetch(sha1);
+ if (retval)
+ return retval;
+
+ if (S_ISDIR(mode)) {
+ retval = process_tree(sha1);
+ if (retval)
+ return retval;
+ }
+ }
+ return 0;
+}
+
+static int process_commit(unsigned char *sha1)
+{
+ int retval;
+ struct revision *rev = lookup_rev(sha1);
+ if (parse_commit_object(rev))
+ return error("Couldn't parse commit %s\n", sha1_to_hex(sha1));
+
+ retval = fetch(rev->tree);
+ if (retval)
+ return retval;
+ retval = process_tree(rev->tree);
+ return retval;
+}
+
+int main(int argc, char **argv)
+{
+ char *commit_id = argv[1];
+ char *url = argv[2];
+ int retval;
+
+ unsigned char sha1[20];
+
+ get_sha1_hex(commit_id, sha1);
+
+ curl_global_init(CURL_GLOBAL_ALL);
+
+ curl = curl_easy_init();
+
+ base = url;
+
+ retval = fetch(sha1);
+ if (retval)
+ return 1;
+ retval = process_commit(sha1);
+ if (retval)
+ return 1;
+
+ curl_global_cleanup();
+ return 0;
+}
^ permalink raw reply
* Re: [4/5] Add option for hardlinkable cache of extracted blobs
From: Daniel Barkalow @ 2005-04-17 18:54 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050417174736.GA1461@pasky.ji.cz>
Drop this one for now; I'll revisit it once more important stuff is
settled down.
-Daniel
*This .sig left intentionally blank*
^ 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