My Itchlist

My Itchlist

[Junio C Hamano]

Here is a short list of itches I would like to get scratched
before 1.0.  I may be forgetting something big, though, so if
your favorite feature request is not included in the list please
speak up.

- Teach send-pack to use get_sha1() on the source side.

  In addition to a pattern that matches one reference on the
  source side, we should be able to use anything get_sha1() can
  grok.  Hopefully I'll be looking into this over the weekend.

- Teach fetch-pack reference renaming.

  On the push side, send-pack now knows updating arbitrary
  remote references from local references.  We need something
  similar for fetching.  I personally do not feel we need it for
  cloning but my cursory reading of clone-pack indicates the
  command is meant to work reasonably even in an already
  populated repository.  If somebody have a good use case for
  it and a clean patch, I may be tempted to accept it.

- Glossary documentation Johannes Schindelin is working on.

  I think coming up with the concensus of terms would come
  fairly quickly on the list.  Updating docs to match the
  concensus may take some time.  Help is greatly appreciated.

- Makefile variables updates from Pasky.

  While I do not have objections to rename dest to DESTDIR and
  such Pasky proposes, I want to have a matching change to RPM
  and deb generation.  I can speak basic debian/rules, but I am
  reluctant to touch RPM side of the things.

  Whether we do the dest/DESTDIR rename or not, we need to tweak
  binary packaging anyway, or stop installing the default
  templates.  I can be talked into either way.


My tentative plan is for 0.99.4 to finish send-pack, 0.99.5
to enhance fetch-pack, 0.99.6 to finish the first pass for the
documentation updates and stabilizing the binary packaging.


These are not 1.0 showstopper items but what I personally would
love to see.

- teach mailsplit/mailinfo basic MIME (attachments and quoted-printable)

  Some people send patches in MIME quoted-printable.  I could
  drop them on the floor and ask the sender to resend, but I've
  been being a nice guy, which currently involves manual
  intervention.

- teach git-apply "reverse" and possibly "fuzz".

  I think this might help Porcelain; currently they have to
  interpret git extended diff headers themselves.

- commit template filler discussed with Pasky some time ago.

- "rev-list a...b" should mean "rev-list `merge-base a b`..b"

Re: My Itchlist

[Linus Torvalds]

On Fri, 5 Aug 2005, Junio C Hamano wrote:
> 
> - Teach fetch-pack reference renaming.

Well, the fetch side at least needs it less.

Right now the renaming means that you can only really fetch _one_ head at 
a time, but that's at least a fairly common and important case, and you 
can do the rest from there.

And doing only one means that git-fetch-pack can just return the result
SHA1 of the head it was asked to fetch. In fact, even that could just be
extended to returning multiple heads: just return each SHA1 in order. No 
"renaming" necessary, since it's then up to the user what to do with the 
results.

In fact, many users don't even want to write the result to a ref _at_all_: 
they just use the raw name - no refs - to merge.

So arguably it is _wrong_ to make git-fetch-pack write refs, because that 
just leads to the problem with temporary refs etc. "Local variables are 
good".

> These are not 1.0 showstopper items but what I personally would
> love to see.
> 
> - teach mailsplit/mailinfo basic MIME (attachments and quoted-printable)
> 
>   Some people send patches in MIME quoted-printable.  I could
>   drop them on the floor and ask the sender to resend, but I've
>   been being a nice guy, which currently involves manual
>   intervention.

This really is a nasty problem. People add their own commentary etc, and 
the fact is, the maintainer _needs_ to edit it.

Otherwise you'll have people saying "Hi there, I really like this thing, 
but I have this problem which this patch fixes" etc, which is all very 
nice, but dammit, that's simply not changelog material.

Also, I definitely myself end up editing patches occasionally: fixing 
things up. Again, this is simply a major pain if the patch comes in as an 
attachment.

So there are tons of reasons to just try to teach people that attachments 
are painful. Much better to teach people not to use them than having 
people use them and the tools "working" with them.

> - teach git-apply "reverse" and possibly "fuzz".
> 
>   I think this might help Porcelain; currently they have to
>   interpret git extended diff headers themselves.

Reverse would definitely be useful. "fuzz" is really pretty dangerous. I 
think that once a a patch doesn't apply, you really want to have helper 
tools like a graphical "wiggle" etc, and that really means that it's not 
"git-apply", it's something totally different.

And quite frankly, if you have a tool that can handle unified diffs 
already, then extending it for the git rename stuff should be pretty easy. 
It's not like we haven't wanted renaming patches for at least a _decade_ 
already, it's just that nobody ever did them. 

So I'm hoping that git can act as a impetus for people to just finally 
have a standard way of saying "rename". EVERYBODY wants it. Anybody who 
ever sees a rename as a patch will always go "damn, it would be nice to 
have renames". And dammit, we have them, so let's try to push out the 
concept.

And if that means that we should use rename patches and let non-git users 
have some pain until they say "ok, ok, it's a good idea, I'll do it. 
Uncle, uncle!", then maybe the world will be a better place. It's not like 
they can't see how git-apply does it already ;)

			Linus

Re: My Itchlist

[Johannes Schindelin]

Hi,

On Fri, 5 Aug 2005, Linus Torvalds wrote:

> On Fri, 5 Aug 2005, Junio C Hamano wrote:
> > 
> > - Teach fetch-pack reference renaming.
> 
> Well, the fetch side at least needs it less.
> 
> Right now the renaming means that you can only really fetch _one_ head at 
> a time, but that's at least a fairly common and important case, and you 
> can do the rest from there.
> 
> And doing only one means that git-fetch-pack can just return the result
> SHA1 of the head it was asked to fetch. In fact, even that could just be
> extended to returning multiple heads: just return each SHA1 in order. No 
> "renaming" necessary, since it's then up to the user what to do with the 
> results.

I think that we need a method to do a push in reverse: If a central 
repository has several branches, I might want to pull just those branches 
where the local head is a strict parent of the remote side, and get 
complains for the others. And maybe reference naming comes as a freebie 
with that.

Ciao,
Dscho

Re: My Itchlist

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> I think that we need a method to do a push in reverse: If a central 
> repository has several branches, I might want to pull just those branches 
> where the local head is a strict parent of the remote side, and get 
> complains for the others. And maybe reference naming comes as a freebie 
> with that.

I can first run "git ls-remote" to discover what are available
heads and tags, and choose to "git fetch" without actually
merging nor touching my references if I did not want to.  I
could then attempt to "git resolve" offline, and if it results
in a real merge, not fast forward, and if I am in a hurry and do
not want to risk merging without thinking, I can just keep my
head and defer the merging part.  I think that is what you are
getting at by "pull only when local is a strict parent of the
remote".

It is really the matter of where the ancestry computation
happens.  You seem to think you would want to do it on the
central server side, but I tend to think that should be done on
the puller's side, like I outlined above.  There are two
reasons:

 (1) as you mentioned in a separate topic, the current
     upload-pack/fetch-pack protocol pair seems to put a
     nontrivial burden on the server side.  I'd prefer to have
     the client side do more work.

 (2) You are interested in that remote branch, so while you may
     not want to merge the upstream changes into the branch you
     have your local modifications right away, it is likely you
     eventually will.  Fetching the objects would not be a
     wasted traffic.

What Linus said makes a lot of sense to me.  While the current
"git fetch" user interface captures a commonly used pattern of
fetching a single remote reference and optionally storing that
remote reference as a local reference under refs/heads, it is
cumbersome to use when you want to slurp objects needed for
multiple remote references and not store the references
themselves anywhere.

Re: My Itchlist

[Petr Baudis]

Dear diary, on Sat, Aug 06, 2005 at 04:39:01AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> On Fri, 5 Aug 2005, Junio C Hamano wrote:
> > - teach git-apply "reverse" and possibly "fuzz".
> > 
> >   I think this might help Porcelain; currently they have to
> >   interpret git extended diff headers themselves.
> 
> Reverse would definitely be useful. "fuzz" is really pretty dangerous. I 
> think that once a a patch doesn't apply, you really want to have helper 
> tools like a graphical "wiggle" etc, and that really means that it's not 
> "git-apply", it's something totally different.

