* Re: Careful object writing..
From: Linus Torvalds @ 2005-05-03 22:13 UTC (permalink / raw)
To: Jan Harkes; +Cc: Git Mailing List
In-Reply-To: <20050503205957.GA25253@delft.aura.cs.cmu.edu>
On Tue, 3 May 2005, Jan Harkes wrote:
>
> Short summary:
>
> rc = link(old, new);
> if (rc == -1 && errno == EXDEV)
> rc = rename(old, new);
Ok, that is safe enough. Will do.
> On Coda, the cross-directory link fails, the following cross-directory
> rename will work fine. On a normal filesystem, if the link fails with
> EXDEV, the rename will fail with the same.
Yup. I do suspect that since you handle the rename anyway, you probably
could handle the git link/unlink patterns too, but it's easy enough to
just do the rename fallback in git itself.
The only reason not to use rename in the first place is literally just to
be able to check for collisions. Which we don't actually _do_ right now,
but I like to be able to do so in theory.
Linus
^ permalink raw reply
* Kernel autobuild now uses Git
From: Darren Williams @ 2005-05-03 22:29 UTC (permalink / raw)
To: LKML, Ia64 Linux; +Cc: Git Mailing List
Hi All
Our ia64 autobuild system has been moved from using
BK to Git. Here we do a nightly pull on Linus's
(not so mainline) Git tree and test the ia64 build.
This may be a benefit to the Git developers to see
the results of a nightly 'cg-pull'.
Thanks to all for the effort, the conversation from BK
to Git was relatively painless.
- dsw
--------------------------------------------------
Darren Williams <dsw AT gelato.unsw.edu.au>
Gelato@UNSW <www.gelato.unsw.edu.au>
--------------------------------------------------
^ permalink raw reply
* Re: Careful object writing..
From: Linus Torvalds @ 2005-05-03 22:37 UTC (permalink / raw)
To: Jan Harkes, Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <20050503200034.GA16104@delft.aura.cs.cmu.edu>
On Tue, 3 May 2005, Jan Harkes wrote:
>
> I tried to pull in the latest version of your tree, but it doesn't look
> like this commit has propagated to rsync.kernel.org yet.
Hmm.. It's still not there a few hours later. I wonder what the mirroring
rules are. Or maybe mirroring is just broken right now. Peter?
One change introduced by me is that the new objects changed from 0664
(-rw-rw-r--) to (0444) -r--r--r-- due to the object writing rules. Maybe
the mirroring decides that such objects shouldn't be mirrored, since they
are "private"?
Or maybe it's just that Peter has shut down mirroring in preparation for
the imminent memory upgrade on master.kernel.org.
Linus
^ permalink raw reply
* Re: Careful object writing..
From: H. Peter Anvin @ 2005-05-03 22:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jan Harkes, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505031531270.26698@ppc970.osdl.org>
Linus Torvalds wrote:
>
> On Tue, 3 May 2005, Jan Harkes wrote:
>
>>I tried to pull in the latest version of your tree, but it doesn't look
>>like this commit has propagated to rsync.kernel.org yet.
>
>
> Hmm.. It's still not there a few hours later. I wonder what the mirroring
> rules are. Or maybe mirroring is just broken right now. Peter?
>
> One change introduced by me is that the new objects changed from 0664
> (-rw-rw-r--) to (0444) -r--r--r-- due to the object writing rules. Maybe
> the mirroring decides that such objects shouldn't be mirrored, since they
> are "private"?
>
> Or maybe it's just that Peter has shut down mirroring in preparation for
> the imminent memory upgrade on master.kernel.org.
>
No, I had stopped the cron job to fix a script bug and forgot to turn it
back on. It's pushing now.
-hpa
^ permalink raw reply
* Re: git and symlinks as tracked content
From: Junio C Hamano @ 2005-05-03 22:44 UTC (permalink / raw)
To: Andreas Gal; +Cc: Linus Torvalds, Kay Sievers, git
In-Reply-To: <Pine.LNX.4.58.0505031446220.31626@sam.ics.uci.edu>
>>>>> "AG" == Andreas Gal <gal@uci.edu> writes:
AG> Whether you use an explicit "dev" type or an implicit "dev"
AG> type that calls itself "blob" and uses a magic mode flag to
AG> tell checkout that it needs special treatment doesn't make a
AG> difference.
True. The use of word "wrong" in my message was _wrong_. But
my gut feeling is that the code that has to deal with the dev
and symlink stuff would be simpler if we just stick to the blob
type.
AG> When was the last time you tried to version control /dev? ;)
Tried? Never. Wished? Number of times. It's just that there
is no such SCM that does this natively, so I keep "ls -l /dev"
output under CVS control as a rough approximation.
^ permalink raw reply
* Re: git and symlinks as tracked content
From: H. Peter Anvin @ 2005-05-03 22:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Andreas Gal, Kay Sievers, git
In-Reply-To: <7vr7got2tz.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> Introducing "dev" type, as Andreas suggests, is wrong. This
> this should be done in the same way as you suggested for the
> symlink case. Store a blob object with those chrdev or blkdev
> modes whose contents are of form:
>
> major=14
> minor=4
> owner=root
> group=audio
> perm=0660
>
> This would impact the diff side least, and for the cache side it
> does not matter in storing and merging. checkout-cache still
> needs to know about this.
>
Owner and permissions are part of the tree object, and apply to all file
types. The only thing equivalent to file data is the major,minor;
storing it as a comma-separated decimal ASCII string is probably the
cleanest, i.e. for your exaple:
14,4
-hpa
^ permalink raw reply
* [PATCH] extend cg-export to support release tarball creation
From: Mark Allen @ 2005-05-03 22:57 UTC (permalink / raw)
To: Petr Baudis, Chris Wright; +Cc: git
Here's a patch for cg-export which supports a "-r RELEASE" option. It will export the
specific ID or HEAD and then create a tar gz and a tar bz2 in your previous working
directory using RELEASE as the tarball name and the directory inside the tarball.
Within cogito itself,
cg-export -r $(cat VERSION) /tmp/foo
seems to work quite nicely to make release tarballs.
Unlike my previous attempt, this one does not make evil tarballs. :-) One could insert a
script to update the .spec file before the tarfiles get created if desired.
Cheers,
--Mark
Signed-off-by: Mark Allen <mrallen1@yahoo.com>
Index: cg-export
===================================================================
--- aa6233be6d1b8bf42797c409a7c23b50593afc99/cg-export (mode:100755
sha1:a4497314ab33f6a6387bc278e84f88d4442070ce)
+++ uncommitted/cg-export (mode:100755 sha1:b0dfdf6049e7a074ef8c8c3f6a43e04a30e5cb89)
@@ -8,10 +8,17 @@
. cg-Xlib
-destdir=$1
-id=$(tree-id $2)
-([ "$destdir" ] && [ "$id" ]) || die "usage: cg-export DESTDIR [TREE_ID]"
+if [ "$1" = "-r" ]; then
+ release=$2
+ destdir="$3/$2"
+ id=$(tree-id $4)
+else
+ destdir=$1
+ id=$(tree-id $2)
+fi
+
+([ "$destdir" ] && [ "$id" ]) || die "usage: cg-export [-r RELEASE] DESTDIR [TREE_ID]"
[ -e "$destdir" ] && die "$destdir already exists."
@@ -20,3 +27,14 @@
git-read-tree $id
git-checkout-cache "--prefix=$destdir/" -a
rm $GIT_INDEX_FILE
+
+if [ "$1" = "-r" ]; then
+ origdir=$PWD
+ cd $destdir
+ cd ..
+ tar czf $origdir/$release.tar.gz $release
+ tar cjf $origdir/$release.tar.bz2 $release
+ cd $origdir
+else
+ exit 0
+fi
^ permalink raw reply
* Re: [PATCH 0/3] cogito spec file updates
From: Chris Wright @ 2005-05-03 23:01 UTC (permalink / raw)
To: Petr Baudis; +Cc: Chris Wright, Mark Allen, git
In-Reply-To: <20050503214401.GE15995@pasky.ji.cz>
* Petr Baudis (pasky@ucw.cz) wrote:
> I wouldn't accept this neither. If git.spec is already version
> controlled, it should be up-to-date in the version control. Therefore,
> you need to update it at the time of release, not at the time of
> generating the tarball.
*shrug*
Well, it's guaranteed to be one step out of sync, but I'll just keep
doing what I've been doing. Build rpm after you release, and send
patch ex-post-facto.
thanks,
-chris
^ permalink raw reply
* Re: Careful object writing..
From: Alex Riesen @ 2005-05-03 23:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505031204030.26698@ppc970.osdl.org>
On 5/3/05, Linus Torvalds <torvalds@osdl.org> wrote:
> I also change the permission to 0444 before it gets its final name.
Maybe umask it first? Just in case.
^ permalink raw reply
* Re: git and symlinks as tracked content
From: Junio C Hamano @ 2005-05-03 23:16 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, Andreas Gal, Kay Sievers, git
In-Reply-To: <42780185.7010204@zytor.com>
>>>>> "HPA" == H Peter Anvin <hpa@zytor.com> writes:
HPA> Owner and permissions are part of the tree object, and apply to all
HPA> file types.
Huh? I am confused... Do you mean tree object should be
changed to record these? That would make the existing in-cache
merging of files, which GIT was built for, quite interesting...
Well, doing device nodes _is_ a tangent, so let's drop this
discussion.
^ permalink raw reply
* Re: git and symlinks as tracked content
From: H. Peter Anvin @ 2005-05-03 23:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Andreas Gal, Kay Sievers, git
In-Reply-To: <7v1x8nuchr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>>>>>>"HPA" == H Peter Anvin <hpa@zytor.com> writes:
>
>
> HPA> Owner and permissions are part of the tree object, and apply to all
> HPA> file types.
>
> Huh? I am confused... Do you mean tree object should be
> changed to record these? That would make the existing in-cache
> merging of files, which GIT was built for, quite interesting...
>
> Well, doing device nodes _is_ a tangent, so let's drop this
> discussion.
>
No, the tree object *ALREADY* records these.
BLOB: A "blob" object is nothing but a binary blob of data, and doesn't
refer to anything else. There is no signature or any other verification
of the data, so while the object is consistent (it _is_ indexed by its
sha1 hash, so the data itself is certainly correct), it has absolutely
no other attributes. No name associations, no permissions. It is
purely a blob of data (ie normally "file contents").
TREE: The next hierarchical object type is the "tree" object. A tree
object is a list of permission/name/blob data, sorted by name. In other
words the tree object is uniquely determined by the set contents, and so
two separate but identical trees will always share the exact same
object.
-hpa
^ permalink raw reply
* Re: Careful object writing..
From: Linus Torvalds @ 2005-05-03 23:22 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <81b0412b05050316045fa31c2a@mail.gmail.com>
On Wed, 4 May 2005, Alex Riesen wrote:
>
> On 5/3/05, Linus Torvalds <torvalds@osdl.org> wrote:
> > I also change the permission to 0444 before it gets its final name.
>
> Maybe umask it first? Just in case.
I considered it, but it's not worth it.
If you don't want somebody else to see your objects, you should just
disable execute permission on your .git directory. "umask" is actually a
fairly nasty interface, since it takes effect on create(), and we do want
to fchmod _after_ the create (some filesystems don't like it when you
create a non-writable object and then write to it, but more importantly,
since we use "mkstemp()" for the temp-file handling, we don't even have
control of the initial umask.
So to make it (0444 & umask) git would actually have to jump through silly
hoops. Without actually buying you anything new, since the access
permissions for git objects really are about the _directory_ anyway.
Linus
^ permalink raw reply
* Re: Careful object writing..
From: Junio C Hamano @ 2005-05-03 23:22 UTC (permalink / raw)
To: Alex Riesen; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <81b0412b05050316045fa31c2a@mail.gmail.com>
>>>>> "AR" == Alex Riesen <raa.lkml@gmail.com> writes:
AR> On 5/3/05, Linus Torvalds <torvalds@osdl.org> wrote:
>> I also change the permission to 0444 before it gets its final name.
AR> Maybe umask it first? Just in case.
In general worrying about umask when you see chmod is a good
practice, but it probably is not applicable to this particular
case. A person with umask 077 should still get 0444 if the
SHA1_FILE_DIRECTORY is shared with other people, and if it is
not shared, his initial git-init-db would have made it 0700, so
it does not matter it the files files underneath it have 0444.
^ permalink raw reply
* Re: Careful object writing..
From: Alex Riesen @ 2005-05-03 23:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505031618360.26698@ppc970.osdl.org>
On 5/4/05, Linus Torvalds <torvalds@osdl.org> wrote:
> > > I also change the permission to 0444 before it gets its final name.
> > Maybe umask it first? Just in case.
>
> I considered it, but it's not worth it.
>
> If you don't want somebody else to see your objects, you should just
> disable execute permission on your .git directory. ...
Of course. It's leaves even more control to the user. Forget I asked :)
^ permalink raw reply
* Re: git and symlinks as tracked content
From: Linus Torvalds @ 2005-05-03 23:42 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, Andreas Gal, Kay Sievers, git
In-Reply-To: <427806CA.6030302@zytor.com>
On Tue, 3 May 2005, H. Peter Anvin wrote:
>
> No, the tree object *ALREADY* records these.
Not ownership.
Yes, the permissions are there, but if you actually want to track
ownership (or things like "mtime" etc), you really do have to track it
outside the tree object.
Also, right now git will actually ignore most of the permission bits too.
We can change that, and make it a dynamic setting somewhere (some flag in
a ".git/settings" file or something), but it does boil down to the fact
that a software development tree tracker wants different things than
something that tracks system settings.
For example, generating different trees just because different users had
different umask settings clearly didn't work out. Which means that right
now git really only tracks the "owner execute" bit of the permissions, and
always resets the other bits to 0755 or 0644 depending on that _one_ bit.
And similarly, tracking actual uid/gid information would _really_ not work
for a distributed kernel source management system, so that's not even in
the tree.
So if you want to track system files, right now "raw git" is _not_ the way
to do it. You'd want something else.
Of course, that's actually true largely even of normal /dev contents.
That's why we've moved towards udev, and having things like device
permissions and ownership not be "filesystem attributes", but really
_rules_ in a udev database. So the fact that git doesn't track them isn't
necessarily a problem for /dev - since modern /dev really wants to track
them at a higher level _anyway_ (and you'd use git to track the _rules_,
not the ownership things themselves).
But if you'd want to track other system directories with git, you'd
probably need to either (a) do serious surgery on git itself, or (probably
preferable) by (b) track the extra things you want "manually" using a file
(that is tracked in git) that describes the ownership and permission data.
Whether git is really suitable for tracking non-source projects is
obviously debatable. It's not what it was designed for, and it _may_ be
able to do so partly just by luck.
Linus
^ permalink raw reply
* Re: git and symlinks as tracked content
From: Junio C Hamano @ 2005-05-03 23:42 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, Andreas Gal, Kay Sievers, git
In-Reply-To: <427806CA.6030302@zytor.com>
>>>>> "HPA" == H Peter Anvin <hpa@zytor.com> writes:
HPA> Junio C Hamano wrote:
HPA> Owner and permissions are part of the tree object, and apply to
HPA> all file types.
>> Huh? I am confused... Do you mean tree object should be
>> changed to record these? That would make the existing in-cache
>> merging of files, which GIT was built for, quite interesting...
HPA> No, the tree object *ALREADY* records these.
As you quoted (and before I uttered my previous confusion I did
look at the code in write-tree.c which I thought to match this
description) ...
HPA> TREE: The next hierarchical object type is the "tree" object. A tree
HPA> object is a list of permission/name/blob data, sorted by name. In other
HPA> words the tree object is uniquely determined by the set contents, and so
HPA> two separate but identical trees will always share the exact same
HPA> object.
... it records permission (but not in the 0660 vs 0600 sense ---
it just records executable bit for file blobs and the treeness
by recording S_IFDIR), name and SHA1. There is no owner or
group information recorded there [*1*].
I am afraid I am missing something in my reading of write-tree.c
Quite confused...
[Footnote]
*1* Nor there should be. Otherwise comparing two identical
trees representing the same set of files become meaningless.
The reason why I placed these information in my hypothetical
representation of device nodes is exactly that. To record owner
and group information is meaningless and harmful for the purpose
of version controlling the source files but it matters _if_ we
wanted to maintain device nodes in GIT. Since it matters only
for those things, it would be preferable to have it as part of
the data that describes the object (i.e. device nodes), not part
of the data that contains the object (i.e. tree). And I thought
GIT tree object is already doing the right thing by not
recording them.
^ permalink raw reply
* Re: cogito "origin" vs. HEAD
From: Benjamin Herrenschmidt @ 2005-05-03 23:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <20050503094723.GA22436@pasky.ji.cz>
On Tue, 2005-05-03 at 11:47 +0200, Petr Baudis wrote:
> Dear diary, on Tue, May 03, 2005 at 09:13:28AM CEST, I got a letter
> where Benjamin Herrenschmidt <benh@kernel.crashing.org> told me that...
> > > when accessing the remote repository, Cogito always looks for remote
> > > refs/heads/master first - if that one isn't there, it takes HEAD, but
> > > there is no correlation between the local and remote branch name. If you
> > > want to fetch a different branch from the remote repository, use the
> > > fragment identifier (see cg-help cg-branch-add).
> >
> > Ok, that I'm getting. So then, what happen of my local
> > refs/heads/<branchname> and refs/heads/master/ ? I'm still a bit
> > confused by the whole branch mecanism... It's my understanding than when
> > I cg-init, it creates both "master" (a head without matching branch)
> > and "origin" (a branch + a head) both having the same sha1. It also
> > checks out the tree.
> >
> > Now, when I cg-update origin, what happens exactly ? I mean, I know it's
> > pulls all objects, then get the master from the remote pointed by the
> > origin branch, but then, I suppose it updates both my local "origin" and
> > my local "master" pointer, right ? I mean, they are always in sync ? Or
> > is this related to what branch my current checkout is tracking ?
>
> They are in sync as long as you update only from that given branch.
> At the moment you do a local commit, they get out of sync, at least
> until your master branch is merged to the origin branch on the other
> side. Every cg-update will then generate a merging commit, so it will
> look like this:
> > .../...
Thanks for that detailed explanation !
Ben.
^ permalink raw reply
* [PATCH] Making cg-seek more robust
From: Pavel Roskin @ 2005-05-04 0:08 UTC (permalink / raw)
To: git
Hello!
This patch does following:
If .git/HEAD is not a link, it's detected early, so that basename is not
called without arguments.
.git/HEAD is not deleted until validity of the branch is verified.
.git/blocked is deleted by "rm -f" to suppress unneeded error message if
it's missing.
Signed-off-by: Pavel Roskin <proski@gnu.org>
--- aa6233be6d1b8bf42797c409a7c23b50593afc99/cg-seek (mode:100755 sha1:111f7842e5ec20a1e0714e162ca221da5e06ce33)
+++ uncommitted/cg-seek (mode:100755)
@@ -29,18 +29,23 @@
if [ -s .git/blocked ]; then
branch=$(grep '^seeked from ' .git/blocked | sed 's/^seeked from //')
else
- branch=$(basename $(readlink .git/HEAD)) || die "HEAD is not on branch"
+ tmp=$(readlink .git/HEAD)
+ [ "$tmp" ] || die "HEAD is not on branch"
+ branch=$(basename "$tmp")
fi
curcommit=$(commit-id)
-rm .git/HEAD
if [ ! "$dstcommit" ] || [ "$dstcommit" = "$branch" ]; then
+ rm .git/HEAD
ln -s "refs/heads/$branch" .git/HEAD
- rm .git/blocked
+ rm -f .git/blocked
dstcommit=$(commit-id)
else
- echo $(commit-id "$dstcommit") >.git/HEAD
+ tmp=$(commit-id "$dstcommit")
+ [ "$tmp" ] || die "branch $dstcommit not found"
+ rm .git/HEAD
+ echo "$tmp" >.git/HEAD
[ -s .git/blocked ] || echo "seeked from $branch" >.git/blocked
fi
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Kernel autobuild now uses Git
From: Darren Williams @ 2005-05-04 0:20 UTC (permalink / raw)
To: LKML; +Cc: Ia64 Linux, Git Mailing List
In-Reply-To: <20050503222951.GE26031@cse.unsw.EDU.AU>
Hi Darren
On Wed, 04 May 2005, Darren Williams wrote:
> Hi All
> Our ia64 autobuild system has been moved from using
> BK to Git. Here we do a nightly pull on Linus's
> (not so mainline) Git tree and test the ia64 build.
>
> This may be a benefit to the Git developers to see
> the results of a nightly 'cg-pull'.
>
> Thanks to all for the effort, the conversation from BK
> to Git was relatively painless.
>
> - dsw
>
Hmmm, how about a URL
http://www.gelato.unsw.edu.au/kerncomp/
--------------------------------------------------
Darren Williams <dsw AT gelato.unsw.edu.au>
Gelato@UNSW <www.gelato.unsw.edu.au>
--------------------------------------------------
^ permalink raw reply
* Sym-links, b/c-special files, pipes, ... Scope Creep
From: Brian O'Mahoney @ 2005-05-04 0:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8y2wszdy.fsf@assigned-by-dhcp.cox.net>
Caution, let us all carefully understand the Source-Code/
Configuration Management issue.
I for one will be very happy if we get a really good distributed
SCM out of this.
Brian
^ permalink raw reply
* Re: Mercurial 0.4b vs git patchbomb benchmark (/usr/bin/env again)
From: David A. Wheeler @ 2005-05-04 2:10 UTC (permalink / raw)
To: Bill Davidsen
Cc: Valdis.Kletnieks, Andrea Arcangeli, Matt Mackall, Linus Torvalds,
linux-kernel, git
In-Reply-To: <4277B778.5020206@tmr.com>
Valdis.Kletnieks@vt.edu wrote:
>> Most likely, his python lives elsewhere than /usr/bin, and the 'env' call
>> results in causing a walk across $PATH to find it....
Bill Davidsen wrote:
> Assuming that he has env in a standard place... I hope this isn't going
> to start some rash of efforts to make packages run on non-standard
> toolchains, which add requirements for one tool to get around
> misplacement of another.
The #!/usr/bin/env prefix is, in my opinion, a very good idea.
There are a very few systems where env isn't in /usr/bin, but they
were extremely rare years ago & are essentially extinct now.
Basically, it's a 99% solution; getting the last 1% is really painful,
but since getting the 99% is easy, let's do it and be happy.
There are LOTS of systems where Python, bash, etc., do NOT
live in whatever place you think of as "standard".
I routinely use an OpenBSD 3.1 system; there is no /usr/bin/bash,
but there _IS_ a /usr/local/bin/bash (in my PATH) and a /usr/bin/env.
So this /usr/bin/env stuff REALLY is useful on a lot of systems, such
as OpenBSD. It's critical to me, at least!
This is actually really useful on ANY system, though.
Even if some interpreter IS where you think it should be,
that is NOT necessarily the interpreter you want to use.
Using "/usr/bin/env" lets you use PATH
to override things, so you don't HAVE to use the interpreter
in some fixed location. That's REALLY handy for testing... I
can download the whizbang Python 9.8.2, set it on the path,
and see if everything works as expected. It's also nice
if someone insists on never upgrading a package; you can
install an interpreter "locally". Yes, you can patch all the
files up, but resetting a PATH is _much_ easier.
--- David A. Wheeler
^ permalink raw reply
* Re: How to get bash to shut up about SIGPIPE?
From: David A. Wheeler @ 2005-05-04 2:30 UTC (permalink / raw)
To: Paul Jackson; +Cc: git
In-Reply-To: <20050502091027.6753998e.pj@sgi.com>
I reported:
>>One approach is to install a trap for SIGPIPE in
>>non-terminating command in a pipeline where the
>>later items might not process all the data, e.g.:
>> (trap {} SIGPIPE; find .) | head -1
Paul Jackson wrote:
> Both the versions of bash that I looked at (2.05 and 3.0) _still_
> complain even if SIGPIPE is trapped - they just complain with
> a more terse message, unless DONT_REPORT_SIGPIPE is not defined.
...
> What bash do you have that this trap silences?
Actually, I have a working bash, so I can't test any of
these work-arounds. I was merely foolish enough to quote
the Debian discussion, where someone reported that as a
work-around. I had hopes that it would help.
That'll teach me to pay attention to documentation :-).
I wonder, does a top-level trap work? E.g.:
trap "" SIGPIPE
...
Anyone, good luck to those with broken bashes...
--- David A. Wheeler
^ permalink raw reply
* Re: How to get bash to shut up about SIGPIPE?
From: Linus Torvalds @ 2005-05-04 2:50 UTC (permalink / raw)
To: David A. Wheeler; +Cc: Paul Jackson, Git Mailing List
In-Reply-To: <427833AE.6030505@dwheeler.com>
On Tue, 3 May 2005, David A. Wheeler wrote:
>
> I wonder, does a top-level trap work? E.g.:
> trap "" SIGPIPE
No.
But putting the traps _inside_ the loops seems to help. So something like
the appended at least makes it somewhat useful
And yes, you need them at both levels, it appears. Or maybe that just
changes the timing enough. Whatever.
Linus
----
Index: cg-log
===================================================================
--- aa6233be6d1b8bf42797c409a7c23b50593afc99/cg-log (mode:100755 sha1:aa2abf370753117a350818dbc91991b14d30ec6b)
+++ uncommitted/cg-log (mode:100755)
@@ -47,10 +47,12 @@
fi
$revls | $revsort | while read time commit parents; do
+ trap "exit 1" SIGPIPE
[ "$revfmt" = "git-rev-list" ] && commit="$time"
echo $colheader""commit ${commit%:*} $coldefault;
git-cat-file commit $commit | \
while read key rest; do
+ trap "exit 1" SIGPIPE
case "$key" in
"author"|"committer")
if [ "$key" = "author" ]; then
^ permalink raw reply
* Mercurial v0.4c
From: Matt Mackall @ 2005-05-04 2:58 UTC (permalink / raw)
To: linux-kernel, git, Linus Torvalds
A new version of Mercurial is available at:
http://selenic.com/mercurial/
This version is officially self-hosting, now that I've added the final
planned changed to the metadata. To pull the repo, do:
hg init
hg merge http://selenic.com/hg
This version fixes numerous reported bugs, adds a "verify" command to
check the repository integrity, transaction handling, and some minor
speed improvements.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* [PATCH] Careful object pulling
From: Daniel Barkalow @ 2005-05-04 4:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505031204030.26698@ppc970.osdl.org>
This splits out the careful methods for writing a file and placing it in
the correct location from the function to write a buffer to the file and
makes the various functions used by git-*-pull programs use those
functions to write their files.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Index: cache.h
===================================================================
--- 51a882a2dc62e0d3cdc79e0badc61559fb723481/cache.h (mode:100644 sha1:8dd812827604d510038f5d93e3718c43f9d12c30)
+++ 4e31436bacfff09ce673665a1061b41e37ffd661/cache.h (mode:100644 sha1:0d7411c3b86a899cee45627997f4bb7ba0df2ea7)
@@ -134,6 +134,12 @@
extern void * read_sha1_file(const unsigned char *sha1, char *type, unsigned long *size);
extern int write_sha1_file(char *buf, unsigned long len, const char *type, unsigned char *return_sha1);
+/* Open a file for writing a sha1 file. */
+extern int open_sha1_tmpfile(char tmpfile[PATH_MAX]);
+
+/* Put a sha1 file in the correct place. */
+extern int place_sha1_file(char tmpfile[PATH_MAX], const unsigned char *sha1);
+
extern int check_sha1_signature(unsigned char *sha1, void *buf, unsigned long size, const char *type);
/* Read a tree into the cache */
Index: http-pull.c
===================================================================
--- 51a882a2dc62e0d3cdc79e0badc61559fb723481/http-pull.c (mode:100644 sha1:f693aba61b4dcb4b738faf1335ec74aa1545e45d)
+++ 4e31436bacfff09ce673665a1061b41e37ffd661/http-pull.c (mode:100644 sha1:793d8b9e125c1f164f774e2888d26beaa75e1df0)
@@ -52,8 +52,9 @@
char real_sha1[20];
char *url;
char *posn;
+ char tmpname[PATH_MAX];
- local = open(filename, O_WRONLY | O_CREAT | O_EXCL, 0666);
+ local = open_sha1_tmpfile(tmpname);
if (local < 0)
return error("Couldn't open %s\n", filename);
@@ -88,15 +89,14 @@
inflateEnd(&stream);
SHA1_Final(real_sha1, &c);
if (zret != Z_STREAM_END) {
- unlink(filename);
+ unlink(tmpname);
return error("File %s (%s) corrupt\n", hex, url);
}
if (memcmp(sha1, real_sha1, 20)) {
- unlink(filename);
+ unlink(tmpname);
return error("File %s has bad hash\n", hex);
}
-
- return 0;
+ return place_sha1_file(tmpname, sha1);
}
int main(int argc, char **argv)
Index: sha1_file.c
===================================================================
--- 51a882a2dc62e0d3cdc79e0badc61559fb723481/sha1_file.c (mode:100644 sha1:e6ce455ae90bd430f2128f454bdb6e0575412486)
+++ 4e31436bacfff09ce673665a1061b41e37ffd661/sha1_file.c (mode:100644 sha1:85daa0b0045c3f19e697d1a7aa8ab15ff54eab99)
@@ -276,6 +276,55 @@
}
}
+int open_sha1_tmpfile(char tmpfile[PATH_MAX])
+{
+ int fd;
+
+ snprintf(tmpfile, sizeof(tmpfile), "%s/obj_XXXXXX", get_object_directory());
+ fd = mkstemp(tmpfile);
+ if (fd < 0) {
+ fprintf(stderr,
+ "unable to create temporary sha1 filename %s: %s",
+ tmpfile, strerror(errno));
+ return -1;
+ }
+ return fd;
+}
+
+int place_sha1_file(char tmpfile[PATH_MAX], const unsigned char *sha1)
+{
+ char *filename = sha1_file_name(sha1);
+ int ret;
+
+ ret = link(tmpfile, filename);
+ if (ret < 0) {
+ ret = errno;
+
+ /*
+ * Coda hack - coda doesn't like cross-directory links,
+ * so we fall back to a rename, which will mean that it
+ * won't be able to check collisions, but that's not a
+ * big deal.
+ *
+ * When this succeeds, we just return 0. We have nothing
+ * left to unlink.
+ */
+ if (ret == EXDEV && !rename(tmpfile, filename))
+ return 0;
+ }
+ unlink(tmpfile);
+ if (ret) {
+ if (ret != EEXIST) {
+ fprintf(stderr,
+ "unable to write sha1 filename %s: %s",
+ filename, strerror(ret));
+ return -1;
+ }
+ /* FIXME!!! Collision check here ? */
+ }
+ return 0;
+}
+
int write_sha1_file(char *buf, unsigned long len, const char *type, unsigned char *returnsha1)
{
int size;
@@ -286,7 +335,7 @@
char *filename;
static char tmpfile[PATH_MAX];
char hdr[50];
- int fd, hdrlen, ret;
+ int fd, hdrlen;
/* Generate the header */
hdrlen = sprintf(hdr, "%s %lu", type, len)+1;
@@ -316,12 +365,9 @@
return -1;
}
- snprintf(tmpfile, sizeof(tmpfile), "%s/obj_XXXXXX", get_object_directory());
- fd = mkstemp(tmpfile);
- if (fd < 0) {
- fprintf(stderr, "unable to create temporary sha1 filename %s: %s", tmpfile, strerror(errno));
- return -1;
- }
+ fd = open_sha1_tmpfile(tmpfile);
+ if (fd < 0)
+ return fd;
/* Set it up */
memset(&stream, 0, sizeof(stream));
@@ -349,53 +395,28 @@
if (write(fd, compressed, size) != size)
die("unable to write file");
+
fchmod(fd, 0444);
close(fd);
- ret = link(tmpfile, filename);
- if (ret < 0) {
- ret = errno;
-
- /*
- * Coda hack - coda doesn't like cross-directory links,
- * so we fall back to a rename, which will mean that it
- * won't be able to check collisions, but that's not a
- * big deal.
- *
- * When this succeeds, we just return 0. We have nothing
- * left to unlink.
- */
- if (ret == EXDEV && !rename(tmpfile, filename))
- return 0;
- }
- unlink(tmpfile);
- if (ret) {
- if (ret != EEXIST) {
- fprintf(stderr, "unable to write sha1 filename %s: %s", filename, strerror(ret));
- return -1;
- }
- /* FIXME!!! Collision check here ? */
- }
-
- return 0;
+ return place_sha1_file(tmpfile, sha1);
}
int write_sha1_from_fd(const unsigned char *sha1, int fd)
{
- char *filename = sha1_file_name(sha1);
-
int local;
z_stream stream;
unsigned char real_sha1[20];
char buf[4096];
char discard[4096];
+ char tmpname[PATH_MAX];
int ret;
SHA_CTX c;
- local = open(filename, O_WRONLY | O_CREAT | O_EXCL, 0666);
+ local = open_sha1_tmpfile(tmpname);
if (local < 0)
- return error("Couldn't open %s\n", filename);
+ return -1;
memset(&stream, 0, sizeof(stream));
@@ -408,7 +429,7 @@
size = read(fd, buf, 4096);
if (size <= 0) {
close(local);
- unlink(filename);
+ unlink(tmpname);
if (!size)
return error("Connection closed?");
perror("Reading from connection");
@@ -431,15 +452,15 @@
close(local);
SHA1_Final(real_sha1, &c);
if (ret != Z_STREAM_END) {
- unlink(filename);
+ unlink(tmpname);
return error("File %s corrupted", sha1_to_hex(sha1));
}
if (memcmp(sha1, real_sha1, 20)) {
- unlink(filename);
+ unlink(tmpname);
return error("File %s has bad hash\n", sha1_to_hex(sha1));
}
-
- return 0;
+
+ return place_sha1_file(tmpname, sha1);
}
int has_sha1_file(const unsigned char *sha1)
^ 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