# Re: Status of git.git repository 96 messages from 2005-08-01 to 2007-01-12. Participants: Horst von Brand, Johannes Schindelin, Matthias Urlichs, Junio C Hamano, Peter Williams, Linus Torvalds, David Kågedal, Martin Langhoff, Tim Ottinger, H. Peter Anvin, Kay Sievers, Petr Baudis, Horst H. von Brand, Nicolas Pitre, Shawn Pearce, Jakub Narebski. Thread: https://gitlist.dev/t/1386 ## Horst von Brand, 2005-08-01 03:29 Subject: Re: Status of git.git repository Message-ID: <200508010329.j713Tg76008388@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200508010329.j713Tg76008388%40laptop11.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: [...] > By the way, do people mind my posting my own patches to the > list? I keep the same in the "pu" (proposed updates) branch, so > if the list readers think I am just adding noise to the list > traffic, I would stop doing so, and instead just invite > interested people to browse the "pu" branch. It's fine with me for you to post your patches here. I'd hope that by posting your patches get more review (and might spark ideas elsewhere). I.e., open source development, Linus style. -- 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-08-08 03:18 Subject: Re: GIT 0.99.4 (preview) Message-ID: <200508080318.j783IJNw012384@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200508080318.j783IJNw012384%40laptop11.inf.utfsm.cl In-Reply-To: ``` My proposed patch, the description as is is misleading. The rest of the .spec file looks sane (yes, I've built my share of RPMs over the years). diff --git a/git-core.spec.in b/git-core.spec.in --- a/git-core.spec.in +++ b/git-core.spec.in @@ -2,7 +2,7 @@ Name: git-core Version: @@VERSION@@ Release: 1 -Vendor: Linus Torvalds +Vendor: Junio C Hamano Summary: Git core and tools License: GPL Group: Development/Tools @@ -13,22 +13,23 @@ BuildRoot: %{_tmppath}/%{name}-%{version Prereq: sh-utils, diffutils, rsync, rcs, mktemp >= 1.5 %description -GIT comes in two layers. The bottom layer is merely an extremely fast -and flexible filesystem-based database designed to store directory trees -with regard to their history. The top layer is a SCM-like tool which -enables human beings to work with the database in a manner to a degree -similar to other SCM tools (like CVS, BitKeeper or Monotone). +This is a stupid (but extremely fast) directory content manager. It +doesn't do a whole lot, but what it _does_ do is track directory +contents efficiently. It is intended to be the base of an efficient, +distributed source code management system. This package includes +rudimentary tools that can be used as a SCM, but you should look +elsewhere for tools for ordinary humans layered on top of this. %prep %setup -q %build - make prefix=%{_prefix} all %{!?_without_docs: doc} %install rm -rf $RPM_BUILD_ROOT -make dest=$RPM_BUILD_ROOT prefix=%{_prefix} mandir=%{_mandir} install install-tools %{!?_without_docs: install-doc} +make dest=$RPM_BUILD_ROOT prefix=%{_prefix} mandir=%{_mandir} \ + install install-tools %{!?_without_docs: install-doc} %clean rm -rf $RPM_BUILD_ROOT @@ -43,7 +44,13 @@ rm -rf $RPM_BUILD_ROOT %{!?_without_docs: %{_mandir}/man7/*.7.gz} %changelog +* Sun Aug 07 2005 Horst H. von Brand +- Redid the description +- Cut overlong make line, loosened changelog a bit +- I think Junio (or perhaps OSDL?) should be vendor... + * Thu Jul 14 2005 Eric Biederman - Add the man pages, and the --without docs build option + * Wed Jul 7 2005 Chris Wright - initial git spec file -- 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-08-10 02:20 Subject: Re: Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards Message-ID: <200508100220.j7A2KNWb005040@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200508100220.j7A2KNWb005040%40laptop11.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > Johannes Schindelin writes: > > >> True. My bad old habit. > > > > An elegant method to do that: > > > > case --some-long-option in "$1"*) ..; esac > > You are almost correct, but you need to realize that I generate > that long "case -s|--s|--so|--som|..." chain using a script that > takes all potential option names as its arguments, and makes > case arms that contain only unambiguous ones, so that I can > handle --some-long-option and --some-other-long-option sensibly. My head spins.... Isn't it easier to just use getopt(1)? > Also you forgot to grok --some-option-with-args=* in your > version ;-). Please stop! I'm dizzy already! -- 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 ``` ## Johannes Schindelin, 2005-08-10 12:52 Subject: Re: Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0508101451200.19746%40wgmdd8.biozentrum.uni-wuerzburg.de In-Reply-To: <200508100220.j7A2KNWb005040@laptop11.inf.utfsm.cl> ``` Hi, On Tue, 9 Aug 2005, Horst von Brand wrote: > Isn't it easier to just use getopt(1)? Only if GNU getopt is available. On Mac OS X, only the BSD version is installed by default, which does not handle long options at all. > Please stop! I'm dizzy already! :-) Ciao, Dscho ``` ## Horst von Brand, 2005-08-16 19:41 Subject: Re: Git 1.0 Synopis (Draft v4) Message-ID: <200508161941.j7GJfpI3023107@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200508161941.j7GJfpI3023107%40laptop11.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: [...] > - Oh, another itch I did not list in the previous message. Is > anybody interested in doing an Emacs VC back-end for GIT? And teach make(1) about checking out files from git... or just create a co(1) command for git. -- 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 ``` ## Johannes Schindelin, 2005-08-16 20:41 Subject: Re: Git 1.0 Synopis (Draft v4) Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0508162240060.19656%40wgmdd8.biozentrum.uni-wuerzburg.de In-Reply-To: <200508161941.j7GJfpI3023107@laptop11.inf.utfsm.cl> ``` Hi, On Tue, 16 Aug 2005, Horst von Brand wrote: > And teach make(1) about checking out files from git... or just create a > co(1) command for git. How about "git-checkout-script", optionally with the "-f" flag to ignore changes since the last checkout/checkin? Ciao, Dscho ``` ## Matthias Urlichs, 2005-08-18 09:27 Subject: Re: Git 1.0 Synopis (Draft v4) Message-ID: URL: https://gitlist.dev/e/pan.2005.08.18.09.27.42.884179%40smurf.noris.de In-Reply-To: <200508161941.j7GJfpI3023107@laptop11.inf.utfsm.cl> ``` Hi, Horst von Brand wrote: > And teach make(1) about checking out files from git... or just create a > co(1) command for git. Ummm... why? make's SCCS support depends on the presence of a SCCS/s. file for each . We don't have that. Teaching make about git would be equivalent to teaching it about parsing the index file. Technically, that would require a stable libgit.so or so. In reality, however, I don't know when I last had a tree which wasn't fully populated, but it's been a while, and it's something that can be readily fixed by "git-checkout-cache -a". -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - One possible reason that things aren't going according to plan is that there never was a plan in the first place. ``` ## Horst von Brand, 2005-09-02 01:50 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: <200509020150.j821oXXM006699@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200509020150.j821oXXM006699%40laptop11.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > Tim Ottinger 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. 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. -- 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-04 21:43 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: <200509042143.j84LhDZo020359@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200509042143.j84LhDZo020359%40laptop11.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano 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, Chile Fax: +56 32 797513 ``` ## Junio C Hamano, 2005-09-05 00:03 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: <7vmzmsbcuc.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vmzmsbcuc.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200509042143.j84LhDZo020359@laptop11.inf.utfsm.cl> ``` Horst von Brand 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? ``` ## Peter Williams, 2005-09-05 00:26 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: <431B90B9.4000108@bigpond.net.au> URL: https://gitlist.dev/e/431B90B9.4000108%40bigpond.net.au In-Reply-To: <7vmzmsbcuc.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > Horst von Brand 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; *.pl is what is usually used for perl scripts. > > - 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Peter Williams pwil3058@bigpond.net.au "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce ``` ## Junio C Hamano, 2005-09-05 00:35 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: <7vbr38bbcm.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vbr38bbcm.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <431B90B9.4000108@bigpond.net.au> ``` Peter Williams 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'. ``` ## Peter Williams, 2005-09-05 00:45 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: <431B9521.1010703@bigpond.net.au> URL: https://gitlist.dev/e/431B9521.1010703%40bigpond.net.au In-Reply-To: <7vbr38bbcm.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > Peter Williams 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'. I'm no expert and was just reporting what I'd observed but that observation wasn't thorough enough to notice the distinction that you make so forget what I said. :-) Peter -- Peter Williams pwil3058@bigpond.net.au "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce ``` ## Horst von Brand, 2005-09-05 00:54 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: <200509050054.j850sC3D023778@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200509050054.j850sC3D023778%40laptop11.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > Horst von Brand 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. Grepping for what? It is not /that/ much more expensive to run file(1) over the tree if you want to know what is a script and what isn't. Furthermore, the "-script" extension doesn't work for this as of today (see your own message a while back ;-). Keeping it requires discipline that tools don't help enforcing today (and the extension use itself is very un-Unix-like), so further "mistakes" /will/ happen. In any case, this would be for a very specialized, developer-only, occasional task. I don't see how that warrants a fractured tool namespace for /all/ users /all/ the time. -- 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 ``` ## Junio C Hamano, 2005-09-05 01:35 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: <7vwtlw9tzo.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vwtlw9tzo.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200509050054.j850sC3D023778@laptop11.inf.utfsm.cl> ``` Horst von Brand writes: > Junio C Hamano 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 their argument and, as I said, I did not particularly buy that argument because I myself do not find it too disturbing that a grep in my built tree says "Binary file libgit.a matches", especially I typically run grep in my Emacs buffer and C-x ` (next-error) does not get confused by such useless hits. But I can understand why it matters to people working in other environments. > In any case, this would be for a very specialized, > developer-only, occasional task. I don't see how that warrants > a fractured tool namespace for /all/ users /all/ the time. Yes, you convinced the convert again. Now I have to find a poor unsuspecting volunteer to do the actual heavylifting after 0.99.6 happens ;-). ``` ## Linus Torvalds, 2005-09-05 14:41 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0509050738340.3504%40evo.osdl.org In-Reply-To: <200509050054.j850sC3D023778@laptop11.inf.utfsm.cl> ``` 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 way to check that you fixed all users right now is grep old-binary-name *.c *.h *-scripts and you catch all users. In contrast, "grep *" will catch totally uninteresting patterns like object files etc. I personally find that very useful, 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? There's no reason to name things by the interpreter. Kubys ``` ## David Kågedal, 2005-09-05 15:13 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: URL: https://gitlist.dev/e/u5tvf1feedt.fsf%40lysator.liu.se In-Reply-To: ``` Linus Torvalds 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 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. > > In contrast, "grep *" will catch totally uninteresting patterns like > object files etc. > > I personally find that very useful, 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? There's no reason to name things by > the interpreter. But to the users (like myself), there's no point in naming it by whether it's a script or a binary. Since, as a user, I couldn't care less that git-foobar is a shell script, I don't want to pollute the command name space with "-script" suffixes. Calling the command git-foobar makes much more sense, and allows us to reimplement the scripts as binaries, or whatever. So your argument that it makes it easier for git developers to work with the source doesn't help the user. The consequence is maybe that the scripts should be called *-script in the source, but be installed without the suffix? -- David Kågedal ``` ## Linus Torvalds, 2005-09-05 16:04 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0509050902070.3568%40evo.osdl.org In-Reply-To: ``` 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 ``` ## David Kågedal, 2005-09-05 16:28 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: URL: https://gitlist.dev/e/u5tk6hveawy.fsf%40lysator.liu.se In-Reply-To: ``` Linus Torvalds 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 ``` ## Junio C Hamano, 2005-09-05 18:13 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: <7vr7c35qoe.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vr7c35qoe.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Linus Torvalds 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. ``` ## Junio C Hamano, 2005-09-05 18:23 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: <7vek835q79.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vek835q79.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` David Kågedal 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 please >> the developers? > > I'm not suggesting we'd call them ".pl" or ".sh". Well, I was. Here is what I had in mind. 1. Introduce SCRIPT_SH and SCRIPT_PERL, and make "SCRIPTS = $(SCRIPT_SH) $(SCRIPT_PERL)" in the Makefile. 2. Install git-foo.sh as $(DEST)$(bin)/git-foo 3. Documentation to describe git-foo command is Documentation/git-foo.txt I was planning to leave gitk source as gitk, not gitk.tcl nor gitk.wish nor gitk.sh for now, if only to help me merging from paurus. Depending on how people would react to the "why would people care what scripting language is the thing written in" comment by Linus, I may be persuaded otherwise though, in which case 1. is not needed, and 2. would lose '.sh', but 3. would not change. ``` ## Martin Langhoff, 2005-09-06 00:13 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: <46a038f90509051713389c62c8@mail.gmail.com> URL: https://gitlist.dev/e/46a038f90509051713389c62c8%40mail.gmail.com In-Reply-To: ``` On 9/6/05, Linus Torvalds 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 ``` ## Linus Torvalds, 2005-09-06 07:16 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0509060013520.4316%40evo.osdl.org In-Reply-To: <46a038f90509051713389c62c8@mail.gmail.com> ``` 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 ``` ## Junio C Hamano, 2005-09-06 07:46 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: <7vll2atz8a.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vll2atz8a.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Linus Torvalds 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? ``` ## Martin Langhoff, 2005-09-06 07:53 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: <46a038f90509060053cdd57e1@mail.gmail.com> URL: https://gitlist.dev/e/46a038f90509060053cdd57e1%40mail.gmail.com In-Reply-To: ``` On 9/6/05, Linus Torvalds 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 ``` ## Linus Torvalds, 2005-09-06 07:59 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0509060057491.4316%40evo.osdl.org In-Reply-To: <7vll2atz8a.fsf@assigned-by-dhcp.cox.net> ``` On Tue, 6 Sep 2005, Junio C Hamano wrote: > Linus Torvalds 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 ``` ## Junio C Hamano, 2005-09-06 08:38 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: <7vwtlusi9t.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vwtlusi9t.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Linus Torvalds 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. ``` ## David Kågedal, 2005-09-06 08:57 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: URL: https://gitlist.dev/e/u5tek82bmlb.fsf%40fidgit.hq.vtech In-Reply-To: <7vwtlusi9t.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano writes: > Linus Torvalds 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 ``` ## Tim Ottinger, 2005-09-06 16:42 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: <431DC6D9.30802@progeny.com> URL: https://gitlist.dev/e/431DC6D9.30802%40progeny.com In-Reply-To: <200509020150.j821oXXM006699@laptop11.inf.utfsm.cl> ``` Horst von Brand wrote: >Junio C Hamano wrote: > > >>Tim Ottinger 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. ``` ## Junio C Hamano, 2005-09-06 23:54 Subject: Re: Tool renames? was Re: First stab at glossary Message-ID: <7v1x41g3c6.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v1x41g3c6.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` > 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 ``` ## Junio C Hamano, 2005-09-08 01:04 Subject: Tool renames. Message-ID: <7vfysg2wvo.fsf_-_@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vfysg2wvo.fsf_-_%40assigned-by-dhcp.cox.net In-Reply-To: <7v1x41g3c6.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano 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 > 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 have done this and the first commit since 0.99.6 in the proposed updates branch contains the big rename. ``` ## Horst von Brand, 2005-09-13 17:39 Subject: Re: [PATCH] Improve "git grep" flags handling Message-ID: <200509131739.j8DHdQL1010615@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200509131739.j8DHdQL1010615%40laptop11.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: [...] > Thanks, Linus. This is what will go into "master" tonight. > > git-grep.sh | 64 ++++++++++++++++++++++++++++++++++++++--------------------- > 1 files changed, 41 insertions(+), 23 deletions(-) > > 6df4eef9b10c8de2b9bc3dc769f3a008a1200df7 > diff --git a/git-grep.sh b/git-grep.sh > --- a/git-grep.sh > +++ b/git-grep.sh > @@ -1,25 +1,43 @@ > #!/bin/sh Shouldn't shebang go /bin/bash, as the script uses bash-isms now? (For portability to non-enlightened systems the installation would have to locate bash too... and/or mention this in the INSTALL file) Or perhaps redo the mess in Perl or some such? -- 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-13 17:51 Subject: Re: [PATCH] Improve "git grep" flags handling Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0509131044340.3351%40g5.osdl.org In-Reply-To: <200509131739.j8DHdQL1010615@laptop11.inf.utfsm.cl> ``` On Tue, 13 Sep 2005, Horst von Brand wrote: > > Shouldn't shebang go /bin/bash, as the script uses bash-isms now? > (For portability to non-enlightened systems the installation would have to > locate bash too... and/or mention this in the INSTALL file) Some bash installs only install in /bin/sh, so.. > Or perhaps redo the mess in Perl or some such? Hey, the code isn't a mess. The fact that there are tons of different shells and they don't support it is the mess. So we should strive for bash syntax to be so common that other shells follow suit ;) I personally find perl to be a really bad language. It has more of a unified base (different versions, but at least not totally different and unrelated implementations), and it's clearly more powerful, but as a _language_ I don't understand how anybody can accept that crap. The "there's more than one way to do something" slogan may be cute and sound good to people who are drawn to that thing, but it's actually bad. The language is designed to be write-only, and the "you can do it fifty different ways" is part of it (and line noise characters is another part of it). So sh is actually often a much better language. Too bad some of the features end up being outside the standard language. I know, I know, people will consider me crazy for saying that. Oh, well. As long as all the _important_ stuff is in C, we're ok. Linus ``` ## Junio C Hamano, 2005-09-13 18:53 Subject: Re: [PATCH] Improve "git grep" flags handling Message-ID: <7v8xy03ilk.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v8xy03ilk.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200509131739.j8DHdQL1010615@laptop11.inf.utfsm.cl> ``` Horst von Brand writes: > Shouldn't shebang go /bin/bash, as the script uses bash-isms now? > (For portability to non-enlightened systems the installation would have to > locate bash too... and/or mention this in the INSTALL file) I heard somebody say the shell arrays actually came from Korn, so /bin/bash is a wrong thing to do if that is the case. > Or perhaps redo the mess in Perl or some such? Especially given 'xargs grep' part is moderately expensive anyway and startup overhead between shell and perl does not matter here very much, the suggestion is mildly tempting. ``` ## Linus Torvalds, 2005-09-13 19:09 Subject: Re: [PATCH] Improve "git grep" flags handling Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0509131203280.3351%40g5.osdl.org In-Reply-To: <7v8xy03ilk.fsf@assigned-by-dhcp.cox.net> ``` On Tue, 13 Sep 2005, Junio C Hamano wrote: > > I heard somebody say the shell arrays actually came from Korn, > so /bin/bash is a wrong thing to do if that is the case. Me. There are differences in indexing the arrays between ksh and bash, but I think the git-grep.sh style of usage should work on both bash and ksh. [ goes off and tests ] Indeed. I just tested the thing I sent out with "ksh git-grep.sh .." and it worked fine. Using "zsh" the grep flags don't work, and "tcsh" obviously will never run _any_ valid shell code ;) Linus ``` ## Horst von Brand, 2005-09-13 22:03 Subject: Re: dumb transports not being welcomed.. Message-ID: <200509132203.j8DM3foH008451@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200509132203.j8DM3foH008451%40laptop11.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: [...] > Using cogito is not a problem at all. The mechanism to prepare > trees to serve wider audience not being used widely is. It isn't really documented... -- 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 ``` ## Junio C Hamano, 2005-09-13 22:23 Subject: Re: dumb transports not being welcomed.. Message-ID: <7vek7swqrm.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vek7swqrm.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200509132203.j8DM3foH008451@laptop11.inf.utfsm.cl> ``` Horst von Brand writes: > Junio C Hamano wrote: > > [...] > >> Using cogito is not a problem at all. The mechanism to prepare >> trees to serve wider audience not being used widely is. > > It isn't really documented... True. The existing documentation might be sketchy. We only have the following documentation pages right now. Clarification patches are welcome. http://www.kernel.org/pub/software/scm/git/docs/tutorial.html Look for "Publishing your work" section, and "Working with Others section, "project lead" and "subsystem maintainer" subsections, both bullet point #2. http://www.kernel.org/pub/software/scm/git/docs/git-update-server-info.html The above sections in the tutorial repeatedly mentions this command. http://www.kernel.org/pub/software/scm/git/docs/repository-layout.html And git-update-server-info documentation refers to this page. Look for "objects/info/packs" and "info/refs". ``` ## H. Peter Anvin, 2005-09-15 05:56 Subject: Re: Tool renames. Message-ID: <43290D0F.9060408@zytor.com> URL: https://gitlist.dev/e/43290D0F.9060408%40zytor.com In-Reply-To: <7vfysg2wvo.fsf_-_@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > > I have done this and the first commit since 0.99.6 in the > proposed updates branch contains the big rename. > I noticed you also renamed git-ssh-{push,pull}. These tools rely on having the same names on both sides, so you have introduced a major version skew problem. -hpa ``` ## Junio C Hamano, 2005-09-15 08:03 Subject: Re: Tool renames. Message-ID: <7vr7bqahb8.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vr7bqahb8.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <43290D0F.9060408@zytor.com> ``` "H. Peter Anvin" writes: > I noticed you also renamed git-ssh-{push,pull}. These tools rely on > having the same names on both sides, so you have introduced a major > version skew problem. True. It seems that both myself and Daniel did not think that would be a major problem when we were discussing the tool renames. As a workaround, you could always say GIT_SSH_PULL='blah' and GIT_SSH_PUSH='bah' when you run either side to name what will be run on the other end. Now the interesting problem is if we should rename these environment variables ... ``` ## Junio C Hamano, 2005-09-15 08:52 Subject: Re: Tool renames. Message-ID: <7vr7bq4ssc.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vr7bq4ssc.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7vr7bqahb8.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano writes: > "H. Peter Anvin" writes: > >> I noticed you also renamed git-ssh-{push,pull}. These tools rely on >> having the same names on both sides, so you have introduced a major >> version skew problem. > > True. It seems that both myself and Daniel did not think that > would be a major problem when we were discussing the tool > renames. > > As a workaround, you could always say GIT_SSH_PULL='blah' and > GIT_SSH_PUSH='bah' when you run either side to name what will be > run on the other end. Come to think of it, I should be able to build git-ssh-push and git-ssh-pull as fully backward compatible way to call the counterpart with original name, instead of supplying just symlinks the same way I do currently. Let me work do that before I do 0.99.7 this weekend. > Now the interesting problem is if we should rename these > environment variables ... And the old and new binaries will be built separately anyway, I could use GIT_SSH_FETCH and GIT_SSH_UPLOAD in the newname binaries while keeping the old names in oldname binaries. Ack? ``` ## H. Peter Anvin, 2005-09-16 05:44 Subject: Re: Tool renames. Message-ID: <432A5BCE.3030200@zytor.com> URL: https://gitlist.dev/e/432A5BCE.3030200%40zytor.com In-Reply-To: <7vr7bq4ssc.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > > Come to think of it, I should be able to build git-ssh-push and > git-ssh-pull as fully backward compatible way to call the > counterpart with original name, instead of supplying just > symlinks the same way I do currently. Let me work do that > before I do 0.99.7 this weekend. > Better yet, always install the links, and have them use the *old* names when calling the remote end. >>Now the interesting problem is if we should rename these >>environment variables ... > > And the old and new binaries will be built separately anyway, I > could use GIT_SSH_FETCH and GIT_SSH_UPLOAD in the newname > binaries while keeping the old names in oldname binaries. Ack? Urk. Why do this rename anyway? Typically when doing new environment variables like this you do: foo = getenv("NEW_NAME"); if ( !foo ) foo = getenv("OLD_NAME"); -hpa ``` ## Junio C Hamano, 2005-09-16 06:20 Subject: Re: Tool renames. Message-ID: <7vk6hhsfcy.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vk6hhsfcy.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <432A5BCE.3030200@zytor.com> ``` "H. Peter Anvin" writes: > Urk. Why do this rename anyway? The "big rename"? Or these two environment variables? The former is because it was brought up by somebody who was introduced to git not so long time ago (i.e. fingers not so trained to use the old names and the brain wired to terminology found in the glossary document) for consistency, with favorable response from the git list. The latter is just me feeling that would make things more consistent. As I outlined, if you keep using the git-ssh-{push,pull} names, nothing should break. They call each other using old names, and 0.99.7 will ship both new and old, so one end having 0.99.5 and the other having 0.99.7 should not be a problem both ways. The same goes for those GIT_SSH_* environment variables -- backward compatible commands honor environment variables with old names. > Typically when doing new environment variables like this you do: Yes that was what we did with the other old environment names, but I can finally deprecate them in 0.99.7. Initially I said 0.99.8 will stop supporting the old names (including git-ssh-{push,pull}) and switch to new names only, but I could be talked into carrying that beyond that, although I have not heard any objections for that "dropping" plan since I initially announced it when 0.99.6 was done. But I personally prefer dropping the old names before we hit 1.0. ``` ## Horst von Brand, 2005-09-17 01:58 Subject: Re: deprecating more Message-ID: <200509170158.j8H1wOVh027636@inti.inf.utfsm.cl> URL: https://gitlist.dev/e/200509170158.j8H1wOVh027636%40inti.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: [About axing programs] > Among them, I could be talked into keeping git-export on the > condition that we will add a counterpart git-import that can > read git-export output and recreate an identical repository > [*1*]; without something like that, I doubt its usefulness, > especially since "git-whatchanged" is far more useful for > everyday use. > > [Footnote] > > *1* which I think actually is impossible without fixing > git-export first so that it exports the initial commit. I may > be mistaken. Given that you can just tar the whole repository up and handle it that way, all that work makes little sense. Note that bk export (and cg-export) copy the current snapshot into a directory or tarball, so this doesn't do what I'd expected. -- 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-20 03:12 Subject: Re: What shall we do with the GECOS field again? Message-ID: <200509200312.j8K3C2KZ002935@inti.inf.utfsm.cl> URL: https://gitlist.dev/e/200509200312.j8K3C2KZ002935%40inti.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > Linus Torvalds writes: > > The Perl User::pwent module seems to agree, btw (also about '&'): > > > > "Interpretation of the gecos field varies between systems, but > > traditionally holds 4 comma-separated fields containing the user's > > full name, office location, work phone number, and home phone number. > > > > An & in the gecos field should be replaced by the user's properly > > capitalized login name." > > I vaguelly recall seeing that & somewhere and wondering what > they do with mcdonalds ;-) You can't use it in that case. > > I still worry about names of the type "Torvalds, Linus", but maybe that's > > just not an issue. > > Does not appear to be. So I'd vote for us doing the "cut at > first comma, substitute & with toupper(login[0])+login[1..]". That is exactly the intent. -- 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-10-03 15:09 Subject: Re: What to expect after 0.99.8 Message-ID: <200510031509.j93F97Ij018270@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200510031509.j93F97Ij018270%40laptop11.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > A Large Angry SCM writes: > > > If you were to publish the ToDo to the mailing list once a week it might > > encourage more of those patches you want to accept. > > Hmph. I tend to dislike periodical posting that is more often > than once a month. > > >> * Accept patches to finish missing docs. > > > > A list of missing, incomplete, and/or wrong docs in the ToDo file would > > help focus effort when people (like me) have space cycles. > Well, the thing is, I am not good at documentation, especially > when I have other interests, and once I start writing a list of > missing or incomplete docs, my interests _will_ shift to fill in > those gaps and I will end up doing them myself, which means I > would not have a chance to place the list in the TODO file. Then put the following on the TODO list: * Accept patches to the TODO list for missing/incomplete/... documentation ;-) -- 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-10-04 19:52 Subject: Re: [PATCH] Return error when not checking out an entry due to dirtiness. Message-ID: <200510041952.j94Jq1Hs016453@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200510041952.j94Jq1Hs016453%40laptop11.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > Without -f flag, 'git-checkout-index foo.c' issued an error message > when foo.c already existed in the working tree and did not match index. > However it did not return an error from the underlying checkout_entry() > function and resulted in a successful exit(0). > > Signed-off-by: Junio C Hamano > > --- > > * I've made sure that the existing scripts do not use > checkout-index without -f in a way that could be affected by > this change. However, third-party scripts may be affected by > this. Cogito and StGIT should be OK -- they either run > checkout with -f, do not check the error return when it does > not use -f, or runs checkout without -f in an empty working > tree. > > checkout-index.c | 11 ++++++++--- > entry.c | 2 +- > 2 files changed, 9 insertions(+), 4 deletions(-) > > 5a166f6a9d1b7ca2de673139fbfc4112b1b2e308 > diff --git a/checkout-index.c b/checkout-index.c > --- a/checkout-index.c > +++ b/checkout-index.c > @@ -63,15 +63,20 @@ static int checkout_file(const char *nam > > static int checkout_all(void) > { > - int i; > + int i, errs; > > - for (i = 0; i < active_nr ; i++) { > + for (errs = i = 0; i < active_nr ; i++) { This is ugly. Why not just: errs = 0; for (i = 0; i < active_nr ; i++) { (errs is in no way the variable controlled by the for). -- 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-10-27 21:13 Subject: Re: [TENTATIVE PATCH] Complain loudly, dying, when a ref is invalid Message-ID: <200510272113.j9RLD5ho017717@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200510272113.j9RLD5ho017717%40laptop11.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: [...] > Not that the current loop is any better for that purpose. We > silently ignore not just dangling ref and ref not storing > 40-byte hex, but files starting with a period '.', names longer > than 255 bytes, and unreadable ones, all of which we would > probably want to warn about in such a tool. I have yet to come across a filesystem allowing names of more than 255 characters... -- 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-10-31 21:40 Subject: Archaeology [Was: Re: GIT 0.99.9] Message-ID: <200510312141.j9VLemi9003820@inti.inf.utfsm.cl> URL: https://gitlist.dev/e/200510312141.j9VLemi9003820%40inti.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: [...] > One good thing to have would be to add a section to Tutorial. > Currently we cover building a small project from scratch and > have the readers graduate when they learn basic commit swapping, > but we do not talk much about archaeology tools. One of the problems with that is to have a sufficiently rich repository at hand. People who futz around with git could be directed to get the latest git from git for a guided tour. Or create a script like the one in the cogito tutorial to build up someting interesting and then direct people to look it over. -- 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-11-01 23:15 Subject: Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug) Message-ID: <200511012315.jA1NFHbH003838@inti.inf.utfsm.cl> URL: https://gitlist.dev/e/200511012315.jA1NFHbH003838%40inti.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: [...] > I do not know much about how things are done in the RPM world, > but is there a concept of "the upstream" vs "packaging > maintainer" there? IOW, are the majority of RPM binary packages > done by the upstream maintainer? No, they aren't. RPM is set up so you can take the vanilla upstream package and add local patches, special configuration, ... at will downstream. > > I am currently generating i386 RPMs and i386 debs myself but I > am not particularly proud of the current setup. I do not have > an RPM based machine that I can install the result myself to > test (which is what started this thread). Since I am not a > Debian developer (and I do not particularly wish to become one > myself), the debs I generate will not be official anyway. > Personally I'd be happier if I can just lose rpm and deb targets > from the "upstream" Makefile (git-core.spec file and debian/ > subdirectory as well while we are at it), ask "packaging > maintainers" to pull from kernel.org/ tree and do RPMs and Debs > outside. Please keep the git-core.spec file, it is useful to be able to build RPMs directly from the tarball. [...] > One thing we could do without breaking much of the current > arrangement is to have a team of people to help porting for > major packaging formats (RPMs and Debs mostly but I know we have > OpenBSD and Darwin people here too), and ask them to feed me the > updates to rpm/deb/whatever target in the Makefile as needed. > Especially before a major release I could ask them to test > things out and generate binary packages, perhaps taken out of > the tip of the master branch, or even another "for-porters" > branch for this purpose. Good idea. Will build RPMs regularly then. -- 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 ``` ## Junio C Hamano, 2005-11-02 03:36 Subject: Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug) Message-ID: <7vwtjr3elp.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vwtjr3elp.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200511012315.jA1NFHbH003838@inti.inf.utfsm.cl> ``` Horst von Brand writes: > Junio C Hamano wrote: > >> One thing we could do without breaking much of the current >> arrangement is to have a team of people to help porting for >> major packaging formats (RPMs and Debs mostly but I know we have >> OpenBSD and Darwin people here too), and ask them to feed me the >> updates to rpm/deb/whatever target in the Makefile as needed. >> Especially before a major release I could ask them to test >> things out and generate binary packages, perhaps taken out of >> the tip of the master branch, or even another "for-porters" >> branch for this purpose. > > Good idea. Will build RPMs regularly then. Can I take that to mean you are volunteering? ``` ## Horst von Brand, 2005-11-06 03:12 Subject: Re: git binary directory? Message-ID: <200511060312.jA63CUcv010887@inti.inf.utfsm.cl> URL: https://gitlist.dev/e/200511060312.jA63CUcv010887%40inti.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > Linus Torvalds writes: > > Now, I happen to think that 2500+ files in /usr/bin is a bit much (ever > > try to use the horrid gnome executable finder on it when you want to > > convince firefox to use xpdf instead of that broken crap called "evince"? > > Takes absolutely ages and is horrible). > > > > And git made it about 4% worse all on its own. [...] > Since we do not have enough clout to have /usr/bin/git/ and ask > the users to put that in their PATH like X11 does, That is going away. No more /usr/X11R6/{bin,lib,man} junk. > we need to > teach some of our commands that use other git commands to > prepend /usr/lib/git/ (or /usr/libexec/git) AFAIU, /usr/libexec/git (or /usr/libexec/git-) would be better. Including the version would make it possible to have the last stable and a development version coexisting, like gcc does with -V. Or its -B option, which tells it where to find the executables that do the real work. > on their PATH while > they run. Although many of the Porcelainish commands include > git-sh-setup, git-sh-setup itself is a prime candidate to be > kicked out of /usr/bin, which means essentially everything needs > to have that PATH trick. > This also is a bit inconvenient for our in-source-tree tests. Explicitly saying where to find all the stuff with -B would help here. The only downside is that git- won't find them anymore, but I'm sure the bash-completion people will fix that soon ;-) -- 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 ``` ## Kay Sievers, 2005-11-06 05:00 Subject: Re: git binary directory? Message-ID: <20051106050049.GA5910@vrfy.org> URL: https://gitlist.dev/e/20051106050049.GA5910%40vrfy.org In-Reply-To: <200511060312.jA63CUcv010887@inti.inf.utfsm.cl> ``` On Sun, Nov 06, 2005 at 12:12:30AM -0300, Horst von Brand wrote: > Junio C Hamano wrote: > > Linus Torvalds writes: > > > Now, I happen to think that 2500+ files in /usr/bin is a bit much (ever > > > try to use the horrid gnome executable finder on it when you want to > > > convince firefox to use xpdf instead of that broken crap called "evince"? > > > Takes absolutely ages and is horrible). > > > > > > And git made it about 4% worse all on its own. > > [...] > > > Since we do not have enough clout to have /usr/bin/git/ and ask > > the users to put that in their PATH like X11 does, > > That is going away. No more /usr/X11R6/{bin,lib,man} junk. > > > we need to > > teach some of our commands that use other git commands to > > prepend /usr/lib/git/ (or /usr/libexec/git) > > AFAIU, /usr/libexec/git (or /usr/libexec/git-) would be better. Note that "libexec" is not LSB conform - whatever that means, but it should probably not be used for new projects. It states: "Applications may use a single subdirectory under /usr/lib." Kay ``` ## Junio C Hamano, 2005-11-06 05:36 Subject: Re: git binary directory? Message-ID: <7v4q6q5ock.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v4q6q5ock.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20051106050049.GA5910@vrfy.org> ``` Kay Sievers writes: > Note that "libexec" is not LSB conform - whatever that means, but it > should probably not be used for new projects. It states: "Applications > may use a single subdirectory under /usr/lib." I had an impression that there are still UNIXy systems that are not even Linux; do they follow LSB and drop libexec? ``` ## Petr Baudis, 2005-11-06 08:23 Subject: Re: git binary directory? Message-ID: <20051106082338.GN1431@pasky.or.cz> URL: https://gitlist.dev/e/20051106082338.GN1431%40pasky.or.cz In-Reply-To: <7v4q6q5ock.fsf@assigned-by-dhcp.cox.net> ``` Dear diary, on Sun, Nov 06, 2005 at 06:36:59AM CET, I got a letter where Junio C Hamano told me that... > Kay Sievers writes: > > > Note that "libexec" is not LSB conform - whatever that means, but it > > should probably not be used for new projects. It states: "Applications > > may use a single subdirectory under /usr/lib." > > I had an impression that there are still UNIXy systems that are > not even Linux; do they follow LSB and drop libexec? At least BSDs still seem to have libexec, but they are just as likely to have lib, I would say, while on Linux it is going away (not that I would be excited about it). So we could either make this per-system, or default to something that is going to be present everywhere (lib), I think. -- Petr "Pasky libdir=$(prefix)/lib/cogito" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't. ``` ## Petr Baudis, 2005-11-06 08:28 Subject: Re: git binary directory? Message-ID: <20051106082830.GO1431@pasky.or.cz> URL: https://gitlist.dev/e/20051106082830.GO1431%40pasky.or.cz In-Reply-To: <200511060312.jA63CUcv010887@inti.inf.utfsm.cl> ``` Dear diary, on Sun, Nov 06, 2005 at 04:12:30AM CET, I got a letter where Horst von Brand told me that... > Junio C Hamano wrote: > > we need to > > teach some of our commands that use other git commands to > > prepend /usr/lib/git/ (or /usr/libexec/git) > > AFAIU, /usr/libexec/git (or /usr/libexec/git-) would be better. > Including the version would make it possible to have the last stable and a > development version coexisting, like gcc does with -V. Or its -B option, > which tells it where to find the executables that do the real work. In Cogito, when including the lib programs, I'm doing . ${COGITO_LIB}cg-Xlib || exit 1 and then during installation I do: sed -e 's/\$${COGITO_LIB}/"\$${COGITO_LIB:-$(libdir)\/}"/g' Then I can override it during execution by exporting $COGITO_LIB. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't. ``` ## Junio C Hamano, 2005-11-06 08:33 Subject: Re: git binary directory? Message-ID: <7vzmoi2n1f.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vzmoi2n1f.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20051106082338.GN1431@pasky.or.cz> ``` Petr Baudis writes: > At least BSDs still seem to have libexec, but they are just as likely to > have lib, I would say, while on Linux it is going away (not that I would > be excited about it). So we could either make this per-system, or > default to something that is going to be present everywhere (lib), > I think. Yes, that should definitely be done per system. The main Makefile does not have it different from bindir. In fact, the main Makefile still installs everything in $HOME/bin by default. ``` ## Horst von Brand, 2005-12-04 20:16 Subject: Re: [ANNOUNCE] GIT 0.99.9l aka 1.0rc4 Message-ID: <200512042016.jB4KGEIt031938@pincoya.inf.utfsm.cl> URL: https://gitlist.dev/e/200512042016.jB4KGEIt031938%40pincoya.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > GIT 0.99.9l aka 1.0rc4 is found at a new location. What would that new location be? -- 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 ``` ## H. Peter Anvin, 2005-12-04 20:49 Subject: Re: [ANNOUNCE] GIT 0.99.9l aka 1.0rc4 Message-ID: <43935658.8030707@zytor.com> URL: https://gitlist.dev/e/43935658.8030707%40zytor.com In-Reply-To: <200512042016.jB4KGEIt031938@pincoya.inf.utfsm.cl> ``` Horst von Brand wrote: > Junio C Hamano wrote: > >>GIT 0.99.9l aka 1.0rc4 is found at a new location. > > What would that new location be? If you get RPMS, you want to get them from: http://www.kernel.org/pub/software/scm/git/RPMS/$basearch/ I don't believe non-RPMs have changed. -hpa ``` ## Horst von Brand, 2005-12-22 00:27 Subject: Re: [PATCH] off-by-one bugs found by valgrind Message-ID: <200512220027.jBM0RetQ003481@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200512220027.jBM0RetQ003481%40laptop11.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > Pavel Roskin writes: [...] > > quote_c_style_counted() in quote.c uses a dangerous construct, when a > > variable is incremented once and used twice in the same expression. > > Sorry, I do not follow you. Isn't && a sequence point? > > > - for (sp = name; (ch = *sp++) && (sp - name) <= namelen; ) { > > - > > + for (sp = name; sp < name + namelen; sp++) { Yes, it is, so it doesn't fix any bugs; but Pavel's version is definitely more readable. -- 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-01-28 04:55 Subject: Re: Notes on Subproject Support Message-ID: <200601280455.k0S4tx6N003251@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200601280455.k0S4tx6N003251%40laptop11.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > This is still a draft/WIP, but "release early" is a good > discipline, so... One thing that has bugged me from the beginning of this, and which does come out of your example: Why only project/subproject? In your example, you have the kernel (OK(ish)) and "rest of the world", which could itself break up and be tracking e.g. uClibc, and dhcp, and... And perhaps the kernel itself breaks up into (local and vanilla) components. -- 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 ``` ## Junio C Hamano, 2006-01-28 21:43 Subject: Re: Notes on Subproject Support Message-ID: <7vfyn8t4e5.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vfyn8t4e5.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200601280455.k0S4tx6N003251@laptop11.inf.utfsm.cl> ``` Horst von Brand writes: > One thing that has bugged me from the beginning of this, and which does > come out of your example: Why only project/subproject? In your example, you > have the kernel (OK(ish)) and "rest of the world",... Because I presented the example badly, perhaps? There is nothing that prevents you from having more "bind" lines than the example showed, to have one project that works with N subprojects. In fact, the examples in earlier threads used a project with the kernel and gcc subprojects -- I just felt it was so obvious you can do N subprojects instead of just one, so used just one subproject in the latest round of example for the sake of brevity. And there is nothing that prevents you from having "bind" lines in the subproject commit objects, either. The structure the lower level objects support with the "bound commit" extension is not about "project vs subproject". You can express "project that has subprojects each of which has subsubprojects". Now, it is totally a separate issue that anybody sane would want to keep track of such structure, or we would be better off leaving it to build infrastructure specific to each toplevel project, as argued by some earlier. ``` ## Horst von Brand, 2006-06-04 02:02 Subject: Re: [PATCH 0/27] Documentation: Spelling fixes Message-ID: <200606040202.k5422b7X016612@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200606040202.k5422b7X016612%40laptop11.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > Most do not seem to be typoes, depending on where you learned > the language (XYZour vs XYZor; ok, Ok, and OK; ie vs i.e.). I > favour the latter two changes myself, but honestly, I do not > deeply care that much. The rest are real typos. > > It seems that 1/27 did not make here, nor either of the two big > mailing list archives (gmane and marc). Just resent it alone. -- 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-06-06 15:42 Subject: Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email Message-ID: <200606061542.k56Fg9Cm006226@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200606061542.k56Fg9Cm006226%40laptop11.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > Horst von Brand writes: > > >> > # check for a local address: > >> > - return $address if ($address =~ /^([\w\-]+)$/); > >> > + return $address if ($address =~ /^([\w\-.]+)$/); > >> > >> I keep forgetting this, '+' is a valid (and useful) setup, too. > > > > Oops... > >> > >> Actually, I'm retracting my earlier ack on this. This is way too > >> restrictive. I'd rather allow an occasional invalid email address than > >> to reject valid ones. I generally trust git users to know what they're > >> doing when entering email addresses[1]. > >> > >> *, $, ^, +, = are all valid characters in the username portion (not sure > >> about local accounts, though), and I'm sure there are more that I don't > >> know about. > > > > As a general principle, I prefer to check what is legal instead of trying > > to filter out what isn't. > If we start doing addr-spec in RFC2822 (page 17) ourselves, we > should rather be using Email::Valid. A permissive sanity check > to catch obvious mistakes would be more appropriate here than > being RFC police. OK. > I think something like the attached, on top of your patch, would > be appropriate for upcoming 1.4.0. > > -- >8 -- > send-email: be more lenient and just catch obvious mistakes. > > This cleans up the pattern matching subroutine by introducing > two variables to hold regexp to approximately match local-part > and domain in the e-mail address. It is meant to catch obvious > mistakes with a cheap check. > > The patch also moves "scalar" to force Email::Valid->address() > to work in !wantarray environment to extract_valid_address; > earlier it was in the caller of the subroutine, which was way > too error prone. Right. > --- > diff --git a/git-send-email.perl b/git-send-email.perl > index a7a7797..700d0c3 100755 > --- a/git-send-email.perl > +++ b/git-send-email.perl > @@ -312,16 +312,18 @@ our ($message_id, $cc, %mail, $subject, > > sub extract_valid_address { > my $address = shift; > + my $local_part_regexp = '[^<>"\s@]+'; > + my $domain_regexp = '[^.<>"\s@]+\.[^<>"\s@]+'; This forces a '.' in the domain, while vonbrand@localhost is perfectly reasonable. Plus it doesn't disallow adyacent '.'s. What about: my $domain_regexp = '[^.<>"\s@]+(\.[^<>"\s@]+)*'; (but this is probably nitpicking...) -- 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 ``` ## Junio C Hamano, 2006-06-06 15:54 Subject: Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email Message-ID: <7vpshmth3q.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vpshmth3q.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200606061542.k56Fg9Cm006226@laptop11.inf.utfsm.cl> ``` Horst von Brand writes: >> diff --git a/git-send-email.perl b/git-send-email.perl >> index a7a7797..700d0c3 100755 >> --- a/git-send-email.perl >> +++ b/git-send-email.perl >> @@ -312,16 +312,18 @@ our ($message_id, $cc, %mail, $subject, >> >> sub extract_valid_address { >> my $address = shift; >> + my $local_part_regexp = '[^<>"\s@]+'; >> + my $domain_regexp = '[^.<>"\s@]+\.[^<>"\s@]+'; > > This forces a '.' in the domain, while vonbrand@localhost is perfectly > reasonable. Plus it doesn't disallow adyacent '.'s. What about: > > my $domain_regexp = '[^.<>"\s@]+(\.[^<>"\s@]+)*'; > > (but this is probably nitpicking...) I do not have preference either way about allowing an address like tld-administrator@net myself, but Email::Valid->address does not seem to allow it, and I just copied that behaviour for consistency between two alternative implementations. I think you meant to say: > my $domain_regexp = '[^.<>"\s@]+(\.[^.<>"\s@]+)*'; (i.e. exclude dot from the latter character class), but I am inclined to do this instead: my $domain_regexp = '[^.<>"\s@]+(?:\.[^.<>"\s@]+)+'; (i.e. still require at least two levels). ``` ## Horst von Brand, 2006-06-06 16:05 Subject: Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email Message-ID: <200606061605.k56G5gHo006581@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200606061605.k56G5gHo006581%40laptop11.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > Horst von Brand writes: > > >> diff --git a/git-send-email.perl b/git-send-email.perl > >> index a7a7797..700d0c3 100755 > >> --- a/git-send-email.perl > >> +++ b/git-send-email.perl > >> @@ -312,16 +312,18 @@ our ($message_id, $cc, %mail, $subject, > >> > >> sub extract_valid_address { > >> my $address = shift; > >> + my $local_part_regexp = '[^<>"\s@]+'; > >> + my $domain_regexp = '[^.<>"\s@]+\.[^<>"\s@]+'; > > > > This forces a '.' in the domain, while vonbrand@localhost is perfectly > > reasonable. Plus it doesn't disallow adyacent '.'s. What about: > > > > my $domain_regexp = '[^.<>"\s@]+(\.[^<>"\s@]+)*'; > > > > (but this is probably nitpicking...) > > I do not have preference either way about allowing an address > like tld-administrator@net myself, but Email::Valid->address > does not seem to allow it, and I just copied that behaviour for > consistency between two alternative implementations. Reasonable. > I think you meant to say: > > > my $domain_regexp = '[^.<>"\s@]+(\.[^.<>"\s@]+)*'; > > (i.e. exclude dot from the latter character class), Right, my bad. > but I am > inclined to do this instead: > > my $domain_regexp = '[^.<>"\s@]+(?:\.[^.<>"\s@]+)+'; > > (i.e. still require at least two levels). OK, but be careful as this (?:...) is an extended regexp (needs /x on match). I'd just leave it plain (the performance impact shouldn't be noticeable). I don't see any use except for $1, so the extra parenthesis should be safe. -- 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 ``` ## Junio C Hamano, 2006-06-06 16:58 Subject: Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email Message-ID: <7vlksate4w.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vlksate4w.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200606061605.k56G5gHo006581@laptop11.inf.utfsm.cl> ``` Horst von Brand writes: > Junio C Hamano wrote: >> but I am >> inclined to do this instead: >> >> my $domain_regexp = '[^.<>"\s@]+(?:\.[^.<>"\s@]+)+'; >> >> (i.e. still require at least two levels). > > OK, but be careful as this (?:...) is an extended regexp (needs /x on > match). Are you sure about /x? ``` ## Horst von Brand, 2006-06-06 21:24 Subject: Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email Message-ID: <200606062124.k56LOroI007738@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200606062124.k56LOroI007738%40laptop11.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > Horst von Brand writes: > > Junio C Hamano wrote: > >> but I am > >> inclined to do this instead: > >> > >> my $domain_regexp = '[^.<>"\s@]+(?:\.[^.<>"\s@]+)+'; > >> > >> (i.e. still require at least two levels). > > > > OK, but be careful as this (?:...) is an extended regexp (needs /x on > > match). > Are you sure about /x? The manual (perlop(1)) says you need /x to match extended regexps, and (?...) is the marker for such (perlre(1)). But my perl here (5.5.8-6 on Fedora rawhide) doesn't care... -- 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 ``` ## Junio C Hamano, 2006-06-06 21:39 Subject: Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email Message-ID: <7vlksanev9.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vlksanev9.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200606062124.k56LOroI007738@laptop11.inf.utfsm.cl> ``` Horst von Brand writes: >> > OK, but be careful as this (?:...) is an extended regexp (needs /x on >> > match). > >> Are you sure about /x? > > The manual (perlop(1)) says you need /x to match extended regexps, and > (?...) is the marker for such (perlre(1)). I always had the impression that eXtended in the context to talk about /x was about ignoring whitespaces and forcing people to write \s (or perhaps \040) when they mean a whitespace and had nothing to do with (?...) stuff. Let me look up the fine manual. ``` ## Horst von Brand, 2006-06-06 22:48 Subject: Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email Message-ID: <200606062248.k56MmGr6008515@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200606062248.k56MmGr6008515%40laptop11.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > Horst von Brand writes: > >> > OK, but be careful as this (?:...) is an extended regexp (needs /x on > >> > match). > > > >> Are you sure about /x? > > > > The manual (perlop(1)) says you need /x to match extended regexps, and > > (?...) is the marker for such (perlre(1)). > I always had the impression that eXtended in the context to talk > about /x was about ignoring whitespaces and forcing people to > write \s (or perhaps \040) when they mean a whitespace and had > nothing to do with (?...) stuff. Let me look up the fine > manual. You might be right... and it even sounds sensible; but both (?...) stuff and the ignoring of space is described as extended here. Note that \s is a space character (' ', '\t', ...), which is not the same as \040 (and that one assumes ASCII...). -- 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 H. von Brand, 2006-10-10 14:25 Subject: Re: [PATCH] gitweb: Show project README if available Message-ID: <200610101425.k9AEPLfD004981@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200610101425.k9AEPLfD004981%40laptop13.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: [...] > Also we might want to consider using this file (or description) > for git-daemon "motd" action if we were to enhance it. I > remember that early days of git-daemon some people wanted to > have motd. I consider motd to be a system-wide property, not of a particular project/repository... -- 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 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ``` ## Horst H. von Brand, 2006-10-10 20:54 Subject: Junio's wishes [Was: Re: Approxidate licensing] Message-ID: <200610102054.k9AKsQ2a004095@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200610102054.k9AKsQ2a004095%40laptop13.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > My wishes about the code I write for this project is very > simple: > > If you improve my code that had helped you to make it help > you even better, I would like to have that change back, so > that your change would help me the same way as it helped > you. > > The readers may have noticed that I have slight problem with > GPLv2; in my wish it does not matter if you distribute the > result or not. And I am selfish. It is not about helping my > users, but about helping me ;-). There is a small practical problem with that: How would you find out I'm using a modified version of your code internally? Also, the "distribution" part of GPLv2 is a useful filter: Only such modifications that are worthwhile to distribute get back, not each and every corner I paint myself into while playing around. All in all, a nice balance, IMVHO. -- 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 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ``` ## Linus Torvalds, 2006-10-10 22:12 Subject: Re: Junio's wishes [Was: Re: Approxidate licensing] Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0610101509460.3952%40g5.osdl.org In-Reply-To: <200610102054.k9AKsQ2a004095@laptop13.inf.utfsm.cl> ``` On Tue, 10 Oct 2006, Horst H. von Brand wrote: > > There is a small practical problem with that: How would you find out I'm > using a modified version of your code internally? Also, the "distribution" > part of GPLv2 is a useful filter: Only such modifications that are > worthwhile to distribute get back, not each and every corner I paint myself > into while playing around. Hey, I obviously agree that the GPLv2 is a good license, but at the same time, I think too many people tend to think _just_ about legal issues. Sometimes the wishes of an author should matter, regardless of whether there is any law that forces you to do so. So I personally think a license that says: "if you improve this, give out the improvements regardless of whether you distribute things further or not" is a nice sentiment, and should be honored, regardless of whether you can legally enforce any such private tinkering or not. Linus ``` ## Horst H. von Brand, 2006-10-13 18:05 Subject: Re: [PATCH 2/2] git-repack: -b to pass --delta-base-offset Message-ID: <200610131805.k9DI5QDH016016@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200610131805.k9DI5QDH016016%40laptop13.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > This new option makes the resulting pack express the delta base > with more compact "offset" format. > > Signed-off-by: Junio C Hamano [...] > @@ -35,6 +35,12 @@ OPTIONS > about people fetching via dumb protocols from it. Use > with '-d'. > > +-b:: > + Pass the `--delta-base-offset` to `git pack-objects`; > + see gitlink:git-pack-objects[1]. Do not use this option > + if you want the repository to be accessible by older > + versions of git. > + Need to tell which version is the cutoff (say before 1.4.3 won't work). -- 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 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ``` ## Nicolas Pitre, 2006-10-13 18:29 Subject: Re: [PATCH 2/2] git-repack: -b to pass --delta-base-offset Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0610131423200.2435%40xanadu.home In-Reply-To: <200610131805.k9DI5QDH016016@laptop13.inf.utfsm.cl> ``` On Fri, 13 Oct 2006, Horst H. von Brand wrote: > Junio C Hamano wrote: > > This new option makes the resulting pack express the delta base > > with more compact "offset" format. > > > > Signed-off-by: Junio C Hamano > > [...] > > > @@ -35,6 +35,12 @@ OPTIONS > > about people fetching via dumb protocols from it. Use > > with '-d'. > > > > +-b:: > > + Pass the `--delta-base-offset` to `git pack-objects`; > > + see gitlink:git-pack-objects[1]. Do not use this option > > + if you want the repository to be accessible by older > > + versions of git. > > + > > Need to tell which version is the cutoff (say before 1.4.3 won't work). Before and including 1.4.3 actually. Oh and the description should be augmented with "... if you want the repository to be accessible by older versions of git when _not_ using the native GIT protocol." as the native protocol is able to select between either format on the fly regardless of the on-disk pack format. Nicolas ``` ## Horst H. von Brand, 2006-10-15 14:52 Subject: Re: Recent and near future backward incompatibilities Message-ID: <200610151452.k9FEqcIN003546@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200610151452.k9FEqcIN003546%40laptop13.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > It was brought to my attention that the public git.git > repository cannot be cloned with older versions of git. [...] There seem to be a bunch of incompatible changes comming up... how about scheduling them for a 2.0 version, soon(ish)? -- 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 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ``` ## Horst H. von Brand, 2006-10-20 12:31 Subject: Re: [ANNOUNCE] GIT 1.4.3 Message-ID: <200610201231.k9KCVQjf008998@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200610201231.k9KCVQjf008998%40laptop13.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > The latest feature release GIT 1.4.3 is available at the usual > places: [...] > rename builtin-cat-file.c => builtin-cat-file.c (0%) Huh?! -- 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 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ``` ## Horst H. von Brand, 2006-10-26 01:48 Subject: Re: Combined diff format documentation Message-ID: <200610260148.k9Q1mr99007511@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200610260148.k9Q1mr99007511%40laptop13.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > Jakub Narebski writes: [...] > > 5. Hunk header is also modified: in ordinary diff we have > > ... > > It might be not obvoious that we have (number of parents + 1) '@' > > characters in chunk header for combined dif format. > Correct. This was done to prevent people from accidentally > feeding it to "patch -p1". In other words, we wanted to make it > so obvious that it is _not_ a patch. It isn't, really... perhaps it should be made /more/ obvious (not use @ but e.g. &, ...)? -- 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 ``` ## Junio C Hamano, 2006-10-26 03:04 Subject: Re: Combined diff format documentation Message-ID: <7vmz7jkcap.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vmz7jkcap.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200610260148.k9Q1mr99007511@laptop13.inf.utfsm.cl> ``` "Horst H. von Brand" writes: >> Correct. This was done to prevent people from accidentally >> feeding it to "patch -p1". In other words, we wanted to make it >> so obvious that it is _not_ a patch. > > It isn't, really... perhaps it should be made /more/ obvious (not use @ but > e.g. &, ...)? Eh, sorry, what I meant was "obvious to the tool", so "patch" would take notice. ``` ## Horst H. von Brand, 2006-10-29 19:03 Subject: Re: Generating docu in 1.4.3.3.g01929 Message-ID: <200610291903.k9TJ3am7017976@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200610291903.k9TJ3am7017976%40laptop13.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: [...] > and here is what I have: > > asciidoc-7.0.2-3.fc6 > xmlto-0.0.18-13.1 > python-2.4.3-18.fc6 > docbook-dtds-1.0-30.1 > package docbook-xsl is not installed > flex-2.5.4a-41.fc6 > libxslt-1.1.17-1.1 > passivetex-1.25-5.1.1 > util-linux-2.13-0.44.fc6 > w3m-0.5.1-14.1 I've got: asciidoc-7.0.2-3.fc6 xmlto-0.0.18-13.1 python-2.4.4-1.fc7 docbook-dtds-1.0-30.1 package docbook-xsl is not installed flex-2.5.4a-41.fc6 libxslt-1.1.18-1 passivetex-1.25-5.1.1 util-linux-2.13-0.44.fc6 w3m-0.5.1-14.1 > "rpm -q --whatprovides docbook-xsl" says: > > docbook-style-xsl-1.69.1-5.1 docbook-style-xsl-1.69.1-5.1 Differences are (mine (Junio's)): python-2.4.4-1.fc7 (python-2.4.3-18.fc6) libxslt-1.1.18-1 (libxslt-1.1.17-1.1) libxslt requires libxml2: libxml2-2.6.27-1 (Fedora 6 has libxml2-2.6.26-2.1.1) Getting the Fedora 6 libxslt (Junio's) and redoing git gives no errors. Judging from the libxslt changelog they tightened up the processing, so I'd guess asciidoc is generating fishy XML or xmlto is broken. I've no clue here... somebody knowledgeable who can take a closer look or otherwise lend me a hand? Thanks! PS: I get similar errors with tig... -- 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 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ``` ## Horst H. von Brand, 2006-11-06 16:46 Subject: Re: [PATCH] git-pickaxe -C -C -C Message-ID: <200611061646.kA6GkHgi009592@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200611061646.kA6GkHgi009592%40laptop13.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > Three -C options makes the command to look for copied lines from _any_ > existing file in the parent commit, not just changed files. IMHO, this is horrible UI. -C is one thing -C -C is another -C -C -C is still another? -- 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 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ``` ## Junio C Hamano, 2006-11-06 17:25 Subject: Re: [PATCH] git-pickaxe -C -C -C Message-ID: <7v3b8webdb.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v3b8webdb.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200611061646.kA6GkHgi009592@laptop13.inf.utfsm.cl> ``` "Horst H. von Brand" writes: > Junio C Hamano wrote: >> Three -C options makes the command to look for copied lines from _any_ >> existing file in the parent commit, not just changed files. > > IMHO, this is horrible UI. > > -C is one thing > -C -C is another > -C -C -C is still another? I think of it as "-v" vs "-v -v" vs "-v -v -v" some programs use to give you increasing levels of verbosity. Triple-C version is a kind of joke and not to be integrated (although it seems to work as advertised, it is inpractically slow), so it really is between -C vs -C -C, but certainly I am open to better ways of specifying the current -C/-C -C options. ``` ## Horst H. von Brand, 2006-11-15 21:13 Subject: Re: Sometimes "Failed to find remote refs" means "try git-fetch --no-tags" Message-ID: <200611152113.kAFLDgZO005651@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200611152113.kAFLDgZO005651%40laptop13.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: [...] > However "fetch --no-tags" from http upstream is a band-aid to > hide that the upstream repository has stale info/refs, and I do > not think we would want to encourage the band-aid. Rather, the > message should say "yell loudly at the repository owner" ;-). I'm seeing this gem here: [vonbrand@laptop13 git]$ git pull fatal: read error (Connection reset by peer) Fetch failure: git://git.kernel.org/pub/scm/git/git.git fatal: read error (Connection reset by peer) Failed to find remote refs No changes. Who shall I yell at? ;-) Seriously, this is broken. I get 4 different error messages, plus a (reassuring?) "No changes". Yes, I know this is what I'll see if the machine is overloaded. -- 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 ``` ## Horst H. von Brand, 2006-11-20 17:00 Subject: Re: [PATCH] git-merge: make it usable as the first class UI Message-ID: <200611201700.kAKH0msM012002@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200611201700.kAKH0msM012002%40laptop13.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: [...] > -- >8 -- > [PATCH] git-merge: make it usable as the first class UI > > This teaches the oft-requested syntax > > git merge $commit > > to implement merging the named commit to the current branch. > This hopefully would make "git merge" usable as the first class > UI instead of being a mere backend for "git pull". > > Most notably, $commit above can be any committish, so you can > say for example: > > git merge js/shortlog~2 > > to merge early part of a topic branch without merging the rest > of it. "Early part", i.e., branch js/shortlog up to js/shortlog~2 or just that one commit? > A custom merge message can be given with the new --message= > parameter. The message is prepended in front of the usual > "Merge ..." message autogenerated with fmt-merge-message. Why not -m too (consistency!)? -- 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 ``` ## Junio C Hamano, 2006-11-20 19:52 Subject: Re: [PATCH] git-merge: make it usable as the first class UI Message-ID: <7vr6vx28w1.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vr6vx28w1.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200611201700.kAKH0msM012002@laptop13.inf.utfsm.cl> ``` "Horst H. von Brand" writes: >> Most notably, $commit above can be any committish, so you can >> say for example: >> >> git merge js/shortlog~2 >> >> to merge early part of a topic branch without merging the rest >> of it. > > "Early part", i.e., branch js/shortlog up to js/shortlog~2 or just that one > commit? "Early part up to that commit" -- this is not a cherry pick. >> A custom merge message can be given with the new --message= >> parameter. The message is prepended in front of the usual >> "Merge ..." message autogenerated with fmt-merge-message. > > Why not -m too (consistency!)? That form also is accepted, I think. ``` ## Horst H. von Brand, 2006-11-26 23:05 Subject: Re: [PATCH] Make logAllRefUpdates true by default Message-ID: <200611262305.kAQN5FoO016231@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200611262305.kAQN5FoO016231%40laptop13.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: [...] > Having thought about all the above, I think the event to create > distribution/synchronization point repositories are rare enough > and the simplest and cleanest way might be to make it default > and add a --without-reflog option to the command, and forget > about the guessing. Looks sanest. I hate stuff that tries to outguess me by being "smart" (part of the reason I love Unixy systems). -- 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 ``` ## Horst H. von Brand, 2006-12-14 23:52 Subject: Re: What's in git.git (stable) Message-ID: <200612142352.kBENq8Ie002603@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200612142352.kBENq8Ie002603%40laptop13.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: [...] > In general the principle ought to be not to say anything if the > command does exactly what it was told to do successfully, unless > the operation is expected to take longer than other normal > commands in the git suite, or something that is rarely used. Nodz. Just hoary Unix tradition. > Perhaps under "[user] expert" control. Nope. You'd be surprised what kind of people consider themselves "experts"... I'd prefer adding -v/--verbose flags to all commands (if nothing else, for symmetry's sake), have a '[default] --verbose' controlling this across the board (perhaps also '[default "command"] --verbose'), with '[default]' setting default switches. -- 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 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ``` ## Jakub Narebski, 2006-12-15 10:53 Subject: Re: What's in git.git (stable) Message-ID: URL: https://gitlist.dev/e/eltumg%24n03%241%40sea.gmane.org In-Reply-To: <200612142352.kBENq8Ie002603@laptop13.inf.utfsm.cl> ``` Horst H. von Brand wrote: >> Perhaps under "[user] expert" control. > > Nope. You'd be surprised what kind of people consider themselves > "experts"... I'd prefer adding -v/--verbose flags to all commands (if > nothing else, for symmetry's sake), have a '[default] --verbose' controlling > this across the board (perhaps also '[default "command"] --verbose'), with > '[default]' setting default switches. Nice idea... but configuration variables have to have name. So it would be $ git repo-config defaults.command --verbose resulting in [defaults] command = --verbose -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ``` ## Horst H. von Brand, 2006-12-27 12:06 Subject: Re: [RFH] An early draft of v1.5.0 release notes Message-ID: <200612271206.kBRC6ke2004207@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200612271206.kBRC6ke2004207%40laptop13.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > This is still rough, but I think we have a pretty good idea what > will and what won't be in v1.5.0 by now, and end-of-year is a > good slow time to summarize what we have done. Could somebody please summarize how to "upgrade" a repository to the new layout? This has got my head spinning... and I'm /not/ cloning the various repos I've got here just to take advantage of the changes. Thanks! -- 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 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ``` ## Horst H. von Brand, 2006-12-28 01:35 Subject: Re: http git and curl 7.16.0 Message-ID: <200612280135.kBS1ZL5v004756@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200612280135.kBS1ZL5v004756%40laptop13.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > "Horst H. von Brand" writes: > > Sven Verdoolaege wrote: > >> On Sat, Nov 18, 2006 at 08:07:08AM +0400, George Sherwood wrote: > >> > I seem to be having a problem doing an http checkout with git built > >> > with curl 7.16.0 enabled. If I build against curl 7.16.0 and try a > >> > clone, I get: > > ... > >> > git clone http://dmlb2000.homelinux.org/~dmlb2000/git-repos/local/castfs.git > >> > error: Unable to start request error: Could not interpret heads/master > >> > as something to pull > >> > > >> > If I rebuild git against curl 7.15.5 then I get: > >> [..] > >> > and the checkout finishes. > >> > > >> > Has any one else seen this? > > > >> FWIW, I've seen the same with curl 7.16.0 on a Solaris 9 machine. > >> It worked fine with curl 7.15.0. > > > > It works fine for me on Aurora Corona (sparc) with curl-7.15.5-1.al3, while > > it fails as above on Fedora rawhide (i386) with curl-7.16.0-4.fc7. > > > > Furthermore, with new curl pulling from HTTP repos when there are updates > > gives double free errors and a crash. > > Hmmm. Could somebody please run http-fetch under gdb and see > where it breaks? The exact command line you need to use would > be obtainable by running "sh -x git-clone" once. It crashes the kernel for me here :-( I tried to chop down a tig repo a few commits from the top for checking out the crash I'm seeing (only when pulling from a remote repo by HTTP, and it is not up to date here) by doing: cp -r tig tig.tst cd tig.tst git reset --hard HEAD~3 git prune But now git-pull /doesn't/ fetch anything, so I see no crash. What am I doing wrong here? -- 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 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ``` ## Shawn Pearce, 2006-12-28 01:42 Subject: Re: http git and curl 7.16.0 Message-ID: <20061228014225.GB16612@spearce.org> URL: https://gitlist.dev/e/20061228014225.GB16612%40spearce.org In-Reply-To: <200612280135.kBS1ZL5v004756@laptop13.inf.utfsm.cl> ``` "Horst H. von Brand" wrote: > I tried to chop down a tig repo a few commits from the top for checking out > the crash I'm seeing (only when pulling from a remote repo by HTTP, and it > is not up to date here) by doing: > > cp -r tig tig.tst > cd tig.tst > git reset --hard HEAD~3 > git prune > > But now git-pull /doesn't/ fetch anything, so I see no crash. What am I > doing wrong here? Another ref points at the same commit as what ORIG_HEAD points at, so there wasn't anything to fetch as you already had that commit. Its probably a tag, a ref under refs/remotes, or another branch... -- Shawn. ``` ## Junio C Hamano, 2006-12-28 02:58 Subject: Re: [RFH] An early draft of v1.5.0 release notes Message-ID: <7v64bw3ewk.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v64bw3ewk.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200612271206.kBRC6ke2004207@laptop13.inf.utfsm.cl> ``` "Horst H. von Brand" writes: > Junio C Hamano wrote: >> This is still rough, but I think we have a pretty good idea what >> will and what won't be in v1.5.0 by now, and end-of-year is a >> good slow time to summarize what we have done. > > Could somebody please summarize how to "upgrade" a repository to the new > layout? This has got my head spinning... and I'm /not/ cloning the > various repos I've got here just to take advantage of the changes. The old layout was to map remote branch $B to local tracking branch .git/refs/heads/$B, unless $B == 'master' in which case it was mapped to .git/refs/heads/origin (and I think we discarded 'origin' at remote). Each remote branch $B is tracked with .git/refs/remote/origin/$B in the new layout. And you will get something like this in your .git/config: [remote "origin"] url = git://git.kernel.org/pub/scm/.../torvalds/linux-2.6.git/ fetch = refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master The first section defines what the token 'origin' means when you say "git pull origin" or "git fetch origin". remote.origin.url defines the URL to fetch/pull from, and remote.origin.fetch supplies the refspecs you omitted from the command line (fetch everything from refs/heads/ hierarchy of remote and store them in my refs/remotes/origin/ hierarchy). The second section defines what happens when you say "git pull" or "git fetch" while on your "master" branch. It tells that you meant to say "git pull origin" or "git fetch origin" when you omitted the URL argument from the command line. And because you are also omitting the refspecs, remote.origin.fetch kicks in and slurps all the branches from the remote side and stores them in your refs/remotes/origin/ hierarchy. When the command was "git pull", it also says the merge that follows the fetch is to merge the 'master' branch at the remote side (which happens to be copied to your remotes/origin/master only because you have remote.origin.fetch) into your current branch (which is "master", because this section is about what happens while you are on your "master" branch). So for an existing repository that does not use the separate remotes layout, you can easily convert that by hand if you wanted to by: - Move tracking branches from refs/heads/* to refs/remotes/origin/*, - create the config section like the above in .git/config, and - remove .git/remotes/origin when you are done. ``` ## Jakub Narebski, 2006-12-28 11:50 Subject: Re: [RFH] An early draft of v1.5.0 release notes Message-ID: URL: https://gitlist.dev/e/en0asv%24bjm%241%40sea.gmane.org In-Reply-To: <7v64bw3ewk.fsf@assigned-by-dhcp.cox.net> ``` [Cc: git@vger.kernel.org, Junio C Hamano , "Horst H. von Brand" ] Junio C Hamano wrote: > "Horst H. von Brand" writes: > >> Junio C Hamano wrote: >>> This is still rough, but I think we have a pretty good idea what >>> will and what won't be in v1.5.0 by now, and end-of-year is a >>> good slow time to summarize what we have done. >> >> Could somebody please summarize how to "upgrade" a repository to the new >> layout? This has got my head spinning... and I'm /not/ cloning the >> various repos I've got here just to take advantage of the changes. > > The old layout was to map remote branch $B to local tracking > branch .git/refs/heads/$B, unless $B == 'master' in which case > it was mapped to .git/refs/heads/origin (and I think we > discarded 'origin' at remote). How to discard 'origin' in the new wildcard / globbing remote config? IIRC there was proposal to use '-' or '!' to exclude branch from fetching, but no code... [...] > - create the config section like the above in .git/config, and You can use contrib/remotes2config.sh script... > - remove .git/remotes/origin when you are done. ...which saves remotes/ under remotes.old/ -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ``` ## Horst H. von Brand, 2006-12-29 12:37 Subject: Re: [PATCH/RFT] Work around http-fetch built with cURL 7.16.0 Message-ID: <200612291237.kBTCbq0P010010@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200612291237.kBTCbq0P010010%40laptop13.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > It appears that curl_easy_duphandle() from libcurl 7.16.0 > returns a curl session handle which fails GOOD_MULTI_HANDLE() > check in curl_multi_add_handle(). This causes fetch_ref() to > fail because start_active_slot() cannot start the request. > > For now, check for 7.16.0 to work this issue around. > > Signed-off-by: Junio C Hamano > --- > > * I think people who were having trouble with cURL 7.16.0 want > to have the issue resolved before v1.5.0-rc1. Please test > and report, or else ;-). Checked it out. Now clone and pull both work here. Thanks! -- 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 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ``` ## Horst H. von Brand, 2007-01-08 13:30 Subject: Re: [ANNOUNCE] GIT 1.4.4.4 Message-ID: <200701081330.l08DUd7H023896@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200701081330.l08DUd7H023896%40laptop13.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > The latest maintenance release GIT 1.4.4.4 is available at the > usual places: > > http://www.kernel.org/pub/software/scm/git/ > > git-1.4.4.4.tar.{gz,bz2} (tarball) > git-htmldocs-1.4.4.4.tar.{gz,bz2} (preformatted docs) > git-manpages-1.4.4.4.tar.{gz,bz2} (preformatted docs) > RPMS/$arch/git-*-1.4.4.4-1.$arch.rpm (RPM) > > This is to push out a handful bugfixes since 1.4.4.3. > > On the 'master' development front, the stabilization for v1.5.0 > will start soonish. I get git version 1.4.4.4.g9a5e4 (used to be 1.5.0.rc0.gXXXX) on the msater branch now? -- 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 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ``` ## Horst H. von Brand, 2007-01-12 20:15 Subject: Re: 1.5.0.rc1.g4494: Can't use a bare GIT_DIR to add Message-ID: <200701122015.l0CKFB8j022355@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200701122015.l0CKFB8j022355%40laptop13.inf.utfsm.cl In-Reply-To: ``` Junio C Hamano wrote: > "Horst H. von Brand" writes: > > > I tried this: > > > > mkdir xyz > > cd xyz > > git --git-dir=../xyz.git > > # Initialized empty Git repository in ../xyz.git/ > > echo Junk > file-a > > git --git-dir=../xyz.git add . > > # fatal: add cannot be used in a bare git directory > > > > I expected that "GIT_DIR is bare, over there, stuff is here" works the same > > as "GIT_DIR is .git, right here among stuff". > Sheesh, why didn't you speak out earlier while the discussion > was on (I am not serious, git mailing list is still moving too > fast for people to be always on top of)? Because I just noticed :-( > Now, seriously. [...] > You said "I tried". Is this something you do in real life? There was a discussion going on about importing several tarballs (one version after the other) into git. If you want to just export the result, not futz around in it, it leads naturally to doing something like: mkdir /base/test.git cd /base/test.git; git --bare init for v in 0.8.0.99 0.99a 0.99b 1.0 1.1 1.2.0 1.2.1 1.2.2; do cd /work tar zxf test-$v.tar.gz cd test-$v git --git-dir=/base/test.git add . git --git-dir=/base/test.git commit -a "Version $v" git --git-dir=/base/test.git tag v$v cd /work rm -rf test-$v done > This _is_ a regression, as we are checking something we did not > check before and refusing to work in cases where we did. But I > am not sure if reverting to lift the safety (for that matter, > introducing the third "depends" alternative) is better than the > latest behaviour. It grates me somewhat that there isn't a clean way of saying "My .git stuff is over there". No big deal, really. And it is not a "depends", AFAICS: GIT_DIR says where to stash stuff, users had better know what they are doing in that case... so perhaps allow anything if GIT_DIR is set? > For one thing, you could (sometime before the "git add ." and do > this only once) do: > > $ ln -s ../xyz.git .git > > and that would make all the future git operation work without > the --git-dir parameter (or GIT_DIR environment) in xyz > directory. An added benefit is that it would even allow git > command to work from a subdirectory of xyz (specifying GIT_DIR > or --git-dir means you are bypassing the discovery for the top > of the working tree, so you have to always be at the top). For this particular case this is no real help. But no big deal to me. Still trying to wrap my brain aound git, that's all. -- 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 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ``` ## Junio C Hamano, 2007-01-12 21:33 Subject: Re: 1.5.0.rc1.g4494: Can't use a bare GIT_DIR to add Message-ID: <7vps9kq6aa.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vps9kq6aa.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200701122015.l0CKFB8j022355@laptop13.inf.utfsm.cl> ``` "Horst H. von Brand" writes: > Junio C Hamano wrote: > ... >> This _is_ a regression, as we are checking something we did not >> check before and refusing to work in cases where we did. But I >> am not sure if reverting to lift the safety (for that matter, >> introducing the third "depends" alternative) is better than the >> latest behaviour. > > It grates me somewhat that there isn't a clean way of saying "My .git stuff > is over there". No big deal, really. > > And it is not a "depends", AFAICS: GIT_DIR says where to stash stuff, users > had better know what they are doing in that case... so perhaps allow > anything if GIT_DIR is set? One problem I have with that is that doing so would make it harder to prevent pushing into the current branch of a repository with working tree from happening later. In the "sequence of tarballs" example, I wonder why you cannot do something like: git init-db for tarball do tar xf $tarball # if it extracts in a wrong directory, move them # up first ... git add . git commit -a git rm -r . done ```