I don't know, but I come across fuzzy patches quite frequently and any
problems have been always _extremely_ rare. And in any case, I can (and
do) verify it right away by doing cg-diff and checking what changes did
the patch really do.

> And quite frankly, if you have a tool that can handle unified diffs 
> already, then extending it for the git rename stuff should be pretty easy. 
> It's not like we haven't wanted renaming patches for at least a _decade_ 
> already, it's just that nobody ever did them. 

That reminds me I should finally add support for renames to cg-patch...

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

GIT 0.99.4 (preview)

[Junio C Hamano]

I said:

> My tentative plan is for 0.99.4 to finish send-pack, 0.99.5
> to enhance fetch-pack, 0.99.6 to finish the first pass for the
> documentation updates and stabilizing the binary packaging.

Ok, I am almost ready to push 0.99.4 out.  Here is what I have
in the public repository.

  - The branches master & pu are as usual.  Modulo bugs, I
    consider send-pack enhancement finished.

  - There is an "rc" branch whose Makefile already says 0.99.4.
    I've been working on Debian and RPM packaging issues today,
    with help from Chris Wright and H Peter Anvin, in this
    branch.

The plan is to stabilize the binary packaging issues in the "rc"
branch, and ordinary feature updates and bugfixes in "master" or
"pu" branch as usual.  When things are ready, "rc" and "master"
will be merged, 0.99.4 gets created and tagged, and "master" and
"pu" will continue from there.

I would appreciate if folks familiar with binary packaging,
especially RPM, give final sanity checks on what is currently in
"rc" branch.

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 <torvalds@osdl.org>
+Vendor: 	Junio C Hamano <junkio@cox.net>
 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 <vonbrand@inf.utfsm.cl>
+- 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 <ebiederm@xmission.com>
 - Add the man pages, and the --without docs build option
+
 * Wed Jul 7 2005 Chris Wright <chris@osdl.org>
 - 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

GIT 0.99.4 preview: current status

[Junio C Hamano]

Things are looking almost ready for a new release.  The list at
the end of this message shows what went into the release
candidate branch since 0.99.3: Dan's commit walker updates to
deal with a packed repository, Johannes fixed quite a lot of
problems in the documentation, I did reference-renaming push, a
couple of usability improvements from Linus, gitk updates from
Paul, and Ryan added an bulk e-mailer.  With help from Kalle,
Horst and Chris Wright, binary packaging looks in a better shape
now.  I'll let this simmer for a couple more days, and plan to
merge them back to the master branch on Wednesday and tag it as
v0.99.4.  Some of the patches I will receive before Wednesday
from the list, and some of what I already have in the proposed
update branch, may graduate to the master branch before that
happens.

Earlier, I posted my itchlist.  I would of course appreciate if
somebody scratches them, but at the same time would appreciate
people to voice their own itches.  My personal 0.99.5 itches are
to enhance fetch to deal with multiple references and have
local-pull to deal with a packed repository.  Dan's help would be
greatly appreciated on the latter one.

Oh, another itch I did not list in the previous message.  Is
anybody interested in doing an Emacs VC back-end for GIT?

BTW, I used "git log v0.99.3..rc | git shortlog" to prepare the
attached list, but ended up hand-removing many "Merge with blah"
entries.  It may not be a bad idea to have an option to filter
out the merge entries at "git log" time.  Adding
'--single-parent-only' flag to git-rev-list would be one way of
doing it.  Suggestions?

------------
Alecs King:
  Fix sparse warnings

barkalow@iabervon.org:
  Object library enhancements
  Parallelize the pull algorithm
  Parallelize pulling by ssh

Holger Eitzenberger:
  git: add git_mkstemp()
  git: use git_mkstemp() instead of mkstemp() for diff generation.

Horst von Brand:
  RPM spec updates.

Johannes Schindelin:
  git-commit-script fix for degenerated merge
  Assorted documentation patches

Junio C Hamano:
  Clean t/trash upon "make clean" as well.
  Make send-pack --all and explicit ref mutually exclusive.
  receive-pack hooks updates.
  Make sure leading directories exist when pushing refs.
  git-send-email-script: minimum whitespace cleanup.
  send-pack: handle partial pushes correctly.
  Install sample hooks
  Renaming push.
  git-send-pack: documentation
  Retire check-files.
  Retire git-check-files documentation too.
  git-bisect termination condition fix.
  git-init-db: brown paper bag bugfix.
  Fix send-pack for non-commitish tags.
  Update get_sha1() to grok extended format.
  Teach rev-list since..til notation.
  daemon.c: squelch error message from EINTR
  git-applymbox: allow retrying after fixing up.
  Fix refname termination.
  Fix ref_newer() in send-pack.
  send-pack: allow the same source to be pushed more than once.
  send-pack: allow generic sha1 expression on the source side.
  gitk proposed fix: handle more than one SHA1 links.
  Redo the templates generation and installation.
  GIT 0.99.4 (release candidate)
  Fix RPM build that omitted templates and tools.
  Fix build rules for debian package.
  (revert local fix)
  Update Maintainer field of debian/control

Kalle Valo:
  Fix debian doc-base

Linus Torvalds:
  Make git-sh-setup-script do what it was supposed to do
  Extend "git reset" to take a reset point
  gitk "parent information" in commit window

Nicolas Pitre:
  list shortlog items in commit order

Paul Mackerras:
  Compress the graph horizontally if it gets too wide.
  Add forward and back buttons and make SHA1 IDs clickable links.
  Change cursor to a hand cursor when over a SHA1 ID link.
  Use lf translation rather than binary when reading commit data.
  Better graph line details display and expand history coverage.

Petr Baudis:
  Fix git-merge-cache -q

Ryan Anderson:
  Add git-send-email-script - tool to send emails from git-format-patch-script
  Add documentation for git-send-email-script
  Add new dependencies caused by git-send-email-script to debian/control
  Convert from using quoted-printable to just 8bit encoding on all emails.
  Cleanup initial comments, add copyright notices.
  Add "--chain-reply-to" to git-send-email-script, to control whether or not the
  git-send-email-script: Reformat readline interface and generate a better message-id.
  Make the SMTP server used by git-sendm-email-script configurable on the command line with "--smtp-server"
  git-send-email-script - fix 2 small bugs that snuck through an untested bout of editing.
  git-send-email-script - Fix loops that limit emails to unique values to be pedantically correct.
  Doc: update git-send-email-script documentation.

Sergey Vlasov:
  Plug memory leaks in git-unpack-objects

Request for help from binary packaging people.

[Junio C Hamano]

I need a bit more help from binary packaging people.

I have not heard from Darwin or BSD people for some time.  Is
your portfile up to date?  Do you have updates you want me to
include?  Have we introduced non-Linux non-GNU incompatibilities
lately that you want to see fixed and/or worked around?

For RPM, from my lack of RPM expertise (and RPM capable
environment until recently), I have not updated the "Prereq:"
field in git-core.spec.in at all.  I would appreciate somebody
to sanity check the list of dependencies.  The dependency list
Debian side has is more up-to-date and I am reasonably sure it
is accurate.  It lists patch, diff, and rcs (for the "merge"
command) as the essential dependency (aside from the shared
libraries like libc), and libmail-sendmail-perl, rsync, curl,
ssh, and libemail-valid-perl as the recommended dependency.  I
do not even know if RPM has the notion of such multi-tier
dependencies, but the latter list is meant to mean "you could
live without these, but to exercise this package fully you may
want them" (in our case of git-core, you could live without the
networking if you do not do multi-user, multi-repository).  If
RPM spec file has a way to say something like that, I would like
to see these packages (probably their names are different
between Debian and RPM) listed on the recommended dependency
list; otherwise I would want to see them added to the main
"Prereq:" list.

For Debian, we recommend lib*-*-perl packages.  Do we need to
recommend perl itself as well, or is it the case that things
that are covered with the automatic dependency chain need not be
listed?  Earlier I said that the Debian side is reasonably
accurate to the best of my knowledge, but I would appreciate it
if somebody ran lintian on it.

Pretty please?

Re: Request for help from binary packaging people.

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2797 bytes --]

