Re: Tool renames? was Re: First stab at glossary
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 things like em * when doing global renames (I use micro-emacs - em - as my editor). Again, em *-script actually works. The point being that if we have naming rules, make them USEFUL. *-script is useful - it works wonderfully well for git xxx (which knows to add -script), and it works wonderfully well for developers. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
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 PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
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. OTOH... 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. Hrmmm. Not so convinced about that. There are good reasons to distinguish files with different internal syntax. Perhaps it's your C-bias but for script maintainers it isn't helpful to deal with -script prefixes. If a bash script is rewritten in C, it is a useful and meaningful change (from a developer perspective) that the file changes name. Both can live in the tree while the new one matures, running diffs or pickaxes will show one file created and another removed, instead of a very meaningless diff. The same applies if it is rewritten in Perl, or Python. IOW: Perl programmers are developers too ;-) cheers, martin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
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: git. That script right now is simple. If you rewrite git-cvsimport-script from shell to perl, it looks the same to git. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
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
* install it as $(bindir)/git-cvsimport
* simplify 'git' (whose source is of course in 'git.sh') to
only do:
cmd=$1; shift; exec git-$cmd ${1+$@}
Naturally, the rewrite of git-cvsimport in shell or C would look
the same to git.
One potential downside (for people who consider this a downside)
is that you cannot easily run uninstalled, but you already
cannot run tools/git-applymbox and git-cherry-pick uninstalled
anyway, and I do not think it is such a big deal.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
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: * have git-cvsimport.perl in the source * install it as $(bindir)/git-cvsimport That was what I suggested too, although I don't really care if it's called .perl or -script in the source. 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', and 'git rev-parse', and 'git merge-one-file' and 'git sh-setup-script' in decreasing order of usefulness... But running 'git' without arguments only list the -script commands as available. -- David Kågedal - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
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 many of us have already got our fingers wired to type cache, and the glossary is there to describe both cache andindex. I'd vote for cleaning it up /now/. Sure, it will hurt, but if you let time go by and do it later, it will hurt much more. Pre-1.0 is the last chance, AFAICS. I guess it all depends on whether your target audience is already using it an happy with how it is, or whether your target audience is yet to be reached. Is git growing? Do we expect to suddenly find git upside down, where there are a few old-timers awash in a sea of newbies? Do we care? If you care, and git is growing, then probably it makes sense to choose the greatest good for the greatest number, I guess. Personally, I'm a newbie and I find the command set confusing and hard to internalize for reasons mostly dealing with naming, but also because I don't have 6 months shared history with all of you. I have to learn it partly from docs and partly through folklore gleaned from the list (which moves pretty quickly). Maybe that's just complaining, but maybe it is pointing out a weakness that's correctable. -- ... either 'way ahead of the game, or 'way out in left field. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
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', and 'git rev-parse', and 'git merge-one-file' and 'git sh-setup-script' in decreasing order of usefulness... But running 'git' without arguments only list the -script commands as available. You are correct. I think 'git' showing only *-script was done as an attempt to give a list of Porcelainish commands, excluding the core commands that people are not supposed to be typing from the command line. It so happened that all of the Porcelainish commands were scripts. But what Linus wants *-script to mean is editability in the source tree (his grep and em examples). The command being Porcelainish and the command being implemented as a script tend to have strong correlations, but in principle they are orthogonal. As you mention, 'git merge-one-file' is not really useful standalone, neither is 'git sh-setup'. On the other hand, 'git fsck-cache' is. 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 first half of the 'git' wrapper (it just needs to attempt running git-$1), but does not help what the latter half of 'git' wrapper does (to give you the list of Porcelainish commands). To make 'git' wrapper produce useful 'list of subcommands', we need to come up with a list of Porcelainish commands, be they written in C or sh or Perl, and tell 'git' about that list. Current implementation cheats by assuming everything that ends with *-script are such, but it does not have to stay that way. I'd nominate all $(SCRIPTS) in Makefile and tools/Makefile except *1*, plus *2* as the list of subcommands 'git' wrapper would show. List *1*: implemented as script but not Porcelainish. git git-merge-one-file-script git-sh-setup-script List *2*: implemented in C but Porcelainish. git-init-db git-fsck-cache git-get-tar-commit-id git-apply git-patch-id git-pack-objects git-show-branch - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
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 wrong. 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 please the developers? So your argument that it makes it easier for git developers to work with the source doesn't help the user. It doesn't _help_ the user, but since it doesn't hurt him either, why the hell would we even _care_ about the user? Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
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 it out, or you're already doing something wrong. Then I'm doing something wrong. And I'm pretty sure others are too. If I'm not supposed to see the -script ending, then don't install it in my $PATH. Until someone (possibly myself) writes some zsh completion code to handle git sub command, I will continue to hit TAB and see all those names. Furthermore, the man page for git clone is called git-clone-script(1). And the -script suffix appears inside the documentation in various places. I see it in howtos and log messages. And the git-merge-one-file-script script is supposed to be used in a way where I have to supply the long name. Etc. 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 please the developers? I'm not suggesting we'd call them .pl or .sh. -- David Kågedal - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
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 syntax-aware and looks *only* at filename suffix to figure out which language syntax to use (Emacs is not one of them -- it knows how to read #! line). Another is, although we do not currently do it, to make the Makefile simpler if/when we start to do the interpreter line munging (#!/usr/bin/perl - #!/usr/local/bin/perl) before install time. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
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: grep -I git-commit * cheers, martin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
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 particularly like it, but I am throwing this in for discussion. I for one think this makes the command name dependent on a non-essential implementation detail, so -script should go. -- 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, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
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 the command name dependent on a non-essential
implementation detail, so -script should go.
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.
I'm tempted to suggest doing something along these lines:
- Rename things that are implemented in shell from *-script to
*.sh, and perl to *.perl in the source tree;
- Install them without .{sh,perl} suffix.
Once this is done, the users nor the 'git' wrapper do not have
to deal with *-script.
Comments?
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
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 '*.pl'. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
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 git-fsck-cache git-fsck-index git-merge-cache git-merge-index git-update-cachegit-update-index 2. The act of combining two or more heads is called 'merging'; fetching immediately followed by merging is called 'pulling'. git-resolve-script git-merge-script The commit walkers are called *-pull, but this is probably confusing. They are not pulling. git-http-pull git-http-walk git-local-pull git-local-walk git-ssh-pullgit-ssh-walk 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. git-applymbox git-applymbox-script git-applypatch git-applypatch-script git-cherry git-cherry-script git-shortloggit-shortlog-script git-whatchanged git-whatchanged-script 4. To be removed shortly. git-clone-dumb-http should be folded into git-clone-script - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
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 fingers wired to type cache, and the glossary is there to describe both cache and index. My vote's for changing the official names, but keeping symlinks for the old names. As far as I know, there aren'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. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
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 be 'index' now. -- ... either 'way ahead of the game, or 'way out in left field. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
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 there to describe both cache and index. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Tool renames? was Re: First stab at glossary
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 differently, I understand. -- ... either 'way ahead of the game, or 'way out in left field. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tool renames? was Re: First stab at glossary
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 majordomo info at http://vger.kernel.org/majordomo-info.html
