The "master" branch post 0.99.6 already has the renamed tools
with backward compatibility symlinks. I'll be sending a
patch to address an issue raised by some people separately to
see what the list thinks, and also will attempt to send out a
patch for the Pasky and Catalin heads later this week.
Junio C Hamano <[EMAIL PROTECTED]> writes:
> My proposal to have git-archimport.perl in the source tree and
> install it as $(bindir)/git-archimport solves the editability
> issues (sorry, Linus, you will have to say "em *.sh *.perl"
> instead of "em *-script" if we did this) and simplifies the
>
> 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-fil
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
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 w
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 so
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 t
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 abstractio
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
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
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 fil
David K.ANegedal <[EMAIL PROTECTED]> writes:
> If the "-script" part is supposed to be hidden from me, why do I keep
> seeing it everywhere I turn?
>
>> So to users it doesn't matter, and to developers it _does_ matter (and
>> calling them ".pl" or ".sh" or something would be _bad_), why not pl
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 synt
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
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 Sun, 4 Sep 2005, Horst von Brand wrote:
>> > I had the same opinion. The counter-argument people raised when
>> > this topic came up on the list was that it would help grepping
>> > in the source tree.
>>
>> Grepping for what?
>
> Grepping for stri
On Sun, 4 Sep 2005, Horst von Brand wrote:
> > I had the same opinion. The counter-argument people raised when
> > this topic came up on the list was that it would help grepping
> > in the source tree.
>
> Grepping for what?
Grepping for strings.
For example, when renaming a binary, the sane
Horst von Brand <[EMAIL PROTECTED]> writes:
> Junio C Hamano <[EMAIL PROTECTED]> wrote:
>> I had the same opinion. The counter-argument people raised when
>> this topic came up on the list was that it would help grepping
>> in the source tree.
>
> Grepping for what?
I am only a messenger for the
Junio C Hamano <[EMAIL PROTECTED]> wrote:
> 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 th
Junio C Hamano wrote:
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 mad
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 th
Junio C Hamano wrote:
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
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 th
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 di
On Sat, 3 Sep 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > I think "fetch" is more applicable to what they do.
>
> OK. then they are git-http-fetch and friends. How about
> git-ssh-push? The counterpart of fetch-pack/clone-pack is
> called upload-pack, so wo
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> Agreed, except that git-convert-cache and git-fsck-cache actually have
> nothing to do this the index by any name, and should probably be
> git-convert-objects and git-fsck-objects.
You are right.
> I think "fetch" is more applicable to what they d
On Fri, 2 Sep 2005, Junio C Hamano wrote:
> 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-
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
t any actual conflicts, and we
> might as well have new users pick up the logical names. I particularly
> think "git merge" would be really good to have.
OK. As Horst also says, we should do this before 1.0.
0.99.6::
This hopefully will be done on Sep 7th. Tool renam
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
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 many of us have already got ou
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
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:
> 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]
M
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 different
35 matches
Mail list logo
