# My Itchlist 56 messages from 2005-08-06 to 2005-08-15. Participants: Junio C Hamano, Linus Torvalds, Johannes Schindelin, Sergey Vlasov, Chris Wright, Matthias Urlichs, Martin Langhoff, Sebastian Kuzminsky, Sam Ravnborg, Gene Heskett, Alan Chandler, Christian Meder, Andreas Jellinghaus [c], David Lang, Petr Baudis, Ryan Anderson. Thread: https://gitlist.dev/t/1433 ## Junio C Hamano, 2005-08-06 01:52 Subject: My Itchlist Message-ID: <7v8xzfde7t.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v8xzfde7t.fsf%40assigned-by-dhcp.cox.net ``` 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" ``` ## Linus Torvalds, 2005-08-06 02:39 Subject: Re: My Itchlist Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0508051924390.3258%40g5.osdl.org In-Reply-To: <7v8xzfde7t.fsf@assigned-by-dhcp.cox.net> ``` 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 ``` ## Johannes Schindelin, 2005-08-06 06:50 Subject: Re: My Itchlist Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0508060846050.12882%40wgmdd8.biozentrum.uni-wuerzburg.de In-Reply-To: ``` 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 ``` ## Junio C Hamano, 2005-08-06 19:04 Subject: Re: My Itchlist Message-ID: <7voe8a6g5a.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7voe8a6g5a.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Johannes Schindelin 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. ``` ## Junio C Hamano, 2005-08-07 06:00 Subject: GIT 0.99.4 (preview) Message-ID: <7vr7d6z3pn.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vr7d6z3pn.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7v8xzfde7t.fsf@assigned-by-dhcp.cox.net> ``` 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. ``` ## Junio C Hamano, 2005-08-08 09:09 Subject: GIT 0.99.4 preview: current status Message-ID: <7vacjsdcbj.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vacjsdcbj.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7vr7d6z3pn.fsf@assigned-by-dhcp.cox.net> ``` 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 ``` ## Junio C Hamano, 2005-08-08 17:38 Subject: Request for help from binary packaging people. Message-ID: <7vwtmw5nx7.fsf_-_@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vwtmw5nx7.fsf_-_%40assigned-by-dhcp.cox.net In-Reply-To: <7vacjsdcbj.fsf@assigned-by-dhcp.cox.net> ``` 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? ``` ## Sergey Vlasov, 2005-08-08 18:20 Subject: Re: Request for help from binary packaging people. Message-ID: <20050808222051.275984ff.vsu@altlinux.ru> URL: https://gitlist.dev/e/20050808222051.275984ff.vsu%40altlinux.ru In-Reply-To: <7vwtmw5nx7.fsf_-_@assigned-by-dhcp.cox.net> ``` 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. ``` ## Chris Wright, 2005-08-08 18:58 Subject: Re: Request for help from binary packaging people. Message-ID: <20050808185858.GC8041@shell0.pdx.osdl.net> URL: https://gitlist.dev/e/20050808185858.GC8041%40shell0.pdx.osdl.net In-Reply-To: <7vwtmw5nx7.fsf_-_@assigned-by-dhcp.cox.net> ``` * 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 ``` ## Junio C Hamano, 2005-08-08 22:02 Subject: Re: Request for help from binary packaging people. Message-ID: <7vbr482ik5.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vbr482ik5.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20050808185858.GC8041@shell0.pdx.osdl.net> ``` Chris Wright 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. ``` ## Chris Wright, 2005-08-08 22:21 Subject: Re: Request for help from binary packaging people. Message-ID: <20050808222119.GE7762@shell0.pdx.osdl.net> URL: https://gitlist.dev/e/20050808222119.GE7762%40shell0.pdx.osdl.net In-Reply-To: <7vbr482ik5.fsf@assigned-by-dhcp.cox.net> ``` * Junio C Hamano (junkio@cox.net) wrote: > Chris Wright 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 ``` ## Junio C Hamano, 2005-08-08 22:49 Subject: Re: Request for help from binary packaging people. Message-ID: <7v8xzc11ue.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v8xzc11ue.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20050808222119.GE7762@shell0.pdx.osdl.net> ``` Chris Wright 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. ``` ## Matthias Urlichs, 2005-08-10 21:15 Subject: Re: Request for help from binary packaging people. Message-ID: URL: https://gitlist.dev/e/pan.2005.08.10.21.15.41.143251%40smurf.noris.de In-Reply-To: <7vwtmw5nx7.fsf_-_@assigned-by-dhcp.cox.net> ``` 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" ``` ## Matthias Urlichs, 2005-08-10 22:11 Subject: [PATCH] Debian packaging for 0.99.4 Message-ID: URL: https://gitlist.dev/e/pan.2005.08.10.22.11.25.242201%40smurf.noris.de In-Reply-To: ``` 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 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 +Maintainer: Junio C Hamano 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> ``` ## Martin Langhoff, 2005-08-10 22:56 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <46a038f9050810155642bb5580@mail.gmail.com> URL: https://gitlist.dev/e/46a038f9050810155642bb5580%40mail.gmail.com In-Reply-To: ``` On 8/11/05, Matthias Urlichs wrote: > Debian packaging fixes for 0.99.4: Is this anywhere in the archive? cheers, martin ``` ## Matthias Urlichs, 2005-08-10 23:39 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <20050810233953.GV28270@kiste.smurf.noris.de> URL: https://gitlist.dev/e/20050810233953.GV28270%40kiste.smurf.noris.de In-Reply-To: <46a038f9050810155642bb5580@mail.gmail.com> ``` Hi, Martin Langhoff: > On 8/11/05, Matthias Urlichs 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 ; 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. ``` ## Sebastian Kuzminsky, 2005-08-11 03:17 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: URL: https://gitlist.dev/e/E1E33Zb-0004dT-Bx%40highlab.com In-Reply-To: <20050810233953.GV28270@kiste.smurf.noris.de> ``` Matthias Urlichs wrote: > Cogito 0.12.1 (which includes git) has been packaged by Sebastian > Kuzminsky ; 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 ``` ## Martin Langhoff, 2005-08-11 04:44 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <46a038f90508102144358a4bcf@mail.gmail.com> URL: https://gitlist.dev/e/46a038f90508102144358a4bcf%40mail.gmail.com In-Reply-To: ``` On 8/11/05, Sebastian Kuzminsky 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 ``` ## Sebastian Kuzminsky, 2005-08-11 05:01 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: URL: https://gitlist.dev/e/E1E35C2-0004kt-VH%40highlab.com In-Reply-To: <46a038f90508102144358a4bcf@mail.gmail.com> ``` Martin Langhoff wrote: > On 8/11/05, Sebastian Kuzminsky 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 ``` ## Linus Torvalds, 2005-08-11 05:05 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0508102200560.3295%40g5.osdl.org In-Reply-To: <46a038f90508102144358a4bcf@mail.gmail.com> ``` 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 ``` ## Johannes Schindelin, 2005-08-11 05:30 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0508110729390.9750%40wgmdd8.biozentrum.uni-wuerzburg.de In-Reply-To: ``` 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 ``` ## Sebastian Kuzminsky, 2005-08-11 05:48 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: URL: https://gitlist.dev/e/E1E35vU-0004nP-JR%40highlab.com In-Reply-To: ``` Linus Torvalds 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 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 ``` ## Junio C Hamano, 2005-08-11 06:12 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <7vbr45ngse.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vbr45ngse.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Sebastian Kuzminsky 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. ``` ## Matthias Urlichs, 2005-08-11 16:04 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: URL: https://gitlist.dev/e/pan.2005.08.11.16.04.11.888690%40smurf.noris.de In-Reply-To: ``` 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. ``` ## Linus Torvalds, 2005-08-11 16:30 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0508110915210.3295%40g5.osdl.org In-Reply-To: ``` 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 ``` ## Sebastian Kuzminsky, 2005-08-11 19:06 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: URL: https://gitlist.dev/e/E1E3IOG-0005HO-AK%40highlab.com In-Reply-To: ``` Linus Torvalds 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 ``` ## Junio C Hamano, 2005-08-11 19:11 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <7vfytgl25g.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vfytgl25g.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Linus Torvalds 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. is the package name; is the number of people who installed this package; is the number of people who use this package regularly; is the number of people who installed, but don't use this package regularly; 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. ``` ## Sam Ravnborg, 2005-08-11 20:15 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <20050811201558.GA2874@mars.ravnborg.org> URL: https://gitlist.dev/e/20050811201558.GA2874%40mars.ravnborg.org In-Reply-To: ``` > > 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 ``` ## Sebastian Kuzminsky, 2005-08-11 20:23 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: URL: https://gitlist.dev/e/E1E3Jag-0005Tm-EQ%40highlab.com In-Reply-To: <20050811201558.GA2874@mars.ravnborg.org> ``` Sam Ravnborg 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 ``` ## Matthias Urlichs, 2005-08-11 20:24 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <20050811202410.GB5411@kiste.smurf.noris.de> URL: https://gitlist.dev/e/20050811202410.GB5411%40kiste.smurf.noris.de In-Reply-To: <20050811201558.GA2874@mars.ravnborg.org> ``` 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 ``` ## Matthias Urlichs, 2005-08-11 20:32 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <20050811203248.GC5411@kiste.smurf.noris.de> URL: https://gitlist.dev/e/20050811203248.GC5411%40kiste.smurf.noris.de In-Reply-To: ``` 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 ``` ## Sam Ravnborg, 2005-08-11 20:32 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <20050811203258.GA3560@mars.ravnborg.org> URL: https://gitlist.dev/e/20050811203258.GA3560%40mars.ravnborg.org In-Reply-To: <20050811202410.GB5411@kiste.smurf.noris.de> ``` 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 ``` ## Sebastian Kuzminsky, 2005-08-11 20:44 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: URL: https://gitlist.dev/e/E1E3Juf-0005YZ-PR%40highlab.com In-Reply-To: <20050811203248.GC5411@kiste.smurf.noris.de> ``` Matthias Urlichs 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 ``` ## Gene Heskett, 2005-08-11 21:45 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <200508111745.49128.gene.heskett@verizon.net> URL: https://gitlist.dev/e/200508111745.49128.gene.heskett%40verizon.net In-Reply-To: <7vfytgl25g.fsf@assigned-by-dhcp.cox.net> ``` On Thursday 11 August 2005 15:11, Junio C Hamano wrote: >Linus Torvalds 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. > > is the package name; > is the number of people who installed this package; > is the number of people who use this package regularly; > is the number of people who installed, but don't use > this package regularly; > 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. ``` ## Linus Torvalds, 2005-08-11 21:51 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0508111450110.3295%40g5.osdl.org In-Reply-To: <20050811201558.GA2874@mars.ravnborg.org> ``` 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 ``` ## Linus Torvalds, 2005-08-11 21:53 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0508111448090.3295%40g5.osdl.org In-Reply-To: ``` 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 ``` ## Alan Chandler, 2005-08-11 22:13 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <42FBCD73.3090507@chandlerfamily.org.uk> URL: https://gitlist.dev/e/42FBCD73.3090507%40chandlerfamily.org.uk In-Reply-To: <20050811202410.GB5411@kiste.smurf.noris.de> ``` 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 ``` ## Sebastian Kuzminsky, 2005-08-11 22:18 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: URL: https://gitlist.dev/e/E1E3LNk-0005f0-11%40highlab.com In-Reply-To: <42FBCD73.3090507@chandlerfamily.org.uk> ``` Alan Chandler 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 ``` ## Sebastian Kuzminsky, 2005-08-11 22:20 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: URL: https://gitlist.dev/e/E1E3LPr-0005fs-D5%40highlab.com In-Reply-To: ``` Linus Torvalds 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 ``` ## Junio C Hamano, 2005-08-11 22:21 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <7v3bpgglmo.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v3bpgglmo.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200508111745.49128.gene.heskett@verizon.net> ``` Gene Heskett 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. ``` ## Christian Meder, 2005-08-11 23:09 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <1123801793.17147.12.camel@localhost> URL: https://gitlist.dev/e/1123801793.17147.12.camel%40localhost In-Reply-To: ``` On Thu, 2005-08-11 at 16:20 -0600, Sebastian Kuzminsky wrote: > Linus Torvalds 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) ``` ## Matthias Urlichs, 2005-08-11 23:12 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <20050811231202.GF5411@kiste.smurf.noris.de> URL: https://gitlist.dev/e/20050811231202.GF5411%40kiste.smurf.noris.de In-Reply-To: ``` 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 ``` ## Andreas Jellinghaus [c], 2005-08-12 08:08 Subject: Re: [PATCH] Debian packaging for 0.99.4 [u] Message-ID: <200508121008.11659.aj@dungeon.inka.de> URL: https://gitlist.dev/e/200508121008.11659.aj%40dungeon.inka.de In-Reply-To: ``` 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 # # is the package name; # is the number of people who installed this package; # is the number of people who use this package regularly; # is the number of people who installed, but don't use this package # regularly; # is the number of people who upgraded this package recently; # 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 ``` ## Matthias Urlichs, 2005-08-12 08:34 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: URL: https://gitlist.dev/e/pan.2005.08.12.08.34.45.679778%40smurf.noris.de In-Reply-To: <42FBCD73.3090507@chandlerfamily.org.uk> ``` 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. ``` ## David Lang, 2005-08-12 08:41 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.62.0508120139230.19902%40qynat.qvtvafvgr.pbz In-Reply-To: ``` 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 > 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 ``` ## Matthias Urlichs, 2005-08-12 10:35 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <20050812103555.GG5411@kiste.smurf.noris.de> URL: https://gitlist.dev/e/20050812103555.GG5411%40kiste.smurf.noris.de In-Reply-To: ``` 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" ``` ## Junio C Hamano, 2005-08-12 20:21 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <7vpssiucss.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vpssiucss.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20050810235436.GW28270@kiste.smurf.noris.de> ``` Matthias Urlichs 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? ``` ## Martin Langhoff, 2005-08-12 22:54 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <46a038f905081215547618441c@mail.gmail.com> URL: https://gitlist.dev/e/46a038f905081215547618441c%40mail.gmail.com In-Reply-To: <7vpssiucss.fsf@assigned-by-dhcp.cox.net> ``` > 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 ``` ## Matthias Urlichs, 2005-08-13 00:38 Subject: [PATCH] more Debian packaging fixes Message-ID: <20050813003814.GN5411@kiste.smurf.noris.de> URL: https://gitlist.dev/e/20050813003814.GN5411%40kiste.smurf.noris.de In-Reply-To: <7vpssiucss.fsf@assigned-by-dhcp.cox.net> ``` git-tk should be architecture independent. git-core forgot to depend on perl. Signed-Off-By: Matthias Urlichs --- Hi, Junio C Hamano: > Matthias Urlichs 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 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 ``` ## Matthias Urlichs, 2005-08-13 00:41 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <20050813004125.GO5411@kiste.smurf.noris.de> URL: https://gitlist.dev/e/20050813004125.GO5411%40kiste.smurf.noris.de In-Reply-To: <46a038f905081215547618441c@mail.gmail.com> ``` 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. ``` ## Petr Baudis, 2005-08-13 20:05 Subject: Re: My Itchlist Message-ID: <20050813200504.GL5608@pasky.ji.cz> URL: https://gitlist.dev/e/20050813200504.GL5608%40pasky.ji.cz In-Reply-To: ``` Dear diary, on Sat, Aug 06, 2005 at 04:39:01AM CEST, I got a letter where Linus Torvalds 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 ``` ## Ryan Anderson, 2005-08-13 23:57 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <20050813235716.GB6844@mythryan2.michonline.com> URL: https://gitlist.dev/e/20050813235716.GB6844%40mythryan2.michonline.com In-Reply-To: <20050812103555.GG5411@kiste.smurf.noris.de> ``` 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 ``` ## Matthias Urlichs, 2005-08-14 00:11 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <20050814001148.GV5411@kiste.smurf.noris.de> URL: https://gitlist.dev/e/20050814001148.GV5411%40kiste.smurf.noris.de In-Reply-To: <20050813235716.GB6844@mythryan2.michonline.com> ``` 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 ``` ## Junio C Hamano, 2005-08-14 00:48 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <7vek8xl4xi.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vek8xl4xi.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20050813235716.GB6844@mythryan2.michonline.com> ``` 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. ``` ## Junio C Hamano, 2005-08-14 00:49 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <7v8xz5l4um.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v8xz5l4um.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7vek8xl4xi.fsf@assigned-by-dhcp.cox.net> ``` Oops, sorry that was not something ready to be sent out. Please discard. ``` ## Ryan Anderson, 2005-08-15 05:08 Subject: Re: [PATCH] Debian packaging for 0.99.4 Message-ID: <20050815050844.GB7001@mythryan2.michonline.com> URL: https://gitlist.dev/e/20050815050844.GB7001%40mythryan2.michonline.com In-Reply-To: <20050814001148.GV5411@kiste.smurf.noris.de> ``` 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 ```