* Re: Pasky problem with 'git init URL'
From: John Stoffel @ 2005-04-22 12:44 UTC (permalink / raw)
To: Petr Baudis; +Cc: John Stoffel, Martin Schlemmer, GIT Mailing Lists
In-Reply-To: <20050421212648.GM7443@pasky.ji.cz>
Petr> Dear diary, on Thu, Apr 21, 2005 at 11:15:54PM CEST, I got a letter
Petr> where John Stoffel <john@stoffel.org> told me that...
>> >>>>> "Petr" == Petr Baudis <pasky@ucw.cz> writes:
>>
Petr> Perhaps it would be useful to have some "command classes" (with at least
Petr> cg-*-(add|ls|rm)), like:
>>
Petr> cg-branch-ls
Petr> cg-remote-rm
Petr> cg-tag-add
>>
>> Does a standard like:
>>
>> git <objecttype> <command> <args> [<obj> ...]
Petr> Isn't this basically what I was proposing? (Modulo the UI
Petr> changes related to git-pasky -> Cogito.)
I'm not quite upto speed on git, I was away on vacation when the list
started up and didn't catch it until just recently...
And it is close to what you were proposing, but instead of dashes (-)
between the command and the object, I'm proposing just a space.
Actually, I'm proposing that we decide on a grammar and it's syntax
and to try and make it orthagonal and consistent. Principal of least
surprises, etc.
Thanks,
John
^ permalink raw reply
* [PATCH] git-pasky debian dir
From: Joshua T. Corbin @ 2005-04-22 13:18 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 615 bytes --]
After seeing the spec file, I had to do this:
You can get the binary here:
http://node1.wunjo.org/~jcorbin/git-pasky_0.6.3-1_i386.deb
alternatively you can pull from here:
rsync://node1.wunjo.org/git/git
It's against b31d16fad0013b3f106b227232559e24daf36962. It installs
to /usr/bin, but I hacked things about so that *.sh goes
in /usr/share/git-pasky/scripts. Haven't had many people try it yet, but it
works for me; this isn't exactly my first debian package, but if anyone sees
any glaring issues with it, I'd love to hear about it.
Signed-off-by: Joshua T. Corbin <jcorbin@wunjo.org>
[-- Attachment #2: debian.diff --]
[-- Type: text/x-diff, Size: 24851 bytes --]
--- /dev/null
+++ 2f556bba4a059b3aaefb0bbacac64d60a14e127a/debian/changelog
@@ -0,0 +1,6 @@
+git-pasky (0.6.3-1) unstable; urgency=low
+
+ * Saw the spec file, felt obliged ;)
+
+ -- Joshua T. Corbin <jcorbin@wunjo.org> Fri, 22 Apr 2005 00:17:03 -0400
+
--- /dev/null
+++ 2f556bba4a059b3aaefb0bbacac64d60a14e127a/debian/compat
@@ -0,0 +1 @@
+4
--- /dev/null
+++ 2f556bba4a059b3aaefb0bbacac64d60a14e127a/debian/control
@@ -0,0 +1,16 @@
+Source: git-pasky
+Section: admin
+Priority: optional
+Maintainer: Joshua T. Corbin <jcorbin@wunjo.org>
+Build-Depends: debhelper (>= 4.0.0)
+Standards-Version: 3.6.1
+
+Package: git-pasky
+Architecture: any
+Depends: ${shlibs:Depends}
+Description: GIT - the stupid content tracker
+ GIT comes in two layers. The bottom layer is merely an extremely fast and
+ flexible filesystem-based database designed to store directory trees with
+ regard to their history. The top layer is a SCM-like tool which enables human
+ beings to work with the database in a manner to a degree similar to other SCM
+ tools (like CVS, BitKeeper or Monotone).
--- /dev/null
+++ 2f556bba4a059b3aaefb0bbacac64d60a14e127a/debian/copyright
@@ -0,0 +1,367 @@
+This package was debianized by Joshua T. Corbin <jcorbin@wunjo.org> on
+Fri, 22 Apr 2005 00:17:03 -0400.
+
+It was downloaded from rsync://pasky.or.cz/git
+
+License:
+
+ Note that the only valid version of the GPL as far as this project
+ is concerned is _this_ particular version of the license (ie v2, not
+ v2.2 or v3.x or whatever), unless explicitly otherwise stated.
+
+ HOWEVER, in order to allow a migration to GPLv3 if that seems like
+ a good idea, I also ask that people involved with the project make
+ their preferences known. In particular, if you trust me to make that
+ decision, you might note so in your copyright message, ie something
+ like
+
+ This file is licensed under the GPL v2, or a later version
+ at the discretion of Linus.
+
+ might avoid issues. But we can also just decide to synchronize and
+ contact all copyright holders on record if/when the occasion arises.
+
+ Linus Torvalds
+
+----------------------------------------
+
+ GNU GENERAL PUBLIC LICENSE
+ Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+ 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+ Preamble
+
+ The licenses for most software are designed to take away your
+freedom to share and change it. By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users. This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it. (Some other Free Software Foundation software is covered by
+the GNU Library General Public License instead.) You can apply it to
+your programs, too.
+
+ When we speak of free software, we are referring to freedom, not
+price. Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+ To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+ For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have. You must make sure that they, too, receive or can get the
+source code. And you must show them these terms so they know their
+rights.
+
+ We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+ Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software. If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+ Finally, any free program is threatened constantly by software
+patents. We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary. To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+ The precise terms and conditions for copying, distribution and
+modification follow.
+\f
+ GNU GENERAL PUBLIC LICENSE
+ TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+ 0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License. The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language. (Hereinafter, translation is included without limitation in
+the term "modification".) Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope. The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
+
+ 1. You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you
+conspicuously and appropriately publish on each copy an appropriate
+copyright notice and disclaimer of warranty; keep intact all the
+notices that refer to this License and to the absence of any warranty;
+and give any other recipients of the Program a copy of this License
+along with the Program.
+
+You may charge a fee for the physical act of transferring a copy, and
+you may at your option offer warranty protection in exchange for a fee.
+
+ 2. You may modify your copy or copies of the Program or any portion
+of it, thus forming a work based on the Program, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+ a) You must cause the modified files to carry prominent notices
+ stating that you changed the files and the date of any change.
+
+ b) You must cause any work that you distribute or publish, that in
+ whole or in part contains or is derived from the Program or any
+ part thereof, to be licensed as a whole at no charge to all third
+ parties under the terms of this License.
+
+ c) If the modified program normally reads commands interactively
+ when run, you must cause it, when started running for such
+ interactive use in the most ordinary way, to print or display an
+ announcement including an appropriate copyright notice and a
+ notice that there is no warranty (or else, saying that you provide
+ a warranty) and that users may redistribute the program under
+ these conditions, and telling the user how to view a copy of this
+ License. (Exception: if the Program itself is interactive but
+ does not normally print such an announcement, your work based on
+ the Program is not required to print an announcement.)
+\f
+These requirements apply to the modified work as a whole. If
+identifiable sections of that work are not derived from the Program,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works. But when you
+distribute the same sections as part of a whole which is a work based
+on the Program, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote it.
+
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Program.
+
+In addition, mere aggregation of another work not based on the Program
+with the Program (or with a work based on the Program) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+ 3. You may copy and distribute the Program (or a work based on it,
+under Section 2) in object code or executable form under the terms of
+Sections 1 and 2 above provided that you also do one of the following:
+
+ a) Accompany it with the complete corresponding machine-readable
+ source code, which must be distributed under the terms of Sections
+ 1 and 2 above on a medium customarily used for software interchange; or,
+
+ b) Accompany it with a written offer, valid for at least three
+ years, to give any third party, for a charge no more than your
+ cost of physically performing source distribution, a complete
+ machine-readable copy of the corresponding source code, to be
+ distributed under the terms of Sections 1 and 2 above on a medium
+ customarily used for software interchange; or,
+
+ c) Accompany it with the information you received as to the offer
+ to distribute corresponding source code. (This alternative is
+ allowed only for noncommercial distribution and only if you
+ received the program in object code or executable form with such
+ an offer, in accord with Subsection b above.)
+
+The source code for a work means the preferred form of the work for
+making modifications to it. For an executable work, complete source
+code means all the source code for all modules it contains, plus any
+associated interface definition files, plus the scripts used to
+control compilation and installation of the executable. However, as a
+special exception, the source code distributed need not include
+anything that is normally distributed (in either source or binary
+form) with the major components (compiler, kernel, and so on) of the
+operating system on which the executable runs, unless that component
+itself accompanies the executable.
+
+If distribution of executable or object code is made by offering
+access to copy from a designated place, then offering equivalent
+access to copy the source code from the same place counts as
+distribution of the source code, even though third parties are not
+compelled to copy the source along with the object code.
+\f
+ 4. You may not copy, modify, sublicense, or distribute the Program
+except as expressly provided under this License. Any attempt
+otherwise to copy, modify, sublicense or distribute the Program is
+void, and will automatically terminate your rights under this License.
+However, parties who have received copies, or rights, from you under
+this License will not have their licenses terminated so long as such
+parties remain in full compliance.
+
+ 5. You are not required to accept this License, since you have not
+signed it. However, nothing else grants you permission to modify or
+distribute the Program or its derivative works. These actions are
+prohibited by law if you do not accept this License. Therefore, by
+modifying or distributing the Program (or any work based on the
+Program), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Program or works based on it.
+
+ 6. Each time you redistribute the Program (or any work based on the
+Program), the recipient automatically receives a license from the
+original licensor to copy, distribute or modify the Program subject to
+these terms and conditions. You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties to
+this License.
+
+ 7. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License. If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Program at all. For example, if a patent
+license would not permit royalty-free redistribution of the Program by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Program.
+
+If any portion of this section is held invalid or unenforceable under
+any particular circumstance, the balance of the section is intended to
+apply and the section as a whole is intended to apply in other
+circumstances.
+
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system, which is
+implemented by public license practices. Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+\f
+ 8. If the distribution and/or use of the Program is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Program under this License
+may add an explicit geographical distribution limitation excluding
+those countries, so that distribution is permitted only in or among
+countries not thus excluded. In such case, this License incorporates
+the limitation as if written in the body of this License.
+
+ 9. The Free Software Foundation may publish revised and/or new versions
+of the General Public License from time to time. Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+Each version is given a distinguishing version number. If the Program
+specifies a version number of this License which applies to it and "any
+later version", you have the option of following the terms and conditions
+either of that version or of any later version published by the Free
+Software Foundation. If the Program does not specify a version number of
+this License, you may choose any version ever published by the Free Software
+Foundation.
+
+ 10. If you wish to incorporate parts of the Program into other free
+programs whose distribution conditions are different, write to the author
+to ask for permission. For software which is copyrighted by the Free
+Software Foundation, write to the Free Software Foundation; we sometimes
+make exceptions for this. Our decision will be guided by the two goals
+of preserving the free status of all derivatives of our free software and
+of promoting the sharing and reuse of software generally.
+
+ NO WARRANTY
+
+ 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
+FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
+OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
+PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
+OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
+TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
+PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
+REPAIR OR CORRECTION.
+
+ 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
+OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
+TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
+YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+ END OF TERMS AND CONDITIONS
+\f
+ How to Apply These Terms to Your New Programs
+
+ If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+ To do so, attach the following notices to the program. It is safest
+to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+ <one line to give the program's name and a brief idea of what it does.>
+ Copyright (C) <year> <name of author>
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+
+
+Also add information on how to contact you by electronic and paper mail.
+
+If the program is interactive, make it output a short notice like this
+when it starts in an interactive mode:
+
+ Gnomovision version 69, Copyright (C) year name of author
+ Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+ This is free software, and you are welcome to redistribute it
+ under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License. Of course, the commands you use may
+be called something other than `show w' and `show c'; they could even be
+mouse-clicks or menu items--whatever suits your program.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary. Here is a sample; alter the names:
+
+ Yoyodyne, Inc., hereby disclaims all copyright interest in the program
+ `Gnomovision' (which makes passes at compilers) written by James Hacker.
+
+ <signature of Ty Coon>, 1 April 1989
+ Ty Coon, President of Vice
+
+This General Public License does not permit incorporating your program into
+proprietary programs. If your program is a subroutine library, you may
+consider it more useful to permit linking proprietary applications with the
+library. If this is what you want to do, use the GNU Library General
+Public License instead of this License.
--- /dev/null
+++ 2f556bba4a059b3aaefb0bbacac64d60a14e127a/debian/dirs
@@ -0,0 +1,2 @@
+usr/bin
+usr/sbin
--- /dev/null
+++ 2f556bba4a059b3aaefb0bbacac64d60a14e127a/debian/docs
@@ -0,0 +1,3 @@
+README
+README.reference
+COPYING
--- /dev/null
+++ 2f556bba4a059b3aaefb0bbacac64d60a14e127a/debian/rules
@@ -0,0 +1,66 @@
+#!/usr/bin/make -f
+
+#export DH_VERBOSE=1
+
+CFLAGS = -Wall -g
+
+ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
+ CFLAGS += -O0
+else
+ CFLAGS += -O2
+endif
+
+configure:
+
+build: build-stamp
+
+build-stamp:
+ dh_testdir
+
+ patch -p1 < $(CURDIR)/debian/scriptdir.diff
+ $(MAKE)
+
+ touch build-stamp
+
+clean:
+ dh_testdir
+ dh_testroot
+ rm -f build-stamp
+
+ -$(MAKE) clean
+ patch -Rp1 < $(CURDIR)/debian/scriptdir.diff
+
+ dh_clean
+
+install: build
+ dh_testdir
+ dh_testroot
+ dh_clean -k
+ dh_installdirs
+
+ $(MAKE) install DESTDIR=$(CURDIR)/debian/git-pasky prefix='/usr'
+ install -m755 -d $(CURDIR)/debian/git-pasky/usr/share/doc/git-pasky/contrib
+ install $(CURDIR)/contrib/* $(CURDIR)/debian/git-pasky/usr/share/doc/git-pasky/contrib
+
+binary-arch: build install
+ dh_testdir
+ dh_testroot
+ dh_installchangelogs
+ dh_installdocs
+ dh_installexamples
+# dh_install
+# dh_installmenu
+# dh_installinfo
+ dh_installman
+ dh_link
+ dh_strip
+ dh_compress
+ dh_fixperms
+ dh_installdeb
+ dh_shlibdeps
+ dh_gencontrol
+ dh_md5sums
+ dh_builddeb
+
+binary: binary-arch
+.PHONY: build clean binary-arch binary install
--- /dev/null
+++ 2f556bba4a059b3aaefb0bbacac64d60a14e127a/debian/scriptdir.diff
@@ -0,0 +1,82 @@
+diff -u a/Makefile b/Makefile
+--- a/Makefile 2005-04-22 00:59:22.000000000 -0400
++++ b/Makefile 2005-04-22 00:59:43.000000000 -0400
+@@ -18,6 +18,7 @@
+ prefix=$(HOME)
+
+ bindir=$(prefix)/bin
++scriptdir=$(prefix)/share/git-pasky/scripts
+
+ CC=gcc
+ AR=ar
+@@ -28,11 +29,11 @@
+ check-files ls-tree merge-base merge-cache unpack-file git-export \
+ diff-cache convert-cache
+
+-SCRIPT= parent-id tree-id git gitXnormid.sh gitadd.sh gitaddremote.sh \
+- gitcommit.sh gitdiff-do gitdiff.sh gitlog.sh gitls.sh gitlsobj.sh \
+- gitmerge.sh gitpull.sh gitrm.sh gittag.sh gittrack.sh gitexport.sh \
+- gitapply.sh gitcancel.sh gitXlntree.sh commit-id gitlsremote.sh \
+- gitfork.sh gitinit.sh gitseek.sh gitstatus.sh gitpatch.sh \
++BINSCRIPTS= parent-id tree-id git gitdiff-do commit-id
++SCRIPT= gitXnormid.sh gitadd.sh gitaddremote.sh gitcommit.sh gitdiff.sh \
++ gitlog.sh gitls.sh gitlsobj.sh gitmerge.sh gitpull.sh gitrm.sh gittag.sh \
++ gittrack.sh gitexport.sh gitapply.sh gitcancel.sh gitXlntree.sh \
++ gitlsremote.sh gitfork.sh gitinit.sh gitseek.sh gitstatus.sh gitpatch.sh \
+ gitmerge-file.sh
+
+ COMMON= read-cache.o
+@@ -80,7 +81,9 @@
+
+ install: $(PROG) $(GEN_SCRIPT)
+ install -m755 -d $(DESTDIR)$(bindir)
+- install $(PROG) $(SCRIPT) $(GEN_SCRIPT) $(DESTDIR)$(bindir)
++ install -m755 -d $(DESTDIR)$(scriptdir)
++ install $(PROG) $(BINSCRIPTS) $(DESTDIR)$(bindir)
++ install $(SCRIPT) $(GEN_SCRIPT) $(DESTDIR)$(scriptdir)
+
+ clean:
+ rm -f *.o mozilla-sha1/*.o $(PROG) $(GEN_SCRIPT) $(LIB_FILE)
+diff -u a/commit-id b/commit-id
+--- a/commit-id 2005-04-22 00:59:22.000000000 -0400
++++ b/commit-id 2005-04-22 01:02:40.000000000 -0400
+@@ -5,4 +5,4 @@
+ #
+ # Takes the appropriate ID, defaults to HEAD.
+
+-gitXnormid.sh -c $1
++/usr/share/git-pasky/scripts/gitXnormid.sh -c $1
+Common subdirectories: a/contrib and b/contrib
+Only in b: debian
+diff -u a/git b/git
+--- a/git 2005-04-22 00:59:22.000000000 -0400
++++ b/git 2005-04-22 01:01:43.000000000 -0400
+@@ -17,6 +17,7 @@
+ exit 1
+ }
+
++export PATH=/usr/share/git-pasky/scripts:$PATH
+
+ help () {
+ cat <<__END__
+Common subdirectories: a/mozilla-sha1 and b/mozilla-sha1
+diff -u a/parent-id b/parent-id
+--- a/parent-id 2005-04-22 00:59:22.000000000 -0400
++++ b/parent-id 2005-04-22 01:02:01.000000000 -0400
+@@ -7,6 +7,6 @@
+
+ PARENT="^parent [A-Za-z0-9]{40}$"
+
+-id=$(gitXnormid.sh -c $1) || exit 1
++id=$(/usr/share/git-pasky/scripts/gitXnormid.sh -c $1) || exit 1
+
+ cat-file commit $id | egrep "$PARENT" | cut -d ' ' -f 2
+diff -u a/tree-id b/tree-id
+--- a/tree-id 2005-04-22 00:59:22.000000000 -0400
++++ b/tree-id 2005-04-22 01:00:40.000000000 -0400
+@@ -5,4 +5,4 @@
+ #
+ # Takes ID of the appropriate commit, defaults to HEAD.
+
+-gitXnormid.sh $1
++/usr/share/git-pasky/scripts/gitXnormid.sh $1
^ permalink raw reply
* Re: First web interface and service API draft
From: Christian Meder @ 2005-04-22 13:30 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jon Seymour, git
In-Reply-To: <20050422121059.GB7173@pasky.ji.cz>
On Fri, 2005-04-22 at 14:10 +0200, Petr Baudis wrote:
> Dear diary, on Fri, Apr 22, 2005 at 01:34:45PM CEST, I got a letter
> where Jon Seymour <jon.seymour@gmail.com> told me that...
> > On 4/22/05, Christian Meder <chris@absolutegiganten.org> wrote:
> > >
> > > Comments ? Ideas ? Other feedback ?
> > >
> >
> > I'd suggest serving XML rather than HTML and using client side XSLT to
> > transform it into HTML. Client-side XSLT works well in IE 6 and all
> > versions of Firefox, so there is no question that it is a mature
> > technology. Provide a fall back via server transformed HTML if need
> > be, but that is trivial to do once you have the client-side XSLT
> > stylesheets.
> >
> > Serving XML is as easy as serving HTML and gives you a much more
> > flexible outcome.
>
> Why "rather than"? Why not "in addition to"?
>
> You just append either .html or .xml, based on what you want.
I agree with Petr. I think we should do both.
Christian
--
Christian Meder, email: chris@absolutegiganten.org
The Way-Seeking Mind of a tenzo is actualized
by rolling up your sleeves.
(Eihei Dogen Zenji)
^ permalink raw reply
* Re: First web interface and service API draft
From: Christian Meder @ 2005-04-22 13:32 UTC (permalink / raw)
To: jon; +Cc: Petr Baudis, git
In-Reply-To: <2cfc403205042205277b2d9f69@mail.gmail.com>
On Fri, 2005-04-22 at 22:27 +1000, Jon Seymour wrote:
> On 4/22/05, Petr Baudis <pasky@ucw.cz> wrote:
> > Dear diary, on Fri, Apr 22, 2005 at 01:34:45PM CEST, I got a letter
> > where Jon Seymour <jon.seymour@gmail.com> told me that...
> > > On 4/22/05, Christian Meder <chris@absolutegiganten.org> wrote:
> > > >
> > > > Comments ? Ideas ? Other feedback ?
> > > >
> > >
> > > I'd suggest serving XML rather than HTML and using client side XSLT to
> > > transform it into HTML. ...
> >
> > Why "rather than"? Why not "in addition to"?
> >
> > You just append either .html or .xml, based on what you want.
> >
>
> You are right - there is no good reason that an implementation should
> not to support both.
>
> >From the point of view of a specification, though, I think it would be
> useful to focus on an XML content model rather than the details of one
> particular HTML model - get the XML model right and you can do
> whatever you like with the HTML model at any time after that.
Actually I think the order is get the C content model right (done), get
the Python object model right (in flux), produce an appropriate XML
model.
Christian
>
> jon.
>
> On 4/22/05, Petr Baudis <pasky@ucw.cz> wrote:
> > Dear diary, on Fri, Apr 22, 2005 at 01:34:45PM CEST, I got a letter
> > where Jon Seymour <jon.seymour@gmail.com> told me that...
> > > On 4/22/05, Christian Meder <chris@absolutegiganten.org> wrote:
> > > >
> > > > Comments ? Ideas ? Other feedback ?
> > > >
> > >
> > > I'd suggest serving XML rather than HTML and using client side XSLT to
> > > transform it into HTML. Client-side XSLT works well in IE 6 and all
> > > versions of Firefox, so there is no question that it is a mature
> > > technology. Provide a fall back via server transformed HTML if need
> > > be, but that is trivial to do once you have the client-side XSLT
> > > stylesheets.
> > >
> > > Serving XML is as easy as serving HTML and gives you a much more
> > > flexible outcome.
> >
> > Why "rather than"? Why not "in addition to"?
> >
> > You just append either .html or .xml, based on what you want.
> >
> > --
> > Petr "Pasky" Baudis
> > Stuff: http://pasky.or.cz/
> > C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
> >
>
>
--
Christian Meder, email: chris@absolutegiganten.org
The Way-Seeking Mind of a tenzo is actualized
by rolling up your sleeves.
(Eihei Dogen Zenji)
^ permalink raw reply
* Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
From: Rhys Hardwick @ 2005-04-22 13:42 UTC (permalink / raw)
To: git
Hey there,
I am trying to pull the latest repository of the linux-2.6 git from Linus'
rsync mirror.
Here is the shell:
===========
rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
defaulting to local storage area
gitpull.sh: unknown remote
gitinit.sh: pull failed
rhys@metatron:~/repo/linux-2.6.repo$ rm -r .git
rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
defaulting to local storage area
gitpull.sh: unknown remote
gitinit.sh: pull failed
rhys@metatron:~/repo/linux-2.6.repo$
=============
Any idea why this is not working?
Thanks for any help,
Rhys
^ permalink raw reply
* Re: First web interface and service API draft
From: Christian Meder @ 2005-04-22 13:44 UTC (permalink / raw)
To: El Draper; +Cc: git
In-Reply-To: <4268F027.6030304@eldiablo.co.uk>
On Fri, 2005-04-22 at 13:37 +0100, El Draper wrote:
> Christian Meder wrote:
>
> >Comments ? Ideas ? Other feedback ?
> >
> >
> >
>
> Hi guys,
>
> New around these parts, so be gentle :-)
>
> I would like to suggest the idea of a SOAP interface. If we are talking
> about a true service orientated API, then a way of calling a uri and
> having it return a nice SOAP packet with the return data in it would be
> great. If we ensured compliance with web service standards, then it
> would then mean anyone could write themselves a client desktop based
> program, a web interface, or any utility command line tools (in Java,
> .net, whatever they want, and for whatever platform), that could
> communicate with the web service and retrieve relevant data. You'd then
> have a true service interface into a Git repository. Seeing as how the
> idea of returning XML has already come up, I don't think it would be a
> stretch to extend the web interface to returning web service compliant
> SOAP packets in order to return data.
Ok, I should've known we get into this being a Web Java guy by
profession ;-)
Right now I'd like to concentrate more on a RESTful approach
http://www.xfront.com/REST-Web-Services.html
I'm concentrating on getting a clean and simple API for mere mortals and
developers alike. SOAP is likely further down on my list. But I
certainly will take patches ;-)
Christian
--
Christian Meder, email: chris@absolutegiganten.org
The Way-Seeking Mind of a tenzo is actualized
by rolling up your sleeves.
(Eihei Dogen Zenji)
^ permalink raw reply
* Re: First web interface and service API draft
From: Jon Seymour @ 2005-04-22 13:47 UTC (permalink / raw)
To: El Draper, git
In-Reply-To: <1114177468.3233.55.camel@localhost>
> >
> > >From the point of view of a specification, though, I think it would be
> > useful to focus on an XML content model rather than the details of one
> > particular HTML model - get the XML model right and you can do
> > whatever you like with the HTML model at any time after that.
>
> Actually I think the order is get the C content model right (done), get
> the Python object model right (in flux), produce an appropriate XML
> model.
Mmm.. I am not sure that a Python model is logically a pre-requisite
to the XML model nor that the ideal C API model is complete - we still
don't have a libgit, for example. For an XML model we can get by
pretty well with the data model as it is - and an XML model really
shouldn't be dependent on any particular API or programming language.
Certainly, though, an XML model isn't a pre-requisite to a Python
model. Though it might be a pre-req to a SOAP model :-).
jon.
^ permalink raw reply
* Re: Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
From: Martin Schlemmer @ 2005-04-22 13:52 UTC (permalink / raw)
To: rhys; +Cc: git
In-Reply-To: <200504221442.29488.rhys@rhyshardwick.co.uk>
[-- Attachment #1: Type: text/plain, Size: 932 bytes --]
On Fri, 2005-04-22 at 14:42 +0100, Rhys Hardwick wrote:
> Hey there,
>
> I am trying to pull the latest repository of the linux-2.6 git from Linus'
> rsync mirror.
>
> Here is the shell:
>
> ===========
>
> rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> defaulting to local storage area
> gitpull.sh: unknown remote
> gitinit.sh: pull failed
> rhys@metatron:~/repo/linux-2.6.repo$ rm -r .git
> rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> defaulting to local storage area
> gitpull.sh: unknown remote
> gitinit.sh: pull failed
> rhys@metatron:~/repo/linux-2.6.repo$
>
> =============
>
> Any idea why this is not working?
>
Try:
$ git init rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
From: Rhys Hardwick @ 2005-04-22 13:50 UTC (permalink / raw)
To: git
In-Reply-To: <1114177940.29271.9.camel@nosferatu.lan>
On Friday 22 Apr 2005 14:52, Martin Schlemmer wrote:
> On Fri, 2005-04-22 at 14:42 +0100, Rhys Hardwick wrote:
> > Hey there,
> >
> > I am trying to pull the latest repository of the linux-2.6 git from
> > Linus' rsync mirror.
> >
> > Here is the shell:
> >
> > ===========
> >
> > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> > defaulting to local storage area
> > gitpull.sh: unknown remote
> > gitinit.sh: pull failed
> > rhys@metatron:~/repo/linux-2.6.repo$ rm -r .git
> > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> > defaulting to local storage area
> > gitpull.sh: unknown remote
> > gitinit.sh: pull failed
> > rhys@metatron:~/repo/linux-2.6.repo$
> >
> > =============
> >
> > Any idea why this is not working?
>
> Try:
>
> $ git init
> rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
Exactly the same, sorry.....
Rhys
^ permalink raw reply
* Re: Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
From: Martin Schlemmer @ 2005-04-22 14:00 UTC (permalink / raw)
To: rhys; +Cc: git
In-Reply-To: <200504221450.48196.rhys@rhyshardwick.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]
On Fri, 2005-04-22 at 14:50 +0100, Rhys Hardwick wrote:
> On Friday 22 Apr 2005 14:52, Martin Schlemmer wrote:
> > On Fri, 2005-04-22 at 14:42 +0100, Rhys Hardwick wrote:
> > > Hey there,
> > >
> > > I am trying to pull the latest repository of the linux-2.6 git from
> > > Linus' rsync mirror.
> > >
> > > Here is the shell:
> > >
> > > ===========
> > >
> > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> > > defaulting to local storage area
> > > gitpull.sh: unknown remote
> > > gitinit.sh: pull failed
> > > rhys@metatron:~/repo/linux-2.6.repo$ rm -r .git
> > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> > > defaulting to local storage area
> > > gitpull.sh: unknown remote
> > > gitinit.sh: pull failed
> > > rhys@metatron:~/repo/linux-2.6.repo$
> > >
> > > =============
> > >
> > > Any idea why this is not working?
> >
> > Try:
> >
> > $ git init
> > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
>
> Exactly the same, sorry.....
>
With latest git-pasky, after blowing the .git directory? I am not sure
(and have not checked) that git will do the right thing if you retry
without clearing.
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-pasky spec file
From: Kevin Smith @ 2005-04-22 14:16 UTC (permalink / raw)
To: Chris Wright; +Cc: git
In-Reply-To: <20050422015521.GK493@shell0.pdx.osdl.net>
Chris Wright wrote:
> Here's a simple spec file to do rpm builds.
(snip)
> Creates a package named git, which seems
> fine since Linus' isn't likely to be packaged directly.
Um. Really? I can't imagine why Linus's git wouldn't be packaged
directly. He has strongly indicated that folks who want to build on top
of it should not expect to see libgit any time soon, so git will be an
important independent tool.
But presumably you'll change the name of this package to cogito soon
anyway, as soon as git-pasky itself is renamed.
Kevin
^ permalink raw reply
* [patch] fixup GECOS handling
From: Martin Schlemmer @ 2005-04-22 14:23 UTC (permalink / raw)
To: GIT Mailing Lists; +Cc: Linus Torvalds
In-Reply-To: <1113827713.5286.13.camel@localhost.localdomain>
[-- Attachment #1.1: Type: text/plain, Size: 1514 bytes --]
Hi,
This still applies - any reason for not doing this?
Thanks,
----
The GECOS is delimited by ',' or ';', so we should only use whatever is
before the first ',' or ';' for the full name, rather than just
stripping those.
Signed-off-by: Martin Schlemmer <azarah@gentoo.org>
commit-tree.c: ec53a4565ec0033aaf6df2a48d233ccf4823e8b0
--- 1/commit-tree.c
+++ 2/commit-tree.c 2005-04-18 12:22:18.000000000 +0200
@@ -96,21 +96,6 @@
if (!c)
break;
}
-
- /*
- * Go back, and remove crud from the end: some people
- * have commas etc in their gecos field
- */
- dst--;
- while (--dst >= p) {
- unsigned char c = *dst;
- switch (c) {
- case ',': case ';': case '.':
- *dst = 0;
- continue;
- }
- break;
- }
}
static const char *month_names[] = {
@@ -313,6 +298,11 @@
if (!pw)
die("You don't exist. Go away!");
realgecos = pw->pw_gecos;
+ /* The name is seperated from the room no., tel no, etc via [,;] */
+ if (strchr(realgecos, ','))
+ *strchr(realgecos, ',') = 0;
+ else if (strchr(realgecos, ';'))
+ *strchr(realgecos, ';') = 0;
len = strlen(pw->pw_name);
memcpy(realemail, pw->pw_name, len);
realemail[len] = '@';
--
Martin Schlemmer
[-- Attachment #1.2: git-gecos.patch --]
[-- Type: text/x-patch, Size: 917 bytes --]
commit-tree.c: ec53a4565ec0033aaf6df2a48d233ccf4823e8b0
--- 1/commit-tree.c
+++ 2/commit-tree.c 2005-04-18 12:22:18.000000000 +0200
@@ -96,21 +96,6 @@
if (!c)
break;
}
-
- /*
- * Go back, and remove crud from the end: some people
- * have commas etc in their gecos field
- */
- dst--;
- while (--dst >= p) {
- unsigned char c = *dst;
- switch (c) {
- case ',': case ';': case '.':
- *dst = 0;
- continue;
- }
- break;
- }
}
static const char *month_names[] = {
@@ -313,6 +298,11 @@
if (!pw)
die("You don't exist. Go away!");
realgecos = pw->pw_gecos;
+ /* The name is seperated from the room no., tel no, etc via ',' or ';' */
+ if (strchr(realgecos, ','))
+ *strchr(realgecos, ',') = 0;
+ else if (strchr(realgecos, ';'))
+ *strchr(realgecos, ';') = 0;
len = strlen(pw->pw_name);
memcpy(realemail, pw->pw_name, len);
realemail[len] = '@';
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: First web interface and service API draft
From: Jan Harkes @ 2005-04-22 14:23 UTC (permalink / raw)
To: Christian Meder; +Cc: git
In-Reply-To: <1114166517.3233.4.camel@localhost>
On Fri, Apr 22, 2005 at 12:41:56PM +0200, Christian Meder wrote:
> -------
> /<project>/blob/<blob-sha1>
> /<project>/commit/<commit-sha1>
It is trivial to find an object when given a sha, but to know the object
type you'd have to decompress it and check inside. Also the way git
stores these things you can't have both a blob and a commit with the
same sha anyways.
So why not use,
/<project/<hexadecimal sha1 representation>
will give you the raw object.
/<project/<hexadecimal sha1 representation>.html (.xml/.txt)
will give you a parsed version for user presentation
And since hexadecimal numbers only have [0-9a-f] as valid characters,
you can still have additional directories that can be guaranteed unique
as long as the first two characters are not a valid hexadecimal value.
So things like /branch/linus, or /changelog/, /log/, /diff/. Yeah, you
can't use /delta/ without looking at more than the first two characters,
but that's where dictionaries can come in handy.
Jan
^ permalink raw reply
* [git pasky] tarball question
From: Martin Schlemmer @ 2005-04-22 14:31 UTC (permalink / raw)
To: GIT Mailing Lists; +Cc: Petr Baudis
[-- Attachment #1: Type: text/plain, Size: 717 bytes --]
Hi,
I understand why you have the git-pasky-0.6.x.tar.bz2 tarballs with
the .git database included as well (btw, great stuff renaming it to
something more distributable), but its going to be a pita for users of
source based distro's like us (Gentoo), as well as our mirrors if it
gets much bigger. (Already asked r3pek to add it to portage).
How about ripping the .git directory from the next release, and just
have a un-numbered tarball (like you used to) that have the latest
snapshot of the .git directory for those that want to do git-pasky
development? Should even make things easier your side, as you could
just do a cron to update it one a day/whatever.
Thanks,
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
From: Martin Schlemmer @ 2005-04-22 14:44 UTC (permalink / raw)
To: rhys; +Cc: GIT Mailing Lists
In-Reply-To: <200504221530.32645.rhys@rhyshardwick.co.uk>
[-- Attachment #1: Type: text/plain, Size: 2025 bytes --]
On Fri, 2005-04-22 at 15:30 +0100, Rhys Hardwick wrote:
> On Friday 22 Apr 2005 15:00, Martin Schlemmer wrote:
> > On Fri, 2005-04-22 at 14:50 +0100, Rhys Hardwick wrote:
> > > On Friday 22 Apr 2005 14:52, Martin Schlemmer wrote:
> > > > On Fri, 2005-04-22 at 14:42 +0100, Rhys Hardwick wrote:
> > > > > Hey there,
> > > > >
> > > > > I am trying to pull the latest repository of the linux-2.6 git from
> > > > > Linus' rsync mirror.
> > > > >
> > > > > Here is the shell:
> > > > >
> > > > > ===========
> > > > >
> > > > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> > > > > defaulting to local storage area
> > > > > gitpull.sh: unknown remote
> > > > > gitinit.sh: pull failed
> > > > > rhys@metatron:~/repo/linux-2.6.repo$ rm -r .git
> > > > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > > > www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> > > > > defaulting to local storage area
> > > > > gitpull.sh: unknown remote
> > > > > gitinit.sh: pull failed
> > > > > rhys@metatron:~/repo/linux-2.6.repo$
> > > > >
> > > > > =============
> > > > >
> > > > > Any idea why this is not working?
> > > >
> > > > Try:
> > > >
> > > > $ git init
> > > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> > >
> > > Exactly the same, sorry.....
> >
> > With latest git-pasky, after blowing the .git directory? I am not sure
> > (and have not checked) that git will do the right thing if you retry
> > without clearing.
>
> Yes to all the above. I pulled the latest today, and make && make install.
> Also, I have tried it with a .git in place, deleted, in the unpacked
> 2.6.11-r3 source, all of the above!
>
> >From what I can gather, it must happen in an empty directory, and that is what
> the top two examples are.
>
Really weird. I tested it my side before doing my last reply. Maybe
Petr will know.
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
From: Rhys Hardwick @ 2005-04-22 14:43 UTC (permalink / raw)
To: git
In-Reply-To: <1114181091.29271.27.camel@nosferatu.lan>
On Friday 22 Apr 2005 15:44, Martin Schlemmer wrote:
> On Fri, 2005-04-22 at 15:30 +0100, Rhys Hardwick wrote:
> > On Friday 22 Apr 2005 15:00, Martin Schlemmer wrote:
> > > On Fri, 2005-04-22 at 14:50 +0100, Rhys Hardwick wrote:
> > > > On Friday 22 Apr 2005 14:52, Martin Schlemmer wrote:
> > > > > On Fri, 2005-04-22 at 14:42 +0100, Rhys Hardwick wrote:
> > > > > > Hey there,
> > > > > >
> > > > > > I am trying to pull the latest repository of the linux-2.6 git
> > > > > > from Linus' rsync mirror.
> > > > > >
> > > > > > Here is the shell:
> > > > > >
> > > > > > ===========
> > > > > >
> > > > > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > > > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6
> > > > > >.git defaulting to local storage area
> > > > > > gitpull.sh: unknown remote
> > > > > > gitinit.sh: pull failed
> > > > > > rhys@metatron:~/repo/linux-2.6.repo$ rm -r .git
> > > > > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > > > > www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> > > > > > defaulting to local storage area
> > > > > > gitpull.sh: unknown remote
> > > > > > gitinit.sh: pull failed
> > > > > > rhys@metatron:~/repo/linux-2.6.repo$
> > > > > >
> > > > > > =============
> > > > > >
> > > > > > Any idea why this is not working?
> > > > >
> > > > > Try:
> > > > >
> > > > > $ git init
> > > > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.g
> > > > >it
> > > >
> > > > Exactly the same, sorry.....
> > >
> > > With latest git-pasky, after blowing the .git directory? I am not sure
> > > (and have not checked) that git will do the right thing if you retry
> > > without clearing.
> >
> > Yes to all the above. I pulled the latest today, and make && make
> > install. Also, I have tried it with a .git in place, deleted, in the
> > unpacked 2.6.11-r3 source, all of the above!
> >
> > >From what I can gather, it must happen in an empty directory, and that
> > > is what
> >
> > the top two examples are.
>
> Really weird. I tested it my side before doing my last reply. Maybe
> Petr will know.
Hopefully!
Thanks for the help anywho.....
Rhys
^ permalink raw reply
* Re: Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
From: Rhys Hardwick @ 2005-04-22 14:54 UTC (permalink / raw)
To: git
In-Reply-To: <200504221543.43210.rhys@rhyshardwick.co.uk>
On Friday 22 Apr 2005 15:43, Rhys Hardwick wrote:
> On Friday 22 Apr 2005 15:44, Martin Schlemmer wrote:
> > On Fri, 2005-04-22 at 15:30 +0100, Rhys Hardwick wrote:
> > > On Friday 22 Apr 2005 15:00, Martin Schlemmer wrote:
> > > > On Fri, 2005-04-22 at 14:50 +0100, Rhys Hardwick wrote:
> > > > > On Friday 22 Apr 2005 14:52, Martin Schlemmer wrote:
> > > > > > On Fri, 2005-04-22 at 14:42 +0100, Rhys Hardwick wrote:
> > > > > > > Hey there,
> > > > > > >
> > > > > > > I am trying to pull the latest repository of the linux-2.6 git
> > > > > > > from Linus' rsync mirror.
> > > > > > >
> > > > > > > Here is the shell:
> > > > > > >
> > > > > > > ===========
> > > > > > >
> > > > > > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > > > > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2
> > > > > > >.6 .git defaulting to local storage area
> > > > > > > gitpull.sh: unknown remote
> > > > > > > gitinit.sh: pull failed
> > > > > > > rhys@metatron:~/repo/linux-2.6.repo$ rm -r .git
> > > > > > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > > > > > www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> > > > > > > defaulting to local storage area
> > > > > > > gitpull.sh: unknown remote
> > > > > > > gitinit.sh: pull failed
> > > > > > > rhys@metatron:~/repo/linux-2.6.repo$
> > > > > > >
> > > > > > > =============
> > > > > > >
> > > > > > > Any idea why this is not working?
> > > > > >
> > > > > > Try:
> > > > > >
> > > > > > $ git init
> > > > > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6
> > > > > >.g it
> > > > >
> > > > > Exactly the same, sorry.....
> > > >
> > > > With latest git-pasky, after blowing the .git directory? I am not
> > > > sure (and have not checked) that git will do the right thing if you
> > > > retry without clearing.
> > >
> > > Yes to all the above. I pulled the latest today, and make && make
> > > install. Also, I have tried it with a .git in place, deleted, in the
> > > unpacked 2.6.11-r3 source, all of the above!
> > >
> > > >From what I can gather, it must happen in an empty directory, and that
> > > > is what
> > >
> > > the top two examples are.
> >
> > Really weird. I tested it my side before doing my last reply. Maybe
> > Petr will know.
>
> Hopefully!
>
> Thanks for the help anywho.....
>
> Rhys
I think I have some more information. If you remove the -e from the origins
file, and put the name at the start of the line, it suddenly works!!!
Cool,
Not sure what was going on there, but hey, Petr will work it out!
Rhys
^ permalink raw reply
* Re: Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
From: Martin Schlemmer @ 2005-04-22 15:22 UTC (permalink / raw)
To: rhys; +Cc: git
In-Reply-To: <200504221554.04749.rhys@rhyshardwick.co.uk>
[-- Attachment #1: Type: text/plain, Size: 3043 bytes --]
On Fri, 2005-04-22 at 15:54 +0100, Rhys Hardwick wrote:
> On Friday 22 Apr 2005 15:43, Rhys Hardwick wrote:
> > On Friday 22 Apr 2005 15:44, Martin Schlemmer wrote:
> > > On Fri, 2005-04-22 at 15:30 +0100, Rhys Hardwick wrote:
> > > > On Friday 22 Apr 2005 15:00, Martin Schlemmer wrote:
> > > > > On Fri, 2005-04-22 at 14:50 +0100, Rhys Hardwick wrote:
> > > > > > On Friday 22 Apr 2005 14:52, Martin Schlemmer wrote:
> > > > > > > On Fri, 2005-04-22 at 14:42 +0100, Rhys Hardwick wrote:
> > > > > > > > Hey there,
> > > > > > > >
> > > > > > > > I am trying to pull the latest repository of the linux-2.6 git
> > > > > > > > from Linus' rsync mirror.
> > > > > > > >
> > > > > > > > Here is the shell:
> > > > > > > >
> > > > > > > > ===========
> > > > > > > >
> > > > > > > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > > > > > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2
> > > > > > > >.6 .git defaulting to local storage area
> > > > > > > > gitpull.sh: unknown remote
> > > > > > > > gitinit.sh: pull failed
> > > > > > > > rhys@metatron:~/repo/linux-2.6.repo$ rm -r .git
> > > > > > > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > > > > > > www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
> > > > > > > > defaulting to local storage area
> > > > > > > > gitpull.sh: unknown remote
> > > > > > > > gitinit.sh: pull failed
> > > > > > > > rhys@metatron:~/repo/linux-2.6.repo$
> > > > > > > >
> > > > > > > > =============
> > > > > > > >
> > > > > > > > Any idea why this is not working?
> > > > > > >
> > > > > > > Try:
> > > > > > >
> > > > > > > $ git init
> > > > > > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6
> > > > > > >.g it
> > > > > >
> > > > > > Exactly the same, sorry.....
> > > > >
> > > > > With latest git-pasky, after blowing the .git directory? I am not
> > > > > sure (and have not checked) that git will do the right thing if you
> > > > > retry without clearing.
> > > >
> > > > Yes to all the above. I pulled the latest today, and make && make
> > > > install. Also, I have tried it with a .git in place, deleted, in the
> > > > unpacked 2.6.11-r3 source, all of the above!
> > > >
> > > > >From what I can gather, it must happen in an empty directory, and that
> > > > > is what
> > > >
> > > > the top two examples are.
> > >
> > > Really weird. I tested it my side before doing my last reply. Maybe
> > > Petr will know.
> >
> > Hopefully!
> >
> > Thanks for the help anywho.....
> >
> > Rhys
>
> I think I have some more information. If you remove the -e from the origins
> file, and put the name at the start of the line, it suddenly works!!!
>
> Cool,
>
> Not sure what was going on there, but hey, Petr will work it out!
>
Seems your /bin/sh do not support 'echo -e' ... Know what provides
your /bin/sh (I think ash at least do support it)?
Petr, I think you should really start to consider going full bash?
--
Martin Schlemmer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-pasky spec file
From: Chris Wright @ 2005-04-22 15:21 UTC (permalink / raw)
To: Kevin Smith; +Cc: Chris Wright, git
In-Reply-To: <4269073C.1080802@qualitycode.com>
* Kevin Smith (yarcs@qualitycode.com) wrote:
> But presumably you'll change the name of this package to cogito soon
> anyway, as soon as git-pasky itself is renamed.
that's the plan.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
^ permalink raw reply
* Re: Pulling linux-2.6.git with gitinit.sh and gitpull.sh fails
From: Rhys Hardwick @ 2005-04-22 15:24 UTC (permalink / raw)
To: git
In-Reply-To: <1114183357.29271.31.camel@nosferatu.lan>
On Friday 22 Apr 2005 16:22, Martin Schlemmer wrote:
> On Fri, 2005-04-22 at 15:54 +0100, Rhys Hardwick wrote:
> > On Friday 22 Apr 2005 15:43, Rhys Hardwick wrote:
> > > On Friday 22 Apr 2005 15:44, Martin Schlemmer wrote:
> > > > On Fri, 2005-04-22 at 15:30 +0100, Rhys Hardwick wrote:
> > > > > On Friday 22 Apr 2005 15:00, Martin Schlemmer wrote:
> > > > > > On Fri, 2005-04-22 at 14:50 +0100, Rhys Hardwick wrote:
> > > > > > > On Friday 22 Apr 2005 14:52, Martin Schlemmer wrote:
> > > > > > > > On Fri, 2005-04-22 at 14:42 +0100, Rhys Hardwick wrote:
> > > > > > > > > Hey there,
> > > > > > > > >
> > > > > > > > > I am trying to pull the latest repository of the linux-2.6
> > > > > > > > > git from Linus' rsync mirror.
> > > > > > > > >
> > > > > > > > > Here is the shell:
> > > > > > > > >
> > > > > > > > > ===========
> > > > > > > > >
> > > > > > > > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > > > > > > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/lin
> > > > > > > > >ux-2 .6 .git defaulting to local storage area
> > > > > > > > > gitpull.sh: unknown remote
> > > > > > > > > gitinit.sh: pull failed
> > > > > > > > > rhys@metatron:~/repo/linux-2.6.repo$ rm -r .git
> > > > > > > > > rhys@metatron:~/repo/linux-2.6.repo$ gitinit.sh
> > > > > > > > > www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.g
> > > > > > > > >it defaulting to local storage area
> > > > > > > > > gitpull.sh: unknown remote
> > > > > > > > > gitinit.sh: pull failed
> > > > > > > > > rhys@metatron:~/repo/linux-2.6.repo$
> > > > > > > > >
> > > > > > > > > =============
> > > > > > > > >
> > > > > > > > > Any idea why this is not working?
> > > > > > > >
> > > > > > > > Try:
> > > > > > > >
> > > > > > > > $ git init
> > > > > > > > rsync://www.kernel.org/pub/linux/kernel/people/torvalds/linux
> > > > > > > >-2.6 .g it
> > > > > > >
> > > > > > > Exactly the same, sorry.....
> > > > > >
> > > > > > With latest git-pasky, after blowing the .git directory? I am
> > > > > > not sure (and have not checked) that git will do the right thing
> > > > > > if you retry without clearing.
> > > > >
> > > > > Yes to all the above. I pulled the latest today, and make && make
> > > > > install. Also, I have tried it with a .git in place, deleted, in
> > > > > the unpacked 2.6.11-r3 source, all of the above!
> > > > >
> > > > > >From what I can gather, it must happen in an empty directory, and
> > > > > > that is what
> > > > >
> > > > > the top two examples are.
> > > >
> > > > Really weird. I tested it my side before doing my last reply. Maybe
> > > > Petr will know.
> > >
> > > Hopefully!
> > >
> > > Thanks for the help anywho.....
> >
> > I think I have some more information. If you remove the -e from the
> > origins file, and put the name at the start of the line, it suddenly
> > works!!!
> >
> > Cool,
> >
> > Not sure what was going on there, but hey, Petr will work it out!
>
> Seems your /bin/sh do not support 'echo -e' ... Know what provides
> your /bin/sh (I think ash at least do support it)?
>
> Petr, I think you should really start to consider going full bash?
I use dash...
^ permalink raw reply
* Re: Mozilla SHA1 implementation
From: Linus Torvalds @ 2005-04-22 15:31 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Edgar Toernig, Git Mailing List
In-Reply-To: <17000.43340.760901.175004@cargo.ozlabs.ibm.com>
On Fri, 22 Apr 2005, Paul Mackerras wrote:
> Linus Torvalds writes:
>
> > Interestingly, the Mozilla SHA1 code is about twice as fast as the openssl
> > code on my G5, and judging by the disassembly, it's because it's much
> > simpler. I think the openssl people have unrolled all the loops totally,
> > which tends to be a disaster on any half-way modern CPU. But hey, it could
> > be something as simple as optimization flags too.
>
> Which gcc version are you using?
gcc-3.3.3.
But it's more likely the precompiled libssl. I'm not compiling the openssl
thing myself, but just using the standard 0.9.7a version that comes with
YDL. Which, btw, causes all of
/lib/libcrypto.so.4
/usr/lib/libgssapi_krb5.so.2
/usr/lib/libkrb5.so.3
/lib/libcom_err.so.2
/usr/lib/libk5crypto.so.3
/lib/libresolv.so.2
/lib/libdl.so.2
to also be included. Oh, well.
> I get the opposite result on my 2GHz G5: the Mozilla version does
> 45MB/s, the openssl version does 135MB/s, and my version does 218MB/s.
> The time for a fsck-cache on a linux-2.6 tree (cache hot) is 8.0
> seconds for the Mozilla version, 5.2 seconds for the openssl version,
> and 4.4 seconds for my version.
I get 16 seconds for the openssl one, and 8 for the Mozilla one. I'll try
your version.
Linus
^ permalink raw reply
* Re: Mozilla SHA1 implementation
From: Linus Torvalds @ 2005-04-22 15:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Edgar Toernig, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504220824480.2344@ppc970.osdl.org>
On Fri, 22 Apr 2005, Linus Torvalds wrote:
>
> > I get the opposite result on my 2GHz G5: the Mozilla version does
> > 45MB/s, the openssl version does 135MB/s, and my version does 218MB/s.
> > The time for a fsck-cache on a linux-2.6 tree (cache hot) is 8.0
> > seconds for the Mozilla version, 5.2 seconds for the openssl version,
> > and 4.4 seconds for my version.
>
> I get 16 seconds for the openssl one, and 8 for the Mozilla one. I'll try
> your version.
Ok, I get 4.9s on my kernel archive, so this is definitely a big win.
Can you sign off on the thing, since this is real new code? Let's do it
right.
Linus
^ permalink raw reply
* (anal) Q: Are there any coding styles or development guidelines?
From: Klaus Robert Suetterlin @ 2005-04-22 15:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504220838340.2344@ppc970.osdl.org>
I'm currently doing a source audit of the git core components.
Mainly I want to check if I can spot some left over memory leaks.
Unfortunately ;) I didn't find any so far (after reading five files).
Still I did find quite a lot of stuff that lint would most likely
complain about. Like not checking return values. Should this be
fixed now or isn't it time to do the cleanup, yet?
I also found several literal copies of the same function including
function name, parameter list, etc. Wouldn't it be better do clean
those up and put them in a utility.{c,h} file? A similar problem
is the continous reimplementation of linked lists, dynamic memory,
smart strings / vectors, etc. And then there are some stale files
(i.e. revision.*) that the Changelog already mentions as removed,
but which are still active in HEAD.
I am a little reluctant to do the work, as the code still changes
so fast I do not really know if code I fix will still be there
tomorrow.
Also I do not know if there is any notion of coding style published
somewhere. I only noticed, that the code does not look like anything
I'd have written and seems to follow some general principle.
Kind regards,
--Robert Suetterlin (robert@mpe.mpg.de)
phone: (+49)89 / 30000-3546 fax: (+49)89 / 30000-3950
^ permalink raw reply
* Re: enforcing DB immutability
From: Bill Davidsen @ 2005-04-22 16:10 UTC (permalink / raw)
To: linux; +Cc: git, linux-kernel, mingo
In-Reply-To: <20050420084115.2699.qmail@science.horizon.com>
linux@horizon.com wrote:
> [A discussion on the git list about how to provide a hardlinked file
> that *cannot* me modified by an editor, but must be replaced by
> a new copy.]
>
> mingo@elte.hu wrote all of:
>
>>>>perhaps having a new 'immutable hardlink' feature in the Linux VFS
>>>>would help? I.e. a hardlink that can only be readonly followed, and
>>>>can be removed, but cannot be chmod-ed to a writeable hardlink. That i
>>>>think would be a large enough barrier for editors/build-tools not to
>>>>play the tricks they already do that makes 'readonly' files virtually
>>>>meaningless.
>>>
>>>immutable hardlinks have the following advantage: a hardlink by design
>>>hides the information where the link comes from. So even if an editor
>>>wanted to play stupid games and override the immutability - it doesnt
>>>know where the DB object is. (sure, it could find it if it wants to,
>>>but that needs real messing around - editors wont do _that_)
>>
>>so the only sensible thing the editor/tool can do when it wants to
>>change the file is precisely what we want: it will copy the hardlinked
>>files's contents to a new file, and will replace the old file with the
>>new file - a copy on write. No accidental corruption of the DB's
>>contents.
>
>
> This is not a horrible idea, but it touches on another sore point I've
> worried about for a while.
>
> The obvious way to do the above *without* changing anything is just to
> remove all write permission to the file. But because I'm the owner, some
> piece of software running with my permissions can just deicde to change
> the permissions back and modify the file anyway. Good old 7th edition
> let you give files away, which could have addressed that (chmod a-w; chown
> phantom_user), but BSD took that ability away to make accounting work.
>
> The upshot is that, while separate users keeps malware from harming the
> *system*, if I run a piece of malware, it can blow away every file I
> own and make me unhappy. When (notice I'm not saying "if") commercial
> spyware for Linux becomes common, it can also read every file I own.
>
> Unless I have root access, Linux is no safer *for me* than Redmondware!
>
> Since I *do* have root access, I often set up sandbox users and try
> commercial binaries in that environment, but it's a pain and laziness
> often wins. I want a feature that I can wrap in a script, so that I
> can run a commercial binary in a nicely restricted enviromment.
>
> Or maybe I even want to set up a "personal root" level, and run
> my normal interactive shells in a slightly restricted enviroment
> (within which I could make a more-restricted world to run untrusted
> binaries). Then I could solve the immutable DB issue by having a
> "setuid" binary that would make checked-in files unwriteable at my
> normal permission level.
>
> Obviously, a fundamental change to the Unix permissions model won't
> be available to solve short-term problems, but I thought I'd raise
> the issue to get people thinking about longer-term solutions.
chattr +i file
But the real problem is that you expect your editor to be smart enough
to diddle permissions (some aren't) or create a new file (some aren't
that either).
It sounds as if you're kind of using the wrong tool here, frankly.
You also don't understand hard links, they don't hide anything, the
inode number is there, which is exactly as much information as is in the
original link. And they are lots safer, since you can't wind up with
them pointing to a non-existent file, get them in circular loops, etc.
Okay, YOU probably wouldn't, but believe me semi-competent users
regularly these things.
--
-bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
^ permalink raw reply
* Re: [Gnu-arch-users] Re: [GNU-arch-dev] [ANNOUNCEMENT] /Arch/ embraces `git'
From: Linus Torvalds @ 2005-04-22 16:13 UTC (permalink / raw)
To: Tomas Mraz; +Cc: Tom Lord, gnu-arch-users, gnu-arch-dev, git
In-Reply-To: <1114069758.5886.9.camel@perun.redhat.usu>
On Thu, 21 Apr 2005, Tomas Mraz wrote:
>
> However you're right that the original structure proposed by Linus is
> too flat.
You're wrong.
The thing is, having 256 sybdirectories already eats one _megabyte_ of
diskspace on common filessystems. If you expand that to be either deeper
(ie subdirectories within subdirectories), or use more than 8 bits for the
first level, you'll be using much more.
A megabyte of diskspace is peanuts for a project like Linux, but I think
it matters for small projects. I want git to work reasonably even for
really trivial stuff.
For example, if you just expand the fan-out to use 12 bits instead of 8,
you're now using 16MB of diskspace just for the directory structure, even
for a trivially small project. I just think that sucks.
Secondly, any sane OS (and filesystem) will look up flat directories
_faster_ than deep directories. Peter Anvid did the testing: a _totally_
flat directory is actually the best-performing one.
I just don't want to go there, because while it's ok to have tens of
thousands of files in one subdirectory, I don't think it's ok to have
hundreds of thousands of files. The 8-bit initial fan-out is very much a
middle ground: we waste some space (and some time) doing it, but it does
make the really horrible case largely go away.
Trust me, the design of git didn't just come out of my *ss. Unlike pretty
much apparently any other SCM engineer in the history of mankind (judging
by the performance crap that is out there), I actually know what performs
well, and I can calculate how much space we waste, and I actually _did_ do
so, and chose a reasonably intelligent middle ground.
You can bicker about the details (should it be 9 bits? should we pack the
names more densely? should we use another algorithm for compression? why
does it bother to use ASCII headers?), but please realize that those are
_details_. And even then, they are details where I bet that I have
selected pretty reasonable initial values.
So my choices may not be optimal, but they are "reasonable across a wide
variety of different parameters". And that includes project size,
filesystem implementation, disk wastage etc etc.
The only "extreme" choice I actually made was to go with the highest
compression level of zlib. I think I made the right choice there too: it
wastes CPU-time, but it's still pretty cheap(*) and keeps getting cheaper.
And we have a much higher read-to-write ratio that most other systems
have.
(*) I'll also argue that one reason even "-9" is cheap is actually that
most of the files we compress are small. All the metadata files are really
quite small, and most source-files tend to be just a few kB in size too -
I personally believe that _big_ files tend to be things that really change
quite seldom (things with big tables like firmware files etc). And for a
small file, it doesn't actually matter that much, the compression window
just can't grow too much.
So people say that "gzip -9" is expensive, but it's really expensive only
for large files. Try it out, it's just a personal pet theory of mine. But
realize that I _do_ generally think things through. I don't just cobble
together random things. There's a real _reason_ why git runs like a bat
out of hell. It was _designed_.
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox