threads / discuss / 1203

Re: Trial git RPM's..

Subject: Re: Trial git RPM's..

## tl;dr

19 messages between Jul 11, 2005 and Dec 2, 2006.

replies: 18people: 7as markdown or json

Horst von Brand· Jul 11, 2005, 20:11 UTC · lore
Linus Torvalds <torvalds@osdl.org> wrote:
> On Mon, 11 Jul 2005, Eric W. Biederman wrote:
> > A couple of pieces.  The dist target has assumes git-tar-tree is in the
> > path.  Making it so you have to have git installed to build the rpm.
> Yes. Maybe we could relax that requirement by using "./git-tar-tree" or 
> something? That still requires that you have _built_ git to do the rpm, 
> but at least you won't have had to install it.
I don't see a problem here. Sure, you need git to build git, so place it in
Build-requires: Need to install the binary to build the next from source,
that's all. Just like gcc ;-)
[...]
> > The man pages are not built. The build dependencies do not call out
> > the tools necessary to build the man pages.
> Most people don't have asciidoc, and I'm not sure we want to require it. 
> Maybe we could have a separate "make man-rpm" target for that?

Would have to be a requirement for building anyway. There is a (not really nice) SRPM at <http://www.pvv.ntnu.no/~terjeros/rpms/asciidoc/>. Will see to clean it up.

-- 
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, Chile                Fax:  +56 32 797513
Horst von Brand· Sep 16, 2005, 04:08 UTC · lore

Re: "Read my lips: no more merges" - aka Linux 2.6.14-rc1

Linus Torvalds <torvalds@osdl.org> wrote:
Show 10 quoted lines
> On Wed, 14 Sep 2005, Alejandro Bonilla Beeche wrote:
> > 
> > debian:~# cd linux-2.6/
> > debian:~/linux-2.6# git log
> > /usr/local/bin/git-log-script: line 4: less: command not found
> 
> A very strange Linux installation that doesn't come with "less"...
> 
> What a strange box. Anyway, that does point out that maybe the git RPM 
> spec should have "less" as a dependency. 
Your wish is my command.

---- The git commands assume less(1) as pager. This adds the dependency, as suggested by Linus.

Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
 git-core.spec.in |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)
0abd0856f2cb750a019451c7547694f36e60e83b
diff --git a/git-core.spec.in b/git-core.spec.in
--- a/git-core.spec.in
+++ b/git-core.spec.in
@@ -10,7 +10,7 @@ URL: 		http://kernel.org/pub/software/sc
 Source: 	http://kernel.org/pub/software/scm/git/%{name}-%{version}.tar.gz
 BuildRequires:	zlib-devel, openssl-devel, curl-devel  %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
 BuildRoot:	%{_tmppath}/%{name}-%{version}-root
-Requires: 	sh-utils, curl, diffutils, rsync, rcs, openssh-clients, perl, python >= 2.4, tk
+Requires: 	sh-utils, curl, diffutils, less, rsync, rcs, openssh-clients, perl, python >= 2.4, tk
 
 %description
 This is a stupid (but extremely fast) directory content manager.  It
