* Re: [PATCH] archimport improvements
From: Martin Langhoff @ 2005-11-14 22:38 UTC (permalink / raw)
To: Eric Wong; +Cc: git list
In-Reply-To: <20051112202150.GA2037@Muzzle>
Eric,
thanks for resending those so quickly. I think I'm going to sit on the
'overhaul of changeset application' patch a bit -- I'll test & ack
your other patches for merge soonish but I want to review and test
this one carefully.
My main concern is that it seems to be calling tla get for each
revision that it imports. For large trees, this is slow. I would be
much happier with a fast Perl-based approach. Have you got a public
repo with directory renames?
Additional comments follow...
On 11/13/05, Eric Wong <normalperson@yhbt.net> wrote:
> > > * Identify git branches as an Arch "archive,category<--branch>--version"
> > > Anything less than that is ambiguous as far as history and patch
> > > relationships go.
> >
> > These bug/sanity fixes are _good_. As you mention, I wasn't aware that
> > patchnames could show up not having a --branch part. Tricky...
>
> Thanks. I got lazy one day and started ignoring --branch on some of my
> personal projects to save my fingers :)
Yup, makes sense. My concern now is that existing imports will change
the name of branches and tags going forward. Can I ask you to resend
that patch with the new branchname mangling as default, and the old
one as optional?
I know it'll force us to go back to using shellquote, but I am not too
worried by that dependency at the moment.
> > > Current weaknesses:
> > >
> > > * (Present in the original code as well).
> > > The code still assumes that dates in commit logs can be trusted, which is
> > > fine in most cases, but a wayward branch can screw up git-archimport and
> > > cause parents to be missed.
> >
> > Fair enough. You mention an alternative strategy (tla ancestry) --
> > have you tried it at all?
>
> No, not yet.
Also interested in this if you get around to it.
cheers,
martin
^ permalink raw reply
* Re: [PATCH 1/1] git-cvsexportcommit.perl: Fix usage() output.
From: Martin Langhoff @ 2005-11-14 22:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kevin Geiss, git
In-Reply-To: <7vbr0mx4fj.fsf@assigned-by-dhcp.cox.net>
On 11/15/05, Junio C Hamano <junkio@cox.net> wrote:
> I hate to be nitpicky, but this slurps in File::Basename
> (9Kbytes) only to shorten the displayed command name.
Fair enough -- I'll leave that one up to you. I'm happy with Kevin's
patches -- what's the ideal workflow for this? Is the sign-off line
important enough that I should setup a public repo for you to pull
from?
BTW, File::Basename is a standard library usually installed w perl --
it shouldn't add any painful dependencies. Not sure if that matters.
martin
^ permalink raw reply
* Re: [PATCH 1/1] git-cvsexportcommit.perl: Fix usage() output.
From: Junio C Hamano @ 2005-11-14 22:14 UTC (permalink / raw)
To: Kevin Geiss; +Cc: martin.langhoff, git
In-Reply-To: <20051114164505.GF9131@raven.localdomain>
Kevin Geiss <kevin@desertsol.com> writes:
> sub usage {
> print STDERR <<END;
> -Usage: GIT_DIR=/path/to/.gi ${\basename $0} # fetch/update GIT from CVS
> - [-h] [-p] [ parent ] commit
> +Usage: GIT_DIR=/path/to/.git ${\basename $0} [-h] [-p] [-v] [-c] [ parent ] commit
> END
> exit(1);
> }
I hate to be nitpicky, but this slurps in File::Basename
(9Kbytes) only to shorten the displayed command name.
I personally do not like programs that shorten $0 (or in C
argv[0]) when they identify themselves. This is probably just
me, but I was bitten by such programs too many times while
debugging them, after wasting too many hours only to find that I
was not running the executable I thought I was running but
something else that happened to be earlier on my PATH X-<.
^ permalink raw reply
* allow git-update-ref create refs with slashes in names
From: Alex Riesen @ 2005-11-14 22:10 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20051114215905.GA5714@steel.home>
Sorry for the previuos untested patch, the tradition seem to be
catching... This one is actualy tested.
Make git-update-ref create references with slashes in them. git-branch
and git-checkout already support such reference names.
git-branch can use git-update-ref to create the references in a more
formal manner now.
---
the patch also adds to trivial test cases (just to notice regression,
even if I don't believe that is possible for such a trivial thing).
diff --git a/git-branch.sh b/git-branch.sh
index 67f113a..11d52fd 100755
--- a/git-branch.sh
+++ b/git-branch.sh
@@ -102,6 +102,5 @@ rev=$(git-rev-parse --verify "$head") ||
git-check-ref-format "heads/$branchname" ||
die "we do not like '$branchname' as a branch name."
-leading=`expr "refs/heads/$branchname" : '\(.*\)/'` &&
-mkdir -p "$GIT_DIR/$leading" &&
-echo $rev > "$GIT_DIR/refs/heads/$branchname"
+git update-ref "refs/heads/$branchname" $rev
+
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 5f98f64..36f7749 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -24,4 +24,12 @@ test_expect_failure \
'git branch --help should not have created a bogus branch' \
'test -f .git/refs/heads/--help'
+test_expect_success \
+ 'git branch abc should create a branch' \
+ 'git-branch abc && test -f .git/refs/heads/abc'
+
+test_expect_success \
+ 'git branch a/b/c should create a branch' \
+ 'git-branch a/b/c && test -f .git/refs/heads/a/b/c'
+
test_done
diff --git a/update-ref.c b/update-ref.c
index d79dc52..e6fbddb 100644
--- a/update-ref.c
+++ b/update-ref.c
@@ -19,7 +19,8 @@ static int re_verify(const char *path, u
int main(int argc, char **argv)
{
char *hex;
- const char *refname, *value, *oldval, *path, *lockpath;
+ const char *refname, *value, *oldval, *path;
+ char *lockpath;
unsigned char sha1[20], oldsha1[20], currsha1[20];
int fd, written;
@@ -49,6 +50,8 @@ int main(int argc, char **argv)
}
path = strdup(path);
lockpath = mkpath("%s.lock", path);
+ if (safe_create_leading_directories(lockpath) < 0)
+ die("Unable to create all of %s", lockpath);
fd = open(lockpath, O_CREAT | O_EXCL | O_WRONLY, 0666);
if (fd < 0)
^ permalink raw reply related
* Re: [PATCH] git-daemon: --inetd implies --syslog
From: Junio C Hamano @ 2005-11-14 22:01 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4379006E.8020607@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> That shouldn't be a problem because;
> 1) handle() dupes the connected socket to stdin and stdout, but not stderr.
I am afraid that
$ git whatchanged -s -S'FIXME' daemon.c
tells me otherwise. Whatever we do in handle() is too late to matter.
diff-tree 7c3693f1f240e17772c864fad35bc16226038fc8 (from 6a2e50f9dfdca7ac572bbe30dd0efdf19ca250f6)
Author: lars.doelle@on-line.de <lars.doelle@on-line.de>
Date: Thu Sep 8 03:50:01 2005 +0200
[PATCH] git-daemon --inetd
git-daemon using inetd. does not work properly. inetd routes stderr onto the
network line just like stdout, which was apparently not expected to be so.
As the result of this, the stream is closed by the receiver, because some
"Packing %d objects\n" originating from pack_objects is first reported over
the line instead of the expected pack_header, and so the SIGNATURE test
fails. Here is a workaround.
Signed-off-by: Junio C Hamano <junkio@cox.net>
^ permalink raw reply
* allow git-update-ref create refs with slashes in names
From: Alex Riesen @ 2005-11-14 21:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Make git-update-ref create references with slashes in them. git-branch
and git-checkout already support such reference names.
git-branch can use git-update-ref to create the references in a more
formal manner now.
---
the patch also adds to trivial test cases (just to notice regression,
even if I don't believe that is possible for such a trivial thing).
diff --git a/git-branch.sh b/git-branch.sh
index 67f113a..11d52fd 100755
--- a/git-branch.sh
+++ b/git-branch.sh
@@ -102,6 +102,5 @@ rev=$(git-rev-parse --verify "$head") ||
git-check-ref-format "heads/$branchname" ||
die "we do not like '$branchname' as a branch name."
-leading=`expr "refs/heads/$branchname" : '\(.*\)/'` &&
-mkdir -p "$GIT_DIR/$leading" &&
-echo $rev > "$GIT_DIR/refs/heads/$branchname"
+git update-ref "refs/heads/$branchname" $rev
+
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 5f98f64..36f7749 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -24,4 +24,12 @@ test_expect_failure \
'git branch --help should not have created a bogus branch' \
'test -f .git/refs/heads/--help'
+test_expect_success \
+ 'git branch abc should create a branch' \
+ 'git-branch abc && test -f .git/refs/heads/abc'
+
+test_expect_success \
+ 'git branch a/b/c should create a branch' \
+ 'git-branch a/b/c && test -f .git/refs/heads/a/b/c'
+
test_done
diff --git a/update-ref.c b/update-ref.c
index d79dc52..aac04e6 100644
--- a/update-ref.c
+++ b/update-ref.c
@@ -49,6 +49,8 @@ int main(int argc, char **argv)
}
path = strdup(path);
lockpath = mkpath("%s.lock", path);
+ if (safe_create_leading_directories(lockpath) < 0)
+ die("Unable to create all of %s", lockpath);
fd = open(lockpath, O_CREAT | O_EXCL | O_WRONLY, 0666);
if (fd < 0)
^ permalink raw reply related
* Re: [PATCH] Bugfix: stop if directory already exists
From: Junio C Hamano @ 2005-11-14 21:30 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Josef Weidendorfer, git
In-Reply-To: <437858A1.9010007@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Junio C Hamano wrote:
>>
>>> usage: git clone ...
>>> For more details, see 'man git-clone'
>> And "for more details see man" goes without saying.
>
> But we name them differently, as hpa pointed out some week ago.
>
> When I see "usage: <prog> <command>" I expect to find the info in "man
> <prog>".
... meaning, "man git", which would list the subcommands.
And a user who got "usage: git clone blah" and did "man git"
once is intelligent enough to know and remember "man git" lists
the subcommands, what she wanted to know about was listed as
"git-clone(1)", and she had to do "man git-clone", so next time
around we should be able to expect her to do "man git-commit".
Am I overestimating the users or overtaxing them?
^ permalink raw reply
* Re: [PATCH] GIT commit statistics.
From: Martin Langhoff @ 2005-11-14 21:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20051114092554.GR30496@pasky.or.cz>
On 11/14/05, Petr Baudis <pasky@suse.cz> wrote:
> All the woes just to get rid of the merge commits. What's wrong on merge
> commits? If they irritate you so much, cg-log -M. ;-)
Well, if you have a team of 5 working closely, doing commit/update
several times a day, soon the following things happen:
- everyone has sightly different histories, even if they all have the same tree
- in the repo, there are 'update' merges galore.
- as soon as you _actually_ have branches, it's really hard to
distinguish branch merges from 'same branch update before commit'
merges.
by replacing the daily/hourly intra-team, self-branch `cg-update` with
`cg-fetch && git-rebase` our history makes much more sense _and_
looking at gitk I can see clearly again the interesting merges (ie:
merges with other branches).
In practice, it's exactly what happens with git's history -- the
merges are actually from rebased patches, that's why the history is
"readable".
does that make sense?
cheers,
martin
^ permalink raw reply
* Re: [PATCH] git-daemon: --inetd implies --syslog
From: Andreas Ericsson @ 2005-11-14 21:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <7vlkzrx84p.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> exon@op5.se (Andreas Ericsson) writes:
>
>
>>Otherwise nothing is logged anywhere, which is a Bad Thing.
>>
>>Signed-off-by: Andreas Ericsson <ae@op5.se>
>
>
> Thanks; I am OK with what you are trying to do with this change,
> except that:
>
> - I suspect closing stderr is still needed (the "workaround"
> was about inetd connection sending output to both fd 1 and 2
> to the client, which would corrupt the protocol conversation
> when exec'ed program writes anything to its standard error
> stream).
>
That shouldn't be a problem because;
1) handle() dupes the connected socket to stdin and stdout, but not stderr.
2) A program sending output to stderr() fails (well, *should* be either
failing or silent), so it's most likely not sane to continue doing
things anyway. This assumes that no client prints anything to stderr
that can be interpreted as "real" protocol data, ofcourse.
> - I would have preferred the removal of needless else as a
> separate cleanup patch (this is minor).
>
Sorry. I think I missed that part when I glanced at the diff output.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9g
From: Junio C Hamano @ 2005-11-14 21:15 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4378578E.5090409@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Junio C Hamano wrote:
>> My current thinking about this problem is that the handful
>> programs that need to run "on the other end" should stay in
>> /usr/bin, even after we move most things out of /usr/bin, if
>> only to avoid configuration hassles. They are:
>> receive-pack, upload-pack
>> ssh-fetch, ssh-pull, ssh-push, ssh-upload
>
> I liked your suggestion of deprecating the /usr/bin use a month or two
> before it's effected better. We could then provide symlinks for the
> necessary programs that point to their real locations in GIT_EXEC_PATH
> and (someday) drop those links when they're no longer needed.
Yes, but the problem is when that "someday" comes. Unlike a
single machine installation where we can tell "git" to look into
somewhere different at the same time we move the subcommands out
of /usr/bin, "the other end" can lag behind and sometimes not
under control of the end user.
I think it's simpler to manage and can be made configuration
free if we keep receive-pack and upload-pack in /usr/bin and
always call these programs in dash-form (i.e. not "git
upload-pack") from the other end. .bash_profile is not read for
incoming ssh connections to execute a single command, but many
people set their PATH in there, without setting PATH in .bashrc.
I personally think that having to set PATH in .bashrc it is
actually a bug in what bash does, but that is OT.
^ permalink raw reply
* Re: [RFC] Not grabbing ALL branches and tags with git clone
From: Junio C Hamano @ 2005-11-14 21:01 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git
In-Reply-To: <20051114182616.GB19105@hpsvcnb.fc.hp.com>
Carl Baldwin <cnb@fc.hp.com> writes:
> Lately, I've found that 'git clone' gives me more than what I want.
> Especially when there are a lot of branches and tags in the remote
> repository.
When I make a clone of git.git, oftentimes the first thing I do
is:
$ git branch -D todo
But I've always considered that a rare exception (i.e. the todo
branch is not related to the main source). What kind of
unrelated things do you keep in a single repository such that
you do not want to start out in sync with all of its branches?
^ permalink raw reply
* Re: [Question] info/grafts file.
From: Junio C Hamano @ 2005-11-14 20:56 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git
In-Reply-To: <20051114182019.GA19105@hpsvcnb.fc.hp.com>
Grafts are considered local preference, and not copied when
cloned. I am unsure this was a right decision, but that is how
things are right now.
^ permalink raw reply
* Re: [PATCH] git-daemon: --inetd implies --syslog
From: Junio C Hamano @ 2005-11-14 20:54 UTC (permalink / raw)
To: Andreas Ericsson, H. Peter Anvin; +Cc: git
In-Reply-To: <20051114164101.58A495BF92@nox.op5.se>
exon@op5.se (Andreas Ericsson) writes:
> Otherwise nothing is logged anywhere, which is a Bad Thing.
>
> Signed-off-by: Andreas Ericsson <ae@op5.se>
Thanks; I am OK with what you are trying to do with this change,
except that:
- I suspect closing stderr is still needed (the "workaround"
was about inetd connection sending output to both fd 1 and 2
to the client, which would corrupt the protocol conversation
when exec'ed program writes anything to its standard error
stream).
- I would have preferred the removal of needless else as a
separate cleanup patch (this is minor).
Peter, I am CC'ing this to you because I do not know how you run
the daemon on kernel.org machines -- I suspect you use --syslog
already and am hoping you are OK with this change.
^ permalink raw reply
* Re: [PATCH 1/1] git-cvsexportcommit.perl: Fix usage() output.
From: Kevin Geiss @ 2005-11-14 20:24 UTC (permalink / raw)
To: Kevin Geiss; +Cc: git
In-Reply-To: <20051114164505.GF9131@raven.localdomain>
this was supposed to be 1/4 of course.
^ permalink raw reply
* Re: ./configure script prototype
From: Junio C Hamano @ 2005-11-14 20:21 UTC (permalink / raw)
To: git
In-Reply-To: <4378DF71.3060103@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Linus Torvalds wrote:
>
>> If you want to do a "configure" script (and I'm not sure it's worth
>> it),
>
> Perhaps not. I was under the impression that Junio was for it to
> simplify the possible move of binaries to GIT_EXEC_PATH.
I do not see how that is related to it.
Offtopic, but if you really want to do ${var##} and friends
portably, expr(1) is the tool traditionalists prefer; not echo
piped to sed, please.
^ permalink raw reply
* Re: [PATCH] Show URL in the "Getting <foo> list" http-fetch messages
From: Junio C Hamano @ 2005-11-14 20:11 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Petr Baudis, git
In-Reply-To: <20051114190225.GA3793@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> On Sat, Nov 12, 2005 at 09:22:02AM -0800, Nick Hengeveld wrote:
>
>> This should not be an issue with index requests because they are only
>> initiated from fetch(). The previous patch to load alternates on demand
>> added alternate handling to process_curl_messages() so that a 404 for an
>> object can be handled immediately rather than waiting for the fetch()
>> call for that object to notice.
>
> Seems like it might make sense to handle pack downloads immediately when
> an object is unavailable rather than waiting for the fetch() call. It
> could prevent attempts to download any other objects inside that pack,
> although queued requests that activate while a pack is downloading
> would have to wait to see whether the download is successful.
I think that makes sense, and it probably is preferable to make
them wait than blindly go ahead. Although we are issuing
requests in parallel, these simultaneous requests are asking for
related things (e.g. parent commit objects or the tree object of
the commit we just saw; blob objects contained in the tree we
just saw) and are more likely than not to be found in the pack
being requested. Losing parallelism while a pack is in transit
would not be too much of a problem.
^ permalink raw reply
* [PATCH] cg-clean: fix argument processing
From: Pavel Roskin @ 2005-11-14 20:03 UTC (permalink / raw)
To: git; +Cc: Petr Baudis, Yann Dirson
cg-clean was broken by the "robustified usage checks". This patch
restores the old behavior, i.e. cg-clean reports errors if there is
anything but switches on the command line. Empty arguments are rejected
now as well.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/cg-clean b/cg-clean
index f680aee..1cc1ae8 100755
--- a/cg-clean
+++ b/cg-clean
@@ -44,7 +44,7 @@ while optparse; do
fi
done
-[ ${#ARGS[*]} -ge 1 ] || usage
+[ ${#ARGS[*]} = 0 ] || usage
clean_dirs()
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: [Question] info/grafts file.
From: Petr Baudis @ 2005-11-14 19:59 UTC (permalink / raw)
To: git
In-Reply-To: <20051114182019.GA19105@hpsvcnb.fc.hp.com>
Hello,
Dear diary, on Mon, Nov 14, 2005 at 07:20:19PM CET, I got a letter
where Carl Baldwin <cnb@fc.hp.com> said that...
> A simple question to clarify something in the repository.
>
> What level of support is to be expected for the .git/info/grafts file?
> I added a grafts file to a repository imported from SVN. However, when
> I cloned the repository using git clone -l -s I did not end up with a
> grafts file in the cloned repository.
grafts are meant to be a purely local thing, private to your current
repository so that you can extend it in certain way. If you want
something public and official, that's what the "parent" lines in the
commit objects are - so you are really better off just rewriting the
history.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Command line hint of the day
From: Andreas Ericsson @ 2005-11-14 19:08 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511141049410.3263@g5.osdl.org>
Linus Torvalds wrote:
> Maybe we should have a git man-page section of "strange but useful
> examples"? Things people do just because they are useful, but may not be
> immediately obvious to somebody who comes from CVS-land and uses git as
> just another old SCM?
>
Sounds like a good idea. The sed1liners.txt (sic) has probably saved me
several hundred hours of boring and tedious cut'n paste work (or more
interesting but still not exactly fun one-shot programming).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: ./configure script prototype
From: Andreas Ericsson @ 2005-11-14 19:03 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511141027380.3263@g5.osdl.org>
Linus Torvalds wrote:
>
> On Mon, 14 Nov 2005, Joel Becker wrote:
>
>
>>On Mon, Nov 14, 2005 at 02:29:56PM +0100, Petr Baudis wrote:
>>
>>>Dear diary, on Mon, Nov 14, 2005 at 01:18:52PM CET, I got a letter
>>>where Andreas Ericsson <ae@op5.se> said that...
>>>
>>>> --prefix=*)
>>>> prefix=${1##*=}
>>
>> ${i# and ${i% are POSIX, iirc.
>
>
> They may be in POSIX, but they sure as h*ll aren't portable.
>
A bit funny really. I've already said I'll change them to some sed
thing, so the last 16 emails on this thread have been purely academic. I
guess more people than me are bored by mondays.
> If you want to do a "configure" script (and I'm not sure it's worth it),
Perhaps not. I was under the impression that Junio was for it to
simplify the possible move of binaries to GIT_EXEC_PATH.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Show URL in the "Getting <foo> list" http-fetch messages
From: Nick Hengeveld @ 2005-11-14 19:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <20051112172201.GF4051@reactrix.com>
On Sat, Nov 12, 2005 at 09:22:02AM -0800, Nick Hengeveld wrote:
> This should not be an issue with index requests because they are only
> initiated from fetch(). The previous patch to load alternates on demand
> added alternate handling to process_curl_messages() so that a 404 for an
> object can be handled immediately rather than waiting for the fetch()
> call for that object to notice.
Seems like it might make sense to handle pack downloads immediately when
an object is unavailable rather than waiting for the fetch() call. It
could prevent attempts to download any other objects inside that pack,
although queued requests that activate while a pack is downloading
would have to wait to see whether the download is successful. If such
an object also exists loose it would prevent a redundant download and if
not it would at least prevent an unnecessary check and 404.
Thoughts?
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: ./configure script prototype
From: Joel Becker @ 2005-11-14 18:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Andreas Ericsson, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511141027380.3263@g5.osdl.org>
On Mon, Nov 14, 2005 at 10:39:26AM -0800, Linus Torvalds wrote:
> > ${i# and ${i% are POSIX, iirc.
>
> They may be in POSIX, but they sure as h*ll aren't portable.
By POSIX I meant POSIX shell, which is ksh. That's available on
just about all modern non-free Unices, and we all know bash and zsh are
compatible with it.
But I had no intention of arguing how portable POSIX is, I was
just trying to describe the minimum breadth of support. My personal
experience is that these particular variable forms have worked on Linux,
Solaris, AIX, Ultrix, IRIX, and the BSDs for, I dunno, eight to ten
years or so.
That said, $(echo | sed), or `echo | sed` for even more
backwards portability (I bet $() is about as portable as ${i%}), can be
used to replace the ${i%} forms.
Joel
--
"I always thought the hardest questions were those I could not answer.
Now I know they are the ones I can never ask."
- Charlie Watkins
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Command line hint of the day
From: Linus Torvalds @ 2005-11-14 18:58 UTC (permalink / raw)
To: Git Mailing List
So I got a question about ppp in the kernel, and quite frankly, the things
I know about ppp can be engraved with a jack-hammer on a grain of rice.
So what did I do?
git whatchanged $(git-ls-files *ppp*)
actually does something useful. It will only look at files that are
_currently_ called *ppp*, so you'd not see files that have been deleted,
but it does the right thing for what I wanted.
You can also do "git log" or "gitk" instead of "git whatchanged", but the
whatchanged thing has the advantage that it can run incrementally. Doing a
"git log" ends up figuring out _all_ the commits before it can display
them, since it also does the densification etc.
Maybe we should have a git man-page section of "strange but useful
examples"? Things people do just because they are useful, but may not be
immediately obvious to somebody who comes from CVS-land and uses git as
just another old SCM?
Linus
^ permalink raw reply
* Re: Offtopic [Re: Can't use gitk.]
From: Andreas Ericsson @ 2005-11-14 18:52 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511141005590.3263@g5.osdl.org>
Linus Torvalds wrote:
> It can be confusing, since in Italy (and, I think, southern Germany and
> much of Eastern Europe), "Andrea" is a boy, and in fact, the name
> originally comes from the Greek meaning "man".
>
While we're working up the trivia section here we might as well be anal
about it.
Andrea does indeed mean 'man' in the sense of 'human being' (think
android). It was a form of flattery in ancient Greece, where being, with
every breath, as human (or humane, which was originally the same) as
possible was considered the best anyone could hope to be. Alas, that
meaning has long since been somewhat watered.
Andreas stems from Andros and means "powerful protective guardian" in
the sense of a totem. Chicks dig that. ;)
> In the rest of the world, Andrea seems to mostly female, but it probably
> depends on where the cultural influences come from.
>
> So leaving off the "s" can be very strange to the recipient.
>
Personally I don't mind. I just thought it weird that so many are doing
it. Thanks for the clarification though. It killed a full ten minutes of
dull late-monday work of debugging other peoples perl-scripts.
Oh well. Back to it, I suppose.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: ./configure script prototype
From: Linus Torvalds @ 2005-11-14 18:39 UTC (permalink / raw)
To: Joel Becker; +Cc: Petr Baudis, Andreas Ericsson, Git Mailing List
In-Reply-To: <20051114181958.GD20749@ca-server1.us.oracle.com>
On Mon, 14 Nov 2005, Joel Becker wrote:
> On Mon, Nov 14, 2005 at 02:29:56PM +0100, Petr Baudis wrote:
> > Dear diary, on Mon, Nov 14, 2005 at 01:18:52PM CET, I got a letter
> > where Andreas Ericsson <ae@op5.se> said that...
> > > --prefix=*)
> > > prefix=${1##*=}
>
> ${i# and ${i% are POSIX, iirc.
They may be in POSIX, but they sure as h*ll aren't portable.
There's a _lot_ of machines out there that don't do POSIX, just because
those "newfangled" things are so complicated.
Also, even in POSIX, there's tons of different substandards, and you might
follow one but not the other.
Finally, even if somebody is certified, they can very well be certified
with "exceptions", so if they claim POSIX it doesn't necessarily mean that
they follow all of it.
If you want to do a "configure" script (and I'm not sure it's worth it),
you should cater to the lowest common denominator for it to be meaningful.
What the hell that would be, I have no idea, since if you ever want to run
on native Windows, it won't even be traditional shell. But traditional
shell is at least a lot closer to that lowest common denominator than
POSIX shell is.
That said, most of those ${var...} sequences definitely _are_ very
traditional, and for all I know, ## may be too.
Linus
^ 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