Re: Tool renames? was Re: First stab at glossary

[Horst von Brand]

Junio C Hamano <[EMAIL PROTECTED]> wrote:
> Horst von Brand <[EMAIL PROTECTED]> writes:
> >> 3. Non-binaries are called '*-scripts'.
> >> 
> >>In earlier discussions some people seem to like the
> >>distinction between *-script and others; I did not
> >>particularly like it, but I am 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, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Tool renames? was Re: First stab at glossary

[Horst von Brand]

Junio C Hamano <[EMAIL PROTECTED]> wrote:
> I said:
> 
> > I'll draw up a strawman tonight unless somebody else
> > does it first.

[...]

> 3. Non-binaries are called '*-scripts'.
> 
>In earlier discussions some people seem to like the
>distinction between *-script and others; I did not
>particularly like it, but I am throwing this in for
>discussion.

I for one think this makes the command name dependent on a non-essential
implementation detail, so -script should go.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Tool renames? was Re: First stab at glossary

[Horst von Brand]

Junio C Hamano <[EMAIL PROTECTED]> wrote:
> Tim Ottinger <[EMAIL PROTECTED]> writes:
> > git-update-cache for instance?
> > I am not sure which 'cache' commands need to be 'index' now.

> Logically you are right, but I suspect that may not fly well in
> practice.  Too many of us have already got our fingers wired to
> type cache, and the glossary is there to describe both cache 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, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: baffled again

[Horst von Brand]

Tony Luck <[EMAIL PROTECTED]> wrote:
> >  * Even if it does always choose the nicer choice of the two,
> >Tony was lucky (no pun intended).  Rather, we were lucky that
> >Tony was observant.  A careless merger may well have easily
> >missed this mismerge (from the human point of view).

> Actually I can't take credit here. This was a case of the "many-eyes" of
> open source working at its finest ... someone e-mailed me and told me
> that I should have backed out the old patch before applying the new one.
> While typing the e-mail to say that I already had in the release branch,
> I found the problem that it had been "lost" in the merge into the test
> branch.

> But this is a good reminder that merging is not a precise science, and
> there is more than one plausible merge in many situations ... and while
> GIT will pick the one that you want far more often than not, there is
> the possibility that it will surprise you.  Maybe there should be a note
> to this effect in the tutorial.  Git is not magic, nor is it imbued with
> DWIM technology.

I have to disagree. If in some corner case it can do the wrong thing, no
amount of "I told you so in the docu!" will save the day. People /will/
overlook it, or be bitten when they have all but forgotten about it.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Git 1.0 Synopis (Draft v4)

[Horst von Brand]

Junio C Hamano <[EMAIL PROTECTED]> 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, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards

[Horst von Brand]

Junio C Hamano <[EMAIL PROTECTED]> wrote:
> Johannes Schindelin <[EMAIL PROTECTED]> 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, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: GIT 0.99.4 (preview)

[Horst von Brand]

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 <[EMAIL PROTECTED]>
+Vendor:Junio C Hamano <[EMAIL PROTECTED]>
 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 <[EMAIL PROTECTED]>
+- 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 <[EMAIL PROTECTED]>
 - Add the man pages, and the --without docs build option