On Mon, 08 Aug 2005 10:38:44 -0700 Junio C Hamano wrote:

> For RPM, from my lack of RPM expertise (and RPM capable
> environment until recently), I have not updated the "Prereq:"
> field in git-core.spec.in at all.

That "Prereq:" should be "Requires:" instead.  "Prereq:" also
enforces installation ordering between packages; it is required
when the package has some installation scripts (%pre, %post) -
in this case all packages which are needed to execute these
scripts must be listed in "Prereq:".  In case of git-core there
are no such scripts (at least for now), so "Requires:" should be
used - then the package manager will be free to install packages
in any order as long as all dependencies will be satisfied in
the end.

> I would appreciate somebody to sanity check the list of
> dependencies.  The dependency list Debian side has is more
> up-to-date and I am reasonably sure it is accurate.  It lists
> patch, diff, and rcs (for the "merge" command) as the
> essential dependency (aside from the shared libraries like
> libc), and libmail-sendmail-perl, rsync, curl, ssh, and
> libemail-valid-perl as the recommended dependency.  I do not
> even know if RPM has the notion of such multi-tier
> dependencies, but the latter list is meant to mean "you could
> live without these, but to exercise this package fully you may
> want them" (in our case of git-core, you could live without
> the networking if you do not do multi-user, multi-repository).

RPM does not have "Suggests" and "Recommends" like dpkg - all
RPM dependencies are strict.  Because of this limitation, a
single RPM package is often split into several binary
subpackages.

> If RPM spec file has a way to say something like that, I would
> like to see these packages (probably their names are different
> between Debian and RPM) listed on the recommended dependency
> list; otherwise I would want to see them added to the main
> "Prereq:" list.

Not only the names of packages are different between Debian and
RPM - the names of similar RPM packages are different between
different RPM-based distributions. :(

E.g., in ALT Linux distributions /usr/bin/ssh is contained in
the openssh-clients package; SuSE 9.3 seems to have it in the
package named "openssh".  There are lots of such differences.

Most modern RPM-based distributions have some mechanism to find
dependencies automatically (e.g., by scanning all Perl scripts
in the package for "use" statements).  But these mechanisms are
incompatible between different distributions too.

Different distributions also have different RPM packaging
conventions, different RPM macros, etc etc...

So the best thing you can really do is to provide an RPM package
for some distribution you choose, which would then be used as a
basis for packages on other distributions.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Request for help from binary packaging people.

[Chris Wright]

* Junio C Hamano (junkio@cox.net) wrote:
> For RPM, from my lack of RPM expertise (and RPM capable
> environment until recently), I have not updated the "Prereq:"
> field in git-core.spec.in at all.  I would appreciate somebody
> to sanity check the list of dependencies.  The dependency list
> Debian side has is more up-to-date and I am reasonably sure it
> is accurate.  It lists patch, diff, and rcs (for the "merge"
> command) as the essential dependency (aside from the shared
> libraries like libc), and libmail-sendmail-perl, rsync, curl,
> ssh, and libemail-valid-perl as the recommended dependency.  I
> do not even know if RPM has the notion of such multi-tier
> dependencies, but the latter list is meant to mean "you could
> live without these, but to exercise this package fully you may
> want them" (in our case of git-core, you could live without the
> networking if you do not do multi-user, multi-repository).  If
> RPM spec file has a way to say something like that, I would like
> to see these packages (probably their names are different
> between Debian and RPM) listed on the recommended dependency
> list; otherwise I would want to see them added to the main
> "Prereq:" list.

I'd say the proper rpm method would be with subpackages with their own
prereqs.  Also, rpm is able to determine the perl dependencies
automatically (of course, ditto for shared libraries).

Now, the only issue is this package is unlikely to install because of the
Mail/Sendmail.pm and Email/Valid.pm requirements.  We can add specific
package requirements for those since they are less common.

Here's the actual install dependency list:

$ rpm -qp /home/chrisw/rpms/RPMS/i386/git-core-0.99.4-1.i386.rpm --requires
/bin/sh
/usr/bin/env
/usr/bin/perl
diffutils
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.2.3)
libc.so.6(GLIBC_2.3)
libcrypto.so.4
libcurl.so.3
libssl.so.4
libz.so.1
mktemp >= 1.5
perl(Data::Dumper)
perl(Email::Valid)
perl(File::Basename)
perl(File::Path)
perl(File::Spec)
perl(File::Temp)
perl(Getopt::Long)
perl(Getopt::Std)
perl(IO::Pipe)
perl(IO::Socket)
perl(Mail::Sendmail)
perl(POSIX)
perl(Term::ReadLine)
perl(Time::Local)
perl(strict)
perl(warnings)
rcs
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1
rsync
sh-utils

Re: Request for help from binary packaging people.

[Junio C Hamano]

Chris Wright <chrisw@osdl.org> writes:

> ...  Also, rpm is able to determine the perl dependencies
> automatically (of course, ditto for shared libraries).

I take it to mean that we do not have to explicitly list perl
module dependencies.  If that is the case then I presume that
the current dependency list is fine.

Re: Request for help from binary packaging people.

[Chris Wright]

* Junio C Hamano (junkio@cox.net) wrote:
> Chris Wright <chrisw@osdl.org> writes:
> 
> > ...  Also, rpm is able to determine the perl dependencies
> > automatically (of course, ditto for shared libraries).
> 
> I take it to mean that we do not have to explicitly list perl
> module dependencies.  If that is the case then I presume that
> the current dependency list is fine.

That's correct.  The only benefit to itemzing the package level dependency in
this case is just for an error message that tells you which package
you're missing rather than the low-level perl module.

thanks,
-chris

Re: Request for help from binary packaging people.

[Junio C Hamano]

Chris Wright <chrisw@osdl.org> writes:

>> I take it to mean that we do not have to explicitly list perl
>> module dependencies.  If that is the case then I presume that
>> the current dependency list is fine.
>
> That's correct.  The only benefit to itemzing the package level dependency in
> this case is just for an error message that tells you which package
> you're missing rather than the low-level perl module.

Again, thanks.

Re: Request for help from binary packaging people.

[Matthias Urlichs]

Hi, Junio C Hamano wrote:

> For Debian, we recommend lib*-*-perl packages.  Do we need to recommend
> perl itself as well, or is it the case that things that are covered with
> the automatic dependency chain need not be listed? 

No, yes.  ;-)

What happens if the lib*-perl packages are not installed? If some scripts
break, that's a Bad Thing, and would require those packages to be moved to
Depends:.

> Earlier I said that
> the Debian side is reasonably accurate to the best of my knowledge, but I
> would appreciate it if somebody ran lintian on it.

Will do.

-- 
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
 - -
"I say we take off; nuke the site from orbit.  It's the only way to be sure."
- Corporal Hicks, in "Aliens"

[PATCH] Debian packaging for 0.99.4

[Matthias Urlichs]

Debian packaging fixes for 0.99.4:

- Add a debian/changelog entry.
- Split gitk off to its own package;
  it needs tk installed, but nothing else does.
- Refer to GPL properly, don't install COPYING.
- Fix maintainer.
- Use dh_movefiles instead of dh_install;
  we don't want to list everything *except* gitk.

---
More Lintian warnings (not fixed by this patch):

W: git-core: binary-without-manpage git-LOTS
W: git-tk: binary-without-manpage gitk

Debian *really* dislikes exec tricks:
E: git-tk: shell-script-fails-syntax-check ./usr/bin/gitk

git-parse-remote is not an executable script and therefore
does *not* belong in /usr/bin:
W: git-core: executable-not-elf-or-script ./usr/bin/git-parse-remote

Do we need any newer features of diff? If not => drop from Depends:.
E: git-core: depends-on-essential-package-without-using-version depends: diff

---
diff --git a/debian/changelog b/debian/changelog
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+git-core (0.99.4-1) unstable; urgency=low
+
+  * Lots and lots of changes.
+
+ -- Matthias Urlichs <smurf@debian.org>  Wed, 10 Aug 2005 23:18:34 +0200
+
 git-core (0.99-2) unstable; urgency=low
 
   * Conflict with the GNU Interactive Tools package, which also installs
