# Re: Trial git RPM's.. 19 messages from 2005-07-11 to 2006-12-02. Participants: Horst von Brand, Linus Torvalds, Junio C Hamano, Petr Baudis, Jakub Narebski, Jeff King, Horst H. von Brand, Sam Vilain. Thread: https://gitlist.dev/t/1203 ## Horst von Brand, 2005-07-11 20:11 Subject: Re: Trial git RPM's.. Message-ID: <200507112011.j6BKBBwx011503@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200507112011.j6BKBBwx011503%40laptop11.inf.utfsm.cl In-Reply-To: ``` Linus Torvalds 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 . 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, 2005-09-16 04:08 Subject: Re: "Read my lips: no more merges" - aka Linux 2.6.14-rc1 Message-ID: <200509160415.j8G48Oto006070@inti.inf.utfsm.cl> URL: https://gitlist.dev/e/200509160415.j8G48Oto006070%40inti.inf.utfsm.cl In-Reply-To: ``` Linus Torvalds wrote: > 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 --- 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 +- Linus noticed that less is required, added to the dependencies + * Sun Sep 11 2005 Horst H. von Brand - Updated dependencies - Don't assume manpages are gzipped ``` ## Horst von Brand, 2005-09-29 23:17 Subject: Re: [howto] Kernel hacker's guide to git, updated Message-ID: <200509292317.j8TNHC7S022247@inti.inf.utfsm.cl> URL: https://gitlist.dev/e/200509292317.j8TNHC7S022247%40inti.inf.utfsm.cl In-Reply-To: ``` Linus Torvalds 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, 2005-09-30 00:47 Subject: Re: [howto] Kernel hacker's guide to git, updated Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0509291742170.3378%40g5.osdl.org In-Reply-To: <200509292317.j8TNHC7S022247@inti.inf.utfsm.cl> ``` 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, 2005-09-30 01:54 Subject: Re: [howto] Kernel hacker's guide to git, updated Message-ID: <7vwtkzb9qo.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vwtkzb9qo.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Linus Torvalds writes: > 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, 2005-09-30 02:36 Subject: Re: [howto] Kernel hacker's guide to git, updated Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0509291918530.3378%40g5.osdl.org In-Reply-To: <7vwtkzb9qo.fsf@assigned-by-dhcp.cox.net> ``` 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. > 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, 2005-10-01 00:10 Subject: Re: [howto] Kernel hacker's guide to git, updated Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0509301709350.3378%40g5.osdl.org In-Reply-To: ``` 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, 2005-10-01 01:58 Subject: Re: [howto] Kernel hacker's guide to git, updated Message-ID: <200510010158.j911wiB3005296@inti.inf.utfsm.cl> URL: https://gitlist.dev/e/200510010158.j911wiB3005296%40inti.inf.utfsm.cl In-Reply-To: ``` Linus Torvalds wrote: > 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, 2005-10-03 01:03 Subject: Re: [howto] Kernel hacker's guide to git, updated Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0510021752390.31407%40g5.osdl.org In-Reply-To: <200510010158.j911wiB3005296@inti.inf.utfsm.cl> ``` [ 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, 2005-11-01 23:11 Subject: Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug) Message-ID: <200511012311.jA1NBGii003792@inti.inf.utfsm.cl> URL: https://gitlist.dev/e/200511012311.jA1NBGii003792%40inti.inf.utfsm.cl In-Reply-To: ``` Linus Torvalds 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". > 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, 2006-05-27 12:52 Subject: Re: ~/.git/config ? Message-ID: <200605271252.k4RCqZhR003192@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200605271252.k4RCqZhR003192%40laptop11.inf.utfsm.cl In-Reply-To: ``` Linus Torvalds wrote: > 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. [...] > 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, 2006-05-28 21:59 Subject: [PATCH] Support for configurable git command aliases Message-ID: <20060528215945.GD10488@pasky.or.cz> URL: https://gitlist.dev/e/20060528215945.GD10488%40pasky.or.cz In-Reply-To: <200605271252.k4RCqZhR003192@laptop11.inf.utfsm.cl> ``` Dear diary, on Sat, May 27, 2006 at 02:52:35PM CEST, I got a letter where Horst von Brand said that... > > 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 --- 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 #include #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, 2006-05-28 22:57 Subject: Re: [PATCH] Support for configurable git command aliases Message-ID: URL: https://gitlist.dev/e/e5d9sm%245d4%241%40sea.gmane.org In-Reply-To: <20060528215945.GD10488@pasky.or.cz> ``` Petr Baudis wrote: > Dear diary, on Sat, May 27, 2006 at 02:52:35PM CEST, I got a letter > where Horst von Brand 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 ``` ## Junio C Hamano, 2006-05-29 02:01 Subject: Re: [PATCH] Support for configurable git command aliases Message-ID: <7v7j45d1wz.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v7j45d1wz.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20060528215945.GD10488@pasky.or.cz> ``` Petr Baudis 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. Please stick to [alias "co"] syntax. ``` ## Jeff King, 2006-05-29 03:58 Subject: Re: [PATCH] Support for configurable git command aliases Message-ID: <20060529035857.GA7641@coredump.intra.peff.net> URL: https://gitlist.dev/e/20060529035857.GA7641%40coredump.intra.peff.net In-Reply-To: ``` On Mon, May 29, 2006 at 12:57:26AM +0200, Jakub Narebski wrote: > 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 ``` ## Petr Baudis, 2006-05-29 08:02 Subject: Re: [PATCH] Support for configurable git command aliases Message-ID: <20060529080246.GT11941@pasky.or.cz> URL: https://gitlist.dev/e/20060529080246.GT11941%40pasky.or.cz In-Reply-To: <7v7j45d1wz.fsf@assigned-by-dhcp.cox.net> ``` Dear diary, on Mon, May 29, 2006 at 04:01:48AM CEST, I got a letter where Junio C Hamano said that... > Petr Baudis 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, 2006-12-02 20:59 Subject: Re: On removing files and "git-rm is pointless" Message-ID: <200612022059.kB2Kx565009646@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200612022059.kB2Kx565009646%40laptop13.inf.utfsm.cl In-Reply-To: ``` Linus Torvalds wrote: [...] > 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, 2006-12-02 21:10 Subject: Re: On removing files and "git-rm is pointless" Message-ID: <4571EBD7.2040004@vilain.net> URL: https://gitlist.dev/e/4571EBD7.2040004%40vilain.net In-Reply-To: <200612022059.kB2Kx565009646@laptop13.inf.utfsm.cl> ``` Horst H. von Brand wrote: >> - 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, 2006-12-02 21:33 Subject: Re: On removing files and "git-rm is pointless" Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0612021330070.3476%40woody.osdl.org In-Reply-To: <200612022059.kB2Kx565009646@laptop13.inf.utfsm.cl> ``` 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. ```