On Tue, 6 Sep 2005, Martin Langhoff wrote:
Grep knows how to ignore binary files.
That wasn't the _point_.
The point is, naming things as being scripts is useful. Grep is just an
example. Naming things as being .pl or .sh is _not_ useful.
So with grep you can use -I, but what about doing
Linus Torvalds [EMAIL PROTECTED] writes:
The point is, naming things as being scripts is useful. Grep is just an
example. Naming things as being .pl or .sh is _not_ useful.
Sorry, but why not?
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL
On 9/6/05, Linus Torvalds [EMAIL PROTECTED] wrote:
That wasn't the _point_.
Agreed - sorry I should have qualified my comment.
I agree with having useful extensions for ease of development. And I
agree with the suggestion of installing them with stripped extensions
-- to extend the abstraction.
On Tue, 6 Sep 2005, Junio C Hamano wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
The point is, naming things as being scripts is useful. Grep is just an
example. Naming things as being .pl or .sh is _not_ useful.
Sorry, but why not?
What's the upside?
I can point to one downside:
Linus Torvalds [EMAIL PROTECTED] writes:
What's the upside?
I can point to one downside: git. That script right now is simple. If
you rewrite git-cvsimport-script from shell to perl, it looks the same to
git.
What I've been working on was to:
* have git-cvsimport.perl in the source
*
Junio C Hamano [EMAIL PROTECTED] writes:
Linus Torvalds [EMAIL PROTECTED] writes:
What's the upside?
I can point to one downside: git. That script right now is simple. If
you rewrite git-cvsimport-script from shell to perl, it looks the same to
git.
What I've been working on was to:
Horst von Brand wrote:
Junio C Hamano [EMAIL PROTECTED] wrote:
Tim Ottinger [EMAIL PROTECTED] writes:
git-update-cache for instance?
I am not sure which 'cache' commands need to be 'index' now.
Logically you are right, but I suspect that may not fly well in practice. Too
By the way, I'm not sure how the 'git' script is supposed to be used.
I know that if there is a git-foo-script file in your path, you can
run it as 'git foo'. But what about e.g. git-init-db? You can run
that as 'git init-db' today. And 'git read-cache' should work too.
And 'git ls-files',
On Mon, 5 Sep 2005, David Kågedal wrote:
But to the users (like myself), there's no point in naming it by
whether it's a script or a binary.
So? There's no downside.
To you, as a user, you never see the -script ending anyway. You'd never
type it out, or you're already doing something
Linus Torvalds [EMAIL PROTECTED] writes:
On Mon, 5 Sep 2005, David Kågedal wrote:
But to the users (like myself), there's no point in naming it by
whether it's a script or a binary.
So? There's no downside.
To you, as a user, you never see the -script ending anyway. You'd never
type
Linus Torvalds [EMAIL PROTECTED] writes:
... and I don't see _any_ point to naming
by what _kind_ of interpreter you use. Why would _anybody_ care whether
something is written in perl vs shell?
One possibility that comes to mind is to again help developers
who use an editor that is
On 9/6/05, Linus Torvalds [EMAIL PROTECTED] wrote:
Grepping for strings.
For example, when renaming a binary, the sane way to check that you fixed
all users right now is
grep old-binary-name *.c *.h *-scripts
and you catch all users.
Grep knows how to ignore binary files. Try:
Junio C Hamano [EMAIL PROTECTED] wrote:
I said:
I'll draw up a strawman tonight unless somebody else
does it first.
[...]
3. Non-binaries are called '*-scripts'.
In earlier discussions some people seem to like the
distinction between *-script and others; I did not
Horst von Brand [EMAIL PROTECTED] writes:
3. Non-binaries are called '*-scripts'.
In earlier discussions some people seem to like the
distinction between *-script and others; I did not
particularly like it, but I am throwing this in for
discussion.
I for one think this makes
Peter Williams [EMAIL PROTECTED] writes:
*.pl is what is usually used for perl scripts.
My recollection may be faulty, but '*.pl' was meant to be used
for older Perl libraries back in perl4 days, and the standalone
scripts are to be named '*.perl' but many people made the
mistake of naming them
I said:
I'll draw up a strawman tonight unless somebody else
does it first.
1. Say 'index' when you are tempted to say 'cache'.
git-checkout-cache git-checkout-index
git-convert-cache git-convert-index
git-diff-cache git-diff-index
On Thu, 1 Sep 2005, Junio C Hamano wrote:
Tim Ottinger [EMAIL PROTECTED] writes:
git-update-cache for instance?
I am not sure which 'cache' commands need to be 'index' now.
Logically you are right, but I suspect that may not fly well in
practice. Too many of us have already got our
Junio C Hamano wrote:
Tim Ottinger [EMAIL PROTECTED] writes:
So when this gets all settled, will we see a lot of tool renaming?
I personally do not see it coming. Any particular one you have
in mind?
git-update-cache for instance?
I am not sure which 'cache' commands need to
Tim Ottinger [EMAIL PROTECTED] writes:
git-update-cache for instance?
I am not sure which 'cache' commands need to be 'index' now.
Logically you are right, but I suspect that may not fly well in
practice. Too many of us have already got our fingers wired to
type cache, and the glossary is
So when this gets all settled, will we see a lot of tool renaming?
While it would cause me and my team some personal effort (we have
a special-purpose porcelain), it would be welcome to have a lexicon
that is sane and consistent, and in tune with all the documentation.
Others may feel
Tim Ottinger [EMAIL PROTECTED] writes:
So when this gets all settled, will we see a lot of tool renaming?
I personally do not see it coming. Any particular one you have
in mind?
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More
Hi,
long, long time. Here´s my first stab at the glossary, attached the
alphabetically sorted, asciidoc marked up txt file (Comments?
Suggestions? Pizzas?):
object::
The unit of storage in GIT. It is uniquely identified by
the SHA1 of its contents. Consequently, an object can
On Wed, 17 Aug 2005, Johannes Schindelin wrote:
Hi,
long, long time. Here?s my first stab at the glossary, attached the
alphabetically sorted, asciidoc marked up txt file (Comments?
Suggestions? Pizzas?):
object::
The unit of storage in GIT. It is uniquely identified
Hi,
On Wed, 17 Aug 2005, Daniel Barkalow wrote:
On Wed, 17 Aug 2005, Johannes Schindelin wrote:
SHA1::
A 20-byte sequence (or 41-byte file containing the hex
representation and a newline). It is calculated from the
contents of an object by the Secure Hash Algorithm 1.
Johannes Schindelin [EMAIL PROTECTED] writes:
Okay for hash. What is the consensus on object name being more
standard than SHA1?
The tutorial uses the term object name, so does README
(implicitly, by saying All objects are named by their content,
which is approximated by the SHA1 hash of the
Hi,
On Wed, 17 Aug 2005, Daniel Barkalow wrote:
On Wed, 17 Aug 2005, Johannes Schindelin wrote:
On Wed, 17 Aug 2005, Daniel Barkalow wrote:
[...]
Okay for hash.
I think we only need at most two names for this, so this is more a matter
of fixing old usage than documenting it.
It's
26 matches
Mail list logo