diff --git a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -1,7 +1,7 @@
 Source: git-core
 Section: devel
 Priority: optional
-Maintainer: Linus Torvalds <torvalds@osdl.org>
+Maintainer: Junio C Hamano <junkio@cox.net>
 Build-Depends-Indep: libz-dev, libssl-dev, libcurl3-dev, asciidoc > 6.0.3, xmlto, debhelper (>= 4.0.0)
 Standards-Version: 3.6.1
 
@@ -15,5 +15,11 @@ Description: The git content addressable
  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).
+ similar to other SCM tools.
+
+Package: git-tk
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}, git-core, tk8.4
+Description: The git content addressable filesystem, GUI add-on
+ This package contains 'gitk', the git revision tree visualizer
 
diff --git a/debian/copyright b/debian/copyright
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,3 +1,19 @@
-License: 
+This package was downloaded from ftp.kernel.org:/INSERT_PATH_HERE
 
-GPL v2 (see COPYING for details)
+Upstream Author: Linus Torvalds and many others
+
+Copyright:
+
+ Copyright 2005, Linus Torvalds and others.
+ 
+ This file is free software; as a special exception the author gives
+ unlimited permission to copy and/or distribute it, with or without
+ modifications, as long as this notice is preserved.
+ 
+ This file is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
+ implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+
+This program is free-software released under the terms of the GNU Public
+License, version 2.0. Please check /usr/share/common-licenses/GPL for
+more information.
diff --git a/debian/docs b/debian/docs
--- a/debian/docs
+++ b/debian/docs
@@ -1,3 +1 @@
 README
-COPYING
-
diff --git a/debian/git-core.files b/debian/git-core.files
new file mode 100644
--- /dev/null
+++ b/debian/git-core.files
@@ -0,0 +1 @@
+/usr
diff --git a/debian/git-core.install b/debian/git-core.install
deleted file mode 100644
--- a/debian/git-core.install
+++ /dev/null
@@ -1 +0,0 @@
-*
diff --git a/debian/git-tk.files b/debian/git-tk.files
new file mode 100644
--- /dev/null
+++ b/debian/git-tk.files
@@ -0,0 +1 @@
+/usr/bin/gitk
diff --git a/debian/rules b/debian/rules
--- a/debian/rules
+++ b/debian/rules
@@ -61,7 +61,9 @@ install: build
 	mkdir -p $(DOC_DESTDIR)
 	find $(DOC) '(' -name '*.txt' -o -name '*.html' ')' -exec install {} $(DOC_DESTDIR) ';'
 
-	dh_install --list-missing --sourcedir=$(DESTDIR)
+	dh_movefiles -p git-tk
+	dh_movefiles -p git-core
+	find debian/tmp -type d -o -print | sed -e 's/^/? /'
 
 binary: build install
 	dh_testdir

-- 
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
 - -
Any false value is gonna be fairly boring in Perl, mathematicians
notwithstanding.
             -- Larry Wall in <199707300650.XAA05515@wall.org>

Re: [PATCH] Debian packaging for 0.99.4

[Martin Langhoff]

On 8/11/05, Matthias Urlichs <smurf@smurf.noris.de> wrote:
> Debian packaging fixes for 0.99.4:

Is this anywhere in the archive?

cheers,


martin

Re: [PATCH] Debian packaging for 0.99.4

[Matthias Urlichs]

[-- Attachment #1: Type: text/plain, Size: 907 bytes --]

Hi,

Martin Langhoff:
> On 8/11/05, Matthias Urlichs <smurf@smurf.noris.de> wrote:
> > Debian packaging fixes for 0.99.4:
> 
> Is this anywhere in the archive?
> 
Cogito 0.12.1 (which includes git) has been packaged by Sebastian
Kuzminsky <seb@highlab.com>; it's in Debian Unstable. I assume
he'll do something about packaging the current version; I just filed a
wishlist bug in Debian.

The current "cogito" package in Debian renames both the git and cg
command line programs because there are already packages with conflicting
commands in Debian ("git" and "cgvg"). I consider that to be a mistake,
to be honest.

-- 
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
 - -
Coding is easy. All you do is sit staring at a terminal
until the drops of blood form on your forehead.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Debian packaging for 0.99.4

[Sebastian Kuzminsky]

Matthias Urlichs <smurf@smurf.noris.de> wrote:
> Cogito 0.12.1 (which includes git) has been packaged by Sebastian
> Kuzminsky <seb@highlab.com>; it's in Debian Unstable. I assume
> he'll do something about packaging the current version; I just filed a
> wishlist bug in Debian.
> 
> The current "cogito" package in Debian renames both the git and cg
> command line programs because there are already packages with conflicting
> commands in Debian ("git" and "cgvg"). I consider that to be a mistake,
> to be honest.

I agree completely - it's super bogus to rename the two central programs.
It makes Debian essentially incompatible with the rest of the world.

My cogito Debian package initially conflicted with the original git
(GNU Interactive Tools), so that both could install /usr/bin/git, but
I got flamed pretty good for this on the debian-devel list, and as a
junior maintainer I followed the recommendations of the more experienced
maintainers - renaming "our" git executable was their choice.

I even suggested using update-alternatives, but that was nixed too.


I predict the current "native" debian package of git will be critizised
for the same reason: because it conflicts with GNU Interactive
Tools.  Before uploading it to the Debian archive I (or someone)
will have to either mangle it like cogito.deb (renaming /usr/bin/git
to /usr/bin/something-else), or convince the Debian people to change
their minds.  If it's the former, I assume everyone who cares will just
compile their own version of git and install that.


-- 
Sebastian Kuzminsky

Re: [PATCH] Debian packaging for 0.99.4

[Martin Langhoff]

On 8/11/05, Sebastian Kuzminsky <seb@highlab.com> wrote:
> I agree completely - it's super bogus to rename the two central programs.
> It makes Debian essentially incompatible with the rest of the world.

Well, I doubt this problem lies with Debian. GNU Interactive Tools is
packaged for most (all?) distributions, and has been there for ages. A
quick google search shows a page tracking a few of its distributed
versions: http://linux.maruhn.com/sec/git.html

So it is fair to assume all distros are going to rename it, and wreak
havoc with the calls to the binaries from cogito, qgit, etc. Perhaps
it'd be better to rename the binaries within the git project. Better
Junio at it than a bunch of package maintainers... It'll also nullify
the risk of different packagers choosing different renaming
strategies.

cheers,


martin

Re: [PATCH] Debian packaging for 0.99.4

[Sebastian Kuzminsky]

Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 8/11/05, Sebastian Kuzminsky <seb@highlab.com> wrote:
> > I agree completely - it's super bogus to rename the two central programs.
> > It makes Debian essentially incompatible with the rest of the world.
> 
> Well, I doubt this problem lies with Debian. GNU Interactive Tools is
> packaged for most (all?) distributions, and has been there for ages. A
> quick google search shows a page tracking a few of its distributed
> versions: http://linux.maruhn.com/sec/git.html
> 
> So it is fair to assume all distros are going to rename it, and wreak
> havoc with the calls to the binaries from cogito, qgit, etc. Perhaps
> it'd be better to rename the binaries within the git project. Better
> Junio at it than a bunch of package maintainers... It'll also nullify
> the risk of different packagers choosing different renaming
> strategies.

Yes, this would be best.  Linus was resistant to this idea, but maybe
Junio will be sympathetic?

I'll once again suggest "lit", for "Linu{x,s} Information Tracker",
meaning "filled with light", "on fire", and "drunk".


While we're at it, renaming cogito's "cg" to "cog" would fix another
filename conflict in Debian, and would give the right hand something to
do while the left hand seeks from c to g.  ;-)


-- 
Sebastian Kuzminsky

Re: [PATCH] Debian packaging for 0.99.4

[Junio C Hamano]

Sebastian Kuzminsky <seb@highlab.com> writes:

> While we're at it, renaming cogito's "cg" to "cog" would fix another
> filename conflict in Debian, and would give the right hand something to
> do while the left hand seeks from c to g.  ;-)

Well, these days cogito ships without git, so maybe it should be
renamed to "coo" ;-).

No, renaming git to lit is not on my list of immediate things to
do.  At least not yet.