+
 * Wed Jul 7 2005 Chris Wright <[EMAIL PROTECTED]>
 - 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, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Git 1.0 Synopis (Draft v3

[Horst von Brand]

[Yes, I know it is considered odd when you speak to yourself in public...]

Horst von Brand <[EMAIL PROTECTED]> wrote:
> Ryan Anderson <[EMAIL PROTECTED]> wrote:
> > Source Code Management with Git

> More bugging...

And then some.

> > To get the 'Porcelain' tools mentioned above:
> > SCM Interface layers:
> > cogito - http://www.kernel.org/pub/software/scm/cogito/
> > StGIT - http://www.procode.org/stgit/
> 
> At least cogito includes a (slightly old) version of git. Dunno about
> StGIT. And git and cogito have a gitk inside too. This should be mentioned,
> i.e., look at the package(s) you are interested and see what else they
> carry or require and keep in mind that (for now?) getting git as part of
> one package is /not/ guaranteed to be compatible with another or standard
> git.

Also note that StGIT is /not/ a SCM (as cogito is), it is a tool to shuffle
patches that uses git as a backend/target.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Git 1.0 Synopis (Draft v3

[Horst von Brand]

Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 29, 2005 at 04:29:41AM -0400, Ryan Anderson wrote:
> > Source Code Management with Git
> 

> The article should include a HOWTO part alos.

I'd vote for a separate file.

>   So people can see how to
> edit a file, pull from a remote repository etc.

Exactly.

> Since you have introduced core and porcelains it would be most logical
> to use one of the porcelains in these examples, maybe accompanied by the
> raw git commands being executed.

Better leave the Porcelain-HOWTO to individual Porcelain. Perhaps the
Plumbing-HOWTO should include a section on interfacing to Porcelain (or it
should be yet another 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, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Git 1.0 Synopis (Draft v3

[Horst von Brand]

Ryan Anderson <[EMAIL PROTECTED]> wrote:
> Source Code Management with Git

More bugging...

- Either stay with your idea of "Git is the idea, git the implementation"
  (iff blessed by the Git Powers That Be) and be consistent about it, or
  just use "git" throughout.

- Attribute the meaning appropiately, say by:

In Linus' own words as the inventor of git:

> "git" can mean anything, depending on your mood.
> 
>  - random three-letter combination that is pronounceable, and not
>actually used by any common UNIX command.  The fact that it is a
>mispronunciation of "get" may or may not be relevant.
>  - stupid. contemptible and despicable. simple. Take your pick from the
>dictionary of slang.
>  - "global information tracker": you're in a good mood, and it actually
>works for you. Angels sing, and a light suddenly fills the room. 
>  - "goddamn idiotic truckload of sh*t": when it breaks
[...]

> To get a copy of Git:
>   Daily snapshots are available at:
>   http://www.codemonkey.org.uk/projects/git-snapshots/git/
>   (Thanks to Dave Jones)
> 
>   Source tarballs and RPMs at:
>   http://www.kernel.org/pub/software/scm/git/
> 
>   Deb packages at:
>   
> 
>   Or via Git itself:
>   git clone http://www.kernel.org/pub/scm/git/git.git/ 
>   git clone rsync://rsync.kernel.org/pub/scm/git/git.git/  directory>
> 
>   (rsync is generally faster for an initial clone, you can switch later
>   by editing .git/branches/origin and changing the url)
> 
> To get the 'Porcelain' tools mentioned above:
>   SCM Interface layers:
>   cogito - http://www.kernel.org/pub/software/scm/cogito/
>   StGIT - http://www.procode.org/stgit/

At least cogito includes a (slightly old) version of git. Dunno about
StGIT. And git and cogito have a gitk inside too. This should be mentioned,
i.e., look at the package(s) you are interested and see what else they
carry or require and keep in mind that (for now?) getting git as part of
one package is /not/ guaranteed to be compatible with another or standard
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, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Status of git.git repository

[Horst von Brand]

Junio C Hamano <[EMAIL PROTECTED]> 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, ChileFax:  +56 32 797513

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Trial git RPM's..

[Horst von Brand]

Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Mon, 11 Jul 2005, Eric W. Biederman wrote:
> > A couple of pieces.  The dist target has assumes git-tar-tree is in the
> > path.  Making it so you have to have git installed to build the rpm.

> Yes. Maybe we could relax that requirement by using "./git-tar-tree" or 
> something? That still requires that you have _built_ git to do the rpm, 
> but at least you won't have had to install it.

I don't see a problem here. Sure, you need git to build git, so place it in
Build-requires: Need to install the binary to build the next from source,
that's all. Just like gcc ;-)

[...]

> > The man pages are not built. The build dependencies do not call out
> > the tools necessary to build the man pages.

> Most people don't have asciidoc, and I'm not sure we want to require it. 
> Maybe we could have a separate "make man-rpm" target for that?

Would have to be a requirement for building anyway. There is a (not really
nice) SRPM at . Will see
to clean it up.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: BUG: cg-clone accepts '_' in git_ssh: URI's, but cg-push does not.

[Horst von Brand]

John Ellson <[EMAIL PROTECTED]> wrote:
> BUG: cg-clone accepts '_' in git+ssh: URI's, but cg-push does not.

Right. '_' is illegal in domain names...
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SHA1 hash safety

[Horst von Brand]

[EMAIL PROTECTED] said:

[...]

> Linus has already weighed in that he doesn't give a crap.  All the
> crypto-babble about collision whitepapers is uninteresting without a
> repo that has real collisions.  git is far too cool as is - prove I
> should be concerned.

Just copy over a file (might be the first step in splitting it, or a
header file that is duplicated for convenience, ...)
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html