@@ -44,6 +44,9 @@ rm -rf $RPM_BUILD_ROOT
 %{!?_without_docs: %{_mandir}/man7/*.7*}
 
 %changelog
+* Fri Sep 16 2005 Horst H. von Brand <vonbrand@inf.utfsm.cl>
+- Linus noticed that less is required, added to the dependencies
+
 * Sun Sep 11 2005 Horst H. von Brand <vonbrand@inf.utfsm.cl>
 - Updated dependencies
 - Don't assume manpages are gzipped
Horst von Brand· Sep 29, 2005, 23:17 UTC · lore

Re: [howto] Kernel hacker's guide to git, updated

Linus Torvalds <torvalds@osdl.org> wrote:
[...]
> Of course, pico is still pico. Which I find a bit sad: my editor of choise 
> is still an improved version of uemacs, and pico actually comes from the 
> same uemacs history, but has different key-bindings for just enough keys 
> to be slightly confusing.

Can I get a URL for the source for your editor? The one on kernel.org doesn't compile, and probably hasn't for a long time.

[Yes, there is some (perverse) fun in telling people you use the very same
 editor than Linus Torvalds :-]> 
-- 
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, Chile                Fax:  +56 32 797513
Linus Torvalds· Sep 30, 2005, 00:47 UTC · re: Horst von Brand · lore

Re: [howto] Kernel hacker's guide to git, updated

On Thu, 29 Sep 2005, Horst von Brand wrote:
> 
> Can I get a URL for the source for your editor? The one on kernel.org
> doesn't compile, and probably hasn't for a long time.
Oh, it compiles with trivial modifications. Not cleanly, but it works.
I put my git repo on 
	kernel.org:/pub/software/editors/uemacs/uemacs.git
but it will take a moment to mirror out. 

The "readme" says non-commercial only, but I asked Daniel Lawrence if it was ok to include it in commercial distributions a long time ago, and he said yes. Sadly, I've lost that email, so I don't have any paper trail for that. So you should consider the readme binding.

> [Yes, there is some (perverse) fun in telling people you use the very same
>  editor than Linus Torvalds :-]> 

The thing is, it's not a wonderful editor. It's small, and good enough, but I really wished somebody wrote something that handled UTF-8, for example. But I've got the keybindings hardcoded in my spine, so I can't ever change.

		Linus
Junio C Hamano· Sep 30, 2005, 01:54 UTC · re: Linus Torvalds · lore

Re: [howto] Kernel hacker's guide to git, updated

Linus Torvalds <torvalds@osdl.org> writes:
Show 5 quoted lines
> I put my git repo on 
>
> 	kernel.org:/pub/software/editors/uemacs/uemacs.git
>
> but it will take a moment to mirror out. 

Wouldn't underneath pub/scm/ be more appropriate and gitweb friendly?

> The thing is, it's not a wonderful editor. It's small, and good enough, 
> but I really wished somebody wrote something that handled UTF-8, for 
> example.

Hmph. I vaguely recall in my distant past when I was still in school, I did my own Japanization of microEmacs. I wonder if yours share the same root -- I do not have the source of my version anymore so I have no way checking which ancient version I mucked with.

Linus Torvalds· Sep 30, 2005, 02:36 UTC · re: Junio C Hamano · lore

Re: [howto] Kernel hacker's guide to git, updated

On Thu, 29 Sep 2005, Junio C Hamano wrote:
> 
> Wouldn't underneath pub/scm/ be more appropriate and gitweb
> friendly?

Well, I don't actually have write permissions to anything there except for udner the kernel tree. Also, I suspect there aren't all that many uemacs users out there, and anybody who isn't already a uemacs user probably shouldn't pick it up.

I don't think it has gotten any real development for the last ten years, and while it was arguably the best editor twenty years ago (not a lot of competition - what else worked on DOS, VMS and UNIX without being crazy and modal?) it's definitely showing its age.

So since I already had a uemacs subdirectory, I just put the git archive there too.

Show 5 quoted lines
> Hmph.  I vaguely recall in my distant past when I was still in
> school, I did my own Japanization of microEmacs.  I wonder if
> yours share the same root -- I do not have the source of my
> version anymore so I have no way checking which ancient version
> I mucked with.

It's based on 3.9e, with some fixes by Petri Kutvonen at Helsinki University. With various (slight) modernizations by yours truly (eg posix termios support rather than the old "termio" stuff).

It _shouldn't_ be that hard to teach it about UTF-8, but every time I look at it I realize that there is a lot of stuff that should be improved. Converting it to K&R, getting rid of the things that made sense in the 80's but haven't made sense in ten years, re-indenting it (right now it's a strange mix of indentation styles)..

And if you open a binary file with it, it will literally spew binary characters to the tty, and can seriously confuse it due to the control chars. Or if you have a really long line, it can SIGSEGV on you. Cute.

But dammit, I'm not giving it up.
			Linus
Linus Torvalds· Oct 1, 2005, 00:10 UTC · re: Linus Torvalds · lore

Re: [howto] Kernel hacker's guide to git, updated

On Thu, 29 Sep 2005, Linus Torvalds wrote:
> 
> I put my git repo on 
> 
> 	kernel.org:/pub/software/editors/uemacs/uemacs.git

Gaah. You guys shamed me into actually trying to clean up the sources a bit.

It's by no means done, but some of it is even sparse-clean now.

I suspect there's a lot of it that still works mainly by luck than because it does anything right.

		Linus
Horst von Brand· Oct 1, 2005, 01:58 UTC · lore

Re: [howto] Kernel hacker's guide to git, updated

Linus Torvalds <torvalds@osdl.org> wrote:
Show 8 quoted lines
> On Thu, 29 Sep 2005, Linus Torvalds wrote:
> > 
> > I put my git repo on 
> > 
> > 	kernel.org:/pub/software/editors/uemacs/uemacs.git
> 
> Gaah. You guys shamed me into actually trying to clean up the sources a 
> bit.

I'd been trying my hand at the original version. Need to merge my changes with yours...

-- 
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, Chile                Fax:  +56 32 797513
Linus Torvalds· Oct 3, 2005, 01:03 UTC · re: Horst von Brand · lore

Re: [howto] Kernel hacker's guide to git, updated

[ Sorry about the spam, most of you probably have never cared ]
On Fri, 30 Sep 2005, Horst von Brand wrote:
> 
> I'd been trying my hand at the original version. Need to merge my changes
> with yours...

Heh, now that I got into cleaning things up, I've also been actually fixing things that have long irritated me, but the code was just too messy for me, and my level of care wasn't high enough to overcome.

I fixed the "outputs binary data in the 128-159 range to the terminal" yesterday (which would quite possibly corrupt terminal state if trying to edit binary files), and today I added a "utf-8" mode.

The utf-8 mode is purely about the _terminal_ being in UTF-8. The actual editor is still very much byte-char based, but now it understands 8-bit input that comes in UTF8-encoded, and can output things in UTF-8 format.

(Since UTF-8 is basically always used with Unicode, and the 8-bit subset of Unicode is iso-8859-1 aka Latin1, this is probably _less_ international than the non-UTF8, but hey, what can I say? If you want more, you'd need to teach uemacs about actual UTF8 contents).

The new "emacs.rc" will enable utf-8 mode automatically if $LANG contains the substring "UTF-8", since that _usually_ means that the terminal is in utf-8 mode. If it's wrong, you can add or delete the mode by hand (just like any global mode: Meta-X to add, Meta-Ctrl-X to delete).

Basically, it means that you don't have to switch the whole terminal into latin1 just to use uemacs.

			Linus
Horst von Brand· Nov 1, 2005, 23:11 UTC · lore

Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)

Linus Torvalds <torvalds@osdl.org> wrote:
> On Mon, 31 Oct 2005, H. Peter Anvin wrote:
> > The git-core RPM definitiely needs to be split.  Doubly ironic that it's
> > called "core".
Show 5 quoted lines
> I don't think it's necessarily ironic. It's actually a good thing.
> 
> I think that what we want to have is one _project_ (called "git"), which 
> can generate multiple RPM's ("git-core", "git-svnimport", "git-docs", 
> whatever).

Better cut along outside requirements: git-svn, git-cvs, git-scm-du-jour, git-gtk. Please _don't_ split out documentation.

> So I think it was good that we called the RPM "git-core". We've just not 
> yet done the obvious thing to create a few _other_ RPM's.
Right.
> Now, I'm not certain how happy RPM would be with having one source RPM 
> generate multiple binary RPM's,

Works fine. It is exactly what is used to build -devel packages. What doesn't work is doing multiple architectures, e.g. creating git-core-1.2.3.i386.rpm and git-gitk-1.2.3.noarch.rpm, in one 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, Chile                Fax:  +56 32 797513
Horst von Brand· May 27, 2006, 12:52 UTC · lore

Re: ~/.git/config ?

Linus Torvalds <torvalds@osdl.org> wrote:
Show 5 quoted lines
> On Sat, 27 May 2006, Petr Baudis wrote:
> > 
> > ~/.gitrc might get useful for actually doing what ~/.cvsrc or ~/.cgrc
> > does, that is providing default options for git commands. ~/.gitconfig
> > would just give you per-user defaults for the repository config file.
Yep.
[...]
Show 5 quoted lines
> So they would do "alias cvs git" in a desperate attempt to save themselves 
> from CVS, and then add
> 
> 	[alias "co"]
> 		cmd = commit -a

I don't like this syntax. What other stuff (beside "cmd") would be under "[alias "co"]? Why not simply:

        [alias]
		co = commit -a
		publish = push public.site.com:/pub/scm/my-public-repo
-- 
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, Chile                Fax:  +56 32 797513
Petr Baudis· May 28, 2006, 21:59 UTC · re: Horst von Brand · lore

[PATCH] Support for configurable git command aliases

Dear diary, on Sat, May 27, 2006 at 02:52:35PM CEST, I got a letter where Horst von Brand <vonbrand@inf.utfsm.cl> said that...

Show 12 quoted lines
> > So they would do "alias cvs git" in a desperate attempt to save themselves 
> > from CVS, and then add
> > 
> > 	[alias "co"]
> > 		cmd = commit -a
> 
> I don't like this syntax. What other stuff (beside "cmd") would be under
> "[alias "co"]? Why not simply:
> 
>         [alias]
> 		co = commit -a
> 		publish = push public.site.com:/pub/scm/my-public-repo
Nice, I like this.

Well, the following isn't exactly the nicest code I have ever written... But it seems to work. ;-)

---

This patch adds support for configurable aliases for git commands - "alias.WHATEVER = which ever" will kick in when you do "git WHATEVER" and substitute WHATEVER with "which ever" (splitted to arguments at whitespaces).

Signed-off-by: Petr Baudis <pasky@suse.cz>
---
 Documentation/config.txt |    5 ++++
 Documentation/git.txt    |    3 +++
 git.c                    |   52 ++++++++++++++++++++++++++++++++++++++++++++--
 3 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index d1a4bec..ce616e3 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -83,6 +83,11 @@ core.warnAmbiguousRefs::
 	If true, git will warn you if the ref name you passed it is ambiguous
 	and might match multiple refs in the .git/refs/ tree. True by default.
 
+alias.*::
+	Command aliases for the gitlink:git[1] command wrapper - e.g.
+	after defining "alias.last = cat-file commit HEAD", the invocation
+	"git last" is equivalent to "git cat-file commit HEAD".
+
 apply.whitespace::
 	Tells `git-apply` how to handle whitespaces, in the same way
 	as the '--whitespace' option. See gitlink:git-apply[1].
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 24ca55d..e474bdf 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -21,6 +21,9 @@ link:everyday.html[Everyday Git] for a u
 "man git-commandname" for documentation of each command.  CVS users may
 also want to read link:cvs-migration.html[CVS migration].
 
+The COMMAND is either a name of a Git command (see below) or an alias
+as defined in the configuration file (see gitlink:git-repo-config[1]).
+
 OPTIONS
 -------
 --version::
diff --git a/git.c b/git.c
index 10ea934..0d9cd0e 100644
--- a/git.c
+++ b/git.c
@@ -10,6 +10,7 @@ #include <limits.h>
 #include <stdarg.h>
 #include "git-compat-util.h"
 #include "exec_cmd.h"
+#include "cache.h" /* setup_git_directory_gently() */
 
 #include "builtin.h"
 
@@ -87,13 +88,27 @@ static void handle_internal_command(int 
 	}
 }
 