Re: [PATCH] Debian packaging for 0.99.4

[Linus Torvalds]

On Thu, 11 Aug 2005, Martin Langhoff wrote:
> 
> Well, I doubt this problem lies with Debian.

Oh, it definitely does.

>				 GNU Interactive Tools is
> packaged for most (all?) distributions, and has been there for ages.

.. but no other distribution seems to install it.

The _only_ people who have ever even noticed are debian people.

That should clue somebody in.

The top man-page I found for GNU interactive tools says:

	A Set of Interactive Programs
	Edition 2.5, for GIT version 4.3.16
	January 1997

just let it die in peace.

		Linus

Re: [PATCH] Debian packaging for 0.99.4

[Johannes Schindelin]

Hi,

On Wed, 10 Aug 2005, Linus Torvalds wrote:

> 	A Set of Interactive Programs
> 	Edition 2.5, for GIT version 4.3.16
> 	January 1997
> 
> just let it die in peace.

God have mercy over (old) GIT's soul.

Amen

Re: [PATCH] Debian packaging for 0.99.4

[Sebastian Kuzminsky]

Linus Torvalds <torvalds@osdl.org> wrote:
> The top man-page I found for GNU interactive tools says:
> 
> 	A Set of Interactive Programs
> 	Edition 2.5, for GIT version 4.3.16
> 	January 1997
> 
> just let it die in peace.


The top of the RCS changelog says:

    Fri Jun 16 06:19:24 1995  Paul Eggert  <eggert@twinsun.com>

            Version 5.7 released.
             

Should we let /usr/bin/merge die in peace too?


People still use GNU Interactive Tools.  Not just crazy, stupid people,
and I bet not just Debian people.


-- 
Sebastian Kuzminsky

Re: [PATCH] Debian packaging for 0.99.4

[Matthias Urlichs]

Hi, Sebastian Kuzminsky wrote:

> People still use GNU Interactive Tools.  Not just crazy, stupid people,
> and I bet not just Debian people.

Possibly. But the number of people running both git and git are, I'd bet,
smaller than those who will send annoying emails when they install git and
can't run all the "git xxx" commands we talk about here.

Same with cgvg, cogito, and cg.

-- 
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
 - -
The girl who remembers her first kiss now has a daughter who can't even
remember her first husband.

Re: [PATCH] Debian packaging for 0.99.4

[Linus Torvalds]

On Wed, 10 Aug 2005, Sebastian Kuzminsky wrote:
> 
> People still use GNU Interactive Tools.  Not just crazy, stupid people,
> and I bet not just Debian people.

Why do you say that?

Do you have anybody who actually does, or are you just claiming so?

Some distributions seems to disagree with you. rpm.pbone.net already
implies that SuSE not only has never packaged GNU interactive tools at
all, they're already packaging git-core. Redhat seems to have dropped it
after RH-7.1 according to the same admittedly very nonscientific source
(while rpmfind.net didn't find any RH packages at all).

So..

		Linus

Re: [PATCH] Debian packaging for 0.99.4

[Sebastian Kuzminsky]

Linus Torvalds <torvalds@osdl.org> wrote:
> 
> On Wed, 10 Aug 2005, Sebastian Kuzminsky wrote:
> > 
> > People still use GNU Interactive Tools.  Not just crazy, stupid people,
> > and I bet not just Debian people.
> 
> Why do you say that?
> 
> Do you have anybody who actually does, or are you just claiming so?

What I have is bug reports against the cogito package, from people who
want to install both.  The reports came very soon after I released the
package, so I dont think it's a totally freak occurance.

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=309776;archive=yes


Some Debian maintainers defend GNU Interactive Tools, but I'm guessing
that will only lower your opinion of Debian maintainers:

    http://lists.debian.org/debian-mentors/2005/06/msg00013.html


Anyway, enough of this.  I understand the name will not change and I'm
ok with that.  I'll deal with it on our (Debian's) end.


-- 
Sebastian Kuzminsky

Re: [PATCH] Debian packaging for 0.99.4

[Sam Ravnborg]

> 
> Anyway, enough of this.  I understand the name will not change and I'm
> ok with that.  I'll deal with it on our (Debian's) end.

The easy fix is to kill the small git script that is not
mandatory anyway (as far as my quick grep told me).

The cg script has a bit more value.

	Sam

Re: [PATCH] Debian packaging for 0.99.4

[Sebastian Kuzminsky]

Sam Ravnborg <sam@ravnborg.org> wrote:
> > 
> > Anyway, enough of this.  I understand the name will not change and I'm
> > ok with that.  I'll deal with it on our (Debian's) end.
> 
> The easy fix is to kill the small git script that is not
> mandatory anyway (as far as my quick grep told me).
> 
> The cg script has a bit more value.

Tried that too, and I got the bug reports to prove it.  ;-)

The problem there is that tons of docs and webpages and mailing list
archives talk about running "git this" and "git that".  So the poor
confused Debian user tries the recipe and gets "command not found", and
gives up in disgust.  Or worse, mails the git list saying it doesnt work,
and wasting everyones time debugging the intentional package mungling.

Really, the bottom line is we should all mean the same thing when we say
"git-core" and "cogito".


-- 
Sebastian Kuzminsky

Re: [PATCH] Debian packaging for 0.99.4

[Matthias Urlichs]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

Hi,

Sebastian Kuzminsky:
> > The cg script has a bit more value.
> 
> Tried that too, and I got the bug reports to prove it.  ;-)
> 
Another possible solution: Rename git's git to X and install ours as Y.
Ask the user which should be symlinked to /usr/bin/git, if both are
installed, via the existing "alternatives" system.

(The install scripts to Gnu Interactive Tools should of course do the
same thing.)

-- 
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
 - -
Too much of a good thing is WONDERFUL.
		-- Mae West

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Debian packaging for 0.99.4

[Sebastian Kuzminsky]

Matthias Urlichs <smurf@smurf.noris.de> wrote:
> Another possible solution: Rename git's git to X and install ours as Y.
> Ask the user which should be symlinked to /usr/bin/git, if both are
> installed, via the existing "alternatives" system.

I suggested this on debian-devel, and was told that update-alternatives is
not to be used for programs that do not do the same thing.  Debian Policy
Manual, section 10.1.

It's ok for vim and nvi to use update-alternatives to pick who gets
to be vi, because no matter which alternative is active, running "vi"
does what you expect.  It's not ok to use it for git and GNU Interactive
Tools, because they do such different things.

Thanks for working with me on this, I appreciate all the suggestions.
I hope we can make Debian not suck at git.


-- 
Sebastian Kuzminsky

Re: [PATCH] Debian packaging for 0.99.4

[Matthias Urlichs]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

Hi,

Sam Ravnborg:
> > 
> > Anyway, enough of this.  I understand the name will not change and I'm
> > ok with that.  I'll deal with it on our (Debian's) end.
> 
> The easy fix is to kill the small git script that is not
> mandatory anyway (as far as my quick grep told me).

I'd vote to keep the scripts in the default build, so that people
who like to compile their own package (i.e. everybody _except_ the
Debian packager ;-) get to keep their git and cg scripts.

A small Debian-specific patch to rename the offending scripts (and drop
the Conflicts: entries) is cheap.

-- 
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
 - -
Experience *that breathing.*
From books and words come fantasy,
and sometimes, from fantasy comes union. -- Rumi, tr. Coleman Barks

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Debian packaging for 0.99.4

[Sam Ravnborg]

On Thu, Aug 11, 2005 at 10:24:10PM +0200, Matthias Urlichs wrote:
> Hi,
> 
> Sam Ravnborg:
> > > 
> > > Anyway, enough of this.  I understand the name will not change and I'm
> > > ok with that.  I'll deal with it on our (Debian's) end.
> > 
> > The easy fix is to kill the small git script that is not
> > mandatory anyway (as far as my quick grep told me).
> 
> I'd vote to keep the scripts in the default build, so that people
> who like to compile their own package (i.e. everybody _except_ the
> Debian packager ;-) get to keep their git and cg scripts.
> 
> A small Debian-specific patch to rename the offending scripts (and drop
> the Conflicts: entries) is cheap.

