My Itchlist

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"

On Fri, 5 Aug 2005, Junio C Hamano wrote:

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".

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.

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

Hi,

On Fri, 5 Aug 2005, Linus Torvalds wrote:

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

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

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.

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...

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.

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

I said:

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.

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

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?

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

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.

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.

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.

* Junio C Hamano (junkio@cox.net) wrote:

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

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.

* Junio C Hamano (junkio@cox.net) wrote:

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

Chris Wright <chrisw@osdl.org> writes:

Again, thanks.

Hi, Junio C Hamano wrote:

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:.

Will do.

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

---

On 8/11/05, Matthias Urlichs <smurf@smurf.noris.de> wrote:

Is this anywhere in the archive?

cheers,

martin

Hi,

Martin Langhoff:

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 <smurf@smurf.noris.de> 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.

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.

On 8/11/05, Sebastian Kuzminsky <seb@highlab.com> wrote:

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

Martin Langhoff <martin.langhoff@gmail.com> wrote:

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 <seb@highlab.com> writes:

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.

On Thu, 11 Aug 2005, Martin Langhoff wrote:

Oh, it definitely does.

.. 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

Hi,

On Wed, 10 Aug 2005, Linus Torvalds wrote:

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

Amen

Linus Torvalds <torvalds@osdl.org> wrote:

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.

Hi, Sebastian Kuzminsky wrote:

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.

On Wed, 10 Aug 2005, Sebastian Kuzminsky wrote:

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

Linus Torvalds <torvalds@osdl.org> 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.

    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.

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

Sam Ravnborg <sam@ravnborg.org> wrote:

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".

Hi,

Sebastian Kuzminsky:

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 <smurf@smurf.noris.de> wrote:

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.

Hi,

Sam Ravnborg:

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.

On Thu, Aug 11, 2005 at 10:24:10PM +0200, Matthias Urlichs wrote:

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

	Sam

Matthias Urlichs 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?

Alan Chandler <alan@chandlerfamily.org.uk> wrote:

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. ;-)

Hi, Alan Chandler wrote:

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

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:

Hi,

David Lang:

Lots.

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 ૐ. ;-)

On Fri, Aug 12, 2005 at 12:35:55PM +0200, Matthias Urlichs wrote:

"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 $*

Hi,

Ryan Anderson:

Ouch.

if at all.

On Sun, Aug 14, 2005 at 02:11:50AM +0200, Matthias Urlichs wrote:

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

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.

    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.

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.

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

On Thu, 11 Aug 2005, Sam Ravnborg wrote:

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

On Thu, 11 Aug 2005, Sebastian Kuzminsky wrote:

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

Linus Torvalds <torvalds@osdl.org> wrote:

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...

On Thu, 2005-08-11 at 16:20 -0600, Sebastian Kuzminsky wrote:

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 

Hi,

Linus Torvalds:

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.

On Thursday 11 August 2005 23:53, Linus Torvalds wrote:

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

Linus Torvalds <torvalds@osdl.org> writes:

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.

On Thursday 11 August 2005 15:11, Junio C Hamano wrote:

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.

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

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.

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

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

Hi,

Martin Langhoff:

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

Exactly. ;-)

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:

True.