* Re: git-send-email is omitting author and date lines
From: Junio C Hamano @ 2007-09-24 18:43 UTC (permalink / raw)
To: martin f krafft; +Cc: Johannes Schindelin, Hanspeter Kunz, git
In-Reply-To: <20070924173014.GB27816@lapse.madduck.net>
martin f krafft <madduck@madduck.net> writes:
> also sprach Johannes Schindelin <Johannes.Schindelin@gmx.de> [2007.09.24.1210 +0100]:
>> And that is perfectly okay, since as far as the public is
>> concerned, this is the date of the patch.
>
> If you say so. I don't find this at all convincing.
I think that is the reasoning for the current behaviour of
send-email, but it is not unreasonable to have an option to
always add in-body From: and Date: headers to send-email, with a
blessing from a recent post from Linus to the kernel mailing
list:
http://article.gmane.org/gmane.linux.kernel/582450
Notice the part he says he appreciates Andrew's practice and
talks about message being further forwarded by somebody else.
^ permalink raw reply
* Re: [PATCH] Move option parsing code to parse-options.[ch].
From: Kristian Høgsberg @ 2007-09-24 18:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsl57iz1t.fsf@gitster.siamese.dyndns.org>
On Fri, 2007-09-21 at 12:44 -0700, Junio C Hamano wrote:
> Kristian Høgsberg <krh@redhat.com> writes:
>
> > Signed-off-by: Kristian Høgsberg <krh@redhat.com>
> > ---
> > Makefile | 2 +-
> > builtin-commit.c | 117 ++++++++----------------------------------------------
> > parse-options.c | 74 ++++++++++++++++++++++++++++++++++
> > parse-options.h | 29 +++++++++++++
> > 4 files changed, 121 insertions(+), 101 deletions(-)
> > create mode 100644 parse-options.c
> > create mode 100644 parse-options.h
>
> Hmmmmmmm. Is it too much to ask to pretend as if the previous
> "builtin-commit.c" that had these parts that did not belong to
> it in the first place never happened?
No problem, I wasn't sure whether to update the patches or to just send
follow-up patches now that it was in pu. I'll resend 7/7 as 3 new
patches that exports add_files_to_cache(), adds option parsing, and
finally builtin-commit.
Kristian
^ permalink raw reply
* Re: [PATCH] post-checkout hook, and related docs and tests
From: Junio C Hamano @ 2007-09-24 18:34 UTC (permalink / raw)
To: Josh England; +Cc: git
In-Reply-To: <1190654052.6078.14.camel@beauty>
"Josh England" <jjengla@sandia.gov> writes:
>> What's the _semantics_ you are trying to achieve?
>
> I'd like to get a hook that runs whenever the working dir gets
> updated. The 'git-checkout otherbranch path.c' case should
> run it also, so I view that as a bug.
I think that _is_ INSANE. Do you run the hook for these then?
$ edit path.c
$ git-cat-file otherbranch:path.c >path.c
Why "git checkout otherbranch path.c" should be any different?
^ permalink raw reply
* Re: behaviour of git diff, GIT_DIR & checked out tree
From: Junio C Hamano @ 2007-09-24 18:31 UTC (permalink / raw)
To: David Tweed; +Cc: Junio C Hamano, Johannes Schindelin, Git Mailing List
In-Reply-To: <e1dab3980709241009q71f9a40r1f8b551b417f7475@mail.gmail.com>
"David Tweed" <david.tweed@gmail.com> writes:
> ... I'm just asking if there's a way to say
> "the `working dir' associated with this git dir" explicitly (in the same
> way I can use `HEAD' to refer to the topmost commit on the
> current branch) when you're not somewhere within the 'working dir'.
Not for "git diff <one-tree>" which is a way to diff the _part_
of work tree you are _currently in_ with the given tree, nor for
"git diff" which is to do the same with the index. With these
commands (and others that error out when you run without GIT_DIR
outside the work tree), you are really expected to be _in_ the
subdirectory you are interested in.
GIT_WORK_TREE is somewhat related but is a different issue, by
the way. It is to let you say where the top level of the work
tree is. It does not change the fact that the way for you to
express which subdirectory in the work tree you are interested
in to work tree commands is by your $PWD relative to the top of
the work tree.
^ permalink raw reply
* Re: [PATCH] post-checkout hook, and related docs and tests
From: Josh England @ 2007-09-24 17:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzlzfh7xd.fsf@gitster.siamese.dyndns.org>
On Fri, 2007-09-21 at 17:15 -0700, Junio C Hamano wrote:
> "root" <root@sandia.gov> writes:
>
> > +post-checkout
> > +-----------
> > +
> > +This hook is invoked when a `git-checkout` is run on a local repository.
> > +The hook is given two parameters: the ref of the previous HEAD, and the ref of
> > +the new HEAD. This hook cannot affect the outcome of `git-checkout`.
> > +
> > +This hook can be used to perform repository validity checks, auto-display
> > +differences from the previous HEAD, or set working dir metadata properties.
> > +
>
> People may wonder why this is not run when they do "git checkout
> otherbranch path.c"; the second sentence from the above
> description implies why it shouldn't, but the first sentence
> probably should state it more clearly.
>
> What's the _semantics_ you are trying to achieve?
>
> Why does the hook run every time git-bisect suggests the next
> revision to try?
Its being run since git-bisect calls git-checkout internally, but since
the 'git-checkout $branch' could potentially update the working tree it
may be desirable to have the hook run. Since one stated purpose of the
hook is maintain repository validity or update metadata, running the
hook at this time may be the right thing to do.
> Why does the hook run when rebase starts its work?
I think this case is actually desirable. If the rebase changes some
aspects of the working dir that the hook cares about (eg: metadata),
then the hook will be able handle the situation correctly. Not running
the hook for a rebase operation could result in the working dir being
left in an inconsistent state.
-JE
^ permalink raw reply
* Re: git-send-email is omitting author and date lines
From: martin f krafft @ 2007-09-24 17:30 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano, Hanspeter Kunz, git
In-Reply-To: <Pine.LNX.4.64.0709241209470.28395@racer.site>
[-- Attachment #1: Type: text/plain, Size: 599 bytes --]
also sprach Johannes Schindelin <Johannes.Schindelin@gmx.de> [2007.09.24.1210 +0100]:
> And that is perfectly okay, since as far as the public is
> concerned, this is the date of the patch.
If you say so. I don't find this at all convincing.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"if i am occasionally a little overdressed, i make up for it by being
always immensely over-educated."
-- oscar wilde
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] post-checkout hook, and related docs and tests
From: Josh England @ 2007-09-24 17:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzlzfh7xd.fsf@gitster.siamese.dyndns.org>
On Fri, 2007-09-21 at 17:15 -0700, Junio C Hamano wrote:
> "root" <root@sandia.gov> writes:
>
> > +post-checkout
> > +-----------
> > +
> > +This hook is invoked when a `git-checkout` is run on a local repository.
> > +The hook is given two parameters: the ref of the previous HEAD, and the ref of
> > +the new HEAD. This hook cannot affect the outcome of `git-checkout`.
> > +
> > +This hook can be used to perform repository validity checks, auto-display
> > +differences from the previous HEAD, or set working dir metadata properties.
> > +
>
> People may wonder why this is not run when they do "git checkout
> otherbranch path.c"; the second sentence from the above
> description implies why it shouldn't, but the first sentence
> probably should state it more clearly.
>
> What's the _semantics_ you are trying to achieve?
I'd like to get a hook that runs whenever the working dir gets
updated. The 'git-checkout otherbranch path.c' case should run it also, so I view that as a bug.
> Why does the hook run every time git-bisect suggests the next
> revision to try?
> Why does the hook run when rebase starts its work?
It may be inserted in a ad place or maybe it needs some intelligence in
there to know when *not* to run.
> When "git pull" or "git merge" results in a fast forward, the
> situation is no different from checking out a new revision. Why
> doesn't the hook run in these cases?
This is actually what I'd like to do. I submitted the post-merge patch
some time ago to serve that purpose. Do you think they should both be
rolled into a single post-checkout hook? It would seem to make sense to
me.
^ permalink raw reply
* Re: behaviour of git diff, GIT_DIR & checked out tree
From: David Tweed @ 2007-09-24 17:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <7v6420au43.fsf@gitster.siamese.dyndns.org>
On 9/24/07, Junio C Hamano <gitster@pobox.com> wrote:
> It would be illustrative if David did the following.
>
> $ cd $HOME
> $ cp -a V W
> $ rm -fr W/.git
> $ cd W
> $ GIT_DIR=$HOME/V/.git git diff @{midnight}
>
> Now we are in a random place outside of the work tree
> (i.e. "W"), and we drive "git diff" with GIT_DIR specified,
> telling it to pretend that we are at the top level of the work
> tree. So ~/W/frotz is compared with "frotz" at the top level of
> the commit (which usually is compared with ~/V/frotz), etc. But
> the directory we happen to be in very much resembles the work
> tree, so it would give identical results to
>
> $ cd $HOME/V
> $ git diff @{midnight}
To separate the two issues, I did all the commands to the diff
above and then removed one directory from the tree in W.
GIT_DIR=$HOME/V/.git git diff master~1
(which ought not need reflogs, right) and it gave a diff between
the contents of W and master~1. I also tried with commit
master@{midnight} and that also gave the difference between
W and the last commit yesterday. So Junio's explanation of what's going on
is right. I'm just asking if there's a way to say
"the `working dir' associated with this git dir" explicitly (in the same
way I can use `HEAD' to refer to the topmost commit on the
current branch) when you're not somewhere within the 'working dir'.
If there's not I can alias around it with
"cd $HOME/V && command && cd -". (As I say, for reasons unrelated
to git usage I don't actually "do work" within the tracked tree.)
Many thanks,
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee
^ permalink raw reply
* Problem importing a subversion repository with git-svnimport
From: Guillaume Chazarain @ 2007-09-24 16:49 UTC (permalink / raw)
To: git
Hello,
Here is a simple testcase illustrating a conversion problem between
subversion and git. git-svn handles it fine, but git-svnimport keeps
stuff in the checkout that shouldn't be there.
# git --version => git version 1.5.3.2.99.ge4b2
# svn --version | head -n 1 => svn, version 1.4.3 (r23084)
mkdir test-svn
cd test-svn
svnadmin create svn-repo
svn co file://$PWD/svn-repo svn-check-out
cd svn-check-out
mkdir trunk branches tags
svn add *
svn ci -m 'SVN dirs'
cd trunk
mkdir -p a/b/c/d
echo A > a/A
echo B > a/b/B
echo C > a/b/c/C
echo D > a/b/c/d/D
svn add a
svn ci -m 'Add some data'
svn mv a/b .
svn rm b/c
svn ci -m 'Some shuffling around'
ls -R
cd ../..
mkdir git-repo
cd git-repo
git-svnimport file://$PWD/../svn-repo
ls -R
After the subversion manipulations, the svn checkout only contains the
directories a/ b/ with their respective files A and B.
The checkout from git-svnimport contains these elements, but also the
full c/ directory in b/.
Hope the testcase is clear enough ;-)
--
Guillaume
^ permalink raw reply
* Re: The msysGit Herald, issue 2
From: Junio C Hamano @ 2007-09-24 16:49 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Linus Torvalds, Johannes Schindelin, msysgit, git
In-Reply-To: <46F7E2A5.6030202@eudaptics.com>
Johannes Sixt <j.sixt@eudaptics.com> writes:
> Linus Torvalds schrieb:
>
>> ...
>> Or maybe you did fetch a tracking branch?
>
> I don't think I fetched a tracking branch. If I do:
>
> $ mkdir foo && cd foo && git init
> $ git fetch ../git master:refs/heads/master
>
> (where ../git is a clone of git.git with a few local changes), I get
> all the tags. Good or bad?
That's exactly Linus meant "fetching a tracking branch". Your
refspec has non-empty string on the RHS of the colon.
$ git fetch ../git master
is the form without tracking. IOW, not storing into your refs
namespace.
^ permalink raw reply
* Re: behaviour of git diff, GIT_DIR & checked out tree
From: Junio C Hamano @ 2007-09-24 16:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Tweed, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0709241400410.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 24 Sep 2007, David Tweed wrote:
>
>> ... In
>> a different directory, OUTSIDE of $HOME/V, I tried
>>
>> env GIT_DIR=$HOME/V/.git git diff master@{midnight}
>>
>> to get the same effect but, whilst I do get a diff output, it
>> looks like a diff of the commit against an empty tree.
>
> Yes, this is fully expected.
>
> The @{time} notation accesses the _reflogs_, which are purely local
> beasts. They are not transmitted when cloning.
Yeah, but my reading of the problem description suggests the two
cases refer to the same repository (hence the same reflogs).
The issue is that the second case runs "git diff <one-tree>" in
a random directory. This form is about comparing the part of
work tree you are in with a given tree, and does not make _any_
sense when outside the work tree. Usually without GIT_DIR
environment, the command would give you an error message.
With $GIT_DIR, but without $GIT_WORK_TREE, the user is telling
the command that it is being run at the top level of the work
tree and the repository metadata is not in the usual ".git"
subdirectory of the top level of the work tree (in this case, by
definition that is "$PWD/.git") but elsewhere where $GIT_DIR
specifies. Because it is very likely that the files under the
random location does not share much resemblance to what are in
$HOME/V, it is not surprising that the output consisted of many
deletions.
It would be illustrative if David did the following.
$ cd $HOME
$ cp -a V W
$ rm -fr W/.git
$ cd W
$ GIT_DIR=$HOME/V/.git git diff @{midnight}
Now we are in a random place outside of the work tree
(i.e. "W"), and we drive "git diff" with GIT_DIR specified,
telling it to pretend that we are at the top level of the work
tree. So ~/W/frotz is compared with "frotz" at the top level of
the commit (which usually is compared with ~/V/frotz), etc. But
the directory we happen to be in very much resembles the work
tree, so it would give identical results to
$ cd $HOME/V
$ git diff @{midnight}
^ permalink raw reply
* Re: git-svn: Deleting directories
From: Adam Roben @ 2007-09-24 16:37 UTC (permalink / raw)
To: Russ Brown; +Cc: git
In-Reply-To: <46F7C3EA.2080806@gmail.com>
Russ Brown wrote:
> I've just noticed that when deleting entire directory trees in git, when
> the dcommit happens only the files in that trees get deleted, which
> leaves a 'ghost town' of a directory tree with folders but no files,
> which will no doubt have somewhat confused my svn-using colleagues.
>
> This is obviously an interoperability problem, but I understand that git
> does not track folders and is so tricky to fix.
>
> The question though is how to handle it. Ideally, dcommit will detect
> that an entire directory has gone and send through a changeset which
> deletes just that one directory, instead of the current behaviour of
> explicitly deleting every file in the directory but leaving the
> directories themselves intact.
>
There's a similar problem when renaming a directory. dcommit will
essentially commit a series of moves of individual files rather than
moving the whole directory. Again this is due to git not tracking
directories. I should hope that whatever logic is used for detecting a
directory removal may also be used for detecting a directory rename.
-Adam
^ permalink raw reply
* Re: The msysGit Herald, issue 2
From: Johannes Schindelin @ 2007-09-24 16:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Linus Torvalds, msysgit, git
In-Reply-To: <46F7E2A5.6030202@eudaptics.com>
Hi,
On Mon, 24 Sep 2007, Johannes Sixt wrote:
> Linus Torvalds schrieb:
> >
> > On Sun, 23 Sep 2007, Johannes Schindelin wrote:
> > > > 6) What was the most frustrating moment when working with Git?
> > > Just the other day, I wanted to fetch a set of changes from a public
> > > repo into my test repo in order to cherry-pick from them - and it
> > > automatically fetched all the tags. But, the heck, I don't want them tags
> > > here, just the commits. I just can't figure out how to avoid the
> > > automatic
> > > fetching of tags.
> >
> > The way this was *supposed* to work is that if you are not fetching a
> > "tracking branch", it should not fetch any tags.
> >
> > Maybe this got broken lately?
> >
> > Or maybe you did fetch a tracking branch?
>
> I don't think I fetched a tracking branch. If I do:
>
> $ mkdir foo && cd foo && git init
> $ git fetch ../git master:refs/heads/master
>
> (where ../git is a clone of git.git with a few local changes), I get all the
> tags. Good or bad?
The ":refs/heads/master" part says that you fetch into a tracking branch.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Supplant the "while case ... break ;; esac" idiom
From: Junio C Hamano @ 2007-09-24 16:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Miles Bader, Eygene Ryabinkin, Pierre Habouzit, git
In-Reply-To: <Pine.LNX.4.64.0709241502330.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 24 Sep 2007, Miles Bader wrote:
>> ...
>> In practice that's not an issue though -- every reasonable shell has
>> test as a builtin these days, so the "works when test is not a builtin"
>> criteria is really important only for robustness.
>
> AAAAAAAAAAAAAARRRRRGGGHHHHHHHHHHHH!
>
> _Exactly_ the same reasoning can be said about the old code: _every_
> reasonable shell can grok the code that used to be there!
>
> <rhetoric-question>
> So what exactly was your point again?
> </rhetoric-question>
The points are:
(1) The code used to be there is known to cause trouble with a
deployed shell on FreeBSD of some vintage. It may be true
that the shell is broken, but it does not matter much to
the end user on such systems if breakage is in shell or in
scripts --- the end result is that the user cannot benefit
from git, and we already happen to know the workaround,
which does not make the scripts less readable nor less
portable;
(2) It's not like people who work on git scripts share the
exact same style and tradition. While I do not personally
think there is much readability improvements between the
old code and the new code, if more people find the latter
easier to work with, it's better to switch to the new code
especially because there is no downside.
(2-a) Nobody finds the latter less readable nor impossible
to work with. Even I am not saying that; I only said
I do not think it improves.
(2-b) git is not an educational project. It can be done
elsewhere in a UNIX history class, not here, to teach
people that "case ... esac" used to be much more
preferred over "test" because often the latter was
not built-in and slower.
Regarding "$# != 0" vs "$# -ne 0", I agree with the patch by
David. If the variable were "$something_else", then it might
have been better to use the explicitly numeric form, but I think
any seasoned shell people is much more used to see $# and $? (or
$status after an earlier "status=$?") compared with numeric
string with "=" or "!=".
^ permalink raw reply
* Re: The msysGit Herald, issue 2
From: Johannes Sixt @ 2007-09-24 16:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, msysgit, git
In-Reply-To: <alpine.LFD.0.999.0709240840310.3579@woody.linux-foundation.org>
Linus Torvalds schrieb:
>
> On Sun, 23 Sep 2007, Johannes Schindelin wrote:
>>> 6) What was the most frustrating moment when working with Git?
>> Just the other day, I wanted to fetch a set of changes from a public
>> repo into my test repo in order to cherry-pick from them - and it
>> automatically fetched all the tags. But, the heck, I don't want them tags
>> here, just the commits. I just can't figure out how to avoid the automatic
>> fetching of tags.
>
> The way this was *supposed* to work is that if you are not fetching a
> "tracking branch", it should not fetch any tags.
>
> Maybe this got broken lately?
>
> Or maybe you did fetch a tracking branch?
I don't think I fetched a tracking branch. If I do:
$ mkdir foo && cd foo && git init
$ git fetch ../git master:refs/heads/master
(where ../git is a clone of git.git with a few local changes), I get all the
tags. Good or bad?
-- Hannes
^ permalink raw reply
* Re: The msysGit Herald, issue 2
From: Linus Torvalds @ 2007-09-24 15:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: msysgit, git
In-Reply-To: <Pine.LNX.4.64.0709232153230.28395@racer.site>
On Sun, 23 Sep 2007, Johannes Schindelin wrote:
>
> > 6) What was the most frustrating moment when working with Git?
>
> Just the other day, I wanted to fetch a set of changes from a public
> repo into my test repo in order to cherry-pick from them - and it
> automatically fetched all the tags. But, the heck, I don't want them tags
> here, just the commits. I just can't figure out how to avoid the automatic
> fetching of tags.
The way this was *supposed* to work is that if you are not fetching a
"tracking branch", it should not fetch any tags.
Maybe this got broken lately?
Or maybe you did fetch a tracking branch?
Anyway, I fetch stuff all the time, and if git were to fetch the tags too,
I'd be *really* unhappy. So either the people I work with are just good
people, or more likely it still works the way it's supposed to work: if
you just fetch into FETCH_HEAD (by explicitly giving the remote repository
name, and not using tracking branches), it should not fetch tags for you.
Linus
^ permalink raw reply
* Re: [PATCH] Supplant the "while case ... break ;; esac" idiom
From: Miles Bader @ 2007-09-24 14:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Eygene Ryabinkin, Pierre Habouzit, git
In-Reply-To: <Pine.LNX.4.64.0709241502330.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> In practice that's not an issue though -- every reasonable shell has
>> test as a builtin these days, so the "works when test is not a builtin"
>> criteria is really important only for robustness.
>
> AAAAAAAAAAAAAARRRRRGGGHHHHHHHHHHHH!
>
> _Exactly_ the same reasoning can be said about the old code: _every_
> reasonable shell can grok the code that used to be there!
As has been stated, that's not true. Some "real" shells don't handle
the old code correctly (and the old code is less readable as well).
AFAIK, the new code works all cases, it's merely very slightly slower in
unusual circumstances.
-Miles
--
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy this into your sig so it can spread.
^ permalink raw reply
* Re: [PATCH] Supplant the "while case ... break ;; esac" idiom
From: David Kastrup @ 2007-09-24 14:24 UTC (permalink / raw)
To: git
In-Reply-To: <85ps08k2fj.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Well, as we all know that we disagree on this point, stating what
>> you consider one-sidedly here is quite inappropriate.
>
> Hm. If I create a patch after you basically said "go ahead, I don't
> mind, but I consider it unimportant", how am I going to put the
> motivation for the patch in the commit message while expressing
> _your_ opinion? I thought that using "I" to make clear that it is
> my personal view would be doing that.
>
> So what am I supposed to write instead?
>
> "There is no good reason for this patch, but we might as well do
> it."?
[...]
>> In other words, I am somewhat disgusted with the first part of
>> your proposed commit log message, although I like what the patch
>> does ;-).
>
> Could you propose a commit message that would be acceptable to you,
> yet not make it appear like a mistake to actually commit the patch?
>
>>> -while case "$#" in 0) break ;; esac
>>> +while test "$#" != 0
>>> do
>>> case "$1" in
>>> -a)
>>
>> And let's not quote "$#".
>
> I kept this as it was originally. Some authors prefer to quote
> every shell variable as a rule in order to avoid stupid syntactic
> things happening. Of course, $# never needs quoting, but I did not
> want to change the personal style of the respective authors. I can
> make this consistent if you want to.
It seems like the window of opportunity to fix the objectable commit
message has closed for me, as well as doing the work of removing the
"$#" (which you did already): I find that the patch has already made
it into upstream.
I am somewhat taken aback that a commit message considered offensive
(though I still have a problem understanding why and certainly did not
intend this) has been committed into master without giving me a chance
to amend it.
Unfortunately, the ensuing discussion around the _technical_ merits is
somewhat lopsided since Dscho keeps me in his killfile, and so the
commit message in the repository is all he'll ever be able to see from
me concerning this matter.
Which makes it more unfortunate that I have not been able to amend it.
Too bad.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] Supplant the "while case ... break ;; esac" idiom
From: David Kastrup @ 2007-09-24 14:10 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0709241502330.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Mon, 24 Sep 2007, Miles Bader wrote:
>
>> Eygene Ryabinkin <rea-git@codelabs.ru> writes:
>> >> The comment "... holds only for a shell where [ is a builtin" doesn't
>> >> make any sense to me
>> >
>> > The 'while case ...' construct does not invoke any external commands.
>> > The 'while test ...' too, but only when 'test' is builtin. When
>> > 'test' is the external binary you get one additional fork/exec per
>> > each cycle.
>>
>> In practice that's not an issue though -- every reasonable shell has
>> test as a builtin these days, so the "works when test is not a builtin"
>> criteria is really important only for robustness.
>
> AAAAAAAAAAAAAARRRRRGGGHHHHHHHHHHHH!
>
> _Exactly_ the same reasoning can be said about the old code: _every_
> reasonable shell can grok the code that used to be there!
There are no known shells that would not grok the proposed code, and
the BSD shells don't grok the "code that used to be there".
So what point is there in preserving compatibility with some mystical
non-specified shell while breaking compatibility with actually
existing shells?
And by using a less human-readable idiom, to boot?
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] Supplant the "while case ... break ;; esac" idiom
From: David Kastrup @ 2007-09-24 13:58 UTC (permalink / raw)
To: git
In-Reply-To: <87k5qgrxcu.fsf@catnip.gol.com>
Miles Bader <miles@gnu.org> writes:
> Eygene Ryabinkin <rea-git@codelabs.ru> writes:
>>> The comment "... holds only for a shell where [ is a builtin" doesn't
>>> make any sense to me
>>
>> The 'while case ...' construct does not invoke any external commands.
>> The 'while test ...' too, but only when 'test' is builtin. When
>> 'test' is the external binary you get one additional fork/exec per
>> each cycle.
>
> In practice that's not an issue though -- every reasonable shell has
> test as a builtin these days, so the "works when test is not a builtin"
> criteria is really important only for robustness.
Since the external test is pretty standardized, "works when test is
one of various builtins" is actually more important for robustness...
--
David Kastrup
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: David Kastrup @ 2007-09-24 13:57 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20070924T134013-959@post.gmane.org>
figo <rcc_dark@hotmail.com> writes:
> http://www.research.att.com/~bs/applications.html
>
> just as Bjarne once wrote in his TC++PL, its hard to teach an old dog new
> tricks. Its even harder to give quality education about how to use something
> to someone who doesnt want to learn.
>
> you hate high level, then continue programming operative systems,
> please NEVER DO something else. C++ was designed to give programmers
> high level tools and still being able to take care about
> performance.
>
> portability wont be possible after a standard is published and some
>couple of years given to the compiler developers. C++ had its
>standard in 1998, and add two or three years for compiler development
>= 2002. "Quite recently", way more recently that your last use of C++
>I can bet.
Care to explain why there are still not two numerical C++ libraries
with compatible matrix classes?
What use is talking about portability and high level when a basic
interoperability feature that has been available since the sixties
(more than 4 decades ago) in Fortran has not yet managed to make it
into C++? C++ by now more or less offers a (somewhat deficient)
standardized way to work with complex numbers, but matrices are still
not standardized in any manner, and libraries won't interoperate.
So C++ should get its head wrapped around the _low_ level problems
first. It is a bloody shame that it still has not caught up with
Fortran IV (or even Fortran II) with regard to usefulness for
numerical libraries.
It is not a matter of "hating high level" to see that C++ is mostly
focused about addressing the wrong kinds of problems in the wrong
ways. The pain/gain ratio is just bad.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] Supplant the "while case ... break ;; esac" idiom
From: Johannes Schindelin @ 2007-09-24 14:04 UTC (permalink / raw)
To: Miles Bader; +Cc: Eygene Ryabinkin, Pierre Habouzit, git
In-Reply-To: <87k5qgrxcu.fsf@catnip.gol.com>
Hi,
On Mon, 24 Sep 2007, Miles Bader wrote:
> Eygene Ryabinkin <rea-git@codelabs.ru> writes:
> >> The comment "... holds only for a shell where [ is a builtin" doesn't
> >> make any sense to me
> >
> > The 'while case ...' construct does not invoke any external commands.
> > The 'while test ...' too, but only when 'test' is builtin. When
> > 'test' is the external binary you get one additional fork/exec per
> > each cycle.
>
> In practice that's not an issue though -- every reasonable shell has
> test as a builtin these days, so the "works when test is not a builtin"
> criteria is really important only for robustness.
AAAAAAAAAAAAAARRRRRGGGHHHHHHHHHHHH!
_Exactly_ the same reasoning can be said about the old code: _every_
reasonable shell can grok the code that used to be there!
<rhetoric-question>
So what exactly was your point again?
</rhetoric-question>
Ciao,
Dscho
^ permalink raw reply
* git-svn: Deleting directories
From: Russ Brown @ 2007-09-24 14:04 UTC (permalink / raw)
To: git
I've just noticed that when deleting entire directory trees in git, when
the dcommit happens only the files in that trees get deleted, which
leaves a 'ghost town' of a directory tree with folders but no files,
which will no doubt have somewhat confused my svn-using colleagues.
This is obviously an interoperability problem, but I understand that git
does not track folders and is so tricky to fix.
The question though is how to handle it. Ideally, dcommit will detect
that an entire directory has gone and send through a changeset which
deletes just that one directory, instead of the current behaviour of
explicitly deleting every file in the directory but leaving the
directories themselves intact.
--
Russ
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: figo @ 2007-09-24 13:41 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.999.0709061839510.5626@evo.linux-foundation.org>
http://www.research.att.com/~bs/applications.html
just as Bjarne once wrote in his TC++PL, its hard to teach an old dog new
tricks. Its even harder to give quality education about how to use something
to someone who doesnt want to learn.
you hate high level, then continue programming operative systems, please NEVER
DO something else. C++ was designed to give programmers high level tools and
still being able to take care about performance.
portability wont be possible after a standard is published and some couple of
years given to the compiler developers. C++ had its standard in 1998, and add
two or three years for compiler development = 2002. "Quite recently", way more
recently that your last use of C++ I can bet.
^ permalink raw reply
* Re: [PATCH] Supplant the "while case ... break ;; esac" idiom
From: Miles Bader @ 2007-09-24 13:45 UTC (permalink / raw)
To: Eygene Ryabinkin; +Cc: Johannes Schindelin, Pierre Habouzit, git
In-Reply-To: <20070924113556.GI8111@void.codelabs.ru>
Eygene Ryabinkin <rea-git@codelabs.ru> writes:
>> The comment "... holds only for a shell where [ is a builtin" doesn't
>> make any sense to me
>
> The 'while case ...' construct does not invoke any external commands.
> The 'while test ...' too, but only when 'test' is builtin. When
> 'test' is the external binary you get one additional fork/exec per
> each cycle.
In practice that's not an issue though -- every reasonable shell has
test as a builtin these days, so the "works when test is not a builtin"
criteria is really important only for robustness.
> I believe that this trick comes from the old days where people were
> generally much more eager to save CPU cycles than now ;))
Yes. I still occasionally find myself using "case" where if+test might
be more natural, but I think it's basically an anachronism these days,
and causes more harm by reducing readability than good.
-Miles
--
The car has become... an article of dress without which we feel uncertain,
unclad, and incomplete. [Marshall McLuhan, Understanding Media, 1964]
^ 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