Yep - my comment was directed to debian only. Not git-core.

	Sam

Re: [PATCH] Debian packaging for 0.99.4

[Alan Chandler]

Matthias Urlichs wrote:

> 
> A small Debian-specific patch to rename the offending scripts (and drop
> the Conflicts: entries) is cheap.
> 


Not sure I understand the proper use of dpkg-divert in Debian, but could 
_this_ git-core package perhaps ask the user which set of the two 
packages he wish to keep as git command and use dpkg-divert to change 
the other to another name to some other name?




-- 
Alan Chandler
http://www.chandlerfamily.org.uk

Re: [PATCH] Debian packaging for 0.99.4

[Sebastian Kuzminsky]

Alan Chandler <alan@chandlerfamily.org.uk> wrote:
> Matthias Urlichs wrote:
> > A small Debian-specific patch to rename the offending scripts (and drop
> > the Conflicts: entries) is cheap.
> 
> Not sure I understand the proper use of dpkg-divert in Debian, but could 
> _this_ git-core package perhaps ask the user which set of the two 
> packages he wish to keep as git command and use dpkg-divert to change 
> the other to another name to some other name?

This may be a possibility.  I'm discussing the details of this kind of
solution on the debian-devel list right now.

Come join the fun!  I make a poor flame-conduit between the git list
and the debian-devel list, cut out the middle man and save.  ;-)


-- 
Sebastian Kuzminsky

Re: [PATCH] Debian packaging for 0.99.4

[Matthias Urlichs]

Hi, Alan Chandler wrote:
> Not sure I understand the proper use of dpkg-divert in Debian, but could 
> _this_ git-core package perhaps ask the user which set of the two 
> packages he wish to keep as git command and use dpkg-divert to change 
> the other to another name to some other name?

IIRC, that's against Policy too, because different users on the system
might have different expectations WRT which git is git.

-- 
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
 - -
You have a strong appeal for members of the opposite sex.

Re: [PATCH] Debian packaging for 0.99.4

[David Lang]

after so many years of software development (and with the policy of never 
having conflicting command names) what three letter combinations are still 
avilable?

I'm assuming that the much smaller pool of two letter commands was long 
since exhausted, but if not what two letter commands are available?

David Lang

  On Fri, 12 Aug 2005, Matthias Urlichs wrote:

> Date: Fri, 12 Aug 2005 10:34:45 +0200
> From: Matthias Urlichs <smurf@smurf.noris.de>
> To: git@vger.kernel.org
> Subject: Re: [PATCH] Debian packaging for 0.99.4
> 
> Hi, Alan Chandler wrote:
>> Not sure I understand the proper use of dpkg-divert in Debian, but could
>> _this_ git-core package perhaps ask the user which set of the two
>> packages he wish to keep as git command and use dpkg-divert to change
>> the other to another name to some other name?
>
> IIRC, that's against Policy too, because different users on the system
> might have different expectations WRT which git is git.
>
> -- 
> 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
> - -
> You have a strong appeal for members of the opposite sex.
>
>
> -
> 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
>

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: [PATCH] Debian packaging for 0.99.4

[Matthias Urlichs]

[-- Attachment #1: Type: text/plain, Size: 896 bytes --]

Hi,

David Lang:
> after so many years of software development (and with the policy of never 
> having conflicting command names) what three letter combinations are still 
> avilable?
> 
Lots.

> I'm assuming that the much smaller pool of two letter commands was long 
> since exhausted, but if not what two letter commands are available?
> 
Lots of them, I hope, but all of them obscure.

We even have 25 one-letter commands that are free. My /usr/bin/ only has
'w'. And if we run out, we could branch off into other alphabets;
unfortunately, not everybody has a quick way to type an ä. Or α. Or ૐ. ;-)

-- 
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
 - -
The hope that springs eternal
Springs right up your behind.
		-- Ian Drury, "This Is What We Find"

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Debian packaging for 0.99.4

[Ryan Anderson]

On Fri, Aug 12, 2005 at 12:35:55PM +0200, Matthias Urlichs wrote:
> David Lang:
> > after so many years of software development (and with the policy of never 
> > having conflicting command names) what three letter combinations are still 
> > avilable?
> > 
> Lots.
> 
> > I'm assuming that the much smaller pool of two letter commands was long 
> > since exhausted, but if not what two letter commands are available?
> > 
> Lots of them, I hope, but all of them obscure.
> 
> We even have 25 one-letter commands that are free. My /usr/bin/ only has
> 'w'. And if we run out, we could branch off into other alphabets;
> unfortunately, not everybody has a quick way to type an ??. Or ??. Or ???. ;-)

"gt" seems free on my machine here.  I haven't poke around at all the
other ones that have slightly different sets of software, but searching
on the Debian packages search engine:

http://packages.debian.org/cgi-bin/search_contents.pl?word=%2Fusr%2Fbin%2Fgt&searchmode=searchfiles&case=insensitive&version=unstable&arch=i386

cogito in Debian seems to have taken it already for git, anyway.

We can make the conversion easy for people by providing this shell
script for a few weeks:

	#!/bin/sh
	echo "Don't get a git - use gt!
	gt $*

-- 

Ryan Anderson
  sometimes Pug Majere

Re: [PATCH] Debian packaging for 0.99.4

[Matthias Urlichs]

Hi,

Ryan Anderson:
> 
> 	#!/bin/sh
> 	echo "Don't get a git - use gt!
Ouch.

> 	echo "Don't get a git - use gt!" >&2
if at all.

-- 
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
 - -
USENET would be a better laboratory if there were more labor and less oratory.
		-- Elizabeth Haley

Re: [PATCH] Debian packaging for 0.99.4

[Ryan Anderson]

On Sun, Aug 14, 2005 at 02:11:50AM +0200, Matthias Urlichs wrote:
> Hi,
> 
> Ryan Anderson:
> > 
> > 	#!/bin/sh
> > 	echo "Don't get a git - use gt!
> Ouch.

:)  I meant it as a joke, obviously.  I also thinkoed the sentence I was
aiming for, thus losing the humor.  Oh well.

> > 	echo "Don't get a git - use gt!" >&2
> if at all.

True.

On this same topic, cogito seems to be consistently using the long forms
of the names (i.e, git-*-script), so renaming "git" in the core Debian
package should not be a problem, other than for the canned recipes
people are writing constantly to demonstrate the power of git.

-- 

Ryan Anderson
  sometimes Pug Majere

Re: [PATCH] Debian packaging for 0.99.4

[Junio C Hamano]

    Debian folks on the list: We had to make this ugly hack in
    our Debianization because Debian heavyweights did not like
    to see "Conflicts:" and us lowly new maintainers needed to
    obey their wishes.

    Linus: The alleged name clash appears to be a Debian
    specific problem.  No other distribution seem to ship GNU
    interactive tools and hence have this name clash.  Debian
    folks have not even substantiated their claim that the other
    GIT is so popular that name clash with it is a bad thing.

    JC: Well, here is the popcon numbers.  I'll let people
    decide if these numbers illustrate that the other GIT is so
    popular that we cannot take over its name.

In a sense, both Linus and myself have been unfair to Debian
folks on the list.  Worrying about the name clash with the other
GIT so much to change our name was not something they liked to
do to begin with.

> Personally, I'm a mugwump, and I don't care who yields as long as it
> takes place and things can then proceed at their usual pace.

Yes, and that is what Linus and myself are saying.  We would
rather stay outside the name politics, which is internal to a
particular distribution.  Linus and I were trying to give
ammunition for the Debian folks on the list to make an argument.
Linus said that our GIT installs /usr/bin/git everywhere else
without the name clash problem.  I said that the other GIT does
not seem to be used that much even on Debian.  From these facts,
they could make an argument that, if Debian as a distribution
wants to stay compatible with other distributions, either (1) it
should tolerate Conflict: and let us install /usr/bin/git, or
(2) get the other GIT renamed.  It is up to the folks pushing
Debianization of our GIT to the Debian official archive which
recommendation to make and deal with the Debian heavyweights.