+static const char *cmd;
+static char *cmdalias;
+
+int git_alias_config(const char *var, const char *value)
+{
+	if (strncmp(var, "alias.", 6))
+		return 0;
+	var += /* strlen("alias.") */ 6;
+	if (!strcmp(var, cmd))
+		cmdalias = strdup(value);
+	return 0;
+}
+
 int main(int argc, const char **argv, char **envp)
 {
-	const char *cmd = argv[0];
-	char *slash = strrchr(cmd, '/');
+	char *slash = strrchr(argv[0], '/');
 	char git_command[PATH_MAX + 1];
 	const char *exec_path = NULL;
 
+	cmd = argv[0];
+
 	/*
 	 * Take the basename of argv[0] as the command
 	 * name, and the dirname as the default exec_path
@@ -165,6 +180,39 @@ int main(int argc, const char **argv, ch
 	}
 	argv[0] = cmd;
 
+	/* Is this an alias? */
+	{
+		/* XXX: We do a redundant git directory detection. */
+		int nongit = 0;
+		const char *subdir = setup_git_directory_gently(&nongit);
+
+		if (!nongit) {
+			git_config(git_alias_config);
+			if (cmdalias) {
+				/* More than the worst case: */
+				const char **argv2 = malloc((strlen(cmdalias) + argc) * sizeof(char*));
+				int argc2 = 0, i = 1;
+
+				while (cmdalias && *cmdalias) {
+					argv2[argc2++] = strsep(&cmdalias, " \t");
+					if (cmdalias)
+						while (*cmdalias == ' ' || *cmdalias == '\t')
+							cmdalias++;
+				}
+				while (i < argc) {
+					argv2[argc2++] = argv[i++];
+				}
+				argv2[argc2] = NULL;
+				argv = argv2;
+				argc = argc2;
+			}
+		}
+
+		/* Go back so that the commands start with clean table */
+		if (subdir)
+			chdir(subdir);
+	}
+
 	/*
 	 * We search for git commands in the following order:
 	 *  - git_exec_path()
-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
Jakub Narebski· May 28, 2006, 22:57 UTC · re: Petr Baudis · lore

Re: [PATCH] Support for configurable git command aliases

Petr Baudis wrote:
Show 14 quoted lines
> Dear diary, on Sat, May 27, 2006 at 02:52:35PM CEST, I got a letter
> where Horst von Brand <vonbrand@inf.utfsm.cl> said that...
>>
>> I don't like this syntax. What other stuff (beside "cmd") would be under
>> "[alias "co"]? Why not simply:
>> 
>>         [alias]
>>              co = commit -a
>>              publish = push public.site.com:/pub/scm/my-public-repo
> 
> Nice, I like this.
> 
> Well, the following isn't exactly the nicest code I have ever written...
> But it seems to work. ;-)

Well, if [alias] would be used also for giving default options for git commands, e.g.

        [alias]
            log = log --pretty

(from what Petr "Pasky" Baudis said on IRC, currently on the right side there should be only true git commands, which eliminates nicely problems with recursion ;-), it would be better to ensure that aliases are checked *only* for interactive sessions - otherwise using aliases for default arguments would/could mess the scripts.

-- 
Jakub Narebski
Warsaw, Poland
Jeff King· May 29, 2006, 03:58 UTC · re: Jakub Narebski · lore

Re: [PATCH] Support for configurable git command aliases

On Mon, May 29, 2006 at 12:57:26AM +0200, Jakub Narebski wrote:
Show 5 quoted lines
> Well, if [alias] would be used also for giving default options for git
> commands, e.g.
> 
>         [alias]
>             log = log --pretty
A funny side effect of that would be that "git log" and "git-log" would
now have completely different defaults (unless the alias mechanism
starts intercepting direct calls to git-*, which seems invasive). I
wonder if it might be simpler to just add 
  core.defaults.log = "--pretty"
or similar.
-Peff
Junio C Hamano· May 29, 2006, 02:01 UTC · re: Petr Baudis · lore

Re: [PATCH] Support for configurable git command aliases

Petr Baudis <pasky@ucw.cz> writes:
Show 8 quoted lines
>> I don't like this syntax. What other stuff (beside "cmd") would be under
>> "[alias "co"]? Why not simply:
>> 
>>         [alias]
>> 		co = commit -a
>> 		publish = push public.site.com:/pub/scm/my-public-repo
>
> Nice, I like this.

Sorry, I don't. The left hand side of '=' does not allow anything but alnum and squashes the case. Please stick to [alias "co"] syntax.

Petr Baudis· May 29, 2006, 08:02 UTC · re: Junio C Hamano · lore

Re: [PATCH] Support for configurable git command aliases

Dear diary, on Mon, May 29, 2006 at 04:01:48AM CEST, I got a letter where Junio C Hamano <junkio@cox.net> said that...

Show 13 quoted lines
> Petr Baudis <pasky@ucw.cz> writes:
> 
> >> I don't like this syntax. What other stuff (beside "cmd") would be under
> >> "[alias "co"]? Why not simply:
> >> 
> >>         [alias]
> >> 		co = commit -a
> >> 		publish = push public.site.com:/pub/scm/my-public-repo
> >
> > Nice, I like this.
> 
> Sorry, I don't.  The left hand side of '=' does not allow
> anything but alnum and squashes the case.

Does that really matter that much? Perhaps we might support something like

	"!ooOk" = commit -a

(and it will probably not do what the user expects if he sticks whitespaces in).

> Please stick to [alias "co"] syntax.

That sucks, e.g. because it's alias-specific, and it's inconsistent. I can't have anything like "cgalias" then.

Let's make some effort to keep the syntax clean...
-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
Horst H. von Brand· Dec 2, 2006, 20:59 UTC · lore

Re: On removing files and "git-rm is pointless"

Linus Torvalds <torvalds@osdl.org> wrote:
[...]
Show 10 quoted lines
> One thing to look out for: "git rm" actually defaults to the recursive 
> behaviour, something that might take people by surprise. If you give it a 
> directory name, it will happily delete all tracked files from within that 
> directory, even without "-r". That is probably a design mistake. So it 
> would probably make sense to:
> 
>  - without "-r", don't do the partial matches at the beginning (but still 
>    do globbing matches, of course, so "git rm dir/*" wouldn't need an 
>    "-r", but "git rm -r dir/", which does the same thing, _would_ need an 
>    "-r" to be effective)

The command should never even see the '*' here. Globbing is handled (uniformly) by the shell. Don't loose that.

-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Sam Vilain· Dec 2, 2006, 21:10 UTC · re: Horst H. von Brand · lore

Re: On removing files and "git-rm is pointless"

Horst H. von Brand wrote:
Show 7 quoted lines
>>  - without "-r", don't do the partial matches at the beginning (but still 
>>    do globbing matches, of course, so "git rm dir/*" wouldn't need an 
>>    "-r", but "git rm -r dir/", which does the same thing, _would_ need an 
>>    "-r" to be effective)
> 
> The command should never even see the '*' here. Globbing is handled
> (uniformly) by the shell. Don't loose that.
But;
  git-rm \*>/dev/null; git-add \*
is just so darned handy!
Linus Torvalds· Dec 2, 2006, 21:33 UTC · re: Horst H. von Brand · lore

Re: On removing files and "git-rm is pointless"

On Sat, 2 Dec 2006, Horst H. von Brand wrote:
> 
> The command should never even see the '*' here. Globbing is handled
> (uniformly) by the shell. Don't loose that.
Git supprts an extra level of globbing.
In the kernel tree, try the difference between these two command lines:
	git ls-files fs/*.c
	
	git ls-files 'fs/*.c'
and enjoy.

It's _very_ useful for a number of programs (including "git add") but I find it _especially_ useful for something like

	git grep jiffies -- '*.h'
where the git-level globbign is important.
Not all git programs do that globbing, but many do.

← back to recent threads