* Re: How to get bash to shut up about SIGPIPE?
From: Paul Jackson @ 2005-04-30 0:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, pasky
In-Reply-To: <Pine.LNX.4.58.0504281121430.18901@ppc970.osdl.org>
> bash is being an ass about SIGPIPE
You have a multiprocessor, don't you.
The following silly little shell script will provoke the bash SIGPIPE
complaint reliably on a multiprocessor. It writes a big file, twice,
from a for-loop in a separate bash subshell through a pipe to a command
that exits after seeing one line.
Code Sample 1:
#!/bin/bash
for x in 1 2
do
cat /etc/termcap # a big text file
done | sed 1q
Adding a right trap _inside_ the shell loop that is _before_ the pipe
will reduce the verbosity of the complaint substantially (not show the
line number and text for each command inside the loop that is killed by
the SIGPIPE; rather just show the simple "Broken pipe" error message):
Code Sample 2:
#!/bin/bash
for x in 1 2
do
trap continue PIPE # reduce broken pipe screeching
cat /etc/termcap # a big text file
done | sed 1q
Then wrapping the entire pipeline (now that the bogus output is a
constant "Broken pipe" string) in the following manner will filter out
just that noise, leaving whatever else was on stdout and/or stderr
unscathed:
Code Sample 3:
#!/bin/bash
( ( (
for x in 1 2
do
trap continue PIPE # reduce broken pipe screeching
cat /etc/termcap # a big text file
done | sed 1q
) 1>&3 ) 2>&1 | grep -vxF 'Broken pipe' 1>&2 ) 3>&1
The following patch to bash jobs.c will enable "Code Sample 2" to do the
right thing, without depending (so much) on the DONT_REPORT_SIGPIPE
compile time flag. With this patch, you don't have to go all the way to
the baroque code in "Code Sample 3" to shut bash up. Just a well placed
trap is sufficient.
Whether or not this is actually worth persuing (or was even worth
reading ;) I don't know.
--- jobs.c.orig 2001-03-26 10:08:24.000000000 -0800
+++ jobs.c 2005-04-29 17:09:44.294763496 -0700
@@ -2686,11 +2686,8 @@ notify_of_job_status ()
}
else if (IS_FOREGROUND (job))
{
-#if !defined (DONT_REPORT_SIGPIPE)
- if (termsig && WIFSIGNALED (s) && termsig != SIGINT)
-#else
- if (termsig && WIFSIGNALED (s) && termsig != SIGINT && termsig != SIGPIPE)
-#endif
+ if (termsig && WIFSIGNALED (s) && termsig != SIGINT &&
+ (termsig != SIGPIPE || signal_is_trapped (termsig) == 0))
{
fprintf (stderr, "%s", strsignal (termsig));
--
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: Trying to use AUTHOR_DATE
From: tony.luck @ 2005-04-30 0:21 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <4272C4DE.8090806@zytor.com>
> There was a time-parsing bug somewhere, where mktime() got invoked on a
> UTC date. I proposed changing it to curl_gettime() instead.
Here's a patch to switch to using curl_getdate():
Signed-off-by: Tony Luck <tony.luck@intel.com>
---
Makefile | 1
commit-tree.c | 143 ++++------------------------------------------------------
2 files changed, 11 insertions(+), 133 deletions(-)
Makefile: d73bea1cbb9451a89b03d6066bf2ed7fec32fd31
--- k/Makefile
+++ l/Makefile
@@ -92,6 +92,7 @@ $(LIB_FILE): $(LIB_OBJS)
rpush: rsh.c
rpull: rsh.c
http-pull: LIBS += -lcurl
+commit-tree: LIBS += -lcurl
ifneq (,$(wildcard .git))
commit-tree.c: 23de13361944ad7ba7c5320cf7cdd04e81842c60
--- k/commit-tree.c
+++ l/commit-tree.c
@@ -10,6 +10,7 @@
#include <string.h>
#include <ctype.h>
#include <time.h>
+#include <curl/curl.h>
#define BLOCKING (1ul << 14)
@@ -80,146 +81,22 @@ static void remove_special(char *p)
}
}
-static const char *month_names[] = {
- "Jan", "Feb", "Mar", "Apr", "May", "Jun",
- "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"
-};
-
-static const char *weekday_names[] = {
- "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"
-};
-
-
-static char *skipfws(char *str)
-{
- while (isspace(*str))
- str++;
- return str;
-}
-
-
/* Gr. strptime is crap for this; it doesn't have a way to require RFC2822
(i.e. English) day/month names, and it doesn't work correctly with %z. */
-static void parse_rfc2822_date(char *date, char *result, int maxlen)
+static void parse_date(char *date, time_t *now, char *result, int maxlen)
{
- struct tm tm;
char *p;
- int i, offset;
time_t then;
- memset(&tm, 0, sizeof(tm));
-
- /* Skip day-name */
- p = skipfws(date);
- if (!isdigit(*p)) {
- for (i=0; i<7; i++) {
- if (!strncmp(p,weekday_names[i],3) && p[3] == ',') {
- p = skipfws(p+4);
- goto day;
- }
- }
- return;
- }
-
- /* day */
- day:
- tm.tm_mday = strtoul(p, &p, 10);
-
- if (tm.tm_mday < 1 || tm.tm_mday > 31)
- return;
-
- if (!isspace(*p))
- return;
-
- p = skipfws(p);
-
- /* month */
-
- for (i=0; i<12; i++) {
- if (!strncmp(p, month_names[i], 3) && isspace(p[3])) {
- tm.tm_mon = i;
- p = skipfws(p+strlen(month_names[i]));
- goto year;
- }
- }
- return; /* Error -- bad month */
-
- /* year */
- year:
- tm.tm_year = strtoul(p, &p, 10);
-
- if (!tm.tm_year && !isspace(*p))
- return;
-
- if (tm.tm_year > 1900)
- tm.tm_year -= 1900;
-
- p=skipfws(p);
-
- /* hour */
- if (!isdigit(*p))
- return;
- tm.tm_hour = strtoul(p, &p, 10);
-
- if (!tm.tm_hour > 23)
- return;
-
- if (*p != ':')
- return; /* Error -- bad time */
- p++;
-
- /* minute */
- if (!isdigit(*p))
- return;
- tm.tm_min = strtoul(p, &p, 10);
-
- if (!tm.tm_min > 59)
+ if ((then = curl_getdate(date, now)) == 0)
return;
- if (isspace(*p))
- goto zone;
-
- if (*p != ':')
- return; /* Error -- bad time */
- p++;
-
- /* second */
- if (!isdigit(*p))
- return;
- tm.tm_sec = strtoul(p, &p, 10);
-
- if (!tm.tm_sec > 59)
- return;
-
- if (!isspace(*p))
- return;
-
- zone:
- p = skipfws(p);
-
- if (*p == '-')
- offset = -60;
- else if (*p == '+')
- offset = 60;
- else
- return;
-
- if (!isdigit(p[1]) || !isdigit(p[2]) || !isdigit(p[3]) || !isdigit(p[4]))
- return;
-
- i = strtoul(p+1, NULL, 10);
- offset *= ((i % 100) + ((i / 100) * 60));
-
- if (*(skipfws(p + 5)))
- return;
-
- then = mktime(&tm); /* mktime appears to ignore the GMT offset, stupidly */
- if (then == -1)
- return;
-
- then -= offset;
-
- snprintf(result, maxlen, "%lu %5.5s", then, p);
+ /* find the timezone at the end */
+ p = date + strlen(date);
+ while (p > date && isdigit(*--p))
+ ;
+ if ((*p == '+' || *p == '-') && strlen(p) == 5)
+ snprintf(result, maxlen, "%lu %5.5s", then, p);
}
static void check_valid(unsigned char *sha1, const char *expect)
@@ -298,7 +175,7 @@ int main(int argc, char **argv)
email = getenv("AUTHOR_EMAIL") ? : realemail;
audate = getenv("AUTHOR_DATE");
if (audate)
- parse_rfc2822_date(audate, date, sizeof(date));
+ parse_date(audate, &now, date, sizeof(date));
remove_special(gecos); remove_special(realgecos); remove_special(commitgecos);
remove_special(email); remove_special(realemail); remove_special(commitemail);
^ permalink raw reply
* description
From: H. Peter Anvin @ 2005-04-30 0:14 UTC (permalink / raw)
To: Git Mailing List
I guess this is technically speaking complete nonstandard addition to
git :) but I have added the following to the script that generates
http://www.kernel.org/git/:
If there is a plain text file called "description" in the .git
directory, it will appear on that webpage.
-hpa
^ permalink raw reply
* Re: [PATCH] GIT: Create tar archives of tree on the fly
From: Rene Scharfe @ 2005-04-30 0:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504291522250.18901@ppc970.osdl.org>
Linus Torvalds schrieb:
>
> Having just done the git-0.7.tar.gz file with git-tar-tree, I started
> wondering if there is some nice way to encode the commit version
> that got tarred up into the tar archive itself.
The pax archive format allows for comments; you can store the commit ID
in a (archive-)global comment. Archivers are supposed to ignore it and
GNU tar at least does so. You can extract the ID with
$ dd bs=1 skip=523 count=41 2>/dev/null < TARFILE
because it would always end up at that position at the start of the archive.
Rene
^ permalink raw reply
* Re: The big git command renaming..
From: H. Peter Anvin @ 2005-04-29 23:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dave Jones, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504291638260.18901@ppc970.osdl.org>
Linus Torvalds wrote:
>
> On Fri, 29 Apr 2005, H. Peter Anvin wrote:
>
>>If you have any other non-kernel git projects, just let me know and I'll
>>make directories for them.
>
>
> The others are small and specialized (sparse, and the "git-tools" thing,
> and the latter is so much smaler than my BK tools used to be that I
> suspect I should just move it into git as the "apply mbox" import thing it
> is)
>
I created /pub/scm/devel/sparse to go along with
/pub/software/devel/sparse. I agree with git-tools; just put it in the
git directory (after all, you can have more than one dir.git underneath it.)
-hpa
^ permalink raw reply
* Re: The big git command renaming..
From: Linus Torvalds @ 2005-04-29 23:39 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Dave Jones, Git Mailing List
In-Reply-To: <4272BE9C.7090906@zytor.com>
On Fri, 29 Apr 2005, H. Peter Anvin wrote:
>
> If you have any other non-kernel git projects, just let me know and I'll
> make directories for them.
The others are small and specialized (sparse, and the "git-tools" thing,
and the latter is so much smaler than my BK tools used to be that I
suspect I should just move it into git as the "apply mbox" import thing it
is)
> P.S. Are you still updating the trees in
> /pub/linux/kernel/people/torvalds/? They still show up on our change
> reports, and cause problems for the mirrors. Perhaps you could replace
> those trees with symlinks into /pub/scm.
Fixed.
Linus
^ permalink raw reply
* Re: Trying to use AUTHOR_DATE
From: H. Peter Anvin @ 2005-04-29 23:35 UTC (permalink / raw)
To: tony.luck; +Cc: git
In-Reply-To: <200504292314.j3TNE1P23342@unix-os.sc.intel.com>
tony.luck@intel.com wrote:
> I'm using cogito-0.8 (036bb73c6dd1871101ca19557298684ab9832f81) and trying
> to set AUTHOR_DATE based on the "Date:" from the patch e-mail. But, it
> appears that commit-tree is munging this based on my timezone.
>
> Here's what I set in the environment before invoking cg-commit:
>
> AUTHOR_DATE="29 Apr 2005 02:02:00 -0700"
>
> and here's what cg-log reports on the "author" line:
>
> Fri, 29 Apr 2005 10:02:00 -0700
>
> My /etc/localtime is set for "US/Pacific" ... which is where the 8 hours
> comes from (I think). If I set "TZ=GMT0BST" as well in the environment of
> cg-commit to override /etc/localtime, then the author time comes out ok,
> but then the "committer" time gets messed up.
>
There was a time-parsing bug somewhere, where mktime() got invoked on a
UTC date. I proposed changing it to curl_gettime() instead.
-hpa
^ permalink raw reply
* Trying to use AUTHOR_DATE
From: tony.luck @ 2005-04-29 23:14 UTC (permalink / raw)
To: git
I'm using cogito-0.8 (036bb73c6dd1871101ca19557298684ab9832f81) and trying
to set AUTHOR_DATE based on the "Date:" from the patch e-mail. But, it
appears that commit-tree is munging this based on my timezone.
Here's what I set in the environment before invoking cg-commit:
AUTHOR_DATE="29 Apr 2005 02:02:00 -0700"
and here's what cg-log reports on the "author" line:
Fri, 29 Apr 2005 10:02:00 -0700
My /etc/localtime is set for "US/Pacific" ... which is where the 8 hours
comes from (I think). If I set "TZ=GMT0BST" as well in the environment of
cg-commit to override /etc/localtime, then the author time comes out ok,
but then the "committer" time gets messed up.
-Tony
^ permalink raw reply
* Re: The big git command renaming..
From: H. Peter Anvin @ 2005-04-29 23:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dave Jones, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504291511410.18901@ppc970.osdl.org>
Linus Torvalds wrote:
>
> Sure.
>
> Just a quick question: what are the "rules" for /pub/scm/git?
>
> Should I put just git in it, or is it meant for any "git project", and
> should I also copy the 2.6.x kernel home from
>
> /pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> to
>
> /pub/scm/git/linux-2.6.git
>
> or what?
>
> Me, I can do either or both, I just don't know what the intent was..
/pub/scm/git I created for your git project; don't move the kernel in there.
If you have any other non-kernel git projects, just let me know and I'll
make directories for them.
-hpa
P.S. Are you still updating the trees in
/pub/linux/kernel/people/torvalds/? They still show up on our change
reports, and cause problems for the mirrors. Perhaps you could replace
those trees with symlinks into /pub/scm.
-hpa
^ permalink raw reply
* Re: Mercurial 0.4b vs git patchbomb benchmark
From: Andrea Arcangeli @ 2005-04-29 22:47 UTC (permalink / raw)
To: Olivier Galibert, Sean, Matt Mackall, Linus Torvalds,
linux-kernel, git
In-Reply-To: <20050429223052.GD28540@dspnet.fr.eu.org>
On Sat, Apr 30, 2005 at 12:30:52AM +0200, Olivier Galibert wrote:
> Nothing a little caching can't solve. Given that git's objects are
> immutable caching is especially easy to do, you can have the delta
> reference indexes in the filename.
Rather than creating delta reference indexes we can as well use
mercurial that uses them as primary storage.
git is the _storage_ filesystem, if we can't use it but we've to create
another different representation to do efficient network download, we
can as well the more efficient representation instead of git, that's
what mercurial does AFIK.
^ permalink raw reply
* [PATCH] leftover bits for git rename
From: Junio C Hamano @ 2005-04-29 22:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
commit 2d280e1c5e6fdcf5428e60219eae14a2c6629c51
parent aed7a5a9dab96d1a17be4fadf7685086047178cc
author Linus Torvalds <torvalds@ppc970.osdl.org> Fri Apr 29 15:02:43 2005
committer Linus Torvalds <torvalds@ppc970.osdl.org> Fri Apr 29 15:02:43 2005
Update the merge scripts for the big git rename.
Let's see what else I forgot..
Not that many, but here they are.
Signed-off-by: Junio C Hamano <junkio@cox.net>
----
git-merge-one-file-script | 6 +++---
git-prune-script | 2 +-
git-tag-script | 2 +-
cd /opt/packrat/playpen/public/in-place/git/git.linus/
jit-snap -v 0
# - [PATCH] Makefile: The big git command renaming fallout fix.
# + working tree
--- k/git-merge-one-file-script (mode:100755)
+++ l/git-merge-one-file-script (mode:100755)
@@ -9,7 +9,7 @@
#
#
# Handle some trivial cases.. The _really_ trivial cases have
-# been handled already by read-tree, but that one doesn't
+# been handled already by git-read-tree, but that one doesn't
# do any merges that migth change the tree layout
#
@@ -41,7 +41,7 @@ case "${1:-.}${2:-.}${3:-.}" in
#
".$2." | "..$3" )
echo "Adding $4 with perm $6$7"
- mv $(unpack-file "$2$3") $4
+ mv $(git-unpack-file "$2$3") $4
chmod "$6$7" $4
git-update-cache --add -- $4
exit 0
@@ -55,7 +55,7 @@ case "${1:-.}${2:-.}${3:-.}" in
exit 1
fi
echo "Adding $4 with perm $6"
- mv $(unpack-file "$2") $4
+ mv $(git-unpack-file "$2") $4
chmod "$6" $4
git-update-cache --add -- $4
exit 0;;
--- k/git-prune-script (mode:100755)
+++ l/git-prune-script (mode:100755)
@@ -1,2 +1,2 @@
#!/bin/sh
-fsck-cache --unreachable $(cat .git/HEAD ) | grep unreachable | cut -d' ' -f3 | sed 's:^\(..\):.git/objects/\1/:' | xargs rm
+git-fsck-cache --unreachable $(cat .git/HEAD ) | grep unreachable | cut -d' ' -f3 | sed 's:^\(..\):.git/objects/\1/:' | xargs rm
--- k/git-tag-script (mode:100755)
+++ l/git-tag-script (mode:100755)
@@ -1,6 +1,6 @@
#!/bin/sh
object=${2:-$(cat .git/HEAD)}
-type=$(cat-file -t $object) || exit 1
+type=$(git-cat-file -t $object) || exit 1
( echo -e "object $object\ntype $type\ntag $1\n"; cat ) > .tmp-tag
rm -f .tmp-tag.asc
gpg -bsa .tmp-tag && cat .tmp-tag.asc >> .tmp-tag
^ permalink raw reply
* Re: Mercurial 0.4b vs git patchbomb benchmark
From: Olivier Galibert @ 2005-04-29 22:30 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: Sean, Matt Mackall, Linus Torvalds, linux-kernel, git
In-Reply-To: <20050429201957.GJ17379@opteron.random>
On Fri, Apr 29, 2005 at 10:19:57PM +0200, Andrea Arcangeli wrote:
> such a system might fall apart under load, converting on the fly from
> git to network-optimized format sound quite expensive operation, even
> ignorign the initial decompression of the payload.
Nothing a little caching can't solve. Given that git's objects are
immutable caching is especially easy to do, you can have the delta
reference indexes in the filename.
OG.
^ permalink raw reply
* Re: [PATCH] GIT: Create tar archives of tree on the fly
From: Linus Torvalds @ 2005-04-29 22:26 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <20050426144222.GA12035@lsrfire.ath.cx>
Having just done the git-0.7.tar.gz file with git-tar-tree, I started
wondering if there is some nice way to encode the commit version that got
tarred up into the tar archive itself.
There are various obvious ways, like creating a fake zero-sized file
called <base>/.git-version-<commit-id>, and maybe that's the right thing
to do. But maybe the tar archive format (and no, I don't even want to know
details) has some nice way to hide off a keyname even _without_ having to
create a file.
Would people like to have such a file for later? Obviously there would be
a need to suppress it with a command line flag if you don't want it (or
have a cmd line flag to enable it in the first place), what do people
think? Rene?
Linus
^ permalink raw reply
* Re: [PATCH] Make cg-clone handle local directories as sources
From: Ryan Anderson @ 2005-04-29 22:17 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20050429215928.GF1233@mythryan2.michonline.com>
cg-clone is described as only being used with remote repositories, but
it has the nice feature of creating the destination directory for you.
This patch adds two features:
1. A destination directory can (optionally) be specified.
2. The source directory can be in the local file system.
The following, for example, now works:
cg-clone rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
mkdir test ; cd test
cg-clone ../cogito ../cogito2/
(This version of the patch actually doesn't break existing
functionality.)
Index: cg-clone
===================================================================
--- c3aa1e6b53cc59d5fbe261f3f859584904ae3a63/cg-clone (mode:100755 sha1:4ee0685c358e094c5350b3968d013105da6ddf7e)
+++ 3dc3edca08f66f90147d0cb2240274072fa8644a/cg-clone (mode:100755 sha1:e42237e0408bc3f34cc70a956c29df1251bd1571)
@@ -11,13 +11,25 @@
. cg-Xlib
location=$1
-[ "$location" ] || die "usage: cg-clone SOURCE_LOC"
+[ "$location" ] || die "usage: cg-clone SOURCE_LOC [DEST_LOC]"
location=${location%/}
-dir=${location##*/}; dir=${dir%.git}
+if [ "$2" == "" ]; then
+ dir=${location##*/}; dir=${dir%.git}
+else
+ dir=$2
+fi
+
+pwd=$(pwd)
+if ! echo "$location" | grep -q ":" ; then
+ relative_location=$(echo "$location" | sed -e "s#^[^/]#$pwd\/&#")
+else
+ relative_location="$location"
+fi
+
[ -e "$dir" ] && die "$dir/ already exists"
mkdir "$dir"
cd "$dir"
-cg-init $location || exit $?
+cg-init "$relative_location" || exit $?
echo "Cloned to $dir/ (origin $location available as branch \"origin\")"
^ permalink raw reply
* Re: The big git command renaming..
From: Linus Torvalds @ 2005-04-29 22:14 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Dave Jones, Git Mailing List
In-Reply-To: <4272AE05.2070202@zytor.com>
On Fri, 29 Apr 2005, H. Peter Anvin wrote:
>
> Oh yes, and can that tarball please be put in /pub/software/scm/git, and
> the associated git tree be moved to /pub/scm/git?
Sure.
Just a quick question: what are the "rules" for /pub/scm/git?
Should I put just git in it, or is it meant for any "git project", and
should I also copy the 2.6.x kernel home from
/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
to
/pub/scm/git/linux-2.6.git
or what?
Me, I can do either or both, I just don't know what the intent was..
Linus
^ permalink raw reply
* Re: [PATCh] jit-trackdown
From: Junio C Hamano @ 2005-04-29 22:09 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: David Greaves, GIT Mailing Lists
In-Reply-To: <Pine.LNX.4.21.0504291730000.30848-100000@iabervon.org>
>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
DB> I've made a proposal like the following:
DB> .git/
DB> objects/ (traditional)
DB> refs/ Directories of hex SHA1 + newline files
DB> heads/ Commits which are heads of various sorts
DB> tags/ Tags, by the tag name (or some local renaming of it)
DB> info/ Other shared information
DB> remotes
DB> ... Everything else isn't shared
DB> HEAD Symlink to refs/heads/<something>
Thank you for clear description.
I agree with Linus that plumbing does not need to know anything
but objects/. What the porcelain passes fsck-cache to implement
prune/garbage-collect does not concern it. Of course it matters
to the users and that is the reason why I asked.
^ permalink raw reply
* Re: [PATCH] Make cg-clone handle local directories as sources
From: Ryan Anderson @ 2005-04-29 22:08 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20050429215928.GF1233@mythryan2.michonline.com>
Ignore this, I did something stupid - new patch to follow in a minute.
On Fri, Apr 29, 2005 at 05:59:29PM -0400, Ryan Anderson wrote:
>
> cg-clone is described as only being used with remote repositories, but
> it has the nice feature of creating the destination directory for you.
>
> This patch adds two features:
> 1. A destination directory can (optionally) be specified.
> 2. The source directory can be in the local file system.
>
> The following, for example, now works:
>
> cg-clone rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
> mkdir test ; cd test
> cg-clone ../cogito ../cogito2/
>
> Index: cg-clone
> ===================================================================
> --- c3aa1e6b53cc59d5fbe261f3f859584904ae3a63/cg-clone (mode:100755 sha1:4ee0685c358e094c5350b3968d013105da6ddf7e)
> +++ uncommitted/cg-clone (mode:100755)
> @@ -11,13 +11,22 @@
> . cg-Xlib
>
> location=$1
> -[ "$location" ] || die "usage: cg-clone SOURCE_LOC"
> +[ "$location" ] || die "usage: cg-clone SOURCE_LOC [DEST_LOC]"
> location=${location%/}
>
> -dir=${location##*/}; dir=${dir%.git}
> +if [ "$2" == "" ]; then
> + dir=${location##*/}; dir=${dir%.git}
> +else
> + dir=$2
> +fi
> +
> +pwd=$(pwd)
> +relative_location=$(echo "$location" | sed -e "s#^[^/]#$pwd\/&#")
> +
> [ -e "$dir" ] && die "$dir/ already exists"
> mkdir "$dir"
> cd "$dir"
>
> -cg-init $location || exit $?
> +echo "cg-init $relative_location"
> +cg-init $relative_location || exit $?
> echo "Cloned to $dir/ (origin $location available as branch \"origin\")"
>
>
> --
>
> Ryan Anderson
> sometimes Pug Majere
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: More problems...
From: Junio C Hamano @ 2005-04-29 22:01 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Linus Torvalds, Ryan Anderson, Petr Baudis, Russell King, git
In-Reply-To: <Pine.LNX.4.21.0504291717360.30848-100000@iabervon.org>
>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
DB> If someone does this, they should make a pull.c out of http-pull and
DB> rpull; the logic for determining what you need to copy, given what you
DB> have and what the user wants to have, should be shared.
I agree with your analysis. I was hoping that that someone
would be you, knowing where http-pull originated ;-).
^ permalink raw reply
* [PATCH] Make cg-clone handle local directories as sources
From: Ryan Anderson @ 2005-04-29 21:59 UTC (permalink / raw)
To: git
cg-clone is described as only being used with remote repositories, but
it has the nice feature of creating the destination directory for you.
This patch adds two features:
1. A destination directory can (optionally) be specified.
2. The source directory can be in the local file system.
The following, for example, now works:
cg-clone rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
mkdir test ; cd test
cg-clone ../cogito ../cogito2/
Index: cg-clone
===================================================================
--- c3aa1e6b53cc59d5fbe261f3f859584904ae3a63/cg-clone (mode:100755 sha1:4ee0685c358e094c5350b3968d013105da6ddf7e)
+++ uncommitted/cg-clone (mode:100755)
@@ -11,13 +11,22 @@
. cg-Xlib
location=$1
-[ "$location" ] || die "usage: cg-clone SOURCE_LOC"
+[ "$location" ] || die "usage: cg-clone SOURCE_LOC [DEST_LOC]"
location=${location%/}
-dir=${location##*/}; dir=${dir%.git}
+if [ "$2" == "" ]; then
+ dir=${location##*/}; dir=${dir%.git}
+else
+ dir=$2
+fi
+
+pwd=$(pwd)
+relative_location=$(echo "$location" | sed -e "s#^[^/]#$pwd\/&#")
+
[ -e "$dir" ] && die "$dir/ already exists"
mkdir "$dir"
cd "$dir"
-cg-init $location || exit $?
+echo "cg-init $relative_location"
+cg-init $relative_location || exit $?
echo "Cloned to $dir/ (origin $location available as branch \"origin\")"
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: More problems...
From: Anton Altaparmakov @ 2005-04-29 21:57 UTC (permalink / raw)
To: Russell King
Cc: Junio C Hamano, Linus Torvalds, Ryan Anderson, Petr Baudis, git
In-Reply-To: <20050429221903.F30010@flint.arm.linux.org.uk>
On Fri, 29 Apr 2005, Russell King wrote:
> On Fri, Apr 29, 2005 at 02:07:29PM -0700, Junio C Hamano wrote:
> > >>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
> > LT> Absolutely. I use the same "git-pull-script" between two local directories
> > LT> on disk...
> > LT> Of course, I don't bother with the linking. But that's the trivial part.
> >
> > Would it be useful if somebody wrote local-pull.c similar to
> > http-pull.c, which clones one local SHA_FILE_DIRECTORY to
> > another, with an option to (1) try hardlink and if it fails
> > fail; (2) try hardlink and if it fails try symlink and if it
> > fails fail; (3) try hardlink and if it fails try copy and if it
> > fails fail?
>
> What would be nice is if it finds an existing file for the one it's
> trying to hard link, it compares the contents (maybe - is this actually
> necessary?) and if identical, it removes the original file replacing
> it with a hard link.
Unless I have completely misunderstood things, you never need to compare
the file contents. Just compare the file names. If they match, i.e. the
SHA1 is the same, the contents must match by definition. So you only need
a stat(), rather than read&decompress&compare.
> This means that you'll always be trying to maintain the hard linked
> structure between various working trees in the background.
>
> But maybe this should have an option to enable this behaviour.
There should definitely be an option to either enable or disable this as
there are legitimate cases for not wanting hard links or indeed using
file systems which do not support them.
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
^ permalink raw reply
* Re: The big git command renaming..
From: H. Peter Anvin @ 2005-04-29 21:58 UTC (permalink / raw)
To: Dave Jones; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050429213540.GA1691@redhat.com>
Dave Jones wrote:
> On Fri, Apr 29, 2005 at 02:24:43PM -0700, Linus Torvalds wrote:
> >
> > Ok, I hate to do this, since my fingers have already gotten used to the
> > old names, but we clearly can't continue to use command names like
> > "update-cache" or "read-tree" that are totally non-git-specific.
> >
> > So I just pushed out a change that renames the commands to always have a
> > "git-" prefix. In addition, I renamed "show-diff" to "diff-files", with
> > together with the prefix means that it becomes "git-diff-files" when used.
> >
> > Since I end up using tab-completion for almost all my work, and since
> > -within- the source directory there's no confusion, I didn't actually name
> > the source files with any git- prefix. Quite the reverse: I removed the
> > prefix from the two .c files that already had it (so git-mktag.c is now
> > just "mktag.c"), and the general rule for building the executable from a C
> > file is now
> >
> > git-%: %.c $(LIB_FILE)
> > $(CC) $(CFLAGS) -o $@ $(filter %.c,$^) $(LIBS)
> >
> >
> > this seemed to be a nice regular interface that means that binaries get
> > installed with clear "git-" prefixes, but that I don't have to look at
> > them when I edit the sources.
>
> Can you push out a new tarball to kernel.org too please, to kill
> some potential confusion in documentation/scripts ?
Oh yes, and can that tarball please be put in /pub/software/scm/git, and
the associated git tree be moved to /pub/scm/git?
-hpa
^ permalink raw reply
* Re: Mercurial 0.4b vs git patchbomb benchmark
From: Denys Duchier @ 2005-04-29 21:57 UTC (permalink / raw)
To: Tom Lord; +Cc: noel, seanlkml, git
In-Reply-To: <200504292044.NAA28429@emf.net>
Tom Lord <lord@emf.net> writes:
> > My example had Joe downloading a remote signed tree, reviewing the changes
> > locally between his own trusted tree and the remote tree,
>
> In the real world, that "review" step is the weak link. When it goes
> wrong, the first step is to make sure we are reviewing a tree everyone
> involved *intended* -- and it's only with signed diffs adding up to
> that tree that we get there.
Hi Tom,
I hope I am not speaking out of turn or misinterpreting issues beyond my grasp,
but my perception of git is that when you sign a commit, you guarantee that this
is indeed the next step in the chronology of your own branch. It's not about
diffs; it's about a singular brachial chronology - of course, additional
information may be recorded about topological antecedents, but that's not what
the signature is about. The diff from that chronology can easily be generated
and scrutinized by anyone, and imported or not into another branch.
Cheers,
--
Dr. Denys Duchier - IRI & LIFL - CNRS, Lille, France
AIM: duchierdenys
^ permalink raw reply
* [PATCH] Makefile: The big git command renaming fallout fix.
From: Junio C Hamano @ 2005-04-29 21:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <7vacnh45x0.fsf@assigned-by-dhcp.cox.net>
Here is another. This one belongs to a clean-up category.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
cd /opt/packrat/playpen/public/in-place/git/git.linus/
show-diff -p Makefile
--- k/Makefile (mode:100644)
+++ l/Makefile (mode:100644)
@@ -59,8 +59,6 @@ CFLAGS += '-DSHA1_HEADER=$(SHA1_HEADER)'
$(LIB_FILE): $(LIB_OBJS)
$(AR) rcs $@ $(LIB_OBJS)
-init-db: init-db.o
-
git-%: %.c $(LIB_FILE)
$(CC) $(CFLAGS) -o $@ $(filter %.c,$^) $(LIBS)
@@ -104,6 +102,7 @@ read-cache.o: $(LIB_H)
sha1_file.o: $(LIB_H)
usage.o: $(LIB_H)
diff.o: $(LIB_H)
+strbuf.o: $(LIB_H)
clean:
rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE)
^ permalink raw reply
* RE: Mercurial 0.4b vs git patchbomb benchmark
From: Andrew Timberlake-Newell @ 2005-04-29 20:57 UTC (permalink / raw)
To: 'Tom Lord'; +Cc: noel, seanlkml, git
In-Reply-To: <200504292026.NAA28131@emf.net>
> > It looks to me like he did read carefully.
>
> > There were two different ideas:
> > TL) Passing tree & diff and trusting diff to create tree
> > NM) Passing tree and generating diff versus local tree for review
>
> Well, I guess *you* didn't read carefully. I also spoke about the
> value of passing around triples: ancestry, diff, and tree. The
> question is about linking signatures to things that humans can
> reasonably *intend* and be reasonably held accountable for, hence one
> of the values of signed diffs. (I cited other practical reasons to
> value signed diffs and use them in specific ways, too.)
I know that you mentioned other things. That doesn't invalidate that Noel
was talking about your starting point description of how git works and
suggesting that it isn't how git actually works. The relevance of your
other points depends upon having the base model correct.
You can argue that glass houses are inherently brittle, but why should I
care if mine is already made of bricks instead of glass? If the model
against which you are arguing is not the model which is used by git, then
the model isn't a relevant basis for claiming problems with git.
^ permalink raw reply
* Re: Mercurial 0.4b vs git patchbomb benchmark
From: Horst von Brand @ 2005-04-29 21:45 UTC (permalink / raw)
To: Tom Lord; +Cc: seanlkml, git
In-Reply-To: <200504291928.MAA27145@emf.net>
Tom Lord <lord@emf.net> said:
> Think of it this way:
>
> (a) Joe, the mainline maintainer, gets a trusted message containing
> a diff.
>
> (b) Joe reads the diff, it makes great sense, he wants to merge.
>
> (c) Joe downloads a tree. Supposedly that tree is the result of
> applying this diff. The tree, not the diff, is used for
> merging.
>
> You can see the logical whole there... now the practical one:
>
>
> (d) Joe is repeating (a..c) at an unfathomably high rate.
> At a low rate, he could be double-checking enough that
> that the diff-vs-tree problem isn't that serious. But
> at the rate he operates, exploits appear all along the
> patch-flow pipeline because so much stuff goes unchecked.
>
> Joe may be scan the changes he's merged before committing but,
> if his rate is high, that scan *must*, out of biological and
> physical necessity, be shallow. Exploits can occur on the
> submitter machine, in the communication channel, and on Joe's
> machine. Social exploits can occur because of the separation
> between a submitter saying "this is what I'm doing" vs. the reality
> of what the submitter is doing.
Now pray tell how Joe signing one, two, three, or none of the things he is
juggling makes any difference here.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ 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