Another thing to note is that it is not unusual for an official
Debian package to have a patch to debian/* files even when the
upstream sources have some such Debianization files.  The Debian
folks on the list could take that approach without first
proposing to change the name of /usr/bin/git worldwide.  I, as a
Debian user [*1*], would be perfectly happy if the Debianization
of our GIT did not ship "/usr/bin/git", and told the user to
copy "/usr/share/doc/git-core/examples/git" to $HOME/bin/ and
put $HOME/bin at the beginning of the PATH [*2*].  Maybe such a
Debianization would ship with a modified tutorial that has a
paragraph to remind the user about that as well.

[Footnote]
*1* I do not have a single RPM machine at home nor
workplace. Practically everything I touch run Debian.

*2* Even install script offering a choice to make a symlink
/usr/local/bin/git pointing at /usr/bin/git-core-scm would be
possible, but that would only be acceptable on a single-user
machine.

Re: [PATCH] Debian packaging for 0.99.4

[Junio C Hamano]

Oops, sorry that was not something ready to be sent out.  Please
discard.

Re: [PATCH] Debian packaging for 0.99.4

[Linus Torvalds]

On Thu, 11 Aug 2005, Sam Ravnborg wrote:
> 
> The easy fix is to kill the small git script that is not
> mandatory anyway (as far as my quick grep told me).

It's not "mandatory", but the tutorial etc use it as an example.

In other words, if you remove the git script, you are going to have a 
_bad_ package.

I'd suggest that people who don't like the naming just don't install "git" 
at all. Live with it.

		Linus

Re: [PATCH] Debian packaging for 0.99.4

[Linus Torvalds]

On Thu, 11 Aug 2005, Sebastian Kuzminsky wrote:
> 
> What I have is bug reports against the cogito package, from people who
> want to install both.  The reports came very soon after I released the
> package, so I dont think it's a totally freak occurance.

The point is, people have the thing _installed_, because apparently it
comes as default with a full debian install. That doesn't mean they 
actually use them - they're complaining because they get a "this clashes 
with that" error.

At least that's the only comment I've ever gotten: people that say that
they had the old git installed. None of the ones that contacted me said
that they had actually ever _used_ it.

Hands up people. Does anybody _use_ GNU interactive tools? None of this "I 
have a package" crap.

		Linus

Re: [PATCH] Debian packaging for 0.99.4

[Sebastian Kuzminsky]

Linus Torvalds <torvalds@osdl.org> wrote:
> Hands up people. Does anybody _use_ GNU interactive tools? None of this "I 
> have a package" crap.

Obviously no one on the git list uses GNU Interactive Tools, or this
problem would have been caught much sooner.

It's only when you release it into the wild that these kind of things
get noticed.  If only it weren't for the fuc*ing users, man...


-- 
Sebastian Kuzminsky

Re: [PATCH] Debian packaging for 0.99.4

[Christian Meder]

On Thu, 2005-08-11 at 16:20 -0600, Sebastian Kuzminsky wrote:
> Linus Torvalds <torvalds@osdl.org> wrote:
> > Hands up people. Does anybody _use_ GNU interactive tools? None of this "I 
> > have a package" crap.
> 
> Obviously no one on the git list uses GNU Interactive Tools, or this
> problem would have been caught much sooner.
> 
> It's only when you release it into the wild that these kind of things
> get noticed.  If only it weren't for the fuc*ing users, man...

Hi,

I still have to meet somebody who actually ever used GNU Interactive
Tools.

I'd recommend to just conflict with GNU Interactive Tools and be done
with it.

1. It's an upstream decision by Linus
2. You are the maintainer of the package. Just take a stand and put the
bug reports in wontfix mode. 

Being a long time Debian maintainer I'd note that in Debian you've got
to take ownership to get things done.



			Christian 


-- 
Christian Meder, email: chris@absolutegiganten.org

The Way-Seeking Mind of a tenzo is actualized 
by rolling up your sleeves.

                (Eihei Dogen Zenji)

Re: [PATCH] Debian packaging for 0.99.4

[Matthias Urlichs]

[-- Attachment #1: Type: text/plain, Size: 693 bytes --]

Hi,

Linus Torvalds:
> Hands up people. Does anybody _use_ GNU interactive tools? None of this "I 
> have a package" crap.
> 
You're preaching to the converted here.

The Debian-package-for-Debian could pop up a notice asking the user to
symlink /usr/local/bin/git => /usr/bin/gitscm (or whatever) if they
want to use the "normal" name... that's probably the only solution which
would work reasonably well without being too much hassle to implement.

-- 
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
 - -
For the right person, the impossible is easy!
					-- Dumbo

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Debian packaging for 0.99.4 [u]

[Andreas Jellinghaus [c]]

On Thursday 11 August 2005 23:53, Linus Torvalds wrote:
> Hands up people. Does anybody _use_ GNU interactive tools? None of this "I 
> have a package" crap.

http://popcon.debian.org/by_inst
#Format
#   
#<name> is the package name;
#<inst> is the number of people who installed this package;
#<vote> is the number of people who use this package regularly;
#<old> is the number of people who installed, but don't use this package
#      regularly;
#<recent> is the number of people who upgraded this package recently;
#<no-files> is the number of people whose entry didn't contain enough
#           information (atime and ctime were 0).
#rank name                            inst  vote   old recent no-files 
6607  git                              114    25    82     7     0 

the database reflects 7162 users.

Andreas

Re: [PATCH] Debian packaging for 0.99.4

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> On Wed, 10 Aug 2005, Sebastian Kuzminsky wrote:
>> 
>> People still use GNU Interactive Tools.  Not just crazy, stupid people,
>> and I bet not just Debian people.
>
> Why do you say that?
>
> Do you have anybody who actually does, or are you just claiming so?

Debian folks have a handy way to substantiate that claim or get
that claim proven wrong, and I am somewhat surprised that nobody
mentioned it so far.

Debian popularity contest (http://popcon.debian.org/).

Here is an excerpt I just made.

    <name> is the package name;
    <inst> is the number of people who installed this package;
    <vote> is the number of people who use this package regularly;
    <old>  is the number of people who installed, but don't use
          this package regularly;
    <recent> is the number of people who upgraded this package recently;

    rank  name            inst    vote     old recent
    1     base-files      7147    6777     158    212
    2     base-passwd     7147    6724     163    260
    3     debianutils     7147    6739     120    288
    4     sed             7147    6763     155    229
    ...                                                                    
    6591  git              114      24      83      7
    ...                                                                    
    25555 git-core           2       1       0      1 (Not in sid)
    29939 cogito-scm         1       0       1      0 (Not in sid)
    ...                                                                    
    46416 zope2.6            0       0       0      0
    -------------------------------------------------
    46416 Total        6768849 2118048 2306009 595621

So yes, among 46.5K packages in the known universe, the other
git ranks 6600th.  Does that mean it is popular?  I dunno.

Obviously, not everybody who installs Debian participates in
popcon.  The sample size of the above statistics is 7147
installations of base-files.

Among these 7147 sample installations, the other git was
installed by 114 people, and 24 people regularly use it.

Re: [PATCH] Debian packaging for 0.99.4

[Gene Heskett]

On Thursday 11 August 2005 15:11, Junio C Hamano wrote:
>Linus Torvalds <torvalds@osdl.org> writes:
>> On Wed, 10 Aug 2005, Sebastian Kuzminsky wrote:
>>> People still use GNU Interactive Tools.  Not just crazy, stupid
>>> people, and I bet not just Debian people.
>>
>> Why do you say that?
>>
>> Do you have anybody who actually does, or are you just claiming
>> so?
>
>Debian folks have a handy way to substantiate that claim or get
>that claim proven wrong, and I am somewhat surprised that nobody
>mentioned it so far.
>
>Debian popularity contest (http://popcon.debian.org/).
>
>Here is an excerpt I just made.
>
>    <name> is the package name;
>    <inst> is the number of people who installed this package;
>    <vote> is the number of people who use this package regularly;
>    <old>  is the number of people who installed, but don't use
>          this package regularly;
>    <recent> is the number of people who upgraded this package
> recently;
>
>    rank  name            inst    vote     old recent
>    1     base-files      7147    6777     158    212
>    2     base-passwd     7147    6724     163    260
>    3     debianutils     7147    6739     120    288
>    4     sed             7147    6763     155    229
>    ...
>    6591  git              114      24      83      7
>    ...
>    25555 git-core           2       1       0      1 (Not in sid)
>    29939 cogito-scm         1       0       1      0 (Not in sid)
>    ...
>    46416 zope2.6            0       0       0      0
>    -------------------------------------------------
>    46416 Total        6768849 2118048 2306009 595621
>
>So yes, among 46.5K packages in the known universe, the other
>git ranks 6600th.  Does that mean it is popular?  I dunno.
>
>Obviously, not everybody who installs Debian participates in
>popcon.  The sample size of the above statistics is 7147
>installations of base-files.
>
>Among these 7147 sample installations, the other git was
>installed by 114 people, and 24 people regularly use it.

This obviously is not even a fair assesment of the potential
popularity of this new kernel package admin tool.  By holding to this
attitude, you will surely alienate linux users away from debian.

If so far, only 114 people out of the 7147 who were kind enough to
fill out a questionaire have installed the debian 'git' and 24 report
that they are using this tool, then obviously once a stable release of
the Linus version of git has been achieved, the user count of the new
tool will handily exceed the user count of the older and totally
different toolkit from gnu.  This will occur within 24 hours of a
working, stable release of the Linus git.  Possibly aleady has
occured, I have it (the rpm) here already.

Methinks its a good time for one or the other to come up with a new
name.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: [PATCH] Debian packaging for 0.99.4

[Junio C Hamano]

Gene Heskett <gene.heskett@verizon.net> writes:

>>    rank  name            inst    vote     old recent
>>    6591  git              114      24      83      7
>>    25555 git-core           2       1       0      1 (Not in sid)
>>    29939 cogito-scm         1       0       1      0 (Not in sid)
>
> This obviously is not even a fair assesment of the potential
> popularity of this new kernel package admin tool.  By holding to this
> attitude, you will surely alienate linux users away from debian.

> If so far, only 114 people out of the 7147 who were kind enough to
> fill out a questionaire have installed the debian 'git' and 24 report
> that they are using this tool, then obviously once a stable release of
> the Linus version of git has been achieved, the user count of the new
> tool will handily exceed the user count of the older and totally
> different toolkit from gnu.  This will occur within 24 hours of a
> working, stable release of the Linus git.  Possibly aleady has
> occured, I have it (the rpm) here already.

I suspect you are confused.  The entry "git" in above table is
the GNU interactive tools and comment about 114/7147 ratio is
about GNU interactive tools, not our GIT.  Ours are "git-core"
and "cogito-scm", marked as "Not in sid".  I do not understand
why you think my attitude would alienate users away from debian.

As you say, when it is included in the official archive, I
expect our numbers would exceed "the other GIT" very quickly.

Re: [PATCH] Debian packaging for 0.99.4

[Junio C Hamano]

Matthias Urlichs <smurf@smurf.noris.de> writes:

> - Split gitk off to its own package;
>   it needs tk installed, but nothing else does.

I just noticed from "dpkg --info" output that the generated
git-tk has "Architecture: i386".  Shouldn't it read "all" and
resulting package also named git-tk_${VERSION}_all.deb, instead
of whatever architecture I happened to build it?

Re: [PATCH] Debian packaging for 0.99.4

[Martin Langhoff]

> I just noticed from "dpkg --info" output that the generated
> git-tk has "Architecture: i386".  Shouldn't it read "all" and
> resulting package also named git-tk_${VERSION}_all.deb, instead
> of whatever architecture I happened to build it?

It is correct to have Architecture: i386, as you'd naturally have
multiple binary packages. When this is uploaded to the Debian archive,
all the other architectures are built in the "buildd" farm. That's why
the source package 'native' arch is 'any'.

Packages with arch 'all' are interpreted languages. The cogito package
will probably be for 'all' arches, and just be one binary package.

cheers,


martin

Re: [PATCH] Debian packaging for 0.99.4

[Matthias Urlichs]

Hi,

Martin Langhoff:
> It is correct to have Architecture: i386, as you'd naturally have
> multiple binary packages.

However, git(-t)k doesn't contain any i386 code, just a tk script.

> Packages with arch 'all' are interpreted languages.

Exactly. ;-)

-- 
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
 - -
compuberty, n:
	The uncomfortable period of emotional and hormonal changes a
	computer experiences when the operating system is upgraded and
	a sun4 is put online sharing files.

[PATCH] more Debian packaging fixes

[Matthias Urlichs]

git-tk should be architecture independent.
git-core forgot to depend on perl.

Signed-Off-By: Matthias Urlichs <smurf@debian.org>
---
Hi,

Junio C Hamano:
> Matthias Urlichs <smurf@smurf.noris.de> writes:
> 
> > - Split gitk off to its own package;
> >   it needs tk installed, but nothing else does.
> 
> I just noticed from "dpkg --info" output that the generated
> git-tk has "Architecture: i386".  Shouldn't it read "all" and
> resulting package also named git-tk_${VERSION}_all.deb, instead
> of whatever architecture I happened to build it?
> 
True.


diff --git a/debian/changelog b/debian/changelog
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,7 @@
 git-core (0.99.5-0) unstable; urgency=low
 
   * Split off gitk.
+    - ... into an architecture-independent package.
 
  -- Matthias Urlichs <smurf@debian.org>  Thu, 11 Aug 2005 01:43:24 +0200
 
diff --git a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Standards-Version: 3.6.1
 
 Package: git-core
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, patch, diff, rcs
+Depends: ${perl:Depends}, ${shlibs:Depends}, ${misc:Depends}, patch, diff, rcs
 Recommends: rsync, curl, ssh, libmail-sendmail-perl, libemail-valid-perl
 Conflicts: git
 Description: The git content addressable filesystem
@@ -18,7 +18,7 @@ Description: The git content addressable
  similar to other SCM tools.
 
 Package: git-tk
-Architecture: any
+Architecture: all
 Depends: ${shlibs:Depends}, ${misc:Depends}, git-core, tk8.4
 Description: The git content addressable filesystem, GUI add-on
  This package contains 'gitk', the git revision tree visualizer
diff --git a/debian/rules b/debian/rules
--- a/debian/rules
+++ b/debian/rules
@@ -65,33 +65,36 @@ install: build
 	dh_movefiles -p git-core
 	find debian/tmp -type d -o -print | sed -e 's/^/? /'
 
-binary: build install
+binary-arch: build install
 	dh_testdir
 	dh_testroot
-	dh_installchangelogs
-	dh_installdocs
-	dh_installexamples
-#	dh_installmenu
-#	dh_installdebconf	
-#	dh_installlogrotate	
-#	dh_installemacsen
-#	dh_installpam
-#	dh_installmime
-#	dh_installinit
-#	dh_installcron
-#	dh_installinfo
-	dh_installman
-	dh_link
-	dh_strip
-	dh_compress 
-	dh_fixperms
-#	dh_perl
-#	dh_python
-	dh_makeshlibs
-	dh_installdeb
-	dh_shlibdeps
-	dh_gencontrol
-	dh_md5sums
-	dh_builddeb
+	dh_installchangelogs -a
+	dh_installdocs -a
+	dh_strip -a
+	dh_compress  -a
+	dh_fixperms -a
+	dh_perl -a
+	dh_makeshlibs -a
+	dh_installdeb -a
+	dh_shlibdeps -a
+	dh_gencontrol -a
+	dh_md5sums -a
+	dh_builddeb -a
+
+binary-indep: build install
+	dh_testdir
+	dh_testroot
+	dh_installchangelogs -i
+	dh_installdocs -i
+	dh_compress  -i
+	dh_fixperms -i
+	dh_makeshlibs -i
+	dh_installdeb -i
+	dh_shlibdeps -i
+	dh_gencontrol -i
+	dh_md5sums -i
+	dh_builddeb -i
+
+binary: binary-arch binary-indep
 
 .PHONY: build clean binary install clean debian-clean
-- 
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
 - -
GUBBISH [a portmanteau of "garbage" and "rubbish"?] n. Garbage; crap;
   nonsense.  "What is all this gubbish?"
				-- From the AI Hackers' Dictionary